Ouch, it seems we have a nasty regression with GTK, which happens to be the default on linux. Could you try starting it with

ipython --pylab --qthread

or

ipython --pylab --q4thread

To use Wx or Qt instead? Let us know how that goes, and if it works OK, it may be a necessary workaround until we find/fix the bug.

Wx and Qt/Qt4 work fine.

OK, thanks for the report. We'll try to fix the gtk bug as soon as possible, though. In the meantime, wx/qt will have to be the workaround.

Thanks, Fernando!

Took a quick look at this.
If I check out the 0.10.2 branch and invoke: ipython --pylab --gthread
it hangs.
Reverting commits
3e84e9f (most recent commit to muck with GTK in Shell.py) and
dfb0d60 (which applies on top of the previous commit)
appears to fix the hanging problem.

My gtkfix branch (http://github.com/markvoorhies/ipython/tree/gtkfix) is 0.10.2 with
the above reversions, if anyone wants to try it.

Confirmed that "ipython --pylab --gthread" hangs prior to reverting 3e84e9f, but that
after reverting "ipython --pylab --gthread" works, "plot(rand(100))" works without
hanging, and "show()" also does not hang.

Keeping simple things simple - I can confirm that:
$ ipython -pylab -gthread
In [1]: ax = subplot(111); ax.plot(rand(10)); show()
all work, without blocking with just one line change to the current 0.10.2 branch, by uncommenting gtk.set_interactive(False) after gtk is imported on line 781 of Shell.py

http://github.com/ivanov/ipython/tree/fix185

I updated to the 10.2 git branch just now, and while "ipython -pylab -gthread" leads to a working interpreter, "ipython -pylab" (no -gthread argument) exhibits the same problems described in the bug description.

Mmh, I see that. It's very odd, but thanks for pointing it out. I'll investigate further before pushing 0.10.2 out.

Any word on when 0.10.2 will be released?

Unfortunately I'm swamped and will remain so for the next 3-4 weeks. The issue is that even in the 0.10.2 branch as it stands now, the regression isn't fixed. Non-gtk backends work OK, but the gtk one remains borked, and if nobody submits a pull request with a good fix for it, I'll need some time to work on restoring the functionality myself.

So likely 3 weeks at best, I'm afraid. Lack of manpower sucks...

The best way to help would be for someone to provide a pull request against 0.10.2 that fully fixes this, and then I could quickly cut a release.

I should have time to hack on this tomorrow night, but I'm having a bit of trouble
reproducing the bug. If I check out 42cb9 (the 0.10.2 branch from 10/12) I can
reproduce the "ipython --pylab --gthread" freeze. If I check out 8ed54 (Paul's fix),
81615 (Fernando's additional check_gtk calls), or 972dc (most recent 0.10.2 commit)
and test with:

ipython --pylab
ax = subplot(111); ax.plot(rand(10)); show()

I don't see blocking. (This is on Ubuntu Lucid with up-to-date matplotlib)

Fernando or Drew, is there a better test case that I should be using?
(If not, I'll double check that I'm getting a clean rebuild of IPython after my checkouts)

The original issue was created by a portion of commit 3e84e9f which I'll refer to as "problematic commit".

My fix185 branch originally undid a portion of the problematic commit, and the outstanding issue relates to other portions of that same commit.

What isn't clear to me is the purpose of the function check_gtk inside Shell.py, which was added in the problematic commit. For some reason, it unconditionally returns mode 'tkthread' if gtk was safely imported and hasattr 'set_interactive', regardless of what mode was passed to it. This "functionality" is not used with the -pylab flag, which is why original one line change did not fix the issue for "ipython -gthread"

I added another commit to the fix185 branch which removes check_gtk() altogether, and see no issues using ipython -gthread, ipython -gthread -pylab, or ipython -pylab. Additionally, the check_gtk() imported gtk regardless of what mode the user selected, and might also be what's been causing the "Why is IPython using X11" threads on the mailing list.

also, I just want to note here that users will see this issue if they use e.g "ipython -gthread" but their matplotlib is set to some other backend by default (say "WX").

I opened pull request #237 to get this into 0.10.2 branch

mark: d'oh - we keep getting into race conditions with one another! :)

can you test the latest in my fix185 branch with:

ipython -gthread

the ipython -pylab -gthread were taken care of by the earlier fix, the -gthread without -pylab and just -pylab was actually problematic for me. Make sure that your matplotlib is using backend GTK when you do your test. I tested with

import matplotlib.pyplot as plt
plt.plot([1,2])
plt.show()
'GTK' in plt.get_backend()

Paul: Ah, my bad, I was testing with the TkAgg backend.

With the GTK backend and current fix185 (7fb20b) "ipython --gthread" runs Paul's test
without blocking (with the TkAgg backend, plt.show() blocks until the plot window is
closed). For this commit, "ipython --pylab" and "ipython --pylab --gthread" can
plot without blocking for both the GTK and TkAgg backends.
(dumping more complete test results in Paul's pull request)

Note: this old bug in LP

https://bugs.launchpad.net/ipython/+bug/270856

actually has useful info and the attached script by Ville seems to work well.

I'll try to take care of this in the next few days so we can finally get 0.10.2 out the door and fix the gtk brokenness.

Actually, now that we've merged all of Paul's pull requests, I think we're finally back to normal for GTK on 0.10.2.

Many thanks to everyone for the help with this! I'll close this now, please reopen if anybody notices any problems still with 0.10.2.