1. Is it possible to exit a Python program but still have the graph
window generated by pylot remain visible? Right now the program stops
when I display the (only) final graph. When I close this window, the
program exits. I would like to finish the program, but have the graph
stay visible if that's possible (I suppose I could save a graphics
file and then display it - but that's a bit different)
2. Is it possible to update graphs somewhat efficiently during the
runtime of the program? Say I have a loop that generates value to
be plotted. Right now I collect them and plot them at the end, ie
values = []
for i in range(0, 200):
values.append(i)
various pyplot commands to plot the values list.
I wonder if I could have the graph update during each iteration instead
giving me an up-to-date view of the data. (The above is a super simplified
example of course)
You’d have to run the plotting in a separate process from the computation. subprocess would let you do that, assuming you can spin off a child task that stays alive when the parent exits. You’d also need to get the computing process to give new results to the child plot, maybe using a pipe (which I think subprocess can handle as well.)
Ryan
···
On Thu, Apr 23, 2009 at 4:16 PM, Esmail <ebonak@…32…> wrote:
Thanks Ryan, that'll give me some idea with regard to the animation,
and real-time drawings.
Any idea if it's possible to finish a Python program but still have the
graph showing?
FWIW, I'm doing this under Linux.
You'd have to run the plotting in a separate process from the computation.
subprocess would let you do that, assuming you can spin off a child task
that stays alive when the parent exits. You'd also need to get the
computing process to give new results to the child plot, maybe using a pipe
(which I think subprocess can handle as well.)
This is exactly what I have tried/described in [1], using the multiprocessing module. It sort of works, but I have that hanging problem at the end - maybe somebody jumps in and helps this time
Any idea if it's possible to finish a Python program but still have the
graph showing?
FWIW, I'm doing this under Linux.
You'd have to run the plotting in a separate process from the computation. subprocess would let you do that, assuming you can spin off a child task that stays alive when the parent exits. You'd also need to get the computing process to give new results to the child plot, maybe using a pipe (which I think subprocess can handle as well.)
Thanks Ryan, I have been meaning to explore Python's
threading/multi-processing facilities, so this will provide a
good excuse to do so [when I find the time... so much to learn,
so little time]
This is exactly what I have tried/described in [1], using the multiprocessing module. It sort of works, but I have that hanging problem at the end - maybe somebody jumps in and helps this time
This is exactly what I have tried/described in [1], using the multiprocessing module. It sort of works, but I have that hanging problem at the end - maybe somebody jumps in and helps this time
I was curious, so I cooked up a quick demo using two scripts. Put them in the same directory and run datasource.py. It’s not perfect, and I think the use of raw_input() is a little odd, but it works.
On Fri, Apr 24, 2009 at 5:52 AM, Esmail <ebonak@...32...> wrote:
Ryan May wrote:
Any idea if it's possible to finish a Python program but still have
the
graph showing?
FWIW, I'm doing this under Linux.
You'd have to run the plotting in a separate process from the
computation. subprocess would let you do that, assuming you can spin
off a child task that stays alive when the parent exits. You'd also
need to get the computing process to give new results to the child plot,
maybe using a pipe (which I think subprocess can handle as well.)
Thanks Ryan, I have been meaning to explore Python's
threading/multi-processing facilities, so this will provide a
good excuse to do so [when I find the time... so much to learn,
so little time]
I was curious, so I cooked up a quick demo using two scripts. Put them in
the same directory and run datasource.py. It's not perfect, and I think the
use of raw_input() is a little odd, but it works.
Nice! I will try using the subprocess module instead of multiprocessing, as your example works for me.
I was curious, so I cooked up a quick demo using two scripts. Put them in the same directory and run datasource.py. It's not perfect, and I think the use of raw_input() is a little odd, but it works.
Very cool Ryan, thanks for doing that, I plan on studying your code
this weekend.
Thanks Ryan, that'll give me some idea with regard to the animation,
and real-time drawings.
Any idea if it's possible to finish a Python program but still have the
graph showing?
FWIW, I'm doing this under Linux.
You'd have to run the plotting in a separate process from the computation.
subprocess would let you do that, assuming you can spin off a child task
that stays alive when the parent exits. You'd also need to get the
computing process to give new results to the child plot, maybe using a pipe
(which I think subprocess can handle as well.)
This is exactly what I have tried/described in [1], using the multiprocessing module. It sort of works, but I have that hanging problem at the end - maybe somebody jumps in and helps this time
Just for the record: Ryan May's example in this thread, that uses pipes, inspired me to try pipes as well, instead of queues (multiprocessing.Pipe instead of Queue) and the "hanging problem", i.e. the problem that Ctrl-C interrupted the program, but it had to be killed to stop, disappeared. I can fix the script that I sent in message [1] and provide it, if there is interest. (Currently I have fixed only the version that is within sfepy).
thanks!
r.
[1] [Matplotlib-users] plotting in a separate process, 31.03.2009
···
On Thu, Apr 23, 2009 at 4:16 PM, Esmail <ebonak@...32...> wrote:
On Wed, May 6, 2009 at 7:57 AM, Robert Cimrman <cimrman3@...1098...> wrote:
Just for the record: Ryan May's example in this thread, that uses pipes,
inspired me to try pipes as well, instead of queues
(multiprocessing.Pipe instead of Queue) and the "hanging problem", i.e.
the problem that Ctrl-C interrupted the program, but it had to be killed
to stop, disappeared. I can fix the script that I sent in message [1]
and provide it, if there is interest. (Currently I have fixed only the
version that is within sfepy).
I know I'd be interested. With your permission, it might make a nice
example as well.
Permission granted I have sent the script in response to William.
Just for the record: Ryan May's example in this thread, that uses pipes,
inspired me to try pipes as well, instead of queues
(multiprocessing.Pipe instead of Queue) and the "hanging problem", i.e.
the problem that Ctrl-C interrupted the program, but it had to be killed
to stop, disappeared. I can fix the script that I sent in message [1]
and provide it, if there is interest. (Currently I have fixed only the
version that is within sfepy).
I know I'd be interested. With your permission, it might make a nice
example as well.
Permission granted I have sent the script in response to William.
Done. I like the fact that with your example, everything is self-contained
in a single script.
Exactly, the details of starting another python process are hidden, the multiprocessing module is really nice.
You might want to add
import matplotlib
matplotlib.use('GtkAgg')
to the script, and remove "from Queue import Empty".
FYI: I am sending also a more complex example - a Log class used in sfepy, which supports multiple subplots, labels, logarithmic plots etc. The file contains some other support classes too, so that it works standalone. It is not very polished, but it serves its purpose.
In case you are not receiving the automatic svn commit messages: yesterday I took the liberty of renaming log.py to multiprocess.py, because as far as I could see the former gave no clue as to the point of the example. Feel free to change it back, or change it to something else, if you think I am mistaken or confused about this.
Eric
···
On Wed, May 6, 2009 at 8:53 AM, Robert Cimrman <cimrman3@...1098...> >> wrote:
On Wed, May 6, 2009 at 7:57 AM, Robert Cimrman <cimrman3@...1098...> >>>> wrote:
Just for the record: Ryan May's example in this thread, that uses pipes,
inspired me to try pipes as well, instead of queues
(multiprocessing.Pipe instead of Queue) and the "hanging problem", i.e.
the problem that Ctrl-C interrupted the program, but it had to be killed
to stop, disappeared. I can fix the script that I sent in message [1]
and provide it, if there is interest. (Currently I have fixed only the
version that is within sfepy).
I know I'd be interested. With your permission, it might make a nice
example as well.
Permission granted I have sent the script in response to William.
Done. I like the fact that with your example, everything is self-contained
in a single script.
Exactly, the details of starting another python process are hidden, the multiprocessing module is really nice.
You might want to add
import matplotlib
matplotlib.use('GtkAgg')
to the script, and remove "from Queue import Empty".
FYI: I am sending also a more complex example - a Log class used in sfepy, which supports multiple subplots, labels, logarithmic plots etc. The file contains some other support classes too, so that it works standalone. It is not very polished, but it serves its purpose.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
