Re: [matplotlib-devel] [Numpy-discussion] [ANN] Announcing the SciPy conference schedule
A humble suggestion--for the March meeting of the american physical society, there is a roommate finder for splitting hotel rooms. This could be useful in keeping expenses down for some. There should be a way to do it without liability Cheers, William On Wed, Jul 15, 2009 at 10:13 PM, Gael Varoquaux < gael.varoqu...@normalesup.org> wrote: > The SciPy conference committee is pleased to announce the schedule of the > conference: > > http://conference.scipy.org/schedule > > This year’s program is very rich. In order to limit the number of > interesting talks that we had to turn down, we decided to reduce the > length of talks. Although this results in many short talks, we hope that > it will foster discussions, and give new ideas. Many subjects are > covered, both varying technical subject in the scientific computing > spectrum, and covering a lot of different research areas. > > I would personally like to thank the members of the program committee, > who spent time reviewing the proposed abstracts and giving the chairs > feedback. > > Fernando Perez and the tutorial presenters are hard at work finishing > planning all the details of the two-day tutorial session that will > precede the conference. An introduction tutorial track and an advanced > tutorial track, both covering various aspect of scientific computing in > Python, presented by experts in the field, should help many people > getting up to speed on the amazing technology driving this community. > > The SciPy 2009 program committee > >* Co-Chair Gaël Varoquaux, Applied Mathematics and Neuroscience, >* Neurospin, CEA - INRIA Saclay (France) >* Co-Chair Stéfan van der Walt, Applied Mathematics, University of >* Stellenbosch (South Africa) >* Michael Aivazis, Center for Advanced Computing Research, California >* Institute of Technology (USA) >* Brian Granger, Physics Department, California Polytechnic State >* University, San Luis Obispo (USA) >* Aric Hagberg, Theoretical Division, Los Alamos National Laboratory >* (USA) >* Konrad Hinsen, Centre de Biophysique Moléculaire, CNRS Orléans >* (France) >* Randall LeVeque, Mathematics, University of Washington, Seattle >* (USA) >* Travis Oliphant, Enthought (USA) >* Prabhu Ramachandran, Department of Aerospace Engineering, IIT >* Bombay (India) >* Raphael Ritz, International Neuroinformatics Coordinating Facility >* (Sweden) >* William Stein, Mathematics, University of Washington, Seattle (USA) > > Conference Chair: Jarrod Millman, Neuroscience Institute, UC Berkeley > (USA) > > ___ > NumPy-Discussion mailing list > numpy-discuss...@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-user] [Numpy-discussion] [ANN] Announcing the SciPy conference schedule
On Fri, Jul 17, 2009 at 02:38, william ratcliff wrote: > A humble suggestion--for the March meeting of the american physical society, > there is a roommate finder for splitting hotel rooms. This could be useful > in keeping expenses down for some. There should be a way to do it without > liability A wiki page would probably be the best thing given the short time frame. I recommend either the Saga or the Vagabond hotels for keeping costs down and staying close to campus. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Michiel, Thanks for the ideas. I have implemented both of the approaches you describe and I am attaching a file that has all 3 approaches. At this point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What I most need to to find strenuous test cases that can probe which of these has the best performance? Robert, could you run the Chaco test again with approaches 2 and 3 and try tuning the parameters (see the docstrings)? Cheers, Brian On Thu, Jul 16, 2009 at 11:32 PM, Michiel de Hoon wrote: > > Without monitoring stdin, you could do the following: > > while True: >run the event loop for a specified duration (say, 0.1 seconds) >check for input on stdin; if there is any: break > > But you can only do this if wx has such a time-out capability. If not, you > can do the following: > > while True: >handle all accumulated events >check for input on stdin; if there is any: break >sleep for 0.1 seconds > > The sleep is important, otherwise the CPU is busy 100% of the time, which > will drain your battery. > > This loop is essentially what you are doing in your current code, except > that you're using Python/readline for the repeated calls into the hook > function. It's better to have this loop explicitly inside your hook > function, because of the variation in PyOS_InputHook behavior between > different versions of Python/readline. > > --Michiel > > --- On Fri, 7/17/09, Brian Granger wrote: > > > From: Brian Granger > > Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes > based prototype of PyOS_InputHook for wx 2.8 and 2.9 > > To: "Michiel de Hoon" > > Cc: "Robert Kern" , enthought-...@enthought.com, > "matplotlib development list" , > "IPython Development list" > > Date: Friday, July 17, 2009, 12:59 AM > > Michiel, > > > > Thanks for the reply, this will help us to find a better > > approach. According to one of the wx devs, Robin Dunn, wx > > currently does not have the ability to monitor stdin in its > > even loop without polling. I guess there is a GSoC project > > to add this capability, but it is not there yet. Any > > thoughts on how this could be done without monitoring > > stdin. I will give the polling stdin approach a try > > though. > > > > > > Cheers, > > > > Brian > > > > > > > > > > The chunkiness probably comes from the fact that > > inputhook_wx is called repeatedly. This is different from > > how PyOS_InputHook is being used in Tkinter, PyGTK, and the > > Mac OS X backend. > > > > > > > > Schematically, this is how the Tkinter/PyGTK/MacOSX event > > loops work: > > > > > > > > 1) PyOS_InputHook is called when Python is waiting for the > > user to type in the next Python command. > > > > > > > > 2) The hook function sets up the event loop such that stdin > > is being monitored while the event loop is running. > > > > > > > > 3) The hook function then starts the event loop. > > > > > > > > 4) When input is available on stdin, the hook function > > exits the event loop, and returns. > > > > > > > > This is how the proposed Wx event loop currently works: > > > > > > > > 1) PyOS_InputHook is called when Python is waiting for the > > user to type in the next Python command. > > > > > > > > 2) The hook function processes whatever events are > > available at the time. > > > > > > > > 3) The hook function returns. > > > > > > > > 4) If still no input is available on stdin, Python calls > > the hook function again via PyOS_InputHook after a timeout. > > > > > > > > I believe the timeout is 0.1 seconds by default. However, > > Python may not call PyOS_InputHook repeatedly at all; this > > depends on which Python version is being used, and the > > version of the readline library. In some configurations > > (particularly on Windows), PyOS_InputHook is called only > > once, so wx will freeze between Python commands. > > > > > > > > > > I am not familiar with wx, but there hopefully there is > > some way to monitor stdin while the event loop is running? > > > > > > > > --Michiel. > > > > > > > > > > > > --- On Thu, 7/16/09, Brian Granger wrote: > > > > > > > > > From: Brian Granger > > > > > Subject: Re: [matplotlib-devel] [IPython-dev] > > [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for > > wx 2.8 and 2.9 > > > > > To: "Robert Kern" > > > > > Cc: enthought-...@enthought.com, > > "matplotlib development list" , > > "IPython Development list" > > > > > > > Date: Thursday, July 16, 2009, 6:57 PM > > > > > Robert, > > > > > > > > > > Thanks for testing this so quickly. Performance is > > one of > > > > > the big issues that I am concerned about. I will > > work on a > > > > > Cython based version to see if that solves the > > problem. > > > > > > > > > > Cheers, > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > Works for me with wx 2.8.8.1 on OS X 10.5 and > > > > > Chaco. Pan and zoom > > > > > > > > > > interactions are substantially chunky, though. I do > > not see > > > > > such > > > > > > > > > >
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 14:48, Brian Granger wrote: > Michiel, > > Thanks for the ideas. I have implemented both of the approaches you > describe and I am attaching a file that has all 3 approaches. At this > point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What I > most need to to find strenuous test cases that can probe which of these has > the best performance? Robert, could you run the Chaco test again with > approaches 2 and 3 and try tuning the parameters (see the docstrings)? #2 was pretty good out-of-box. #3 was slightly better than #1 but still noticeably chunky. Reducing the sleep down to 0.01 instead of 0.05 made things appreciably smooth. I thought I noticed a tiny bit of chunkiness, but I certainly didn't do a double-blind trial. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ANN: SciPy 2009 early registration extended to July 22nd
The early registration deadline for SciPy 2009 has been extended until Wednesday, July 22, 2009. Please register ( http://conference.scipy.org/to_register ) by this date to take advantage of the reduced early registration rate. Since we just announced the conference schedule, I was asked to provide extra time for people to register. Fortunately, we were able to get a few extra days from our vendors. But we will have to place orders next Thursday, so this is the last time we will be able to extend the deadline for registration. The conference schedule is available here: http://conference.scipy.org/schedule About the conference SciPy 2009, the 8th Python in Science conference, will be held from August 18-23, 2009 at Caltech in Pasadena, CA, USA. The conference starts with two days of tutorials to the scientific Python tools. There will be two tracks, one for introduction of the basic tools to beginners, and one for more advanced tools. The tutorials will be followed by two days of talks. Both days of talks will begin with a keynote address. The first day’s keynote will be given by Peter Norvig, the Director of Research at Google; while, the second keynote will be delivered by Jon Guyer, a Materials Scientist in the Thermodynamics and Kinetics Group at NIST. The program committee will select the remaining talks from submissions to our call for papers. All selected talks will be included in our conference proceedings edited by the program committee. After the talks each day we will provide several rooms for impromptu birds of a feather discussions. Finally, the last two days of the conference will be used for a number of coding sprints on the major software projects in our community. For the 8th consecutive year, the conference will bring together the developers and users of the open source software stack for scientific computing with Python. Attendees have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider commercial, academic, and research communities, this conference fosters collaboration and facilitates the sharing of software components, techniques, and a vision for high level language use in scientific computing. For further information, please visit the conference homepage: http://conference.scipy.org. Important Dates --- * Friday, July 3: Abstracts Due * Wednesday, July 15: Announce accepted talks, post schedule * Wednesday, July 22: Early Registration ends * Tuesday-Wednesday, August 18-19: Tutorials * Thursday-Friday, August 20-21: Conference * Saturday-Sunday, August 22-23: Sprints * Friday, September 4: Papers for proceedings due Executive Committee --- * Jarrod Millman, UC Berkeley, USA (Conference Chair) * Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair) * Stéfan van der Walt, University of Stellenbosch, South Africa (Program Co-Chair) * Fernando Pérez, UC Berkeley, USA (Tutorial Chair) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote: > On Fri, Jul 17, 2009 at 14:48, Brian Granger wrote: >> Michiel, >> >> Thanks for the ideas. I have implemented both of the approaches you >> describe and I am attaching a file that has all 3 approaches. At this >> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What I >> most need to to find strenuous test cases that can probe which of these has >> the best performance? Robert, could you run the Chaco test again with >> approaches 2 and 3 and try tuning the parameters (see the docstrings)? > > #2 was pretty good out-of-box. #3 was slightly better than #1 but > still noticeably chunky. Reducing the sleep down to 0.01 instead of > 0.05 made things appreciably smooth. I thought I noticed a tiny bit of > chunkiness, but I certainly didn't do a double-blind trial. Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite good, #2 perfect. However: with #2, if I did copy and paste of some command into the python terminal, I could see how ipython was putting the command letter by letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I could literally see: i in inp inpu ... (everything on one line, e.g. like if there was sleep(0.05) between each letter) with #1 and #3, pasting was immediate. Ondrej -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 2:07 PM, Ondrej Certik wrote: > On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote: >> On Fri, Jul 17, 2009 at 14:48, Brian Granger wrote: >>> Michiel, >>> >>> Thanks for the ideas. I have implemented both of the approaches you >>> describe and I am attaching a file that has all 3 approaches. At this >>> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What I >>> most need to to find strenuous test cases that can probe which of these has >>> the best performance? Robert, could you run the Chaco test again with >>> approaches 2 and 3 and try tuning the parameters (see the docstrings)? >> >> #2 was pretty good out-of-box. #3 was slightly better than #1 but >> still noticeably chunky. Reducing the sleep down to 0.01 instead of >> 0.05 made things appreciably smooth. I thought I noticed a tiny bit of >> chunkiness, but I certainly didn't do a double-blind trial. > > Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite > good, #2 perfect. However: > > with #2, if I did copy and paste of some command into the python > terminal, I could see how ipython was putting the command letter by > letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I > could literally see: > > i > in > inp > inpu > ... > > (everything on one line, e.g. like if there was sleep(0.05) between each > letter) > > with #1 and #3, pasting was immediate. so I also reduced the sleep in #3 from 0.05 to 0.01 and then #3 is absolutely smooth for me and also pasting to ipython is immediate e.g. this looks like a perfect solution to me. Ondrej -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Ondrej and Robert, Thanks for testing this. Some comments: 2) We can speed up pasting and general keyboard response by changing the polling time. Pasting is slow very slow at the original setting of 50. But if you make it smaller pasting becomes faster (although still not instant). 3) We can speed up the GUI response by decreasing the time.sleep interval. The setting of 0.01 works pretty well. Why not decrease the polling or sleep times even further? As you descrease either of these times, the idle CPU load starts to go up. Here is what I observe on my MacBook pro (both 2 and 3 show the same result): polling/sleep time of 1 (ms) gives about 13% CPU load polling/sleep time of 5 (ms) gives about 3% CPU load polling/sleep time of 10 (ms) gives about 1.5% CPU load In summary, method 3 with a time of 10 ms seems like the best overall approach. However, I am going to leave in the other methods and make it easy to set the time intervals. That way, if people want to optimize their performance for particular usage cases they can. Now, onto testing for Windows. Can anyone help with that? Thanks, Brian On Fri, Jul 17, 2009 at 1:13 PM, Ondrej Certik wrote: > On Fri, Jul 17, 2009 at 2:07 PM, Ondrej Certik wrote: > > On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote: > >> On Fri, Jul 17, 2009 at 14:48, Brian Granger > wrote: > >>> Michiel, > >>> > >>> Thanks for the ideas. I have implemented both of the approaches you > >>> describe and I am attaching a file that has all 3 approaches. At this > >>> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What > I > >>> most need to to find strenuous test cases that can probe which of these > has > >>> the best performance? Robert, could you run the Chaco test again with > >>> approaches 2 and 3 and try tuning the parameters (see the docstrings)? > >> > >> #2 was pretty good out-of-box. #3 was slightly better than #1 but > >> still noticeably chunky. Reducing the sleep down to 0.01 instead of > >> 0.05 made things appreciably smooth. I thought I noticed a tiny bit of > >> chunkiness, but I certainly didn't do a double-blind trial. > > > > Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite > > good, #2 perfect. However: > > > > with #2, if I did copy and paste of some command into the python > > terminal, I could see how ipython was putting the command letter by > > letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I > > could literally see: > > > > i > > in > > inp > > inpu > > ... > > > > (everything on one line, e.g. like if there was sleep(0.05) between each > letter) > > > > with #1 and #3, pasting was immediate. > > so I also reduced the sleep in #3 from 0.05 to 0.01 and then #3 is > absolutely smooth for me and also pasting to ipython is immediate e.g. > this looks like a perfect solution to me. > > Ondrej > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 02:13:08PM -0600, Ondrej Certik wrote: > so I also reduced the sleep in #3 from 0.05 to 0.01 and then #3 is > absolutely smooth for me and also pasting to ipython is immediate e.g. > this looks like a perfect solution to me. Polling at 100Hz is a horrendous solution from a technical point of view. I typical have a dozen IPython instances opened, where I have been working a while ago, but not doing anything right now, because I am planning to come back to it. Having these all poll at a 100Hz wil keep my laptop hot, make it switch context all the time, and drain the battery. Adobe Flash works that way. I use it as seldom as possible. One trick I play sometimes when I am developping software that needs to poll and cannot be event-driven, is to unable polling when there is activity, but turn it off when there is None. I am not sure how you can adapt the idea here, though. Gaël -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-Dev] [IPython-dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Gael, Polling at 100Hz is a horrendous solution from a technical point of view. > I typical have a dozen IPython instances opened, where I have been > working a while ago, but not doing anything right now, because I am > planning to come back to it. Having these all poll at a 100Hz wil keep my > laptop hot, make it switch context all the time, and drain the battery. > Adobe Flash works that way. I use it as seldom as possible. > I agree that polling is a non-optimal approach. But, until wx supports monitoring stdin from within the event loop, we are stuck with polling. Because of usage cases like yours, I think it is important that users be able to tune these things. For example, slower polling intervals work just fine for many things (like basic matplotlib plots) and have essentially 0 load of the CPU. It also depends on what type of compromises you are wlling to make. If you don't mind slightly slower keyboard response, but you want super fast GUI responses, then approach 2 will work great. Likewise, if you don't mind slow GUI response, but want fast keyboard, then approach 3 is best. Bottom line = we are into a position of compromise because of wx. The good news is that I think we can offer users a very flexible way of tuning all these things. > > One trick I play sometimes when I am developping software that needs to > poll and cannot be event-driven, is to unable polling when there is > activity, but turn it off when there is None. I am not sure how you can > adapt the idea here, though. > I will think about this. Cheers, Brian > > Gaël > ___ > Enthought-Dev mailing list > enthought-...@enthought.com > https://mail.enthought.com/mailman/listinfo/enthought-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Sat, Jul 18, 2009 at 12:54 AM, Brian Granger wrote: > best. Bottom line = we are into a position of compromise because of wx. > The good news is that I think we can offer users a very flexible way of > tuning all these things. Perhaps adaptive autotuning algorithm could help your case; if stdin came in rapidly, poll again very soon, otherwise adjust the delay. -- Ville M. Vainio http://tinyurl.com/vainio -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-Dev] [IPython-dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 16:54, Brian Granger wrote: > Gael, > > >> Polling at 100Hz is a horrendous solution from a technical point of view. >> I typical have a dozen IPython instances opened, where I have been >> working a while ago, but not doing anything right now, because I am >> planning to come back to it. Having these all poll at a 100Hz wil keep my >> laptop hot, make it switch context all the time, and drain the battery. >> Adobe Flash works that way. I use it as seldom as possible. > > I agree that polling is a non-optimal approach. But, until wx supports > monitoring stdin from within the event loop, we are stuck with polling. Can you describe the patch you are putting together for wxPython? or is it wxWidgets? Perhaps there is a way for us to monkeypatch the same approach into old versions. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Can you describe the patch you are putting together for wxPython? or > is it wxWidgets? Perhaps there is a way for us to monkeypatch the same > approach into old versions. > There is *very* little difference between my ctypes prototype and the patch for wxPython. The only real differences are these: * A few lines of C code that sets PyOS_InputHook and handles threading * A wx.App subclass called IApp that turns on the capability and has the implementation of the inputhook. We could definitely monkey patch wx with this IApp class. Cheers, Brian > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 17:31, Brian Granger wrote: > > >> Can you describe the patch you are putting together for wxPython? or >> is it wxWidgets? Perhaps there is a way for us to monkeypatch the same >> approach into old versions. > > There is *very* little difference between my ctypes prototype and the patch > for wxPython. Which approach? #1? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
The current patch for wxpython is based on approach 1, but that is obviously going to change after what we are seeing performance wise. Once I have a ctypes version that is really well tested (also on Win32 and Linux) I will help create a patch for wx that implements that approach. Cheers, Brian On Fri, Jul 17, 2009 at 3:40 PM, Robert Kern wrote: > On Fri, Jul 17, 2009 at 17:31, Brian Granger > wrote: > > > > > >> Can you describe the patch you are putting together for wxPython? or > >> is it wxWidgets? Perhaps there is a way for us to monkeypatch the same > >> approach into old versions. > > > > There is *very* little difference between my ctypes prototype and the > patch > > for wxPython. > > Which approach? #1? > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
On Fri, Jul 17, 2009 at 3:57 PM, Ville M. Vainio wrote: > On Sat, Jul 18, 2009 at 12:54 AM, Brian Granger > wrote: > >> best. Bottom line = we are into a position of compromise because of wx. >> The good news is that I think we can offer users a very flexible way of >> tuning all these things. > > Perhaps adaptive autotuning algorithm could help your case; if stdin > came in rapidly, poll again very soon, otherwise adjust the delay. The following patch implements this in the #3 approach: $ diff -Naur /home/ondrej/Desktop/inputhook.py inputhook.py --- /home/ondrej/Desktop/inputhook.py 2009-07-17 14:09:34.0 -0600 +++ inputhook.py2009-07-17 17:12:37.0 -0600 @@ -110,17 +110,26 @@ This sleep time should be tuned though for best performance. """ import wx +from timeit import default_timer as clock app = wx.GetApp() if app is not None: assert wx.Thread_IsMain() evtloop = wx.EventLoop() ea = wx.EventLoopActivator(evtloop) +t = clock() while not stdin_ready(): while evtloop.Pending(): +t = clock() evtloop.Dispatch() app.ProcessIdle() -time.sleep(0.01) # Change this to tune performance +if clock() - t > 0.1: +# no input is happening, we can sleep as much as we want +time.sleep(0.05) +else: +# input is happening, either wx (e.g. mouse) or keyboard, so +# sleep only very little +time.sleep(0.001) del ea return 0 Now if no input is happening, the "sleep(0.05)" version is running, thus it has very low CPU usage. If however some input is happening (either matplotlib, or ipython), then we just sleep(0.001), maybe we don't have to sleep at all, I am not sure about this. In any case, this should fix Gael's objection. Ondrej -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
