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

Ben Abbott bpabbott at mac.com
Sun Apr 12 11:38:16 CDT 2009


On Apr 12, 2009, at 9:22 AM, Ben Abbott wrote:

> 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
>
> <changeset-visible.patch>

Opps ... this time with the new file included.

Ben

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






More information about the Bug-octave mailing list