Re: wait_for_file ??

[Shai Ayal]

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