gnuplot-py-users Mailing List for Gnuplot.py

Dear Andrey or Andre,

I am forwarding this question to the gnuplot-py-users list.  I suggest
you join this list if you are interested in Gnuplot.py issues.  You
can do so at

    http://lists.sourceforge.net/lists/listinfo/gnuplot-py-users

Andre Revyakin writes:
> Dear Michael,
> 
> I attempted to install Gnuplot.py on Win98 having numpy and gnuplot
> installed and had no luck. I extracted the content 
> of the package into python22/gnuplot
> directory, then from within python22 I typed python gnuplot/setup.py
> build, then python gnuplot/setup.py install. Then I tried importing
> Gnuplot from python shell and it could not  do that.
> The error messages that I get are attached. I would greatly appreciate
> your assistance. Thank you in advance,
> 
> Andrey Revyakin, Ph D student.

I don't use windows so I can't help too much.  But it seems strange
that you extracted the contents to python22/gnuplot and then ran
setup.py--normally you would do one or the other:

1. Extract it to python22/Gnuplot then it should be ready to run, or

2. Extract it elsewhere and then run setup.py which installs it to
   python22/Gnuplot.

Method 2 is generally recommended.  Maybe this helps?

Michael

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

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...

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

Dear Jonathan,

Jonathan Ricketson writes:
> Hey Michael, the interface that you have written for gnuplot is
> really good.  But I am having a problem with using it from a web
> browser.
> 
> The funny thing is that it works fine from the command line but when
> I try to run the script from a browser it has this problem:
> 
> gnuplot> set title "Some Title"
> gnuplot> set term png
> gnuplot> set output "/var/www/sample.png"
> gnuplot> set data style linespoints
> gnuplot> plot '/tmp/@18326.0' notitle
> 
> gnuplot> plot '/tmp/@18326.0' notitle
>               ^
>          can't read data file "/tmp/@18326.0"
>          line 0: (No such file or directory)
> 
> the problem seems to be that the tmp file is deleted too quickly, or
> doesn't exist yet... Because from the command line I can replicate
> the problem by the following code:
> 
>   g.plot(data)
>   raw_input('Please press return to continue...\n')
> 
> If I keep the raw input line, then it works, otherwise if I take it
> out, then it has the same error as above.
> 
> If you have any idea what the problem might be I would really
> appreciate your help.
> 
> Jonathan

Your diagnosis is exactly correct.  Communication with gnuplot is via
temporary files by default, and the temporary files are deleted as
soon as the "Gnuplot.Data" object is garbage collected, which in your
example probably occurs when the script ends or when you plot
something else.  (Until you plot something else, the Gnuplot object
keeps a reference to all of the old plot items to prevent they're
being garbage collected.)  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.

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.

2. Introduce a delay between the time you plot and the time you allow
   the Data object to be deleted.  You could just use time.sleep(), or
   in your example you might watch for the creation of the
   /var/www/sample.png file and at that point assume that gnuplot is
   done with the temporary file.

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.

I have directed this reply to the gnuplot-py-users mailing list.
Please join this list if you are interested in Gnuplot.py issues.  You
can do so at the following web site:

    http://lists.sourceforge.net/lists/listinfo/gnuplot-py-users

Yours,
Michael

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

On Wed, 14 Aug 2002, Michael Haggerty wrote:

> For just setting tables and line types and stuff you don't have to
> extend the PlotItem interface directly; you can use the Data class
> which is a type of PlotItem already customized for array data.
>
> There are many examples in demo.py about how to use the Data class.
> For example,
>
>     x = arange(10, typecode=Float)
>     y1 = x**2
>     d = Gnuplot.Data(x, y1,
>                      title='calculated by python',
>                      with='points 3 3')
Ahh, now this is clear.  I just was 'grep'ing for PlotItem and did not
found this keyword.  The reason is that I'm quite a Python beginner, sorry.

> You would do something like the following (untested):
>
> g.plot(
>     Gnuplot.Data(X, title='This is the X dataset', with='linespoints'),
>     Gnuplot.Data(Y, title='Some more data', with='points 2 5'),
>     )
I've got the point now.

Thanks for this fine software!

> Please subscribe.  The list has an archive but since the list is very
> new there are only a few messages in it.
I'll do so for my next question ;-).  The amount of lists I'm subscribed
is quite high but if this is a low volume list I can cope with this.

Kind regards

        Andreas.

Andreas Tille writes:
> Unfortunately I have real trouble using PlotItem.

For just setting tables and line types and stuff you don't have to
extend the PlotItem interface directly; you can use the Data class
which is a type of PlotItem already customized for array data.

There are many examples in demo.py about how to use the Data class.
For example,

    x = arange(10, typecode=Float)
    y1 = x**2
    d = Gnuplot.Data(x, y1,
                     title='calculated by python',
                     with='points 3 3')

So for your example,

> #!/usr/bin/python
> 
> import Gnuplot, Gnuplot.funcutils
> 
> X = []
> Y = []
> for x in range(32):
>    X.append((x, 2*x ))
>    Y.append((x, 3*x ))
> 
> g = Gnuplot.Gnuplot(debug=1)
> 
> g.plot(X, Y)
> raw_input('Please press return to continue...\n')

You would do something like the following (untested):

g.plot(
    Gnuplot.Data(X, title='This is the X dataset', with='linespoints'),
    Gnuplot.Data(Y, title='Some more data', with='points 2 5'),
    )

> PS: I'm not yet subscribed to this list and would be happy about a CC
>     because a list archive does not seem to be available.

Please subscribe.  The list has an archive but since the list is very
new there are only a few messages in it.

Michael

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

Marc French writes:
> After renaming the folder to 'Gnuplot', I am able to import it, but
> when running demo,test, or using the command line I am not able to
> get Gnuplot to open and show a simple plot.

Can you run gnuplot (the graphics program itself) from your command
line by typing pgnuplot.exe?  You need a version of the program that
can read commands from stdin, which usually has this name.  If it is
not in your PATH, then add it.  If it has a different name, then
change the GnuplotOpts.gnuplot_command setting in gp_win32.py.

Michael

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

Hello,

I just tried Gnuplot-py and regard it very valu to solce a certain job.

Unfortunately I have real trouble using PlotItem.  The documentation says:

   For the finest control over the output, you can create PlotItems
   yourself with additional keyword options, or derive new classes
   from PlotItem.

But as a Python beginner I seem to have trouble to understand the
syntax.  I started with a fairly simple example:


#!/usr/bin/python

import Gnuplot, Gnuplot.funcutils

X = []
Y = []
for x in range(32):
   X.append((x, 2*x ))
   Y.append((x, 3*x ))

g = Gnuplot.Gnuplot(debug=1)

g.plot(X, Y)
raw_input('Please press return to continue...\n')


Now I wanted to use PlotItem objects for X and Y to get finer control about
titles and style because the quite simple 2*x and 3*x will be replaced by
some more sophisticated database queries and further plots will be added.

But I do really not understand how to instantiate PlotItems and there
is no example available.

Could you please provide some simple examples?

Thanks for this fine software

          Andreas.

PS: I'm not yet subscribed to this list and would be happy about a CC
    because a list archive does not seem to be available.

Marc French writes:
> Mike,
> This is the error I am getting when importing Gnuplot.py
> 
> >>>import Gnuplot
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ImportError: No module named Gnuplot
> 
> > > >Marc French writes:
> > > > > Hello Michael,
> > > > > I am having trouble getting the gnuplot.py to work in a windows
> > > > > environment.  I am very new to python, and I think I am missing
> > > > > something very small. I have installed the gnuplot.py. It created a=
> >
> > > > > directory "C:\python22\lib\site-packages\Gnuplot-1.5" I have tried
> > > > > running both the demo.py and the test.py. I am trying to load some
> > > > > spectral data and do peak fitting once I get this to work. Do you
> > > > > have any pointers for me? Can you help?

Oh, there's one strange thing.  The directory that Gnuplot.py created
was C:\python22\lib\site-packages\Gnuplot-1.5, when normally it should
be something like C:\python22\lib\site-packages\Gnuplot.  Can you
check if you have that directory too, and if not rename the directory
you have with that name?

Also try starting python then typing

>>> import sys
>>> print sys.path

and check whether the directory *containing* the Gnuplot directory (in
your case probably C:\python22\lib\site-packages) is included in the
path.

Michael

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

Hi Marc

> >>>import Gnuplot
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ImportError: No module named Gnuplot

Two things: may be you have two versions of python installed ?
You may need to run python2 explicitly

Also: what exactly did you type to install Gnuplot ?

-- Leo

Mike,
This is the error I am getting when importing Gnuplot.py

>>>import Gnuplot
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
ImportError: No module named Gnuplot

I hope this helps with the problem.
Marc


>From: Michael Haggerty <hag...@jp...>
>Reply-To: hag...@jp...
>To: gnu...@li...
>CC: "Marc French" <mcf...@ho...>
>Subject: Re: Gnuplot.py question
>Date: Tue, 13 Aug 2002 15:39:21 +0200 (CEST)
>
>Hi,
>
>I can only guess because I don't know how your system is set up and
>you still haven't described what isn't working, what error messages
>you get, etc.
>
>It sounds like Gnuplot.py installed itself in an appropriate directory
>for you, so you shouldn't have to do anything with your PYTHONPATH or
>run things from a specific directory.
>
>Try running python from the command line and type "import Gnuplot".
>If this works, then Gnuplot.py is installed correctly.
>
>Then type "g =3D Gnuplot.Gnuplot()".  If this works, then gnuplot (the
>plotting program) is also installed correctly.
>
>If those two things work, then the demo should also work.
>
>If something doesn't work, please tell us what error message you got!
>Otherwise it is almost impossible to help you.
>
>By the way, I forwarded your email to the new gnuplot-py-users mailing
>list.  It would be good if users would subscribe to the list and use
>it for discussions.
>
>Yours,
>Michael
>
>Marc French writes:
> > Hello Michael,
> > Does the gnuplot.py need to be in a specific directory?
> > Or can the path be set before importing?
> > I am sorry these are probably very trivial questions, but
> > I am a Visual Basic programmer. I want to use python for
> > lab automation.
> > Thanks for your help.
> > Marc
> > =
>
> > =
>
> > >From: Michael Haggerty <hag...@jp...>
> > >Reply-To: hag...@jp...
> > >To: "Marc French" <mcf...@ho...>
> > >Subject: Re: Gnuplot.py question
> > >Date: Tue, 6 Aug 2002 11:22:58 +0200 (CEST)
> > >
> > >Marc French writes:
> > > > Hello Michael,
> > > > I am having trouble getting the gnuplot.py to work in a windows
> > > > environment.  I am very new to python, and I think I am missing
> > > > something very small. I have installed the gnuplot.py. It created a=
>
> > > > directory "C:\python22\lib\site-packages\Gnuplot-1.5" I have tried
> > > > running both the demo.py and the test.py. I am trying to load some
> > > > spectral data and do peak fitting once I get this to work. Do you
> > > > have any pointers for me? Can you help?
> > >
> > >It would help if you would give me some information about how it
> > >fails.  Do you get an error message?  Can you run it from the msdos
> > >command line?  I don't use windows but your probably have to type
> > >something like
> > >
> > >     C:\> python.exe demo.py
> > >
> > >Michael
> > >
> > >--
> > >Michael Haggerty
> > >hag...@jp...
> > =
>
> > =
>
> > =
>
> > =
>
> > _________________________________________________________________
> > Join the world=92s largest e-mail service with MSN Hotmail. =
>
> > http://www.hotmail.com
>
>
>--
>Michael Haggerty
>hag...@jp...




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Hi,

I can only guess because I don't know how your system is set up and
you still haven't described what isn't working, what error messages
you get, etc.

It sounds like Gnuplot.py installed itself in an appropriate directory
for you, so you shouldn't have to do anything with your PYTHONPATH or
run things from a specific directory.

Try running python from the command line and type "import Gnuplot".
If this works, then Gnuplot.py is installed correctly.

Then type "g =3D Gnuplot.Gnuplot()".  If this works, then gnuplot (the
plotting program) is also installed correctly.

If those two things work, then the demo should also work.

If something doesn't work, please tell us what error message you got!
Otherwise it is almost impossible to help you.

By the way, I forwarded your email to the new gnuplot-py-users mailing
list.  It would be good if users would subscribe to the list and use
it for discussions.

Yours,
Michael

Marc French writes:
> Hello Michael,
> Does the gnuplot.py need to be in a specific directory?
> Or can the path be set before importing?
> I am sorry these are probably very trivial questions, but
> I am a Visual Basic programmer. I want to use python for
> lab automation.
> Thanks for your help.
> Marc
> =

> =

> >From: Michael Haggerty <hag...@jp...>
> >Reply-To: hag...@jp...
> >To: "Marc French" <mcf...@ho...>
> >Subject: Re: Gnuplot.py question
> >Date: Tue, 6 Aug 2002 11:22:58 +0200 (CEST)
> >
> >Marc French writes:
> > > Hello Michael,
> > > I am having trouble getting the gnuplot.py to work in a windows
> > > environment.  I am very new to python, and I think I am missing
> > > something very small. I have installed the gnuplot.py. It created a=

> > > directory "C:\python22\lib\site-packages\Gnuplot-1.5" I have tried
> > > running both the demo.py and the test.py. I am trying to load some
> > > spectral data and do peak fitting once I get this to work. Do you
> > > have any pointers for me? Can you help?
> >
> >It would help if you would give me some information about how it
> >fails.  Do you get an error message?  Can you run it from the msdos
> >command line?  I don't use windows but your probably have to type
> >something like
> >
> >     C:\> python.exe demo.py
> >
> >Michael
> >
> >--
> >Michael Haggerty
> >hag...@jp...
> =

> =

> =

> =

> _________________________________________________________________
> Join the world=92s largest e-mail service with MSN Hotmail. =

> http://www.hotmail.com


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

Hi Michael

> > There is a preview at 
> > http://www.sci.muni.cz/~mikulik/gnuplot.html#pm3d
> 
> Yes, this looks very cool.
> 
> > Are you planning to add support for it ?.
> 
> I am busy at work right now and don't have a lot of time to put into
> Gnuplot.py.  But it looks like pm3d mostly works through the old splot
> interface by just setting a couple of extra options, so the data
> handling that is already in Gnuplot.py might be adequate.  (The extra
> settings can, as always, be accessed using the Gnuplot __call__
> method.)

Yes, sure, that's why I like Gnuplot.py, for the flexibility you
get. 
 
> What changes do you think would be needed in Gnuplot.py to support
> pm3d better?

I'll tell you what, I'll start using pm3d whenever I need it for
research or have some spare time and let you know if I find a
useful way to include it explicitly in Gnuplot.py and make it
easier to be accessed by the user ...

Thanks a lot,
-- Leo

Leonardo Milano writes:
> One thing I have been thinking is that it may be a good idea to add
> support for pm3d (a new mode added in the development branch (future
> 3.8 release) of gnuplot.
> 
> It is pretty cool, it adds the remaining (IMHO) fundamental feature
> for scientific plotting: intentisy surfaces and maps.
> 
> There is a preview at 
> http://www.sci.muni.cz/~mikulik/gnuplot.html#pm3d

Yes, this looks very cool.

> Are you planning to add support for it ?.

I am busy at work right now and don't have a lot of time to put into
Gnuplot.py.  But it looks like pm3d mostly works through the old splot
interface by just setting a couple of extra options, so the data
handling that is already in Gnuplot.py might be adequate.  (The extra
settings can, as always, be accessed using the Gnuplot __call__
method.)

What changes do you think would be needed in Gnuplot.py to support
pm3d better?

Michael

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

Hi Again Michael

Thank you for opening the list :-)

One thing I have been thinking is that it may be 
a good idea to add support for pm3d (a new mode
added in the development branch (future 3.8 release)
of gnuplot. 

It is pretty cool, it adds the remaining (IMHO) fundamental
feature for scientific plotting: intentisy surfaces and 
maps. 

There is a preview at 
http://www.sci.muni.cz/~mikulik/gnuplot.html#pm3d

Are you planning to add support for it ?. 

Thanks a lot,
-- leo