gnuplot-py-users Mailing List for Gnuplot.py

Nate Gelbard wrote:
> As usual, after asking the question, I find an answer.
> 
> Editing /usr/local/lib/python2.2/site-packages/Gnuplot/gp_unix.py
> and changing default_term = 'x11' to 'xlib' solved this problem.
> 
> Should that be the default?

NO!

For 99+% of Unix users, X11 is the most reasonable default to have.  Having a 
Unix Gnuplot with only xlib compiled in is a most unusual setup.  It's fine if 
you need it, but making it the default would flood this list with 'Gnuplot.py 
is broken for Unix' messages :)

Cheers,

f

As usual, after asking the question, I find an answer.

Editing /usr/local/lib/python2.2/site-packages/Gnuplot/gp_unix.py
and changing default_term =3D 'x11' to 'xlib' solved this problem.

Should that be the default?

-----Original Message-----
From: Nate Gelbard=20
Sent: Tuesday, October 28, 2003 4:56 PM
To: gnu...@li...
Subject: [Gnuplot-py-users] set terminal x11


Hello,

I'm back on the graphing wagon, again.
RedHat 7.3, python 2.2.3, gnuplot-3.7.3, gnuplot-py 1.7.

g =3D Gnuplot.Gnuplot(debug=3D1)
g('set data style lines')
g('set terminal png color')
g('set output \"%s\"' % outfile)
g.title("Time vs Memory")
g.xlabel("Time \(5min interval\)")
g.ylabel("KBytes")

[gelbardn@webster agent]$ ./Graph.py=20
gnuplot> set terminal x11
gnuplot> set data style lines
gnuplot> set terminal png color
gnuplot> set output "test.png"
gnuplot> set title "Time vs Memory"
gnuplot> set xlabel "Time \(5min interval\)"
gnuplot> set ylabel "KBytes"

gnuplot-py is calling 'set terminal x11' which is failing.
I think it should be calling 'set terminal xlib'

Did I setup gnuplot 3.7.3 incorrectly or should gnuplot-py be calling it
with xlib instead of x11?

I only configured gnuplot --with-png.

[gelbardn@webster agent]$ ./Graph.py=20
gnuplot> set terminal x11
gnuplot> set data style lines
gnuplot> set terminal png color
gnuplot> set output "test.png"
gnuplot> set title "Time vs Memory"
gnuplot> set xlabel "Time \(5min interval\)"
gnuplot> set ylabel "KBytes"

gnuplot> set terminal x11
                      ^
         line 0: unknown or ambiguous terminal type; type just 'set
terminal' for a list

Thanks,
--( Nate Gelbard, QA Engineer    =20
--( Tripwire, Inc., The Integrity Assurance Company


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Gnuplot-py-users mailing list Gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-py-users

Hello,

I'm back on the graphing wagon, again.
RedHat 7.3, python 2.2.3, gnuplot-3.7.3, gnuplot-py 1.7.

g =3D Gnuplot.Gnuplot(debug=3D1)
g('set data style lines')
g('set terminal png color')
g('set output \"%s\"' % outfile)
g.title("Time vs Memory")
g.xlabel("Time \(5min interval\)")
g.ylabel("KBytes")

[gelbardn@webster agent]$ ./Graph.py=20
gnuplot> set terminal x11
gnuplot> set data style lines
gnuplot> set terminal png color
gnuplot> set output "test.png"
gnuplot> set title "Time vs Memory"
gnuplot> set xlabel "Time \(5min interval\)"
gnuplot> set ylabel "KBytes"

gnuplot-py is calling 'set terminal x11' which is failing.
I think it should be calling 'set terminal xlib'

Did I setup gnuplot 3.7.3 incorrectly or should gnuplot-py be calling
it with xlib instead of x11?

I only configured gnuplot --with-png.

[gelbardn@webster agent]$ ./Graph.py=20
gnuplot> set terminal x11
gnuplot> set data style lines
gnuplot> set terminal png color
gnuplot> set output "test.png"
gnuplot> set title "Time vs Memory"
gnuplot> set xlabel "Time \(5min interval\)"
gnuplot> set ylabel "KBytes"

gnuplot> set terminal x11
                      ^
         line 0: unknown or ambiguous terminal type; type just 'set
terminal' for a list

Thanks,
--( Nate Gelbard, QA Engineer    =20
--( Tripwire, Inc., The Integrity Assurance Company

Michael,

> The problem reported below seems to be pretty common among Windows 
> users.  I believe it is caused by Gnuplot.py not being able to find 
> the pgnuplot.exe executable because it is not in the PATH or not 
> installed.

It may be true that there is a problem in finding pgnuplot.exe, but 
there also seems to be a problem in the structure of Gnuplot.py because 
it does not seem to contain funcutils.

Here is the part of my original message the shows this problem:

> >>> import demo
> Traceback (most recent call last):
>  File "<interactive input>", line 1, in ?
>  File "C:\Python23\Lib\site-packages\Gnuplot\demo.py", line 22, in ?
>    import Gnuplot, Gnuplot.funcutils
> ImportError: No module named funcutils
> >>> import Gnuplot.funcutils
> Traceback (most recent call last):
>  File "<interactive input>", line 1, in ?
> ImportError: No module named funcutils 


-Roger

Can any Windows users help?

The problem reported below seems to be pretty common among Windows 
users.  I believe it is caused by Gnuplot.py not being able to find the 
pgnuplot.exe executable because it is not in the PATH or not installed. 
 Are there any Windows users of Gnuplot.py who can come up with a way to 
diagnose the problem within the Gnuplot.py package so that users are not 
confronted with such a strange error message?  It might help people 
recognize and fix the problem on their own.

For example, is there a way to tell if a call to popen() fails under 
Windows?  Ideally, it should work for the old python versions, too, 
where win32pipe.popen() as well as the new versions where os.popen() is 
used.  But even a partial solution would be an improvement.

Ideally, there would be a test in the gp_win32.GnuplotProcess 
constructor which generated a more descriptive exception in the case of 
errors.

Otherwise, I guess I have to add a FAQ.txt question about this issue.

Thanks,
Michael

Roger Frye wrote:

> I can't get started with version 1.7 on Windows XP Professional
> I am using the following packages:
>  Python-2.3.2-1.exe
>  win32all-157.exe
>  Numeric-23.1.win32-py2.3.exe
>  gp373w32.zip
>  gnuplot-py-1.7.zip
>
> Here is a transcript of my attempt to run the demo from the Command Line:
> ---------------------------------------------------
> >C:\Python23\python demo.py
> gnuplot> set terminal windows
> gnuplot> set title "A simple example"
> gnuplot> set data style linespoints
> gnuplot> plot 'c:\docume~1\rogerf~1\locals~1\temp\tmphzycgx' notitle
> Please press return to continue...
>
> Traceback (most recent call last):
>  File "demo.py", line 113, in ?
>    demo()
>  File "demo.py", line 39, in demo
>    g.reset()
>  File "C:\Python23\Lib\site-packages\Gnuplot\_Gnuplot.py", line 355, 
> in reset
>    self('reset')
>  File "C:\Python23\Lib\site-packages\Gnuplot\_Gnuplot.py", line 199, 
> in __call_
> _
>    self.gnuplot(s)
>  File "C:\Python23\Lib\site-packages\Gnuplot\gp_win32.py", line 125, 
> in __call_
> _
>    self.write(s + '\n')
> IOError: [Errno 22] Invalid argument
> --------------------------------------------------



-- 
Michael Haggerty
mh...@al...

I can't get started with version 1.7 on Windows XP Professional
I am using the following packages:
  Python-2.3.2-1.exe
  win32all-157.exe
  Numeric-23.1.win32-py2.3.exe
  gp373w32.zip
  gnuplot-py-1.7.zip

Here is a transcript of my attempt to run the demo from the Command Line:
---------------------------------------------------
 >C:\Python23\python demo.py
gnuplot> set terminal windows
gnuplot> set title "A simple example"
gnuplot> set data style linespoints
gnuplot> plot 'c:\docume~1\rogerf~1\locals~1\temp\tmphzycgx' notitle
Please press return to continue...

Traceback (most recent call last):
  File "demo.py", line 113, in ?
    demo()
  File "demo.py", line 39, in demo
    g.reset()
  File "C:\Python23\Lib\site-packages\Gnuplot\_Gnuplot.py", line 355, in 
reset
    self('reset')
  File "C:\Python23\Lib\site-packages\Gnuplot\_Gnuplot.py", line 199, in 
__call_
_
    self.gnuplot(s)
  File "C:\Python23\Lib\site-packages\Gnuplot\gp_win32.py", line 125, in 
__call_
_
    self.write(s + '\n')
IOError: [Errno 22] Invalid argument
--------------------------------------------------

Here is a transcript of my attempt to run the demo from PythonWin
-----------------------------------------------------
PythonWin 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] 
on win32.
Portions Copyright 1994-2001 Mark Hammond (mha...@sk...) - 
see 'Help/About PythonWin' for further copyright information.
 >>> import Gnuplot
 >>> dir(Gnuplot)
['Data', 'DataError', 'Error', 'Errors', 'File', 'Func', 'Gnuplot', 
'GnuplotOpts', 'GnuplotProcess', 'GridData', 'OptionError', 'PlotItem', 
'PlotItems', '_Gnuplot', '__all__', '__builtins__', '__cvs_version__', 
'__doc__', '__file__', '__name__', '__path__', '__version__', 'gp', 
'gp_win32', 'termdefs', 'test_persist', 'utils']
 >>> Gnuplot.GnuplotOpts.gnuplot_command
'C:\\Program Files\\gp373w32\\pgnuplot.exe'
 >>> import demo
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\Python23\Lib\site-packages\Gnuplot\demo.py", line 22, in ?
    import Gnuplot, Gnuplot.funcutils
ImportError: No module named funcutils
 >>> import Gnuplot.funcutils
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
ImportError: No module named funcutils
 >>>
-----------------------------------------------------

-Roger

Michael Haggerty wrote:

> Jim Kleckner wrote:
> 
>> I added the code below to termdefs.py to allow hardcopy
>> to work with pdf.
> 
> Thanks, I just added this to CVS.  Sorry I didn't get it into the release.


Great, thanks!


>> I also found that the temporary file was being removed before
>> the gnuplot process was done with it.  Adding a sleep() of a
>> few seconds made it work but that was kind of a kludge.
>> Adding a g.gnuplot.gnuplot.close() worked fine since it
>> causes a wait for the popen() process to exit (if not using
>> inline).  I wonder if there is some way to put this into
>> the __del__() function at a place where this would happen
>> naturally?  I tried the obvious on Gnuplot but it didn't work.
> 
> The temporary-file removal problem is discussed in FAQ.txt.  Under what 
> circumstances exactly did calling close() help?  It would probably make 
> more sense to add a close() method to the GnuplotProcess objects because 
> its implementation is likely to be platform-specific.  Then I guess 
> Gnuplot should call the close() method in its own __del__ method.  Hmmm, 
> I guess this helps by ensuring that the pipe is closed before the 
> plotitems are destroyed.
> 
> OK, I just implemented this in CVS, too.
> 
> Thanks for your note and suggestions!
> 
> Michael
> 


Yes, when I upgraded to 1.7 CVS I noticed that cygwin
implemented inline by default now and that is the strongest
way to guarantee that the data will be synchronized.  I ended
up switching everything over to that.

I switched back over to "not inline" and it still fails when

you reuse an existing plot process.  The race seems to be that
when you perform a new plot (without closing the process)
and the piped command hasn't finished processing the last file,
it can get deleted by the next rapid fire g.plot() request that
replaces the plot items.  A total hack could be to keep an
invisible list of plot items not in the queue that gets set to
None at close time resulting in file deletion.  Quite a hack.
Proabably better to tell people to just use inline or create
a new plot object for each plot.


Thanks!
Jim

Hi,

Thanks for your suggestion and patch for generating an RPM for 
Gnuplot.py.  I included RPMs with the last release, and I realize that 
distutils makes it quite easy.  But:

1.  For what Python version should I provide RPMs?  The RPM is dependent 
on the Python version because that determines where the files are 
installed (/usr/lib/python1.5, /usr/lib/python2.2, etc).  I am not 
psyched about having to create RPMs for multiple Python versions, partly 
because I don't have all the versions installed myself.

2. Creating an RPM for Python 2.2 under RedHat is not entirely trivial, 
because under RedHat the Python 2.2 executable is called "python2", but 
distutils calls "python" for one of its internal processing steps. 
 (Obviously it wouldn't be too hard to work around this problem.)

3. Since there are no standard RPMs for Numeric (that I know of), it is 
not clear how to specify that dependency.  For example, since I have 
installed Numeric from source, I think that your suggested "requires = 
_numpy.so" wouldn't work on my system.

4. It is really easy for somebody to download the source tar file and 
create an RPM himself, then install the RPM.  This gives the benefit of 
RPM (e.g., being able to remove the package later) without some of the 
problems.  (I documented this procedure in README.txt.)

These arguments, and a tiny bit of laziness, led me to skip building RPMs.

How would you answer these questions (particularly the first one)?

Michael

Leonardo Milano wrote:

>Does it make sense to provide RPMS in the sourceforge page? 
>The distutils allow for almost automatic rpm building.
>  
>
-- 
Michael Haggerty
mh...@al...

Jim Kleckner wrote:

> I added the code below to termdefs.py to allow hardcopy
> to work with pdf.


Thanks, I just added this to CVS.  Sorry I didn't get it into the release.

> I also found that the temporary file was being removed before
> the gnuplot process was done with it.  Adding a sleep() of a
> few seconds made it work but that was kind of a kludge.
> Adding a g.gnuplot.gnuplot.close() worked fine since it
> causes a wait for the popen() process to exit (if not using
> inline).  I wonder if there is some way to put this into
> the __del__() function at a place where this would happen
> naturally?  I tried the obvious on Gnuplot but it didn't work.


The temporary-file removal problem is discussed in FAQ.txt.  Under what 
circumstances exactly did calling close() help?  It would probably make 
more sense to add a close() method to the GnuplotProcess objects because 
its implementation is likely to be platform-specific.  Then I guess 
Gnuplot should call the close() method in its own __del__ method.  Hmmm, 
I guess this helps by ensuring that the pipe is closed before the 
plotitems are destroyed.

OK, I just implemented this in CVS, too.

Thanks for your note and suggestions!

Michael

-- 
Michael Haggerty
mh...@al...

Hi Michael,

Does it make sense to provide RPMS in the sourceforge page? 
The distutils allow for almost automatic rpm building.

Here is a little diff:

#### patch begins
--- setup.cfg   2003-10-21 16:41:55.000000000 -0400
+++ setup.cfg.orig      2003-10-21 15:15:52.000000000 -0400
@@ -10,6 +10,4 @@
             LICENSE.txt
             Gnuplot.html
             doc/
-requires = _numpy.so, python >= 1.5
-vendor = gnuplot-py.sourceforge.net
#### patch ends

Just to add the dependency with python, numPy and to add a vendor.
Then you can run:
    python setup.py bdist --formats=rpm
and get a src.rpm and a noarch.rpm

Hope this helps,
-- Leo

> At long last, I have just released version 1.7 of Gnuplot.py.  You can 
> get it at SourceForge,
> 
>     http://gnuplot-py.sourceforge.net/

Congrats Michael, thanks a lot for taking the time !

Cheers,
-- leo

On Mon, 20 Oct 2003, Michael Haggerty wrote:

> Hi Everybody,
> 
> At long last, I have just released version 1.7 of Gnuplot.py.  You can 
> get it at SourceForge,
> 
>     http://gnuplot-py.sourceforge.net/

Hi Everybody,

At long last, I have just released version 1.7 of Gnuplot.py.  You can 
get it at SourceForge,

    http://gnuplot-py.sourceforge.net/

This version doesn't contain any significant changes to what's been in 
CVS for quite a while; it's just that I finally made some time to 
package it up and release it :-|

I apologize for the things that didn't make it into the release.  If I 
had waited until everything was done, this release would have never 
gotten done.

Thanks everybody for your suggestions, feedback, and patches.

Highlights in this version:

  + Relaxed license from GPL to LGPL.

  + Added support for sending data to gnuplot via FIFOs (named pipes).
    This eliminates the ambiguity about when temporary files can be
    deleted, and thereby removes a common source of problems with
    Gnuplot.py.  Unfortunately, FIFOs only work under forms of unix.

  + Added preliminary support for running Gnuplot.py under Jython, the
    Java implementation of the Python language.  It partly works but
    depends on JNumeric, which is still beta-level.

  + Changed handling of 1-D arrays in the Data() function.  Now 1-D
    arrays are plotted as N points against the index number, rather than
    as 1 point with N coordinates.

Yours,
Michael

-- 
Michael Haggerty
mh...@al...

I added the code below to termdefs.py to allow hardcopy
to work with pdf.  However, I found that to get printout
without an interactive session, I was better off just sending
the appropriate commands to gnuplot and going around hardcopy.
Note that I am using cygwin but with a compiled version of
gnuplot for X11.

I also found that the temporary file was being removed before
the gnuplot process was done with it.  Adding a sleep() of a
few seconds made it work but that was kind of a kludge.
Adding a g.gnuplot.gnuplot.close() worked fine since it
causes a wait for the popen() process to exit (if not using
inline).  I wonder if there is some way to put this into
the __del__() function at a place where this would happen
naturally?  I tried the obvious on Gnuplot but it didn't work.

Jim

This is vs. the CVS archive:

Index: termdefs.py
===================================================================
RCS file: /cvsroot/gnuplot-py/gnuplot-py/termdefs.py,v
retrieving revision 2.4
diff -u -r2.4 termdefs.py
--- termdefs.py    21 Apr 2003 09:44:09 -0000    2.4
+++ termdefs.py    17 Oct 2003 20:25:40 -0000
@@ -386,6 +386,21 @@
      BareStringArg(argname='fontsize'),
      ]

+terminal_opts['pdf'] = [
+    KeywordOrBooleanArg(
+        options=['landscape', 'portrait', 'eps', 'default'],
+        argname='mode',
+        ),
+    KeywordOrBooleanArg(options=['color', 'monochrome']),
+    KeywordOrBooleanArg(options=['solid', 'dashed']),
+    KeywordOrBooleanArg(
+        options=['defaultplex', 'simplex', 'duplex'],
+        argname='duplexing',
+        ),
+    StringArg(argname='fontname'),
+    BareStringArg(argname='fontsize'),
+    ]
+
  terminal_opts['png'] = [
      KeywordOrBooleanArg(
          options=['small', 'medium', 'large'],

Hi all,

today I got a report from an ipython user who saw some breakage of IPython's 
gnuplot support.  He thought he was using Gnuplot.py 1.6, but it turned out he 
had a CVS-updated copy.  I have a few questions:

- Is the __version__ in CVS still 1.6?  If so, could it be tagged to reflect 
that this is not 'stock' 1.6 anymore?  It would help in pinning down these 
problems, since I know that IPython lives happily with Gnuplot.py 1.5 and 1.6.

- The reported problem generated the following traceback:

/home/python/PYTHON/lib/python2.3/site-packages/IPython/Gnuplot2.py
      43
      44 # Fix the File class to add the 'index' option
---> 45 class File(Gnuplot_ori.File):
      46
      47     _option_list = Gnuplot_ori.File._option_list.copy()

/home/python/PYTHON/lib/python2.3/site-packages/IPython/Gnuplot2.py in
File()
      45 class File(Gnuplot_ori.File):
      46
---> 47     _option_list = Gnuplot_ori.File._option_list.copy()
      48     _option_list.update({
      49         'index' : lambda self, index:
self.set_option_index(index),

AttributeError: 'function' object has no attribute '_option_list'


Is this change fundamental, or merely accidental?  If it is at all reasonable, 
I was wondering if the current evolution of Gnuplot.py could maintain 
backwards compatibility for the sake of users who have old code (such as 
IPython, in fairly wide deployment already through debian, gentoo & Fink).  I 
can always update ipython for a new release to protect against this, but that 
won't help much existing users if they update their Gnuplot.py and their 
existing code breaks (which is already happening).

I understand perfectly that sometimes, backwards compatibility just has to be 
broken in order to advance with a proper design.  If that is the case here, 
would it be possible to label the new Gnuplot.py version 2.0 or something like 
that?  This would be a strong indicator of 'significant changes', and I could 
either that ipython only works with versions 1.x.  Perhaps (since I know many 
of the new changes supercede my ipython hacks), I can even make my 
ipython-gnuplot layer be much thinner in the presence of 2.0.

Thanks in advance for any feedback.

Regards,

Fernando.