octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: bpabbott
Subject: Re: wait_for_file ?? [who/what/where does fclose()?]
Date: Fri, 10 Sep 2010 18:58:32 +0000 (GMT)

On 10 Sep, 2010,at 02:38 PM, Shai Ayal <address@hidden> wrote:

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 testpdf
> 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?

From what I understand from my reading, pclose in the context above should work ok, since it waits for the process to end. Am I wrong? 

I'm ready for a "hell no" ... but if pclose() will not interfere with GL2PS output, then for files can we return to the conventional syntax ...

drawnow ("eps", "test.eps")

Where drawnow open and closes the file ... and for pipes pass the id?

pid = popen ("...", "w")
drawnow ("eps", pid)
pclose (pid)

I don't have any idea how much of a hassle that would be on the c++ side ... so forgive my ignorance if I'm suggesting a burdensome approach.

Ben


reply via email to

[Prev in Thread] Current Thread [Next in Thread]