Hi Filipe,

I'm not sure here about the changes done for R. I think for R we'll end up with some painful limitations like no syntax completion. Is this still correct? Why not simply to replace the communication with rserver via dbus by a communication via stdout? If we only refactor this part, we don't loose any functionality. Also this would be more consistent with other "backends" where the interpreter can be embedded. For R, for julia and for python3 we start a new external process where we embedd the interpreter and have the access to its full functionality. And we communicate with this external process via stdout. So, instead of communicating with the R-executable via stdout with limited functionality like it was impelemented last summer, if I'm not wrong, we communicate with our rserver via stdout without loosing any functionality.

So, to get a clean and stable arhitecture for cantor I'd propose to:

• always communicate via stdout with all backends
• for embedablle interpreters start our external proceses (like for R, python3 and julia at the moment) where the interpreter is ebmedded. For python2 we're doing it wrongly at the moment (https://bugs.kde.org/show_bug.cgi?id=363606).

Regards,
Alexander

Hi @asemke, do you think it is better to drop R backend for 18.04 release? I was thinking in provide it for now and rework fotr the next release. Currently (in fact, since some years ago), R backend is not working but the code provide by Rishabh can fix it for now.

Hi @filipesaraiva, there're still couple of days until 18.04 is tagged and released. Let's try to fix the current implementation for R. It doesn't look completely broken and I think or hope it'ss only a small thing that needs to be fixed/adjusted now and we have again running R. In case we don't manage to fix this quickly, we still can discuss what to do with R in 18.04.

Hi @filipesaraiva, I just pushed a small fix https://commits.kde.org/cantor/46acb9e84775ed01fbe70e807cf10a1a2bc2a375 . Can you also please give it a try?

Hi, @filipesaraiva, @rishabhg, as I see qprocess_port branch isn't finished and was in a worse state than currect master branch.
On master branch we have working plots and correct highlighting and I see, that qprocess_port haven't these features, so merging qprocess_port with master will be regression.
That more important, last commit in this branch was 14 Feb 2018, so, as I see, developing on this branch stopped.
So, I will close this task as outdated on 7 July, if you don't reply until this date.