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 16:13:57 +0000 (GMT)

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
 
Thanks!

It does appear that the output from gl2ps doesn't get written until we've returned to the Octave prompt.

In any event, I asked because I'm occasionally getting the error below when printing via the pipe.

GL2PS error: Bad file pointer

I'll have to pay closer attention to see if I can determine what causes it to show up.

Ben



reply via email to

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