1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
# $Id: FAQ.txt 294 2006-11-07 02:33:08Z parejkoj $
Frequently Asked Questions
This file is meant to answer the most frequently asked questions about
the Gnuplot.py package. If you want to suggest additional questions
(with or without answers!) please mail them to the Gnuplot.py users
mailing list, <gnuplot-py-users@lists.sourceforge.net>.
======================================================================
Q1:
When running the following script
------------------------------------------------
#! /usr/bin/python
import Gnuplot, Gnuplot.funcutils
from numpy import *
g = Gnuplot.Gnuplot()
g.plot([[0,1.1], [1,5.8], [2,3.3], [3,4.2]])
------------------------------------------------
I get the error
gnuplot> plot '/tmp/@24463.2'
^
can't read data file "/tmp/@24463.2"
line 0: (No such file or directory)
However, the same commands work fine if I type them into the
interpreter! What's wrong?
A1:
The problem is that in many cases Gnuplot.py sends data to gnuplot via
a temporary file. But Gnuplot.py has no way of knowing when it is
safe to delete the temporary file. So it deletes it when the
corresponding PlotItem object is deleted, which is typically when the
next Gnuplot.plot() command is executed or when the python script
ends. (Until you plot something else, the Gnuplot object keeps a
reference to all of the old plot items to prevent their being garbage
collected.)
To prevent this problem, there are several possibilities:
1. Switch to Unix. On that platform, Gnuplot.py now uses FIFOs (named
pipes) by default to send data to gnuplot. This seems to provide a
robust and somewhat elegant solution to this problem.
2. Use "inline data" instead of temporary files to communicate with
gnuplot. This is already available in gnuplot for most 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.
Since inline data doesn't involve temporary files, the problem goes
away.
3. 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
if you are producing a graphics file you might watch for the
creation of the output file and at that point assume that gnuplot
is done with the temporary file. One idea is to explicitly create
a PlotItem to represent the data, and keep a reference to the
PlotItem for some time after the plot() command is executed; e.g.,
data = Gnuplot.Data([[0,1.1], [1,5.8], [2,3.3], [3,4.2]])
g.plot(data)
# ... do something guaranteed to last a couple seconds
del data # temporary file is deleted at this moment
4. Change Gnuplot.py itself 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 a lot of work but it would allow other new features such as
detecting gnuplot errors, reading gnuplot fit command output back
to python, etc.
======================================================================
Q2:
Does Gnuplot.py work under Jython/Java?
A2:
Partly. Version 1.7 added the low-level interface gp_java.py for
communicating with gnuplot using the Java libraries, and that part
seems to work.
However, Gnuplot.py relies on the Python Numeric library, which is a C
library. The Jython equivalent, called JNumeric
<http://jnumerical.sourceforge.net/>, therefore has to be installed.
However, JNumeric is still at beta level, and operation under Jython
hasn't been tested much at all, so feedback is welcome!
======================================================================
Q3:
[from Tate Wilson]
I am trying to set up your gnuplot/python package on my mac (osX).
The readme file says I need to convert the files to mac text files.
The coverter I usually use, maclink, won't handle these files. Can
you give me a hint how to convert the files or where to look for help?
A3:
I don't know. But the same user later reported what worked for him:
I did have to convert the files. It may not be true for all mac
Python users, but I suspect it is. I'm using a graphical Python
development environment called "Python IDE for mac" which may have its
own pickiness, but still, it wouldn't even recognize the files in your
package as being the type it could open. I tried a few different file
converters with no luck. Then I just opened all the files with
BBedit, changed something so I would be prompted to save it on closing
(like add and remove a letter), and closed BBedit. Then all the files
were 'mac' files and the Python interpreter recognised them.
======================================================================
Q4:
I am using Windows and I get an error like
> Traceback (most recent call last):
> [...]
> File "C:\Python23\Lib\site-packages\Gnuplot\gp_win32.py",
> line 125, in __call__
> self.write(s + '\n')
> IOError: [Errno 22] Invalid argument
What is the problem?
A4:
This is apparently the error that results when Gnuplot.py cannot start
the pgnuplot.exe executable under Windows. It could be that gnuplot
(the plotting program, as opposed to Gnuplot.py) is not installed, or
that it is not in your PATH. If your pgnuplot.exe executable is named
differently, or you do not want to add its directory to your PATH, you
can change gnuplot_command in gp_win32.py to indicate the precise path
to the executable.
|