On 09/13/2010 08:54 AM, Brian Granger wrote: > 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.
Brian, Thanks for the clarification. Your basic approach sounds fine. I need to think a little more about how to handle this in mpl. The proposed modification is not quite right yet. I probably can't work on it until the weekend. Eric > > 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 >> > > > ------------------------------------------------------------------------------ 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
