From vivainio at gmail.com Wed Jul 1 02:51:21 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 1 Jul 2009 09:51:21 +0300 Subject: [IPython-dev] Configuration, hooks and plugins In-Reply-To: <6ce0ac130906301442o1eaffb10qda43ba45a7efabc9@mail.gmail.com> References: <6ce0ac130906301442o1eaffb10qda43ba45a7efabc9@mail.gmail.com> Message-ID: <46cb515a0906302351g4889ccd3pd66b0ce505c30702@mail.gmail.com> On Wed, Jul 1, 2009 at 12:42 AM, Brian Granger wrote: > Plugins > ---------- > > Currently we use "hooks" to allow people to customize how IPython > behaves in non-trivial ways. ?Typically, hooks involve implementing > some complex behavior by in a python function. ?The current hooks > system is quite messy and grew into existence partly because IPython > simply didn't use good object oriented design. ?I propose that we move To my eyes, the hooks are the simpler way of getting most of the stuff done. There is no need for real "plugin system", magic folders, conventions, etc. This is a benefit when you are embedding ipython to another program. However, there *could* be a plugin system, but the plugins could still interface to ipython using hooks. > up as plugins. ?I have fewer thoughts on how to implement plugins, but > I know that we won't be able to use any of the fancy ways of doing > plugins like zope or setuptools. Check out: http://martyalchin.com/2008/jan/10/simple-plugin-framework/ -- Ville M. Vainio http://tinyurl.com/vainio From jorgen.stenarson at bostream.nu Wed Jul 1 13:24:49 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 01 Jul 2009 19:24:49 +0200 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> Message-ID: <4A4B9BE1.7010203@bostream.nu> Brian Granger skrev: > >> How are the changes to the testing framework going? Currently the tests >> don't work at all on windows in trunk. There is a WindowsError and no tests >> are processed. > > Ohh, I will look at that. Last I checked it did work. It is probably > related to your not having a dependency installed though. Do you have > any of: > > nose > zope.interface > twisted > > installed? > Only nose /J?rgen From fperez.net at gmail.com Wed Jul 1 15:46:50 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 1 Jul 2009 12:46:50 -0700 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> Message-ID: On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger wrote: > I would love to be able to type "ipython" rather than "IPython" all > the time so I am for this change. ?What do others think? ?Are there > problems with this that I am missing? I personally would *love* to do this now. I remember pulling back from this change a long time ago when we realized the problem on OSX/Windows because of name clashes. One aspect of this change does worry me though: there's a LOT of code in the wild that embeds ipython in all manner of tools, and we'd be breaking all of that with this change. While we're all on board with doing backwards-incompatible changes, it would be nice to keep *some* level of backwards compatibility, even if done with shim layers. We could provide a few shims so embedding code like from IPython.Shell import IPShellEmbed continues to work for one or two more releases, with proper DeprecationWarnings raised. But if we rename IPython -> ipython, I don't see a way to expose any backwards compatibility mechanism. And I think all changes of this kind should strive for a fair balance between necessary evolution and limiting the damage for existing users: there's no absolute right answer here, just a matter of finding an acceptable compromise. Cheers, f From ondrej at certik.cz Wed Jul 1 16:59:00 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Wed, 1 Jul 2009 14:59:00 -0600 Subject: [IPython-dev] how to contribute to ipython Message-ID: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> Hi, What is the way to send patches to ipython? I read this: http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines which says: " 5. Submit a patch if it's good! Go to ipython dir and do: $ bzr diff > my_cool_patch.diff 6. Attach my_cool_patch.diff to an email and send it over to ipython-dev for review & checkin. " So I did exactly that and submitted a patch to this list about 10 days ago: http://mail.scipy.org/pipermail/ipython-dev/2009-June/005191.html see the whole thread: http://mail.scipy.org/pipermail/ipython-dev/2009-June/thread.html#5191 but I never got any reply from any ipython developer. Let me know if you prefer any other workflow. Ondrej From vivainio at gmail.com Wed Jul 1 17:09:49 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 2 Jul 2009 00:09:49 +0300 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> Message-ID: <46cb515a0907011409j66f172b5ob8ca5e3b8150f33@mail.gmail.com> On Wed, Jul 1, 2009 at 10:46 PM, Fernando Perez wrote: > One aspect of this change does worry me though: there's a LOT of code > in the wild that embeds ipython in all manner of tools, and we'd be > breaking all of that with this change. ?While we're all on board with > doing backwards-incompatible changes, it would be nice to keep *some* > level of backwards compatibility, even if done with shim layers. ?We > could provide a few shims so embedding code like One more thought - perhaps this could be done after ipython works on python 3? Then, the 2.x codebase could be left as-is, and the code in py3 would be too (in the initial phase). But after a while, some refactorings for the py3 version could start trickling in. This way, 2.x would be the "same old" python, whereas the py3 branch can tolerate quite a bit of heavier breakage (because people are not relying on its apis yet). python 3 is a rather important project for ipython, since the interactive prompt is where the users will be testing the py3 waters first (and are probably less worried about having to jump a few hoops to cater for IPython). -- Ville M. Vainio http://tinyurl.com/vainio From robert.kern at gmail.com Wed Jul 1 17:15:06 2009 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 01 Jul 2009 16:15:06 -0500 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: <46cb515a0907011409j66f172b5ob8ca5e3b8150f33@mail.gmail.com> References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> <46cb515a0907011409j66f172b5ob8ca5e3b8150f33@mail.gmail.com> Message-ID: On 2009-07-01 16:09, Ville M. Vainio wrote: > On Wed, Jul 1, 2009 at 10:46 PM, Fernando Perez wrote: > >> One aspect of this change does worry me though: there's a LOT of code >> in the wild that embeds ipython in all manner of tools, and we'd be >> breaking all of that with this change. While we're all on board with >> doing backwards-incompatible changes, it would be nice to keep *some* >> level of backwards compatibility, even if done with shim layers. We >> could provide a few shims so embedding code like > > One more thought - perhaps this could be done after ipython works on > python 3? Then, the 2.x codebase could be left as-is, and the code in > py3 would be too (in the initial phase). But after a while, some > refactorings for the py3 version could start trickling in. This way, > 2.x would be the "same old" python, whereas the py3 branch can > tolerate quite a bit of heavier breakage (because people are not > relying on its apis yet). The Python developers have requested that projects *not* use the Python 3 transition as an opportunity to break compatibility. -- 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 From ellisonbg.net at gmail.com Wed Jul 1 17:16:04 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 1 Jul 2009 14:16:04 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> Message-ID: <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> Ondrej, I did see your patch when you posted it. Most of us have been on an IPython vacation for a variety of reasons. But, this week, we are getting back to things. Sorry about the silence. On Wed, Jul 1, 2009 at 1:59 PM, Ondrej Certik wrote: > Hi, > > What is the way to send patches to ipython? I read this: > > http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines > This is quite outdated. A more recent description is: http://ipython.scipy.org/doc/nightly/html/development/overview.html But, this is a little out of date compared to how it really happens these days. Here is the bottom line on how to contribute to IPython: 1. Post a bzr branch on launchpad with your changes. 2. Request a merge/review into trunk launchpad. This will trigger the review process and get the code into trunk. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Wed Jul 1 17:24:16 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 1 Jul 2009 17:24:16 -0400 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> Message-ID: On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez wrote: > On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger > wrote: > > I would love to be able to type "ipython" rather than "IPython" all > > the time so I am for this change. What do others think? Are there > > problems with this that I am missing? > > I personally would *love* to do this now. I remember pulling back > from this change a long time ago when we realized the problem on > OSX/Windows because of name clashes. > > One aspect of this change does worry me though: there's a LOT of code > in the wild that embeds ipython in all manner of tools, and we'd be > breaking all of that with this change. While we're all on board with > doing backwards-incompatible changes, it would be nice to keep *some* > level of backwards compatibility, even if done with shim layers. We > could provide a few shims so embedding code like > > from IPython.Shell import IPShellEmbed > > continues to work for one or two more releases, with proper > DeprecationWarnings raised. But if we rename IPython -> ipython, I > don't see a way to expose any backwards compatibility mechanism. And > I think all changes of this kind should strive for a fair balance > between necessary evolution and limiting the damage for existing > users: there's no absolute right answer here, just a matter of finding > an acceptable compromise. > Could the current IPython package be cleaned up to cooperate with relative package imports (using absolute_import from __future__)? Then packages that require the old organization could include it as a subpackage of their own projects, and the top-level ipython-1.0 can reorganize under ipython/. Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 1 23:58:27 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 1 Jul 2009 20:58:27 -0700 Subject: [IPython-dev] Using pygments for coloring in IPython Message-ID: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> Hi, Currently in IPython we have custom code for coloring things (python source code, tracebacks, etc.). There are a number of disadvantages with this: * We can only color python source code. It would be nice if pycat could color other languages. * We can only color to the terminal. As we develop non-terminal based IPython's, it would be very nice to be able to color to html or other forms. * Currently, we are the ones who get to maintain all this custom parsing and coloring code. These days pygments is getting a ton of use and attention because (amongst others) of its use by Sphinx. What about using pygments to color everything in IPython? I am not sure it is possible, but it might be very nice to be able to move the coloring code out of the core into the frontends - that way a frontend could decide what format things needed to be colored in. The downside is another dep (or we throw it into externals?!) Thoughts? Feedback? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Thu Jul 2 01:04:05 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 2 Jul 2009 07:04:05 +0200 Subject: [IPython-dev] Using pygments for coloring in IPython In-Reply-To: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> References: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> Message-ID: <20090702050405.GA27524@phare.normalesup.org> On Wed, Jul 01, 2009 at 08:58:27PM -0700, Brian Granger wrote: > Thoughts?? Feedback? Sounds great. As long as we have a nice fallback if pygment is not installed/non functional. Ga?l From ellisonbg.net at gmail.com Thu Jul 2 01:09:55 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 1 Jul 2009 22:09:55 -0700 Subject: [IPython-dev] Using pygments for coloring in IPython In-Reply-To: <20090702050405.GA27524@phare.normalesup.org> References: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> <20090702050405.GA27524@phare.normalesup.org> Message-ID: <6ce0ac130907012209m42478310yb0bd007489679dee@mail.gmail.com> > Sounds great. As long as we have a nice fallback if pygment is not > installed/non functional. > I think the there are a couple of fallbacks: * Just no coloring - everything works, but you get uncolored text. * Any frontend can do its own coloring if it wants. What I wouldn't want to do is still maintain our own coloring code because (in my mind) the goal of this transition is to get away from that. If we really wanted to make sure that coloring always worked, we could just ship pygments in IPython.external Would this satisfy you? Brian > Ga?l > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Thu Jul 2 01:11:22 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 2 Jul 2009 07:11:22 +0200 Subject: [IPython-dev] Using pygments for coloring in IPython In-Reply-To: <6ce0ac130907012209m42478310yb0bd007489679dee@mail.gmail.com> References: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> <20090702050405.GA27524@phare.normalesup.org> <6ce0ac130907012209m42478310yb0bd007489679dee@mail.gmail.com> Message-ID: <20090702051122.GA27993@phare.normalesup.org> On Wed, Jul 01, 2009 at 10:09:55PM -0700, Brian Granger wrote: > Sounds great. As long as we have a nice fallback if pygment is not > installed/non functional. > I think the there are a couple of fallbacks: > * Just no coloring - everything works, but you get uncolored text. > * Any frontend can do its own coloring if it wants. > What I wouldn't want to do is still maintain our own coloring code because > (in my mind) the goal of this transition is to get away from that.? If we > really wanted to make sure that coloring always worked, we could just ship > pygments in IPython.external > ? > Would this satisfy you? Any of the above would. I trust you fully to do the right choices, Ga?l From ellisonbg.net at gmail.com Thu Jul 2 02:18:15 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 1 Jul 2009 23:18:15 -0700 Subject: [IPython-dev] Progress on module reorganization: backwards compatibility Message-ID: <6ce0ac130907012318k7730aa58u8357761fc338203b@mail.gmail.com> Hi, I am making progress on re-organizing all the top-level modules of IPython into logical sub-packages. You can monitor my progress here: https://code.launchpad.net/~ipython-dev/ipython/module-reorg Overall, I am extremely pleased in how this is going - I think it will make a huge difference in making IPython easier to understand and develop. But, before this branch is merged into trunk, we need to decide how to handle certain aspects of backwards compatibility. Certain things in Ipython have become a sort of informal developer API (like ipapi) by others. For the most commonly used developer APIs we need to put in "shims" as Fernando would calls them. These shims will: * Temporarily allow people to import the dev API things the old way. * Print out a warning that the old way is depricated and will go away. The quesiton is this: what modules and classes do people think need to be handled in this way. I want to keep the number as small as possible (I am NOT going to shim the whole project!), but I also don't want to leave out really important things. In my mind, the goal here is NOT backwards compatiblity, the goal is to ease the transition to new APIs and package organization. I really need to feedback from people like Fernando and Ville on this as they have the best idea of what things fall into this category. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Thu Jul 2 03:31:46 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 2 Jul 2009 10:31:46 +0300 Subject: [IPython-dev] Progress on module reorganization: backwards compatibility In-Reply-To: <6ce0ac130907012318k7730aa58u8357761fc338203b@mail.gmail.com> References: <6ce0ac130907012318k7730aa58u8357761fc338203b@mail.gmail.com> Message-ID: <46cb515a0907020031p3bbdc29du8da67092333b19d6@mail.gmail.com> On Thu, Jul 2, 2009 at 9:18 AM, Brian Granger wrote: > The quesiton is this:? what modules and classes do people think need to be > handled in this way.? I want to keep the number as small as possible (I am > NOT going to shim the whole project!), but I also don't want to leave out Shell.py, ipapi.py and iplib.py. ipapi.py is a sort of "proxy shim" already. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Thu Jul 2 13:50:19 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Jul 2009 10:50:19 -0700 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> Message-ID: <6ce0ac130907021050n12facde8y5515206b76e0550d@mail.gmail.com> If you got rid of 2.4 support we could do this, but we still support 2.4. Brian On Wed, Jul 1, 2009 at 2:24 PM, Darren Dale wrote: > > > On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez wrote: > >> On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger >> wrote: >> > I would love to be able to type "ipython" rather than "IPython" all >> > the time so I am for this change. What do others think? Are there >> > problems with this that I am missing? >> >> I personally would *love* to do this now. I remember pulling back >> from this change a long time ago when we realized the problem on >> OSX/Windows because of name clashes. >> >> One aspect of this change does worry me though: there's a LOT of code >> in the wild that embeds ipython in all manner of tools, and we'd be >> breaking all of that with this change. While we're all on board with >> doing backwards-incompatible changes, it would be nice to keep *some* >> level of backwards compatibility, even if done with shim layers. We >> could provide a few shims so embedding code like >> >> from IPython.Shell import IPShellEmbed >> >> continues to work for one or two more releases, with proper >> DeprecationWarnings raised. But if we rename IPython -> ipython, I >> don't see a way to expose any backwards compatibility mechanism. And >> I think all changes of this kind should strive for a fair balance >> between necessary evolution and limiting the damage for existing >> users: there's no absolute right answer here, just a matter of finding >> an acceptable compromise. >> > > Could the current IPython package be cleaned up to cooperate with relative > package imports (using absolute_import from __future__)? Then packages that > require the old organization could include it as a subpackage of their own > projects, and the top-level ipython-1.0 can reorganize under ipython/. > > Darren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jul 2 13:51:58 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Jul 2009 10:51:58 -0700 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> <46cb515a0907011409j66f172b5ob8ca5e3b8150f33@mail.gmail.com> Message-ID: <6ce0ac130907021051n4b9c0efl132e086d12473c78@mail.gmail.com> > The Python developers have requested that projects *not* use the Python 3 > transition as an opportunity to break compatibility. > This is a good point. Even before Ville brought this up here, we had talked about this option offline. I think I agree though that we probably want to make this transition *before* we think about the 3k transition (if we do at all). 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Thu Jul 2 14:19:33 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 2 Jul 2009 14:19:33 -0400 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: <6ce0ac130907021050n12facde8y5515206b76e0550d@mail.gmail.com> References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> <6ce0ac130907021050n12facde8y5515206b76e0550d@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 1:50 PM, Brian Granger wrote: > If you got rid of 2.4 support we could do this, but we still support 2.4. > How much longer will you continue to support python-2.4? If dropping support for python-2.4 provided you with the flexibility to reorganize ipython the way you want, wouldn't that be a compelling reason to do so? Darren > > On Wed, Jul 1, 2009 at 2:24 PM, Darren Dale wrote: > >> >> >> On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez wrote: >> >>> On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger >>> wrote: >>> > I would love to be able to type "ipython" rather than "IPython" all >>> > the time so I am for this change. What do others think? Are there >>> > problems with this that I am missing? >>> >>> I personally would *love* to do this now. I remember pulling back >>> from this change a long time ago when we realized the problem on >>> OSX/Windows because of name clashes. >>> >>> One aspect of this change does worry me though: there's a LOT of code >>> in the wild that embeds ipython in all manner of tools, and we'd be >>> breaking all of that with this change. While we're all on board with >>> doing backwards-incompatible changes, it would be nice to keep *some* >>> level of backwards compatibility, even if done with shim layers. We >>> could provide a few shims so embedding code like >>> >>> from IPython.Shell import IPShellEmbed >>> >>> continues to work for one or two more releases, with proper >>> DeprecationWarnings raised. But if we rename IPython -> ipython, I >>> don't see a way to expose any backwards compatibility mechanism. And >>> I think all changes of this kind should strive for a fair balance >>> between necessary evolution and limiting the damage for existing >>> users: there's no absolute right answer here, just a matter of finding >>> an acceptable compromise. >>> >> >> Could the current IPython package be cleaned up to cooperate with relative >> package imports (using absolute_import from __future__)? Then packages that >> require the old organization could include it as a subpackage of their own >> projects, and the top-level ipython-1.0 can reorganize under ipython/. >> >> Darren >> > > -- "In our description of nature, the purpose is not to disclose the real essence of the phenomena but only to track down, so far as it is possible, relations between the manifold aspects of our experience" - Niels Bohr "It is a bad habit of physicists to take their most successful abstractions to be real properties of our world." - N. David Mermin "Once we have granted that any physical theory is essentially only a model for the world of experience, we must renounce all hope of finding anything like the correct theory ... simply because the totality of experience is never accessible to us." - Hugh Everett III -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jul 2 14:42:54 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 2 Jul 2009 11:42:54 -0700 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> <6ce0ac130907021050n12facde8y5515206b76e0550d@mail.gmail.com> Message-ID: <6ce0ac130907021142r5bef1283x97fe55db49b7f8d5@mail.gmail.com> > How much longer will you continue to support python-2.4? If dropping > support for python-2.4 provided you with the flexibility to reorganize > ipython the way you want, wouldn't that be a compelling reason to do so? > I am not sure. I don't know how many 2.4 users we have. It would be very nice to be able tyo use the 2.5 features like with and relative imports. But I am not sure those features are sufficient to drop 2.4 support...yet. What do others think? Brian > > Darren > > >> >> On Wed, Jul 1, 2009 at 2:24 PM, Darren Dale wrote: >> >>> >>> >>> On Wed, Jul 1, 2009 at 3:46 PM, Fernando Perez wrote: >>> >>>> On Tue, Jun 30, 2009 at 2:49 PM, Brian Granger >>>> wrote: >>>> > I would love to be able to type "ipython" rather than "IPython" all >>>> > the time so I am for this change. What do others think? Are there >>>> > problems with this that I am missing? >>>> >>>> I personally would *love* to do this now. I remember pulling back >>>> from this change a long time ago when we realized the problem on >>>> OSX/Windows because of name clashes. >>>> >>>> One aspect of this change does worry me though: there's a LOT of code >>>> in the wild that embeds ipython in all manner of tools, and we'd be >>>> breaking all of that with this change. While we're all on board with >>>> doing backwards-incompatible changes, it would be nice to keep *some* >>>> level of backwards compatibility, even if done with shim layers. We >>>> could provide a few shims so embedding code like >>>> >>>> from IPython.Shell import IPShellEmbed >>>> >>>> continues to work for one or two more releases, with proper >>>> DeprecationWarnings raised. But if we rename IPython -> ipython, I >>>> don't see a way to expose any backwards compatibility mechanism. And >>>> I think all changes of this kind should strive for a fair balance >>>> between necessary evolution and limiting the damage for existing >>>> users: there's no absolute right answer here, just a matter of finding >>>> an acceptable compromise. >>>> >>> >>> Could the current IPython package be cleaned up to cooperate with >>> relative package imports (using absolute_import from __future__)? Then >>> packages that require the old organization could include it as a subpackage >>> of their own projects, and the top-level ipython-1.0 can reorganize under >>> ipython/. >>> >>> Darren >>> >> >> > > > -- > "In our description of nature, the purpose is not to disclose the real > essence of the phenomena but only to track down, so far as it is possible, > relations between the manifold aspects of our experience" - Niels Bohr > > "It is a bad habit of physicists to take their most successful abstractions > to be real properties of our world." - N. David Mermin > > "Once we have granted that any physical theory is essentially only a model > for the world of experience, we must renounce all hope of finding anything > like the correct theory ... simply because the totality of experience is > never accessible to us." - Hugh Everett III > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Thu Jul 2 15:09:33 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 2 Jul 2009 15:09:33 -0400 Subject: [IPython-dev] IPython module and package reorganization In-Reply-To: <6ce0ac130907021142r5bef1283x97fe55db49b7f8d5@mail.gmail.com> References: <6ce0ac130906301320x7f0d624dgc7cf911ae1924c0b@mail.gmail.com> <4A4A82A6.7030206@bostream.nu> <6ce0ac130906301449g52a4289ejc53085bf3e0c82a1@mail.gmail.com> <6ce0ac130907021050n12facde8y5515206b76e0550d@mail.gmail.com> <6ce0ac130907021142r5bef1283x97fe55db49b7f8d5@mail.gmail.com> Message-ID: On Thu, Jul 2, 2009 at 2:42 PM, Brian Granger wrote: > > How much longer will you continue to support python-2.4? If dropping >> support for python-2.4 provided you with the flexibility to reorganize >> ipython the way you want, wouldn't that be a compelling reason to do so? >> > > I am not sure. I don't know how many 2.4 users we have. It would be very > nice to be able tyo use the 2.5 features like with and relative imports. > But I am not sure those features are sufficient to drop 2.4 support...yet. > What do others think? > Is there a compelling reason why python-2.4 users can not simply continue using whatever version of ipython they already have installed? Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokhansever at gmail.com Fri Jul 3 15:48:14 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Fri, 3 Jul 2009 14:48:14 -0500 Subject: [IPython-dev] Using pygments for coloring in IPython In-Reply-To: <6ce0ac130907030028h40da8313w32b28479c107325b@mail.gmail.com> References: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> <49d6b3500907022132q5b2aaf8cn720732c4dc325d31@mail.gmail.com> <6ce0ac130907030028h40da8313w32b28479c107325b@mail.gmail.com> Message-ID: <49d6b3500907031248x6015f621n7a5af7e3045c3b77@mail.gmail.com> On Fri, Jul 3, 2009 at 2:28 AM, Brian Granger wrote: > Hi, > > >> Brian, >> >> Could you tell me where is the syntax coloring code in the latest IPy >> devel branch? >> > > Yes, and no. At some level, the coloring code is spread out over many > different modules. Here are a few of them: > > * PyColorize.py > * Prompts.py > * ColorANSI.py > *excolors.py > * ultraTB > > I am not very familiar with the coloring code yet. But overall my > impression is that it is mixed in all over - thus is could be a challenge to > factor it out. > > >> >> Another question is: how easy to integrate pygments into the code-base? >> How many estimated coding days? >> > > I am still getting familiar with the coloring code, so I am not sure. One > thing that I don't know yet is exactly where the coloring is done. If it is > simply a matter of taking strings, having pygments parse and color them, > then it will be easy. But I have a feeling that the coloring is done at a > lower level *before* the strings exist and as they are created from the > relevant underlying data structures. That will make it more challenging. > > I will be refactoring the IPython core this summer. One of the things that > will happen is that the core will be decoupled from the terminal. Ideally, > I would like coloring to be done outside the core in the "view" code for > whatever frontend (terminal or GUI or web-browser, etc.) is active. > > Are you interested in helping out? > > Cheers, > > Brian > > >> >> >> -- >> G?khan >> >> > > > On Thu, Jul 2, 2009 at 9:32 PM, G?khan SEVER wrote: > >> On Wed, Jul 1, 2009 at 10:58 PM, Brian Granger >> wrote: >> > Hi, >> > >> > Currently in IPython we have custom code for coloring things (python >> source >> > code, tracebacks, etc.). There are a number of disadvantages with >> this: >> > >> > * We can only color python source code. It would be nice if pycat could >> > color other languages. >> > * We can only color to the terminal. As we develop non-terminal based >> > IPython's, it would be very nice to be able to color to html or other >> forms. >> > * Currently, we are the ones who get to maintain all this custom parsing >> and >> > coloring code. >> > >> > These days pygments is getting a ton of use and attention because >> (amongst >> > others) of its use by Sphinx. What about using pygments to color >> everything >> > in IPython? >> > >> > I am not sure it is possible, but it might be very nice to be able to >> move >> > the coloring code out of the core into the frontends - that way a >> frontend >> > could decide what format things needed to be colored in. The downside >> is >> > another dep (or we throw it into externals?!) >> > >> > Thoughts? Feedback? >> > >> > Cheers, >> > >> > Brian >> > >> > _______________________________________________ >> > IPython-dev mailing list >> > IPython-dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/ipython-dev >> > >> > >> >> Brian, >> >> Could you tell me where is the syntax coloring code in the latest IPy >> devel branch? >> >> Another question is: how easy to integrate pygments into the code-base? >> How many estimated coding days? >> >> >> -- >> G?khan >> >> > I might want to be helpful at some point during the improvement of ipython. However, I usually get easily lost in the sources. Do you have any plans for making a tutorial or giving a talk about the development details of the ipython. There are lots of presentations regarding to the usage. It would be nice to a good starting point for the novices like me to see where to get started first. -- G?khan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Fri Jul 3 15:59:32 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 3 Jul 2009 22:59:32 +0300 Subject: [IPython-dev] Using pygments for coloring in IPython In-Reply-To: <49d6b3500907031248x6015f621n7a5af7e3045c3b77@mail.gmail.com> References: <6ce0ac130907012058m8a077a9sc9fdde6c1053a84a@mail.gmail.com> <49d6b3500907022132q5b2aaf8cn720732c4dc325d31@mail.gmail.com> <6ce0ac130907030028h40da8313w32b28479c107325b@mail.gmail.com> <49d6b3500907031248x6015f621n7a5af7e3045c3b77@mail.gmail.com> Message-ID: <46cb515a0907031259h3ab56524w81b5ba35636d6663@mail.gmail.com> On Fri, Jul 3, 2009 at 10:48 PM, G?khan SEVER wrote: > I might want to be helpful at some point during the improvement of ipython. > However, I usually get easily lost in the sources. Do you have any plans for > making a tutorial or giving a talk about the development details of the > ipython. There are lots of presentations regarding to the usage. It would be > nice to a good starting point for the novices like me to see where to get > started first. IPython source is just a big pile of details, so there is not much "architectural complexity" to think about. Just read through iplib.py, and you'll be fine. Back in the day I wrote an extension to use pygments for coloring through monkeypatching, and it wasn't too much code - unfortunately I've lost the code (probably abandoned the idea because e.g. it couldn't colorize tracebacks without writing a new tokenizer, and it was just a quick hack). pygments does yield better colorizing for e.g. pycat. -- Ville M. Vainio http://tinyurl.com/vainio From dwf at cs.toronto.edu Sat Jul 4 17:48:23 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Sat, 4 Jul 2009 17:48:23 -0400 Subject: [IPython-dev] [patch] timeit unit select breaks with >= 1000second duration Message-ID: <0ED3A291-EC44-4536-8FC3-8CBE6AC99706@cs.toronto.edu> This is a minor concern since I don't know how many people use timeit for things that take more than a few seconds but I noticed that if you have a function that runs for say, 1000 seconds, the code in Magic.py fails since 'order' gets a negative number. Thus you get something like 1.0e12 nanoseconds being printed, which is kind of silly. Attached is a patch that fixes it in the simplest way possible: if best is >= 1000 then just use seconds, e.g. In [16]: %timeit -n 1 -r 1 time.sleep(1000) 1 loops, best of 1: 1e+03 s per loop Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: duration-patch.diff Type: application/octet-stream Size: 528 bytes Desc: not available URL: -------------- next part -------------- From lists at informa.tiker.net Thu Jul 9 20:01:20 2009 From: lists at informa.tiker.net (Andreas =?utf-8?q?Kl=C3=B6ckner?=) Date: Thu, 9 Jul 2009 20:01:20 -0400 Subject: [IPython-dev] IPython <-> PuDB integration Message-ID: <200907092001.21523.lists@informa.tiker.net> Hi all, I'm the author of PuDB [1], a full-screen, console-based visual debugger for Python. I've recently (0.92.6) added support for using IPython as an interactive shell, prompted by a user's request. [1] http://pypi.python.org/pypi/pudb Now that gave me an idea. The IPython web page mentions that IPython can optionally drop to Python's pdb debugger. If a user has PuDB installed, you could offer an option to drop into PuDB instead, resulting in an arguably nicer debugging experience (I'm biased, though). As of 0.92.7 (hot off the presses) PuDB offers the same programming interface as pdb--just replace 'pdb' with 'pudb'. I hope this suggestion meets with your approval. :) Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From vivainio at gmail.com Fri Jul 10 00:41:18 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 10 Jul 2009 07:41:18 +0300 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907092001.21523.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> Message-ID: <46cb515a0907092141t9b9c6b5j54de2783c7f31fd3@mail.gmail.com> On Fri, Jul 10, 2009 at 3:01 AM, Andreas Kl?ckner wrote: > Now that gave me an idea. The IPython web page mentions that IPython can > optionally drop to Python's pdb debugger. If a user has PuDB installed, you > could offer an option to drop into PuDB instead, resulting in an arguably > nicer debugging experience (I'm biased, though). As of 0.92.7 (hot off the > presses) PuDB offers the same programming interface as pdb--just replace 'pdb' > with 'pudb'. The recommended way to examine a post-mortem stack is to call %debug after it happens. Perhaps you could provide a magic command as an extension that did the same, but for PuDB? See %debug?? in ipython session. > I hope this suggestion meets with your approval. :) Actually, it doesn't even need approval, optimally, since you can ship the ipython extension with PuDB. grep for expose_magic in source tree how to create new magic commands. There is also pydb integration in place already, it may give you some hints. BTW, nice project ;-). I always thought pdb sort of sucks because of the archaic usage pattern (even gdb provides a full-screen mode out of the box). -- Ville M. Vainio http://tinyurl.com/vainio From lists at informa.tiker.net Fri Jul 10 10:25:44 2009 From: lists at informa.tiker.net (Andreas =?iso-8859-1?q?Kl=F6ckner?=) Date: Fri, 10 Jul 2009 10:25:44 -0400 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <46cb515a0907092141t9b9c6b5j54de2783c7f31fd3@mail.gmail.com> References: <200907092001.21523.lists@informa.tiker.net> <46cb515a0907092141t9b9c6b5j54de2783c7f31fd3@mail.gmail.com> Message-ID: <200907101025.45512.lists@informa.tiker.net> On Freitag 10 Juli 2009, Ville M. Vainio wrote: > > I hope this suggestion meets with your approval. :) > > Actually, it doesn't even need approval, optimally, since you can ship > the ipython extension with PuDB. grep for expose_magic in source tree > how to create new magic commands. There is also pydb integration in > place already, it may give you some hints. I'm a bit lost here. I've looked at pydbgr's (pydb's successor project) IPython integration, here: http://is.gd/1tADH and its setup script, here: http://is.gd/1tAF3 and I'm not sure I understand what's going on--especially where the IPython integration code gets installed to and how it gets found by IPython. Also, "%debug??" results in def magic_debug(self, parameter_s=''): self.shell.debugger(force=True) which I couldn't quite trace any further. Any hints? Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From lists at informa.tiker.net Fri Jul 10 10:27:32 2009 From: lists at informa.tiker.net (Andreas =?iso-8859-15?q?Kl=F6ckner?=) Date: Fri, 10 Jul 2009 10:27:32 -0400 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907092001.21523.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> Message-ID: <200907101027.33155.lists@informa.tiker.net> On Donnerstag 09 Juli 2009, Andreas Kl?ckner wrote: > Hi all, > > I'm the author of PuDB [1], a full-screen, console-based visual debugger > for Python. I've recently (0.92.6) added support for using IPython as an > interactive shell, prompted by a user's request. > > [1] http://pypi.python.org/pypi/pudb Actually, I'm running into a problem here. This is what my IPy integration code looks like: from IPython.Shell import IPShell IPShell(user_ns=locals, user_global_ns=globals) \ .mainloop(banner=banner) Now unfortunately, it seems that IPython spews a good bunch of stuff into the dict I pass as "user_ns". Any way to avoid that? Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From gokhansever at gmail.com Fri Jul 10 10:40:16 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Fri, 10 Jul 2009 09:40:16 -0500 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907101027.33155.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> <200907101027.33155.lists@informa.tiker.net> Message-ID: <49d6b3500907100740h4c69901p1e81383439d1156@mail.gmail.com> On Fri, Jul 10, 2009 at 9:27 AM, Andreas Kl?ckner wrote: > On Donnerstag 09 Juli 2009, Andreas Kl?ckner wrote: > > Hi all, > > > > I'm the author of PuDB [1], a full-screen, console-based visual debugger > > for Python. I've recently (0.92.6) added support for using IPython as an > > interactive shell, prompted by a user's request. > > > > [1] http://pypi.python.org/pypi/pudb > > Actually, I'm running into a problem here. This is what my IPy integration > code looks like: > > from IPython.Shell import IPShell > IPShell(user_ns=locals, user_global_ns=globals) \ > .mainloop(banner=banner) > > Now unfortunately, it seems that IPython spews a good bunch of stuff into > the > dict I pass as "user_ns". Any way to avoid that? > > Andreas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > How do you drop into an IPy shell with the above commands? I get bunch of error if I try them here: >>> from IPython.Shell import IPShell >>> IPShell(user_ns=locals, user_global_ns=globals).mainloop(banner=banner) Traceback (most recent call last): File "", line 1, in File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line 73, in __init__ debug=debug,shell_class=shell_class) File "/home/gsever/Desktop/python-repo/ipython/IPython/ipmaker.py", line 100, in make_IPython embedded=embedded,**kw) File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line 474, in __init__ user_global_ns) File "/home/gsever/Desktop/python-repo/ipython/IPython/ipapi.py", line 654, in make_user_namespaces user_ns.setdefault('__name__','__main__') AttributeError: 'builtin_function_or_method' object has no attribute 'setdefault' Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) IPython 0.10.bzr.r1174 -- An enhanced Interactive Python. -- G?khan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at informa.tiker.net Fri Jul 10 10:47:19 2009 From: lists at informa.tiker.net (Andreas =?iso-8859-15?q?Kl=F6ckner?=) Date: Fri, 10 Jul 2009 10:47:19 -0400 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <49d6b3500907100740h4c69901p1e81383439d1156@mail.gmail.com> References: <200907092001.21523.lists@informa.tiker.net> <200907101027.33155.lists@informa.tiker.net> <49d6b3500907100740h4c69901p1e81383439d1156@mail.gmail.com> Message-ID: <200907101047.20707.lists@informa.tiker.net> On Freitag 10 Juli 2009, G?khan SEVER wrote: > On Fri, Jul 10, 2009 at 9:27 AM, Andreas Kl?ckner > > from IPython.Shell import IPShell > > IPShell(user_ns=locals, user_global_ns=globals) \ > > .mainloop(banner=banner) > > How do you drop into an IPy shell with the above commands? "locals" is a variable that contains my locals, not the built-in function. Poor style, I know. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From robert.kern at gmail.com Fri Jul 10 11:36:09 2009 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 10 Jul 2009 10:36:09 -0500 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907101025.45512.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> <46cb515a0907092141t9b9c6b5j54de2783c7f31fd3@mail.gmail.com> <200907101025.45512.lists@informa.tiker.net> Message-ID: On 2009-07-10 09:25, Andreas Kl?ckner wrote: > On Freitag 10 Juli 2009, Ville M. Vainio wrote: >>> I hope this suggestion meets with your approval. :) >> Actually, it doesn't even need approval, optimally, since you can ship >> the ipython extension with PuDB. grep for expose_magic in source tree >> how to create new magic commands. There is also pydb integration in >> place already, it may give you some hints. > > I'm a bit lost here. I've looked at pydbgr's (pydb's successor project) > IPython integration, here: > http://is.gd/1tADH > > and its setup script, here: > http://is.gd/1tAF3 > > and I'm not sure I understand what's going on--especially where the IPython > integration code gets installed to and how it gets found by IPython. The user explicitly imports it in their ~/.ipython/ipy_user_conf.py . In ipy_pydbgr.py's case, I presume that Rocky intends us to manually copy that file into our ~/.ipython/ directories. I prefer to include these in the package itself so that it is always installed and ready for users to import. > Also, "%debug??" results in > > def magic_debug(self, parameter_s=''): > self.shell.debugger(force=True) > > which I couldn't quite trace any further. self.shell is an InteractiveShell, defined in IPython/iplib.py . The guts are all in IPython/Debugger.py . -- 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 From robert.kern at gmail.com Fri Jul 10 19:04:51 2009 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 10 Jul 2009 18:04:51 -0500 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907101027.33155.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> <200907101027.33155.lists@informa.tiker.net> Message-ID: On 2009-07-10 09:27, Andreas Kl?ckner wrote: > On Donnerstag 09 Juli 2009, Andreas Kl?ckner wrote: >> Hi all, >> >> I'm the author of PuDB [1], a full-screen, console-based visual debugger >> for Python. I've recently (0.92.6) added support for using IPython as an >> interactive shell, prompted by a user's request. >> >> [1] http://pypi.python.org/pypi/pudb > > Actually, I'm running into a problem here. This is what my IPy integration > code looks like: > > from IPython.Shell import IPShell > IPShell(user_ns=locals, user_global_ns=globals) \ > .mainloop(banner=banner) > > Now unfortunately, it seems that IPython spews a good bunch of stuff into the > dict I pass as "user_ns". Any way to avoid that? Not really. A worthwhile addition to IPShell would be a method that cleans up things it added to the namespace. -- 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 From jorgen.stenarson at bostream.nu Tue Jul 14 14:13:16 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 14 Jul 2009 20:13:16 +0200 Subject: [IPython-dev] weird error Message-ID: <4A5CCABC.3020809@bostream.nu> Have anyone had any problems using sqlite3 when running the ipython shell? I get an import error when I import sqlite3 from the ipython shell but not from the regular shell, see below. Is this something anyone alse have seen? Any ideas on what could be wrong? /J?rgen c:\python>ipython Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] Type "copyright", "credits" or "license" for more information. IPython 0.10.bzr.r1163 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: import sqlite3 --------------------------------------------------------------------------- ImportError Traceback (most recent call last) c:\python\ in () C:\Python25\lib\sqlite3\__init__.py in () 20 # 2. Altered source versions must be plainly marked as such, and must no t be 21 # misrepresented as being the original software. 22 # 3. This notice may not be removed or altered from any source distribut ion. 23 ---> 24 from dbapi2 import * C:\Python25\lib\sqlite3\dbapi2.py in () 25 import time 26 ---> 27 from _sqlite3 import * 28 29 paramstyle = "qmark" ImportError: DLL load failed: Felaktig ?tkomst till minnet. In [2]: Do you really want to exit ([y]/n)? c:\python>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 >>> From vivainio at gmail.com Tue Jul 14 14:15:28 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 14 Jul 2009 21:15:28 +0300 Subject: [IPython-dev] weird error In-Reply-To: <4A5CCABC.3020809@bostream.nu> References: <4A5CCABC.3020809@bostream.nu> Message-ID: <46cb515a0907141115l377169e2mb65554db3551de17@mail.gmail.com> On Tue, Jul 14, 2009 at 9:13 PM, J?rgen Stenarson wrote: > I get an import error when I import sqlite3 from the ipython shell but > not from the regular shell, see below. Is this something anyone alse > have seen? Any ideas on what could be wrong? Possibly you have different PATH in your ipython session. Check your %env. Works fine here. -- Ville M. Vainio http://tinyurl.com/vainio From jorgen.stenarson at bostream.nu Tue Jul 14 14:30:56 2009 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 14 Jul 2009 20:30:56 +0200 Subject: [IPython-dev] weird error In-Reply-To: <46cb515a0907141115l377169e2mb65554db3551de17@mail.gmail.com> References: <4A5CCABC.3020809@bostream.nu> <46cb515a0907141115l377169e2mb65554db3551de17@mail.gmail.com> Message-ID: <4A5CCEE0.6080706@bostream.nu> Ville M. Vainio skrev: > On Tue, Jul 14, 2009 at 9:13 PM, J?rgen > Stenarson wrote: > >> I get an import error when I import sqlite3 from the ipython shell but >> not from the regular shell, see below. Is this something anyone alse >> have seen? Any ideas on what could be wrong? > > Possibly you have different PATH in your ipython session. Check your %env. > > Works fine here. > My PATH was the same in both cases. Just importing IPython before sqlite3 causes the problem but only on python2.5 not on 2.6, see below. What version did you test? The errormessage is a memory access violation. /J?rgen C:\Python26>python Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import IPython >>> import sqlite3 >>> C:\Python26>cd .. C:\>cd Python25 C:\Python25>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import IPython >>> import sqlite3 Traceback (most recent call last): File "", line 1, in File "C:\Python25\lib\sqlite3\__init__.py", line 24, in from dbapi2 import * File "C:\Python25\lib\sqlite3\dbapi2.py", line 27, in from _sqlite3 import * ImportError: DLL load failed: Felaktig ?tkomst till minnet. >>> C:\Python25>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 >>> From ellisonbg.net at gmail.com Tue Jul 14 18:55:04 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 14 Jul 2009 15:55:04 -0700 Subject: [IPython-dev] Back from vacation and checking in... Message-ID: <6ce0ac130907141555o7f556091h3c5e028ce68bb9d6@mail.gmail.com> Hello all, I just got back from a week long vacation and wanted to check in. Tomorrow I am going to continue the module and package reorganization work that is ongoing here: https://code.launchpad.net/~ipython-dev/ipython/module-reorg I will soon need some serious code review on this branch - details will follow. Any status as to 0.10? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Wed Jul 15 19:44:35 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Wed, 15 Jul 2009 17:44:35 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> Message-ID: <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> On Wed, Jul 1, 2009 at 3:16 PM, Brian Granger wrote: > Ondrej, > > I did see your patch when you posted it.? Most of us have been on an IPython > vacation for a variety of reasons.? But, this week, we are getting back to > things.? Sorry about the silence. > > On Wed, Jul 1, 2009 at 1:59 PM, Ondrej Certik wrote: >> >> Hi, >> >> What is the way to send patches to ipython? I read this: >> >> http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines > > This is quite outdated.? A more recent description is: > > http://ipython.scipy.org/doc/nightly/html/development/overview.html > > But, this is a little out of date compared to how it really happens these > days. > > Here is the bottom line on how to contribute to IPython: > > 1.? Post a bzr branch on launchpad with your changes. > 2.? Request a merge/review into trunk launchpad.? This will trigger the > review process and get the code into trunk. Many thanks. So here is what I did. I registered a branch set_trace, then I did: $ bzr launchpad-login ondrej-certik and setup my ssh keys. Then I did: $ bzr push lp:~ipython-dev/ipython/set_trace bzr: ERROR: Target directory lp:~ipython-dev/ipython/set_trace already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway. so I tried the --use-existing-dir options, is that the correct way? $ bzr push --use-existing-dir lp:~ipython-dev/ipython/set_trace Using default stacking branch /~ipython-dev/ipython/trunk at bzr+ssh://bazaar.launchpad.net/%7Eipython-dev/ipython/ Created new branch. then I went to the web address of the branch: https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace and clicked "Propose for merging into another branch": https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace/+merge/8855 let me know if I did things correctly. If I want to checkout the trunk branch instead (e.g. without my commit), how do I do that? E.g. the equivalent of: git checkout master git checkout my_branch looking here: http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/ it's seems pretty complex. I am new to bzr, so I might be doing things the wrong way. Ondrej From ellisonbg.net at gmail.com Thu Jul 16 00:10:30 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 15 Jul 2009 21:10:30 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> Message-ID: <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> > > Many thanks. So here is what I did. I registered a branch set_trace, then I > did: > > $ bzr launchpad-login ondrej-certik > > and setup my ssh keys. Then I did: > > $ bzr push lp:~ipython-dev/ipython/set_trace > bzr: ERROR: Target directory lp:~ipython-dev/ipython/set_trace already > exists, but does not have a valid .bzr directory. Supply > --use-existing-dir to push there anyway. > > > so I tried the --use-existing-dir options, is that the correct way? > You can just push without registering the branch ahead of time. Then you don't have to use the --use-existing-dir flag. Basically a push of a new branch to lp does the registration for you. > > $ bzr push --use-existing-dir lp:~ipython-dev/ipython/set_trace > Using default stacking branch /~ipython-dev/ipython/trunk at > bzr+ssh://bazaar.launchpad.net/%7Eipython-dev/ipython/ > Created new branch. > > then I went to the web address of the branch: > > https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace > > and clicked "Propose for merging into another branch": > > https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace/+merge/8855 > > let me know if I did things correctly. > Yep, I got the email with the merge request. Fernando is about to begin working on the 0.10 release and this might make it in for that. Otherwise, we will target it for 0.11. > > If I want to checkout the trunk branch instead (e.g. without my > commit), how do I do that? E.g. the equivalent of: > > git checkout master > git checkout my_branch > > looking here: > > > http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/ > > it's seems pretty complex. I am new to bzr, so I might be doing things > the wrong way. > This does look complicated. The way we are using bzr on a daily basis is quite different from the typicaly git workflow and much simpler. With your adoration of git, you probably won't like it ;-) To get the ipython trunk branch: $ mkdir code $ cd code $ bzr branch lp:ipython This will create a new, independent "ipython" directory within "code" that will only have that branch. To also get your branch do: $ cd code $ bzr branch lp:~ipython-div/ipython/set_trace $ ls ipython set_trace To merge upstream ipython into set_trace: $ cd code/set_trace $ bzr merge ../ipython To merge the updated set_trace into trunk do: $ cd code/ipython $ bzr merge ../set_trace BUT, you want to make sure you merge all upstream changes from trunk into set_trace first. Notice, everything in our workflow is based upon the assumption that branch=directory, which is very different from git's repo=multiple branches=directory model. Anyways, thank for the code. Cheers, Brian > > Ondrej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Thu Jul 16 00:34:01 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Wed, 15 Jul 2009 22:34:01 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> Message-ID: <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> > You can just push without registering the branch ahead of time.? Then you > don't have to use the --use-existing-dir flag.? Basically a push of a new > branch to lp does the registration for you. Ah, good. >> let me know if I did things correctly. > > Yep, I got the email with the merge request.? Fernando is about to begin > working on the 0.10 release and this might make it in for that.? Otherwise, > we will target it for 0.11. Yes, but please review it, I think you may suggest me to put it somewhere else than into __init__.py. I just didn't know where it should go. > >> >> If I want to checkout the trunk branch instead (e.g. without my >> commit), how do I do that? E.g. the equivalent of: >> >> git checkout master >> git checkout my_branch >> >> looking here: >> >> >> http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/ >> >> it's seems pretty complex. I am new to bzr, so I might be doing things >> the wrong way. > > This does look complicated.? The way we are using bzr on a daily basis is > quite different from the typicaly git workflow and much simpler.? With your > adoration of git, you probably won't like it ;-)? To get the ipython trunk I will hold my judgement, until I learn bzr good enough to do all the things that I ask below. :) But don't worry, I will not hold my opinions for myself after that. :) > branch: > > $ mkdir code > $ cd code > $ bzr branch lp:ipython > > This will create a new, independent "ipython" directory within "code" that > will only have that branch.? To also get your branch do: > > $ cd code > $ bzr branch lp:~ipython-div/ipython/set_trace Except that this downloaded the whole bzr repo again. So it's very slow (but works). > $ ls > ipython > set_trace > > To merge upstream ipython into set_trace: > > $ cd code/set_trace > $ bzr merge ../ipython > > To merge the updated set_trace into trunk do: > > $ cd code/ipython > $ bzr merge ../set_trace > > BUT, you want to make sure you merge all upstream changes from trunk into > set_trace first. Right, thanks for this. Now let's say you tell me to move the function to some other file. I go to the set_trace branch, move the function. Now what -- is there a way to fix the latest commit? Or do I need to commit one more commit? What if I have to fix the 3rd commit from the top? Is there a way to do it? Now, what if I want to rebase my branch on top of the (updated) main ipython branch? E.g. not merge, but rebase. One way would be to export the patch to a file, delete the latest commit (is there some easy way to do that?), merge the main ipython branch and then manually apply the patch, and fix all collisions myself. Those are things that I was doing in mercurial, and it was a pain, but doable, until I got fedup and switched to git. In git it's super easy. So now I want to learn how to do it in bzr, so that I can compare. Then I can say which of bzr, hg, git is the best. :) > > Notice, everything in our workflow is based upon the assumption that > branch=directory, which is very different from git's repo=multiple > branches=directory model. > > Anyways, thank for the code. > > Cheers, > > Brian > > >> >> Ondrej > > From vivainio at gmail.com Thu Jul 16 03:19:21 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 16 Jul 2009 10:19:21 +0300 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> Message-ID: <46cb515a0907160019n1ac0760er3e7d73fc2663aeaf@mail.gmail.com> On Thu, Jul 16, 2009 at 7:34 AM, Ondrej Certik wrote: > I will hold my judgement, until I learn bzr good enough to do all the > things that I ask below. :) But don't worry, I will not hold my > opinions for myself after that. :) You just can't take a git workflow and apply it to bzr. That is, you are not supposed to even try it, because it'll leave you astray. Just commit normally, then merge to trunk. There will be single commit for merge, so you can think of that as your "squashing". > ipython branch? E.g. not merge, but rebase. One way would be to export > the patch to a file, delete the latest commit (is there some easy way > to do that?), merge the main ipython branch and then manually apply > the patch, and fix all collisions myself. If you want this workflow (and are familiar with hg), perhaps polishing the patches using mercurial queues would be an option? > Those are things that I was doing in mercurial, and it was a pain, but > doable, until I got fedup and switched to git. In git it's super easy. > So now I want to learn how to do it in bzr, so that I can compare. > > Then I can say which of bzr, hg, git is the best. :) As for how relevant this is to ipython, the VCS worklflow performance is hardly a blocking factor in development (as you can see, bzr log has ~ 1200 commits on mainline trunk), and other branches are not that active either: https://code.launchpad.net/ipython In general terms, having observed people using hg and git, and having used both myself, I would be hard pressed to suggest git over hg to anyone. It seems to require lots of "support" (i.e. some git-savvy person around to guide newcomers frequently), whereas hg and bzr are pretty much learn-as-you-go affairs. Git is getting lot of popularity and "buzz" at the moment, but I wouldn't be surprised by more and more people getting disappointed with it as time goes on. In the meantime, hg has extension support for 'bookmarks', 'collapse' (squash), rebase, transplant etc., for people/projects that want those (in addition to bzr-like merge-heavy worklflow with somewhat untidy version history). -- Ville M. Vainio http://tinyurl.com/vainio From fperez.net at gmail.com Thu Jul 16 03:23:51 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 Jul 2009 00:23:51 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> Message-ID: On Wed, Jul 15, 2009 at 9:10 PM, Brian Granger wrote: > Yep, I got the email with the merge request.? Fernando is about to begin > working on the 0.10 release and this might make it in for that.? Otherwise, > we will target it for 0.11. Yes! Just pinging back myself here as well. Ondrej, despite all appearances to the contrary, no attempt at ignoring you is being made :) I'll write tomorrow with more details on branch review for 0.10, so that Brian can focus only on the refactoring work. I'd promised him I'd deal with 0.10 and this falls on that category, so it's my problem :) Cheers, f From ellisonbg.net at gmail.com Thu Jul 16 13:04:33 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 10:04:33 -0700 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." Message-ID: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> Hello all, [sent to mpl-dev, enthought-dev and ipython-dev] This summer, we are doing some major refactoring of IPython's core. One of the things I am working on is changing how IPython's works with GUI toolkits. These changes will have a significant impact (hopefully for the better) on your project, so I wanted to open a discussion about this issue. Here is the current situation: currently, IPython uses threads to allow GUI event loops. This code lives in IPython.Shell and is extremely subtle, hard to maintain and fragile. Fernando and John Hunter have done a fantastic job in developing this code, but in the long run we need a more robust approach. Here is the proposal: Python has an obscure hook called PyOS_InputHook. By using this hook, GUI toolkits can interleave their event loop with a command line program *without threads*. Even though PyOS_InputHook is not well known, this is how Python's built-in integration with Tk works. The good news is that other GUI toolkits are starting to support PyOS_InputHook: * PyGTK 2.15.1 has this. * The mpl MacOSX backend works this way * Recent versions of PyQT 4 have this. * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9 Bottom line: once people are using these recent/upcoming versions of the GUI toolkits, IPython will no longer need to maintain the code in Shell.py and IPython won't need to have -pylab/-wthread/etc options. So, how does affect your project? * People will be able to use your project interactive from the regular python prompt. * You will need to make small changes to your GUI toolkits initialization code. * All of us will need to coordinate version transitions to make sure that there is a clean transition to this new approach. * I need help testing the new approach (especially with wxPython) to make sure that your project actually works with the new approach. What needs to be done at this point? * I would like to discuss how the transition should be made in terms of versions. * I need help testing this new approach in the various toolkits - especially with wx. * I want to see if there are other issues related to this that I am missing. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Thu Jul 16 13:20:52 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 19:20:52 +0200 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> Message-ID: <20090716172052.GD31447@phare.normalesup.org> On Thu, Jul 16, 2009 at 10:04:33AM -0700, Brian Granger wrote: > So, how does affect your project? > * People will be able to use your project interactive from the regular > python prompt. > * You will need to make small changes to your GUI toolkits initialization > code. > * All of us will need to coordinate version transitions to make sure that > there is a clean transition to this new approach. > * I need help testing the new approach (especially with wxPython) to make > sure that your project actually works with the new approach. Would it be possible for IPython to expose both solutions for a while (say 6 month to a year), so that we all have time to adapt? Ga?l From vivainio at gmail.com Thu Jul 16 13:26:05 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 16 Jul 2009 20:26:05 +0300 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> Message-ID: <46cb515a0907161026h43ae0deesf207bd1584aa5034@mail.gmail.com> On Thu, Jul 16, 2009 at 8:04 PM, Brian Granger wrote: > * PyGTK 2.15.1 has this. > * The mpl MacOSX backend works this way > * Recent versions of PyQT 4 have this. I think PyQT has always(?) had this. They only recently added a way to *remove* the input hook (pyqtRemoveInputHook), because pdb required it. I think the answer regarding pdb is to not use pdb (there are alternatives), but it may be possible to make pdb work anyway. > * All of us will need to coordinate version transitions to make sure that > there is a clean transition to this new approach. I'm not sure explicit transition is needed - basically, everyone that embeds ipython can move to the new approach independenly. There are no ipython changes needed for it. I think writing up instructions on embedding ipython in the "better" way could be enough, and possibly pointing to the documentation in the "deprecation note" for -wthread & likes. Here's a brief summary of what you need to do: - Tk - nothing. Just launch embedded ipython session normally, no threads needed. - Qt: http://ipython0.wordpress.com/2008/05/15/embedding-ipython-in-gui-apps-is-trivial/ - Gtk: http://launchpadlibrarian.net/17663928/pylabgtk.py, https://bugs.launchpad.net/ipython/+bug/270856 - Wx: work currently being done by Brian ;-). I do think this (PyOS_InputHook) should be done in wxpython upstream to avoid bundling binary blobs / stuff to compile w/ ipython. It should be easy to motivate wxpython people by saying all the other toolkits do this ;-) -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Thu Jul 16 13:28:11 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 16 Jul 2009 20:28:11 +0300 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <20090716172052.GD31447@phare.normalesup.org> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> Message-ID: <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> On Thu, Jul 16, 2009 at 8:20 PM, Gael Varoquaux wrote: > Would it be possible for IPython to expose both solutions for a while > (say 6 month to a year), so that we all have time to adapt? You can start adapting already, as indicated in previous post. Just adjust the embedding code, and any old version of ipython will work. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Thu Jul 16 13:28:54 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 10:28:54 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> Message-ID: <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> > > Right, thanks for this. Now let's say you tell me to move the function > to some other file. I go to the set_trace branch, move the function. > Now what -- is there a way to fix the latest commit? Or do I need to > commit one more commit? What if I have to fix the 3rd commit from the > top? Is there a way to do it? > You just keep committing. Our philosophy at this point is that all commits are worth keeping as it shows the logic of how things were developed. Often times, it is useful to see that logic looking back as it allows you to see what was tried and why it needed to be modified and how it was modified. With git rebase, you only see the final result (which I agree is very clean). The review system on launchpad actually works pretty well with this "just keep committing" approach. Now, what if I want to rebase my branch on top of the (updated) main > ipython branch? E.g. not merge, but rebase. One way would be to export > the patch to a file, delete the latest commit (is there some easy way > to do that?), merge the main ipython branch and then manually apply > the patch, and fix all collisions myself. > Definitely too painful. Just keep committing. Those are things that I was doing in mercurial, and it was a pain, but > doable, until I got fedup and switched to git. In git it's super easy. > So now I want to learn how to do it in bzr, so that I can compare. > > Then I can say which of bzr, hg, git is the best. :) > If you like to rebase, you will NOT like bzr. Cheers, Brian PS - even though I *really* like git, I agree with Ville that it is more complicated to learn and you have to use it often to keep it in your head. bzr is simple enough that I can step away from it for 3 months and when I come back, I remember everything. With git, after even a week away, I have to start digging in the docs again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Thu Jul 16 13:31:57 2009 From: mdroe at stsci.edu (Michael Droettboom) Date: Thu, 16 Jul 2009 13:31:57 -0400 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> Message-ID: <4A5F640D.8060902@stsci.edu> This is a great project and I'm sure we're all looking forward to having "just one way to do it". However, do not overestimate how up-to-date these packages will be, particularly in managed environments. For instance the RHEL4 boxes we run at my employer still have pygtk 2.4. (Yes, that is 4 years old!) It would be unfortunate if our users couldn't update matplotlib without the pain of recompiling a large part of the gtk stack underneath. So just a plea to keep the old code paths working -- perhaps surrounded in big flashing "REMOVE ME LATER" comments. I understand that maintaining code that fewer and fewer users will be running is like a time bomb. Maybe we could raise a deprecation warning if a user has an old version of a toolkit, so at least when the bomb finally goes off the user has a first guess as to why. But I think dropping all support for these older versions in one step would be a mistake. Cheers, Mike Brian Granger wrote: > Hello all, > > [sent to mpl-dev, enthought-dev and ipython-dev] > > This summer, we are doing some major refactoring of IPython's core. > One of the things I am working on is changing how IPython's works with > GUI toolkits. These changes will have a significant impact (hopefully > for the better) on your project, so I wanted to open a discussion > about this issue. > > Here is the current situation: currently, IPython uses threads to > allow GUI event loops. This code lives in IPython.Shell and is > extremely subtle, hard to maintain and fragile. Fernando and John > Hunter have done a fantastic job in developing this code, but in the > long run we need a more robust approach. > > Here is the proposal: Python has an obscure hook called > PyOS_InputHook. By using this hook, GUI toolkits can interleave their > event loop with a command line program *without threads*. Even though > PyOS_InputHook is not well known, this is how Python's built-in > integration with Tk works. The good news is that other GUI toolkits > are starting to support PyOS_InputHook: > > * PyGTK 2.15.1 has this. > * The mpl MacOSX backend works this way > * Recent versions of PyQT 4 have this. > * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9 > > Bottom line: once people are using these recent/upcoming versions of > the GUI toolkits, IPython will no longer need to maintain the code in > Shell.py and IPython won't need to have -pylab/-wthread/etc options. > > So, how does affect your project? > > * People will be able to use your project interactive from the regular > python prompt. > * You will need to make small changes to your GUI toolkits > initialization code. > * All of us will need to coordinate version transitions to make sure > that there is a clean transition to this new approach. > * I need help testing the new approach (especially with wxPython) to > make sure that your project actually works with the new approach. > > What needs to be done at this point? > > * I would like to discuss how the transition should be made in terms > of versions. > * I need help testing this new approach in the various toolkits - > especially with wx. > * I want to see if there are other issues related to this that I am > missing. > > Cheers, > > Brian > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA From ellisonbg.net at gmail.com Thu Jul 16 13:38:56 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 10:38:56 -0700 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <20090716172052.GD31447@phare.normalesup.org> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> Message-ID: <6ce0ac130907161038q646ea3edp127d56a5e2850c1a@mail.gmail.com> On Thu, Jul 16, 2009 at 10:20 AM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Thu, Jul 16, 2009 at 10:04:33AM -0700, Brian Granger wrote: > > So, how does affect your project? > > > * People will be able to use your project interactive from the regular > > python prompt. > > * You will need to make small changes to your GUI toolkits > initialization > > code. > > * All of us will need to coordinate version transitions to make sure > that > > there is a clean transition to this new approach. > > * I need help testing the new approach (especially with wxPython) to > make > > sure that your project actually works with the new approach. > > Would it be possible for IPython to expose both solutions for a while > (say 6 month to a year), so that we all have time to adapt? > Yes and no. In the short term, this is definitely possible. Also, as Ville mentions, the new approach will also work with *any* older version of IPython. However, one of the main things that needs to be refactored in IPython is the threading model. This is needed for a variety of reasons, but the bottom line is this - a number of projects are using IPython as if it were thread safe (including IPython itself) - but it is not. When I fix these things (which will be soon), I am not sure (I am doubtful) that the threaded Shell.py code will continue to work. But, this is something that I can look into. But, at some point, we will have to say "if you want the old threaded shells, you will have to use an older version of IPython". We just have to figure out what the transition looks like. Cheers, Brian > Ga?l > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Thu Jul 16 13:39:00 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 11:39:00 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> Message-ID: <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> On Thu, Jul 16, 2009 at 11:28 AM, Brian Granger wrote: > >> >> Right, thanks for this. Now let's say you tell me to move the function >> to some other file. I go to the set_trace branch, move the function. >> Now what -- is there a way to fix the latest commit? Or do I need to >> commit one more commit? What if I have to fix the 3rd commit from the >> top? Is there a way to do it? > > You just keep committing.? Our philosophy at this point is that all commits > are worth keeping as it shows the logic of how things were developed.? Often > times, it is useful to see that logic looking back as it allows you to see > what was tried and why it needed to be modified and how it was modified. > With git rebase, you only see the final result (which I agree is very > clean).? The review system on launchpad actually works pretty well with this > "just keep committing" approach. > > >> Now, what if I want to rebase my branch on top of the (updated) main >> ipython branch? E.g. not merge, but rebase. One way would be to export >> the patch to a file, delete the latest commit (is there some easy way >> to do that?), merge the main ipython branch and then manually apply >> the patch, and fix all collisions myself. > > Definitely too painful.? Just keep committing. > >> Those are things that I was doing in mercurial, and it was a pain, but >> doable, until I got fedup and switched to git. In git it's super easy. >> So now I want to learn how to do it in bzr, so that I can compare. >> >> Then I can say which of bzr, hg, git is the best. :) > > If you like to rebase, you will NOT like bzr. Ok, so I will keep committing. But here is a real problem. I commitetd with an email address ondrej at crow by a mistake and I would like to use my real address, before you merge it in. In other words, I need to fix last two commits. How can I do that? > > Cheers, > > Brian > > PS - even though I *really* like git, I agree with Ville that it is more > complicated to learn and you have to use it often to keep it in your head. > bzr is simple enough that I can step away from it for 3 months and when I > come back, I remember everything.? With git, after even a week away, I have > to start digging in the docs again. I'll comment to these later, after I really learn bazaar. Now only let me say, that you can work with git exactly the same way as with bazaar, e.g. just do: git clone git://git.sympy.org/sympy.git totally forget about git branches and just work with directories, e.g: cd /tmp git clone ~/repos/sympy etc. Then commit using "git ci" etc. And if you want to merge, just use "git pull ~/repos/sympy master" (yes, that's the only difference, that you tell git which branch to pull from, e.g. "master", since you don't use any other git branches) Ondrej From gael.varoquaux at normalesup.org Thu Jul 16 13:39:18 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 19:39:18 +0200 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> Message-ID: <20090716173918.GE31447@phare.normalesup.org> On Thu, Jul 16, 2009 at 08:28:11PM +0300, Ville M. Vainio wrote: > On Thu, Jul 16, 2009 at 8:20 PM, Gael > Varoquaux wrote: > > Would it be possible for IPython to expose both solutions for a while > > (say 6 month to a year), so that we all have time to adapt? > You can start adapting already, as indicated in previous post. Just > adjust the embedding code, and any old version of ipython will work. So, ... I am dumb, and I haven't been following things well enough (not enough time). Concretely, what do I need to do to be able to launch IPython, and pop up a wx dialog not blocking IPython with the new technology? Ga?l From gael.varoquaux at normalesup.org Thu Jul 16 13:41:32 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 19:41:32 +0200 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161038q646ea3edp127d56a5e2850c1a@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> <6ce0ac130907161038q646ea3edp127d56a5e2850c1a@mail.gmail.com> Message-ID: <20090716174132.GF31447@phare.normalesup.org> On Thu, Jul 16, 2009 at 10:38:56AM -0700, Brian Granger wrote: > But, at some point, we will have to say "if you want the old threaded > shells, you will have to use an older version of IPython".? We just have > to figure out what the transition looks like. As long as the packages sitting outside of IPython have a way of dealing with both reasonnably easily that fine. What we don't want to happen is having confusing errors or instructions depending on the version of IPython people use. As Michael points out, there will be people using the old model for a long time. Ga?l From ellisonbg.net at gmail.com Thu Jul 16 13:45:04 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 10:45:04 -0700 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <20090716173918.GE31447@phare.normalesup.org> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> <20090716173918.GE31447@phare.normalesup.org> Message-ID: <6ce0ac130907161045haa2dd27n2ed66ef9e080e09a@mail.gmail.com> Good question Gael, > So, ... I am dumb, and I haven't been following things well enough (not > enough time). Concretely, what do I need to do to be able to launch > IPython, and pop up a wx dialog not blocking IPython with the new > technology? > If you have a patched version of wx (that Robin and I are working on) you just do the following (from either ipython or python!): >>> import wx >>> app = wx.IApp(clearSigInt=False) # for interactive app then you are off to the races (you don't even need to start the mainloop) With current versions of mpl, you can do: >>> import wx >>> app = wx.IApp(clearSigInt=False) >>> from matplotlib import pyplot as plt >>> plt.interactive(True) the everything just works... Obviously, the creation of the IApp object should be put into the GUI toolkit initialization code in mpl/mayavi/etc. I will work with Robin to get a version of wx posted that has the patched applied so people can begin to test this. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Thu Jul 16 13:53:04 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 19:53:04 +0200 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161045haa2dd27n2ed66ef9e080e09a@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> <20090716173918.GE31447@phare.normalesup.org> <6ce0ac130907161045haa2dd27n2ed66ef9e080e09a@mail.gmail.com> Message-ID: <20090716175304.GG31447@phare.normalesup.org> On Thu, Jul 16, 2009 at 10:45:04AM -0700, Brian Granger wrote: > Obviously, the creation of the IApp object should be put into the GUI > toolkit initialization code in mpl/mayavi/etc.? I will work with Robin to > get a version of wx posted that has the patched applied so people can > begin to test this. OK, that's great. It enlightens me. So, it seems you guys are on the right track. I'll just wait for the new versions of wx to come out. You are doing great work on that. One piece of warning: Wx has a terrible upgrade path. Upgrading it breaks stuff. As a consequence, people don't upgrade it often, and my experience is that we have to maintain compatibility with old version for years (at least 3 years: in Ubuntu, latest release, installing SPE drags along wxPython 2.6, and thus people find themselves importing this version without realizing it). Ga?l From ellisonbg.net at gmail.com Thu Jul 16 14:06:24 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 11:06:24 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <4A5F640D.8060902@stsci.edu> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> Message-ID: <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> This is a great project and I'm sure we're all looking forward to having > "just one way to do it". > > However, do not overestimate how up-to-date these packages will be, > particularly in managed environments. For instance the RHEL4 boxes we run > at my employer still have pygtk 2.4. (Yes, that is 4 years old!) It would > be unfortunate if our users couldn't update matplotlib without the pain of > recompiling a large part of the gtk stack underneath. > I am fully aware that some environments upgrade things like GUI toolkits over very long time scales. More important - there isn't a released version of wx that has these capabilities in it. It will be a long time before everyone is running the needed versions of wx/gtk/qt. In the meantime, we will do everything we can to make sure that people running older versions of GUI toolkits can continue to use IPython (and mpl). On the mpl side of things, there will probably have to be some changes to the GUI toolkit initialization code that detects which way things are being run (old/new) and then does the right thing. If we coordinate this well, that should allow newer versions of mpl to work with both new and old versions of IPython and the GUI toolkits. However *at some point*, we will have to make a clean break. > So just a plea to keep the old code paths working -- perhaps surrounded in > big flashing "REMOVE ME LATER" comments. I understand that maintaining code > that fewer and fewer users will be running is like a time bomb. This is especially true of the threaded Shells in IPython. Honestly, even with thousands of people using it (as is currently the case) it is a time bomb. > Maybe we could raise a deprecation warning if a user has an old version of > a toolkit, so at least when the bomb finally goes off the user has a first > guess as to why. But I think dropping all support for these older versions > in one step would be a mistake. > Yes, there will definitely have to be some sort of transition. One possibility is that during the transition, the old threaded Shells would slowly loose features that become impossible to maintain (such as interrupt handling in the threaded shells). With our very limited IPython manpower, we have a very fine line to walk between moving forward and maintaining backwards compatibility. Cheers, Brian > Cheers, > Mike > > Brian Granger wrote: > >> Hello all, >> >> [sent to mpl-dev, enthought-dev and ipython-dev] >> >> This summer, we are doing some major refactoring of IPython's core. One >> of the things I am working on is changing how IPython's works with GUI >> toolkits. These changes will have a significant impact (hopefully for the >> better) on your project, so I wanted to open a discussion about this issue. >> >> Here is the current situation: currently, IPython uses threads to allow >> GUI event loops. This code lives in IPython.Shell and is extremely subtle, >> hard to maintain and fragile. Fernando and John Hunter have done a >> fantastic job in developing this code, but in the long run we need a more >> robust approach. >> >> Here is the proposal: Python has an obscure hook called PyOS_InputHook. >> By using this hook, GUI toolkits can interleave their event loop with a >> command line program *without threads*. Even though PyOS_InputHook is not >> well known, this is how Python's built-in integration with Tk works. The >> good news is that other GUI toolkits are starting to support PyOS_InputHook: >> >> * PyGTK 2.15.1 has this. >> * The mpl MacOSX backend works this way >> * Recent versions of PyQT 4 have this. >> * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9 >> >> Bottom line: once people are using these recent/upcoming versions of the >> GUI toolkits, IPython will no longer need to maintain the code in Shell.py >> and IPython won't need to have -pylab/-wthread/etc options. >> So, how does affect your project? >> >> * People will be able to use your project interactive from the regular >> python prompt. >> * You will need to make small changes to your GUI toolkits initialization >> code. >> * All of us will need to coordinate version transitions to make sure that >> there is a clean transition to this new approach. >> * I need help testing the new approach (especially with wxPython) to make >> sure that your project actually works with the new approach. >> >> What needs to be done at this point? >> >> * I would like to discuss how the transition should be made in terms of >> versions. >> * I need help testing this new approach in the various toolkits - >> especially with wx. >> * I want to see if there are other issues related to this that I am >> missing. >> >> Cheers, >> >> Brian >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> 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 at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Thu Jul 16 14:06:43 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 16 Jul 2009 21:06:43 +0300 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> Message-ID: <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik wrote: > Ok, so I will keep committing. But here is a real problem. I commitetd > with an email address ondrej at crow by a mistake and I would like to use > my real address, before you merge it in. In other words, I need to fix > last two commits. How can I do that? If you don't mind some low-tech legwork, you can do a new branch and get your changes there by bzr diff + standard 'patch' app. > I'll comment to these later, after I really learn bazaar. Now only let > me say, that you can work with git exactly the same way as with > bazaar, e.g. just do: > > git clone git://git.sympy.org/sympy.git > > totally forget about git branches and just work with directories, e.g: > > cd /tmp > git clone ~/repos/sympy > > etc. Then commit using "git ci" etc. And if you want to merge, just > use "git pull ~/repos/sympy master" ? (yes, that's the only > difference, that you tell git which branch to pull from, e.g. > "master", since you don't use any other git branches) The problem with git is not really with the possibly workflows (git has it all), it's the general "user friendliness" of the implementation/ui. It's very easy to reach a "what the hell happened" situation accompanied by cryptic error messages and general discomfort about whether your data is safe or not. If you are using a merge-driven (as opposed rebase-driven) workflow anyway, using a tool that supports that well and still has an easy-to-understand user interface seems like a sensible thing to do. It also helps if the tool has a degree of familiarity with the command names, instead of introducing totally different commands ("hg revert" / "bzr revert" / "git reset --hard"). -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Thu Jul 16 14:07:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 11:07:17 -0700 Subject: [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <20090716175304.GG31447@phare.normalesup.org> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <20090716172052.GD31447@phare.normalesup.org> <46cb515a0907161028m3196e9f2qaed585806baab6d7@mail.gmail.com> <20090716173918.GE31447@phare.normalesup.org> <6ce0ac130907161045haa2dd27n2ed66ef9e080e09a@mail.gmail.com> <20090716175304.GG31447@phare.normalesup.org> Message-ID: <6ce0ac130907161107w5f104555ha0f7370f88533d9e@mail.gmail.com> > OK, that's great. It enlightens me. So, it seems you guys are on the > right track. I'll just wait for the new versions of wx to come out. You > are doing great work on that. > Thanks. > One piece of warning: Wx has a terrible upgrade path. Upgrading it breaks > stuff. As a consequence, people don't upgrade it often, and my experience > is that we have to maintain compatibility with old version for years (at > least 3 years: in Ubuntu, latest release, installing SPE drags along > wxPython 2.6, and thus people find themselves importing this version > without realizing it). > This is good to know. Cheers, Brian > > Ga?l > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Thu Jul 16 14:11:08 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 16 Jul 2009 21:11:08 +0300 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> Message-ID: <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger wrote: > I am fully aware that some environments upgrade things like GUI toolkits > over very long time scales.? More important - there isn't a released version > of wx that has these capabilities in it.? It will be a long time before I thought you were able to make wx work with a cython-based PyOS_InputHook extension. Possibly a C-based extension could fix this issue for users of old wx versions? -- Ville M. Vainio http://tinyurl.com/vainio From ondrej at certik.cz Thu Jul 16 14:33:45 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 12:33:45 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> Message-ID: <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> On Thu, Jul 16, 2009 at 12:06 PM, Ville M. Vainio wrote: > On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik wrote: > >> Ok, so I will keep committing. But here is a real problem. I commitetd >> with an email address ondrej at crow by a mistake and I would like to use >> my real address, before you merge it in. In other words, I need to fix >> last two commits. How can I do that? > > If you don't mind some low-tech legwork, you can do a new branch and > get your changes there by bzr diff + standard 'patch' app. Well, what are my options? 1) have ondrej at crow in the ipython history 2) use the old good patch app. Well, I do want to fix my email address. Imagine I noticed after committing ~20 patches. I would not be happy to rework everything using "patch". For comparison, with git, I would do: git rebase -i HEAD~20 # assuming I have 20 patches to fix # vim fires up, I change "e" next to each patch I want to edit and then git --amend --author="Ondrej Certik " git rebase --continue # repeat the last two commands 20 times and I am done. Let me search the internet, there must be some better way than to do a new branch and rework everything from scratch. >> I'll comment to these later, after I really learn bazaar. Now only let >> me say, that you can work with git exactly the same way as with >> bazaar, e.g. just do: >> >> git clone git://git.sympy.org/sympy.git >> >> totally forget about git branches and just work with directories, e.g: >> >> cd /tmp >> git clone ~/repos/sympy >> >> etc. Then commit using "git ci" etc. And if you want to merge, just >> use "git pull ~/repos/sympy master" ? (yes, that's the only >> difference, that you tell git which branch to pull from, e.g. >> "master", since you don't use any other git branches) > > The problem with git is not really with the possibly workflows (git > has it all), it's the general "user friendliness" of the > implementation/ui. It's very easy to reach a "what the hell happened" > situation accompanied by cryptic error messages and general discomfort > about whether your data is safe or not. If you are using a I see what you mean. Well, with git, as long as you committed (you can easily check with "git log -p" that your commit does contain all your changes), it's always safe, even if you delete the branch, you can still reach all commits in the reflog, so as long as you don't actually delete the physical .git directory from your harddrive, your data is safe. So because of this, I feel very safe with git. And it saved my work several times already, so I know it works. > merge-driven (as opposed rebase-driven) workflow anyway, using a tool > that supports that well and still has an easy-to-understand user > interface seems like a sensible thing to do. Maybe. I'll comment later about bzr interface. > > It also helps if the tool has a degree of familiarity with the command > names, instead of introducing totally different commands ("hg revert" > / "bzr revert" / "git reset --hard"). Yes, I agree with this part. Ondrej From robert.kern at gmail.com Thu Jul 16 14:35:27 2009 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Jul 2009 13:35:27 -0500 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> Message-ID: On 2009-07-16 13:11, Ville M. Vainio wrote: > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger wrote: > >> I am fully aware that some environments upgrade things like GUI toolkits >> over very long time scales. More important - there isn't a released version >> of wx that has these capabilities in it. It will be a long time before > > I thought you were able to make wx work with a cython-based > PyOS_InputHook extension. Possibly a C-based extension could fix this > issue for users of old wx versions? Or even just a bit of ctypes? -- 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 From ellisonbg.net at gmail.com Thu Jul 16 15:06:02 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 12:06:02 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> Message-ID: <6ce0ac130907161206r322a1658ofa4fc49247049831@mail.gmail.com> Yes, this is also a possibility that we need to pursue as it would greatly help the transition. I do have a Cython prototype that works. But, we are currently testing all of this on wx trunk. I am not sure if what we are doing will work on previous versions. I plan on looking into this. Cheers, Brian On Thu, Jul 16, 2009 at 11:11 AM, Ville M. Vainio wrote: > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger > wrote: > > > I am fully aware that some environments upgrade things like GUI toolkits > > over very long time scales. More important - there isn't a released > version > > of wx that has these capabilities in it. It will be a long time before > > I thought you were able to make wx work with a cython-based > PyOS_InputHook extension. Possibly a C-based extension could fix this > issue for users of old wx versions? > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jul 16 15:13:11 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 12:13:11 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> Message-ID: <6ce0ac130907161213g1b1e0b4ag109c38f2433982eb@mail.gmail.com> I tried ctypes first, but with no luck. Here is what I tried: >>> import readline >>> import ctypes >>> ctypes.pythonapi.PyOS_InputHook <_FuncPtr object at 0x76420> >>> def my_callback(): ... print "In am here" ... return 0 ... >>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback) >>> cbf >>> ctypes.pythonapi.PyOS_InputHook = cbf Do you see anything wrong with this? I should probably try it again to see if I can make it work though. Cheers, Brian On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern wrote: > On 2009-07-16 13:11, Ville M. Vainio wrote: > > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger > wrote: > > > >> I am fully aware that some environments upgrade things like GUI toolkits > >> over very long time scales. More important - there isn't a released > version > >> of wx that has these capabilities in it. It will be a long time before > > > > I thought you were able to make wx work with a cython-based > > PyOS_InputHook extension. Possibly a C-based extension could fix this > > issue for users of old wx versions? > > Or even just a bit of ctypes? > > -- > 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jul 16 15:27:15 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 12:27:15 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161213g1b1e0b4ag109c38f2433982eb@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> <46cb515a0907161111vaacda1awf1ce7bec21d19751@mail.gmail.com> <6ce0ac130907161213g1b1e0b4ag109c38f2433982eb@mail.gmail.com> Message-ID: <6ce0ac130907161227n1e4a08d0qf9e9856f90feefa5@mail.gmail.com> OK, I just found this thread that shows how to set PyOS_InputHook from ctypes: http://osdir.com/ml/python.ctypes/2006-12/msg00045.html I tried it and it works fine. This will simplify the transition a lot. I will develop some pure ctypes prototypes for the various toolkits and then folks can begin to try this out. Cheers, Brian On Thu, Jul 16, 2009 at 12:13 PM, Brian Granger wrote: > I tried ctypes first, but with no luck. Here is what I tried: > > >>> import readline > >>> import ctypes > >>> ctypes.pythonapi.PyOS_InputHook > <_FuncPtr object at 0x76420> > >>> def my_callback(): > ... print "In am here" > ... return 0 > ... > >>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback) > >>> cbf > > >>> ctypes.pythonapi.PyOS_InputHook = cbf > > Do you see anything wrong with this? > > I should probably try it again to see if I can make it work though. > > Cheers, > > Brian > > > On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern wrote: > >> On 2009-07-16 13:11, Ville M. Vainio wrote: >> > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger >> wrote: >> > >> >> I am fully aware that some environments upgrade things like GUI >> toolkits >> >> over very long time scales. More important - there isn't a released >> version >> >> of wx that has these capabilities in it. It will be a long time before >> > >> > I thought you were able to make wx work with a cython-based >> > PyOS_InputHook extension. Possibly a C-based extension could fix this >> > issue for users of old wx versions? >> >> Or even just a bit of ctypes? >> >> -- >> 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-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Thu Jul 16 16:27:45 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 14:27:45 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> Message-ID: <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> On Thu, Jul 16, 2009 at 12:33 PM, Ondrej Certik wrote: > On Thu, Jul 16, 2009 at 12:06 PM, Ville M. Vainio wrote: >> On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik wrote: >> >>> Ok, so I will keep committing. But here is a real problem. I commitetd >>> with an email address ondrej at crow by a mistake and I would like to use >>> my real address, before you merge it in. In other words, I need to fix >>> last two commits. How can I do that? >> >> If you don't mind some low-tech legwork, you can do a new branch and >> get your changes there by bzr diff + standard 'patch' app. > > Well, what are my options? > > 1) have ondrej at crow in the ipython history > 2) use the old good patch app. > > Well, I do want to fix my email address. Imagine I noticed after > committing ~20 patches. I would not be happy to rework everything > using "patch". For comparison, with git, I would do: > > git rebase -i HEAD~20 ? ? ?# assuming I have 20 patches to fix > # vim fires up, I change "e" next to each patch I want to edit and then > git --amend --author="Ondrej Certik " > git rebase --continue > # repeat the last two commands 20 times > > and I am done. Let me search the internet, there must be some better > way than to do a new branch and rework everything from scratch. Ok, so there is a better way. First I did "bzr whoami " and this fixes the email in the last commit: bzr uncommit bzr commit -m "set_trace() moved from __init__.py to ipapi.py" Yes, I have to recommit the log (git allow you to reuse the log of the old, deleted, commit), but it's already a big step forward. However, now I have this problem: $ bzr push Using saved push location: bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ bzr: ERROR: These branches have diverged. Try using "merge" and then "push".1 I just changed my email. Git has "git push -f", which rewrites the remote branch. Ok, let me dig some more into this. Ondrej From ondrej at certik.cz Thu Jul 16 16:30:48 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 14:30:48 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907011416u15e69314v3a64bca9dcd2f1d3@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> Message-ID: <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> On Thu, Jul 16, 2009 at 2:27 PM, Ondrej Certik wrote: > On Thu, Jul 16, 2009 at 12:33 PM, Ondrej Certik wrote: >> On Thu, Jul 16, 2009 at 12:06 PM, Ville M. Vainio wrote: >>> On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik wrote: >>> >>>> Ok, so I will keep committing. But here is a real problem. I commitetd >>>> with an email address ondrej at crow by a mistake and I would like to use >>>> my real address, before you merge it in. In other words, I need to fix >>>> last two commits. How can I do that? >>> >>> If you don't mind some low-tech legwork, you can do a new branch and >>> get your changes there by bzr diff + standard 'patch' app. >> >> Well, what are my options? >> >> 1) have ondrej at crow in the ipython history >> 2) use the old good patch app. >> >> Well, I do want to fix my email address. Imagine I noticed after >> committing ~20 patches. I would not be happy to rework everything >> using "patch". For comparison, with git, I would do: >> >> git rebase -i HEAD~20 ? ? ?# assuming I have 20 patches to fix >> # vim fires up, I change "e" next to each patch I want to edit and then >> git --amend --author="Ondrej Certik " >> git rebase --continue >> # repeat the last two commands 20 times >> >> and I am done. Let me search the internet, there must be some better >> way than to do a new branch and rework everything from scratch. > > Ok, so there is a better way. > > First I did "bzr whoami " and this fixes the email > in the last commit: > > bzr uncommit > bzr commit -m "set_trace() moved from __init__.py to ipapi.py" > > Yes, I have to recommit the log (git allow you to reuse the log of the > old, deleted, commit), but it's already a big step forward. > > However, now I have this problem: > > $ bzr push > Using saved push location: > bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ > bzr: ERROR: These branches have diverged. ?Try using "merge" and then "push".1 > > I just changed my email. Git has "git push -f", which rewrites the > remote branch. Ok, let me dig some more into this. Very cool, now this works! $ bzr push --overwrite Using saved push location: bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ Pushed up to revision 1176. So now the only problem is to figure out how to fix the 2nd commit from top. Ondrej From ellisonbg.net at gmail.com Thu Jul 16 16:36:21 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 13:36:21 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <4A5F640D.8060902@stsci.edu> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> Message-ID: <6ce0ac130907161336w7c8beb46hc264fd7353c9c22c@mail.gmail.com> After playing a bit more, I have a ctypes based prototype that can set PyOS_InputHook in an appropriate way for wx 2.9 (trunk). I think it is possible to have a ctypes based version that would work for all the major GUI toolkits that we could ship with IPython until the transition is over (i.e., everyone is using a GUI toolkits recent enough). BUT. I need to begin to narrow the GUI toolkits and versions that we will support. The total number of possibilities (for testing, etc.) is approximately: (number of OSs~3) x (number of GUI toolkits~qt4/wx/gtk) x (number of supported versions of each GUI) Because the first 2 terms are pretty fixed, I want to bring sanity to the picture by keeping the 3rd term as small as possible. So, here is a question. What versions of what GUI toolkits do we realistically need to support moving forward (today and beyond)? By this, I mean that: "unsupported" = older versions of GUIs toolkits that will have to use older versions of IPython. "supported" = versions of GUIS that will be able to use the PyOS_InputHook approach in newer releases of IPython. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Thu Jul 16 16:56:58 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 14:56:58 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <85b5c3130907151644r78c8f9eayc2b7fe52992a1107@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> Message-ID: <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> On Thu, Jul 16, 2009 at 2:30 PM, Ondrej Certik wrote: > On Thu, Jul 16, 2009 at 2:27 PM, Ondrej Certik wrote: >> On Thu, Jul 16, 2009 at 12:33 PM, Ondrej Certik wrote: >>> On Thu, Jul 16, 2009 at 12:06 PM, Ville M. Vainio wrote: >>>> On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik wrote: >>>> >>>>> Ok, so I will keep committing. But here is a real problem. I commitetd >>>>> with an email address ondrej at crow by a mistake and I would like to use >>>>> my real address, before you merge it in. In other words, I need to fix >>>>> last two commits. How can I do that? >>>> >>>> If you don't mind some low-tech legwork, you can do a new branch and >>>> get your changes there by bzr diff + standard 'patch' app. >>> >>> Well, what are my options? >>> >>> 1) have ondrej at crow in the ipython history >>> 2) use the old good patch app. >>> >>> Well, I do want to fix my email address. Imagine I noticed after >>> committing ~20 patches. I would not be happy to rework everything >>> using "patch". For comparison, with git, I would do: >>> >>> git rebase -i HEAD~20 ? ? ?# assuming I have 20 patches to fix >>> # vim fires up, I change "e" next to each patch I want to edit and then >>> git --amend --author="Ondrej Certik " >>> git rebase --continue >>> # repeat the last two commands 20 times >>> >>> and I am done. Let me search the internet, there must be some better >>> way than to do a new branch and rework everything from scratch. >> >> Ok, so there is a better way. >> >> First I did "bzr whoami " and this fixes the email >> in the last commit: >> >> bzr uncommit >> bzr commit -m "set_trace() moved from __init__.py to ipapi.py" >> >> Yes, I have to recommit the log (git allow you to reuse the log of the >> old, deleted, commit), but it's already a big step forward. >> >> However, now I have this problem: >> >> $ bzr push >> Using saved push location: >> bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ >> bzr: ERROR: These branches have diverged. ?Try using "merge" and then "push".1 >> >> I just changed my email. Git has "git push -f", which rewrites the >> remote branch. Ok, let me dig some more into this. > > Very cool, now this works! > > $ bzr push --overwrite > Using saved push location: > bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ > Pushed up to revision 1176. > > So now the only problem is to figure out how to fix the 2nd commit from top. Ok, so I created a new branch set_trace2 and then just merged one commit from set_trace. When I did "bzr merge -r 1175 ../set_trace", it merged it, but "bzr diff" still shows the diff. So I committed it and now "bzr log" shows two commits, the old one and my new one. So I am confused, I thought that a merge would just take the commit and put it on top of my set_trace2 branch. I think I should have used "bzr pull". So I created set_trace3 and used "bzr pull", now it works. I applied my trick above with changing the email (havig to copy the log message by hand sucks, but it works). Unfortunately, I am not able to pull the next commit anymore: $ bzr pull -r 1176 ../set_trace bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. So that's a real problem now. If I use merge, it will merge it but it will be a mess. So let's use patch, that works nice (except that I have to commit the log by hand once again). Ok, so here is my reworked branch: https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace So this worked fine. But if I had 20 patches to fix, I am afraid there is no way to do it. Working with 20 patches by hand and "patch", and copy & pasting 20 log messages, well, that would be a pain. Ondrej From ellisonbg.net at gmail.com Thu Jul 16 17:09:46 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 14:09:46 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907152110r6d5cbc78pe1848435837876b9@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> Message-ID: <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> I think the answer is simple. Simply set your email using whoami like the bzr 5 minute guide says: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#introducing-yourself and then keep committing. In bzr (at least in how I use it) a commit is used in the same sense that it is in a database transaction. Namely, once you commit, there is no going back. Once you accept that this is what "commit" means, your hypothetical of "what if I had to change 20 commits" doesn't make sense. Again, the bottom line is that the conceptual model of bzr is different from git (at least in this area). Cheers, Brian On Thu, Jul 16, 2009 at 1:56 PM, Ondrej Certik wrote: > On Thu, Jul 16, 2009 at 2:30 PM, Ondrej Certik wrote: > > On Thu, Jul 16, 2009 at 2:27 PM, Ondrej Certik wrote: > >> On Thu, Jul 16, 2009 at 12:33 PM, Ondrej Certik > wrote: > >>> On Thu, Jul 16, 2009 at 12:06 PM, Ville M. Vainio > wrote: > >>>> On Thu, Jul 16, 2009 at 8:39 PM, Ondrej Certik > wrote: > >>>> > >>>>> Ok, so I will keep committing. But here is a real problem. I > commitetd > >>>>> with an email address ondrej at crow by a mistake and I would like to > use > >>>>> my real address, before you merge it in. In other words, I need to > fix > >>>>> last two commits. How can I do that? > >>>> > >>>> If you don't mind some low-tech legwork, you can do a new branch and > >>>> get your changes there by bzr diff + standard 'patch' app. > >>> > >>> Well, what are my options? > >>> > >>> 1) have ondrej at crow in the ipython history > >>> 2) use the old good patch app. > >>> > >>> Well, I do want to fix my email address. Imagine I noticed after > >>> committing ~20 patches. I would not be happy to rework everything > >>> using "patch". For comparison, with git, I would do: > >>> > >>> git rebase -i HEAD~20 # assuming I have 20 patches to fix > >>> # vim fires up, I change "e" next to each patch I want to edit and then > >>> git --amend --author="Ondrej Certik " > >>> git rebase --continue > >>> # repeat the last two commands 20 times > >>> > >>> and I am done. Let me search the internet, there must be some better > >>> way than to do a new branch and rework everything from scratch. > >> > >> Ok, so there is a better way. > >> > >> First I did "bzr whoami " and this fixes the email > >> in the last commit: > >> > >> bzr uncommit > >> bzr commit -m "set_trace() moved from __init__.py to ipapi.py" > >> > >> Yes, I have to recommit the log (git allow you to reuse the log of the > >> old, deleted, commit), but it's already a big step forward. > >> > >> However, now I have this problem: > >> > >> $ bzr push > >> Using saved push location: > >> bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ > >> bzr: ERROR: These branches have diverged. Try using "merge" and then > "push".1 > >> > >> I just changed my email. Git has "git push -f", which rewrites the > >> remote branch. Ok, let me dig some more into this. > > > > Very cool, now this works! > > > > $ bzr push --overwrite > > Using saved push location: > > bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/set_trace/ > > Pushed up to revision 1176. > > > > So now the only problem is to figure out how to fix the 2nd commit from > top. > > Ok, so I created a new branch set_trace2 and then just merged one > commit from set_trace. When I did "bzr merge -r 1175 ../set_trace", it > merged it, but "bzr diff" still shows the diff. So I committed it and > now "bzr log" shows two commits, the old one and my new one. So I am > confused, I thought that a merge would just take the commit and put it > on top of my set_trace2 branch. I think I should have used "bzr pull". > So I created set_trace3 and used "bzr pull", now it works. > > I applied my trick above with changing the email (havig to copy the > log message by hand sucks, but it works). Unfortunately, I am not able > to pull the next commit anymore: > > $ bzr pull -r 1176 ../set_trace > bzr: ERROR: These branches have diverged. Use the merge command to > reconcile them. > > So that's a real problem now. If I use merge, it will merge it but it > will be a mess. So let's use patch, that works nice (except that I > have to commit the log by hand once again). > > Ok, so here is my reworked branch: > > https://code.edge.launchpad.net/~ipython-dev/ipython/set_trace > > > So this worked fine. But if I had 20 patches to fix, I am afraid there > is no way to do it. Working with 20 patches by hand and "patch", and > copy & pasting 20 log messages, well, that would be a pain. > > Ondrej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Thu Jul 16 17:26:10 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 15:26:10 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <85b5c3130907152134m76ff8359v59793469c37d5a8@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> Message-ID: <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> On Thu, Jul 16, 2009 at 3:09 PM, Brian Granger wrote: > I think the answer is simple.? Simply set your email using whoami like the > bzr 5 minute guide says: > > http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#introducing-yourself Yes, I did that now. > > and then keep committing.? In bzr (at least in how I use it) a commit is > used in the same sense that it is in a database transaction.? Namely, once > you commit, there is no going back. > > Once you accept that this is what "commit" means, your hypothetical of "what > if I had to change 20 commits" doesn't make sense.? Again, the bottom line > is that the conceptual model of bzr is different from git (at least in this > area). Well, I made a mistake in my commit. And bzr punished me for that. Ondrej From gael.varoquaux at normalesup.org Thu Jul 16 17:31:50 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 23:31:50 +0200 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161336w7c8beb46hc264fd7353c9c22c@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161336w7c8beb46hc264fd7353c9c22c@mail.gmail.com> Message-ID: <20090716213150.GB17409@phare.normalesup.org> On Thu, Jul 16, 2009 at 01:36:21PM -0700, Brian Granger wrote: > What versions of what GUI toolkits do we realistically need to support > moving forward (today and beyond)?? By this, I mean that: > "unsupported" = older versions of GUIs toolkits that will have to use > older versions of IPython. > ?"supported" = versions of GUIS that will be able to use the > PyOS_InputHook approach in newer releases of IPython. For Wx, we would obviously need to support 2.8. We can toy with the idea of not supporting 2.6, I believe. A lot of people are starting to feel that 2.6 is depreciated. Ga?l From ellisonbg.net at gmail.com Thu Jul 16 17:32:08 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 14:32:08 -0700 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <6ce0ac130907161028q414fa4b8n4e33b07585186153@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> Message-ID: <6ce0ac130907161432s780bb512g439e711a9ee78315@mail.gmail.com> > > > Once you accept that this is what "commit" means, your hypothetical of > "what > > if I had to change 20 commits" doesn't make sense. Again, the bottom > line > > is that the conceptual model of bzr is different from git (at least in > this > > area). > > Well, I made a mistake in my commit. And bzr punished me for that. > Yes, I agree. In some ways, your mistake (wrong email) is different from a content mistake in the actual source code. You are completely right that content mistakes can be fixed by further commits, but wrong email mistakes cannot (easily). I guess that is why the bzr docs have the whoami stuff at the top of the docs. But they could be more clear about why it needs to be done *before* you commit. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jul 16 17:34:01 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 14:34:01 -0700 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <20090716213150.GB17409@phare.normalesup.org> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161336w7c8beb46hc264fd7353c9c22c@mail.gmail.com> <20090716213150.GB17409@phare.normalesup.org> Message-ID: <6ce0ac130907161434n12b1e66aw44014edcdbdbd5bd@mail.gmail.com> > For Wx, we would obviously need to support 2.8. We can toy with the idea > of not supporting 2.6, I believe. A lot of people are starting to feel > that 2.6 is depreciated. > Yes, 2.8 is latest stable, so we should support it. How many people would complain if 2.6 were not supported? I take it that all of ETS is 2.8 based? Cheers, Brian > > Ga?l > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Thu Jul 16 17:34:54 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 16 Jul 2009 23:34:54 +0200 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161434n12b1e66aw44014edcdbdbd5bd@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161336w7c8beb46hc264fd7353c9c22c@mail.gmail.com> <20090716213150.GB17409@phare.normalesup.org> <6ce0ac130907161434n12b1e66aw44014edcdbdbd5bd@mail.gmail.com> Message-ID: <20090716213454.GC17409@phare.normalesup.org> On Thu, Jul 16, 2009 at 02:34:01PM -0700, Brian Granger wrote: > Yes, 2.8 is latest stable, so we should support it.? How many people would > complain if 2.6 were not supported?? I take it that all of ETS is 2.8 > based? ETS works better on wx 2.8, but it also works on 2.6, with small bugs. Ga?l From ondrej at certik.cz Thu Jul 16 18:00:49 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 16:00:49 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <6ce0ac130907161432s780bb512g439e711a9ee78315@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> <6ce0ac130907161432s780bb512g439e711a9ee78315@mail.gmail.com> Message-ID: <85b5c3130907161500k297748bdpe03b3a5c78e5e236@mail.gmail.com> On Thu, Jul 16, 2009 at 3:32 PM, Brian Granger wrote: > >> >> > Once you accept that this is what "commit" means, your hypothetical of >> > "what >> > if I had to change 20 commits" doesn't make sense.? Again, the bottom >> > line >> > is that the conceptual model of bzr is different from git (at least in >> > this >> > area). >> >> Well, I made a mistake in my commit. And bzr punished me for that. > > Yes, I agree.? In some ways, your mistake (wrong email) is different from a > content mistake in the actual source code.? You are completely right that > content mistakes can be fixed by further commits, but wrong email mistakes > cannot (easily).? I guess that is why the bzr docs have the whoami stuff at > the top of the docs.? But they could be more clear about why it needs to be > done *before* you commit. After this is pushed in, let me contribute some more stuff using bzr to ipython, maybe some example docstrings, to get more feeling for it. How do you run doctests in ipython? Btw, running scripts/iptest on the latest bzr, I got lots of failures of the type: File "/home/ondrej/ext/code/ipython/IPython/__init__.py", line 63, in from IPython import Release # do it explicitly so pydoc can see it - pydoc bug ImportError: cannot import name Release is this a known bug? But generally, so far my impression is that bzr is more like hg --- I hated that "hg" also punished me for every single mistake I did on my local laptop (before I pushed the branch for other people to use). Hg has at least mercurial queues, which allow some kind of patch editing (but it's still pain). But git approach is very different -- it says, do what you want, I am not going to punish you for anything, I am here to help you do what you want, not to force you to do something and punish you for not obeying -- e.g. git "you tell me what to do, and I'll do it as best as I can." while bzr seems more like "I support this workflow, and if you want something else, it's your problem. read the manual before using me and don't whine if you make a mistake and there is no easy way to fix it -- it was in the manual". :) Ondrej From robert.kern at gmail.com Thu Jul 16 18:04:21 2009 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Jul 2009 17:04:21 -0500 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: <85b5c3130907161500k297748bdpe03b3a5c78e5e236@mail.gmail.com> References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <85b5c3130907161039g479c339asa552bbc9b65c433@mail.gmail.com> <46cb515a0907161106x82c7e3dud89cf030408b46d6@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> <6ce0ac130907161432s780bb512g439e711a9ee78315@mail.gmail.com> <85b5c3130907161500k297748bdpe03b3a5c78e5e236@mail.gmail.com> Message-ID: On 2009-07-16 17:00, Ondrej Certik wrote: > But generally, so far my impression is that bzr is more like hg --- I > hated that "hg" also punished me for every single mistake I did on my > local laptop (before I pushed the branch for other people to use). Hg > has at least mercurial queues, which allow some kind of patch editing > (but it's still pain). But git approach is very different -- it says, > do what you want, I am not going to punish you for anything, I am here > to help you do what you want, not to force you to do something and > punish you for not obeying -- e.g. git "you tell me what to do, and > I'll do it as best as I can." while bzr seems more like "I support > this workflow, and if you want something else, it's your problem. read > the manual before using me and don't whine if you make a mistake and > there is no easy way to fix it -- it was in the manual". :) I have found that I became much happier as a programmer once I stopped anthropomorphizing software. :-) -- 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 From ondrej at certik.cz Thu Jul 16 18:20:29 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 16:20:29 -0600 Subject: [IPython-dev] how to contribute to ipython In-Reply-To: References: <85b5c3130907011359t251a1adbse34990403e28549f@mail.gmail.com> <85b5c3130907161133l11250d2fi19d47ba27d0f7bf9@mail.gmail.com> <85b5c3130907161327n50592fd8pa6684d5d0b857572@mail.gmail.com> <85b5c3130907161330k5d4bfcf2pee693378e1ebb1cd@mail.gmail.com> <85b5c3130907161356v60ec0494g99b3c9b75e02cda5@mail.gmail.com> <6ce0ac130907161409k5a06d53cr8e8d2848760afc1@mail.gmail.com> <85b5c3130907161426g554ab40cj120135c3864428b0@mail.gmail.com> <6ce0ac130907161432s780bb512g439e711a9ee78315@mail.gmail.com> <85b5c3130907161500k297748bdpe03b3a5c78e5e236@mail.gmail.com> Message-ID: <85b5c3130907161520v73ec591au41960190ea9684b8@mail.gmail.com> On Thu, Jul 16, 2009 at 4:04 PM, Robert Kern wrote: > On 2009-07-16 17:00, Ondrej Certik wrote: > >> But generally, so far my impression is that bzr is more like hg --- I >> hated that "hg" also punished me for every single mistake I did on my >> local laptop (before I pushed the branch for other people to use). Hg >> has at least mercurial queues, which allow some kind of patch editing >> (but it's still pain). But git approach is very different -- it says, >> do what you want, I am not going to punish you for anything, I am here >> to help you do what you want, not to force you to do something and >> punish you for not obeying -- e.g. git "you tell me what to do, and >> I'll do it as best as I can." while bzr seems more like "I support >> this workflow, and if you want something else, it's your problem. read >> the manual before using me and don't whine if you make a mistake and >> there is no easy way to fix it -- it was in the manual". :) > > I have found that I became much happier as a programmer once I stopped > anthropomorphizing software. :-) Haha. I am actually more happy if I do anthropomorphize software and also hardware. :) Ondrej From ellisonbg.net at gmail.com Thu Jul 16 18:26:23 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 15:26:23 -0700 Subject: [IPython-dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 Message-ID: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> Hi, I am attaching a working ctypes based prototype of a module that allows wx to be used interactively from *both* python and ipython. It uses PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X (python 2.5). It can be used with an existing wx install and all versions of ipython, but ***don't use the -pylab or -wthread flag***. At this point, I need help testing the heck out of this (window and linux users esp). I have run most matplotlib pylab_examples and they work fine. I also need people to try out things like ETS/Mayavi. The current plan is to replace the existing threaded shells in IPython with this (much simpler) code. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inputhook.py Type: application/octet-stream Size: 2035 bytes Desc: not available URL: From gael.varoquaux at normalesup.org Thu Jul 16 18:38:15 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 17 Jul 2009 00:38:15 +0200 Subject: [IPython-dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> Message-ID: <20090716223815.GC20350@phare.normalesup.org> On Thu, Jul 16, 2009 at 03:26:23PM -0700, Brian Granger wrote: > I am attaching a working ctypes based prototype of a module that allows wx > to be used interactively from *both* python and ipython.? It uses > PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X > (python 2.5). > It can be used with an existing wx install and all versions of ipython, > but ***don't use the -pylab or -wthread flag***.? At this point, I need > help testing the heck out of this (window and linux users esp).? I have > run most matplotlib pylab_examples and they work fine.? I also need people > to try out things like ETS/Mayavi.? The current plan is to replace the > existing threaded shells in IPython with this (much simpler) code. I won't be able to do that reliably before two weeks, I am travelling and have deadlines on top of that. Maybe somebody else can try this? Cheers, Ga?l From rkern at enthought.com Thu Jul 16 18:42:09 2009 From: rkern at enthought.com (Robert Kern) Date: Thu, 16 Jul 2009 17:42:09 -0500 Subject: [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> Message-ID: <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote: > Hi, > > I am attaching a working ctypes based prototype of a module that allows wx > to be used interactively from *both* python and ipython.? It uses > PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X > (python 2.5). > > It can be used with an existing wx install and all versions of ipython, but > ***don't use the -pylab or -wthread flag***.? At this point, I need help > testing the heck out of this (window and linux users esp).? I have run most > matplotlib pylab_examples and they work fine.? I also need people to try out > things like ETS/Mayavi.? The current plan is to replace the existing > threaded shells in IPython with this (much simpler) code. 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 chunkiness with -wthread. It would be worth exploring a Cython alternative to see if it is just ctypes and general Python overhead to blame. -- 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 From ellisonbg.net at gmail.com Thu Jul 16 18:57:03 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 15:57:03 -0700 Subject: [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> Message-ID: <6ce0ac130907161557i240008c1nd1f1ea8d2e3d7f29@mail.gmail.com> 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 > chunkiness with -wthread. It would be worth exploring a Cython > alternative to see if it is just ctypes and general Python overhead to > blame. > > -- > 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjldehoon at yahoo.com Thu Jul 16 21:57:38 2009 From: mjldehoon at yahoo.com (Michiel de Hoon) Date: Thu, 16 Jul 2009 18:57:38 -0700 (PDT) Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 Message-ID: <838930.82140.qm@web62402.mail.re1.yahoo.com> 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-dev at 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 > > chunkiness with -wthread. It would be worth exploring a > Cython > > alternative to see if it is just ctypes and general Python > overhead to > > blame. > > > > -- > > 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-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > -----Inline Attachment Follows----- > > ------------------------------------------------------------------------------ > 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 > -----Inline Attachment Follows----- > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > From ellisonbg.net at gmail.com Fri Jul 17 00:59:50 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 16 Jul 2009 21:59:50 -0700 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <838930.82140.qm@web62402.mail.re1.yahoo.com> References: <838930.82140.qm@web62402.mail.re1.yahoo.com> Message-ID: <6ce0ac130907162159m3a7a4c87t6e79e5a3a756960e@mail.gmail.com> 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-dev at enthought.com, "matplotlib development list" < > matplotlib-devel at lists.sourceforge.net>, "IPython Development list" < > ipython-dev at scipy.org> > > 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 > > > > chunkiness with -wthread. It would be worth exploring a > > Cython > > > > alternative to see if it is just ctypes and general Python > > overhead to > > > > blame. > > > > > > > > -- > > > > 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-dev at scipy.org > > > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > > > -----Inline Attachment Follows----- > > > > > ------------------------------------------------------------------------------ > > 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 > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Fri Jul 17 01:11:19 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 23:11:19 -0600 Subject: [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> Message-ID: <85b5c3130907162211t6bbe6f51k647f8fdae551e1b3@mail.gmail.com> On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote: > On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote: >> Hi, >> >> I am attaching a working ctypes based prototype of a module that allows wx >> to be used interactively from *both* python and ipython.? It uses >> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X >> (python 2.5). >> >> It can be used with an existing wx install and all versions of ipython, but >> ***don't use the -pylab or -wthread flag***.? At this point, I need help >> testing the heck out of this (window and linux users esp).? I have run most >> matplotlib pylab_examples and they work fine.? I also need people to try out >> things like ETS/Mayavi.? The current plan is to replace the existing >> threaded shells in IPython with this (much simpler) code. > > 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 > chunkiness with -wthread. It would be worth exploring a Cython > alternative to see if it is just ctypes and general Python overhead to > blame. Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I tried this example: In [1]: import inputhook In [2]: inputhook.set_inputhook_wx() In [3]: app = wx.App(redirect=False, clearSigInt=False) --------------------------------------------------------------------------- NameError Traceback (most recent call last) /home/ondrej/Desktop/ in () NameError: name 'wx' is not defined In [4]: import wx In [5]: app = wx.App(redirect=False, clearSigInt=False) In [6]: from matplotlib import pyplot as plt In [7]: plt.interactive(True) In [8]: plt.plot(range(10)) Out[8]: [] (maybe you want to add "import wx" into that example docstring) Pan is perfectly smooth, zoom is a bit chunky, but not much, it's definitely usable. Ondrej From ondrej at certik.cz Fri Jul 17 01:27:51 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 16 Jul 2009 23:27:51 -0600 Subject: [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <85b5c3130907162211t6bbe6f51k647f8fdae551e1b3@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> <85b5c3130907162211t6bbe6f51k647f8fdae551e1b3@mail.gmail.com> Message-ID: <85b5c3130907162227q6d6e026bm6070fbd5c6d115fe@mail.gmail.com> On Thu, Jul 16, 2009 at 11:11 PM, Ondrej Certik wrote: > On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote: >> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote: >>> Hi, >>> >>> I am attaching a working ctypes based prototype of a module that allows wx >>> to be used interactively from *both* python and ipython.? It uses >>> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X >>> (python 2.5). >>> >>> It can be used with an existing wx install and all versions of ipython, but >>> ***don't use the -pylab or -wthread flag***.? At this point, I need help >>> testing the heck out of this (window and linux users esp).? I have run most >>> matplotlib pylab_examples and they work fine.? I also need people to try out >>> things like ETS/Mayavi.? The current plan is to replace the existing >>> threaded shells in IPython with this (much simpler) code. >> >> 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 >> chunkiness with -wthread. It would be worth exploring a Cython >> alternative to see if it is just ctypes and general Python overhead to >> blame. > > Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I > tried this example: > > In [1]: import inputhook > > In [2]: inputhook.set_inputhook_wx() > > In [3]: app = wx.App(redirect=False, clearSigInt=False) > --------------------------------------------------------------------------- > NameError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last) > > /home/ondrej/Desktop/ in () > > NameError: name 'wx' is not defined > > In [4]: import wx > > In [5]: app = wx.App(redirect=False, clearSigInt=False) > > In [6]: from matplotlib import pyplot as plt > > In [7]: plt.interactive(True) > > In [8]: plt.plot(range(10)) > Out[8]: [] > > > (maybe you want to add "import wx" into that example docstring) > > > Pan is perfectly smooth, zoom is a bit chunky, but not much, it's > definitely usable. I also tested mayavi, this demo: http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html#a-demo and I didn't notice any speed difference --- e.g. it's as slow as regular mayavi with ipython -wthread. :) Ondrej From gael.varoquaux at normalesup.org Fri Jul 17 01:30:08 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 17 Jul 2009 07:30:08 +0200 Subject: [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <85b5c3130907162227q6d6e026bm6070fbd5c6d115fe@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> <3d375d730907161542g14e5f08fm8f3aadd3ae905d20@mail.gmail.com> <85b5c3130907162211t6bbe6f51k647f8fdae551e1b3@mail.gmail.com> <85b5c3130907162227q6d6e026bm6070fbd5c6d115fe@mail.gmail.com> Message-ID: <20090717053008.GC20594@phare.normalesup.org> On Thu, Jul 16, 2009 at 11:27:51PM -0600, Ondrej Certik wrote: > and I didn't notice any speed difference --- e.g. it's as slow as > regular mayavi with ipython -wthread. :) Nice, nice! Test the volume_slicer example, with latest release, please. That should be a good test. Ga?l From mjldehoon at yahoo.com Fri Jul 17 02:32:06 2009 From: mjldehoon at yahoo.com (Michiel de Hoon) Date: Thu, 16 Jul 2009 23:32:06 -0700 (PDT) Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 Message-ID: <261453.2469.qm@web62402.mail.re1.yahoo.com> 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-dev at 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-dev at 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 > > > > > > chunkiness with -wthread. It would be worth exploring > a > > > Cython > > > > > > alternative to see if it is just ctypes and general > Python > > > overhead to > > > > > > blame. > > > > > > > > > > > > -- > > > > > > 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-dev at scipy.org > > > > > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > > > > > > > > -----Inline Attachment Follows----- > > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > -----Inline Attachment Follows----- > > > > > > _______________________________________________ > > > Matplotlib-devel mailing list > > > Matplotlib-devel at lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > > > > > > > > From hans_meine at gmx.net Fri Jul 17 05:24:21 2009 From: hans_meine at gmx.net (Hans Meine) Date: Fri, 17 Jul 2009 11:24:21 +0200 Subject: [IPython-dev] [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc." In-Reply-To: <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> References: <6ce0ac130907161004k1e4eb218gc447f6088c1964a3@mail.gmail.com> <4A5F640D.8060902@stsci.edu> <6ce0ac130907161106h4681146ucd501a94b17cc229@mail.gmail.com> Message-ID: <200907171124.22325.hans_meine@gmx.net> On Thursday 16 July 2009 20:06:24 Brian Granger wrote: > This is especially true of the threaded Shells in IPython. Honestly, even > with thousands of people using it (as is currently the case) it is a time > bomb. We (ipython users) all know that. We are used to have a locked up ipython from time to time (with -q[4]thread, that is as least). Just to let you know that there will be an immediate user-visible improvement from your work. :-) Have a nice day, Hans From ellisonbg.net at gmail.com Fri Jul 17 15:48:33 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 17 Jul 2009 12:48:33 -0700 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <261453.2469.qm@web62402.mail.re1.yahoo.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> Message-ID: <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> 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-dev at 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-dev at 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 > > > > > > > > > > chunkiness with -wthread. It would be worth exploring > > a > > > > > Cython > > > > > > > > > > alternative to see if it is just ctypes and general > > Python > > > > > overhead to > > > > > > > > > > blame. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 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-dev at scipy.org > > > > > > > > > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > > > > > > > > > > > > > > > > > > -----Inline Attachment Follows----- > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > 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 > > > > > -----Inline Attachment Follows----- > > > > > > > > > > _______________________________________________ > > > > > Matplotlib-devel mailing list > > > > > Matplotlib-devel at lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inputhook.py Type: application/octet-stream Size: 5683 bytes Desc: not available URL: From rkern at enthought.com Fri Jul 17 15:57:56 2009 From: rkern at enthought.com (Robert Kern) Date: Fri, 17 Jul 2009 14:57:56 -0500 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> Message-ID: <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> 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 From ondrej at certik.cz Fri Jul 17 16:07:50 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 17 Jul 2009 14:07:50 -0600 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> Message-ID: <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> 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 From ondrej at certik.cz Fri Jul 17 16:13:08 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 17 Jul 2009 14:13:08 -0600 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> Message-ID: <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> 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 From ellisonbg.net at gmail.com Fri Jul 17 16:49:35 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 17 Jul 2009 13:49:35 -0700 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> Message-ID: <6ce0ac130907171349n1d3d3020p8b8fad31c164860@mail.gmail.com> 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Fri Jul 17 17:44:27 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 17 Jul 2009 23:44:27 +0200 Subject: [IPython-dev] [matplotlib-devel] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> Message-ID: <20090717214427.GC2145@phare.normalesup.org> 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 From ellisonbg.net at gmail.com Fri Jul 17 17:54:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 17 Jul 2009 14:54:17 -0700 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <20090717214427.GC2145@phare.normalesup.org> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> Message-ID: <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> 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-Dev at enthought.com > https://mail.enthought.com/mailman/listinfo/enthought-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Fri Jul 17 17:57:26 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Sat, 18 Jul 2009 00:57:26 +0300 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> Message-ID: <46cb515a0907171457i704d25c4ra4a8bd80ea35cc02@mail.gmail.com> 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 From rkern at enthought.com Fri Jul 17 18:01:33 2009 From: rkern at enthought.com (Robert Kern) Date: Fri, 17 Jul 2009 17:01:33 -0500 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> Message-ID: <3d375d730907171501j461ab1e4l67f521094fbd7b93@mail.gmail.com> 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 From ellisonbg.net at gmail.com Fri Jul 17 18:31:18 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 17 Jul 2009 15:31:18 -0700 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <3d375d730907171501j461ab1e4l67f521094fbd7b93@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> <3d375d730907171501j461ab1e4l67f521094fbd7b93@mail.gmail.com> Message-ID: <6ce0ac130907171531i8c79b97r8243f47caaea9226@mail.gmail.com> 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkern at enthought.com Fri Jul 17 18:40:52 2009 From: rkern at enthought.com (Robert Kern) Date: Fri, 17 Jul 2009 17:40:52 -0500 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907171531i8c79b97r8243f47caaea9226@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> <3d375d730907171501j461ab1e4l67f521094fbd7b93@mail.gmail.com> <6ce0ac130907171531i8c79b97r8243f47caaea9226@mail.gmail.com> Message-ID: <3d375d730907171540v6cc833b2o480e5863877eebdf@mail.gmail.com> 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 From ellisonbg.net at gmail.com Fri Jul 17 18:52:04 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 17 Jul 2009 15:52:04 -0700 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <3d375d730907171540v6cc833b2o480e5863877eebdf@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> <3d375d730907171501j461ab1e4l67f521094fbd7b93@mail.gmail.com> <6ce0ac130907171531i8c79b97r8243f47caaea9226@mail.gmail.com> <3d375d730907171540v6cc833b2o480e5863877eebdf@mail.gmail.com> Message-ID: <6ce0ac130907171552s4f3b5ea0s26486a28c2dc074@mail.gmail.com> 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Fri Jul 17 19:15:20 2009 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 17 Jul 2009 17:15:20 -0600 Subject: [IPython-dev] [Enthought-Dev] [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <46cb515a0907171457i704d25c4ra4a8bd80ea35cc02@mail.gmail.com> References: <261453.2469.qm@web62402.mail.re1.yahoo.com> <6ce0ac130907171248o19629fbdqbe230e8672f8dbe3@mail.gmail.com> <3d375d730907171257s1bcd58b3paf18c5bb48fd7b93@mail.gmail.com> <85b5c3130907171307s586ea2abw3d1ded1e0e5f5f4a@mail.gmail.com> <85b5c3130907171313n649dd232qeb44e61954faae64@mail.gmail.com> <20090717214427.GC2145@phare.normalesup.org> <6ce0ac130907171454g5bb203eeofc9285ba6999f9c0@mail.gmail.com> <46cb515a0907171457i704d25c4ra4a8bd80ea35cc02@mail.gmail.com> Message-ID: <85b5c3130907171615j376ffa0erbbf938060b088ff1@mail.gmail.com> 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.000000000 -0600 +++ inputhook.py 2009-07-17 17:12:37.000000000 -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 From ellisonbg.net at gmail.com Mon Jul 20 13:37:58 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 20 Jul 2009 10:37:58 -0700 Subject: [IPython-dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9 In-Reply-To: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> References: <6ce0ac130907161526o11f1e2b3i11e04de5e807367@mail.gmail.com> Message-ID: <6ce0ac130907201037u3f5dc0a6x4e1684c27690d5cd@mail.gmail.com> All, I have an improved prototype of my ctypes based inputhook for wx. In this version I have: * Added and tested Ondrej's patch. It seems to improve both responsiveness and idle GPU load. Thanks Ondrej! * Tested on Win32 * Small changes related to the GIL. Robert and Gael, can you test this version (with approach 3) to see if it is satisfactory in terms of performance AND idle CPU load. On my system MacBook Pro, the idle load is now below 1%. Cheers and thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inputhook.py Type: application/octet-stream Size: 6491 bytes Desc: not available URL: From lists at informa.tiker.net Sat Jul 25 18:25:15 2009 From: lists at informa.tiker.net (Andreas =?utf-8?q?Kl=C3=B6ckner?=) Date: Sat, 25 Jul 2009 15:25:15 -0700 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: References: <200907092001.21523.lists@informa.tiker.net> <200907101025.45512.lists@informa.tiker.net> Message-ID: <200907251525.16483.lists@informa.tiker.net> On Freitag 10 Juli 2009, Robert Kern wrote: > The user explicitly imports it in their ~/.ipython/ipy_user_conf.py . In > ipy_pydbgr.py's case, I presume that Rocky intends us to manually copy that > file into our ~/.ipython/ directories. I prefer to include these in the > package itself so that it is always installed and ready for users to > import. With PuDB 0.92.10, IPython integration is finally a reality. Quoting PuDB's PyPI page: 8< ------------------------------------------------------------------------- PuDB ships with IPython integration. Just stick the line: import pudb.ipython into your $HOME/.ipython/ipy_user_conf.py, and then you may use the magic command: %pudb script.py [args] where [args] represents optional arguments, to launch PuDB from within IPython. 8< ------------------------------------------------------------------------- Happy debugging, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From gokhansever at gmail.com Sat Jul 25 20:29:52 2009 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_SEVER?=) Date: Sat, 25 Jul 2009 19:29:52 -0500 Subject: [IPython-dev] IPython <-> PuDB integration In-Reply-To: <200907251525.16483.lists@informa.tiker.net> References: <200907092001.21523.lists@informa.tiker.net> <200907101025.45512.lists@informa.tiker.net> <200907251525.16483.lists@informa.tiker.net> Message-ID: <49d6b3500907251729x3ae39479ka098d1e6c818bc49@mail.gmail.com> On Sat, Jul 25, 2009 at 5:25 PM, Andreas Kl?ckner wrote: > On Freitag 10 Juli 2009, Robert Kern wrote: > > The user explicitly imports it in their ~/.ipython/ipy_user_conf.py . In > > ipy_pydbgr.py's case, I presume that Rocky intends us to manually copy > that > > file into our ~/.ipython/ directories. I prefer to include these in the > > package itself so that it is always installed and ready for users to > > import. > > With PuDB 0.92.10, IPython integration is finally a reality. Quoting PuDB's > PyPI page: > > 8< > ------------------------------------------------------------------------- > PuDB ships with IPython integration. Just stick the line: > > import pudb.ipython > > into your $HOME/.ipython/ipy_user_conf.py, and then you may use the magic > command: > > %pudb script.py [args] > > where [args] represents optional arguments, to launch PuDB from within > IPython. > 8< > ------------------------------------------------------------------------- > > Happy debugging, > Andreas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > Thanks Andreas for the implementation of the IPy integration. It works happily with the latest IPy chech-out from the launchpad repository. -- G?khan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Jul 28 04:58:04 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 01:58:04 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> Message-ID: On Mon, Jul 27, 2009 at 12:40 PM, Brian Granger wrote: > Hi, > > I am currently refactoring the IPython configuration system.? I thought this > would be a fairly straightforward task to move IPython to a single unified > config system with a new config file format.? But, it is turning out to be > quite massive undertaking.? I wanted to share some of my notes at this point > to generate discussion about this... > > * Currently, we read assemble the main config objects in ipmaker.py and save > them as IP.rc which is a Struct.? From then on, IPython code can reference > the config variables using a notation like IP.rc.autocall, etc.? The logic > in ipmaker is super-messy and is one of the main config-y-things that needs > refactoring. Sorry you ended up having to see that :) Indeed, that code is absolutely heinous, and the reasons are purely historical artifact. IPython started life as my personal $PYTHONSTARTUP file a few days after I'd begun to learn to use python, so initially it was just one long script to load and configure a bunch of tweaks to sys.displayhook. When it became 'a program' I just copied that mess over, indented it 4 spaces and gave it a name. Thus was ipmaker born unto the world :) But eventually we had to do something about this, and now is the time. I'm more than happy to help shoulder a bit of the load. > * But, this is not merely a configuration system, it is also a runtime > attribute system.? By this, I mean that the values in IP.rc are changed at > runtime by various parts of the code to change the behavior of the running > IPython.? Some attributes (like autocall) can be changed by modifying IP.rc > at runtime and other's (the prompts) can't.? What I mean by "can't" is that > you can change IP.rc, but IPython's behavior won't change.? An example of > this is that to get the prompts to change at runtime you need to? hack into > IP.outputcache.prompt1.? In other cases (like autocall), the relevant > IPython code always looks at IP.rc.autocall, so if it is changed, IPython's > behavior changes. > > Anyone who is paying attention at this point will think... "ahh, observers, > notification, python", this sounds like enthought.traits!!!? Yes, traits > would definitely be one solution for dealing with this issue.? But, we > *really* want IPython to run on IronPython and Jython, so having traits as a > new dependency (it has a ~5000 line C-module) won't work.? The only way we > could use traits is if someone implemented a pure Python version of traits > (or a suitable subset). For the record (you know this already) we're in full agreement here. For example, as of a few days ago apparently ipython runs in IronPython: http://lists.ironpython.com/pipermail/users-ironpython.com/2009-June/010590.html Obviously this means just the interactive interpreter, not all the kernel code, but this is still great news. It would be crazy to kill this in our next version by introducing a dependency like Traits, as much as it can have other benefits. One thing we should strive for, is to remove the need (as much as possible) for any special behavior with options, like it exists today. Basically if something lives in the runtime config holders, then it should be OK to set its value at runtime and things should behave normally and honor this change. If something can't be simply changed like that (say because it really was an argument to some function that has already been called and is now gone), then it should NOT be visible as a runtime option. We can then put in specific calls to set more complex behavior at runtime when needed, but such a design decision would at least allow us to decouple the mess you've identified of having a values holder (the rc struct) where some things can be touched at runtime and others not. > * We need to move away from the model of "IP holds the config for > everything" to each object holding and loading its own config data. > > * We need to de-couple configuration (the behavior of objects upon creation) > from notification/observation (how objects work together at runtime). Broadly speaking I agree, with some minor adjustments. See below. > With these things in mind, here is what I am thinking... > > All IPython classes will inherit from a number of base classes that provide > the basic features we need also classes to have: > > * Configurable = an object that can be configured from the config files, > command line, and by passing in options.? Basically, this is an object that > has a super fancy __init__ logic (possibly not in __init__).? Each class > will declare where its default config file lives, what its command line > options are, etc. > > * NotificationSource = an object that can notify other objects when its > attributes change.? This is basically like a HasTraits. > > Having these 2 different subclasses should de-couple the question of > configuration from the question of notification/runtime attributes. > > Thoughts?? Ideas? Feedback? I'm not 100% sure that we want a base class that is at the root of the object hierarchy to provide management of configuration and notification. But I think both ideas are going in the right direction, so here's a possible twist on them (I'm tired so this may be well off-base, we can and should iterate on it): - Configurable would be used to define configuration objects, but these would be held as attributes of the various 'user-facing' objects. Basically I'm thinking of a 'has a' relationship rather than an 'is a' one, to reduce couplings. - Objects that need it will use Configurable, but in practice the main application 'entry points' will probably use more than one object with a configuration instance. For these, it should be possible to compose/aggregate config instances easily. Something like: s = IPythonShell() s has s.kernel, s.frontend components. Each of these has a config instance above, but the user should only need to use s.config directly, which will hold the configuration of all the subcomponents. I need to crash now though, I'll try to think a little more about this tomorrow and we'll continue to iterate... Thanks for tackling this, I'm really happy about it (long needed)! f From vivainio at gmail.com Tue Jul 28 05:15:13 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 05:15:13 -0400 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> Message-ID: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> On Mon, Jul 27, 2009 at 3:40 PM, Brian Granger wrote: > IPython. Some attributes (like autocall) can be changed by modifying IP.rc > at runtime and other's (the prompts) can't. What I mean by "can't" is that > you can change IP.rc, but IPython's behavior won't change. An example of > this is that to get the prompts to change at runtime you need to hack into > IP.outputcache.prompt1. In other cases (like autocall), the relevant > IPython code always looks at IP.rc.autocall, so if it is changed, IPython's > behavior changes. Many of these problems could be fixed by fixing stuff like prompts to actually look at the config variable every time. Since it needs some "computation" every time, you can remember the value of previous invocation and do the calculation only if it has changed. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Tue Jul 28 12:32:37 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:32:37 -0700 Subject: [IPython-dev] Question about ipykit.py Message-ID: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Hi, During my module reorganization, I have been trying to cleanup our top-level directory (the one with setup.py in it). One file that I don't know what to do with is ipykit.py. Questions? * Is this still being used by anyone? If not, can we delete it? * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Tue Jul 28 12:32:37 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:32:37 -0700 Subject: [IPython-dev] Question about ipykit.py Message-ID: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Hi, During my module reorganization, I have been trying to cleanup our top-level directory (the one with setup.py in it). One file that I don't know what to do with is ipykit.py. Questions? * Is this still being used by anyone? If not, can we delete it? * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Tue Jul 28 12:39:15 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 19:39:15 +0300 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Message-ID: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> On Tue, Jul 28, 2009 at 7:32 PM, Brian Granger wrote: > During my module reorganization, I have been trying to cleanup our top-level > directory (the one with setup.py in it).? One file that I don't know what to > do with is ipykit.py.? Questions? > > * Is this still being used by anyone?? If not, can we delete it? > * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? It's my py2exe'd IPython (to have an IPython that can be moved around on usb stick). I don't use Windows anymore, so maintenance prospects of that feature seem rather slim. You can remove it. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Tue Jul 28 12:39:15 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 19:39:15 +0300 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Message-ID: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> On Tue, Jul 28, 2009 at 7:32 PM, Brian Granger wrote: > During my module reorganization, I have been trying to cleanup our top-level > directory (the one with setup.py in it).? One file that I don't know what to > do with is ipykit.py.? Questions? > > * Is this still being used by anyone?? If not, can we delete it? > * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? It's my py2exe'd IPython (to have an IPython that can be moved around on usb stick). I don't use Windows anymore, so maintenance prospects of that feature seem rather slim. You can remove it. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Tue Jul 28 12:58:49 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:58:49 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> Message-ID: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> > It's my py2exe'd IPython (to have an IPython that can be moved around > on usb stick). > > I don't use Windows anymore, so maintenance prospects of that feature > seem rather slim. You can remove it. > OK, thanks, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Tue Jul 28 12:58:49 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:58:49 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> Message-ID: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> > It's my py2exe'd IPython (to have an IPython that can be moved around > on usb stick). > > I don't use Windows anymore, so maintenance prospects of that feature > seem rather slim. You can remove it. > OK, thanks, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Jul 28 14:50:51 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 11:50:51 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... Message-ID: Hi folks, after a real-life provoked long silence, we have some good news to report... You may have seen Brian's recent refactoring posts and excellent work. Thanks to IPython's importance for one of our projects at work, NIPY (http://neuroimaging.scipy.org), we've been able to secure some funding so that Brian can spend a concentrated amount of time on this critically needed refactoring work. This is in a sense the logical outcome of the ipython1/0 merge, and it will let us revitalize the project in a number of useful directions. I'd like to thank the NIPY project for this support, since for a long time we've needed this kind of solid block of time to achieve such a restructuring but had never been able to support it. Which brings us to the next point... A few months ago we did a bunch of work on cleaning up the code we had to push 0.10 out, and then life got messy and the actual release never happened. Well, now we should really try to finish up, especially so that the code that has been written can be merged as soon as possible for Brian to push the refactoring into trunk. Brian's refactoring is massive and touches everything, so initially there is going to be some breakage (we'll do our best to minimize it and Brian is super careful, but some pain will no doubt occur). For this reason, and to prevent stalling Brian's advance, I'd like to wrap up the 0.10 release work as soon as possible. Status: - Branch reviews: https://code.launchpad.net/ipython/+activereviews * Two of these (the approved ones) I will merge soon if nobody objects in the next few hours. * Ondrej's embedding fix is set for 0.11, so it can be merged after Brian's code is in (I want a bit of tuning on the interface there, and the change is highly localized, so this won't be a problem). * Brian's is the refactoring itself, so it's not for 0.10 * We have 3 remaining ones, one by Tom and two by Ville, that have been awaiting small fixes for a while. On the 3 last ones, it seemed Tom was having some problems cleaning up the commits after conflict markers went in. I'll see if I can make a cleaned-up version of that, since the actual code is pretty small. Ville's have both pending review comments from April 15. A lot of that is probably fairly easy to finish up, Ville, do you think you can address them? - Bugs: we only have four bugs explicitly marked as critical for 0.10: https://bugs.launchpad.net/ipython/0.10/+bugs and 3 of them have had fixes committed. I have a fix for the remaining one in my local tree, that I'll push for review once I can test it better (I'm having some weirdo nose issues right now on my desktop). So from a pending branches/bugs perspective, I think we're very very close. Given this, I'd like to consider the code frozen as of now, unless someone strongly objects, and leave the next few days to sort out the remaining work on the one bug and the three branches. I'm going to work on this today to try to help as much as I can. If all goes well, I'd like to finish merging by Friday or Saturday. That will then allow us to review Brian's work to merge it into trunk, and trunk will then have diverged from the 0.10 'old' series for good. Any last-minute fixes for the actual 0.10 release will be only applied on the 0.10 series branch and backported manually (by me) if necessary to trunk. The trunk would then be the development for the next release with the new API. I'm actually thinking that we should name the trunk version 0.90 instead of 0.11, to emphasize the API jump: 0.10 has the old APIs, and 0.90 will be the start of the new APIs, targetting an actual 1.0 release on the cleaned up and refactored codebase. Any comments on this plan? Cheers, f From fperez.net at gmail.com Tue Jul 28 15:02:55 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 12:02:55 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> Message-ID: On Tue, Jul 28, 2009 at 2:15 AM, Ville M. Vainio wrote: > Many of these problems could be fixed by fixing stuff like prompts to > actually look at the config variable every time. Since it needs some > "computation" every time, you can remember the value of previous > invocation and do the calculation only if it has changed. Yes, that is indeed part of what needs to be done. In the current code, I never gave much serious thought to these matters (I just wrote it 'on the go'), but the problem is now much clearer. Basically we need to be strict about: - options/config objects that can be changed at runtime should always be safe for modification. Basically if you can set a value, it's because anything that depends on it will behave OK with the modification. - Any runtime changes that can't be done by modifying a simple config variable, if really needed, will require a dedicated function to enact the change, rather than trying to set a variable. With this policy in place it would thus be safe, by definition, to manipulate config objects at runtime. Cheers, f From fperez.net at gmail.com Tue Jul 28 15:39:31 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 12:39:31 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner (listsin) wrote: >> You may have seen Brian's recent refactoring posts and excellent work. >> Thanks to IPython's importance for one of our projects at work, NIPY >> (http://neuroimaging.scipy.org), > > Site seems to be down... Really? I just clicked and it worked fine from here. Can you retry? If it fails again, where geographically are you accessing it from? I can report the outage to the admin with some more info, but it's certainly working from here... Cheers, f From robert.kern at gmail.com Tue Jul 28 15:46:47 2009 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 28 Jul 2009 14:46:47 -0500 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: On 2009-07-28 14:39, Fernando Perez wrote: > On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner > (listsin) wrote: >>> You may have seen Brian's recent refactoring posts and excellent work. >>> Thanks to IPython's importance for one of our projects at work, NIPY >>> (http://neuroimaging.scipy.org), >> Site seems to be down... > > Really? I just clicked and it worked fine from here. Can you retry? > If it fails again, where geographically are you accessing it from? I > can report the outage to the admin with some more info, but it's > certainly working from here... It was down but is now back up. -- 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 From ellisonbg.net at gmail.com Tue Jul 28 16:28:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 13:28:17 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> Message-ID: <6ce0ac130907281328s3af0bbc9waf0be1ec29ce9ac3@mail.gmail.com> > IPython. Some attributes (like autocall) can be changed by modifying > IP.rc > > at runtime and other's (the prompts) can't. What I mean by "can't" is > that > > you can change IP.rc, but IPython's behavior won't change. An example of > > this is that to get the prompts to change at runtime you need to hack > into > > IP.outputcache.prompt1. In other cases (like autocall), the relevant > > IPython code always looks at IP.rc.autocall, so if it is changed, > IPython's > > behavior changes. > > Many of these problems could be fixed by fixing stuff like prompts to > actually look at the config variable every time. Since it needs some > "computation" every time, you can remember the value of previous > invocation and do the calculation only if it has changed. > Yes, definitely. However, the current approach of having IP.rc hold the runtime value for *everything* means that everything is tightly coupled to IP. That is what we have to break. My vision is that all objects will hold their own runtime state. Thus the prompt objects will hold the values of the prompt strings. We will then have an API that allows other parts of the code base to modify those values. But all of that will be completey independent of IP. Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From listsin at integrateddevcorp.com Tue Jul 28 17:06:11 2009 From: listsin at integrateddevcorp.com (Steve Steiner (listsin)) Date: Tue, 28 Jul 2009 17:06:11 -0400 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: <24FD0773-EC87-44E3-9077-DC79BC00CD4C@integrateddevcorp.com> scipy.org: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root at enthought.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. S On Jul 28, 2009, at 3:46 PM, Robert Kern wrote: > On 2009-07-28 14:39, Fernando Perez wrote: >> On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner >> (listsin) wrote: >>>> You may have seen Brian's recent refactoring posts and excellent >>>> work. >>>> Thanks to IPython's importance for one of our projects at work, >>>> NIPY >>>> (http://neuroimaging.scipy.org), >>> Site seems to be down... >> >> Really? I just clicked and it worked fine from here. Can you retry? >> If it fails again, where geographically are you accessing it from? I >> can report the outage to the admin with some more info, but it's >> certainly working from here... > > It was down but is now back up. > > -- > 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From robert.kern at gmail.com Tue Jul 28 18:23:38 2009 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 28 Jul 2009 17:23:38 -0500 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: <24FD0773-EC87-44E3-9077-DC79BC00CD4C@integrateddevcorp.com> References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> <24FD0773-EC87-44E3-9077-DC79BC00CD4C@integrateddevcorp.com> Message-ID: On 2009-07-28 16:06, Steve Steiner (listsin) wrote: > scipy.org: > > Internal Server Error It went down again but is now back up. -- 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 From fperez.net at gmail.com Wed Jul 29 05:35:07 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 Jul 2009 02:35:07 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: Message-ID: Howdy, On Tue, Jul 28, 2009 at 11:50 AM, Fernando Perez wrote: > Status: > > - Branch reviews: https://code.launchpad.net/ipython/+activereviews > > ?* Two of these (the approved ones) I will merge soon if nobody > objects in the next few hours. I'll try to do this tomorrow. But I now have mine up for review, that contains... > - Bugs: we only have four bugs explicitly marked as critical for 0.10: > > https://bugs.launchpad.net/ipython/0.10/+bugs > > and 3 of them have had fixes committed. ?I have a fix for the > remaining one in my local tree, that I'll push for review once I can > test it better (I'm having some weirdo nose issues right now on my > desktop). ... the fix for that last bug, as well as a number of other nasty testing problem fixes. I've run the full 'iptest' suite on both python 2.5 and 2.6 Ubuntu (8.10 and 9.04) and now on both systems it passes cleanly. I did NOT add any new functionality, the above branch is strictly bug and test fixing. Another pair of eyes would be very welcome. I'll try to finish up the rest of what we have on the plate for 0.10 to go out then... Cheers, f From ellisonbg.net at gmail.com Wed Jul 29 12:57:45 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 09:57:45 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: Message-ID: <6ce0ac130907290957v5520222fs51b8a25ae0e8fc10@mail.gmail.com> I will review your branch today. Cheers, Brian On Wed, Jul 29, 2009 at 2:35 AM, Fernando Perez wrote: > Howdy, > > On Tue, Jul 28, 2009 at 11:50 AM, Fernando Perez > wrote: > > Status: > > > > - Branch reviews: https://code.launchpad.net/ipython/+activereviews > > > > * Two of these (the approved ones) I will merge soon if nobody > > objects in the next few hours. > > I'll try to do this tomorrow. > > But I now have mine up for review, that contains... > > > - Bugs: we only have four bugs explicitly marked as critical for 0.10: > > > > https://bugs.launchpad.net/ipython/0.10/+bugs > > > > and 3 of them have had fixes committed. I have a fix for the > > remaining one in my local tree, that I'll push for review once I can > > test it better (I'm having some weirdo nose issues right now on my > > desktop). > > ... the fix for that last bug, as well as a number of other nasty > testing problem fixes. I've run the full 'iptest' suite on both > python 2.5 and 2.6 Ubuntu (8.10 and 9.04) and now on both systems it > passes cleanly. > > I did NOT add any new functionality, the above branch is strictly bug > and test fixing. Another pair of eyes would be very welcome. > > I'll try to finish up the rest of what we have on the plate for 0.10 > to go out then... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 13:26:48 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 10:26:48 -0700 Subject: [IPython-dev] A few more things for 0.10 Message-ID: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> Fernando, There are a few more bugs marked Critical that I think we should solve for 0.10: https://bugs.launchpad.net/ipython/+bug/291143 https://bugs.launchpad.net/ipython/+bug/368719 Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 13:26:48 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 10:26:48 -0700 Subject: [IPython-dev] A few more things for 0.10 Message-ID: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> Fernando, There are a few more bugs marked Critical that I think we should solve for 0.10: https://bugs.launchpad.net/ipython/+bug/291143 https://bugs.launchpad.net/ipython/+bug/368719 Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jul 29 13:59:07 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 Jul 2009 10:59:07 -0700 Subject: [IPython-dev] A few more things for 0.10 In-Reply-To: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> References: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 10:26 AM, Brian Granger wrote: > Fernando, > > There are a few more bugs marked Critical that I think we should solve for > 0.10: > > https://bugs.launchpad.net/ipython/+bug/291143 > https://bugs.launchpad.net/ipython/+bug/368719 Got them, thanks. I'll try to finish them ASAP... f From fperez.net at gmail.com Wed Jul 29 13:59:07 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 29 Jul 2009 10:59:07 -0700 Subject: [IPython-dev] A few more things for 0.10 In-Reply-To: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> References: <6ce0ac130907291026x2f067229wd6ec165ba2a07d85@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 10:26 AM, Brian Granger wrote: > Fernando, > > There are a few more bugs marked Critical that I think we should solve for > 0.10: > > https://bugs.launchpad.net/ipython/+bug/291143 > https://bugs.launchpad.net/ipython/+bug/368719 Got them, thanks. I'll try to finish them ASAP... f From ellisonbg.net at gmail.com Wed Jul 29 14:17:36 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 11:17:36 -0700 Subject: [IPython-dev] App's, Components and refactoring Message-ID: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Hi, I have been banging my head on the IPython refactoring this week. Ouch. I am specifically thinking about the config system, IP.rc and ipmaker stuff. Yesterday, Fernando and I talked about some of my ideas and we tentatively settled on some abstractions that I think will greatly help in the refactoring. I wanted to sketch these out to get feedback from folks. Here are the main abstractions: 1. Config objects. Bags of configuration variables that can be read from file or the command line. 2. Component. An object that be configured and has a runtime api. Just about everything in IPython will be a component. 1. App - a top-level IPython program like ipython, ipythonx, ipcluster, ipengine, ipcontroller. The job of an App will be to assemble and merge all relevant config objects and then instantiate and configure components. How do components get created and configured? c = MyComponent() # this build it with class defaults c.configure(config) # The App or parent component passes the config to the object to the component to override the defaults c.freeze_config() # This tells the component that config is done and that it should complete any remaining init related things. >From then on, the component ignore the config info and instead relies on its runtime data. Each component will have a Struct-like object that contains the runtime data named rc = 'runtime configuration'. Notice, this is extremely similar to the existing design on IP. BUT, it is very different because each component will hold its own runtime attributes (IP won't hold many at all). The golden rule of the runtime attributes is this: if you can change them, IPython's behavior *must* change appropriately. Components will have some sort of registry and querying system that will allow different parts of IPython to get the runtime api for other components. This will also be completely independent of IP itself. It will look something like this: rc = Component.find_component_runtime('prompt1', Prompt) # get the runtime api for component named 'prompt1' that is an instance of Prompt Once you have one of these runtime objects you can do a number of things: * read its attributes (rc.prompt_string) * write its attributes * setup notifications rc.add_notification('prompt_string', callable) # callable is called if prompt_string changes. If you are thinking these runtime objects look a lot like enthought.traits, you are right. While we can't use traits, the design of these objects will be very much traits inspired. It will be up to each component to pass the config object it gets onto its children (by calling their configure methods). Thus the config objects will propagate down the component graph as it is created. There are still many things to work out. After sleeping on it, I have some questions... In many cases, components will have not only attributes that can be set/get by others, but also methods. Where to we put these methods? It makes the most sense to put them on the Components themselves. This makes me think that the component/runtime-api relationship should be a "is-a" not a "has-a". The "is-a" approach is more of what Traits uses. Initially, our instinct was to use "has-a", to keep the component namespace clean. But, now I am almost thinking that when other objects get a "runtime api" for a component, what they want is the component itself. Here is what the "is-a" looks like: c = Component.find_component('shell', InteractiveShell) c.autocall = False c.runlines(...) And here is the "has-a": c = Component.find_component('shell', InteractiveShell) c.rc.autocall = False c.runlines(...) Or we could put the runtime api entirely on the rc attribute: rc = Component.find_runtime_api('shell',InteractiveShell) rc.autocall = False c.runlines(...) Here is a short argument against having a separate runtime (I am arguing for the "is-a" approach). This (the 'has-a') is what we use with InteractiveShell and ipapi. ipapi is a thin wrapper around InteractiveShell. The problem with this is that you can end up going in circles. When do you call ipapi and when do you just call InteractiveShell methods? It gets darned confusing. This confusion shows up in silly things like methods of InteractiveShell using ipapi rather than just calling its own methods! I think this is an abuse of OO design. Objects themselves have public APIs. You don't need the extra indirection of a public API that wraps that public API. I think the original reason we came up with ipapi is that InteractiveShell didn't have a clean public api. But, once that is fixed, I think ipapi should go away. Thoughts? Feeback? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 14:17:36 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 11:17:36 -0700 Subject: [IPython-dev] App's, Components and refactoring Message-ID: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Hi, I have been banging my head on the IPython refactoring this week. Ouch. I am specifically thinking about the config system, IP.rc and ipmaker stuff. Yesterday, Fernando and I talked about some of my ideas and we tentatively settled on some abstractions that I think will greatly help in the refactoring. I wanted to sketch these out to get feedback from folks. Here are the main abstractions: 1. Config objects. Bags of configuration variables that can be read from file or the command line. 2. Component. An object that be configured and has a runtime api. Just about everything in IPython will be a component. 1. App - a top-level IPython program like ipython, ipythonx, ipcluster, ipengine, ipcontroller. The job of an App will be to assemble and merge all relevant config objects and then instantiate and configure components. How do components get created and configured? c = MyComponent() # this build it with class defaults c.configure(config) # The App or parent component passes the config to the object to the component to override the defaults c.freeze_config() # This tells the component that config is done and that it should complete any remaining init related things. >From then on, the component ignore the config info and instead relies on its runtime data. Each component will have a Struct-like object that contains the runtime data named rc = 'runtime configuration'. Notice, this is extremely similar to the existing design on IP. BUT, it is very different because each component will hold its own runtime attributes (IP won't hold many at all). The golden rule of the runtime attributes is this: if you can change them, IPython's behavior *must* change appropriately. Components will have some sort of registry and querying system that will allow different parts of IPython to get the runtime api for other components. This will also be completely independent of IP itself. It will look something like this: rc = Component.find_component_runtime('prompt1', Prompt) # get the runtime api for component named 'prompt1' that is an instance of Prompt Once you have one of these runtime objects you can do a number of things: * read its attributes (rc.prompt_string) * write its attributes * setup notifications rc.add_notification('prompt_string', callable) # callable is called if prompt_string changes. If you are thinking these runtime objects look a lot like enthought.traits, you are right. While we can't use traits, the design of these objects will be very much traits inspired. It will be up to each component to pass the config object it gets onto its children (by calling their configure methods). Thus the config objects will propagate down the component graph as it is created. There are still many things to work out. After sleeping on it, I have some questions... In many cases, components will have not only attributes that can be set/get by others, but also methods. Where to we put these methods? It makes the most sense to put them on the Components themselves. This makes me think that the component/runtime-api relationship should be a "is-a" not a "has-a". The "is-a" approach is more of what Traits uses. Initially, our instinct was to use "has-a", to keep the component namespace clean. But, now I am almost thinking that when other objects get a "runtime api" for a component, what they want is the component itself. Here is what the "is-a" looks like: c = Component.find_component('shell', InteractiveShell) c.autocall = False c.runlines(...) And here is the "has-a": c = Component.find_component('shell', InteractiveShell) c.rc.autocall = False c.runlines(...) Or we could put the runtime api entirely on the rc attribute: rc = Component.find_runtime_api('shell',InteractiveShell) rc.autocall = False c.runlines(...) Here is a short argument against having a separate runtime (I am arguing for the "is-a" approach). This (the 'has-a') is what we use with InteractiveShell and ipapi. ipapi is a thin wrapper around InteractiveShell. The problem with this is that you can end up going in circles. When do you call ipapi and when do you just call InteractiveShell methods? It gets darned confusing. This confusion shows up in silly things like methods of InteractiveShell using ipapi rather than just calling its own methods! I think this is an abuse of OO design. Objects themselves have public APIs. You don't need the extra indirection of a public API that wraps that public API. I think the original reason we came up with ipapi is that InteractiveShell didn't have a clean public api. But, once that is fixed, I think ipapi should go away. Thoughts? Feeback? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Wed Jul 29 15:21:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 15:21:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: Hi Brian, On Wed, Jul 29, 2009 at 2:17 PM, Brian Granger wrote: > Hi, > > I have been banging my head on the IPython refactoring this week.? Ouch.? I > am specifically thinking about the config system, IP.rc and ipmaker stuff. > > Yesterday, Fernando and I talked about some of my ideas and we tentatively > settled on some abstractions that I think will greatly help in the > refactoring.? I wanted to sketch these out to get feedback from folks. > > Here are the main abstractions: > > 1.? Config objects.? Bags of configuration variables that can be read from > file or the command line. > 2.? Component.? An object that be configured and has a runtime api.? Just > about everything in IPython will be a component. > 1.? App - a top-level IPython program like ipython, ipythonx, ipcluster, > ipengine, ipcontroller. > > The job of an App will be to assemble and merge all relevant config objects > and then instantiate and configure components.? How do components get > created and configured? > > c = MyComponent()? # this build it with class defaults > c.configure(config) # The App or parent component passes the config to the > object to the component to override the defaults > c.freeze_config() # This tells the component that config is done and that it > should complete any remaining init related things. This seems a bit awkward to me. Why not do: c = MyComponent(..., config=(config1,config2,...)) and have the component complete any remaining init related things at the end of __init__? > From then on, the component ignore the config info and instead relies on its > runtime data.? Each component will have a Struct-like object that contains > the runtime data named rc = 'runtime configuration'.? Notice, this is > extremely similar to the existing design on IP.? BUT, it is very different > because each component will hold its own runtime attributes (IP won't hold > many at all).? The golden rule of the runtime attributes is this: if you can > change them, IPython's behavior *must* change appropriately. I guess I don't understand the motivation for this extra degree of separation, why are run-time attributes held by an objects rc struct instead of by the object itself? It seems more natural to use properties. > Components will have some sort of registry and querying system that will > allow different parts of IPython to get the runtime api for other > components.? This will also be completely independent of IP itself.? It will > look something like this: > > rc = Component.find_component_runtime('prompt1', Prompt) # get the runtime > api for component named 'prompt1' that is an instance of Prompt > > Once you have one of these runtime objects you can do a number of things: > > * read its attributes (rc.prompt_string) > * write its attributes > * setup notifications rc.add_notification('prompt_string', callable) # > callable is called if prompt_string changes. I think you could maybe do all of this with properties. Notifications could be handled with a decorator. > If you are thinking these runtime objects look a lot like enthought.traits, > you are right.? While we can't use traits, the design of these objects will > be very much traits inspired. > > It will be up to each component to pass the config object it gets onto its > children (by calling their configure methods).? Thus the config objects will > propagate down the component graph as it is created. > > There are still many things to work out.? After sleeping on it, I have some > questions... > > In many cases, components will have not only attributes that can be set/get > by others, but also methods.? Where to we put these methods?? It makes the > most sense to put them on the Components themselves.? This makes me think > that the component/runtime-api relationship should be a "is-a" not a > "has-a".? The "is-a" approach is more of what Traits uses.? Initially, our > instinct was to use "has-a", to keep the component namespace clean.? But, > now I am almost thinking that when other objects get a "runtime api" for a > component, what they want is the component itself. I think this is related to my comments above. > Here is what the "is-a" looks like: > > c = Component.find_component('shell', InteractiveShell) > c.autocall = False > c.runlines(...) > > And here is the "has-a": > > c = Component.find_component('shell', InteractiveShell) > c.rc.autocall = False > c.runlines(...) > > Or we could put the runtime api entirely on the rc attribute: > > rc = Component.find_runtime_api('shell',InteractiveShell) > rc.autocall = False > c.runlines(...) > > Here is a short argument against having a separate runtime (I am arguing for > the "is-a" approach).? This (the 'has-a') is what we use with > InteractiveShell and ipapi.? ipapi is a thin wrapper around > InteractiveShell.? The problem with this is that you can end up going in > circles.? When do you call ipapi and when do you just call InteractiveShell > methods?? It gets darned confusing.? This confusion shows up in silly things > like methods of InteractiveShell using ipapi rather than just calling its > own methods!? I think this is an abuse of OO design.? Objects themselves > have public APIs.? You don't need the extra indirection of a public API that > wraps that public API.? I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api.? But, once that is > fixed, I think ipapi should go away. > > Thoughts?? Feeback? I agree. It would be confusing trying to figure out whether the desired attribute or method is found on the component itself or on the rc attr. Maybe I'm just not familiar with any projects that do it this way, so the is-a paradigm feels more natural. Darren From dsdale24 at gmail.com Wed Jul 29 15:21:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 15:21:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: Hi Brian, On Wed, Jul 29, 2009 at 2:17 PM, Brian Granger wrote: > Hi, > > I have been banging my head on the IPython refactoring this week.? Ouch.? I > am specifically thinking about the config system, IP.rc and ipmaker stuff. > > Yesterday, Fernando and I talked about some of my ideas and we tentatively > settled on some abstractions that I think will greatly help in the > refactoring.? I wanted to sketch these out to get feedback from folks. > > Here are the main abstractions: > > 1.? Config objects.? Bags of configuration variables that can be read from > file or the command line. > 2.? Component.? An object that be configured and has a runtime api.? Just > about everything in IPython will be a component. > 1.? App - a top-level IPython program like ipython, ipythonx, ipcluster, > ipengine, ipcontroller. > > The job of an App will be to assemble and merge all relevant config objects > and then instantiate and configure components.? How do components get > created and configured? > > c = MyComponent()? # this build it with class defaults > c.configure(config) # The App or parent component passes the config to the > object to the component to override the defaults > c.freeze_config() # This tells the component that config is done and that it > should complete any remaining init related things. This seems a bit awkward to me. Why not do: c = MyComponent(..., config=(config1,config2,...)) and have the component complete any remaining init related things at the end of __init__? > From then on, the component ignore the config info and instead relies on its > runtime data.? Each component will have a Struct-like object that contains > the runtime data named rc = 'runtime configuration'.? Notice, this is > extremely similar to the existing design on IP.? BUT, it is very different > because each component will hold its own runtime attributes (IP won't hold > many at all).? The golden rule of the runtime attributes is this: if you can > change them, IPython's behavior *must* change appropriately. I guess I don't understand the motivation for this extra degree of separation, why are run-time attributes held by an objects rc struct instead of by the object itself? It seems more natural to use properties. > Components will have some sort of registry and querying system that will > allow different parts of IPython to get the runtime api for other > components.? This will also be completely independent of IP itself.? It will > look something like this: > > rc = Component.find_component_runtime('prompt1', Prompt) # get the runtime > api for component named 'prompt1' that is an instance of Prompt > > Once you have one of these runtime objects you can do a number of things: > > * read its attributes (rc.prompt_string) > * write its attributes > * setup notifications rc.add_notification('prompt_string', callable) # > callable is called if prompt_string changes. I think you could maybe do all of this with properties. Notifications could be handled with a decorator. > If you are thinking these runtime objects look a lot like enthought.traits, > you are right.? While we can't use traits, the design of these objects will > be very much traits inspired. > > It will be up to each component to pass the config object it gets onto its > children (by calling their configure methods).? Thus the config objects will > propagate down the component graph as it is created. > > There are still many things to work out.? After sleeping on it, I have some > questions... > > In many cases, components will have not only attributes that can be set/get > by others, but also methods.? Where to we put these methods?? It makes the > most sense to put them on the Components themselves.? This makes me think > that the component/runtime-api relationship should be a "is-a" not a > "has-a".? The "is-a" approach is more of what Traits uses.? Initially, our > instinct was to use "has-a", to keep the component namespace clean.? But, > now I am almost thinking that when other objects get a "runtime api" for a > component, what they want is the component itself. I think this is related to my comments above. > Here is what the "is-a" looks like: > > c = Component.find_component('shell', InteractiveShell) > c.autocall = False > c.runlines(...) > > And here is the "has-a": > > c = Component.find_component('shell', InteractiveShell) > c.rc.autocall = False > c.runlines(...) > > Or we could put the runtime api entirely on the rc attribute: > > rc = Component.find_runtime_api('shell',InteractiveShell) > rc.autocall = False > c.runlines(...) > > Here is a short argument against having a separate runtime (I am arguing for > the "is-a" approach).? This (the 'has-a') is what we use with > InteractiveShell and ipapi.? ipapi is a thin wrapper around > InteractiveShell.? The problem with this is that you can end up going in > circles.? When do you call ipapi and when do you just call InteractiveShell > methods?? It gets darned confusing.? This confusion shows up in silly things > like methods of InteractiveShell using ipapi rather than just calling its > own methods!? I think this is an abuse of OO design.? Objects themselves > have public APIs.? You don't need the extra indirection of a public API that > wraps that public API.? I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api.? But, once that is > fixed, I think ipapi should go away. > > Thoughts?? Feeback? I agree. It would be confusing trying to figure out whether the desired attribute or method is found on the component itself or on the rc attr. Maybe I'm just not familiar with any projects that do it this way, so the is-a paradigm feels more natural. Darren From ellisonbg.net at gmail.com Wed Jul 29 15:36:14 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 12:36:14 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Darren, Thanks for comments! > c = MyComponent() # this build it with class defaults > > c.configure(config) # The App or parent component passes the config to > the > > object to the component to override the defaults > > c.freeze_config() # This tells the component that config is done and that > it > > should complete any remaining init related things. > > This seems a bit awkward to me. Why not do: > > c = MyComponent(..., config=(config1,config2,...)) > > and have the component complete any remaining init related things at > the end of __init__? > Very good point. For the most part, I think we could do this. But there are two usage patterns that we sometimes run into that might require a separate call to configure: * There are a few cases where we use adaptors, which requires a single argument __init__ method that takes the object to be adapted. In this case, we can't pass additional things into the __init__ method. * Currently we sometimes create an object with a default config, then use it a bit and *then* later finish passing it its config information. But, I don't like this usage pattern so we could probably get rid of it. Overall I agree with you that just using the __init__ method is cleaner though. I guess I don't understand the motivation for this extra degree of > separation, why are run-time attributes held by an objects rc struct > instead of by the object itself? It seems more natural to use > properties. > I think the main motivation is to have runtime objects that have very small and clean namespaces. The classic example of the "is-a" approach is traits. Just tab complete on a HasTraits instance and you will see what I mean about a large a non-clean namespace. But, I agree with you. We are not inheriting from HasTraits and there is no reason we can't keep the namespaces of our object clean. > > > Components will have some sort of registry and querying system that will > > allow different parts of IPython to get the runtime api for other > > components. This will also be completely independent of IP itself. It > will > > look something like this: > > > > rc = Component.find_component_runtime('prompt1', Prompt) # get the > runtime > > api for component named 'prompt1' that is an instance of Prompt > > > > Once you have one of these runtime objects you can do a number of things: > > > > * read its attributes (rc.prompt_string) > > * write its attributes > > * setup notifications rc.add_notification('prompt_string', callable) # > > callable is called if prompt_string changes. > > I think you could maybe do all of this with properties. Notifications > could be handled with a decorator. > Yes, properties or descriptors would handle this fine. We need dynamic notifications (at runtime) so decorators wont work for this. But, it is pretty simple to come up with a basic notification api. That is the easy part. > I agree. It would be confusing trying to figure out whether the > desired attribute or method is found on the component itself or on the > rc attr. Maybe I'm just not familiar with any projects that do it this > way, so the is-a paradigm feels more natural. > I think this is an IPython thing that we maybe want to get away from. Cheers and thanks, Brian > > Darren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 15:36:14 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 12:36:14 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Darren, Thanks for comments! > c = MyComponent() # this build it with class defaults > > c.configure(config) # The App or parent component passes the config to > the > > object to the component to override the defaults > > c.freeze_config() # This tells the component that config is done and that > it > > should complete any remaining init related things. > > This seems a bit awkward to me. Why not do: > > c = MyComponent(..., config=(config1,config2,...)) > > and have the component complete any remaining init related things at > the end of __init__? > Very good point. For the most part, I think we could do this. But there are two usage patterns that we sometimes run into that might require a separate call to configure: * There are a few cases where we use adaptors, which requires a single argument __init__ method that takes the object to be adapted. In this case, we can't pass additional things into the __init__ method. * Currently we sometimes create an object with a default config, then use it a bit and *then* later finish passing it its config information. But, I don't like this usage pattern so we could probably get rid of it. Overall I agree with you that just using the __init__ method is cleaner though. I guess I don't understand the motivation for this extra degree of > separation, why are run-time attributes held by an objects rc struct > instead of by the object itself? It seems more natural to use > properties. > I think the main motivation is to have runtime objects that have very small and clean namespaces. The classic example of the "is-a" approach is traits. Just tab complete on a HasTraits instance and you will see what I mean about a large a non-clean namespace. But, I agree with you. We are not inheriting from HasTraits and there is no reason we can't keep the namespaces of our object clean. > > > Components will have some sort of registry and querying system that will > > allow different parts of IPython to get the runtime api for other > > components. This will also be completely independent of IP itself. It > will > > look something like this: > > > > rc = Component.find_component_runtime('prompt1', Prompt) # get the > runtime > > api for component named 'prompt1' that is an instance of Prompt > > > > Once you have one of these runtime objects you can do a number of things: > > > > * read its attributes (rc.prompt_string) > > * write its attributes > > * setup notifications rc.add_notification('prompt_string', callable) # > > callable is called if prompt_string changes. > > I think you could maybe do all of this with properties. Notifications > could be handled with a decorator. > Yes, properties or descriptors would handle this fine. We need dynamic notifications (at runtime) so decorators wont work for this. But, it is pretty simple to come up with a basic notification api. That is the easy part. > I agree. It would be confusing trying to figure out whether the > desired attribute or method is found on the component itself or on the > rc attr. Maybe I'm just not familiar with any projects that do it this > way, so the is-a paradigm feels more natural. > I think this is an IPython thing that we maybe want to get away from. Cheers and thanks, Brian > > Darren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Wed Jul 29 15:59:58 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 29 Jul 2009 22:59:58 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger wrote: > methods?? It gets darned confusing.? This confusion shows up in silly things > like methods of InteractiveShell using ipapi rather than just calling its > own methods!? I think this is an abuse of OO design.? Objects themselves Using a separate "api" object allows you to actually move stuff out of InteractiveShell if necessary. It also allows you to rename, or in other ways reorganize the underlying implementation, without "locking anything down". A "proxy" api object is able to survive extensive refactoring. > have public APIs.? You don't need the extra indirection of a public API that > wraps that public API.? I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api.? But, once that is > fixed, I think ipapi should go away. In static circles, it's a well known design methodology to restrict the interface you can use as much as you possible can, by not giving yourself access to all the internals (or making "passing the boundary" explicit, through having to use _ip.IP). It's true that implementation of the same concept for Python has been less than stellar success (adapt(), zope interfaces, ...), but it still make the code more "approachable" than building a monolithic "everything goes" mess. Regarding ipapi going away - I don't think it technically "needs to", apart from the parts that don't make sense for new ipython architecture. Regardless of how magic functions are implemented, it's reassuring to know you can always use expose_magic to create a magic function - it may not be the most flexible way, it may jump through various hooks, but the user can rest assured that you will eventually have that magic function available. It just doesn't make sense to break a public API for the matter of taste alone, in the spirit of "I'd rather have this here", if the semantics of the new API are portable with the semantics of the old one. Let's have the new clean API first, and consider breaking compatibility when it is necessary. (i.e. when the new arcticeture can no longer support functionality of the old one). I'm sure most of the "legacy" ipapi can easily be hacked to work with the new stuff by an afternoon of coding. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Jul 29 15:59:58 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 29 Jul 2009 22:59:58 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> Message-ID: <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger wrote: > methods?? It gets darned confusing.? This confusion shows up in silly things > like methods of InteractiveShell using ipapi rather than just calling its > own methods!? I think this is an abuse of OO design.? Objects themselves Using a separate "api" object allows you to actually move stuff out of InteractiveShell if necessary. It also allows you to rename, or in other ways reorganize the underlying implementation, without "locking anything down". A "proxy" api object is able to survive extensive refactoring. > have public APIs.? You don't need the extra indirection of a public API that > wraps that public API.? I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api.? But, once that is > fixed, I think ipapi should go away. In static circles, it's a well known design methodology to restrict the interface you can use as much as you possible can, by not giving yourself access to all the internals (or making "passing the boundary" explicit, through having to use _ip.IP). It's true that implementation of the same concept for Python has been less than stellar success (adapt(), zope interfaces, ...), but it still make the code more "approachable" than building a monolithic "everything goes" mess. Regarding ipapi going away - I don't think it technically "needs to", apart from the parts that don't make sense for new ipython architecture. Regardless of how magic functions are implemented, it's reassuring to know you can always use expose_magic to create a magic function - it may not be the most flexible way, it may jump through various hooks, but the user can rest assured that you will eventually have that magic function available. It just doesn't make sense to break a public API for the matter of taste alone, in the spirit of "I'd rather have this here", if the semantics of the new API are portable with the semantics of the old one. Let's have the new clean API first, and consider breaking compatibility when it is necessary. (i.e. when the new arcticeture can no longer support functionality of the old one). I'm sure most of the "legacy" ipapi can easily be hacked to work with the new stuff by an afternoon of coding. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Jul 29 16:01:08 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 29 Jul 2009 23:01:08 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> On Wed, Jul 29, 2009 at 10:36 PM, Brian Granger wrote: > Yes, properties or descriptors would handle this fine.? We need dynamic > notifications (at runtime) so decorators wont work for this.? But, it is > pretty simple to come up with a basic notification api.? That is the easy > part. This might be of interest: http://pydispatcher.sourceforge.net/ -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Jul 29 16:01:08 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 29 Jul 2009 23:01:08 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> On Wed, Jul 29, 2009 at 10:36 PM, Brian Granger wrote: > Yes, properties or descriptors would handle this fine.? We need dynamic > notifications (at runtime) so decorators wont work for this.? But, it is > pretty simple to come up with a basic notification api.? That is the easy > part. This might be of interest: http://pydispatcher.sourceforge.net/ -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Wed Jul 29 16:34:59 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 13:34:59 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> Message-ID: <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> On Wed, Jul 29, 2009 at 12:59 PM, Ville M. Vainio wrote: > On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger > wrote: > > > methods? It gets darned confusing. This confusion shows up in silly > things > > like methods of InteractiveShell using ipapi rather than just calling its > > own methods! I think this is an abuse of OO design. Objects themselves > > Using a separate "api" object allows you to actually move stuff out of > InteractiveShell if necessary. It also allows you to rename, or in > other ways reorganize the underlying implementation, without "locking > anything down". A "proxy" api object is able to survive extensive > refactoring. > I was thinking about this over lunch. One of the problems with not having a separate runtime api is that it is difficult, when looking at a large class, to know what constitutes its truly public api (at least for a language like python) One approach is informal: anything beginning with "_" is not part of the public api, anything else is. But, the problem is that someone will forget to add a "_" to an attribute and all of a sudden people will start to use it even though it is really private. This is where Java folks (rightfully!!!) get to laugh at us pythonistas. Having a separate api object is a way of saying, "this and only this constitutes my public api." But, originally, I was thinking of attributes only. I don't like the idea of every class in IPython having itself and then a separate api class. That seems redundant. > have public APIs. You don't need the extra indirection of a public API that > wraps that public API. I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api. But, once that is > fixed, I think ipapi should go away. In static circles, it's a well known design methodology to restrict > the interface you can use as much as you possible can, by not giving > yourself access to all the internals (or making "passing the boundary" > explicit, through having to use _ip.IP). If by 'static circles'' you mean statically typed (like Java, C++) you still just use one object, not a separate api object to accomplish this. > It's true that > implementation of the same concept for Python has been less than > stellar success (adapt(), zope interfaces, ...), but it still make the > code more "approachable" than building a monolithic "everything goes" > mess. > > Regarding ipapi going away - I don't think it technically "needs to", > apart from the parts that don't make sense for new ipython > architecture. Regardless of how magic functions are implemented, it's > reassuring to know you can always use expose_magic to create a magic > function - it may not be the most flexible way, it may jump through > various hooks, but the user can rest assured that you will eventually > have that magic function available. > > It just doesn't make sense to break a public API for the matter of > taste alone, in the spirit of "I'd rather have this here", if the > semantics of the new API are portable with the semantics of the old > one. Let's have the new clean API first, and consider breaking > compatibility when it is necessary. (i.e. when the new arcticeture can > no longer support functionality of the old one). That is my plan. > I'm sure most of the > "legacy" ipapi can easily be hacked to work with the new stuff by an > afternoon of coding. > This is likely. But my hope is that the replacements for ipapi will be so far superior, no one will want to use ipapi anymore. But until that amazing new code exists, ipapi will live on! Cheers, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 16:35:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 13:35:17 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> Message-ID: <6ce0ac130907291335q5cdb3faboa5b2c700b9e34084@mail.gmail.com> Thanks, I hadn't seen that! Cheers, Brian On Wed, Jul 29, 2009 at 1:01 PM, Ville M. Vainio wrote: > On Wed, Jul 29, 2009 at 10:36 PM, Brian Granger > wrote: > > > Yes, properties or descriptors would handle this fine. We need dynamic > > notifications (at runtime) so decorators wont work for this. But, it is > > pretty simple to come up with a basic notification api. That is the easy > > part. > > This might be of interest: http://pydispatcher.sourceforge.net/ > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 16:34:59 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 13:34:59 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> Message-ID: <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> On Wed, Jul 29, 2009 at 12:59 PM, Ville M. Vainio wrote: > On Wed, Jul 29, 2009 at 9:17 PM, Brian Granger > wrote: > > > methods? It gets darned confusing. This confusion shows up in silly > things > > like methods of InteractiveShell using ipapi rather than just calling its > > own methods! I think this is an abuse of OO design. Objects themselves > > Using a separate "api" object allows you to actually move stuff out of > InteractiveShell if necessary. It also allows you to rename, or in > other ways reorganize the underlying implementation, without "locking > anything down". A "proxy" api object is able to survive extensive > refactoring. > I was thinking about this over lunch. One of the problems with not having a separate runtime api is that it is difficult, when looking at a large class, to know what constitutes its truly public api (at least for a language like python) One approach is informal: anything beginning with "_" is not part of the public api, anything else is. But, the problem is that someone will forget to add a "_" to an attribute and all of a sudden people will start to use it even though it is really private. This is where Java folks (rightfully!!!) get to laugh at us pythonistas. Having a separate api object is a way of saying, "this and only this constitutes my public api." But, originally, I was thinking of attributes only. I don't like the idea of every class in IPython having itself and then a separate api class. That seems redundant. > have public APIs. You don't need the extra indirection of a public API that > wraps that public API. I think the original reason we came up with ipapi is > that InteractiveShell didn't have a clean public api. But, once that is > fixed, I think ipapi should go away. In static circles, it's a well known design methodology to restrict > the interface you can use as much as you possible can, by not giving > yourself access to all the internals (or making "passing the boundary" > explicit, through having to use _ip.IP). If by 'static circles'' you mean statically typed (like Java, C++) you still just use one object, not a separate api object to accomplish this. > It's true that > implementation of the same concept for Python has been less than > stellar success (adapt(), zope interfaces, ...), but it still make the > code more "approachable" than building a monolithic "everything goes" > mess. > > Regarding ipapi going away - I don't think it technically "needs to", > apart from the parts that don't make sense for new ipython > architecture. Regardless of how magic functions are implemented, it's > reassuring to know you can always use expose_magic to create a magic > function - it may not be the most flexible way, it may jump through > various hooks, but the user can rest assured that you will eventually > have that magic function available. > > It just doesn't make sense to break a public API for the matter of > taste alone, in the spirit of "I'd rather have this here", if the > semantics of the new API are portable with the semantics of the old > one. Let's have the new clean API first, and consider breaking > compatibility when it is necessary. (i.e. when the new arcticeture can > no longer support functionality of the old one). That is my plan. > I'm sure most of the > "legacy" ipapi can easily be hacked to work with the new stuff by an > afternoon of coding. > This is likely. But my hope is that the replacements for ipapi will be so far superior, no one will want to use ipapi anymore. But until that amazing new code exists, ipapi will live on! Cheers, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 16:35:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 13:35:17 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> <46cb515a0907291301r654be189hf77d2410140f138a@mail.gmail.com> Message-ID: <6ce0ac130907291335q5cdb3faboa5b2c700b9e34084@mail.gmail.com> Thanks, I hadn't seen that! Cheers, Brian On Wed, Jul 29, 2009 at 1:01 PM, Ville M. Vainio wrote: > On Wed, Jul 29, 2009 at 10:36 PM, Brian Granger > wrote: > > > Yes, properties or descriptors would handle this fine. We need dynamic > > notifications (at runtime) so decorators wont work for this. But, it is > > pretty simple to come up with a basic notification api. That is the easy > > part. > > This might be of interest: http://pydispatcher.sourceforge.net/ > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Wed Jul 29 16:50:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 16:50:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 3:36 PM, Brian Granger wrote: >> > >> > Once you have one of these runtime objects you can do a number of >> > things: >> > >> > * read its attributes (rc.prompt_string) >> > * write its attributes >> > * setup notifications rc.add_notification('prompt_string', callable) # >> > callable is called if prompt_string changes. >> >> I think you could maybe do all of this with properties. Notifications >> could be handled with a decorator. > > Yes, properties or descriptors would handle this fine.? We need dynamic > notifications (at runtime) so decorators wont work for this. I meant that a decorator could be used to provide dynamic notifications. The decorator might return a callable class that calls the original method, and then the callable class iterates through the list of callables that were registered with it using component.add_notification(). Darren From dsdale24 at gmail.com Wed Jul 29 16:50:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 16:50:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 3:36 PM, Brian Granger wrote: >> > >> > Once you have one of these runtime objects you can do a number of >> > things: >> > >> > * read its attributes (rc.prompt_string) >> > * write its attributes >> > * setup notifications rc.add_notification('prompt_string', callable) # >> > callable is called if prompt_string changes. >> >> I think you could maybe do all of this with properties. Notifications >> could be handled with a decorator. > > Yes, properties or descriptors would handle this fine.? We need dynamic > notifications (at runtime) so decorators wont work for this. I meant that a decorator could be used to provide dynamic notifications. The decorator might return a callable class that calls the original method, and then the callable class iterates through the list of callables that were registered with it using component.add_notification(). Darren From ellisonbg.net at gmail.com Wed Jul 29 17:10:42 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 14:10:42 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> > I meant that a decorator could be used to provide dynamic > notifications. The decorator might return a callable class that calls > the original method, and then the callable class iterates through the > list of callables that were registered with it using > component.add_notification(). > Ahh, yes this would work well for methods. But obviously wouldn't work with attributes. Cheers, Brian > > Darren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Wed Jul 29 17:10:42 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 29 Jul 2009 14:10:42 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> Message-ID: <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> > I meant that a decorator could be used to provide dynamic > notifications. The decorator might return a callable class that calls > the original method, and then the callable class iterates through the > list of callables that were registered with it using > component.add_notification(). > Ahh, yes this would work well for methods. But obviously wouldn't work with attributes. Cheers, Brian > > Darren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Wed Jul 29 18:28:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 18:28:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 5:10 PM, Brian Granger wrote: > >> I meant that a decorator could be used to provide dynamic >> notifications. The decorator might return a callable class that calls >> the original method, and then the callable class iterates through the >> list of callables that were registered with it using >> component.add_notification(). > > Ahh, yes this would work well for methods.? But obviously wouldn't work with > attributes. Hence my suggestion to use properties instead of attributes. From dsdale24 at gmail.com Wed Jul 29 18:28:46 2009 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 29 Jul 2009 18:28:46 -0400 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <6ce0ac130907291236j9e8cc06medc11b9a035ab3af@mail.gmail.com> <6ce0ac130907291410we207ee4j8d6221a7b9783d6d@mail.gmail.com> Message-ID: On Wed, Jul 29, 2009 at 5:10 PM, Brian Granger wrote: > >> I meant that a decorator could be used to provide dynamic >> notifications. The decorator might return a callable class that calls >> the original method, and then the callable class iterates through the >> list of callables that were registered with it using >> component.add_notification(). > > Ahh, yes this would work well for methods.? But obviously wouldn't work with > attributes. Hence my suggestion to use properties instead of attributes. From vivainio at gmail.com Thu Jul 30 02:33:53 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 30 Jul 2009 09:33:53 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> Message-ID: <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> On Wed, Jul 29, 2009 at 11:34 PM, Brian Granger wrote: >> In static circles, it's a well known design methodology to restrict >> the interface you can use as much as you possible can, by not giving >> yourself access to all the internals (or making "passing the boundary" >> explicit, through having to use _ip.IP). > > If by 'static circles'' you mean statically typed (like Java, C++) you still > just use one object, not a separate api object to accomplish this. Yeah, but use it through interface instead of direct concrete class with all the bells and whistles available. Note that the api object is a separate object is an implementation detail - ipapi.get() could as well pass you the direct InteractiveShell object. The user of the api never needs to know what object it gets. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Thu Jul 30 02:33:53 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 30 Jul 2009 09:33:53 +0300 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> Message-ID: <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> On Wed, Jul 29, 2009 at 11:34 PM, Brian Granger wrote: >> In static circles, it's a well known design methodology to restrict >> the interface you can use as much as you possible can, by not giving >> yourself access to all the internals (or making "passing the boundary" >> explicit, through having to use _ip.IP). > > If by 'static circles'' you mean statically typed (like Java, C++) you still > just use one object, not a separate api object to accomplish this. Yeah, but use it through interface instead of direct concrete class with all the bells and whistles available. Note that the api object is a separate object is an implementation detail - ipapi.get() could as well pass you the direct InteractiveShell object. The user of the api never needs to know what object it gets. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Fri Jul 31 14:04:34 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 31 Jul 2009 11:04:34 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> Message-ID: <6ce0ac130907311104j5cb4f72em6240abdcf6e830c3@mail.gmail.com> > > Note that the api object is a separate object is an implementation > detail - ipapi.get() could as well pass you the direct > InteractiveShell object. The change that I am making right now though is that *every* object in IPython (the shell, magics, alias, completers, you name it) will have a runtime api. Also, at this point, I am deeply concerned about implementation details. Thus > The user of the api never needs to know what > object it gets. > True, but as I design and implement the underlying architecture, I surely do care about what objects exist underneath the hood. Minimally, the idea that *every* object will have a runtime API (as well as a configuration interface and other things as well) is a dramatic departure from our current design. I still haven't decided which approach to take - for now I am implementing a few prototypes to see what things look like. Cheers, Brian > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Fri Jul 31 14:04:34 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 31 Jul 2009 11:04:34 -0700 Subject: [IPython-dev] App's, Components and refactoring In-Reply-To: <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> References: <6ce0ac130907291117s463f3c83t78af681ecab56246@mail.gmail.com> <46cb515a0907291259i763c973dj5753095083e26fa5@mail.gmail.com> <6ce0ac130907291334r397622d6tdbb86579870a4b81@mail.gmail.com> <46cb515a0907292333i4208c14csa3fa0b71071023e5@mail.gmail.com> Message-ID: <6ce0ac130907311104j5cb4f72em6240abdcf6e830c3@mail.gmail.com> > > Note that the api object is a separate object is an implementation > detail - ipapi.get() could as well pass you the direct > InteractiveShell object. The change that I am making right now though is that *every* object in IPython (the shell, magics, alias, completers, you name it) will have a runtime api. Also, at this point, I am deeply concerned about implementation details. Thus > The user of the api never needs to know what > object it gets. > True, but as I design and implement the underlying architecture, I surely do care about what objects exist underneath the hood. Minimally, the idea that *every* object will have a runtime API (as well as a configuration interface and other things as well) is a dramatic departure from our current design. I still haven't decided which approach to take - for now I am implementing a few prototypes to see what things look like. Cheers, Brian > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jul 31 20:48:24 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 31 Jul 2009 17:48:24 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> Message-ID: >> I don't use Windows anymore, so maintenance prospects of that feature >> seem rather slim. You can remove it. Done in trunk, will push now. Thanks, f From fperez.net at gmail.com Fri Jul 31 20:48:24 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 31 Jul 2009 17:48:24 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> Message-ID: >> I don't use Windows anymore, so maintenance prospects of that feature >> seem rather slim. You can remove it. Done in trunk, will push now. Thanks, f From ellisonbg.net at gmail.com Mon Jul 27 15:40:16 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 27 Jul 2009 12:40:16 -0700 Subject: [IPython-dev] Configuration system thoughts Message-ID: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> Hi, I am currently refactoring the IPython configuration system. I thought this would be a fairly straightforward task to move IPython to a single unified config system with a new config file format. But, it is turning out to be quite massive undertaking. I wanted to share some of my notes at this point to generate discussion about this... * Currently, we read assemble the main config objects in ipmaker.py and save them as IP.rc which is a Struct. From then on, IPython code can reference the config variables using a notation like IP.rc.autocall, etc. The logic in ipmaker is super-messy and is one of the main config-y-things that needs refactoring. * But, this is not merely a configuration system, it is also a runtime attribute system. By this, I mean that the values in IP.rc are changed at runtime by various parts of the code to change the behavior of the running IPython. Some attributes (like autocall) can be changed by modifying IP.rc at runtime and other's (the prompts) can't. What I mean by "can't" is that you can change IP.rc, but IPython's behavior won't change. An example of this is that to get the prompts to change at runtime you need to hack into IP.outputcache.prompt1. In other cases (like autocall), the relevant IPython code always looks at IP.rc.autocall, so if it is changed, IPython's behavior changes. Anyone who is paying attention at this point will think... "ahh, observers, notification, python", this sounds like enthought.traits!!! Yes, traits would definitely be one solution for dealing with this issue. But, we *really* want IPython to run on IronPython and Jython, so having traits as a new dependency (it has a ~5000 line C-module) won't work. The only way we could use traits is if someone implemented a pure Python version of traits (or a suitable subset). When you think about plugging IPython into an actual GUI app, the need for real observers/notifications increases only more. I am sure that Gael will agree. * We need to move away from the model of "IP holds the config for everything" to each object holding and loading its own config data. * We need to de-couple configuration (the behavior of objects upon creation) from notification/observation (how objects work together at runtime). With these things in mind, here is what I am thinking... All IPython classes will inherit from a number of base classes that provide the basic features we need also classes to have: * Configurable = an object that can be configured from the config files, command line, and by passing in options. Basically, this is an object that has a super fancy __init__ logic (possibly not in __init__). Each class will declare where its default config file lives, what its command line options are, etc. * NotificationSource = an object that can notify other objects when its attributes change. This is basically like a HasTraits. Having these 2 different subclasses should de-couple the question of configuration from the question of notification/runtime attributes. Thoughts? Ideas? Feedback? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Jul 28 04:58:04 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 01:58:04 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> Message-ID: On Mon, Jul 27, 2009 at 12:40 PM, Brian Granger wrote: > Hi, > > I am currently refactoring the IPython configuration system.? I thought this > would be a fairly straightforward task to move IPython to a single unified > config system with a new config file format.? But, it is turning out to be > quite massive undertaking.? I wanted to share some of my notes at this point > to generate discussion about this... > > * Currently, we read assemble the main config objects in ipmaker.py and save > them as IP.rc which is a Struct.? From then on, IPython code can reference > the config variables using a notation like IP.rc.autocall, etc.? The logic > in ipmaker is super-messy and is one of the main config-y-things that needs > refactoring. Sorry you ended up having to see that :) Indeed, that code is absolutely heinous, and the reasons are purely historical artifact. IPython started life as my personal $PYTHONSTARTUP file a few days after I'd begun to learn to use python, so initially it was just one long script to load and configure a bunch of tweaks to sys.displayhook. When it became 'a program' I just copied that mess over, indented it 4 spaces and gave it a name. Thus was ipmaker born unto the world :) But eventually we had to do something about this, and now is the time. I'm more than happy to help shoulder a bit of the load. > * But, this is not merely a configuration system, it is also a runtime > attribute system.? By this, I mean that the values in IP.rc are changed at > runtime by various parts of the code to change the behavior of the running > IPython.? Some attributes (like autocall) can be changed by modifying IP.rc > at runtime and other's (the prompts) can't.? What I mean by "can't" is that > you can change IP.rc, but IPython's behavior won't change.? An example of > this is that to get the prompts to change at runtime you need to? hack into > IP.outputcache.prompt1.? In other cases (like autocall), the relevant > IPython code always looks at IP.rc.autocall, so if it is changed, IPython's > behavior changes. > > Anyone who is paying attention at this point will think... "ahh, observers, > notification, python", this sounds like enthought.traits!!!? Yes, traits > would definitely be one solution for dealing with this issue.? But, we > *really* want IPython to run on IronPython and Jython, so having traits as a > new dependency (it has a ~5000 line C-module) won't work.? The only way we > could use traits is if someone implemented a pure Python version of traits > (or a suitable subset). For the record (you know this already) we're in full agreement here. For example, as of a few days ago apparently ipython runs in IronPython: http://lists.ironpython.com/pipermail/users-ironpython.com/2009-June/010590.html Obviously this means just the interactive interpreter, not all the kernel code, but this is still great news. It would be crazy to kill this in our next version by introducing a dependency like Traits, as much as it can have other benefits. One thing we should strive for, is to remove the need (as much as possible) for any special behavior with options, like it exists today. Basically if something lives in the runtime config holders, then it should be OK to set its value at runtime and things should behave normally and honor this change. If something can't be simply changed like that (say because it really was an argument to some function that has already been called and is now gone), then it should NOT be visible as a runtime option. We can then put in specific calls to set more complex behavior at runtime when needed, but such a design decision would at least allow us to decouple the mess you've identified of having a values holder (the rc struct) where some things can be touched at runtime and others not. > * We need to move away from the model of "IP holds the config for > everything" to each object holding and loading its own config data. > > * We need to de-couple configuration (the behavior of objects upon creation) > from notification/observation (how objects work together at runtime). Broadly speaking I agree, with some minor adjustments. See below. > With these things in mind, here is what I am thinking... > > All IPython classes will inherit from a number of base classes that provide > the basic features we need also classes to have: > > * Configurable = an object that can be configured from the config files, > command line, and by passing in options.? Basically, this is an object that > has a super fancy __init__ logic (possibly not in __init__).? Each class > will declare where its default config file lives, what its command line > options are, etc. > > * NotificationSource = an object that can notify other objects when its > attributes change.? This is basically like a HasTraits. > > Having these 2 different subclasses should de-couple the question of > configuration from the question of notification/runtime attributes. > > Thoughts?? Ideas? Feedback? I'm not 100% sure that we want a base class that is at the root of the object hierarchy to provide management of configuration and notification. But I think both ideas are going in the right direction, so here's a possible twist on them (I'm tired so this may be well off-base, we can and should iterate on it): - Configurable would be used to define configuration objects, but these would be held as attributes of the various 'user-facing' objects. Basically I'm thinking of a 'has a' relationship rather than an 'is a' one, to reduce couplings. - Objects that need it will use Configurable, but in practice the main application 'entry points' will probably use more than one object with a configuration instance. For these, it should be possible to compose/aggregate config instances easily. Something like: s = IPythonShell() s has s.kernel, s.frontend components. Each of these has a config instance above, but the user should only need to use s.config directly, which will hold the configuration of all the subcomponents. I need to crash now though, I'll try to think a little more about this tomorrow and we'll continue to iterate... Thanks for tackling this, I'm really happy about it (long needed)! f From vivainio at gmail.com Tue Jul 28 05:15:13 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 05:15:13 -0400 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> Message-ID: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> On Mon, Jul 27, 2009 at 3:40 PM, Brian Granger wrote: > IPython. Some attributes (like autocall) can be changed by modifying IP.rc > at runtime and other's (the prompts) can't. What I mean by "can't" is that > you can change IP.rc, but IPython's behavior won't change. An example of > this is that to get the prompts to change at runtime you need to hack into > IP.outputcache.prompt1. In other cases (like autocall), the relevant > IPython code always looks at IP.rc.autocall, so if it is changed, IPython's > behavior changes. Many of these problems could be fixed by fixing stuff like prompts to actually look at the config variable every time. Since it needs some "computation" every time, you can remember the value of previous invocation and do the calculation only if it has changed. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Tue Jul 28 12:32:37 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:32:37 -0700 Subject: [IPython-dev] Question about ipykit.py Message-ID: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Hi, During my module reorganization, I have been trying to cleanup our top-level directory (the one with setup.py in it). One file that I don't know what to do with is ipykit.py. Questions? * Is this still being used by anyone? If not, can we delete it? * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Tue Jul 28 12:32:37 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:32:37 -0700 Subject: [IPython-dev] Question about ipykit.py Message-ID: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Hi, During my module reorganization, I have been trying to cleanup our top-level directory (the one with setup.py in it). One file that I don't know what to do with is ipykit.py. Questions? * Is this still being used by anyone? If not, can we delete it? * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Tue Jul 28 12:39:15 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 19:39:15 +0300 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Message-ID: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> On Tue, Jul 28, 2009 at 7:32 PM, Brian Granger wrote: > During my module reorganization, I have been trying to cleanup our top-level > directory (the one with setup.py in it).? One file that I don't know what to > do with is ipykit.py.? Questions? > > * Is this still being used by anyone?? If not, can we delete it? > * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? It's my py2exe'd IPython (to have an IPython that can be moved around on usb stick). I don't use Windows anymore, so maintenance prospects of that feature seem rather slim. You can remove it. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Tue Jul 28 12:39:15 2009 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 28 Jul 2009 19:39:15 +0300 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> Message-ID: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> On Tue, Jul 28, 2009 at 7:32 PM, Brian Granger wrote: > During my module reorganization, I have been trying to cleanup our top-level > directory (the one with setup.py in it).? One file that I don't know what to > do with is ipykit.py.? Questions? > > * Is this still being used by anyone?? If not, can we delete it? > * What is ipykit and shouldn't ipykit.py be put with the rest of ipykit? It's my py2exe'd IPython (to have an IPython that can be moved around on usb stick). I don't use Windows anymore, so maintenance prospects of that feature seem rather slim. You can remove it. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Tue Jul 28 12:58:49 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:58:49 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> Message-ID: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> > It's my py2exe'd IPython (to have an IPython that can be moved around > on usb stick). > > I don't use Windows anymore, so maintenance prospects of that feature > seem rather slim. You can remove it. > OK, thanks, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Tue Jul 28 12:58:49 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 09:58:49 -0700 Subject: [IPython-dev] Question about ipykit.py In-Reply-To: <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> References: <6ce0ac130907280932lb6fea04n1dce3400352ebe91@mail.gmail.com> <46cb515a0907280939j471fb709v779c861ea5a0a96b@mail.gmail.com> Message-ID: <6ce0ac130907280958j217fa6cbg8529979bb73e803c@mail.gmail.com> > It's my py2exe'd IPython (to have an IPython that can be moved around > on usb stick). > > I don't use Windows anymore, so maintenance prospects of that feature > seem rather slim. You can remove it. > OK, thanks, Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Jul 28 14:50:51 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 11:50:51 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... Message-ID: Hi folks, after a real-life provoked long silence, we have some good news to report... You may have seen Brian's recent refactoring posts and excellent work. Thanks to IPython's importance for one of our projects at work, NIPY (http://neuroimaging.scipy.org), we've been able to secure some funding so that Brian can spend a concentrated amount of time on this critically needed refactoring work. This is in a sense the logical outcome of the ipython1/0 merge, and it will let us revitalize the project in a number of useful directions. I'd like to thank the NIPY project for this support, since for a long time we've needed this kind of solid block of time to achieve such a restructuring but had never been able to support it. Which brings us to the next point... A few months ago we did a bunch of work on cleaning up the code we had to push 0.10 out, and then life got messy and the actual release never happened. Well, now we should really try to finish up, especially so that the code that has been written can be merged as soon as possible for Brian to push the refactoring into trunk. Brian's refactoring is massive and touches everything, so initially there is going to be some breakage (we'll do our best to minimize it and Brian is super careful, but some pain will no doubt occur). For this reason, and to prevent stalling Brian's advance, I'd like to wrap up the 0.10 release work as soon as possible. Status: - Branch reviews: https://code.launchpad.net/ipython/+activereviews * Two of these (the approved ones) I will merge soon if nobody objects in the next few hours. * Ondrej's embedding fix is set for 0.11, so it can be merged after Brian's code is in (I want a bit of tuning on the interface there, and the change is highly localized, so this won't be a problem). * Brian's is the refactoring itself, so it's not for 0.10 * We have 3 remaining ones, one by Tom and two by Ville, that have been awaiting small fixes for a while. On the 3 last ones, it seemed Tom was having some problems cleaning up the commits after conflict markers went in. I'll see if I can make a cleaned-up version of that, since the actual code is pretty small. Ville's have both pending review comments from April 15. A lot of that is probably fairly easy to finish up, Ville, do you think you can address them? - Bugs: we only have four bugs explicitly marked as critical for 0.10: https://bugs.launchpad.net/ipython/0.10/+bugs and 3 of them have had fixes committed. I have a fix for the remaining one in my local tree, that I'll push for review once I can test it better (I'm having some weirdo nose issues right now on my desktop). So from a pending branches/bugs perspective, I think we're very very close. Given this, I'd like to consider the code frozen as of now, unless someone strongly objects, and leave the next few days to sort out the remaining work on the one bug and the three branches. I'm going to work on this today to try to help as much as I can. If all goes well, I'd like to finish merging by Friday or Saturday. That will then allow us to review Brian's work to merge it into trunk, and trunk will then have diverged from the 0.10 'old' series for good. Any last-minute fixes for the actual 0.10 release will be only applied on the 0.10 series branch and backported manually (by me) if necessary to trunk. The trunk would then be the development for the next release with the new API. I'm actually thinking that we should name the trunk version 0.90 instead of 0.11, to emphasize the API jump: 0.10 has the old APIs, and 0.90 will be the start of the new APIs, targetting an actual 1.0 release on the cleaned up and refactored codebase. Any comments on this plan? Cheers, f From fperez.net at gmail.com Tue Jul 28 15:02:55 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 12:02:55 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> Message-ID: On Tue, Jul 28, 2009 at 2:15 AM, Ville M. Vainio wrote: > Many of these problems could be fixed by fixing stuff like prompts to > actually look at the config variable every time. Since it needs some > "computation" every time, you can remember the value of previous > invocation and do the calculation only if it has changed. Yes, that is indeed part of what needs to be done. In the current code, I never gave much serious thought to these matters (I just wrote it 'on the go'), but the problem is now much clearer. Basically we need to be strict about: - options/config objects that can be changed at runtime should always be safe for modification. Basically if you can set a value, it's because anything that depends on it will behave OK with the modification. - Any runtime changes that can't be done by modifying a simple config variable, if really needed, will require a dedicated function to enact the change, rather than trying to set a variable. With this policy in place it would thus be safe, by definition, to manipulate config objects at runtime. Cheers, f From fperez.net at gmail.com Tue Jul 28 15:39:31 2009 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 28 Jul 2009 12:39:31 -0700 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner (listsin) wrote: >> You may have seen Brian's recent refactoring posts and excellent work. >> Thanks to IPython's importance for one of our projects at work, NIPY >> (http://neuroimaging.scipy.org), > > Site seems to be down... Really? I just clicked and it worked fine from here. Can you retry? If it fails again, where geographically are you accessing it from? I can report the outage to the admin with some more info, but it's certainly working from here... Cheers, f From robert.kern at gmail.com Tue Jul 28 15:46:47 2009 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 28 Jul 2009 14:46:47 -0500 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: On 2009-07-28 14:39, Fernando Perez wrote: > On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner > (listsin) wrote: >>> You may have seen Brian's recent refactoring posts and excellent work. >>> Thanks to IPython's importance for one of our projects at work, NIPY >>> (http://neuroimaging.scipy.org), >> Site seems to be down... > > Really? I just clicked and it worked fine from here. Can you retry? > If it fails again, where geographically are you accessing it from? I > can report the outage to the admin with some more info, but it's > certainly working from here... It was down but is now back up. -- 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 From ellisonbg.net at gmail.com Tue Jul 28 16:28:17 2009 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 28 Jul 2009 13:28:17 -0700 Subject: [IPython-dev] Configuration system thoughts In-Reply-To: <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> References: <6ce0ac130907271240s48c8ac6cma0c7644f1398ae4@mail.gmail.com> <46cb515a0907280215t42ea8351k2082be009f28742e@mail.gmail.com> Message-ID: <6ce0ac130907281328s3af0bbc9waf0be1ec29ce9ac3@mail.gmail.com> > IPython. Some attributes (like autocall) can be changed by modifying > IP.rc > > at runtime and other's (the prompts) can't. What I mean by "can't" is > that > > you can change IP.rc, but IPython's behavior won't change. An example of > > this is that to get the prompts to change at runtime you need to hack > into > > IP.outputcache.prompt1. In other cases (like autocall), the relevant > > IPython code always looks at IP.rc.autocall, so if it is changed, > IPython's > > behavior changes. > > Many of these problems could be fixed by fixing stuff like prompts to > actually look at the config variable every time. Since it needs some > "computation" every time, you can remember the value of previous > invocation and do the calculation only if it has changed. > Yes, definitely. However, the current approach of having IP.rc hold the runtime value for *everything* means that everything is tightly coupled to IP. That is what we have to break. My vision is that all objects will hold their own runtime state. Thus the prompt objects will hold the values of the prompt strings. We will then have an API that allows other parts of the code base to modify those values. But all of that will be completey independent of IP. Brian > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From listsin at integrateddevcorp.com Tue Jul 28 17:06:11 2009 From: listsin at integrateddevcorp.com (Steve Steiner (listsin)) Date: Tue, 28 Jul 2009 17:06:11 -0400 Subject: [IPython-dev] News, refactoring and getting 0.10 out the door... In-Reply-To: References: <4931EDED-9F4F-415C-A56B-2E5B8210218B@integrateddevcorp.com> Message-ID: <24FD0773-EC87-44E3-9077-DC79BC00CD4C@integrateddevcorp.com> scipy.org: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root at enthought.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. S On Jul 28, 2009, at 3:46 PM, Robert Kern wrote: > On 2009-07-28 14:39, Fernando Perez wrote: >> On Tue, Jul 28, 2009 at 12:29 PM, Steve Steiner >> (listsin) wrote: >>>> You may have seen Brian's recent refactoring posts and excellent >>>> work. >>>> Thanks to IPython's importance for one of our projects at work, >>>> NIPY >>>> (http://neuroimaging.scipy.org), >>> Site seems to be down... >> >> Really? I just clicked and it worked fine from here. Can you retry? >> If it fails again, where geographically are you accessing it from? I >> can report the outage to the admin with some more info, but it's >> certainly working from here... > > It was down but is now back up. > > -- > 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-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev