Sat 19 Dec 2015 01:18:14 AM UTC, comment #10:
No. I Octave still hangs. I have no problem with other gnuplot terminals.
|
Sat 19 Dec 2015 01:08:17 AM UTC, comment #9:
Ben,
Does
plot (rand (3))
pause (10)
plot (rand (3))
work for you?
If so, this looks like the age old timing glitch
in the plot code. I thought that this had been
dealt with a while ago, but maybe not in the gnuplot
path...
|
Sat 19 Dec 2015 12:37:53 AM UTC, comment #8:
Aaron,
When I try your patch my octave gets hung up with by
If I insert a "close all" between the two plot commands, then everything works. I'm running Gnuplot v5 on Mac OS X.
Do you see the same behavior? If so, we may need some more effort to improve the user friendliness.
|
Tue 28 Apr 2015 11:09:14 AM UTC, comment #7:
Silly me - I realised it was a race condition. Attached is a fairly clean patch.
(file #33822)
|
Tue 28 Apr 2015 10:35:38 AM UTC, comment #6:
Attached is the patch. Thanks for your help Mike.
(file #33820)
|
Tue 28 Apr 2015 12:52:03 AM UTC, comment #5:
You might as well post your patch here on this bug report so others interested can find it in the most relevant place. Even if it is not ideal and not suitable for inclusion in Octave yet. Someone else may be able to find a different way to make it work.
|
Mon 27 Apr 2015 05:41:43 PM UTC, comment #4:
So I managed to get it to work, but the patch is not particularly nice.
When gnuplot is set to xterm, it will not output to a file in the same way as it would when set to dumb. This means I am forced to get the output from popen2, which stops working after the first read. The only way I could get it to work repeatedly is to SIGTERM gnuplot and set _plot_stream_ to [].
This works fine until you put it in a loop. The rapid forking and terminating of gnuplot seems to cause errors.
I do not think my patch is worthy of a merge, but I am happy to share if people want it.
|
Mon 27 Apr 2015 01:39:46 PM UTC, comment #3:
Ok, I see what you're talking about now. I agree, this does not work, and there is probably some scripting support needed in the gnuplot m-files to support this terminal type. I now see there are some special cases for the "dumb" type, where the plot goes to stdout, it is actually written to a file, read back and then printed to the terminal. It probably needs something similar for "xterm" or any other terminal types where the plot data is expected to come over stdout back to the terminal that Octave is running on. Please feel free to provide a patch to make this work if you are interested in seeing support for this added to Octave.
|
Mon 27 Apr 2015 10:18:50 AM UTC, comment #2:
Setting GNUTERM to dumb works fine, if you set it to xterm, it would just spew out the data which xterm will parse.
It should be as simple as setenv('GNUTERM', 'xterm') - if you are using an xterm, the tektronix plot will appear in a new window.
I tried to make this work by adding xterm to the list in output_to_screen, in _gnuplot_drawnow_.m, although this should not be necessary. I am assuming there is another issue somewhere.
|
Mon 27 Apr 2015 01:42:16 AM UTC, comment #1:
Thanks for your bug report. What have you tried to make this work? I am not familiar with the plotting mode you are talking about in gnuplot, so how do you make it work with gnuplot? You'll have to give some more details on what you did and what doesn't work as expected. Do you have to "set term" to a specific terminal mode? If so, just set the GNUTERM environment variable in Octave to do the same. Octave should respect whatever GNUTERM is set to. If I `setenv GNUTERM dumb`, I get ascii-art plots as I expect.
|
Mon 27 Apr 2015 01:04:19 AM UTC, original submission:
I use GNU Plot over SSH in an xterm, as plots will appear nicely using the tektronix mode without the need for X forwarding.
Am I right in thinking the same should be happening when in GNU Octave? No window appears.
|