Re: wait_for_file ?? [who/what/where does fclose()?]

[Shai Ayal]

On Fri, Sep 10, 2010 at 9:29 PM, bpabbott <address@hidden> wrote:
> On 10 Sep, 2010,at 09:33 AM, Shai Ayal <address@hidden> wrote:
>
> On Fri, Sep 10, 2010 at 2:48 PM, Ben Abbott <address@hidden> wrote:
>> On Sep 9, 2010, at 7:35 AM, Shai Ayal wrote:
>>
>>> On Thu, Sep 9, 2010 at 9:07 AM, Shai Ayal <address@hidden> wrote:
>>>> On Thu, Sep 9, 2010 at 6:33 AM, Michael D Godfrey
>>>> <address@hidden> wrote:
>>>>> On 09/08/2010 06:26 PM, Ben Abbott wrote:
>>>>>
>>>>> 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
>>>>>
>>>>> This sounded good to me at first, but now I do not see how it is going
>>>>> to
>>>>> work.
>>>>> There must be something that ensures that routine glps_renderer::draw
>>>>> in
>>>>> gl2ps-renderer.cc
>>>>> really gets run when the code in __fltk_print__.m needs it.
>>>>>
>>>>> I hope Shai and Ben have this figured out.
>>>>>
>>>>> Michael
>>>>
>>>> I think using a pipe will not make the render code run when we need
>>>> it, but at least it will make sure that gs is only called when the
>>>> data to convert is ready.
>>>>
>>>> Shai
>>>>
>>>
>>> OK, I pushed the relevant changes to make fltk print to an fid
>>> **warning** this breaks current fltk printing!
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/2786e3b7072e
>>>
>>> to use, pass the fid as a string to drawnow:
>>> e.g. to keep current functionality, use
>>> fid = fopen ("test.eps","wb");
>>> drawnow ("eps" , sprintf ("%d" , fid));
>>>
>>> and to pipe it into another program, use popen:
>>> fid = popen ("cat >  test.eps" , "w")
>>> drawnow ("eps" , sprintf ("%d" , fid));
>>>
>>> Shai
>>
>> Shai does drawnow() take care of closing the pipe/file? ... or should a
>> fclose(fid) follow the drawnow. Basically, I'm confused how the pipe/file
>> should be closed given the asynchronous behavior.
>>
> glps-renderer::draw does an fclose on the pipe file once it's done
> outputting. This should take care of everything.
> Note: it's not really asynchronous -- it all happens in one thread,
> just not when you expect it to happen -- it might be when you call
> drawnow, or maybe later, at the octave prompt.
>
> Shai
>
>
> I'm seeing something I didn't expect. When I use the code below to produce
> output via GL2PS ...
>     fid = popen (pipeline{n}, "w")
>     try
>       drawnow ("eps" , sprintf ("%d" , fid));
>     catch
>       pclose (fid);
>     end
>
> ... I get the following. (I added the pclose to close the pipe in the event
> of an error).
> octave:210> print test.pdf
> octave:211> print test.pdf
> GL2PS error: Bad file pointer
> octave:212> print test.pdf
> octave:213> print test.pdf
> GL2PS error: Bad file pointer
> octave:214> print test.pdf
> octave:215> print test.pdf
> GL2PS error: Bad file pointer
> octave:216> print test.pdf
> GL2PS error: Bad file pointer
> octave:217> print test.pdf
> octave:218> print test.pdf
> octave:219> print test.pdf
> octave:220> print test.pdf
> GL2PS error: Bad file pointer
> octave:221> print test.pdf
> octave:222> print test.pdf
> GL2PS error: Bad file pointer
> octave:223> print test.pdf
> octave:224> print test.pdf
> GL2PS error: Bad file pointer
> octave:225> print test.pdf
> GL2PS error: Bad file pointer
> If instead, pclose() is called unconditionally ...
>     fid = popen (pipeline{n}, "w")
>     unwind_protect
>       drawnow ("eps" , sprintf ("%d" , fid));
>     unwind_protect_cleanup
>       pclose (fid);
>     end_unwind_protect
> octave:237> print test.pdf
> octave:238> print test.pdf
> octave:239> print test.pdf
> octave:240> print test.pdf
> octave:241> print test.pdf
> octave:242> print test.pdf
> octave:243> print test.pdf
> octave:244> print test.pdf
> octave:245> print test.pdf
> Does this indicate that (1) I should be closing the pipe?, (2) there's a
> problem in gl2ps-renderer:draw?, (3) that fclose() isn't equivalent to
> pclose()? or something else?
> MIght it be clearer for the code the does the popen to also handle the
> pclose? ... in this case the m-file that opens the pipe?
> Ben

Having the m-file pclose will make trouble again -- you don't know
that t glps-renderer::draw has been called.
What we can do is use pclose instead of fclose in glps-renderer::draw,
but that would mean the code would only work for pipes. Is the OK?