Re: wait_for_file ??

[Ben Abbott]

On Sep 7, 2010, at 11:55 PM, Shai Ayal wrote:

> On Wed, Sep 8, 2010 at 5:00 AM, Michael D Godfrey
> <address@hidden> wrote:
>> 
>> Here is what is wrong between the glps_renderer::draw code in
>> gl2ps-renderer.cc and the code in print.m:
>> 
>> octave:1> plot(1:20)
>> octave:2> print ('gl2ps_t1x.pdf','-dpdf')
>> GPL Ghostscript 8.71: Unrecoverable error, exit code 1
>> warning: print.m: Error: /undefinedfilename in (/tmp/oct-m3WCVr.eps)
>> Operand stack:
>> 
>> Execution stack:
>>    %interp_exit   .runexec2   --nostringval--   --nostringval--   
>> --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
>> --nostringval--   false   1   %stopped_push
>> Dictionary stack:
>>    --dict:1158/1684(ro)(G)--   --dict:0/20(G)--   --dict:70/200(L)--
>> Current allocation mode is local
>> Last OS error: 2
>> , 'gl2ps_t1x.pdf'.
>> warning: print.m: No such file or directory, '/tmp/oct-m3WCVr.eps'.
>> octave:3> fclose of /tmp/oct-m3WCVr.eps OK>
>> ================================================
>> See the last line above.  This line came from the glps_renderer:: draw code 
>> after it
>> had written and fclosed the file /tmp/oct-m3WCVr.eps.  The code added to
>> ::draw is:    (line 83 of gl2ps_renderer.cc)
>> //      gnulib::fclose (fp);
>>        fflush(fp);
>>        if(fclose(fp) == 0) {printf("fclose of %s OK>\n", 
>> filename.c_str());fflush(stdout);}
>> ================================================
>> Also, note that Octave got all the way back to the command prompt before 
>> glps_renderer::draw
>> was done.
>> So, for some reason the print.m code continues to run even though 
>> glps_renderer
>> has not completed.    Does anyone know right away how to make the print.m 
>> code
>> wait until glps_renderer::draw is done (without the kludge that we tried)?
> 
> since octave is single threaded, it seems to me than not only did
> glps_renderer::draw not complete before the command prompt, it did not
> even START before the command prompt. I would be happy if you could
> confirm this by another printf just before the fopen.
> The problem is that glps_renderer::draw get's called by the mechanism
> that causes a redraw. this mechanism is part of FLTK, and there really
> is no way to really force a redraw, you can just ask FLTK nicely to
> redraw, and it will do so when it sees fit. This usually occurs if
> there is some action on the actual screen. I asked on the FLTK list,
> and there is no way around this.
> 
> So what happens is we ask FLTK for a redraw during the print.m
> (drawing into an eps using glps_renderer::draw), but it only really
> redraws after getting to the command prompt.
> 
> I think jwe's suggestion of drawing to a piped gs rather than to a
> file is the way to go. I'll try to implement the gl2ps part.
> 
> Shai


For gnuplot backend, the gnuplot eps file can be save to a tmp-file which can 
then be converted via the pipe.

However, for the opengl backends, the pipe approach will limit the formats to 
those available from gl2ps and those available from gs (pdf, ps, ps2, and many 
the bitmaps and printer languages). Am I correct?

Output formatted as dxf, emf, fig, hpgl, ai, pstex, mf, etc (all formats 
derived using pstoedit and fig2dev will no longer be available for opengl 
backends? .... If so I think it best to avoid using pstoedit, fig2dev, and 
epstool.

Should the "-tight" option will need to go as well?

As my questions indicate, I'm a bit cloudy on the implications. I'll be 
studying this approach for a while and plan to wait on Shai before contributing 
any significant changes.

Ben