I have no idea whether this is related with the GIL. Anyhow, you may
work around this by running the blocking function in a separate
thread, although I only tested this with Gtk backends. Here is a
related post.
http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0803101609s7bd8fecaj8
Yes I already use this, but I think the problem is that the other
toolkits need the GIL to update but raw_input() also grabs the GIL so
you cannot examine your plot in a pause (i.e. raw_input()). I think
that TK is able to avoid this problem as a side effect of being in a
"C thread" instead of a p
On Sun, Mar 8, 2009 at 21:03, Jonathan Taylor
wrote:
> Wow... changing to TkAgg backend makes raw_input() just work. I
> suppose this is because the Tk thread does not need the GIL to render?
> Is there a downside to using TkAgg? I am also noticing that it is
> much faster than GtkAgg.
If you
Wow... changing to TkAgg backend makes raw_input() just work. I
suppose this is because the Tk thread does not need the GIL to render?
Is there a downside to using TkAgg? I am also noticing that it is
much faster than GtkAgg.
Jon.
On Sun, Mar 8, 2009 at 2:55 PM, Jonathan Taylor
wrote:
> Hi,
>
Hi,
I am looking to have ipython pause to show me a figure and wait for me
to press a key before it updates the figure. I see that raw_input()
does not let the figure update presumably because it blocks the gui
thread. On the other hand, pylab.waitforbuttonpress works but only
takes keys that we