matplotlib in interactive mode locks when run from subprocess

Almar Klein almar.klein at gmail.com
Sat Sep 20 22:12:44 CEST 2008


I think my question was not very clear. I narrowed the problem down to
a reconstructable small example, consisting of a python script (a very
simple interpreter) and three lines to execute in it:

========== start simple interpreter file ======
import os
import sys
import time

def run():
    while True:

        # read a line of text, the thread is stuck here untill a \n is
        # fed to the stream.
        time.sleep(0.1)
        line = ""
        try:
            line = sys.stdin.readline()
        except Exception, why:
            sys.stdout.wite(why.message+"\n")

        if line:
            try:
                code = compile(line,"<none>","exec")
                exec(code)
            except Exception, why:
                sys.stderr.write(why.message)
            sys.stderr.write(">>> ")

if __name__ == "__main__":
    run()

========== end of file ==============

Now I run this file (by double clicking it) and I get a prompt. The three
lines I type in are:
import matplotlib.pylab as pl
pl.ion() #interactive mode on
pl.plot([1,2,3],[4,6,5])

This produces a tk window, but it's unresponsive. The process does have 5
threads, so
matplotlib managed to create the threads, but it seems as if they're
blocked.

When I run the three lines of code in a normal python shell, I get the
proper results:
a responsive figure (I can zoom and pan) and my shell is still responsive
too.

I am in the dark why this does not work. Any thoughts anyone? I've been busy
all day
trying to get this right, with hardly any progress... :(

Almar

PS: I run windows xp, my matplotlibrc file has the backend: TkAgg,
interactive: True


2008/9/18 Almar Klein <almar.klein at gmail.com>

> Hi,
>
> In wxpython, I made an interactive shell, which creates a remote python
> subprocess
> to do the interpreting. Communication is done via a pipe. The idea is that
> the python
> session is an actual process separate from the GUI, which has some
> advantages,
> like I can have multiple such shells in my application, and I can kill them
> without
> worrying that my wx app will crash.
>
> To do this I use the wx.Process class, which allows asynchronous
> communication with
> the remote process.
>
> This all works really, I will also launch wxpython apps. So I was quite
> happy, untill I tried
> doing some plotting with matplotlib (in TkAgg backend). The problem is that
> the process
> becomes unresponsive when I plot something (No prompt is written to the
> stdout/stderr).
> (more details below)
>
> I don't know much about creating subprocess and how they are different from
> a normal
> process. So can anyone offer some help as to what the problem might be?
>
> Thanks in advance,
> Almar
>
> To get to the details:
> - When I start a process with command "python -u -i"
>   -- When interactive mode is off, the whole process becomes unresponsive
> when doing
>      pylab.show()
>   -- When interactive mode in on, on doing pylab.plot(), a figure appears,
> which I can
>     zoom etc., but the process is now stuck, also after closing the figure
>
> - When I start a process with command
>   "python -u -c 'import code;code.interact(readfunc=raw_input)'"  (This is
> how Pype does it).
>   -- When interactive mode is off, the figures show when doing pylab.show()
> and the process
>      behaves as normal after closing the figure(s).
>   -- When interactive mode in on, on doing pylab.plot(), a figure appears,
> but most of the time
>      it is not drawn and emmediately unresponsive, just like the process
> itself.
>
> I have also tried an asynchronous Popen recipe by Joshiah Carlson I found
> on
> activestate. And I made my own process class using
> win32process.CreateProcess.
> Both alternatives to wx.Process resulted in the same sympoms.
>
> Oh, and I run windows.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080920/e7b7a723/attachment.html>


More information about the Python-list mailing list