Eric, Sorry about the delay, I was on vacation last week...comments inline below...
On Tue, Sep 7, 2010 at 2:26 PM, Eric Firing <efir...@hawaii.edu> wrote: > On 09/07/2010 11:07 AM, Fernando Perez wrote: >> Hi Eric, >> >> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<efir...@hawaii.edu> wrote: >>> >>> I have been doing a little testing with ipython 0.10 versus >>> ipython-newkernel, both modes, and with mpl svn versus your guisupport. >>> There are so many possible modes of operation and combinations of >>> versions and backends that all this will take some time to sort out. >>> >>> Can you give me simple examples of what does *not* work correctly when >>> you use mpl *svn* with ipython-newkernel, in either or both of the >>> console or gui modes, but *does* work with your guisupport version? >> >> Thanks for your testing, Eric. >> >> With matplotlib *alone*, I can't find a way to crash/lock/whatever the >> combo of matplotlib(svn)+ipython-newkernel. >> >> The reason, i believe, is that guisupport.py is available in ipython >> itself, and it goes out of its way to avoid creating a second main qt >> app, letting matplotlib create it. Since that main app is alive all >> the time, there's only one app and one event loop and life is good. >> But if I were to open another library that uses Qt and makes a new >> main qApp unconditionally, we'd have problems. >> >> Brian and Evan have recently just added the guisupport.py patch to >> Enthought's ETS, so that now it probably will be pretty hard to >> actually see the problem: if both ipython and ets go out of their way >> to avoid the nested main app issue, mpl can get away with making one >> unconditionally and things will probably work OK. >> >> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a >> collaborative protocol with a simple api: check for one special >> '_in_event_loop' flag in the main toolkit before making one. That >> will make it easier to have interactive code that uses Wx or Qt from >> more than one library coexisting in the same process. > > Fernando, > There are two parts to guisupport: ensure a single main app, and ensure > no more than one call to the mainloop. Yes, that is a good summary. > The first makes perfect sense, > and cannot cause any problems that I can see. The second one is the one > that I think may be both unnecessary and undesirable. The reason is > that the gui toolkit mainloop functions or methods are designed for > nested calls. This permits blocking within a running mainloop, and > allows show() to block when pyplot is not in interactive mode. This is > what is lost with the guisupport mods. Some changes to mainloop logic > may well be needed, but I don't think that prohibiting nested calls to > the underlying toolkit mainloop function is necessary or desirable. This is a very good point and is something that we have thought carefully about. You are very correct, that the functions in guisupport cannot be used to do a nested mainloop. Nested calls to the mainloop should be done in the usual manner by simply calling the appropriate gui toolkit method for doing so. We probably need to clarify this point, but the focus of the functions in guisupport are *only* the first and main invocation of the event loop. Basically, we want to ensure that: * Projects don't accidentally do nested mainloops because there were not aware that the outermost eventloop was already running. * Projects start the outermost eventloop in a manner that other projects will be able to reliably detect. I should mention the other approach that we have tried, but that failed: * Have IPython startup, create an app and start the main loop. * Then monkeypatch the gui toolkit so that the mainloop calls are no-ops. * Further monkeypatch the gui toolkit so that it appears that the mainloop is running (even when it may not be because of PyOS_InputHook magic). This allowed us to do everything, BUT obviously, nested mainloops failed. Thus, making sure that nested mainloops still work was the main reason we have created guisupport. We should better document these details though. Cheers, Brian > Eric > >> >> I'll let Brian fill in with more details when he has some >> availability, but I think that's the gist of it. >> >> Regards, >> >> f > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
