Sat 31 Jan 2015 10:24:48 PM UTC, comment #10:
If gnuplot was not found when Octave was compiled, the gnuplot_binary will be an empty string by default, so you're right, the toolkit will not work. The fix for this bug means the gnuplot toolkit will not be available in that case. Which is exactly what we want.
If the user wants to tell Octave where to find gnuplot later, they can do something like
in an octaverc startup file and everything will work as expected from that point on. I just tested a build with no toolkits and no gnuplot and confirmed that this works.
|
Sat 31 Jan 2015 09:34:15 PM UTC, comment #9:
Mike,
Right, but is it true that if gnuplot was not
found at compile time the toolkit entry is still
available so that gnuplot could be used if found
at runtime?
|
Sat 31 Jan 2015 09:27:28 PM UTC, comment #8:
Yes, the fix for this bug has nothing to do with whether gnuplot is found at compile time or run time. That has already been working for some time now.
|
Sat 31 Jan 2015 08:37:01 PM UTC, comment #7:
Mike:
I just glanced at your patch, It appears to do what
I recommended below.
Is it documented that way?
|
Sat 31 Jan 2015 06:05:35 PM UTC, comment #6:
Mike:
Would just the run time test be sufficient?
This would permit the compilation to allow
gnuplot even if it was not found, but then
if found at execution time it could be used.
And, otherwise it would not be registered.
There could be a compile time option for
people who really do not want to know gnuplot,
but I see little point in that.
|
Sat 31 Jan 2015 07:49:52 AM UTC, comment #5:
Fixed on the default branch with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/408361a8c72f
If gnuplot the program isn't found at configure time or at run time, gnuplot the toolkit will not be registered and cannot be activated.
|
Sun 16 Mar 2014 07:21:45 PM UTC, comment #4:
This bug is ancient, but still relevant. It should not be possible to pick the gnuplot toolkit if it doesn't exist.
When I set the toolkit to gnuplot and it doesn't exist then the only way I have to get out of Octave is to use Ctrl+C three times and crash the interpreter--not very user friendly.
I don't know where the fix should go. Maybe available_graphics_toolkits should check for the existence of the gnuplot executable. Maybe it should go in _init_gnuplot_.cc which is called when 'graphics_toolkit gnuplot' is used.
|
Sat 06 Oct 2012 05:12:49 PM UTC, comment #3:
Confirmed, Octave errors very badly if running gnuplot fails to run. For most typical installations, gnuplot will always be installed along with Octave, so I'm lowering the severity. Here is the output for me if the gnuplot executable is not found at runtime:
Something should be fixed here, but what should the preferred behavior be? One of these two:
1) Octave detects gnuplot doesn't exist and causes the gnuplot backend to disappear, something like:
2) Octave still allows gnuplot backend to be selected but handle the missing executable case more gracefully:
|
Sat 28 Jan 2012 10:14:39 PM UTC, comment #2:
It complains about a broken pipe and not being able to start gnuplot (understandably) until I hit ^C twice, in which case I can terminate it alltogether. I haven't yet found a way to restore a working environment after this happens.
However, I was less concerned with the "crash" than with the fact that it defaults to gnuplot although it should not.
|
Sat 28 Jan 2012 09:17:00 PM UTC, comment #1:
Do you literally mean a crash (Octave terminates abruptly after receiving a signal from the operating system) or just that Octave emits an error?
|
Sat 28 Jan 2012 09:06:20 PM UTC, original submission:
Gnuplot was not installed at compiled time, yet, available_graphics_toolkits lists gnuplot and Octave defaults to it, which results in an ugly "crash" when it attempts to run gnuplot but fails.
|