Bad file pointer [was: Re: Comparing plots to Matlab]

[Søren Hauberg]

ons, 01 12 2010 kl. 23:37 -0800, skrev Michael D Godfrey:
> On 12/01/2010 11:05 PM, John W. Eaton wrote: 
> > I know, but it didn't seem to be working at all without them, even if
> > the plots were displayed to the screen.  I just tried again and it
> > generated 22 PNG files without the pauses.  With them, I got 150 PNG
> > files.
> > 
> > jwe
> There is definitely a lot of randomness in this problem.  The only
> fairly reliable choice that I know of is to run locally and
> break up sequences into a few plots each.
>  Do you get the "GL2PS error: Bad file pointer"
> error? or something else?

I've been trying to debug why print crashes for me (still no luck).
During some of this debugging I started getting the "Bad file pointer"
error, so I thought I'd look into that (hoping it would fix my printing
issue). My *guess* (and I must stress that this is guess-work) is as
follows:

     1. '__fltk_print__' opens some process and sends the process ID (as
        a string) to 'drawnow'.
     2. 'drawnow' passes this string over to the gl2ps renderer, which
        converts the string to an integer and attempts to open the
        underlying stream using 'fdopen'.
     3. The call to 'fdopen' fails!

The real question is: why does this call fail? I believe the gl2ps
renderer is running in a different thread, which somehow has an
influence on the behaviour of 'fdopen'. So, I tried calling 'fdopen' in
'drawnow' (which runs in the same thread as '__fltk_print__' where the
process was opened) and then passing the resulting FILE pointer to the
gl2ps renderer. This removed the "Bad file pointer" error in the
situation where I was able to reproduce it.

I'm attaching a patch that implements the described behaviour. Michael,
could you test if this makes a difference to you?

Soren

bad_file_pointer.patch
Description: Text Data