On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon <mjldeh...@yahoo.com> wrote: > Hi Brian, > Thanks for your reply. I agree that integrating multiple event loops is not > essential for most users. But if you are not integrating multiple event > loops, then why do you need poll?
In the two process kernel we do currently integrate two event loops: 1. Our networking event loop that is based on zeromq/pyzmq 2. A single GUI event loop from wx, qt4, etc. We do this by triggering an iteration of our networking event loop on a periodic GUI timer. So we definitely have to face multiple event loop integration, but it is much simpler when you only have 1 GUi event loop involved. Cheers, Brian > Best, > --Michiel. > > > --- On Sun, 8/29/10, Brian Granger <elliso...@gmail.com> wrote: > >> From: Brian Granger <elliso...@gmail.com> >> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets >> and ipython >> To: "Michiel de Hoon" <mjldeh...@yahoo.com> >> Cc: matplotlib-devel@lists.sourceforge.net, "IPython Development list" >> <ipython-...@scipy.org>, enthought-...@enthought.com, "Evan Patterson" >> <epatt...@enthought.com> >> Date: Sunday, August 29, 2010, 3:24 PM >> On Sat, Aug 28, 2010 at 8:12 PM, >> Michiel de Hoon <mjldeh...@yahoo.com> >> wrote: >> > I implemented an event loop in the MacOSX backend and >> the PyOS_ImportHook event loop in PyGTK, so I've been >> interested in this topic. >> >> Yes, and you were quite helpful last summer when i was >> trying to >> understand the PyOS_InputHook logic. I appreciated that >> greatly! >> >> > If I understand guisupport.py correctly, IPython runs >> the backend-specific event loop. Have you considered to >> implement an event loop in IPython and to run that instead >> of a backend-specific event loop? Then you won't have to >> iterate the event loop, and you can run multiple GUI >> backends (PyGTK, PyQT, Tkinter, ...) at the same time. The >> latter may work with the current guisupport.py, but is >> fragile, because running one of the backend-specific event >> loops may inadvertently run code from a different backend. >> >> Yes, we do run the native event loops of the GUI toolkit >> requested. >> There are a few reasons we haven't gone the direction you >> are >> mentioning (although it has crossed our minds): >> >> 1. We are not *that* passionate about GUI event >> loops. I would say >> our philosophy with event loops is "the simplest solution >> possible >> that is robust." >> 2. While it might be nice to be able to run multiple >> event loops, in >> most cases users can survive fine without this >> feature. This is >> especially true with more and more people migrating to Qt >> because of >> the license change. >> 3. We are just barely at the point of getting the new >> PyOS_InputHook >> and two process kernel GUI support working robustly with >> matplotlib/traits/mayavi/etc. It is an 2xNxMxP >> testing nightmare with >> 2 ways IPython can run the event loop x N toolkits x M >> projects x P >> platforms. Simply installing all possible >> combinations would probably >> take a couple of weeks time, let alone debugging it >> all. I envy >> matlab developers that simple have to test their plotting >> on a few >> platforms. We will be lucky to cover >> matplotlib/traits/mayavi on just >> qt4/wx on Mac/Linux/windows for the 0.11 release. >> 4. Integrating multiple event loops is either 1) >> super subtle and >> difficult (if you actually start all the event loops >> involved) or 2) >> tends to create solutions that busy poll or consume >> non-trivial CPU >> power. The wx based PyOS_Inputhook and our two >> process GUI support >> are already great examples of this. We have to work >> pretty hard to >> create things that are responsive but that don't consume >> 100% of the >> CPU. To reduce the CPU usage of the wx PyOS_InputHook >> we actually >> dynamically scale back the polling time depending on how >> often the >> user is triggering GUI events. >> 5. It is not just about integrating GUI event >> loops. We also have >> multiple other event loops in our apps that handle >> networking. >> >> Cheers, >> >> Brian >> >> >> > --Michiel. >> > >> > --- On Sat, 8/28/10, Brian Granger <elliso...@gmail.com> >> wrote: >> > >> >> From: Brian Granger <elliso...@gmail.com> >> >> Subject: [matplotlib-devel] Uniform GUI support >> across matplotlib, ets and ipython >> >> To: matplotlib-devel@lists.sourceforge.net, >> "IPython Development list" <ipython-...@scipy.org>, >> enthought-...@enthought.com, >> "Evan Patterson" <epatt...@enthought.com> >> >> Date: Saturday, August 28, 2010, 3:42 PM >> >> Hi all, >> >> >> >> As you may know, this summer we have been >> working on >> >> a new two >> >> process IPython that has a beautiful Qt frontend >> GUI and a >> >> ZMQ based >> >> messaging layer between that GUI and the new >> IPython >> >> kernel. Many >> >> thanks to Enthought for funding this effort! >> >> >> >> We are currently in the process of adding GUI >> event loop >> >> integration >> >> to the ipython kernel so users can do interactive >> plotting >> >> like they >> >> can with the regular ipython. You may also >> remember >> >> that last summer >> >> we implemented a new PyOs_InputHook based GUI >> integration >> >> for the >> >> regular ipython. This has not been released yet, >> but >> >> all of this will >> >> be released in the upcoming 0.11 release. >> >> >> >> I am emailing everyone because we see that there >> is a need >> >> for all of >> >> us to agree on two things: >> >> >> >> 1. How to detect if a GUI application object has >> been >> >> created by someone else. >> >> 2. How to detect if a GUI event loop is >> running. >> >> >> >> Currently there is code in both ETS and matplotlib >> that >> >> fails to >> >> handle these things properly in certain cases. >> With >> >> IPython 0.10, >> >> this was not a problem because we used to >> >> hijack/monkeypatch the GUI >> >> eventloops after we started them. In 0.11, we >> will no >> >> longer be doing >> >> that. To address these issues, we have created >> a >> >> standalone module >> >> that implements the needed logic: >> >> >> >> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py >> >> >> >> This module is heavily commented and introduces a >> new >> >> informal >> >> protocol that all of use can use to detect if >> event >> >> loops are >> >> running. This informal protocol is inspired by >> how >> >> some of this is >> >> handled inside ETS. Our idea is that all >> projects >> >> will simply copy >> >> this module into their code and ship it. It is >> >> lightweight and does >> >> not depend on IPython or other top-level >> imports. As >> >> you will see, we >> >> have implemented the logic for wx and qt4, we will >> need >> >> help with >> >> other toolkits. An important point is that >> matplotlib >> >> and ets WILL >> >> NOT WORK with the upcoming release of IPython >> unless >> >> changes are made >> >> to their respective codebases. We consider this >> a >> >> draft and are more >> >> than willing to modify the design or approach as >> >> appropriate. One >> >> thing that we have not thought about yet is how to >> continue >> >> to support >> >> 0.10 within this model. >> >> >> >> The good news amidst all of this is that the >> quality and >> >> stability of >> >> the GUI support in IPython is orders of magnitude >> better >> >> than that in >> >> the 0.10 series. >> >> >> >> Cheers, >> >> >> >> Brian >> >> >> >> PS: If you are curious, here is a bit of >> background >> >> on the issues >> >> related to the PyOS_Inputhook stuff: >> >> >> >> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Sell apps to millions through the Intel(R) >> Atom(Tm) >> >> Developer Program >> >> Be part of this innovative community and reach >> millions of >> >> netbook users >> >> worldwide. Take advantage of special opportunities >> to >> >> increase revenue and >> >> speed time-to-market. Join now, and jumpstart your >> future. >> >> http://p.sf.net/sfu/intel-atom-d2d >> >> _______________________________________________ >> >> 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 >> > > > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com ------------------------------------------------------------------------------ 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
