Andreas Tille writes:
> On Tue, 10 Sep 2002, Michael Haggerty wrote:
>
> > What about having gnuplot write the output to a temporary file and
> > then read the file? If you are under Unix, you could even have
> > gnuplot write the output to a fifo (named pipe) and read it directly
> > into your program.
> I fiddled around something with mkfifo but failed to read it correctly.
> Seems there is some magic to do with threads or someting else because
> reading from the pipe fails completely.
Yes, you would probably have to read from the fifo in another python
thread.
> > I don't think there is a way to get at the string any other way. One
> > could change Gnuplot.py to read gnuplot's standard output, but I'm not
> > sure that output would only have the pure graphics. If you want to
> > pursue this, you would probably want to do it by providing your own
> > substitute GnuplotProcess object.
> Any hint how to do that?
Yes, instead of starting gnuplot with the os.popen() command, you
would start it with os.popen2(). This returns the file objects
(child_stdin, child_stdout). You would write the gnuplot commands to
child_stdin, and you would read the child's results from child_stdout.
Presumably child.stdout would have to be read from a different python
thread to prevent deadlocks. You would probably have to experiment to
check what other output gnuplot writes to its standard output, and
when and if it flushes the output. You might have to limit yourself
to plotting a single graph per gnuplot process to prevent subsequent
graphs from running together.
Note that os.popen2() is only available as of Python 2.0. For
previous Python versions you would have to use the popen2 module. I'm
not sure whether these modules are available for other OSes.
If you implement this and find it to be useful, submit a patch and
I'll add it to the Gnuplot.py source.
Michael
--
Michael Haggerty
hag...@jp...
|
