Hi there,
This appears to be a known problem with the Enthought python distribution. (See https://svn.enthought.com/epd/ticket/186 .) I have verified that I get the same behavior using ordinary ipython rather than iyt. Happily there is also a known solution for ipython: simply invoke ipython with the -whtread option. I have tried this and it solves the problem--- in ipython.
My question now is how to do the same thing for iyt. Is there a build option somewhere, so that iyt will start ipython with the -wthread flag?
Oh, yikes, thank you for bringing this to our attention and tracking down the source. You're completely right, and the bug is definitely on the yt end. I think the source of the error is the way we're embedding the Matplotlib-based IPython interpreter. It looks like (in scripts/iyt: http://yt.enzotools.org/browser/trunk/scripts/iyt/#L21 ) we're initializing: IPython.Shell.IPShellMatplotlib but I think what we *ought* to be doing is initializing: IPython.Shell.IPShellMatplotlibWX if we're doing interactive work. I was able to replicate the beachball error you mention, and this change has fixed it for me. I believe the original decision to go with the former was made under the assumption that IPython knew how to choose the appropriate backend engine; this may have been in error. I believe currently most users only use 'wx' and not, for instance, 'tk' or 'Qt' so this should be okay. I'll do some research and possibly contact the IPython developers for more information, but if you make that change (I have included a diff below, for usage with 'patch -p1' inside the yt directory) and then re-run either "python setup.py install" or "python setup.py develop" (depending on how it was installed originally) it should propagate that change, and 'iyt' should work. I'll report back once I have more information, and if/when this change gets committed to the source repository. Thanks very much for tracking this down! -Matt