Search path and another bug in internal routines.

[Daniel J Sebald]

This post started out as "Is there a simple way of re-directing commands 
for gnuplot?" and morphed into a discovery of two bugs related to 
internal routines, I think.  This starts out describing what my initial 
quest was, and I've left that because otherwise if I describe the bugs 
it might seem too obscure and difficult to follow.

***

Does anyone know of a simple way to have gnuplot commands sent to 
somewhere else other than the pipe created with gnuplot on the other end?

Here's what I've tried:

-------------
octave-cli:1> figure(1)
octave-cli:2> ps = get(gcf(),'__plot_stream__')
ps =

      4      5   9714

octave-cli:3> ps(1) = stderr
ps =

      2      5   9714

octave-cli:4> set(gcf(),'__plot_stream__',ps)
unset multiplot;
set terminal x11 enhanced title "Figure 1"

reset; clear;
octave-cli:5> plot(1:50)
unset multiplot;
set terminal x11 enhanced title "Figure 1"

reset;
set autoscale keepfix;
set origin 0, 0
set size 1, 1
set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#ffffff"
set obj 2 rectangle from graph 0,0 to graph 1,1 behind fc rgb "#ffffff"
set border linecolor rgb "#000000"

set print "/tmp/oct-abOY7k";
------------------

At which point the terminal freezes.  I've opened a file and sent 
commands to the file, but Octave still freezes.  Is the issue that 
Octave is expecting the temp file to appear and is waiting on the temp 
file?  [It is in fact similar to that as I'll explain later.]

I've tried tracing this using the debugger and got into the file 
"axes.m", at which point it reaches

-------------------------------
debug> dbstep
stopped in /home/sebald/octave/axes.m at line 39
39:     tmp = __go_axes__ (cf, varargin{:});
debug> dbstep
stopped in /home/sebald/octave/axes.m at line 40
40:     if (__is_handle_visible__ (tmp))
unset multiplot;
set terminal x11 enhanced title "Figure 1"

reset;
set autoscale keepfix;
set origin 0, 0
set size 1, 1
set obj 1 rectangle from screen 0,0 to screen 1,1 behind fc rgb "#ffffff"
set obj 2 rectangle from graph 0,0 to graph 1,1 behind fc rgb "#ffffff"
set border linecolor rgb "#000000"

set print "/tmp/oct-heuvvh";
-----------------------

This output actually means that line 39 is where the program freezes; 
line 40 is simply the stopping point, not the line just executed.

The __go_axes__ function is an internal routine that creates a new C++ 
axes object.  I stopped searching after looking at the constructor for 
"axes".  It does seem from the gnuplot code above that somehow 
"__go_axes__" comes back out to the scripts and calls 
__go_draw_figure__.m because that's where the "set border linecolor..." 
code is.

The "set print" must be in either

__gnuplot_get_var__.m
__gnuplot_ginput__.m

, more likely __gnuplot_get_var__.m.  The problem is once the debug 
feature goes into an internal function, the ability to track is lost. 
If __go_axes__ ends up calling __gnuplot_get_var__.m, there seems no way 
of knowing that.  That, or I'm missing how this happens.

Hold on, I think I've verified the route of this, and there may be a bug 
or two.  It's as though the output is buffered, so if I put something like

  display('HI')

inside __gnuplot_get_var__.m, that text won't show before Octave 
freezes.  However,

  display('HI')
  error('HI')

will break and give

[snip]
set border linecolor rgb "#000000"
HI

error: HI
error: called from:
error: 
/usr/local/share/octave/3.7.0+/m/plot/private/__gnuplot_get_var__.m at 
line 29, column 1
error: 
/usr/local/share/octave/3.7.0+/m/plot/private/__go_draw_axes__.m at line 
40, column 18
error: 
/usr/local/share/octave/3.7.0+/m/plot/private/__go_draw_figure__.m at 
line 173, column 19
error:   /usr/local/share/octave/3.7.0+/m/plot/__gnuplot_drawnow__.m at 
line 86, column 5

HOWEVER, notice the path here is

/usr/local/share/octave/3.7.0+/m/plot/private/__gnuplot_get_var__.m

but I have a local copy of this where I put "error('ABCD');" that I 
tried using for debugging, i.e.,

octave-cli:3> type __gnuplot_get_var__
__gnuplot_get_var__ is the user-defined function defined from: 
/home/sebald/octave/__gnuplot_get_var__.m

John (if you've followed this far), there may be a bug here in which the 
internal functions aren't observing the search path properly.

Continuing onward by working with the __gnuplot_get_var__.m in the 
installed library.  This freezes:

      fprintf (ostream, "\nset print \"%s\";\n", gpin_name);
      fflush (ostream);
      [gpin, err] = fopen (gpin_name, "r");
display('HI')
error('HI');

This errors out:

      fprintf (ostream, "\nset print \"%s\";\n", gpin_name);
      fflush (ostream);
display('HI')
error('HI');
      [gpin, err] = fopen (gpin_name, "r");

So I may have identified what the issue is here.  The fopen command (an 
internal function) doesn't work properly when called from a script file 
(__gnuplot_get_var__.m) which is called from the __go_axes__ command 
(another internal function).  That seems like a second bug.

So, two bugs as best I can figure:

1) Path not right when coming out of an internal function.
2) Some problem with error status from recursively embedded internal 
routines.

Would you like me to create bug reports for these?  One report?  Two 
different reports?

Dan