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

Leonardo Milano writes:
> > > gnuplot> plot '/tmp/@18326.0' notitle
> > >               ^
> > >          can't read data file "/tmp/@18326.0"
> > >          line 0: (No such file or directory)
> 
> 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 :-(

This technique will also fail if you don't create a new Gnuplot
instance for every new plot; e.g.,

    >>> g = myGnuplot()
    >>> g.plot(dataset1)
    >>> g.plot(dataset2)

In this example the temporary file holding dataset1 will be deleted as
soon as the second plot statement is executed.  In principle one
should add the delay to the TempFile PlotItem.

One kludgey way we could handle this would be to rewrite the __del__
method of TempFile in such a way that it starts up a new thread which
first sleeps a while before deleting the file.  But again one wouldn't
know how long to sleep, and also the delays would keep the script
alive longer than necessary.

> > Possible solutions are:
> > 
> > 1. Use "inline data" instead of temporary files to communicate with
> >    gnuplot.
> 
> I am pretty new to gnuplot, so allow me a stupid question: why isn't 
> inline data available for all plotting modes?

It's been a while since I looked at this; I think the inline mode is
available for all types of plots but only for ascii data--that is, it
is incompatible with the "binary=1" option (which BTW is the default
on some platforms for GridData).

> > 3. Improve Gnuplot.py for all of us by adding an option to use named
> >    pipes instead of temporary files.
> 
> Could you please elaborate a bit more on named pies Michael?  [...]
> Python2 has at least 4 different "popen()'s ", and one of them may
> be the one we need.

Named pipes are like files in that they have filenames and exist
somewhere on the filesystem, but they are like pipes in that they read
data from another process.  You don't use popen(), you use os.mkfifo()
to create a named pipe.  I see in the Python documentation that
mkfifo() is only available under Unix, so it would at best be a
solution for that platform.

I have no experience with named pipes so I don't know whether they
would be practicable.

I should have mentioned a fourth possibility:

4. Change Gnuplot.py to implement two-way communication between
   gnuplot and Gnuplot.py.  Then, for example, Gnuplot.py could delete
   temporary files when the next gnuplot prompt appears.  This would
   be the most work of all but it would allow other new features such
   as detecting gnuplot errors, reading gnuplot fit command output
   back to python, etc.

Michael

--
Michael Haggerty
hag...@jp...