plot(1:10) returns: error: print: unknown device ${plot_file_format}
Well, could you please go to /usr/share/cantor/octavebackend and post here your cantor_print.m file?
(In reply to Nikita Sirgienko from comment #1) > Well, could you please go to /usr/share/cantor/octavebackend and post here > your cantor_print.m file? Right, I'm using the one from master set in ~/.local/share/cantor/octavebackend However, if I remove it and use the one that comes with 20.04 version, it doesn't work either and I get no output and no error in cantor. I'll run cantor in the terminal and paste the output in here...
btw, when this happens: > However, if I remove it and use the one that comes with 20.04 version, > it doesn't work either and I get no output and no error in cantor. cantor becomes irresponsive and needs restart
So, after changing the file cantor_print.m from master to 20.04 version, the error ```` error: print: unknown device ${plot_file_format} ```` gone right? Also, the file posting still will be usefull.
(In reply to Nikita Sirgienko from comment #4) > So, after changing the file cantor_print.m from master to 20.04 version, the > error > ```` > error: print: unknown device ${plot_file_format} > ```` > gone right? Also, the file posting still will be usefull. yes, it's gone. I can paste both files, but they are really the current one in master (symbolic link from repo) and the one in version 20.04 as it comes
Please post them.
Created attachment 128168 [details] 20.04
Created attachment 128169 [details] master
As I have expected, your script from master not Octave script, but cmake template for it. Real script will produce on install step and haven't contains end ${PLOT_FILE_FORMAT}. Also, script extention is .m, but template extention is .m.in
(In reply to Nikita Sirgienko from comment #9) > As I have expected, your script from master not Octave script, but cmake > template for it. Real script will produce on install step and haven't > contains end ${PLOT_FILE_FORMAT}. Also, script extention is .m, but template > extention is .m.in ok, I see, thanks for the info, so I should use master. please note however, that I only (mistakingly) took the one from master after the one in 20.04 failed. I'll add here the ouput, give me a sec. I think the problem is because octave in my system runs in flatpak and it cannot see the /tmp folder (in other words, /tmp for cantor is different than /tmp for octave).
(In reply to avlas from comment #10) > (In reply to Nikita Sirgienko from comment #9) > > As I have expected, your script from master not Octave script, but cmake > > template for it. Real script will produce on install step and haven't > > contains end ${PLOT_FILE_FORMAT}. Also, script extention is .m, but template > > extention is .m.in > > ok, I see, thanks for the info, so I should use master. please note however, > that I only (mistakingly) took the one from master after the one in 20.04 > failed. > > I'll add here the ouput, give me a sec. I think the problem is because > octave in my system runs in flatpak and it cannot see the /tmp folder (in > other words, /tmp for cantor is different than /tmp for octave). Oops, meat I *SHOULDN'T* use master as is, I SHOULD use the one that comes in 20.04 or modify it accordingly
Output: evaluating: "plot(1:10)" evaluate Executing a plot command plot temp file "/tmp/cantor_octave-PtpSCy.eps" readError setting result to a type 1 result readOutput start parsing "CANTOR_OCTAVE_BACKEND_PROMPT:1> " readError readOutput start parsing "CANTOR_OCTAVE_BACKEND_PROMPT:2> " readError parseOutput: "" currentExpressionStatusChanged 1 "cantor_startup" currentExpressionStatusChanged 0 "printf('__cantor_delimiter_line__\\n');__cantor_list__ = who();__cantor_split_var__ = split_long_rows(0);__cantor_parse_values__ = true;for __cantor_index__ = 1:length(__cantor_list__) __cantor_varname__ = char(__cantor_list__{__cantor_index__}); printf([__cantor_varname__ '\\n']); if (__cantor_parse_values__) try eval(['__cantor_string__ = disp(' __cantor_varname__ ');']); printf(__cantor_string__); catch printf(['<unprintable value>' '\\n']); end_try_catch; endif; printf('__cantor_delimiter_line__\\n')endfor;split_long_rows(__cantor_split_var__);clear __cantor_list__;clear __cantor_index__;clear __cantor_varname__;clear __cantor_parse_values__;clear __cantor_string__;clear __cantor_split_var__;" readOutput start parsing "__cantor_delimiter_line__\n" readOutput start parsing "CANTOR_OCTAVE_BACKEND_PROMPT:3> " readError parseOutput: "__cantor_delimiter_line__\n" setting result to a type 1 result currentExpressionStatusChanged 1 "printf('__cantor_delimiter_line__\\n');__cantor_list__ = who();__cantor_split_var__ = split_long_rows(0);__cantor_parse_values__ = true;for __cantor_index__ = 1:length(__cantor_list__) __cantor_varname__ = char(__cantor_list__{__cantor_index__}); printf([__cantor_varname__ '\\n']); if (__cantor_parse_values__) try eval(['__cantor_string__ = disp(' __cantor_varname__ ');']); printf(__cantor_string__); catch printf(['<unprintable value>' '\\n']); end_try_catch; endif; printf('__cantor_delimiter_line__\\n')endfor;split_long_rows(__cantor_split_var__);clear __cantor_list__;clear __cantor_index__;clear __cantor_varname__;clear __cantor_parse_values__;clear __cantor_string__;clear __cantor_split_var__;" currentExpressionStatusChanged 0 "plot(1:10)" readOutput start parsing "CANTOR_OCTAVE_BACKEND_PROMPT:4> " readError parseOutput: ""
Yes, the log looks correct, but as I see Cantor haven't catch any file in /tmp. So, maybe, as you have said, flatpack Octave Just can't generate plot files in /tmp directory
(In reply to Nikita Sirgienko from comment #13) > Yes, the log looks correct, but as I see Cantor haven't catch any file in > /tmp. So, maybe, as you have said, flatpack Octave Just can't generate plot > files in /tmp directory One thing that would be nice for Cantor though is that if loading the eps from /tmp fails for whatever reason, Cantor fails gracefully (i.e., it displays that error and keeps the octave backend functional). Currently no error is shown and octave backend stops working, even when removing the plot instruction, cantor is irresponsive.
By the way, I workarounded the issue starting flatpak's octave as follows (it makes system's /tmp accessible to flatpak's sandbox): ``` #!/bin/sh exec /usr/bin/flatpak run --branch=stable --arch=x86_64 --filesystem=/tmp org.octave.Octave "$@" ```
Well, I will see, how behaviour can be improved in error handling.
(In reply to Nikita Sirgienko from comment #16) > Well, I will see, how behaviour can be improved in error handling. Thanks, appreciated!
I realized about another plotting issue: - If I plot sth using gnuplot graphics and then move to qt and plot again, the plot works in both graphic backends. - However, if I first move to qt graphics and then plot, the figure is not displayed, and neither it is when I move back to gnuplot graphics.
(In reply to avlas from comment #18) > I realized about another plotting issue: > > - If I plot sth using gnuplot graphics and then move to qt and plot again, > the plot works in both graphic backends. > > - However, if I first move to qt graphics and then plot, the figure is not > displayed, and neither it is when I move back to gnuplot graphics. I found another plotting issue. I opened a different bug for all these latter plot issues: https://bugs.kde.org/show_bug.cgi?id=421229
Git commit 87172a9416a8949cc80350b733d771d7b01d90f3 by Nikita Sirgienko. Committed on 11/05/2020 at 22:37. Pushed by sirgienko into branch 'master'. [Octave] Add check, if Octave can have write in temporary dir FIXED-IN: 20.07.70 M +2 -1 src/backends/octave/CMakeLists.txt M +1 -1 src/backends/octave/octaveexpression.cpp M +48 -2 src/backends/octave/octavesession.cpp M +3 -0 src/backends/octave/octavesession.h M +1 -1 src/lib/CMakeLists.txt M +38 -0 src/lib/backend.cpp M +8 -1 src/lib/backend.h https://invent.kde.org/kde/cantor/commit/87172a9416a8949cc80350b733d771d7b01d90f3
(In reply to Nikita Sirgienko from comment #20) > Git commit 87172a9416a8949cc80350b733d771d7b01d90f3 by Nikita Sirgienko. > Committed on 11/05/2020 at 22:37. > Pushed by sirgienko into branch 'master'. > > [Octave] Add check, if Octave can have write in temporary dir > FIXED-IN: 20.07.70 > > M +2 -1 src/backends/octave/CMakeLists.txt > M +1 -1 src/backends/octave/octaveexpression.cpp > M +48 -2 src/backends/octave/octavesession.cpp > M +3 -0 src/backends/octave/octavesession.h > M +1 -1 src/lib/CMakeLists.txt > M +38 -0 src/lib/backend.cpp > M +8 -1 src/lib/backend.h > > https://invent.kde.org/kde/cantor/commit/ > 87172a9416a8949cc80350b733d771d7b01d90f3 I tested this fix (using Cantor's nightly flatpak package) and although it's informative about missing plotting capabilities, it could be improved. This is the popup dialog I got: ``` Plot integration test failed. Failed to open the file /tmp/cantor_octave_plot_integration_test.txt during the plot integration test. The integration of plots will be disabled. ``` First, I don't think the user needs to know about /tmp/cantor_octave_plot_integration_test.txt, just telling that access to the /tmp was not granted would likely be enough. But more importantly Octave fails to work at all afterwards, not only plotting is limited but instructions such as `2+2` also fail: no output and no error messages telling what's wrong either. Ideally the user should be told about missing plot capability but she would be allowed to work otherwise...
Also this test is done even if I don't invoke any plotting function. Starting cantor with octave backend and executing `2+2` also triggers the plotting dialog and irresposive Octave worksheet afterwards.
(In reply to avlas from comment #21) > I tested this fix (using Cantor's nightly flatpak package) and although it's > informative about missing plotting capabilities, it could be improved. I don't think, that Cantor as flatpak can be usable, because Cantor needs executable and filesystem access from host and this is not very good working in flatpak. Also, I suppose, you point to your script, that you have mentioned before, rigth? ``` #!/bin/sh exec /usr/bin/flatpak run --branch=stable --arch=x86_64 --filesystem=/tmp org.octave.Octave "$@" ``` I have reproduce this conditions (flatpak Cantor and this script) and well, the problem is, that inside flatpak package path /usr/bin/flatpak is invalid, so Cantor just print me error from this sh script. But I suppose, we still need a code for notice user, if Octave executable finishes suddenly, like in some other backends. > First, I don't think the user needs to know about > /tmp/cantor_octave_plot_integration_test.txt, just telling that access to > the /tmp was not granted would likely be enough. But that problem is more complicated and there are some possibilityes: Octave don't create this file, Cantor haven't permissions to read /tmp, etc. So, because of that the message have so inconcrete text.
(In reply to Nikita Sirgienko from comment #23) > (In reply to avlas from comment #21) > > I tested this fix (using Cantor's nightly flatpak package) and although it's > > informative about missing plotting capabilities, it could be improved. > I don't think, that Cantor as flatpak can be usable, because Cantor needs > executable and filesystem access from host and this is not very good working > in flatpak. > Also, I suppose, you point to your script, that you have mentioned before, > rigth? > ``` > #!/bin/sh > exec /usr/bin/flatpak run --branch=stable --arch=x86_64 --filesystem=/tmp > org.octave.Octave "$@" > ``` > I have reproduce this conditions (flatpak Cantor and this script) and well, > the problem is, that inside flatpak package path /usr/bin/flatpak is > invalid, so Cantor just print me error from this sh script. But I suppose, > we still need a code for notice user, if Octave executable finishes > suddenly, like in some other backends. > > > First, I don't think the user needs to know about > > /tmp/cantor_octave_plot_integration_test.txt, just telling that access to > > the /tmp was not granted would likely be enough. > But that problem is more complicated and there are some possibilityes: > Octave don't create this file, Cantor haven't permissions to read /tmp, etc. > So, because of that the message have so inconcrete text. I think I didn't explain myself quite well. Let me try again: I was not trying to get into the ultimate problem of why the test fails (which is that cantor uses a different /tmp inside its sandbox). I was just mentioning that when the test fails, Cantor should be smart enough to only limit these functions that require accessing to system's /tmp, i.e. plotting, and work fine otherwise, so that users can execute Octave's commands that are not associated with plotting. For the case you want to try it yourself, communication with Octave via flatpak's Cantor is successful if Cantor in flatpak is run with this: ``` #!/bin/sh exec /usr/bin/flatpak run --branch=master --arch=x86_64 --filesystem=/tmp --filesystem=$HOME org.kde.cantor "$@" ``` But again plotting should not work yet with just this because Cantor is still looking for the plots in a different /tmp (I may need sth else than --filesystem=/tmp in the script). This may be sth possible to achieve but unfortunately I need to deal with other things at the moment and don't have the time right now to investigate.
On a second thought I think this should work ``` #!/bin/sh exec /usr/bin/flatpak run --branch=master --arch=x86_64 --filesystem=/tmp --filesystem=$HOME org.kde.cantor "$@" ``` Saying this because I manually created the file and cantor automatically got rid of it (as I can see in part of the changes you introduced), so the file was visible and could be deleted. This makes me think there is some sort of issue with these last changes you introduced. Unfortunately there is no way for me to test this in the flatpak version immediate before to this commit. If you reverted these changes I could give it a try... (once a new flatpak version is made available)
(In reply to avlas from comment #24) > > I think I didn't explain myself quite well. Let me try again: > > I was not trying to get into the ultimate problem of why the test fails > (which is that cantor uses a different /tmp inside its sandbox). > > I was just mentioning that when the test fails, Cantor should be smart > enough to only limit these functions that require accessing to system's > /tmp, i.e. plotting, and work fine otherwise, so that users can execute > Octave's commands that are not associated with plotting. Yes, this is correct, and this is actually how new code works. For example, when use my normally builed Cantor (master branch) and Octave from flatpak (without enabled access to /tmp), I have gotten error message about disabling plot integration, but after closing it, Octave backend works correctly and even plots works (but appears in separate window, because of disabled plot integration I have also tried reproduce your problem, but I failed to run Cantor from flatpak with Octave from flatpak.
Created attachment 128428 [details] Cantor screen 1
Created attachment 128429 [details] Cantor screen 2
Created attachment 128430 [details] Cantor screen 3
Created attachment 128431 [details] Cantor screen 4
See, how it works in attachments, that I have added.
(In reply to Nikita Sirgienko from comment #26) > (In reply to avlas from comment #24) > > > > I think I didn't explain myself quite well. Let me try again: > > > > I was not trying to get into the ultimate problem of why the test fails > > (which is that cantor uses a different /tmp inside its sandbox). > > > > I was just mentioning that when the test fails, Cantor should be smart > > enough to only limit these functions that require accessing to system's > > /tmp, i.e. plotting, and work fine otherwise, so that users can execute > > Octave's commands that are not associated with plotting. > Yes, this is correct, and this is actually how new code works. For example, > when use my normally builed Cantor (master branch) and Octave from flatpak > (without enabled access to /tmp), I have gotten error message about > disabling plot integration, but after closing it, Octave backend works > correctly and even plots works (but appears in separate window, because of > disabled plot integration > > I have also tried reproduce your problem, but I failed to run Cantor from > flatpak with Octave from flatpak. I'm sorry to insist. It may work for you but I think there are still issues with this because this is not how it works in my system: - Flatpak's Cantor is able to remove the file that I set by hand in /tmp, which means Cantor is having access to /tmp, but the test fails anyway. Flatpak's Octave is able to write to /tmp as well just fine as I can see plots in Non-flatpak's Cantor. And both Cantors have the same config with respect to Flatpak's Octave. - Furthermore, once the test fails, nothing works in Flatpak's Octave anymore. From Octave options in Cantor I see that I can use png/jpg/svg but not eps as you are showing in your screenshot. I guess this is because in flatpak ghostscript is not available. Wondering if that makes the difference between what you see and what I see.
(In reply to avlas from comment #32) > (In reply to Nikita Sirgienko from comment #26) > > (In reply to avlas from comment #24) > > > > > > I think I didn't explain myself quite well. Let me try again: > > > > > > I was not trying to get into the ultimate problem of why the test fails > > > (which is that cantor uses a different /tmp inside its sandbox). > > > > > > I was just mentioning that when the test fails, Cantor should be smart > > > enough to only limit these functions that require accessing to system's > > > /tmp, i.e. plotting, and work fine otherwise, so that users can execute > > > Octave's commands that are not associated with plotting. > > Yes, this is correct, and this is actually how new code works. For example, > > when use my normally builed Cantor (master branch) and Octave from flatpak > > (without enabled access to /tmp), I have gotten error message about > > disabling plot integration, but after closing it, Octave backend works > > correctly and even plots works (but appears in separate window, because of > > disabled plot integration > > > > I have also tried reproduce your problem, but I failed to run Cantor from > > flatpak with Octave from flatpak. > > I'm sorry to insist. It may work for you but I think there are still issues > with this because this is not how it works in my system: > > - Flatpak's Cantor is able to remove the file that I set by hand in /tmp, > which means Cantor is having access to /tmp, but the test fails anyway. > Flatpak's Octave is able to write to /tmp as well just fine as I can see > plots in Non-flatpak's Cantor. And both Cantors have the same config with > respect to Flatpak's Octave. > > - Furthermore, once the test fails, nothing works in Flatpak's Octave > anymore. > > From Octave options in Cantor I see that I can use png/jpg/svg but not eps > as you are showing in your screenshot. I guess this is because in flatpak > ghostscript is not available. Wondering if that makes the difference between > what you see and what I see. Sorry, I meant Faltpak's Cantor here: - Furthermore, once the test fails, nothing works in Flatpak's Octave anymore.