From: Michael H. <hag...@jp...> - 2002-09-16 17:44:52
|
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... |