[changeset] __gnuplot_get_var__.m seems to fail while building documentation

[Ben Abbott]

On Apr 12, 2009, at 3:00 AM, Thomas Treichl wrote:

> Ben Abbott schrieb:
>> On Apr 11, 2009, at 4:36 PM, Thomas Treichl wrote:
>>> Hi,
>>>
>>> I currently have the problem on MacOSX that I can't make the  
>>> documentation right
>>> after compilation. The version that I tried to build is:
>>>
>>>  $ hg tip
>>>  changeset:   9110:22ae6b3411a7
>>>  tag:         tip
>>>  user:        David Bateman <dbateman at free.fr>
>>>  date:        Sat Apr 11 16:26:01 2009 +0200
>>>
>>> The error output is:
>>>
>>>  makeinfo -I.. -I. -I./.. ./octave.texi
>>>  ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot',  
>>> 'eps');"
>>>  ans = [](0x0)
>>>  error: __gnuplot_get_var__: stream to gnuplot not open
>>>  error: called from:
>>>  error:   /Users/Thomas/Development/octave/scripts/plot/ 
>>> __gnuplot_get_var__.m
>>>  at line 47, column 5
>>>  error:   /Users/Thomas/Development/octave/doc/interpreter/ 
>>> sparseimages.m at
>>>  line 54, column 3
>>>  error:   /Users/Thomas/Development/octave/doc/interpreter/ 
>>> sparseimages.m at
>>>  line 30, column 2
>>>  make[3]: *** [gplot.eps] Error 1
>>>  make[2]: *** [interpreter] Error 2
>>>  make[1]: *** [doc] Error 2
>>>  make: *** [all] Error 2
>>>
>>> I then had a look at __gnuplot_get_var__.m line 40 and removed the  
>>> semicolon of
>>> this line: ostream always seems to be an empty matrix. Nect I put  
>>> a "get (h)"
>>> right before line 40 and found out that there is no  
>>> __plot_stream__ option
>>> available in the return value of "get (h)". Any ideas?
>>>
>>> Thanks,
>>>
>>>  Thomas
>> I assume this happens with the "visible" property is "off" ?
>> I'm guessing that the error actually should trace back to print.m ?
>> $ fgrep -in __gnuplot_get_var__ *.m
>> __gnuplot_get_var__.m:20:## @deftypefn {Function File} {@var{value}  
>> =} __gnuplot_get_var__ (@var{h}, @var{name}, @var{fmt})
>> __gnuplot_get_var__.m:27:function gp_var_value =  
>> __gnuplot_get_var__ (h, gp_var_name, fmt)
>> __gnuplot_get_var__.m:45:    error ("__gnuplot_get_var__: stream to  
>> gnuplot not open");
>> __gnuplot_get_var__.m:48:      error ("__gnuplot_get_var__: Need  
>> mkfifo that is not implemented under Windows");
>> __gnuplot_get_var__.m:65:      error ("__gnuplot_get_var__: Can not  
>> make fifo (%s)", msg);
>> __gnuplot_get_var__.m:89:        error ("__gnuplot_get_var__: Can  
>> not open fifo.");
>> gnuplot_drawnow.m:46:        available_terminals =  
>> __gnuplot_get_var__ (plot_stream, "GPVAL_TERMINALS");
>> print.m:407:        available_terminals = __gnuplot_get_var__ (gcf,  
>> "GPVAL_TERMINALS");
>> A simple example ...
>> octave:1> figure(1);set(gcf,'visible','off');plot(1:10);print(gcf,'- 
>> dpdf','test.pdf')
>> error: __gnuplot_get_var__: stream to gnuplot not open
>> error: called from:
>> error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/ 
>> plot/__gnuplot_get_var__.m at line 45, column 5
>> Thomas, what version of gnuplot are you running ... If not the  
>> developers sources then I'm confused.
>> A simple fix would be to check that the "visible" property is "on"  
>> before relying on __gnuplot_get_var__. If there are no objections,  
>> I'll create a changeset.
>> On another point, any chance the error can be made to trace back  
>> correctly? Meaning that the error Thomas found does not mention  
>> "print.m", but a call to print.m results in this error?
>> 48 function gplotimages (nm, typ)
>> 49   bury_output ();
>> 50   A = sparse ([2,6,1,3,2,4,3,5,4,6,1,5],
>> 51               [1,1,2,2,3,3,4,4,5,5,6,6], 1, 6, 6);
>> 52   xy = [0,4,8,6,4,2;5,0,5,7,5,7]';
>> 53   gplot (A, xy)
>> 54   print (cstrcat (nm, ".", typ), cstrcat ("-d", typ))
>> 55   bury_output ();
>> 56 endfunction
>
> Hi Ben,
>
> thanks for your help. You're right, I am 'was' using 4.3 patchlevel  
> 0. I switched back to 4.2.5 and now the creation of the doc works  
> very well. Is it currently better to use a Gnuplot of the 4.2.x  
> series?
>
> If I once again check with Gnuplot 4.3.0 then there is the  
> "visibility" property set "off", yes right.
>
> Don't know why we don't see the trace back of print.m, you're right,  
> if I put a keyboard statement to line 40 of __gnuplot_get_var__.m  
> and then use the dbstack function I see
>
>  debug> vdbs = dbstack ();
>  debug> vdbs(:).name
>  ans = __gnuplot_get_var__
>  ans = print
>  ans = sparseimages>gplotimages
>  ans = sparseimages
>  debug>
>
> Best regards,
>
>  Thoams

The problem with 4.3 is not intended. In general the backend should  
work better with 4.3.

I assume the trace back may be having trouble with the unwind_protect  
blocks ... but I'm just guessing.

In any event, I've attached a changeset intended to fix the original  
problem.

I'll do some testing, and hope to push it later today.

Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset-visible.patch
Type: application/octet-stream
Size: 3298 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090412/48b8b173/attachment.obj 
-------------- next part --------------