there are problems with dependencies and system folders that are not visible because of how flatpak containers work, so wondering if the easiest way may be offering a flatpak version of cantor...
(In reply to avlas from comment #0) > there are problems with dependencies and system folders that are not visible > because of how flatpak containers work, so wondering if the easiest way may > be offering a flatpak version of cantor... I think there is already a flatpack version of cantor. Please check the flatpack repository mentioned here https://community.kde.org/Guidelines_and_HOWTOs/Flatpak . But I'm not sure this will solve your problem. Which kind of errors/problems do you get now?
(In reply to Alexander Semke from comment #1) > (In reply to avlas from comment #0) > > there are problems with dependencies and system folders that are not visible > > because of how flatpak containers work, so wondering if the easiest way may > > be offering a flatpak version of cantor... > I think there is already a flatpack version of cantor. Please check the > flatpack repository mentioned here > https://community.kde.org/Guidelines_and_HOWTOs/Flatpak . But I'm not sure > this will solve your problem. Which kind of errors/problems do you get now? Indeed, cantor (master branch) is available for flatpak (I thought I had the repo enabled in my computer, but forgot I did in a different computer). Issues: - KDE neon package with Octave flatpak: 1) KDE neon should not apply strong dependencies on cantor backends, as users may have those applications from elsewhere (flatpak, snap, or own compilation). This is an issue I should report to KDE neon. I workarounded this by modifying the control file of the deb package. 2) Then, in Cantor, I configured the path to octave (from the flatpak container). This works, however the internal cantor scripts () fail. I could not figure out how to fix this. For instance, (i) first instruction fails with no output but "__cantor_delimiter_line__", (ii) plot instructions fail with "error: 'cantor_print' undefined near line 1 column 12". Also, variables do not appear in the workspace. - Flatpak versions (both Cantor Nightly and Octave Stable, i.e. 5.1 at this point) 3) There is no way I can make Cantor Nightly aware of Octave (so I couldn't test further than that). This may happen because they, being containers, do not see each other (use different filesystems). There should be proper ways, though, allowing interactions between flatpak applications. - General: 4) Cantor recommends Octave 4.0 or 4.2, but there is Octave 5.1 and 4.4 (in fact all 4.x should be discouraged at this moment).
(In reply to avlas from comment #2) > 2) Then, in Cantor, I configured the path to octave (from the flatpak > container). > > This works, however the internal cantor scripts () fail. I could not figure > out how to fix this. For instance, (i) first instruction fails with no > output but "__cantor_delimiter_line__", (ii) plot instructions fail with > "error: 'cantor_print' undefined near line 1 column 12". Also, variables do > not appear in the workspace. It looks like some scripts are not found. Can you please check where the script cantor_print.m is located on your system? It must be in /usr(/local)/share/cantor/octavebackend/. I'm not sure how this is handled in flatpack containers. > 3) There is no way I can make Cantor Nightly aware of Octave (so I couldn't > test further than that). This may happen because they, being containers, do > not see each other (use different filesystems). There should be proper ways, > though, allowing interactions between flatpak applications. This is rather a question to this container infrastructure. Cantor needs e.g. octave if the user wants to work with octave. If the existence of octave is hidden from cantor, I don't see how we can fix this. > 4) Cantor recommends Octave 4.0 or 4.2, but there is Octave 5.1 and 4.4 (in > fact all 4.x should be discouraged at this moment). Ok. We'll test with the new version and we'll change the recommended version to Octave 5.1 in the next release.
(In reply to Alexander Semke from comment #3) > (In reply to avlas from comment #2) > > 2) Then, in Cantor, I configured the path to octave (from the flatpak > > container). > > > > This works, however the internal cantor scripts () fail. I could not figure > > out how to fix this. For instance, (i) first instruction fails with no > > output but "__cantor_delimiter_line__", (ii) plot instructions fail with > > "error: 'cantor_print' undefined near line 1 column 12". Also, variables do > > not appear in the workspace. > It looks like some scripts are not found. Can you please check where the > script cantor_print.m is located on your system? It must be in > /usr(/local)/share/cantor/octavebackend/. I'm not sure how this is handled > in flatpack containers. "__cantor_delimiter_line__" occurs irrespective of this. the error of cantor_print is because the filesystem is not visible to flatpak containers, but this can be workarounded by adding that folder to the Octave path, e.g. copying the folder to home and using Octave's addpath. However if I do I see first a warning: warning: your version of GraphicsMagick limits images to 8 bits per pixel and then an error: free(): double free detected in tcache 2 but no figure appears > > 3) There is no way I can make Cantor Nightly aware of Octave (so I couldn't > > test further than that). This may happen because they, being containers, do > > not see each other (use different filesystems). There should be proper ways, > > though, allowing interactions between flatpak applications. > This is rather a question to this container infrastructure. Cantor needs > e.g. octave if the user wants to work with octave. If the existence of > octave is hidden from cantor, I don't see how we can fix this. Flatpak offers exports, etc, to make executables visible, so I'm sure this can be done. I'll investigate a bit on this > > 4) Cantor recommends Octave 4.0 or 4.2, but there is Octave 5.1 and 4.4 (in > > fact all 4.x should be discouraged at this moment). > Ok. We'll test with the new version and we'll change the recommended version > to Octave 5.1 in the next release. Thank you, very appreciated! [ Regarding (1) above, I filled https://bugs.kde.org/show_bug.cgi?id=406712 ]
I could make flatpak octave executable visible to flatpak cantor by doing: sudo flatpak override --filesystem=/var org.kde.cantor However it seems that this trick is not enough and communication between the two flatpak processes does not work as expected, i.e. any instruction makes cantor turn crazy waiting for a never reached octave's response, with a 100% CPU issue. I think I will open an issue in flatpak to see how this is expected to be done... In the meantime I would like to mention a usability issue in the context of point (1) above: I would recommend against filtering not configured backends at cantor startup (if not default backend is set). This is a matter of usability, mostly important for new users trying cantor: A new user may want to use e.g. Octave to make it default and configure its path (if not automatically detected). With current filtering this is not an option and gives the impression that such an option is not supported. So most final users will give up. Advanced users may realize that they can open any other available backend (if any) and go to settings to configure e.g. Octave's path. This is far from ideal. Ideally, all backends would be present without filtering. Then, if one selects a backend that is not properly configured, settings should be opened, so the user can set them right.
link to flatpak issue: https://github.com/flatpak/flatpak/issues/2846
Good news regarding point (2) above. It seems there is a bug either in flatpak's Octave, or in the upstream Octave code, which gives an error in cantor_print even though cantor_print uses a try-catch instruction. I will fill a bug report about it. In the meantime, one can work around the issue just using the instruction in the "catch" section instead of that of the "try" section. Now that this works, I could test Octave's default graphics backend ('qt'). It works great, so I would suggest to adapt Octave's backend in Cantor to be in consonance. One last thing, I realized that Octave's warnings impede Cantor to proceed with expected outputs. Displaying warnings is a nice feature, but why is Cantor not proceeding? I guess this is a bug of some sort, isn't it?
Unfortunately this bug has become an umbrella of issues. The remaining issues are: A- Cantor packaging in kde neon: a specific bug has been filled B- Octave recommendations: (i) use Octave's default 'qt' graphics_toolkit instead of 'gnuplot' (ii) recommend using latest stable Octave version (5.1.0 at this time). C- workspace: variables are not displayed D- lack of proper communication between cantor and octave when both are flatpak containers: I reported the issue to flatpak (will wait to see if I get some feedback) If you agree, I would propose closing this bug after section B is addressed. for section C I will report another (more specific) bug. I hope this sounds good.
> C- workspace: variables are not displayed specific bug: https://bugs.kde.org/show_bug.cgi?id=406776
Forgot about this: "I realized that Octave's warnings impede Cantor to proceed with expected outputs" Filled specific bug here: https://bugs.kde.org/show_bug.cgi?id=406777
Usability issue of omitted backends at startup: Filled specific bug here https://bugs.kde.org/show_bug.cgi?id=406779
I moved all issues to specific bug reports, with the exception of these two: B- Octave recommendations: (i) use Octave's default 'qt' graphics_toolkit instead of 'gnuplot' (ii) recommend using latest stable Octave version (5.1.0 at this time). Hopefully this will be much more easy to track now.
(In reply to avlas from comment #12) > I moved all issues to specific bug reports, with the exception of these two: > > B- Octave recommendations: > (i) use Octave's default 'qt' graphics_toolkit instead of 'gnuplot' > (ii) recommend using latest stable Octave version (5.1.0 at this time). > > Hopefully this will be much more easy to track now. We have already a task in our backlog item to improve the handling of different "graphics toolkits" - https://phabricator.kde.org/T9475 . We should start working on this soon. As to Octave 5.1, we'll change the recommended version in the next release of Cantor in August. This is a rather trivial task. Everything seems to work fine with 5.1. Let's close this ticket.
(In reply to Alexander Semke from comment #13) > (In reply to avlas from comment #12) > > I moved all issues to specific bug reports, with the exception of these two: > > > > B- Octave recommendations: > > (i) use Octave's default 'qt' graphics_toolkit instead of 'gnuplot' > > (ii) recommend using latest stable Octave version (5.1.0 at this time). > > > > Hopefully this will be much more easy to track now. > We have already a task in our backlog item to improve the handling of > different "graphics toolkits" - https://phabricator.kde.org/T9475 . We > should start working on this soon. > > As to Octave 5.1, we'll change the recommended version in the next release > of Cantor in August. This is a rather trivial task. Everything seems to work > fine with 5.1. > > Let's close this ticket. Sounds good!