Re: [Gnuplot-py-users] Re: gnuplot-py problems

[Leonardo M. <lm...@ud...>]

Hi Michael, Jonathan:

> > gnuplot> plot '/tmp/@18326.0' notitle
> >               ^
> >          can't read data file "/tmp/@18326.0"
> >          line 0: (No such file or directory)

Yes, that was my first and really only problem with Gnuplot. 
It is well documented in the source/docs, but who reads the 
manual before using software ;-)

Anyway, what I did as a dirty horrible quick workaround
is to inherit the Gnuplot class in my own Gnuplot class:

##### Code begins

class myGnuplot(Gnuplot.Gnuplot):
    """
    My addons to Gnuplot

    It will hopefully become a high level simple library some day ...
    """

    def __del__(self):
        """
        Destructor 
        """
        time.sleep(1)

    # (... some other methods are defined below in the class ...)

####

I always call instances of myGnuplot so that I make sure there is
a 1 second delay before deleting the instance, and thus the temporary
files. This works for me for regular 2D plots (y = y (x)).
For surface plots you need more than 1 second though,
but there is no way to estimate in general :-(

As Michael suggested, we need a robust solution
(and I think we really need it, that's one of the things
I had in mind when I suggested opening the list BTW)

Michael suggests:

> There is no way for Gnuplot.py to know when
> gnuplot is done reading the temporary file, so there is no general way
> for it to know when it is actually safe to delete the file.

It seems so, I tried many dirty tricks to find out when gnuplot is 
done with the tmp files with no luck :-(

> Possible solutions are:
> 
> 1. Use "inline data" instead of temporary files to communicate with
>    gnuplot.  This is already available in gnuplot for many plotting
>    modes if you specify the "inline=1" option to the constructor of
>    the Data object, or if you set GnuplotOpts.prefer_inline_data=1.

I am pretty new to gnuplot, so allow me a stupid question: why isn't 
inline data available for all plotting modes ?. Is it a limitation
of gnuplot or a limitation (i.e. non-implemented feature) of 
Gnuplot.py ? . If the latter is the case, would it make sense
to implement in-line data for all modes and use it as a default ?

> 3. Improve Gnuplot.py for all of us by adding an option to use named
>    pipes instead of temporary files.  I think it should be possible
>    for Gnuplot.py to know when gnuplot has finished reading the data
>    from the named pipe so that there is no more ambiguity.  Note that
>    it will take some effort to make such a solution portable across
>    operating systems, which is the main reason that I haven't
>    undertaken it already.

Could you please elaborate a bit more on named pies Michael ?. I am 
very curious. It does seem to be a non-trivial job as you
said. Python2 has at least 4 different "popen()'s ", and one 
of them may be the one we need. I tried playing  a bit some
time ago but I didn't find the answer and had no time to
keep trying :-(

Cheers
-- Leo