From fperez.net at gmail.com Sat Aug 2 05:23:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 2 Aug 2008 02:23:28 -0700 Subject: [IPython-dev] Notes from the testing trenches... Message-ID: Hi all, I'm very sorry that I've completely neglected all the (critically important) discussion here over the last few days. Basically I decided that I needed to focus 100% on pushing on the testing work, which I've become convinced was endangering seriously the long-term viability of IPython. I'm *very* happy to report this now: tlon[plugin]> nosetests -vvs --with-ipdoctest --doctest-tests --doctest-extension=txt IPython ... lots of output ... Doctest: IPython.testing.tutils.fullPath ... ok ---------------------------------------------------------------------- Ran 445 tests in 75.199s OK Yes!!! (the above includes all the IPython1 tests, in addition to many scattered docstrings and small tests from IPython0, many with actual IPython syntax in the docstrings). This is the first time that we've had real testing for all of IPython, and this has proved to be surprisingly difficult to get working. I have nobody but myself to blame for some of it, since precisely the lack of clean tests led to an over-coupled API, but part of the difficulty also stems from the fact that IPython, nose and doctest are effectively all colliding and fighting each other for control of the execution namespace. In fact, there are still things that don't quite work right, and at least one of them (having to do with namespace control) is very important. I have a solution in my head for it, but I need to sleep now and it may be a couple of days before I get to it. For now I'm putting all of this in a branch: https://code.launchpad.net/~ipython/ipython/test-tools where I've been regularly pushing. I don't expect any of this to run on anything but *nix (maybe not even OSX, I'm not sure) for now. We'll eventually make it run under all platforms, but we're not there yet. If you're brave, you can pull that branch and go to the IPython/testing/plugin directory, and type make all let me know how much blows up :) I will be offline for a day or two (visitors), and will try to get back to the notification/API discussion on Monday. A big apology to Barry and Gael for ignoring you, really. But I'd neglected the testing machinery on ipython for years, it was really time to fix this or else it was going to drag the whole project down into the ground. So if anyone is brave/foolish enough to try to run this branch and these tests, please let me know what happens. Eventually we obviously need this to work for everyone, and once the machinery is stable it will allow us to have much more strict policies regarding tests for the project. Cheers, f From barrywark at gmail.com Wed Aug 6 15:54:50 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 6 Aug 2008 15:54:50 -0400 Subject: [IPython-dev] ipython1 and synchronous printing of stdout In-Reply-To: <20080731005528.GA13565@phare.normalesup.org> References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com> <6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com> <20080731005528.GA13565@phare.normalesup.org> Message-ID: On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux wrote: > Hi, > > Sorry for the silence, I have been working my ass off on a release of > Mayavi. Now I can go back to working on ipython. No problem. I'm not finding tons of time to play either. > > On Sun, Jul 27, 2008 at 10:02:08PM -0400, Barry Wark wrote: >> Taking a bit of my own medicine?that working code is better than >> awesome theory?I've checked in the ipython-notification branch and >> proposed it for merging into trunk. It includes a functional spec in >> /blueprints (it's a bit tounge-in-cheek; I hope no one is offended) as >> well as an implementation of the NotificationCenter I've been >> discussin in IPython.kernel.core.notification. > > I had a look at that. I seems to me like a (good) textbook implementation > of the patterns we are discussing. I still fail to see the point of > having this in Ipython, at least at the state we are in right now. My > point is that there are many implementation of such frameworks. The one > you have developed is a simple one, but when you start using it a lot, > you will need to add features, like delegations, or ordering the > callbacks. Also, something that is very important is how does this blend > in the code people write? How do you make it easy for people to write > notifications without thinking too much about it, and registering > handlers (hint decorators are cool). But once again, this looks a lot to > me like traits 1. I am not trying to sell traits here, I don't think > IPyhton should use traits, I am just flashing a warning: this smells like > weel reinvention, and on top of that developing a framework, which is > something you want to limit as much as possible: we already have too many > frameworks. I have the feeling every single person coming to develop an > app using Ipython will already have his notification framework (traits, > cocoa, does Qt have one?). So now he will to write adapting code to use > your framework. Yes, but I claim writing an adaptor layer for each GUI toolkit at the level of ipython.frontend is better than writing the same in ipython.kernel.core. > > Now there is value in having an iptyhon-specific notification layer, and > it is not having uniform code across backends; matplotlib tried that, and > it doesn't bring much value, amongst other things because the backend are > anyhow riddled with toolkit-specific code. The value is that we could > think of network-transparent notifications. That is much harder > (obviously, the simple problems don't need solutions), and I would like > to know if twisted doesn't provide this kind of service. I think you've misunderstood the point. I am not trying to create a universal GUI toolkit. I am concerned with notifications of events in the core -- things that have nothing to do with the GUI toolkit. It's up to the frontend writers to decide (1) what to do with those events and (2) how to translate their GUI tookit's UI events into appropriate calls into the ipython API. > > I guess my point is not that we shouldn't do this, but that we should do > this when the need arises, and not now, for no benefit. Doing this too > early is a good way of getting it wrong. In addition this will just slow > our progress towards getting frontends and we absolutely do not need this > to get the simple frontends. I am not going to spend anytime on this, and > spending too much time on this is a good way of not having any useable > code for a long time, I believe. That's your choice. You can write your code as you wish. > > Sorry, not only am I not paid to worry about distant future, or > network-transparency problems, I am also having difficulties being > interested in something that I cannot specify properly because it doesn't > answer a problem I have. I am not in the business of making a framework, > I am in the business of making a widget. The whole notification framework > stuff, for me, will be done in traits, because this is what we use all > over our apps, because we have a lot of code that works well with it, and > because is it a mature and powerful library. I develop my apps using > traits, and I want an ipython widget to plug in my apps. If the objects > used internally in the ipython widget are standard object like dicts or > lists, I can use traits without any problem. If there are part of a > notification framework that I have to adapt to, I probably have to double > the size of my codebase. Let us see where we really need this framework. > Maybe it can also be developed in a subclass of the standard objects we > use in ipython, say a different frontend base class? > > I hope I am not being to rough or criticizing too much your software > engineering efforts. I am just trying to be practical and figure out how > to ship software that is useful to users (and yes this includes > open-source software) in a reasonable amount of time. And the basis of > agile methods is to get it working, ship it to your users, see the > limitations in your implementation, refactor, ship it again, always > focusing on what benefits to your users, rather than on the architecture > or the software engineering, which is a tool, not a goal. Fine. You have your requirements and if you don't have time to consider alternatives, that's fine with me. I think going down the road you've chosen will force others to recreate much of the functionality you're working on, but it doesn't seem that you have time to think about the more general case. > > As for your code, if you want to merge it in, it is fine by me, but I am > afraid it won't be used for a while, and when we get to use it, we might > want to change it because we have more insight on our problems. Isn't that always the case? > > Thanks for bringing up on interesting discussion, > > Ga?l > From barrywark at gmail.com Thu Aug 7 09:44:50 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 7 Aug 2008 09:44:50 -0400 Subject: [IPython-dev] ipython1 and synchronous printing of stdout In-Reply-To: References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com> <6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com> <20080731005528.GA13565@phare.normalesup.org> Message-ID: Gael, I appologize. In my haste to reply, I'm afraid that my speed may have come off as impatient. Let me try again: Although I was initially a bit offended by your remarks, I realize that we all have too much to do and not enough time to do it. I am not (and won't be) offended if you don't want to use the notification framework. We should always prefer working code and I am looking forward to benefiting from your efforts, no mater what architecture you choose. - Barry On Wed, Aug 6, 2008 at 3:54 PM, Barry Wark wrote: > On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux > wrote: >> Hi, >> >> Sorry for the silence, I have been working my ass off on a release of >> Mayavi. Now I can go back to working on ipython. > > No problem. I'm not finding tons of time to play either. > >> >> On Sun, Jul 27, 2008 at 10:02:08PM -0400, Barry Wark wrote: >>> Taking a bit of my own medicine?that working code is better than >>> awesome theory?I've checked in the ipython-notification branch and >>> proposed it for merging into trunk. It includes a functional spec in >>> /blueprints (it's a bit tounge-in-cheek; I hope no one is offended) as >>> well as an implementation of the NotificationCenter I've been >>> discussin in IPython.kernel.core.notification. >> >> I had a look at that. I seems to me like a (good) textbook implementation >> of the patterns we are discussing. I still fail to see the point of >> having this in Ipython, at least at the state we are in right now. My >> point is that there are many implementation of such frameworks. The one >> you have developed is a simple one, but when you start using it a lot, >> you will need to add features, like delegations, or ordering the >> callbacks. Also, something that is very important is how does this blend >> in the code people write? How do you make it easy for people to write >> notifications without thinking too much about it, and registering >> handlers (hint decorators are cool). But once again, this looks a lot to >> me like traits 1. I am not trying to sell traits here, I don't think >> IPyhton should use traits, I am just flashing a warning: this smells like >> weel reinvention, and on top of that developing a framework, which is >> something you want to limit as much as possible: we already have too many >> frameworks. I have the feeling every single person coming to develop an >> app using Ipython will already have his notification framework (traits, >> cocoa, does Qt have one?). So now he will to write adapting code to use >> your framework. > > Yes, but I claim writing an adaptor layer for each GUI toolkit at the > level of ipython.frontend is better than writing the same in > ipython.kernel.core. > >> >> Now there is value in having an iptyhon-specific notification layer, and >> it is not having uniform code across backends; matplotlib tried that, and >> it doesn't bring much value, amongst other things because the backend are >> anyhow riddled with toolkit-specific code. The value is that we could >> think of network-transparent notifications. That is much harder >> (obviously, the simple problems don't need solutions), and I would like >> to know if twisted doesn't provide this kind of service. > > I think you've misunderstood the point. I am not trying to create a > universal GUI toolkit. I am concerned with notifications of events in > the core -- things that have nothing to do with the GUI toolkit. It's > up to the frontend writers to decide (1) what to do with those events > and (2) how to translate their GUI tookit's UI events into appropriate > calls into the ipython API. > >> >> I guess my point is not that we shouldn't do this, but that we should do >> this when the need arises, and not now, for no benefit. Doing this too >> early is a good way of getting it wrong. In addition this will just slow >> our progress towards getting frontends and we absolutely do not need this >> to get the simple frontends. I am not going to spend anytime on this, and >> spending too much time on this is a good way of not having any useable >> code for a long time, I believe. > > That's your choice. You can write your code as you wish. > >> >> Sorry, not only am I not paid to worry about distant future, or >> network-transparency problems, I am also having difficulties being >> interested in something that I cannot specify properly because it doesn't >> answer a problem I have. I am not in the business of making a framework, >> I am in the business of making a widget. The whole notification framework >> stuff, for me, will be done in traits, because this is what we use all >> over our apps, because we have a lot of code that works well with it, and >> because is it a mature and powerful library. I develop my apps using >> traits, and I want an ipython widget to plug in my apps. If the objects >> used internally in the ipython widget are standard object like dicts or >> lists, I can use traits without any problem. If there are part of a >> notification framework that I have to adapt to, I probably have to double >> the size of my codebase. Let us see where we really need this framework. >> Maybe it can also be developed in a subclass of the standard objects we >> use in ipython, say a different frontend base class? >> >> I hope I am not being to rough or criticizing too much your software >> engineering efforts. I am just trying to be practical and figure out how >> to ship software that is useful to users (and yes this includes >> open-source software) in a reasonable amount of time. And the basis of >> agile methods is to get it working, ship it to your users, see the >> limitations in your implementation, refactor, ship it again, always >> focusing on what benefits to your users, rather than on the architecture >> or the software engineering, which is a tool, not a goal. > > Fine. You have your requirements and if you don't have time to > consider alternatives, that's fine with me. I think going down the > road you've chosen will force others to recreate much of the > functionality you're working on, but it doesn't seem that you have > time to think about the more general case. > >> >> As for your code, if you want to merge it in, it is fine by me, but I am >> afraid it won't be used for a while, and when we get to use it, we might >> want to change it because we have more insight on our problems. > > Isn't that always the case? > >> >> Thanks for bringing up on interesting discussion, >> >> Ga?l >> > From gael.varoquaux at normalesup.org Thu Aug 7 10:56:58 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 7 Aug 2008 16:56:58 +0200 Subject: [IPython-dev] ipython1 and synchronous printing of stdout In-Reply-To: References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com> <6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com> <20080731005528.GA13565@phare.normalesup.org> Message-ID: <20080807145658.GA11600@phare.normalesup.org> On Thu, Aug 07, 2008 at 09:44:50AM -0400, Barry Wark wrote: > Although I was initially a bit offended by your remarks, Sorry, Barry, I really do not want to critisize or downplay your efforts. I value a lot your opinion. I must confess what you are bringing up does not solve at all the problems I am battling for with my frontend, so I don't look at this on a high priority. > I realize that we all have too much to do and not enough time to do it. > I am not (and won't be) offended if you don't want to use the > notification framework. We should always prefer working code and I am > looking forward to benefiting from your efforts, no mater what > architecture you choose. Well, I have come to realize that one of the reasons why we where having this discussion, and not understanding eachothers is that our calls are different: you want asyncrhonous, I want synchronous. As a result, you have much bigger requirements on a notification framework to the engine than I do. I have been fighting with other difficulties, like solid trapping of output (not only at the Python level), redirection of stdin in a GUI eventloop, subprocess manipulation... For what I am trying to do, these are much more important than a notification framework. I will not be using the notification framework, but my code is opensource, and moreover in a DVCS. I strongly hope that you will be able to benefit from it to move foward with your goals. In addition, I am more than happy if my code gets refactored to include this. Let me be clear, I don't consider at all that this code belongs to me in any way. It is there to be refactored, and I will try to make it as easy as possible for people to do it. But for the time being I need to get something working. Cheers, Ga?l From ellisonbg.net at gmail.com Thu Aug 7 14:11:00 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 7 Aug 2008 11:11:00 -0700 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend Message-ID: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Hello all (especially Barry and Gael), We would like to merge the ipython-sync-frontend branch into trunk ASAP. Fernando will be sending out an email later today describing our timeframe for the upcoming release. Meanwhile, I wanted to provide some informal code review and feedback on the stuff in IPython.frontend. I haven't looked over the wx or cocoa specific stuff, just the general stuff. Overall, I am _really_ excited about this code. Many thanks to Barry and Gael for pushing this stuff forward and making the first go and using the new core. I talked to Fernando last night and both of us are completely committed to getting this stuff into the next IPython release, which is coming soon. I should preface my comments by saying that I don't think all of the comments need to be address before the merge or the release. Some of the comments are more long term. Also, Fernando is going to look over the new stuff in IPython.kernel.core (I haven't looked at this stuff). Here are my comments: =============================== Comments about IPython.frontend =============================== General ======= We need a robust way for modules in the frontend to handle interfaces if zope.interface is not installed. Currently each module tries to import zope.interface and then builds a mock zope.interface, like this:: try: from zope.interface import Interface, Attribute, implements, classProvides except ImportError: Interface = object def Attribute(name, doc): pass def implements(interface): pass def classProvides(interface): pass This code should probably be put into a common location, something like frontend.zopeinterface, so that it can be reused. But eventually when IPython.core is created, this should probably be moved there. The docstrings are vague and outdated at points. More detailed and updated docstrings would be helpful. Also, all docstrings should use the epydoc+ReST format. IPython.kernel.core should probably be moved to IPython.core. Once Fernando's testing branch has been merged, more tests should be written. frontendbase.py =============== Configuration should be done using the approach in IPython.config. See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for examples. IFrontEnd has references to Twisted in its docstrings. Because the basic frontend should work without Twisted, the docstrings should be updated to clarify how the interface plays with Twisted, even though it is optional. We really want to document for developers that the base frontend is synchronous and doesn't require Twisted, but that the interface has a particular design that allows it to be wrapped into an asynchronous frontend (like some methods pass through the result). The design of the frontend seems good though. We might eventually want to think about using the notification stuff in the frontend though. Why does FrontEndBase not have a complete method? Other frontend classes do have this method and its seems like the base class should have it too. Also, there are oher methods in the interpreter that we might want to propagate up to the frontend, like push and pull. Thoughts? If these additional methods go in, there should be separate asynchronous versions that return deferreds, but these would go into asyncfrontend.py. asyncfrontendbase.py ==================== Because this frontend us designed for use with Twisted, I don't think we need to protect the zope.interface and Twisted imports. Also setting Failure to Exception will break things as they don't have the same interface. Design looks good though. linefrontendbase.py =================== This looks good as it is simply a concrete subclass of FrontEndBase. General comments above about docstrings apply. prefilterfrontend.py ==================== It is fantastic that we can combine ipython0 and IPython.kernel.core code like this. This is a great way of using the new stuff, but getting the more complete feature set of IPython.* But I think this type of thing should be done in the lower-level Interpreter, rather than the frontend. This is for a couple of reasons: 1. This would give all users of the Interpreter access to completion and the prefilter stuff. We really need this stuff in the parallel computing stuff, as well as non-line-oriented frontends. 2. The Interpreter already has some of this logic and it is simply being repeated. 3. The current implementation requires that the Interpreter is in-process. For connecting to a remote Interpreter, this won't work. But, we might run into a problem with doing this stuff (that cool hack that is begin used currently) in the Interpreter. The reason is that the Interpreter is block based, whereas the prefilter stuff in IPython is only line based. Thus, doing this refactoring might be a little more involved. But it is the eventual design we want to go for. This stuff probably won't be done before the merge. We can work on this at SciPy. Great work everyone!!! Brian From gael.varoquaux at normalesup.org Thu Aug 7 15:18:12 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 7 Aug 2008 21:18:12 +0200 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: <20080807191812.GD26341@phare.normalesup.org> Hi Brian, Thanks a lot for your comments, they are very valuable. I have to run to catch St?fan at the airport, I just wanted to give an informal overview of the status of my work. I am currently battling with subprocess execution, including under windows. The hard stuff is the stdin capture, and it happens more often than I would like. Once I am done with that (hopefully today, though my afternoon will be busy working with St?fan), I have to make sure that 'Ctrl-C' stops Python execution, which should be easy. After this I was planning to clean up the code, add comments and ask for merge. All your comments are very much to the points. Some of them where already on my todo list. Can you prioritize them, and tell me at which point I should do the merge. I also would like to merge ASAP, I just don't want to have bad crashers in the code before I merge (but if you think it is acceptable, I'll go for it), and I want to refactor some names and interfaces before the merge. Hopefully merge is a few work days away. Is that good enough, or should I try to get this done faster? Obviously this is a first cut, and there will be some lessons to learn. > We need a robust way for modules in the frontend to handle interfaces > if zope.interface is not installed. Currently each module tries to > import zope.interface and then builds a mock zope.interface, like > this:: > try: > from zope.interface import Interface, Attribute, implements, classProvides > except ImportError: > Interface = object > def Attribute(name, doc): pass > def implements(interface): pass > def classProvides(interface): pass > This code should probably be put into a common location, something > like frontend.zopeinterface, so that it can be reused. But eventually > when > IPython.core is created, this should probably be moved there. Sounds good. > The docstrings are vague and outdated at points. More detailed and > updated docstrings would be helpful. Also, all docstrings should use > the epydoc+ReST format. Oh yes, definitely. The docstring are not good enough, and some of the names are not explicite enough. > IPython.kernel.core should probably be moved to IPython.core. > Once Fernando's testing branch has been merged, more tests should be written. +1. My stuff is hard to test, but I want to have a go and see what I can do. > frontendbase.py > =============== > Configuration should be done using the approach in IPython.config. > See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for > examples. OK. > IFrontEnd has references to Twisted in its docstrings. Because the > basic frontend should work without Twisted, the docstrings should be > updated to clarify how the interface plays with Twisted, even though > it is optional. We really want to document for developers that the > base frontend is synchronous and doesn't require Twisted, but that the > interface has a particular design that allows it to be wrapped into an > asynchronous frontend (like some methods pass through the result). > The design of the frontend seems good though. We might eventually > want to think about using the notification stuff in the frontend > though. > Why does FrontEndBase not have a complete method? Other frontend > classes do have this method and its seems like the base class should > have it too. I need to come back on all this and define the interfaces in a more formal way. Currently this is messy, and I have been coding the frontend implementation to figure out what the right interface is. So yes, I'll do that before the merge. > Also, there are oher methods in the interpreter that we > might want to propagate up to the frontend, like push and pull. > Thoughts? Not sure this is urgent. I haven't used them so far. But maybe. I want to have a "pyshell" interface for my frontend, maybe in a subclass. This is important as the frontend should be a drop-in replacmeent for pyshell. > prefilterfrontend.py > ==================== > It is fantastic that we can combine ipython0 and IPython.kernel.core > code like this. This is a great way of using the new stuff, but > getting the more complete feature set of IPython.* But I think this > type of thing should be done in the lower-level Interpreter, rather > than the frontend. This is for a couple of reasons: > 1. This would give all users of the Interpreter access to completion and the > prefilter stuff. We really need this stuff in the parallel > computing stuff, > as well as non-line-oriented frontends. > 2. The Interpreter already has some of this logic and it is simply being > repeated. > 3. The current implementation requires that the Interpreter is in-process. > For connecting to a remote Interpreter, this won't work. Absolutely. This is an experiment, and I was waiting for Fernando to be done with his testing to be able to work on that. prefilterfrontend.py should be called "dirtyhackfrontend.py" IMHO. > But, we might run into a problem with doing this stuff (that cool hack > that is begin used currently) in the Interpreter. The reason is that > the Interpreter is block based, whereas the prefilter stuff in IPython > is only line based. Thus, doing this refactoring might be a little > more involved. But it is the eventual design we want to go for. This > stuff probably won't be done before the merge. We can work on this at > SciPy. Once again, thanks a lot for your detailed feedback, it is very valuable to me. Ga?l From barrywark at gmail.com Thu Aug 7 19:36:52 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 7 Aug 2008 19:36:52 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: Brian et al., I don't have time to give your comments the time they deserve tonight so I wanted to just weigh in quickly on merging Gael's branch before the upcoming release. There are some significant changes I want to make to the frontendbase interface, mainly making the concept of a execution block more explicit, but I realize Gael has made great progress with his branch that diverged before I made those changes. I think the synchronous frontend should be merged in for the release if possible. I will hold of on my changes until the release has settled and we have time to evaluate how the newer frontend architecture. I have just one other comment, in line below, for the moment and will try to get you a more proper response soon. On Thu, Aug 7, 2008 at 2:11 PM, Brian Granger wrote: > Hello all (especially Barry and Gael), > > We would like to merge the ipython-sync-frontend branch into trunk > ASAP. Fernando will be sending out an email later today describing > our timeframe for the upcoming release. Meanwhile, I wanted to > provide some informal code review and feedback on the stuff in > IPython.frontend. I haven't looked over the wx or cocoa specific > stuff, just the general stuff. > > Overall, I am _really_ excited about this code. Many thanks to Barry > and Gael for pushing this stuff forward and making the first go and > using the new core. I talked to Fernando last night and both of us > are completely committed to getting this stuff into the next IPython > release, which is coming soon. I should preface my comments by saying > that I don't think all of the comments need to be address before the > merge or the release. Some of the comments are more long term. Also, > Fernando is going to look over the new stuff in IPython.kernel.core (I > haven't looked at this stuff). > > > Here are my comments: > > =============================== > Comments about IPython.frontend > =============================== > > General > ======= > > We need a robust way for modules in the frontend to handle interfaces > if zope.interface is not installed. Currently each module tries to > import zope.interface and then builds a mock zope.interface, like > this:: > > try: > from zope.interface import Interface, Attribute, implements, classProvides > except ImportError: > Interface = object > def Attribute(name, doc): pass > def implements(interface): pass > def classProvides(interface): pass > > This code should probably be put into a common location, something > like frontend.zopeinterface, so that it can be reused. But eventually > when > IPython.core is created, this should probably be moved there. > > The docstrings are vague and outdated at points. More detailed and > updated docstrings would be helpful. Also, all docstrings should use > the epydoc+ReST format. > > IPython.kernel.core should probably be moved to IPython.core. > > Once Fernando's testing branch has been merged, more tests should be written. > > frontendbase.py > =============== > > Configuration should be done using the approach in IPython.config. > See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for > examples. > > IFrontEnd has references to Twisted in its docstrings. Because the > basic frontend should work without Twisted, the docstrings should be > updated to clarify how the interface plays with Twisted, even though > it is optional. We really want to document for developers that the > base frontend is synchronous and doesn't require Twisted, but that the > interface has a particular design that allows it to be wrapped into an > asynchronous frontend (like some methods pass through the result). > > The design of the frontend seems good though. We might eventually > want to think about using the notification stuff in the frontend > though. > > Why does FrontEndBase not have a complete method? Other frontend > classes do have this method and its seems like the base class should > have it too. Also, there are oher methods in the interpreter that we > might want to propagate up to the frontend, like push and pull. > Thoughts? If these additional methods go in, there should be separate > asynchronous versions that return deferreds, but these would go into > asyncfrontend.py. > > asyncfrontendbase.py > ==================== > > Because this frontend us designed for use with Twisted, I don't think > we need to protect the zope.interface and Twisted imports. Also setting > Failure to Exception will break things as they don't have the same interface. > > Design looks good though. > > linefrontendbase.py > =================== > > This looks good as it is simply a concrete subclass of FrontEndBase. > General comments above about docstrings apply. > > prefilterfrontend.py > ==================== > > It is fantastic that we can combine ipython0 and IPython.kernel.core > code like this. This is a great way of using the new stuff, but > getting the more complete feature set of IPython.* But I think this > type of thing should be done in the lower-level Interpreter, rather > than the frontend. This is for a couple of reasons: > > 1. This would give all users of the Interpreter access to completion and the > prefilter stuff. We really need this stuff in the parallel > computing stuff, > as well as non-line-oriented frontends. > 2. The Interpreter already has some of this logic and it is simply being > repeated. > 3. The current implementation requires that the Interpreter is in-process. > For connecting to a remote Interpreter, this won't work. > > But, we might run into a problem with doing this stuff (that cool hack > that is begin used currently) in the Interpreter. The reason is that > the Interpreter is block based, whereas the prefilter stuff in IPython > is only line based. Thus, doing this refactoring might be a little > more involved. But it is the eventual design we want to go for. This > stuff probably won't be done before the merge. We can work on this at > SciPy. I think we should, as Gael points out, think carefully about design decisions early on. Namely, is there a philosophy about what belongs in the core, what in the Interpreter itself, and what in the, e.g. frontend? I tend to think that the Interpreter should be *just* an enhanced python execution engine, knowing as little as possible about where input comes from or where it goes. Even the terminal frontend is a frontend. Similarly, the more we can separate the concerns of input/output from the Interpreter the easier it is to move things between processes/hosts/etc. later on. I realize there is a tension between those who want a lean, fast, Interpreter and those who want an abstracted, layered architecture. I obviously don't have the solution, but hope that in the coming days/weeks we could all articulate a philosophy or blueprint for where we want things to end up. > > > Great work everyone!!! Thanks. Cheers, Barry > > Brian > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From barrywark at gmail.com Thu Aug 7 19:40:37 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 7 Aug 2008 19:40:37 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <20080807191812.GD26341@phare.normalesup.org> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080807191812.GD26341@phare.normalesup.org> Message-ID: On Thu, Aug 7, 2008 at 3:18 PM, Gael Varoquaux wrote: > Hi Brian, > > Thanks a lot for your comments, they are very valuable. > > I have to run to catch St?fan at the airport, I just wanted to give an > informal overview of the status of my work. I am currently battling with > subprocess execution, including under windows. The hard stuff is the > stdin capture, and it happens more often than I would like. Once I am > done with that (hopefully today, though my afternoon will be busy working > with St?fan), I have to make sure that 'Ctrl-C' stops Python execution, > which should be easy. After this I was planning to clean up the code, add > comments and ask for merge. > > All your comments are very much to the points. Some of them where already > on my todo list. Can you prioritize them, and tell me at which point I > should do the merge. I also would like to merge ASAP, I just don't want > to have bad crashers in the code before I merge (but if you think it is > acceptable, I'll go for it), and I want to refactor some names and > interfaces before the merge. Hopefully merge is a few work days away. Is > that good enough, or should I try to get this done faster? > > Obviously this is a first cut, and there will be some lessons to learn. > >> We need a robust way for modules in the frontend to handle interfaces >> if zope.interface is not installed. Currently each module tries to >> import zope.interface and then builds a mock zope.interface, like >> this:: > >> try: >> from zope.interface import Interface, Attribute, implements, classProvides >> except ImportError: >> Interface = object >> def Attribute(name, doc): pass >> def implements(interface): pass >> def classProvides(interface): pass > >> This code should probably be put into a common location, something >> like frontend.zopeinterface, so that it can be reused. But eventually >> when >> IPython.core is created, this should probably be moved there. > > Sounds good. > >> The docstrings are vague and outdated at points. More detailed and >> updated docstrings would be helpful. Also, all docstrings should use >> the epydoc+ReST format. > > Oh yes, definitely. The docstring are not good enough, and some of the > names are not explicite enough. > >> IPython.kernel.core should probably be moved to IPython.core. > >> Once Fernando's testing branch has been merged, more tests should be written. > > +1. My stuff is hard to test, but I want to have a go and see what I can > do. Please, please have (near) complete test coverage for your work. It will be infinitely harder to make the (likely) needed refactorings in the future if we can't test easily. I've been working on several changes to the internal working of FrontEndBase to make notebook-style interfaces more natural and think that I can keep backwards compatible API, but the implementation may change. Complete test will make integrating those changes much easier. > >> frontendbase.py >> =============== > >> Configuration should be done using the approach in IPython.config. >> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for >> examples. > > OK. > >> IFrontEnd has references to Twisted in its docstrings. Because the >> basic frontend should work without Twisted, the docstrings should be >> updated to clarify how the interface plays with Twisted, even though >> it is optional. We really want to document for developers that the >> base frontend is synchronous and doesn't require Twisted, but that the >> interface has a particular design that allows it to be wrapped into an >> asynchronous frontend (like some methods pass through the result). > >> The design of the frontend seems good though. We might eventually >> want to think about using the notification stuff in the frontend >> though. > >> Why does FrontEndBase not have a complete method? Other frontend >> classes do have this method and its seems like the base class should >> have it too. > > I need to come back on all this and define the interfaces in a more > formal way. Currently this is messy, and I have been coding the frontend > implementation to figure out what the right interface is. So yes, I'll do > that before the merge. > >> Also, there are oher methods in the interpreter that we >> might want to propagate up to the frontend, like push and pull. >> Thoughts? > > Not sure this is urgent. I haven't used them so far. But maybe. I want to > have a "pyshell" interface for my frontend, maybe in a subclass. This is > important as the frontend should be a drop-in replacmeent for pyshell. > >> prefilterfrontend.py >> ==================== > >> It is fantastic that we can combine ipython0 and IPython.kernel.core >> code like this. This is a great way of using the new stuff, but >> getting the more complete feature set of IPython.* But I think this >> type of thing should be done in the lower-level Interpreter, rather >> than the frontend. This is for a couple of reasons: > >> 1. This would give all users of the Interpreter access to completion and the >> prefilter stuff. We really need this stuff in the parallel >> computing stuff, >> as well as non-line-oriented frontends. >> 2. The Interpreter already has some of this logic and it is simply being >> repeated. >> 3. The current implementation requires that the Interpreter is in-process. >> For connecting to a remote Interpreter, this won't work. > > Absolutely. This is an experiment, and I was waiting for Fernando to be > done with his testing to be able to work on that. prefilterfrontend.py > should be called "dirtyhackfrontend.py" IMHO. > >> But, we might run into a problem with doing this stuff (that cool hack >> that is begin used currently) in the Interpreter. The reason is that >> the Interpreter is block based, whereas the prefilter stuff in IPython >> is only line based. Thus, doing this refactoring might be a little >> more involved. But it is the eventual design we want to go for. This >> stuff probably won't be done before the merge. We can work on this at >> SciPy. > > Once again, thanks a lot for your detailed feedback, it is very valuable > to me. > > Ga?l > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Fri Aug 8 05:05:54 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 02:05:54 -0700 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <20080807191812.GD26341@phare.normalesup.org> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080807191812.GD26341@phare.normalesup.org> Message-ID: Howdy, On Thu, Aug 7, 2008 at 12:18 PM, Gael Varoquaux wrote: > Hi Brian, > > Thanks a lot for your comments, they are very valuable. > > I have to run to catch St?fan at the airport, I just wanted to give an > informal overview of the status of my work. I am currently battling with > subprocess execution, including under windows. The hard stuff is the > stdin capture, and it happens more often than I would like. Once I am > done with that (hopefully today, though my afternoon will be busy working > with St?fan), I have to make sure that 'Ctrl-C' stops Python execution, > which should be easy. After this I was planning to clean up the code, add > comments and ask for merge. I'm going to put in here my comments regarding the code in kernel.core, and will send a separate email regarding merge plans, since Barry made some comments on that matter too. Modulo any possible conflicts with Barry's changes that we might need to sort out, I think we can also merge in what you've done, so we have an integrated codebase to work off from at scipy. My comments follow, some are generic about files that were in kernel.core before your branch, and some are specific to your code. Overall I don't see any problem though, so I think it's just a matter of moving forward with minimal collisions. ==================================== Comments about IPython.kernel.core ==================================== General ======= We'll likely push this over as IPython.core, but I'd like to do this after we get this release out. It will be much easier to do this refactoring at SciPy, where at the very least we'll have Brian, Gael, Stefan and myself present, plus other possible volunteers. For now it's OK to do the merge where the code is. General naming comment: we have a ton of modules_with_underscores in their names. In trying to keep to pep-8, let's at least make an effort to not let this grow unnecessarily (while keeping in mind pep-8's first advice, "A Foolish Consistency is the Hobgoblin of Little Minds" :) Note: I'm not being petty here, I actually happen to like the package namespace to use that convention... Some of my comments below relate to code in kernel.core in general, not specifically to Gael's recent changes. Testing ======= Ultimately I'd like us to be able to run a substantial fraction of the test suite against each frontend, to ensure that the basic session runs in each correctly. This won't probe the UI aspects, but it will ensure that all frontends conform to the same uses of the core objects for namespace handling, completion, history, etc. If it's not possible right now to do this, it should be a high priority to enable the current code to run the tests. This might be a job for scipy so we can do it together. In the meantime, I concur with Barry's assessment of the need for more tests. I expect we'll be refactoring like mad at Scipy, and doing so without tests is like juggling dual-edge knifes with no handles. Even if there's no time for detailed coverage, at least having a set of small, near-trivial tests for each file that minimally call the various functions/methods makes a big difference. They may not cover every corner case, but they ensure that key invariants are honored, and they remind you of what API breakage you're likely to incur when moving stuff around. display_formatter.py ==================== [ This file is in trunk, so the comments apply to all of us, not specifically to Gael's changes ] I'm assuming that the return value must always be a string (or None), right? Since this is meant to declare the interface, it should be explicit about the valid return types. display_trap.py =============== [ This file is in trunk, so the comments apply to all of us, not specifically to Gael's changes ] What exactly is the purpose of the callback list? Since the callbacks don't return anything, what exactly are they supposed to do? The slight lack of tests/fuller docstrings already mentioned needs some work. On the topic of docstrings, let's keep to pep-8 convention: one-line summary, blank, full text (using reST format). There are GUI tools that use the one-line summary, and I'd like the GUI ipython versions to provide nice api summaries of objects. This works better if you can assume that the first line is readable by itself. add_to_message doesn't conform to this, for example. __init__ needs a docstring In hook, shouldn't obj be stored first, in case an error is raised by a callback? And how are errors in callbacks handled? fd_redirector ============= I imagine this is the part you've been struggling with, from your comments. We certainly need this to gracefully handle i/o under GUIs. Docstrings and tests are critically needed though, and the docstrings should conform to the reST api for sphinx. All attributes should be declared in the constructor, even if they are set to None with a comment of what they do and that their true value is given later (such as in start() ). The fact that Python allows us to create attributes at any point doesn't mean we should do it in normal code, its a feature whose valid use cases are in decorating/annotating external objects. But classes we write should declare their attribute API completely in the constructor, for readability/comprehensibility reasons. Is it necessary to call stop() in getvalue()? file_like.py ============ - writelines should read simply "map(self.write,lines)". Faster, cleaner, shorter. - why are the other methods implemented as 'pass'? Wouldn't it be better not to have them? Making them pass means they return None, which can lead to them being used by other code which will then strangely break when None is the wrong thing to get. output_trap.py ============== This one implements a smaller set of functionality than the original OutputTrap. Why? Do we need to merge the two? Right now we have in core.shell uses of the old module and in core.interpreter, of the new, so likely some sort of merge will be needed. redirector_output_trap.py ========================= No docstrings on constructor. sync_traceback_trap.py ====================== No docstrings on constructor. The top-level docstring could be a bit more verbose. From fperez.net at gmail.com Fri Aug 8 05:34:44 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 02:34:44 -0700 Subject: [IPython-dev] Release plan for 0.9 Message-ID: Hi all, recently a lot of activity on ipython has been happening in three branches: one for testing support that I'm working on, one for notifications by Barry and one for the wx frontend by Gael. With Scipy fast approaching and Enthought planning an EPD release next week, we'd like to cut a release now. The 'ipython0' functionality will for now remain mostly unchanged, other than being (partly) tested for the first time. Gael's and Barry's work are mostly infrastructure for moving forward, and we have all the IPython1 code now merged in. So the question is how to make this merge happen. Here's the branches we have: 1. Testing support code that lives in https://code.launchpad.net/~ipython/ipython/test-tools That touches code in quite a few places but in a mostly harmless manner, and builds tools for testing that are as of yet a bit developer-only. I'll put the user-sugar on top later. I've made the branch proposed for merging, which shows exactly what revisions haven't been merged yet. Unless anyone sees a problem, I'll merge this tomorrow. 2. Gael's work hasn't been merged at all yet. I marked it for merging: https://code.launchpad.net/~gael-varoquaux/ipython/ipython-sync-frontend 3. Barry's notification branch has been merged. 4. Vivian's editor branch: https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor I'm sorry that I haven't been following this one in detail. Vivian and Ville had been working on it together, is it basically ready for merge? If so, marking it 'proposed for merge' will let us easily review it and see what changesets are different from trunk (I just did that). Ville had some comments on it, have they been addressed by the latest changesets? 5. Ville's pyreadline branch: https://code.launchpad.net/~villemvainio/ipython/pyreadline This branch shows no code yet. Ville, what's your plan on this one? 6. Robert Kern's contexts branch: https://code.launchpad.net/~robert-kern/ipython/contexts Robert, what's your plan on this one? Keep it as branch for now, or push it into this release? 7. Min's daemon branch: https://code.launchpad.net/~ipython/ipython/ipython-daemon Min, what's your take on this? Do you want it merged in, or should we postpone this to work on it at scipy? This is extremely important functionality, but I don't know if it's solid enough for merge yet. I marked it for merging so we can see the differences more easily. # end branches Whew. That's actually a lot... Does anyone else have anything in the pipeline that they want in for a release? Keep in mind that this will be very much a 'tech preview' release, whose purpose is the large codebase integration of ipython0/1. I'm sure we'll see some rough spots, and I hope at Scipy we'll have a chance to work together on smoothing them. So I expect to be putting out a 0.10 fairly close after this. Which means that if a particular feature you have in mind or in a branch isn't quite ready, no worries. 0.10 should be not too far behind. So with this, it would be nice if we could cut an RC for 0.9 on Monday. I'll be likely merging the testing stuff tomorrow, and after that the two big ones seem to be Gael's and Min's. Thoughts? f From fperez.net at gmail.com Fri Aug 8 05:36:20 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 02:36:20 -0700 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: Hi Barry, On Thu, Aug 7, 2008 at 4:36 PM, Barry Wark wrote: > Brian et al., > > I don't have time to give your comments the time they deserve tonight > so I wanted to just weigh in quickly on merging Gael's branch before > the upcoming release. There are some significant changes I want to > make to the frontendbase interface, mainly making the concept of a > execution block more explicit, but I realize Gael has made great > progress with his branch that diverged before I made those changes. I > think the synchronous frontend should be merged in for the release if > possible. I will hold of on my changes until the release has settled > and we have time to evaluate how the newer frontend architecture. I > have just one other comment, in line below, for the moment and will > try to get you a more proper response soon. Do you have a sense of how serious the conflicts are? I've marked Gael's branch and my testing one 'for merge' so we can easily see the differences. And will you be attending SciPy? It seems Brian will be there, and so will Gael and Stefan, so we may have a bunch of people simultaneously available to discuss and hack (and anyone else on the list who will make it to scipy is obviously welcome!). Cheers, f From barrywark at gmail.com Fri Aug 8 10:15:46 2008 From: barrywark at gmail.com (Barry Wark) Date: Fri, 8 Aug 2008 10:15:46 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: On Fri, Aug 8, 2008 at 5:36 AM, Fernando Perez wrote: > Hi Barry, > > On Thu, Aug 7, 2008 at 4:36 PM, Barry Wark wrote: >> Brian et al., >> >> I don't have time to give your comments the time they deserve tonight >> so I wanted to just weigh in quickly on merging Gael's branch before >> the upcoming release. There are some significant changes I want to >> make to the frontendbase interface, mainly making the concept of a >> execution block more explicit, but I realize Gael has made great >> progress with his branch that diverged before I made those changes. I >> think the synchronous frontend should be merged in for the release if >> possible. I will hold of on my changes until the release has settled >> and we have time to evaluate how the newer frontend architecture. I >> have just one other comment, in line below, for the moment and will >> try to get you a more proper response soon. > > Do you have a sense of how serious the conflicts are? I've marked > Gael's branch and my testing one 'for merge' so we can easily see the > differences. Besides trivial chanes (e.g. spliitting frontendbase into frontendbase and asyncfrontendbase et al), the most significant diff between Gael's branch and mine is that I've made the concept of an execution Block more explicit. Instead of just an input string, a block is now an object containing prompts, input and output as well as, possibly, sub-blocks. The Block maps, conceptually, pretty directly to a Mathematica notebook cell (you can see the Block definition in my ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe that the API for FrontEndBase can be made largely backwards compatible, but some of the internal implementation must change to support passing around Blocks instead of just strings. OK, so I'd say the conflicts will not be too serious. They may be serious enough to merge one at a time, especially working up to a release. I'll hold off on my branch until things settle out from Gael's merge. > > And will you be attending SciPy? It seems Brian will be there, and so > will Gael and Stefan, so we may have a bunch of people simultaneously > available to discuss and hack (and anyone else on the list who will > make it to scipy is obviously welcome!). Unfortunately, I can't make it. I'd be happy to check in remotely (Skype etc.) while you all are working if that makes sense. > > Cheers, > f > From barrywark at gmail.com Fri Aug 8 10:24:16 2008 From: barrywark at gmail.com (Barry Wark) Date: Fri, 8 Aug 2008 10:24:16 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080807191812.GD26341@phare.normalesup.org> Message-ID: On Fri, Aug 8, 2008 at 5:05 AM, Fernando Perez wrote: > Howdy, > > On Thu, Aug 7, 2008 at 12:18 PM, Gael Varoquaux > wrote: >> Hi Brian, >> >> Thanks a lot for your comments, they are very valuable. >> >> I have to run to catch St?fan at the airport, I just wanted to give an >> informal overview of the status of my work. I am currently battling with >> subprocess execution, including under windows. The hard stuff is the >> stdin capture, and it happens more often than I would like. Once I am >> done with that (hopefully today, though my afternoon will be busy working >> with St?fan), I have to make sure that 'Ctrl-C' stops Python execution, >> which should be easy. After this I was planning to clean up the code, add >> comments and ask for merge. > > I'm going to put in here my comments regarding the code in > kernel.core, and will send a separate email regarding merge plans, > since Barry made some comments on that matter too. > > Modulo any possible conflicts with Barry's changes that we might need > to sort out, I think we can also merge in what you've done, so we have > an integrated codebase to work off from at scipy. > > My comments follow, some are generic about files that were in > kernel.core before your branch, and some are specific to your code. > Overall I don't see any problem though, so I think it's just a matter > of moving forward with minimal collisions. > > ==================================== > Comments about IPython.kernel.core > ==================================== > > General > ======= > > We'll likely push this over as IPython.core, but I'd like to do this after we > get this release out. It will be much easier to do this refactoring at SciPy, > where at the very least we'll have Brian, Gael, Stefan and myself present, plus > other possible volunteers. For now it's OK to do the merge where the code is. > > General naming comment: we have a ton of modules_with_underscores in their > names. In trying to keep to pep-8, let's at least make an effort to not let > this grow unnecessarily (while keeping in mind pep-8's first advice, "A Foolish > Consistency is the Hobgoblin of Little Minds" :) Note: I'm not being petty > here, I actually happen to like the package namespace to use that convention... > > Some of my comments below relate to code in kernel.core in general, not > specifically to Gael's recent changes. > > > Testing > ======= > > Ultimately I'd like us to be able to run a substantial fraction of the test > suite against each frontend, to ensure that the basic session runs in each > correctly. This won't probe the UI aspects, but it will ensure that all > frontends conform to the same uses of the core objects for namespace handling, > completion, history, etc. If it's not possible right now to do this, it should > be a high priority to enable the current code to run the tests. This might be > a job for scipy so we can do it together. > > In the meantime, I concur with Barry's assessment of the need for more tests. > I expect we'll be refactoring like mad at Scipy, and doing so without tests is > like juggling dual-edge knifes with no handles. > > Even if there's no time for detailed coverage, at least having a set of small, > near-trivial tests for each file that minimally call the various > functions/methods makes a big difference. They may not cover every corner > case, but they ensure that key invariants are honored, and they remind you of > what API breakage you're likely to incur when moving stuff around. > > > display_formatter.py > ==================== > > [ This file is in trunk, so the comments apply to all of us, not specifically > to Gael's changes ] > > I'm assuming that the return value must always be a string (or None), right? > Since this is meant to declare the interface, it should be explicit about the > valid return types. I'd like to play devil's advocate for a minute here: I think display formatting should be done exclusively in the frontend. If not, frontends have no choice what to do with, e.g. matplotlib figures. Putting it in core smells of the poor separation of concerns we have in the ipython0 shell. > > > display_trap.py > =============== > > [ This file is in trunk, so the comments apply to all of us, not specifically > to Gael's changes ] > > What exactly is the purpose of the callback list? Since the callbacks don't > return anything, what exactly are they supposed to do? > > The slight lack of tests/fuller docstrings already mentioned needs some work. > On the topic of docstrings, let's keep to pep-8 convention: one-line summary, > blank, full text (using reST format). There are GUI tools that use the > one-line summary, and I'd like the GUI ipython versions to provide nice api > summaries of objects. This works better if you can assume that the first line > is readable by itself. add_to_message doesn't conform to this, for > example. __init__ needs a docstring > > In hook, shouldn't obj be stored first, in case an error is raised by a > callback? And how are errors in callbacks handled? > > > fd_redirector > ============= > > I imagine this is the part you've been struggling with, from your comments. We > certainly need this to gracefully handle i/o under GUIs. Docstrings and tests > are critically needed though, and the docstrings should conform to the reST api > for sphinx. > > All attributes should be declared in the constructor, even if they are set to > None with a comment of what they do and that their true value is given later > (such as in start() ). The fact that Python allows us to create attributes at > any point doesn't mean we should do it in normal code, its a feature whose > valid use cases are in decorating/annotating external objects. But classes we > write should declare their attribute API completely in the constructor, for > readability/comprehensibility reasons. > > Is it necessary to call stop() in getvalue()? > > file_like.py > ============ > > - writelines should read simply "map(self.write,lines)". Faster, cleaner, > shorter. > > - why are the other methods implemented as 'pass'? Wouldn't it be better not > to have them? Making them pass means they return None, which can lead to > them being used by other code which will then strangely break when None is > the wrong thing to get. > > > output_trap.py > ============== > > This one implements a smaller set of functionality than the original > OutputTrap. Why? Do we need to merge the two? Right now we have in > core.shell uses of the old module and in core.interpreter, of the new, so > likely some sort of merge will be needed. > > > redirector_output_trap.py > ========================= > > No docstrings on constructor. > > > sync_traceback_trap.py > ====================== > > No docstrings on constructor. The top-level docstring could be a bit more > verbose. Again, playing Devi's advocate: Much of what appears to be the function of output_trap, sync_traceback_trap, and display_trap could be handled in frontend by posting notifications from the Interpreter. Doing so would separate these UI concerns (i.e. what to do with the Interpreter's output) from the core function (producing that output). > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From gael.varoquaux at normalesup.org Fri Aug 8 11:43:18 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 8 Aug 2008 17:43:18 +0200 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: <20080808154318.GA32657@phare.normalesup.org> On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote: > > Do you have a sense of how serious the conflicts are? I've marked > > Gael's branch and my testing one 'for merge' so we can easily see the > > differences. > Besides trivial chanes (e.g. spliitting frontendbase into frontendbase > and asyncfrontendbase et al), the most significant diff between Gael's > branch and mine is that I've made the concept of an execution Block > more explicit. Instead of just an input string, a block is now an > object containing prompts, input and output as well as, possibly, > sub-blocks. The Block maps, conceptually, pretty directly to a > Mathematica notebook cell (you can see the Block definition in my > ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe > that the API for FrontEndBase can be made largely backwards > compatible, but some of the internal implementation must change to > support passing around Blocks instead of just strings. > OK, so I'd say the conflicts will not be too serious. They may be > serious enough to merge one at a time, especially working up to a > release. I'll hold off on my branch until things settle out from > Gael's merge. Barry, do you want check in access to my branch to implement these changes. I was waiting to add docstrings and tests before proposing this, but if you think you want to do this ASAP, I don't mind at all. I don't think I'll be able to merge before Sunday, though. Ga?l From barrywark at gmail.com Fri Aug 8 11:57:27 2008 From: barrywark at gmail.com (Barry Wark) Date: Fri, 8 Aug 2008 11:57:27 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <20080808154318.GA32657@phare.normalesup.org> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080808154318.GA32657@phare.normalesup.org> Message-ID: On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux wrote: > On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote: >> > Do you have a sense of how serious the conflicts are? I've marked >> > Gael's branch and my testing one 'for merge' so we can easily see the >> > differences. > >> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase >> and asyncfrontendbase et al), the most significant diff between Gael's >> branch and mine is that I've made the concept of an execution Block >> more explicit. Instead of just an input string, a block is now an >> object containing prompts, input and output as well as, possibly, >> sub-blocks. The Block maps, conceptually, pretty directly to a >> Mathematica notebook cell (you can see the Block definition in my >> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe >> that the API for FrontEndBase can be made largely backwards >> compatible, but some of the internal implementation must change to >> support passing around Blocks instead of just strings. > >> OK, so I'd say the conflicts will not be too serious. They may be >> serious enough to merge one at a time, especially working up to a >> release. I'll hold off on my branch until things settle out from >> Gael's merge. > > > Barry, do you want check in access to my branch to implement these > changes. I was waiting to add docstrings and tests before proposing this, > but if you think you want to do this ASAP, I don't mind at all. I don't > think I'll be able to merge before Sunday, though. Thanks for the offer. I think making even relatively minor architectural changes close before a release, while your code is still under active development, and without *really* good test coverage is dangerous. I'm not going to have time to give this the time it would require before early next week when Fernando wants to push a release. So I'd say the safest & best plan is to let you try to get your code ready for release in time. I'll merge my changes in on the next dev cycle. > > Ga?l > From ellisonbg.net at gmail.com Fri Aug 8 12:50:12 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 8 Aug 2008 10:50:12 -0600 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080808154318.GA32657@phare.normalesup.org> Message-ID: <6ce0ac130808080950m224f7eaal31ad0de64f135626@mail.gmail.com> Hello all, Unfortunately, today is the day that we are moving into our new place. Thus, I will be mostly offline until early next week unless I can sneak out to a coffee house some night. Fernando can help make any decisions about how to proceed with the merges. Thanks again everyone for helping out. Cheers, Brian On Fri, Aug 8, 2008 at 9:57 AM, Barry Wark wrote: > On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux > wrote: >> On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote: >>> > Do you have a sense of how serious the conflicts are? I've marked >>> > Gael's branch and my testing one 'for merge' so we can easily see the >>> > differences. >> >>> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase >>> and asyncfrontendbase et al), the most significant diff between Gael's >>> branch and mine is that I've made the concept of an execution Block >>> more explicit. Instead of just an input string, a block is now an >>> object containing prompts, input and output as well as, possibly, >>> sub-blocks. The Block maps, conceptually, pretty directly to a >>> Mathematica notebook cell (you can see the Block definition in my >>> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe >>> that the API for FrontEndBase can be made largely backwards >>> compatible, but some of the internal implementation must change to >>> support passing around Blocks instead of just strings. >> >>> OK, so I'd say the conflicts will not be too serious. They may be >>> serious enough to merge one at a time, especially working up to a >>> release. I'll hold off on my branch until things settle out from >>> Gael's merge. >> >> >> Barry, do you want check in access to my branch to implement these >> changes. I was waiting to add docstrings and tests before proposing this, >> but if you think you want to do this ASAP, I don't mind at all. I don't >> think I'll be able to merge before Sunday, though. > > Thanks for the offer. I think making even relatively minor > architectural changes close before a release, while your code is still > under active development, and without *really* good test coverage is > dangerous. I'm not going to have time to give this the time it would > require before early next week when Fernando wants to push a release. > So I'd say the safest & best plan is to let you try to get your code > ready for release in time. I'll merge my changes in on the next dev > cycle. > >> >> Ga?l >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From robert.kern at gmail.com Fri Aug 8 16:00:02 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 08 Aug 2008 15:00:02 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: Fernando Perez wrote: > 6. Robert Kern's contexts branch: > > https://code.launchpad.net/~robert-kern/ipython/contexts > > Robert, what's your plan on this one? Keep it as branch for now, or > push it into this release? I think it can be pushed. -- 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 gael.varoquaux at normalesup.org Fri Aug 8 16:24:39 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 8 Aug 2008 22:24:39 +0200 Subject: [IPython-dev] ipython1 and synchronous printing of stdout In-Reply-To: <200808082218.50243.hans_meine@gmx.net> References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com> <200808081211.23827.hans_meine@gmx.net> <20080808132359.GB11088@phare.normalesup.org> <200808082218.50243.hans_meine@gmx.net> Message-ID: <20080808202439.GB8104@phare.normalesup.org> On Fri, Aug 08, 2008 at 10:18:49PM +0200, Hans Meine wrote: > > * I execute sub-processes with anonimous-pipes as their stdin/stdout > > and use a separate thread to empty these pipes onto the screen > > without blocking. > Hmm - since I did not write a frontend to ipython with its "!" facility, I am > not sure I ever tried this. Wouldn't the filedescriptor-method also work for > os.system/subprocess.calls? Hum, not really, it is cleaner to use pipe, as it allows to make sure that stdin is in sync with stdout and stderr. That was _hard_ by the way. > > I am anyhow interested in your ideas for that, do mind posting the link > > to the discussion you refer to? My google foo doesn't seem to be > > good-enough to find it. > To be honest - if I knew how to find it again, I would have sent the link in > the first place. > After some digging, I finally found it, it was in the "Changes to Notebook > Format" thread, and it turns out that Robert Kern actually was the one who > came up with the working solution. I only later send his code (with > attribution) to C++-Sig, when the question was discussed there, too. > http://mlblog.osdir.com/python.ipython.devel/2005-08/ OK, I use this, but this by itself is not sufficient, because you want to have trap to shell back out in the GUI mainloop to refresh the screen and process events like "Ctrl-C" every once in a while (once again, multi-threading is unacceptable, because the GUI toolkits that we have are not thread-safe (none is), and it would lead to crashers when the users would input code that interacted with the GUI toolkit. I have to build an event-driven design, but not a multithreaded design. OK, back to doc-string writing, and test-writing. Ga?l From fperez.net at gmail.com Fri Aug 8 18:41:23 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 15:41:23 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Fri, Aug 8, 2008 at 1:00 PM, Robert Kern wrote: > Fernando Perez wrote: >> 6. Robert Kern's contexts branch: >> >> https://code.launchpad.net/~robert-kern/ipython/contexts >> >> Robert, what's your plan on this one? Keep it as branch for now, or >> push it into this release? > > I think it can be pushed. I see these issues (doing this on trunk): lon[IPython]> grin make_user_ns ./Shell.py: 567 : user_ns = IPython.ipapi.make_user_ns(user_ns) ./ipapi.py: 562 : def make_user_ns(user_ns = None): 586 : Similar to make_user_ns(), but global namespaces are really only needed in ./iplib.py: 287 : user_ns = IPython.ipapi.make_user_ns(user_ns) I don't see your changeset addressing either the Shell or the iplib uses of this, do they? The Shell one is in the matplotlib Shell class. I've now grabbed your branch, so I can test easily if you make fixes and we can merge. These changes are small and localized enough that once we address this, I'm happy to do it. It would also be good if you add proper reST parameter descriptions to the docstrings of the new functions you wrote. Cheers, f From fperez.net at gmail.com Fri Aug 8 18:49:15 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 15:49:15 -0700 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: On Fri, Aug 8, 2008 at 7:15 AM, Barry Wark wrote: > Besides trivial chanes (e.g. spliitting frontendbase into frontendbase > and asyncfrontendbase et al), the most significant diff between Gael's > branch and mine is that I've made the concept of an execution Block > more explicit. Instead of just an input string, a block is now an > object containing prompts, input and output as well as, possibly, > sub-blocks. The Block maps, conceptually, pretty directly to a > Mathematica notebook cell (you can see the Block definition in my > ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe > that the API for FrontEndBase can be made largely backwards > compatible, but some of the internal implementation must change to > support passing around Blocks instead of just strings. > > OK, so I'd say the conflicts will not be too serious. They may be > serious enough to merge one at a time, especially working up to a > release. I'll hold off on my branch until things settle out from > Gael's merge. Sounds good. Yes, I do worry about breaking too much right before a release. Even though we know this will be somewhat of a 'tech preview' release, we don't want to have a massive mess for users. I'm working on reviewing the other branches and merging the rest right now. >> And will you be attending SciPy? It seems Brian will be there, and so >> will Gael and Stefan, so we may have a bunch of people simultaneously >> available to discuss and hack (and anyone else on the list who will >> make it to scipy is obviously welcome!). > > Unfortunately, I can't make it. I'd be happy to check in remotely > (Skype etc.) while you all are working if that makes sense. Bummer. We'll irc/skype then. We should plan on having you come down to Berkeley sometime later though. I'll look into the logistics of a sprint at Berkeley for perhaps early next year. Cheers, f From fperez.net at gmail.com Fri Aug 8 19:38:03 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Aug 2008 16:38:03 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Fri, Aug 8, 2008 at 2:34 AM, Fernando Perez wrote: > Hi all, > > recently a lot of activity on ipython has been happening in three > branches: one for testing support that I'm working on, one for > notifications by Barry and one for the wx frontend by Gael. With > Scipy fast approaching and Enthought planning an EPD release next > week, we'd like to cut a release now. The 'ipython0' functionality > will for now remain mostly unchanged, other than being (partly) tested > for the first time. Gael's and Barry's work are mostly infrastructure > for moving forward, and we have all the IPython1 code now merged in. > > So the question is how to make this merge happen. Here's the branches we have: > > 1. Testing support code that lives in > > https://code.launchpad.net/~ipython/ipython/test-tools > > That touches code in quite a few places but in a mostly harmless > manner, and builds tools for testing that are as of yet a bit > developer-only. I'll put the user-sugar on top later. > > I've made the branch proposed for merging, which shows exactly what > revisions haven't been merged yet. Unless anyone sees a problem, I'll > merge this tomorrow. OK, this has been merged into trunk. I'll do some more work on it, but the key pieces are all in. I should warn that some convenience routines aren't in place yet, so you can't quite do something like run 'ipython-test' at a shell. But I don't want to worry about that yet, until a key namespace handling issue is fixed. If any of the devs is interested in playing with it, there's a little Makefile in IPython/testing/plugin that does all the nose plugin installation/test running for you as a convenience. Just edit the install path for the nose plugin at the top. Later I'll add a top-level user script that handles all this transparently. Cheers, f From jdh2358 at gmail.com Sat Aug 9 11:57:20 2008 From: jdh2358 at gmail.com (John Hunter) Date: Sat, 9 Aug 2008 10:57:20 -0500 Subject: [IPython-dev] foolscap Message-ID: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com> I was just playing around with ipython1, and noticed that the foolscap dependency is not listed at http://ipython.scipy.org/doc/ipython1/html/install.html. I didn't catch this til runtime when I got a traceback about the foolscap ImportError -- I'm attaching a check_for_foolscap patch against the bzr trunk which will catch this at build time Brian, I am finally returning to the project you helped me with many moons ago when you wrote the event_client and event_server examples for me using the perspective broker framework. I see on the foolscap page that it is intended as a replacement for the pb, and I wanted to know if I should be using it instead. I see from a previous post that you will be busy moving this weekend but let me know when your schedule frees up because I might try and bend your ear a bit for some more advice on this project... Thanks, JDH -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.patch Type: application/octet-stream Size: 2049 bytes Desc: not available URL: From barrywark at gmail.com Sat Aug 9 12:16:37 2008 From: barrywark at gmail.com (Barry Wark) Date: Sat, 9 Aug 2008 12:16:37 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: On Fri, Aug 8, 2008 at 6:49 PM, Fernando Perez wrote: > On Fri, Aug 8, 2008 at 7:15 AM, Barry Wark wrote: > >> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase >> and asyncfrontendbase et al), the most significant diff between Gael's >> branch and mine is that I've made the concept of an execution Block >> more explicit. Instead of just an input string, a block is now an >> object containing prompts, input and output as well as, possibly, >> sub-blocks. The Block maps, conceptually, pretty directly to a >> Mathematica notebook cell (you can see the Block definition in my >> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe >> that the API for FrontEndBase can be made largely backwards >> compatible, but some of the internal implementation must change to >> support passing around Blocks instead of just strings. >> >> OK, so I'd say the conflicts will not be too serious. They may be >> serious enough to merge one at a time, especially working up to a >> release. I'll hold off on my branch until things settle out from >> Gael's merge. > > Sounds good. Yes, I do worry about breaking too much right before a > release. Even though we know this will be somewhat of a 'tech > preview' release, we don't want to have a massive mess for users. > > I'm working on reviewing the other branches and merging the rest right now. I think that's the best plan. Thanks for managing the merging. > >>> And will you be attending SciPy? It seems Brian will be there, and so >>> will Gael and Stefan, so we may have a bunch of people simultaneously >>> available to discuss and hack (and anyone else on the list who will >>> make it to scipy is obviously welcome!). >> >> Unfortunately, I can't make it. I'd be happy to check in remotely >> (Skype etc.) while you all are working if that makes sense. > > Bummer. We'll irc/skype then. We should plan on having you come down > to Berkeley sometime later though. I'll look into the logistics of a > sprint at Berkeley for perhaps early next year. > > Cheers, > > f > From fperez.net at gmail.com Sat Aug 9 16:26:55 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 9 Aug 2008 13:26:55 -0700 Subject: [IPython-dev] foolscap In-Reply-To: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com> References: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com> Message-ID: Hey John, On Sat, Aug 9, 2008 at 8:57 AM, John Hunter wrote: > I was just playing around with ipython1, and noticed that the foolscap > dependency is not listed at > http://ipython.scipy.org/doc/ipython1/html/install.html. I didn't > catch this til runtime when I got a traceback about the foolscap > ImportError -- I'm attaching a check_for_foolscap patch against the > bzr trunk which will catch this at build time Sorry, we need to just remove those docs altogether. Now that all the IPython1 code has been merged in, there's no need for that anymore. And in the bzr trunk, foolscap is correctly checked for at setup time. We're merging in all the code for a release, and I'll try to work on cleaning up the docs at the site later to avoid these traps for the unwary. Cheers, f From gael.varoquaux at normalesup.org Sat Aug 9 18:17:33 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 10 Aug 2008 00:17:33 +0200 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> Message-ID: <20080809221733.GA30048@phare.normalesup.org> On Thu, Aug 07, 2008 at 11:11:00AM -0700, Brian Granger wrote: > We need a robust way for modules in the frontend to handle interfaces > if zope.interface is not installed. Currently each module tries to > import zope.interface and then builds a mock zope.interface, like > this:: > try: > from zope.interface import Interface, Attribute, implements, classProvides > except ImportError: > Interface = object > def Attribute(name, doc): pass > def implements(interface): pass > def classProvides(interface): pass > This code should probably be put into a common location, something > like frontend.zopeinterface, so that it can be reused. Done. > The docstrings are vague and outdated at points. More detailed and > updated docstrings would be helpful. Also, all docstrings should use > the epydoc+ReST format. Done. > Configuration should be done using the approach in IPython.config. > See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for > examples. I am not sure what you mean here. I don't see anything in the current IPython.kernel.config that is of direct use to the frontends. I do agree that in the long run we want to move to that, but right now I was more focussed on getting the frontend right, and punting on configuration. It can be added later when we are happy with one frontend at least, when the code is well documented and tested. I would say this is low priority. > IFrontEnd has references to Twisted in its docstrings. Because the > basic frontend should work without Twisted, the docstrings should be > updated to clarify how the interface plays with Twisted, even though > it is optional. We really want to document for developers that the > base frontend is synchronous and doesn't require Twisted, but that the > interface has a particular design that allows it to be wrapped into an > asynchronous frontend (like some methods pass through the result). Done. However, some methods in there do not make sens in a synchronous frontend (update_cell_prompt, add_block_id_for_result, add_block_id_for_failure, compile_ast). I suggest moving them in the asyncfrontend, as right now they are just making it hard for the developper to figure out what the core interface of a frontend is. > The design of the frontend seems good though. We might eventually > want to think about using the notification stuff in the frontend > though. Sure, we can talk about this at SciPy. > Why does FrontEndBase not have a complete method? Other frontend > classes do have this method and its seems like the base class should > have it too. Also, there are oher methods in the interpreter that we > might want to propagate up to the frontend, like push and pull. > Thoughts? If these additional methods go in, there should be separate > asynchronous versions that return deferreds, but these would go into > asyncfrontend.py. Done. The methods grew organicaly from my needs to implement the front-end. And I suspect some more will come for some speicif needs. > asyncfrontendbase.py > ==================== > Because this frontend us designed for use with Twisted, I don't think > we need to protect the zope.interface and Twisted imports. Also setting > Failure to Exception will break things as they don't have the same interface. Done. > linefrontendbase.py > =================== > This looks good as it is simply a concrete subclass of FrontEndBase. > General comments above about docstrings apply. Done. > prefilterfrontend.py > ==================== > It is fantastic that we can combine ipython0 and IPython.kernel.core > code like this. This is a great way of using the new stuff, but > getting the more complete feature set of IPython.* But I think this > type of thing should be done in the lower-level Interpreter, rather > than the frontend. This is for a couple of reasons: > 1. This would give all users of the Interpreter access to completion and the > prefilter stuff. We really need this stuff in the parallel > computing stuff, > as well as non-line-oriented frontends. > 2. The Interpreter already has some of this logic and it is simply being > repeated. > 3. The current implementation requires that the Interpreter is in-process. > For connecting to a remote Interpreter, this won't work. I fully agree with you. I would even state that the way forward with this is to abstract out of IPlib the methods used in prefilter frontend, fix things that don't feel right with them (eg that some code is actual executed during the prefiltering), and move them out of this file, into the interpreter. This file should get thinner and thinner as we move forward, and eventually disappear. I see it as a way to transisition softly from ipython0 to ipython1. It is a stop-gap solution. By the way, I have just pushed a cleanup of my branch. I have added docstrings and reorganized the code. I'd be happy to have some feedback on where things are hard it understand and where names or docs could be improved. Will now work on tests. Ga?l From barrywark at gmail.com Sun Aug 10 13:40:20 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 10 Aug 2008 13:40:20 -0400 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <20080809221733.GA30048@phare.normalesup.org> References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com> <20080809221733.GA30048@phare.normalesup.org> Message-ID: On Sat, Aug 9, 2008 at 6:17 PM, Gael Varoquaux wrote: > On Thu, Aug 07, 2008 at 11:11:00AM -0700, Brian Granger wrote: >> We need a robust way for modules in the frontend to handle interfaces >> if zope.interface is not installed. Currently each module tries to >> import zope.interface and then builds a mock zope.interface, like >> this:: > >> try: >> from zope.interface import Interface, Attribute, implements, classProvides >> except ImportError: >> Interface = object >> def Attribute(name, doc): pass >> def implements(interface): pass >> def classProvides(interface): pass > >> This code should probably be put into a common location, something >> like frontend.zopeinterface, so that it can be reused. > > Done. > >> The docstrings are vague and outdated at points. More detailed and >> updated docstrings would be helpful. Also, all docstrings should use >> the epydoc+ReST format. > > Done. > >> Configuration should be done using the approach in IPython.config. >> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for >> examples. > > I am not sure what you mean here. I don't see anything in the current > IPython.kernel.config that is of direct use to the frontends. I do agree > that in the long run we want to move to that, but right now I was more > focussed on getting the frontend right, and punting on configuration. It > can be added later when we are happy with one frontend at least, when the > code is well documented and tested. I would say this is low priority. > >> IFrontEnd has references to Twisted in its docstrings. Because the >> basic frontend should work without Twisted, the docstrings should be >> updated to clarify how the interface plays with Twisted, even though >> it is optional. We really want to document for developers that the >> base frontend is synchronous and doesn't require Twisted, but that the >> interface has a particular design that allows it to be wrapped into an >> asynchronous frontend (like some methods pass through the result). > > Done. However, some methods in there do not make sens in a synchronous > frontend (update_cell_prompt, add_block_id_for_result, > add_block_id_for_failure, compile_ast). I suggest moving them in the > asyncfrontend, as right now they are just making it hard for the > developper to figure out what the core interface of a frontend is. I disagree; they can make just as much sense in a synchronous frontend as in an ansychronous one. If you chose not to use them in your implementation, that's your choice as implementor. > > >> The design of the frontend seems good though. We might eventually >> want to think about using the notification stuff in the frontend >> though. > > Sure, we can talk about this at SciPy. > >> Why does FrontEndBase not have a complete method? Other frontend >> classes do have this method and its seems like the base class should >> have it too. Also, there are oher methods in the interpreter that we >> might want to propagate up to the frontend, like push and pull. >> Thoughts? If these additional methods go in, there should be separate >> asynchronous versions that return deferreds, but these would go into >> asyncfrontend.py. > > Done. The methods grew organicaly from my needs to implement the > front-end. And I suspect some more will come for some speicif needs. > >> asyncfrontendbase.py >> ==================== > >> Because this frontend us designed for use with Twisted, I don't think >> we need to protect the zope.interface and Twisted imports. Also setting >> Failure to Exception will break things as they don't have the same interface. > > Done. > >> linefrontendbase.py >> =================== > >> This looks good as it is simply a concrete subclass of FrontEndBase. >> General comments above about docstrings apply. > > Done. > >> prefilterfrontend.py >> ==================== > >> It is fantastic that we can combine ipython0 and IPython.kernel.core >> code like this. This is a great way of using the new stuff, but >> getting the more complete feature set of IPython.* But I think this >> type of thing should be done in the lower-level Interpreter, rather >> than the frontend. This is for a couple of reasons: > >> 1. This would give all users of the Interpreter access to completion and the >> prefilter stuff. We really need this stuff in the parallel >> computing stuff, >> as well as non-line-oriented frontends. >> 2. The Interpreter already has some of this logic and it is simply being >> repeated. >> 3. The current implementation requires that the Interpreter is in-process. >> For connecting to a remote Interpreter, this won't work. > > I fully agree with you. I would even state that the way forward with this > is to abstract out of IPlib the methods used in prefilter frontend, fix > things that don't feel right with them (eg that some code is actual > executed during the prefiltering), and move them out of this file, into > the interpreter. This file should get thinner and thinner as we move > forward, and eventually disappear. I see it as a way to transisition > softly from ipython0 to ipython1. It is a stop-gap solution. > > By the way, I have just pushed a cleanup of my branch. I have added > docstrings and reorganized the code. I'd be happy to have some feedback > on where things are hard it understand and where names or docs could be > improved. > > Will now work on tests. > > Ga?l > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From robert.kern at gmail.com Mon Aug 11 00:31:00 2008 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 10 Aug 2008 23:31:00 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: Fernando Perez wrote: > On Fri, Aug 8, 2008 at 1:00 PM, Robert Kern wrote: >> Fernando Perez wrote: >>> 6. Robert Kern's contexts branch: >>> >>> https://code.launchpad.net/~robert-kern/ipython/contexts >>> >>> Robert, what's your plan on this one? Keep it as branch for now, or >>> push it into this release? >> I think it can be pushed. > > I see these issues (doing this on trunk): > > lon[IPython]> grin make_user_ns > ./Shell.py: > 567 : user_ns = IPython.ipapi.make_user_ns(user_ns) > ./ipapi.py: > 562 : def make_user_ns(user_ns = None): > 586 : Similar to make_user_ns(), but global namespaces are > really only needed in > ./iplib.py: > 287 : user_ns = IPython.ipapi.make_user_ns(user_ns) > > > I don't see your changeset addressing either the Shell or the iplib > uses of this, do they? The Shell one is in the matplotlib Shell > class. The iplib one was already gone. The Shell one will be gone as soon as I remember how to push to launchpad again. > I've now grabbed your branch, so I can test easily if you make fixes > and we can merge. These changes are small and localized enough that > once we address this, I'm happy to do it. It would also be good if > you add proper reST parameter descriptions to the docstrings of the > new functions you wrote. :Parameters: something : type Description. :Returns: Description. Right? -- 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 Mon Aug 11 02:53:26 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 10 Aug 2008 23:53:26 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: >> I don't see your changeset addressing either the Shell or the iplib >> uses of this, do they? The Shell one is in the matplotlib Shell >> class. > > The iplib one was already gone. The Shell one will be gone as soon as I remember > how to push to launchpad again. Great, thanks. I'll then pull and merge. >> I've now grabbed your branch, so I can test easily if you make fixes >> and we can merge. These changes are small and localized enough that >> once we address this, I'm happy to do it. It would also be good if >> you add proper reST parameter descriptions to the docstrings of the >> new functions you wrote. > > :Parameters: > something : type > Description. > > :Returns: > Description. Yup, we're using epydoc-rest. At scipy I'd like to talk with everyone about uniformizing doc standards (M. Droetboom who did the lion's share of the work for MPL will be there). It would be nice if ipython/numpy/scipy/matplotlib/mayavi2/sympy all used the same doc standard (we're already using sphinx in several of these, I think it's worth integrating further). Cheers, f From fperez.net at gmail.com Mon Aug 11 13:40:17 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 10:40:17 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Sun, Aug 10, 2008 at 11:53 PM, Fernando Perez wrote: > about uniformizing doc standards (M. Droetboom who did the lion's > share of the work for MPL will be there). It would be nice if BTW, in my haste to compose this message, I inadvertently glossed over the fact that the mpl team had its own documentation marathon, where Darren Dale, Eric Firing, John Hunter (and likely others) all put a great amount of work. I shouldn't have put a single name on that message for something that's been a great collective effort (they have several hundred pages of docs by now!). My apologies to those in the mpl team I left aside... Cheers, f From gael.varoquaux at normalesup.org Mon Aug 11 14:44:31 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 11 Aug 2008 20:44:31 +0200 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend (fwd) Message-ID: <20080811184431.GH31632@phare.normalesup.org> Forgot to Cc the mailing list. ----- Forwarded message from Gael Varoquaux ----- Date: Mon, 11 Aug 2008 20:43:43 +0200 From: Gael Varoquaux To: Fernando Perez Subject: Re: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend On Fri, Aug 08, 2008 at 02:05:54AM -0700, Fernando Perez wrote: > fd_redirector > ============= > I imagine this is the part you've been struggling with, from your comments. Partly, but that's only a tiny fraction of the tip of the iceberg. The hardest part was embedding all this in a GUI loop and try to stay interestive without threads. > We certainly need this to gracefully handle i/o under GUIs. Docstrings > and tests are critically needed though, and the docstrings should > conform to the reST api for sphinx. Docstring and tests are now there. All this should work under windows, including the tests. > All attributes should be declared in the constructor, even if they are set to > None with a comment of what they do and that their true value is given later > (such as in start() ). The fact that Python allows us to create attributes at > any point doesn't mean we should do it in normal code, its a feature whose > valid use cases are in decorating/annotating external objects. But classes we > write should declare their attribute API completely in the constructor, for > readability/comprehensibility reasons. > Is it necessary to call stop() in getvalue()? Pretty much. I think I need to close the file descriptor, and redo the duplication, so I pretty much need to implement the stop method in the getvalue. > file_like.py > ============ > - writelines should read simply "map(self.write,lines)". Faster, cleaner, > shorter. Done. > - why are the other methods implemented as 'pass'? Wouldn't it be better not > to have them? Making them pass means they return None, which can lead to > them being used by other code which will then strangely break when None is > the wrong thing to get. I have to implement them to satisfy the file-interface. I have documented this requirement in the code, now. > output_trap.py > ============== > This one implements a smaller set of functionality than the original > OutputTrap. Why? Do we need to merge the two? Right now we have in > core.shell uses of the old module and in core.interpreter, of the new, so > likely some sort of merge will be needed. Hum, I am not too sure I am following. I haven't created a second implementation of something, AFAIK. > redirector_output_trap.py > ========================= > No docstrings on constructor. Fixed. > sync_traceback_trap.py > ====================== > No docstrings on constructor. The top-level docstring could be a bit more > verbose. I improved this, but I must admit I don't fully understand the way traceback_trap is supposed to work (no docstrings), so I cannot fully document this object? I now feel that the branch is in good-enough shape to be merged in. Obviously there still is some work to be done (more test for a better coverage, althought the GUI frontends are pretty much impossible to test). I however feel that we should merge ASAP, and that I will continue to work on this in the trunk. I would appreciate another quick review to check that everything is in order, and for more feedback. Ga?l ----- End forwarded message ----- From gael.varoquaux at normalesup.org Mon Aug 11 19:00:35 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 01:00:35 +0200 Subject: [IPython-dev] Test failures Message-ID: <20080811230035.GC30181@phare.normalesup.org> Hi, I have synced my branch with trunk, and I currently have 3 test failing, 2 of which I know are just noise: =============================================================================== File "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/tests/test_cocoa_frontend.py", line 21, in from IPython.frontend.cocoa.cocoa_frontend import IPythonCocoaController File "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/cocoa_frontend.py", line 28, in import objc ImportError: No module named objc =============================================================================== and =============================================================================== File "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/tests/test_enginefc.py", line 27, in from IPython.kernel.fcutil import Tub, UnauthenticatedTub File "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/fcutil.py", line 20, in from foolscap import Tub, UnauthenticatedTub ImportError: No module named foolscap =============================================================================== These tests should be skipped if objc or foolscap cannot be imported. In addition, I have a test failing for which I am not sure where the problem is: ====================================================================== FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py", line 37, in testExecute self.assertEquals(result, dict(zip(resultKeys,c))) AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '', 'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '', 'stdout': '6.2831853071795862\n'} ---------------------------------------------------------------------- Does this test run on other people's box? If so, I'll look at it more closely. Cheers, Ga?l From fperez.net at gmail.com Mon Aug 11 19:07:00 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 16:07:00 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: > The iplib one was already gone. The Shell one will be gone as soon as I remember > how to push to launchpad again. Care to push? I'm merging... Cheers, f From fperez.net at gmail.com Mon Aug 11 19:43:53 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 16:43:53 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080811230035.GC30181@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 4:00 PM, Gael Varoquaux wrote: > Hi, > > I have synced my branch with trunk, and I currently have 3 test failing, > 2 of which I know are just noise: > > =============================================================================== > File > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/tests/test_cocoa_frontend.py", > line 21, in > from IPython.frontend.cocoa.cocoa_frontend import > IPythonCocoaController > File > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/cocoa_frontend.py", > line 28, in > import objc > ImportError: No module named objc > =============================================================================== > > and > > =============================================================================== > File > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/tests/test_enginefc.py", > line 27, in > from IPython.kernel.fcutil import Tub, UnauthenticatedTub > File > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/fcutil.py", > line 20, in > from foolscap import Tub, UnauthenticatedTub > ImportError: No module named foolscap > =============================================================================== > These tests should be skipped if objc or foolscap cannot be imported. Both of these later we should mark with skipif() decorators for that purpose. > In addition, I have a test failing for which I am not sure where the > problem is: > > ====================================================================== > FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py", > line 37, in testExecute > self.assertEquals(result, dict(zip(resultKeys,c))) > AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '', > 'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': > '', 'stdout': '6.2831853071795862\n'} > > ---------------------------------------------------------------------- > > Does this test run on other people's box? If so, I'll look at it more > closely. Passes here. Cheers, f From robert.kern at gmail.com Mon Aug 11 19:53:03 2008 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 11 Aug 2008 18:53:03 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: Fernando Perez wrote: > On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: > >> The iplib one was already gone. The Shell one will be gone as soon as I remember >> how to push to launchpad again. > > Care to push? I'm merging... Pushed sans docstrings. Still on vacation. Tired from flight. Sleepytime for me. -- 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 Mon Aug 11 20:12:57 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 17:12:57 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern wrote: > Fernando Perez wrote: >> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: >> >>> The iplib one was already gone. The Shell one will be gone as soon as I remember >>> how to push to launchpad again. >> >> Care to push? I'm merging... > > Pushed sans docstrings. Still > on vacation. Tired from flight. > Sleepytime for me. Sorry, I didn't realize you were on vacation! Sleep, no worries. Cheers, f From fperez.net at gmail.com Mon Aug 11 21:05:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 18:05:36 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern wrote: > Fernando Perez wrote: >> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: >> >>> The iplib one was already gone. The Shell one will be gone as soon as I remember >>> how to push to launchpad again. >> >> Care to push? I'm merging... > > Pushed sans docstrings. Still > on vacation. Tired from flight. > Sleepytime for me. OK, I just merged and pushed to trunk your changes. Let me know as you update the branch and I can merge the rest and push it into trunk. Cheers, f From fperez.net at gmail.com Mon Aug 11 21:38:06 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 18:38:06 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com> References: <489CA6B9.5060006@vdesmedt.com> <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com> Message-ID: On Sat, Aug 9, 2008 at 12:34 AM, Ville M. Vainio wrote: > On Fri, Aug 8, 2008 at 11:08 PM, Fernando Perez wrote: > >> Great, thanks. I'll have a look then. Ville, do you have any other >> specific comments or concerns here, or should I proceed with the merge >> right away? > > No specific comments, so merge ahead. Mmh, I was getting ready to merge and push, but then I went and looked at the code, and I see the whole thing is written in camelCase(): http://bazaar.launchpad.net/%7Evivian-vdesmedt/ipython/synchronize-editor/annotate/1007?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1 Why is that the case? For all new code, we are really trying to stick to proper PEP-8 within reason, and I don't want to violate that unless there's a good motive for it. I also don't see any docstrings in any of the functions at all. Vivian, I realize that this may be a bit painful, but as you can see, we're now making an honest effort at building a much higher quality codebase for IPython, so that all code that goes in is reviewed, documented and tested. And we are all living by the same rules (see recent reviews on other branches, and all the work that has gone into having testing machinery for ipython itself). With bzr and launchpad, it's relatively easy for you to track the trunk (simply keep merging from trunk into your working branch and pushing back upstream frequently), so that your branch stays up to date, as you improve it. But I really think that we can't merge this code in until it's properly documented and it matches the naming conventions of the rest of the project. I realize it's a bit frustrating at this point, but hopefully it's clear to you that these rules are there to ensure that as the whole project grows in a very healthy fashion. We're getting more new code coming in than any one of us can handle individually, and the only way we won't crumble under the weight is to enforce that all this new code is compliant with the rest of the project, documented and automatically tested. Regards, f ps - I've added the above as a branch review comment on launchpad as well. From gael.varoquaux at normalesup.org Mon Aug 11 22:23:20 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 04:23:20 +0200 Subject: [IPython-dev] Test failures In-Reply-To: References: <20080811230035.GC30181@phare.normalesup.org> Message-ID: <20080812022320.GA27447@phare.normalesup.org> On Mon, Aug 11, 2008 at 04:43:53PM -0700, Fernando Perez wrote: > > In addition, I have a test failing for which I am not sure where the > > problem is: > > ====================================================================== > > FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest) > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py", > > line 37, in testExecute > > self.assertEquals(result, dict(zip(resultKeys,c))) > > AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '', > > 'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': > > '', 'stdout': '6.2831853071795862\n'} > > ---------------------------------------------------------------------- > > Does this test run on other people's box? If so, I'll look at it more > > closely. > Passes here. OK, the problem is that, in some of my test, I use code that calls ipmaker.make_IPython(). As a result, the output gets trap, and apparently I do not free it well-enough. Any clue to how to free this output? I think the problem comes from there because if I comment this line out, or if I do not include these tests, the test we are worried about passes. Cheers, Ga?l From fperez.net at gmail.com Mon Aug 11 22:42:48 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 19:42:48 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812022320.GA27447@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 7:23 PM, Gael Varoquaux wrote: > OK, the problem is that, in some of my test, I use code that calls > ipmaker.make_IPython(). As a result, the output gets trap, and apparently > I do not free it well-enough. Any clue to how to free this output? Do you actually need to use make_ipython? Would it work for you instead to get the ipython isntance via ipapi.get()? Because explicitly calling make_ip forces the creation of a new, full ipython instance, and there's enough global noise in there that things are likely to break. Yes, we need to work on making it safer to have an arbitrary number of ipython instances running, but this is historical cruft from when ipython was only 'the interpreter', so it was coded with all kinds of global side effects. Cheers, f From gael.varoquaux at normalesup.org Mon Aug 11 23:03:17 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 05:03:17 +0200 Subject: [IPython-dev] Test failures In-Reply-To: References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> Message-ID: <20080812030317.GA6567@phare.normalesup.org> On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote: > Do you actually need to use make_ipython? Would it work for you > instead to get the ipython isntance via ipapi.get()? Well, I need a ipython instance, and I need to create it, so I do believe I need to call make_ipython. Still working on that,... Ga?l From gael.varoquaux at normalesup.org Tue Aug 12 00:03:28 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 06:03:28 +0200 Subject: [IPython-dev] Test failures In-Reply-To: <20080812030317.GA6567@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> Message-ID: <20080812040328.GB6567@phare.normalesup.org> On Tue, Aug 12, 2008 at 05:03:17AM +0200, Gael Varoquaux wrote: > On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote: > > Do you actually need to use make_ipython? Would it work for you > > instead to get the ipython isntance via ipapi.get()? > Well, I need a ipython instance, and I need to create it, so I do believe > I need to call make_ipython. I pin-pointed the problem quite clearly. Add the following test somewhere in your test-suite: def test_stupid(): from IPython.ipmaker import make_IPython i = make_IPython() del i ... and the test we are talking about will fail. This could be a bad interaction between nose, which does some IO magic, and IPython. If anybody feels like helping me on that, please do: I am loosing my evening on it. Cheers, Ga?l From fperez.net at gmail.com Tue Aug 12 00:14:30 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 21:14:30 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812030317.GA6567@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 8:03 PM, Gael Varoquaux wrote: > On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote: >> Do you actually need to use make_ipython? Would it work for you >> instead to get the ipython isntance via ipapi.get()? > > Well, I need a ipython instance, and I need to create it, so I do believe > I need to call make_ipython. Again, why not use ipapi.get()? That object has the public API, and if you need for now to hook deeper, it keeps the actual ipython instance inside as .IP. This is a much better solution than using a call that's dangerous, deprecated and 'private' (meaning, it's not in ipapi, which we intend to expose the visible face of the ipython instance). Please let me know why that solution wouldn't work for you so we can help you get the right thing working, because the make_IPython call is very likely to *never* work (there's simpyl way too many global side effects floating around). Cheers, f From gael.varoquaux at normalesup.org Tue Aug 12 00:24:14 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 06:24:14 +0200 Subject: [IPython-dev] Test failures In-Reply-To: References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> Message-ID: <20080812042414.GC6567@phare.normalesup.org> On Mon, Aug 11, 2008 at 09:14:30PM -0700, Fernando Perez wrote: > On Mon, Aug 11, 2008 at 8:03 PM, Gael Varoquaux > wrote: > > On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote: > >> Do you actually need to use make_ipython? Would it work for you > >> instead to get the ipython isntance via ipapi.get()? > > Well, I need a ipython instance, and I need to create it, so I do believe > > I need to call make_ipython. > Again, why not use ipapi.get()? That object has the public API, and > if you need for now to hook deeper, it keeps the actual ipython > instance inside as .IP. This is a much better solution than using a > call that's dangerous, deprecated and 'private' (meaning, it's not > in ipapi, which we intend to expose the visible face of the ipython > instance). But, I don't get it. I need to create an ipython0 instance, not to retrieve an existing one. This is pretty-much the entry point of my frontend: to create an ipython0 instance. I don't see how ipapi.get can help me on that. I actually don't see how I can do it without make_IPython. If you have something better to suggest, I am happy to use it. Cheers, Ga?l From fperez.net at gmail.com Tue Aug 12 00:37:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 21:37:36 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812042414.GC6567@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 9:24 PM, Gael Varoquaux wrote: > But, I don't get it. I need to create an ipython0 instance, not to > retrieve an existing one. This is pretty-much the entry point of my > frontend: to create an ipython0 instance. I don't see how ipapi.get can > help me on that. I actually don't see how I can do it without > make_IPython. If you have something better to suggest, I am happy to use > it. But this is during the test suite, right? In that case, it's going to be a little tricky, I suspect, because the testing plugin already has to make an ip0 instance so magics and other similar beasts run. Could you make your class take optionally the ip0 instance as a parameter at construction time? This isn't very elegant, but it may do for now so you can run in the testing environment until we can fix it to decouple all the global effects. In that case, you'd run your constructor passing it the ip0 instance retrieved from ipapi.get(), and work with that. Note that with all the i/o capturing that doctest/nose do, this could get ugly in a hurry, if you're also trying to do your own i/o trapping. So no guarantees that this will actually work. Cheers, f From gael.varoquaux at normalesup.org Tue Aug 12 01:06:20 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 07:06:20 +0200 Subject: [IPython-dev] Test failures In-Reply-To: References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> Message-ID: <20080812050620.GD6567@phare.normalesup.org> On Mon, Aug 11, 2008 at 09:37:36PM -0700, Fernando Perez wrote: > > But, I don't get it. I need to create an ipython0 instance, not to > > retrieve an existing one. This is pretty-much the entry point of my > > frontend: to create an ipython0 instance. I don't see how ipapi.get can > > help me on that. I actually don't see how I can do it without > > make_IPython. If you have something better to suggest, I am happy to use > > it. > But this is during the test suite, right? In that case, it's going to > be a little tricky, I suspect, because the testing plugin already has > to make an ip0 instance so magics and other similar beasts run. > Could you make your class take optionally the ip0 instance as a > parameter at construction time? This isn't very elegant, but it may > do for now so you can run in the testing environment until we can fix > it to decouple all the global effects. > In that case, you'd run your constructor passing it the ip0 instance > retrieved from ipapi.get(), and work with that. I tried, but ipapi.get() returns None. > Note that with all the i/o capturing that doctest/nose do, this could > get ugly in a hurry, if you're also trying to do your own i/o > trapping. So no guarantees that this will actually work. Indeed, and I am trying to test this. But this part works. What doesn't work is that when and ipython0 instance is instanciated, the output trapping that you are doing in the ipython1 interpreter is broken. And I happen to need an ipython0 instance to run the frontend I am trying to test. This is a bit frustrating. I have a set of tests for this frontend, but I can't run them through nose, because they cause side effects and have another test to fail. The side-effect is quite clearly in something called by make_IPython, but I am having a hard time figuring out where. Ga?l From fperez.net at gmail.com Tue Aug 12 01:11:54 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 22:11:54 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812050620.GD6567@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> <20080812050620.GD6567@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 10:06 PM, Gael Varoquaux wrote: > I tried, but ipapi.get() returns None. Ah, I thought you were already running with the ipdoctest plugin installed/enabled, and not with just plain nose. That plugin starts up the ipython testing machinery, and it's the only way to actually run the existing docstrings as tests. I haven't advertised much how to use it yet because it's pretty raw, but since you're fighting in the frontlines, might as well give you a gun :) For now, you can use the makefile. Go to the testing/plugin directory, edit the PREFIX at the top to whatever you like on your box, and run make all That should run the test suite for you after installing the plugin. Once that's working, you can use the plugin to run your tests as well with the command line as defined in the $(NOSE) variable atop the makefile. The plugin makes an ipython instance for all tests, so once it's up and running (which you get by simply saying --with-ipdoctest at your nose command line), ipapi.get() in *your* code should then always return an actual ip instance instead of None. >> Note that with all the i/o capturing that doctest/nose do, this could >> get ugly in a hurry, if you're also trying to do your own i/o >> trapping. So no guarantees that this will actually work. > > Indeed, and I am trying to test this. But this part works. What doesn't > work is that when and ipython0 instance is instanciated, the output > trapping that you are doing in the ipython1 interpreter is broken. And I > happen to need an ipython0 instance to run the frontend I am trying to > test. > > This is a bit frustrating. I have a set of tests for this frontend, but I > can't run them through nose, because they cause side effects and have > another test to fail. The side-effect is quite clearly in something > called by make_IPython, but I am having a hard time figuring out where. Yes, I'm sorry you're seeing this. This particular battle isn't going to be fun, and we're paying the price of neglecting testing for such a long time. But we all know it's the right thing to do, and I really appreciate your commitment despite how unpleasant it is. Cheers, f From gael.varoquaux at normalesup.org Tue Aug 12 01:18:11 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 07:18:11 +0200 Subject: [IPython-dev] Test failures In-Reply-To: References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> <20080812050620.GD6567@phare.normalesup.org> Message-ID: <20080812051811.GE6567@phare.normalesup.org> On Mon, Aug 11, 2008 at 10:11:54PM -0700, Fernando Perez wrote: > > This is a bit frustrating. I have a set of tests for this frontend, but I > > can't run them through nose, because they cause side effects and have > > another test to fail. The side-effect is quite clearly in something > > called by make_IPython, but I am having a hard time figuring out where. > Yes, I'm sorry you're seeing this. This particular battle isn't going > to be fun, and we're paying the price of neglecting testing for such a > long time. But we all know it's the right thing to do, and I really > appreciate your commitment despite how unpleasant it is. I apologise for getting a bit frustated. We all know that ipython0 is old and curfty code, but I am sooooo happy to use it on a day to day basis, so really cannot blame anybody for having taken the short way to get there. Besides, it is not that unpleasant, just frustating. I'll buy you a beer for being an unpleasant Frenchmen :) Ga?l From fperez.net at gmail.com Tue Aug 12 01:23:07 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 22:23:07 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812051811.GE6567@phare.normalesup.org> References: <20080811230035.GC30181@phare.normalesup.org> <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> <20080812050620.GD6567@phare.normalesup.org> <20080812051811.GE6567@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 10:18 PM, Gael Varoquaux wrote: > On Mon, Aug 11, 2008 at 10:11:54PM -0700, Fernando Perez wrote: >> > This is a bit frustrating. I have a set of tests for this frontend, but I >> > can't run them through nose, because they cause side effects and have >> > another test to fail. The side-effect is quite clearly in something >> > called by make_IPython, but I am having a hard time figuring out where. > >> Yes, I'm sorry you're seeing this. This particular battle isn't going >> to be fun, and we're paying the price of neglecting testing for such a >> long time. But we all know it's the right thing to do, and I really >> appreciate your commitment despite how unpleasant it is. > > I apologise for getting a bit frustated. We all know that ipython0 is old > and curfty code, but I am sooooo happy to use it on a day to day basis, > so really cannot blame anybody for having taken the short way to get > there. > > Besides, it is not that unpleasant, just frustating. No worries. I'm going to be working for a bit longer, so let me know if you need anything. And please keep merging with trunk and pushing, so I can perhaps tomorrow merge your branch. If you do all the merges with trunk back in your branch and you push it, I can then do a pull and your local commits get registered as such (see the last changes to trunk showing Robet's individual changesets, which I merged today). In fact, I've been mulling today, after all the merge work, a slight reorganization of how we manage branches to simplify review and history handling. But I'll send that in a separate message in a few days, after we finish the current burning issues. > > I'll buy you a beer for being an unpleasant Frenchmen :) Gladly accepted! (the beer, not that you're unpleasang :) Cheers, f From gael.varoquaux at normalesup.org Tue Aug 12 01:24:40 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 12 Aug 2008 07:24:40 +0200 Subject: [IPython-dev] Test failures In-Reply-To: <20080812051811.GE6567@phare.normalesup.org> References: <20080812022320.GA27447@phare.normalesup.org> <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> <20080812050620.GD6567@phare.normalesup.org> <20080812051811.GE6567@phare.normalesup.org> Message-ID: <20080812052440.GF6567@phare.normalesup.org> On Tue, Aug 12, 2008 at 07:18:11AM +0200, Gael Varoquaux wrote: > Besides, it is not that unpleasant, just frustating. And, in addition, I have solved my problem. It was a sys.displayhook problem, not an IO problem. I am happy :). Ga?l From fperez.net at gmail.com Tue Aug 12 01:30:44 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 11 Aug 2008 22:30:44 -0700 Subject: [IPython-dev] Test failures In-Reply-To: <20080812052440.GF6567@phare.normalesup.org> References: <20080812030317.GA6567@phare.normalesup.org> <20080812042414.GC6567@phare.normalesup.org> <20080812050620.GD6567@phare.normalesup.org> <20080812051811.GE6567@phare.normalesup.org> <20080812052440.GF6567@phare.normalesup.org> Message-ID: On Mon, Aug 11, 2008 at 10:24 PM, Gael Varoquaux wrote: > On Tue, Aug 12, 2008 at 07:18:11AM +0200, Gael Varoquaux wrote: >> Besides, it is not that unpleasant, just frustating. > > And, in addition, I have solved my problem. It was a sys.displayhook > problem, not an IO problem. OK, great. Cheers, f From fperez.net at gmail.com Tue Aug 12 03:30:37 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 12 Aug 2008 00:30:37 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: <48A13A57.5090108@vdesmedt.com> References: <489CA6B9.5060006@vdesmedt.com> <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com> <48A13A57.5090108@vdesmedt.com> Message-ID: On Tue, Aug 12, 2008 at 12:23 AM, Vivian De Smedt wrote: > No problem I will adapt the code of the synchronize-editor branch as soon as > possible. > I'll be glad if you could send me the bzr command I should use to merge the > trunk cod in the synchronize-editor branch. Basically the easiest workflow is to have the following: bzr-directory/ ipython/ -> trunk, you get this with 'bzr branch lp:ipython' your_branch/ -> where you're working then in the checkout of trunk, you periodically do bzr pull to pull updates that others have pushed to the trunk. When new updates are in, you can propagate them to your working branch via: cd your_branch bzr pull ../ipython/ if the above fails because a merge is required, you do instead bzr commit -m"Checkpointing local changes before merge" bzr merge ../ipython bzr commit -m"Merge with upstream" This keeps your changes in sync with the upstream development on trunk, which is important to ensure that nothing breaks in your development. You can then periodically do: bzr push This sends your changes to launchpad, so that I and others can get them for review, merging, sharing, etc. I hope this is clear enough, let us know if you have any other questions. Regards, f From vivian at vdesmedt.com Tue Aug 12 03:23:03 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue, 12 Aug 2008 09:23:03 +0200 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <489CA6B9.5060006@vdesmedt.com> <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com> Message-ID: <48A13A57.5090108@vdesmedt.com> Fernando, > Mmh, I was getting ready to merge and push, but then I went and looked > at the code, and I see the whole thing is written in camelCase(): > > http://bazaar.launchpad.net/%7Evivian-vdesmedt/ipython/synchronize-editor/annotate/1007?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1 > > Why is that the case? For all new code, we are really trying to stick > to proper PEP-8 within reason, and I don't want to violate that unless > there's a good motive for it. > > I also don't see any docstrings in any of the functions at all. > > Vivian, I realize that this may be a bit painful, but as you can see, > we're now making an honest effort at building a much higher quality > codebase for IPython, so that all code that goes in is reviewed, > documented and tested. And we are all living by the same rules (see > recent reviews on other branches, and all the work that has gone into > having testing machinery for ipython itself). > > With bzr and launchpad, it's relatively easy for you to track the > trunk (simply keep merging from trunk into your working branch and > pushing back upstream frequently), so that your branch stays up to > date, as you improve it. But I really think that we can't merge this > code in until it's properly documented and it matches the naming > conventions of the rest of the project. > > I realize it's a bit frustrating at this point, but hopefully it's > clear to you that these rules are there to ensure that as the whole > project grows in a very healthy fashion. We're getting more new code > coming in than any one of us can handle individually, and the only way > we won't crumble under the weight is to enforce that all this new code > is compliant with the rest of the project, documented and > automatically tested. > > Regards, > > f > > ps - I've added the above as a branch review comment on launchpad as well. > > No problem I will adapt the code of the synchronize-editor branch as soon as possible. I'll be glad if you could send me the bzr command I should use to merge the trunk cod in the synchronize-editor branch. Vivian. From vivian at vdesmedt.com Tue Aug 12 04:15:15 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue, 12 Aug 2008 10:15:15 +0200 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <489CA6B9.5060006@vdesmedt.com> <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com> <48A13A57.5090108@vdesmedt.com> Message-ID: <48A14693.8020704@vdesmedt.com> Fernando, Thanks for your explanations. I have no access to launchpad right now but I'll test your work flow as soon as possible. Vivian. From robert.kern at gmail.com Tue Aug 12 13:14:03 2008 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 12 Aug 2008 12:14:03 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: Fernando Perez wrote: > On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern wrote: >> Fernando Perez wrote: >>> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern wrote: >>> >>>> The iplib one was already gone. The Shell one will be gone as soon as I remember >>>> how to push to launchpad again. >>> Care to push? I'm merging... >> Pushed sans docstrings. Still >> on vacation. Tired from flight. >> Sleepytime for me. > > OK, I just merged and pushed to trunk your changes. Let me know as > you update the branch and I can merge the rest and push it into trunk. There was a syntax error that I fixed. -- 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 Tue Aug 12 16:29:43 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 12 Aug 2008 13:29:43 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: On Tue, Aug 12, 2008 at 10:14 AM, Robert Kern wrote: >> OK, I just merged and pushed to trunk your changes. Let me know as >> you update the branch and I can merge the rest and push it into trunk. > > There was a syntax error that I fixed. Got it, pushed. Thanks. If you push docstring updates, let me know. Cheers, f From dsdale24 at gmail.com Wed Aug 13 09:14:47 2008 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 13 Aug 2008 09:14:47 -0400 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: Message-ID: <200808130914.47689.dsdale24@gmail.com> I guess the trunk is in a state of flux at the moment, but I wanted to point out before 0.9 is released that -pylab appears to be broken in bzr 1016: $ ipython -pylab Traceback (most recent call last): File "/usr/bin/ipython", line 28, in IPython.Shell.start().mainloop() File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1231, in start return shell(user_ns = user_ns) File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1136, in __init__ shell_class=MatplotlibMTShell) File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1035, in __init__ on_kill=[QtGui.qApp.exit]) File "/usr/lib64/python2.5/site-packages/IPython/ipmaker.py", line 103, in make_IPython embedded=embedded,**kw) File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 637, in __init__ user_ns,b2 = self._matplotlib_config(name,user_ns) ValueError: too many values to unpack Darren On Tuesday 12 August 2008 04:29:43 pm Fernando Perez wrote: > On Tue, Aug 12, 2008 at 10:14 AM, Robert Kern wrote: > >> OK, I just merged and pushed to trunk your changes. Let me know as > >> you update the branch and I can merge the rest and push it into trunk. > > > > There was a syntax error that I fixed. > > Got it, pushed. Thanks. If you push docstring updates, let me know. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev From gael.varoquaux at normalesup.org Wed Aug 13 11:44:09 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 13 Aug 2008 17:44:09 +0200 Subject: [IPython-dev] Evaluation bug in Interpreter? Message-ID: <20080813154409.GA12897@phare.normalesup.org> I hit this behavior, with the ipython1 interpreter: =============================================================================== In [6]: from IPython.kernel.core.interpreter import Interpreter In [7]: i = Interpreter() In [8]: i.execute(u'dedent(""" a\n b\n c""")\n\n') --------------------------------------------------------------------------- IndentationError Traceback (most recent call last) /home/gvaroquaux/dev/ipython/ipython-frontend/scripts/ in () /home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/interpreter.pyc in execute_python(self, python) 352 for cmd in commands: 353 try: --> 354 code = self.command_compiler(cmd, self.filename, 'single') 355 except (SyntaxError, OverflowError, ValueError), e: 356 self.traceback_trap.args = sys.exc_info() /usr/lib/python2.5/codeop.pyc in __call__(self, source, filename, symbol) 164 - Raise SyntaxError, ValueError or OverflowError if the command is a 165 syntax error (OverflowError and ValueError can be produced by 166 malformed literals). 167 """ --> 168 return _maybe_compile(self.compiler, source, filename, symbol) /usr/lib/python2.5/codeop.pyc in _maybe_compile(compiler, source, filename, symbol) 97 return code 98 if not code1 and repr(err1) == repr(err2): ---> 99 raise SyntaxError, err1 100 101 def _compile(source, filename, symbol): IndentationError: unexpected indent (, line 1) =============================================================================== It seems to me that the input is valid Python. Cheers, Ga?l From fperez.net at gmail.com Wed Aug 13 12:50:30 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 13 Aug 2008 09:50:30 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: <200808130914.47689.dsdale24@gmail.com> References: <200808130914.47689.dsdale24@gmail.com> Message-ID: On Wed, Aug 13, 2008 at 6:14 AM, Darren Dale wrote: > I guess the trunk is in a state of flux at the moment, but I wanted to point > out before 0.9 is released that -pylab appears to be broken in bzr 1016: Thanks for reporting it. I'm in a meeting for several hours, but if someone can beat me to the fix it would be great. This has to do with Robert Kern's recent namespace construction API changes, I guess we missed a few spots... Cheers, f From robert.kern at gmail.com Wed Aug 13 16:00:38 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 13 Aug 2008 15:00:38 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <200808130914.47689.dsdale24@gmail.com> Message-ID: Fernando Perez wrote: > On Wed, Aug 13, 2008 at 6:14 AM, Darren Dale wrote: >> I guess the trunk is in a state of flux at the moment, but I wanted to point >> out before 0.9 is released that -pylab appears to be broken in bzr 1016: > > Thanks for reporting it. I'm in a meeting for several hours, but if > someone can beat me to the fix it would be great. This has to do with > Robert Kern's recent namespace construction API changes, I guess we > missed a few spots... Please pardon my sloppiness. Fixed pushed to lp:~robert-kern/ipython/contexts -- 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 Aug 13 16:30:04 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 13 Aug 2008 13:30:04 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <200808130914.47689.dsdale24@gmail.com> Message-ID: On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern wrote: > Please pardon my sloppiness. You are forgiven. We need more tests, more tests, more tests... :) > Fixed pushed to lp:~robert-kern/ipython/contexts Thanks, pushed upstream. Please double-check (I'm having a build problem with numpy right now on this box that I don't want to report yet because it may be my fault, so I can't fully test this myself). Cheers, f From robert.kern at gmail.com Wed Aug 13 19:01:34 2008 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 13 Aug 2008 18:01:34 -0500 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <200808130914.47689.dsdale24@gmail.com> Message-ID: Fernando Perez wrote: > On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern wrote: >> Fixed pushed to lp:~robert-kern/ipython/contexts > > Thanks, pushed upstream. Please double-check (I'm having a build > problem with numpy right now on this box that I don't want to report > yet because it may be my fault, so I can't fully test this myself). ipython -pylab works for me. -- 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 Aug 13 19:15:19 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 13 Aug 2008 16:15:19 -0700 Subject: [IPython-dev] Release plan for 0.9 In-Reply-To: References: <200808130914.47689.dsdale24@gmail.com> Message-ID: On Wed, Aug 13, 2008 at 4:01 PM, Robert Kern wrote: > Fernando Perez wrote: >> On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern wrote: >>> Fixed pushed to lp:~robert-kern/ipython/contexts >> >> Thanks, pushed upstream. Please double-check (I'm having a build >> problem with numpy right now on this box that I don't want to report >> yet because it may be my fault, so I can't fully test this myself). > > ipython -pylab works for me. Thanks, I just sorted out my build problem (it was indeed on my end) and could test things. Everything looks OK (I also tested the -Xthread and embedding call modes). Cheers, f From fperez.net at gmail.com Thu Aug 14 08:55:54 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 05:55:54 -0700 Subject: [IPython-dev] Evaluation bug in Interpreter? In-Reply-To: <20080813154409.GA12897@phare.normalesup.org> References: <20080813154409.GA12897@phare.normalesup.org> Message-ID: On Wed, Aug 13, 2008 at 8:44 AM, Gael Varoquaux wrote: > I hit this behavior, with the ipython1 interpreter: > > =============================================================================== > In [6]: from IPython.kernel.core.interpreter import Interpreter > > In [7]: i = Interpreter() > > In [8]: i.execute(u'dedent(""" a\n b\n c""")\n\n') Bug. It's splitting the lines wrong: ipdb> print cmd c""") File it on lp so we don't lose track... Cheers, f From fperez.net at gmail.com Thu Aug 14 09:04:55 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 06:04:55 -0700 Subject: [IPython-dev] 0.9 beta, anything left? Message-ID: Howdy, I wanted to make the 0.9 beta tonight (well, last night...) but I've just burned several hours trying to track an intermittent failure in a Twisted-using test that I can't seem to pin down. Since the problem is only on a single test, I'm giving up for now. But I just committed the last critical piece of testing machinery that gave me a hard time: the ability to correctly execute in docstrings tests that probe ipython-specific features, like complete(x) where x is in the namespace. This requires a delicate dance with nose and doctest, but I think I finally got a solid solution. The sugar is still missing, so for now the test suite will be really only for developers, but hopefully next week I can add a user-visible layer that makes it easy for users to run and that handles gracefully missing components (like twisted, guis, objc, etc). For now I need to get some sleep, and I'm running very badly behind on things for scipy. So if anyone has anything pending please respond to this email and I'll deal with it when I get up. Otherwise I'll cut an 0.9 beta and shift gears immediately to the scipy tutorial material for a few days. Cheers, f From fperez.net at gmail.com Thu Aug 14 09:18:35 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 06:18:35 -0700 Subject: [IPython-dev] Comments about IPython.frontend, getting ready for merge of ipython-sync-frontend In-Reply-To: <20080814131035.GB22202@phare.normalesup.org> References: <20080813000612.GD631@phare.normalesup.org> <20080813205043.GC21473@phare.normalesup.org> <20080814065502.GF24893@phare.normalesup.org> <20080814130728.GA22202@phare.normalesup.org> <20080814131035.GB22202@phare.normalesup.org> Message-ID: On Thu, Aug 14, 2008 at 6:10 AM, Gael Varoquaux wrote: > On Thu, Aug 14, 2008 at 06:09:21AM -0700, Fernando Perez wrote: >> OK, we'll look at this next week. The code I just wrote does some >> things that may actually fix the problem altogether, or offer a >> cleaner solution. But I'm not sure and I'm too tired to check now. > >> To bed.. > > Wow, that's late. Can I help with something? Very, very late... Yes, if you can do some testing of the installation, it would be great. The setup.py we have now has been massively changed from the old one, merging in the ip1 stuff, but there's a very good chance it may have holes. So testing that the various targets build (sdist, egg, wininst), that the windows installer works (I can't test windows at all, my vmware image is borked), that the docs get put in the right place, etc, would be great. I don't intend to add any more code unless someone jumps at the last minute with something simple, so now it should be just testing that all the ip0/1 merge didn't hose the build/install machinery. Since I always run from my dev directories I haven't tested that part yet, and now I really need to crash. Any help would be very, very much appreciated. Cheers, f From vivainio at gmail.com Thu Aug 14 16:47:28 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 14 Aug 2008 23:47:28 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: Message-ID: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> On Thu, Aug 14, 2008 at 4:04 PM, Fernando Perez wrote: > For now I need to get some sleep, and I'm running very badly behind on > things for scipy. So if anyone has anything pending please respond to > this email and I'll deal with it when I get up. Otherwise I'll cut an > 0.9 beta and shift gears immediately to the scipy tutorial material > for a few days. I just implemented cd -foo. I'll make another post about it, and add it to changes.txt. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Thu Aug 14 17:01:09 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 00:01:09 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> Message-ID: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> On Thu, Aug 14, 2008 at 11:47 PM, Ville M. Vainio wrote: > I just implemented cd -foo. I'll make another post about it, and add > it to changes.txt. Well, of course I need to change it to cd --foo due to option parsing. Stay tuned. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Thu Aug 14 17:31:19 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 14:31:19 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> Message-ID: On Thu, Aug 14, 2008 at 2:01 PM, Ville M. Vainio wrote: > On Thu, Aug 14, 2008 at 11:47 PM, Ville M. Vainio wrote: > >> I just implemented cd -foo. I'll make another post about it, and add >> it to changes.txt. > > Well, of course I need to change it to cd --foo due to option parsing. > Stay tuned. This is a very handy feature, but I wish you'd brought it up for at least cursory discussion first, because there's one point I worry about: you are overloading the '--foo' syntax to have another secondary meaning, on top of its original 'long options' one. This means special-casing code. In the new architecture, the magics will be separate objects with a common options parsing machinery that should be uniform, so there's a good chance we'll have to change a bit exactly how this works in the near future. In any case, it's too late right now, I'm working on scipy stuff and will cut the beta later, so let's leave it in. But let's try to all heed to the discussion/review swing that Barry and Gael got us so well into for all the recent code. It will help us all build something that is well integrated and robust for the long haul. Cheers, f From vivainio at gmail.com Thu Aug 14 20:37:55 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 03:37:55 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> Message-ID: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> On Fri, Aug 15, 2008 at 12:31 AM, Fernando Perez wrote: > means special-casing code. In the new architecture, the magics will > be separate objects with a common options parsing machinery that > should be uniform, so there's a good chance we'll have to change a bit > exactly how this works in the near future. I don't mind if the behaviour changes, as long as it's as convenient (to type) as using --. However, I don't think forcing the magics to go through a common parsing machinery is the optimal way to go; we should retain the possibility for the current behaviour that allows free form data to be passed to magics. We could also change the character before the release, if the dual meaning with long options is a problem. - is something you can type without pressing shift on most keyboard layout, so I'd rather leave it as it is now. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Thu Aug 14 20:44:47 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 17:44:47 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> Message-ID: On Thu, Aug 14, 2008 at 5:37 PM, Ville M. Vainio wrote: > On Fri, Aug 15, 2008 at 12:31 AM, Fernando Perez wrote: > >> means special-casing code. In the new architecture, the magics will >> be separate objects with a common options parsing machinery that >> should be uniform, so there's a good chance we'll have to change a bit >> exactly how this works in the near future. > > I don't mind if the behaviour changes, as long as it's as convenient > (to type) as using --. However, I don't think forcing the magics to go > through a common parsing machinery is the optimal way to go; we should > retain the possibility for the current behaviour that allows free form > data to be passed to magics. > > We could also change the character before the release, if the dual > meaning with long options is a problem. - is something you can type > without pressing shift on most keyboard layout, so I'd rather leave it > as it is now. The issue is one of avoiding special casing. Magics will certainly always be able to be given free-form input, but *if* they take options, then options should be handled as such via optparse or similar. Magics behave at the ipython command line much like system commands, and using -- for both options and arguments would break option parsing altogether. I've never seen a single system command that accepts foo --option1 --option2 --freeformarguments because the option parsing machineries (getopt, optparse, whatever) as far as I know them, always expect to know the list of valid options in advance. This is why I don't want this hybrid mode, 'cd is special' case where -- means two different things. Any suggestions for alternatives? Cheers, f From ellisonbg.net at gmail.com Thu Aug 14 20:50:06 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 14 Aug 2008 17:50:06 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> Message-ID: <6ce0ac130808141750x6796436ema26b14c5cc23b7c7@mail.gmail.com> >> means special-casing code. In the new architecture, the magics will >> be separate objects with a common options parsing machinery that >> should be uniform, so there's a good chance we'll have to change a bit >> exactly how this works in the near future. > > I don't mind if the behaviour changes, as long as it's as convenient > (to type) as using --. However, I don't think forcing the magics to go > through a common parsing machinery is the optimal way to go; we should > retain the possibility for the current behaviour that allows free form > data to be passed to magics. I agree that magics in general should allow free form syntax. But I do feel that if a magic wants to the usual command line style options, that we should keep to a standard syntax. > We could also change the character before the release, if the dual > meaning with long options is a problem. - is something you can type > without pressing shift on most keyboard layout, so I'd rather leave it > as it is now. > > -- > Ville M. Vainio - vivainio.googlepages.com > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Thu Aug 14 20:53:56 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 14 Aug 2008 17:53:56 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> Message-ID: <6ce0ac130808141753k3877a965ref8f7db0d3dd0faf@mail.gmail.com> > foo --option1 --option2 --freeformarguments > > because the option parsing machineries (getopt, optparse, whatever) as > far as I know them, always expect to know the list of valid options in > advance. This is why I don't want this hybrid mode, 'cd is special' > case where -- means two different things. Ahh, yes, this does introduce a sort of messyness in the double interpretation of "--". Also, now that I think about it, "cd --foo" would usually have the interpretation "cd to my home dir and do it in the foo'y way" That is, "--" options are typically optional modifiers, drawn from a pre-specified list of options. The usage "cd --foo" is pretty odd in this light. Brian > Any suggestions for alternatives? > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From vivainio at gmail.com Thu Aug 14 21:34:39 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 04:34:39 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> Message-ID: <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> On Fri, Aug 15, 2008 at 3:44 AM, Fernando Perez wrote: > Any suggestions for alternatives? This would work for me, keyboardwise: cd =foo It seems kinda confusing unless you are writing it yourself, though (looks like assignment), and it doesn't come as naturally as -- (logical followup of -. I still prefer "--", cd can be special that way. People don't think of it as "unix command" and its usage becomes a second reflex. cd is not a command that needs to follow the logic of more rarely used commands. We should really consider end-user typing performance with the cost of slight inconsistency (which magics can have). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Thu Aug 14 21:43:24 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 18:43:24 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> Message-ID: On Thu, Aug 14, 2008 at 6:34 PM, Ville M. Vainio wrote: > On Fri, Aug 15, 2008 at 3:44 AM, Fernando Perez wrote: > >> Any suggestions for alternatives? > > This would work for me, keyboardwise: > > cd =foo > > It seems kinda confusing unless you are writing it yourself, though > (looks like assignment), and it doesn't come as naturally as -- > (logical followup of -. > > I still prefer "--", cd can be special that way. People don't think of > it as "unix command" and its usage becomes a second reflex. cd is not > a command that needs to follow the logic of more rarely used commands. > We should really consider end-user typing performance with the cost of > slight inconsistency (which magics can have). Let's go with the '=' option, then. cd can be special that way :) Otherwise for cd we'd have to implement special parsing logic, since normal options handling would break given arbitrary --foo input. As 'import this' says, Special cases aren't special enough to break the rules. and this is a case where I agree with it, here the benefit of a special case does not in any way outweigh the cost of breaking a pattern. We're aiming for much more consistency in the code going forward, so we should raise the bar pretty high for special cases that break the rules. Cheers, f From vivainio at gmail.com Thu Aug 14 22:57:15 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 05:57:15 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> Message-ID: <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> On Fri, Aug 15, 2008 at 4:43 AM, Fernando Perez wrote: > Let's go with the '=' option, then. cd can be special that way :) = won't work, it raises NameError and never gets to %cd (it looks like python assignment to ipython as well) ;-) > Otherwise for cd we'd have to implement special parsing logic, since > normal options handling would break given arbitrary --foo input. As > 'import this' says, > > Special cases aren't special enough to break the rules. > and this is a case where I agree with it, here the benefit of a > special case does not in any way outweigh the cost of breaking a > pattern. The "parsing" logic we already have in %cd is quite trivial, so we don't really have to shoehorn %cd to the option parsing formula, esp. since cd will never have arguments in the long format. I'd be inclined to say that we should leave it as --, and change it if it proves problematic at some point. We could change it to ---, but that gets kind of heavy, and other characters have special meanings (to python or readline as we currently use it). And since "cd -" is already a special case, the cd magic can be considered terminally broken from the strict option handling point of view... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Thu Aug 14 23:06:38 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 20:06:38 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> Message-ID: On Thu, Aug 14, 2008 at 7:57 PM, Ville M. Vainio wrote: > I'd be inclined to say that we should leave it as --, and change it if > it proves problematic at some point. We could change it to ---, but > that gets kind of heavy, and other characters have special meanings > (to python or readline as we currently use it). I'm deep fighting with the setup.py which is pretty seriously broken, so I can't deal with this. I'm ok leaving it as is, since the code is written, but no promises: when we restructure magics, I reserve the right to change this if needed. If it can be kept without hassles, I won't change it gratuitously; but my tolerance for special-casing stuff is dropping dramatically, so this one could go in the future (into cd -p foo or similar). Cheers, f From fperez.net at gmail.com Thu Aug 14 23:23:47 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 20:23:47 -0700 Subject: [IPython-dev] Docs - authorship? Message-ID: Howdy, I'd like to actually list who's written the documentation/manuals explicitly, since that is a more book-like type of document (see the mpl docs for example at http://matplotlib.sourceforge.net/doc/html/index.html, click on the PDF link). I wrote over 90 pages of documentation originally for that, and Brian has also written a ton of rst docs. But because I haven't kept track of the doc details since the latest reorganization, I'd like to know who else I should list. Please consider that I'm happy to follow purely an honor system here: if you feel your contributions to that document (the PDF clocks in at 128 pages right now) make you a co-author, simply tell me and I'll add your name to the list. I will list 'authors: foo, bar, ...; with contributions from: a,b,c,...' to credit both people who wrote major portions and those who have contributed smaller but valuable parts. Please just tell me and I'll be happy to add your names, listed alphabetically by last name. I think currently I have: - authors: Brian and me. - contributors: Ville (docstrings, wiki pages I imagine will be soon ported since the problem used to be that we had lyx sources). Don't know: Min, Stefan, Gael, Barry, etc. Have you guys written parts of the manual? Does this sound OK to all? Cheers, f From fperez.net at gmail.com Fri Aug 15 00:51:43 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 21:51:43 -0700 Subject: [IPython-dev] Branches merged... Message-ID: Howdy, I've marked as merged Gael's sync frontend branch and Robert's context one. I imagine they can be reopened for new work as needed, this was just for bookeeping purposes. We need to do a bit of branch house cleaning on lp, but not now. On to the beta... f From gael.varoquaux at normalesup.org Fri Aug 15 01:40:22 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 15 Aug 2008 07:40:22 +0200 Subject: [IPython-dev] Docs - authorship? In-Reply-To: References: Message-ID: <20080815054022.GA23607@phare.normalesup.org> On Thu, Aug 14, 2008 at 08:23:47PM -0700, Fernando Perez wrote: > Don't know: Min, Stefan, Gael, Barry, etc. Have you guys written > parts of the manual? Not me. Ga?l From ellisonbg.net at gmail.com Fri Aug 15 02:07:32 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 14 Aug 2008 23:07:32 -0700 Subject: [IPython-dev] Docs - authorship? In-Reply-To: References: Message-ID: <6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com> Min should be listed as a contributor as he wrote some of the parallel computing docs. Brian On Thu, Aug 14, 2008 at 8:23 PM, Fernando Perez wrote: > Howdy, > > I'd like to actually list who's written the documentation/manuals > explicitly, since that is a more book-like type of document (see the > mpl docs for example at > http://matplotlib.sourceforge.net/doc/html/index.html, click on the > PDF link). I wrote over 90 pages of documentation originally for > that, and Brian has also written a ton of rst docs. But because I > haven't kept track of the doc details since the latest reorganization, > I'd like to know who else I should list. > > Please consider that I'm happy to follow purely an honor system here: > if you feel your contributions to that document (the PDF clocks in at > 128 pages right now) make you a co-author, simply tell me and I'll add > your name to the list. I will list 'authors: foo, bar, ...; with > contributions from: a,b,c,...' to credit both people who wrote major > portions and those who have contributed smaller but valuable parts. > > Please just tell me and I'll be happy to add your names, listed > alphabetically by last name. I think currently I have: > > - authors: Brian and me. > - contributors: Ville (docstrings, wiki pages I imagine will be soon > ported since the problem used to be that we had lyx sources). > > Don't know: Min, Stefan, Gael, Barry, etc. Have you guys written > parts of the manual? > > Does this sound OK to all? > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Fri Aug 15 02:13:42 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Aug 2008 23:13:42 -0700 Subject: [IPython-dev] Docs - authorship? In-Reply-To: <6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com> References: <6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com> Message-ID: On Thu, Aug 14, 2008 at 11:07 PM, Brian Granger wrote: > Min should be listed as a contributor as he wrote some of the parallel > computing docs. Got it, thanks. I already got some replies off-list too. Anyone else I'm missing? Cheers, f From fperez.net at gmail.com Fri Aug 15 06:42:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Aug 2008 03:42:36 -0700 Subject: [IPython-dev] 0.9 beta ready for a look... Message-ID: Hi all, http://ipython.scipy.org/dist/testing/ Please have a go at this. I think I'll be very non-responsive for a few days, unfortunately (scipy is looming large). Hopefully the rest of the gang can pitch in a bit. But a pounding on everything would be welcome, in particular anyone who can see if that windows installer does anything remotely sensible would be great. I have no vmware right now, and it may well be putting the docs in the wrong place (or not at all), or worse. And I'm too fried to fix any more code right now. I hate distutils, with a vicious, depraved, passion. Cheers, f From vivainio at gmail.com Fri Aug 15 07:46:54 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 14:46:54 +0300 Subject: [IPython-dev] Docs - authorship? In-Reply-To: References: Message-ID: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com> On Fri, Aug 15, 2008 at 6:23 AM, Fernando Perez wrote: > Please consider that I'm happy to follow purely an honor system here: > if you feel your contributions to that document (the PDF clocks in at > 128 pages right now) make you a co-author, simply tell me and I'll add > your name to the list. I will list 'authors: foo, bar, ...; with > contributions from: a,b,c,...' to credit both people who wrote major > portions and those who have contributed smaller but valuable parts. I have written the following chapters: IPython as a system shell - the 'Sh' profile String lists IPython Extension Api Provided extensions And done some modifications elsewhere, at least in installation and configuration. And yes, the stuff extracted from docstrigs. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Fri Aug 15 07:58:45 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 15 Aug 2008 14:58:45 +0300 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> Message-ID: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez wrote: > so I can't deal with this. I'm ok leaving it as is, since the code is > written, but no promises: when we restructure magics, I reserve the > right to change this if needed. If it can be kept without hassles, I Of course, though I think there should be no need for that. If the restructuring kills the freeform magic argument lists, it would need a redesign before it makes the architecture too rigid. > won't change it gratuitously; but my tolerance for special-casing > stuff is dropping dramatically, so this one could go in the future > (into cd -p foo or similar). It's not special casing as far as code/architecture goes, it's special casing as far as interactive usage goes (which is not a sin). User interfaces are all about special cases like that. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivian at vdesmedt.com Fri Aug 15 08:38:16 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Fri, 15 Aug 2008 14:38:16 +0200 Subject: [IPython-dev] synchronize with editor conform to PEP 8 and contains doc strings In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> Message-ID: <48A578B8.80208@vdesmedt.com> Fernando, Ville, I have change my code to conform to PEP 8, I get rid of the camel names and I have added doc strings. I'm ready for the next wave of comments :-) Regards, Vivian. From laurent.dufrechou at gmail.com Fri Aug 15 13:28:18 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Fri, 15 Aug 2008 19:28:18 +0200 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> Message-ID: <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com> Hi ville, I've just found that there is missing a file in the packaged thing: options.conf that must go inside Ipython/gui/wx/ Is ok to add it? It's a configuration that is used by my ipython0 WX gui to start up and remind what are the options used by the user. Cheers, Laurent > -----Message d'origine----- > De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- > bounces at scipy.org] De la part de Ville M. Vainio > Envoy??: vendredi 15 ao?t 2008 13:59 > ??: Fernando Perez > Cc?: IPython Development list > Objet?: Re: [IPython-dev] 0.9 beta, anything left? > > On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez > wrote: > > > so I can't deal with this. I'm ok leaving it as is, since the code > is > > written, but no promises: when we restructure magics, I reserve the > > right to change this if needed. If it can be kept without hassles, I > > Of course, though I think there should be no need for that. If the > restructuring kills the freeform magic argument lists, it would need > a redesign before it makes the architecture too rigid. > > > won't change it gratuitously; but my tolerance for special-casing > > stuff is dropping dramatically, so this one could go in the future > > (into cd -p foo or similar). > > It's not special casing as far as code/architecture goes, it's special > casing as far as interactive usage goes (which is not a sin). User > interfaces are all about special cases like that. > > -- > Ville M. Vainio - vivainio.googlepages.com > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: options.conf Type: application/octet-stream Size: 110 bytes Desc: not available URL: From gael.varoquaux at normalesup.org Fri Aug 15 14:16:06 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 15 Aug 2008 20:16:06 +0200 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com> References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com> Message-ID: <20080815181606.GC31583@phare.normalesup.org> On Fri, Aug 15, 2008 at 07:28:18PM +0200, Laurent Dufr?chou wrote: > I've just found that there is missing a file in the packaged thing: > options.conf that must go inside Ipython/gui/wx/ > Is ok to add it? > It's a configuration that is used by my ipython0 WX gui to start up and > remind what are the options used by the user. You have to keep in mind that it will be installed in a location where the user might not be able to write. You do have a file in the user home directory, right? You need to add this file to the package data, in the setup.py, for it to be installed. In ipython this is in setupbase.py, function find_package_data. Ga?l From laurent.dufrechou at gmail.com Fri Aug 15 16:02:01 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Fri, 15 Aug 2008 22:02:01 +0200 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <20080815181606.GC31583@phare.normalesup.org> References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com> <20080815181606.GC31583@phare.normalesup.org> Message-ID: <48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com> Hi Gael > You have to keep in mind that it will be installed in a location where > the user might not be able to write. You do have a file in the user > home > directory, right? > > You need to add this file to the package data, in the setup.py, for it > to > be installed. In ipython this is in setupbase.py, function > find_package_data. > You mean installed in user directory or Ipython/gui/wx? For the moment as I've got little time to work on it, I prefer to let it as is in wx directory, it just permits wxIpython to run and user (under linux) will not be able to save it's settings. Will try to find a workaround for the user directory as you said. Do you have an idea how user directory is defined under windows? Under linux it's ~/ but under windows I do not have any idea yet how to find it ... :) Laurent From robert.kern at gmail.com Fri Aug 15 17:18:06 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 15 Aug 2008 16:18:06 -0500 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> References: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com> <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> Message-ID: Ville M. Vainio wrote: > On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez wrote: > >> so I can't deal with this. I'm ok leaving it as is, since the code is >> written, but no promises: when we restructure magics, I reserve the >> right to change this if needed. If it can be kept without hassles, I > > Of course, though I think there should be no need for that. If the > restructuring kills the freeform magic argument lists, it would need > a redesign before it makes the architecture too rigid. As stated before, the architecture will still start with freeform argument lists. As a matter of *policy* for builtin IPython magics, however, - and -- arguments should be processed uniformly with the same internal machinery. -- 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 Fri Aug 15 17:29:19 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Aug 2008 14:29:19 -0700 Subject: [IPython-dev] 0.9 beta, anything left? In-Reply-To: <48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com> References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com> <20080815181606.GC31583@phare.normalesup.org> <48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com> Message-ID: On Fri, Aug 15, 2008 at 1:02 PM, Laurent Dufrechou wrote: > Hi Gael > >> You have to keep in mind that it will be installed in a location where >> the user might not be able to write. You do have a file in the user >> home >> directory, right? >> >> You need to add this file to the package data, in the setup.py, for it >> to >> be installed. In ipython this is in setupbase.py, function >> find_package_data. >> > > You mean installed in user directory or Ipython/gui/wx? > For the moment as I've got little time to work on it, I prefer to let it as > is in wx directory, it just permits wxIpython to run and user (under linux) > will not be able to save it's settings. > Will try to find a workaround for the user directory as you said. Do you > have an idea how user directory is defined under windows? > Under linux it's ~/ but under windows I do not have any idea yet how to find > it ... :) The ipython directory is where you should be storing things: In [6]: from IPython.ipapi import get In [7]: ip = get() In [8]: ip.IP.rc.ipythondir Out[8]: '/home/fperez/.ipython' This will be correctly computed under windows, users can set it via a variable, etc. All ipython code should access that guy instead of computing it directly. If you need to get the user's home dir, use this: In [9]: from IPython import genutils In [10]: genutils.get_home_dir -------> genutils.get_home_dir() Out[10]: '/home/fperez' It also tries to do the right thing under Win32. As for your code: please follow the pattern we've been using lately: have a synced branch that we can review on launchpad, keep it synced to trunk, and mark it for merging with the trunk. See for example how Vivian is doing it: https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor This way I or others can quickly review your changes, and if they are OK, the merge process is quick and easy. For example, right now I can go to vivian's review section: https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor/+merge/676 and see exactly what's there that is unique to this branch. We've gone back and forth a few times, and she keeps improving the state of the code, until we can merge it into the trunk. Let us know if you have any questions on this, or see my recent email to Vivian with the details and commands you need to type to make this work. Once you have it running, it's very easy to use. Cheers, f From fperez.net at gmail.com Fri Aug 15 17:39:39 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Aug 2008 14:39:39 -0700 Subject: [IPython-dev] Docs - authorship? In-Reply-To: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com> References: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com> Message-ID: On Fri, Aug 15, 2008 at 4:46 AM, Ville M. Vainio wrote: > I have written the following chapters: > > IPython as a system shell - the 'Sh' profile > String lists > IPython Extension Api > Provided extensions > > And done some modifications elsewhere, at least in installation and > configuration. And yes, the stuff extracted from docstrigs. I've listed you as an author, I'll push the changes in a minute (will go in for beta2). Cheers, f From fperez.net at gmail.com Fri Aug 15 17:43:38 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Aug 2008 14:43:38 -0700 Subject: [IPython-dev] Docs - authorship? In-Reply-To: References: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com> Message-ID: On Fri, Aug 15, 2008 at 2:39 PM, Fernando Perez wrote: > On Fri, Aug 15, 2008 at 4:46 AM, Ville M. Vainio wrote: > >> I have written the following chapters: >> >> IPython as a system shell - the 'Sh' profile >> String lists >> IPython Extension Api >> Provided extensions >> >> And done some modifications elsewhere, at least in installation and >> configuration. And yes, the stuff extracted from docstrigs. > > I've listed you as an author, I'll push the changes in a minute (will > go in for beta2). It would be great if you could add to the docs now that the system is in good shape, more info about the various things you'd been putting in the wiki. I honestly lost track of much of that, but I'd like to ensure that our docs keep up again with the funcitonality. Originally I was fanatic about not implementing anything without docs and for a while we ended up with the lyx/wiki split and much undocumented/scattered material. Let's do our best to catch up now, with inspiration from the matplotlib guys (their new docs are at 475 pages and counting!). Cheers, f From gael.varoquaux at normalesup.org Fri Aug 15 18:42:11 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 16 Aug 2008 00:42:11 +0200 Subject: [IPython-dev] Interpreter class: 666 Message-ID: <20080815224211.GI31583@phare.normalesup.org> I have just noticed that the interpreter class in ipython1 is exactly 666 lines long. I don't believe in coincidences. Ga?l From fperez.net at gmail.com Fri Aug 15 20:51:16 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 15 Aug 2008 17:51:16 -0700 Subject: [IPython-dev] Interpreter class: 666 In-Reply-To: <20080815224211.GI31583@phare.normalesup.org> References: <20080815224211.GI31583@phare.normalesup.org> Message-ID: On Fri, Aug 15, 2008 at 3:42 PM, Gael Varoquaux wrote: > I have just noticed that the interpreter class in ipython1 is exactly 666 > lines long. I don't believe in coincidences. We refactored it not a moment too soon :) Cheers, f From laurent.dufrechou at gmail.com Sat Aug 16 06:28:59 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Sat, 16 Aug 2008 12:28:59 +0200 Subject: [IPython-dev] IPython Patch In-Reply-To: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com> References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com> Message-ID: <48a6abee.05a0660a.76d1.0635@mx.google.com> Hi cody, Wow, thanks a lot for this patch! This was something I didn't knew how to solve! Thks a lot. > I made the changes to the code on the editra-plugins svn. Hopefully its > not too out of date from the latest ipython. Yeah, ipython guys have undergone big change in the frontend handling, so I'm waiting the new code base to make the frontend evolve. That's why this portion of code has not evolved since then :) Ipython 0.9 (that is going to be commited soon) will have all the new code base and will be ready for testing new code. So I will port al my 'old' code to this new arch, soon. Stay tuned ;) > -----Message d'origine----- > De?: Cody Precord [mailto:codyprecord at gmail.com] > Envoy??: samedi 16 ao?t 2008 04:16 > ??: Laurent Dufrechou > Objet?: IPython Patch > > Hello, > > I am in the process of trying to catch up on some bugs. Here is a patch > to fix an encoding issue in the ipython_view.py. Currently its > hardcoded to use cp1292 for encoding strings, this will fail on > machines that have character sets that cant be represented by cp1292. > Changed it to use 'locale.getpreferredencoding()' instead as this will > return the encoding that the system is using for its native strings. > > I made the changes to the code on the editra-plugins svn. Hopefully its > not too out of date from the latest ipython. > From fperez.net at gmail.com Sat Aug 16 23:20:03 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 20:20:03 -0700 Subject: [IPython-dev] branch management getting better... Message-ID: Hi all, I just merged Vivian's editor branch (will be in beta2) after she updated it per our review. Many thanks, Vivian! But I wanted to report that both a cleaner workflow on my part (I'm finally figuring out how to use bzr right) and what I think are improvements on launchpad itself, mean that the history is being shown much more cleanly. For example, if you go to: http://bazaar.launchpad.net/~ipython/ipython/trunk/changes and click on the triangle for rev 1101, you'll see it shows the topmost of Vivian's actual changes. You can then click on that number and you'll get: http://bazaar.launchpad.net/~ipython/ipython/trunk/changes/1001.2.8 So while it would be very nice if lp actually expanded the tree in the same window, at least now it shows the various merge lines. I also now see how to avoid the 'dropped revisions' problem we'd been having. The only mistake I made was to forget to call the final commit with --author before the push For this reason, I'd like to ask *everyone* who has commit rights to, for a little while, work on their own branches and let me do all the merging (I promise to be quick). If after a few weeks this works well for everyone, we'll document the workflow well and figure out whether to have a single merge person or a bunch of us with a workflow we all understand. But by not having anyone but me merge for a few revisions, we'll avoid the dropping of revisions we've had multiple times (it's happened to a bunch of us). Ultimately I actually think this may be a good way to work in the long haul, as we move towards more regular/strict code review (which we've already started doing recently): the person who makes the actual merge/push is in a way 'signing' the merged work as reviewer. This seems to give us: - summarized view of top-level changes, with an indication of who 'signs off' on the changes. - preservation of the individual change history/authorship for detailed analysis when needed. Any comments? Cheers, f From fperez.net at gmail.com Sat Aug 16 23:41:01 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 20:41:01 -0700 Subject: [IPython-dev] IPython Patch In-Reply-To: <48a6abee.05a0660a.76d1.0635@mx.google.com> References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com> <48a6abee.05a0660a.76d1.0635@mx.google.com> Message-ID: Hi Laurent, On Sat, Aug 16, 2008 at 3:28 AM, Laurent Dufr?chou wrote: > Hi cody, > > Wow, thanks a lot for this patch! This was something I didn't knew how to > solve! Thks a lot. > >> I made the changes to the code on the editra-plugins svn. Hopefully its >> not too out of date from the latest ipython. > > Yeah, ipython guys have undergone big change in the frontend handling, so > I'm waiting the new code base to make the frontend evolve. That's why this > portion of code has not evolved since then :) > Ipython 0.9 (that is going to be commited soon) will have all the new code > base and will be ready for testing new code. > So I will port al my 'old' code to this new arch, soon. > Stay tuned ;) please put your code in a branch we can all see, by doing something like cd your_working_branch bzr push --remember lp:~laurent-dufrechou/ipython/trunk-dev This will give everyone access to the code you're working on for review and merge. Also please make sure that when you merge a change sent in by an outside contributor, you list this fact in the commit message and record it as a standalone change as bzr commit --author="Name of other contributor" This way we can then, on each release, properly credit external users who make contributions to the project, which is very important. By the way, I've just done what I suggested above and pushed my local copy of trunk here: https://code.launchpad.net/~fdo.perez/ipython/trunk-dev so others can review also whatever I'm doing at any time. As I said in my previous email I want to be the only one to handle merging for a few days, but that's *only while we figure out the details*. I think a good way to use launchpad will be for everyone to do their work on a visible branch like this (in addition to possibly shared branches where several people are working on something together). These branches can be kept forever in 'merge pending' status, as we all go about implementing things and merging into trunk. Cheers, f From fperez.net at gmail.com Sun Aug 17 00:19:31 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 21:19:31 -0700 Subject: [IPython-dev] Ma branche In-Reply-To: <20080817032722.GA13945@phare.normalesup.org> References: <20080817032722.GA13945@phare.normalesup.org> Message-ID: On Sat, Aug 16, 2008 at 8:27 PM, Gael Varoquaux wrote: [ on-list, so we keep code reviews there] > Salut, > > Tu pourra marger ma branche avant la release ? J'ai un peu de > changements, rien d'important, mais j'avais fais une erreur de conception > avec le maniement des namespaces. In +def isolate_ipython0(func): + """ Decorator to isolate execution that involves an iptyhon0. + """ + def my_func(*args, **kwargs): + ipython0 = get_ipython0().IP + user_ns = ipython0.user_ns + global_ns = ipython0.global_ns + func(*args, **kwargs) + ipython0.user_ns = user_ns + ipython0.global_ns = global_ns + + return my_func there should be: try: func... finally: restore namespaces so that if the test fails, the namespace handling isn't all mucked up, no? Let me know when you change and I'll proceed. Otherwise it looks OK. Cheers, f From fperez.net at gmail.com Sun Aug 17 00:23:40 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 21:23:40 -0700 Subject: [IPython-dev] synchronize with editor conform to PEP 8 and contains doc strings In-Reply-To: <48A578B8.80208@vdesmedt.com> References: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com> <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com> <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com> <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com> <48A578B8.80208@vdesmedt.com> Message-ID: On Fri, Aug 15, 2008 at 5:38 AM, Vivian De Smedt wrote: > Fernando, Ville, > > I have change my code to conform to PEP 8, I get rid of the camel names and > I have added doc strings. > > I'm ready for the next wave of comments :-) I just merged your branch. Feel free to keep it listed if you intend to continue polishing this feature, this way we can review other improvements and merge them again in the future. And many thanks! Cheers, f From gael.varoquaux at normalesup.org Sun Aug 17 01:14:19 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 17 Aug 2008 07:14:19 +0200 Subject: [IPython-dev] Ma branche In-Reply-To: References: <20080817032722.GA13945@phare.normalesup.org> Message-ID: <20080817051419.GH15301@phare.normalesup.org> On Sat, Aug 16, 2008 at 09:19:31PM -0700, Fernando Perez wrote: > +def isolate_ipython0(func): > + """ Decorator to isolate execution that involves an iptyhon0. > + """ > + def my_func(*args, **kwargs): > + ipython0 = get_ipython0().IP > + user_ns = ipython0.user_ns > + global_ns = ipython0.global_ns > + func(*args, **kwargs) > + ipython0.user_ns = user_ns > + ipython0.global_ns = global_ns > + > + return my_func > there should be: > try: > func... > finally: > restore namespaces > so that if the test fails, the namespace handling isn't all mucked up, no? Yup, sounds good. Code review rocks. > Let me know when you change and I'll proceed. Otherwise it looks OK. I am good. However I have a test failing on my box and it doesn't seem to be due to my code (I have running the test suite without my tests): ====================================================================== FAIL: Doctest: IPython.iplib.InteractiveShell.complete ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py", line 343, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for IPython.iplib.InteractiveShell.complete File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", line 989, in complete ---------------------------------------------------------------------- File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", line 1011, in IPython.iplib.InteractiveShell.complete Failed example: _ip.IP.complete('x.l') Expected: ['x.ljust', 'x.lower', 'x.lstrip'] Got: [] >> raise self.failureException(self.format_failure(> instance at 0x40201c6c>.getvalue())) ---------------------------------------------------------------------- In addition, I have a test failing due to an import to win32api failing. Does all this work on your box? Ga?l From fperez.net at gmail.com Sun Aug 17 01:27:55 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 22:27:55 -0700 Subject: [IPython-dev] Ma branche In-Reply-To: <20080817051419.GH15301@phare.normalesup.org> References: <20080817032722.GA13945@phare.normalesup.org> <20080817051419.GH15301@phare.normalesup.org> Message-ID: Hey, On Sat, Aug 16, 2008 at 10:14 PM, Gael Varoquaux wrote: > I am good. However I have a test failing on my box and it doesn't seem to > be due to my code (I have running the test suite without my tests): > > ====================================================================== > FAIL: Doctest: IPython.iplib.InteractiveShell.complete > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py", > line 343, in runTest > raise self.failureException(self.format_failure(new.getvalue())) > AssertionError: Failed doctest test for > IPython.iplib.InteractiveShell.complete > File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", > line 989, in complete > > ---------------------------------------------------------------------- > File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", line > 1011, in IPython.iplib.InteractiveShell.complete > Failed example: > _ip.IP.complete('x.l') > Expected: > ['x.ljust', 'x.lower', 'x.lstrip'] > Got: > [] > >>> raise self.failureException(self.format_failure(>> instance at 0x40201c6c>.getvalue())) This passes fine now, after fixes I did a few days ago. Have you merged fully with trunk? Here's what 'make all' gives on my box: Ran 463 tests in 71.895s > In addition, I have a test failing due to an import to win32api failing. I don't see that, but I'm not sure why (this is on linux). I'll pull your changes now, my plan for next week after the scipy tutorial is to harden the test suite and improve its usability so everyone can start using it. Cheers, f From fperez.net at gmail.com Sun Aug 17 01:30:16 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 22:30:16 -0700 Subject: [IPython-dev] Ma branche In-Reply-To: <20080817051419.GH15301@phare.normalesup.org> References: <20080817032722.GA13945@phare.normalesup.org> <20080817051419.GH15301@phare.normalesup.org> Message-ID: On Sat, Aug 16, 2008 at 10:14 PM, Gael Varoquaux wrote: > I am good. However I have a test failing on my box and it doesn't seem to OK, I just finished the push, many thanks. Cheers, f From fperez.net at gmail.com Sun Aug 17 02:23:48 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 23:23:48 -0700 Subject: [IPython-dev] FYI: Updated team URL on launchpad Message-ID: Hi all, in case you kept any bookmarks for this around, I've changed the name and description of the IPython team on launchpad, so now we have: https://launchpad.net/ipython -> project page (code, bugs,...). Unchanged. https://launchpad.net/~ipython-dev -> "IPython Developers" team. Changed. Hopefully this will reduce confusion. If anyone objects let me know, but I figured some simple decisions like these can just be made :) Cheers, f From fperez.net at gmail.com Sun Aug 17 02:27:44 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 23:27:44 -0700 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <484A4962.5050606@aisystems.be> References: <484A4962.5050606@aisystems.be> Message-ID: Hi Vivian, 2008/6/7 Vivian De Smedt : > Dear All, > > This is mail concerning pyreadline. I'm a Window user and I'm using > pyreadline. Because of my VisualStudio background I have configured code > completion to be Ctrl+' ' and tab to be tab insertion. I don't know if your patch ever got in or not, but by now Jorgen is running a proper launchpad setup for pyreadline: https://code.launchpad.net/pyreadline Since you're pretty comfortable with bzr/launchpad by now, this should give you a good way to keep your fixes visible to Jorgen, so he can review them and possibly merge them in. Cheers, f From fperez.net at gmail.com Sun Aug 17 02:33:38 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Aug 2008 23:33:38 -0700 Subject: [IPython-dev] How do I do this in bzr? (again) In-Reply-To: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com> References: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com> Message-ID: Brian, On Fri, Jun 6, 2008 at 10:22 AM, Brian Granger wrote: > Hi, > > I am wondering how I can take a file/files from one bzr branch > (ipython1-dev) and bring them into another branch (ipython) if the two > branches have no common heritage. In this case, the two branches > hardly have the same structure and the incoming files will have to be > put into new location. Is this even possible? I know I could do mv > and then bzr add, but then I loose the history of the individual > files. Any ideas? I don't know if you ever figured out an answer to this, but I'd sure love to know. In the svn transition and ip0/1 merge we kind of butchered the ipython history, which I'm very sad about (and much of it was my fault, so I'm not blaming anyone here). It would be cool if some bzr guru came around and was able to produce a copy of today's trunk with a cleaner history... Cheers, f From stefan at sun.ac.za Sun Aug 17 03:57:31 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 17 Aug 2008 02:57:31 -0500 Subject: [IPython-dev] branch management getting better... In-Reply-To: References: Message-ID: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com> 2008/8/16 Fernando Perez : > much more cleanly. For example, if you go to: > > http://bazaar.launchpad.net/~ipython/ipython/trunk/changes I can't open this page -- am I doing something stupid? St?fan From fperez.net at gmail.com Sun Aug 17 03:59:51 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 00:59:51 -0700 Subject: [IPython-dev] branch management getting better... In-Reply-To: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com> References: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com> Message-ID: On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt wrote: > 2008/8/16 Fernando Perez : >> much more cleanly. For example, if you go to: >> >> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes > > I can't open this page -- am I doing something stupid? Sorry, as I just changed the team name, the url moved (after I'd written my original email): http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes Cheers, f From laurent.dufrechou at gmail.com Sun Aug 17 04:12:30 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Sun, 17 Aug 2008 10:12:30 +0200 Subject: [IPython-dev] IPython Patch In-Reply-To: References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com> <48a6abee.05a0660a.76d1.0635@mx.google.com> Message-ID: <7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com> Excellent, that was i wanted to ask you. I didn't knew how to create a new branch on launchad. Will do that thx. Update...: laurent at Pep:~/dev/ipython-wx_Ipython$ bzr push --remember lp:~laurent-dufrechou/ipython/trunk-dev bzr: ERROR: Transport operation not possible: http does not support mkdir() I've taken a look there (interesting doc by the way, can be a good tutorial to link in ipython wiki): http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html They seem to use bzr+ssh protocol. bzr push bzr+ssh://laurent-dufrechou at bazaar.launchpad.net/~laurent-dufrechou/ipython/trunk-dev And now seems ok, but the name is trunk-dev, is it ok? From stefan at sun.ac.za Sun Aug 17 04:15:32 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 17 Aug 2008 03:15:32 -0500 Subject: [IPython-dev] How do I do this in bzr? (again) In-Reply-To: References: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com> Message-ID: <9457e7c80808170115v9de2279n97703cffe445f394@mail.gmail.com> 2008/8/17 Fernando Perez : > On Fri, Jun 6, 2008 at 10:22 AM, Brian Granger wrote: >> Hi, >> >> I am wondering how I can take a file/files from one bzr branch >> (ipython1-dev) and bring them into another branch (ipython) if the two >> branches have no common heritage. In this case, the two branches >> hardly have the same structure and the incoming files will have to be >> put into new location. Is this even possible? I know I could do mv >> and then bzr add, but then I loose the history of the individual >> files. Any ideas? > > I don't know if you ever figured out an answer to this, but I'd sure > love to know. This plugin might help: https://launchpad.net/bzr-merge-into/ St?fan From fperez.net at gmail.com Sun Aug 17 04:29:04 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 01:29:04 -0700 Subject: [IPython-dev] IPython Patch In-Reply-To: <7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com> References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com> <48a6abee.05a0660a.76d1.0635@mx.google.com> <7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com> Message-ID: On Sun, Aug 17, 2008 at 1:12 AM, Laurent Dufrechou wrote: > Excellent, that was i wanted to ask you. > I didn't knew how to create a new branch on launchad. Will do that thx. > > Update...: > laurent at Pep:~/dev/ipython-wx_Ipython$ bzr push --remember > lp:~laurent-dufrechou/ipython/trunk-dev > bzr: ERROR: Transport operation not possible: http does not support mkdir() > > I've taken a look there (interesting doc by the way, can be a good > tutorial to link in ipython wiki): > http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html > > They seem to use bzr+ssh protocol. > bzr push bzr+ssh://laurent-dufrechou at bazaar.launchpad.net/~laurent-dufrechou/ipython/trunk-dev > > And now seems ok, but the name is trunk-dev, is it ok? Yes, that's fine: it's where *you* do development of the trunk (I named mine the same). It's now visible here: https://code.launchpad.net/~laurent-dufrechou/ipython/trunk-dev and I've marked it as proposed for merge into ipython trunk, so at any time it's easy to see any pending differences you may have. In my mind, I think of https://code.launchpad.net/~somebody/ipython/trunk-dev as "this is where user 'somebody' does personal development of the trunk for project ipython". It seems like an easy and simple mnemonic. As I mentioned, mine is identically hosted at https://code.launchpad.net/~fdo.perez/ipython/trunk-dev Cheers, f From fperez.net at gmail.com Sun Aug 17 05:07:22 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 02:07:22 -0700 Subject: [IPython-dev] Thoughts re Leo and Ipython notebooks. In-Reply-To: References: Message-ID: Hi Edward, 2008/7/28 Edward K. Ream : > I've just posted some thoughts re Leo as a compound document: > http://groups.google.com/group/leo-editor/browse_thread/thread/759d20f81119e5ca > > Among other things, the post discusses adding spreadsheet-like features to > Leo in a fairly easy way. These are just ideas, intended to encourage > further invention. > > My intuition tells me that IPython folk might find these ideas useful or > provocative: > > - Leo could be considered an IPython notebook. > > - Generalized spreadsheets might be useful in recording scientific > experiments. > > - Scientific experiments might want to generate notebook/spreadsheet entries > using scripts. > > - The post shows how to declare the "type" of scripts/nodes and show how to > embed scripts of arbitrary types into notebook entries. > > Imo, we have only just scratched the surface of what can be done with > scripts and notebooks. While I don't use leo myself, I know Ville has continued to make improvements to Leo integration, so there's definitely good things to be found here. You may have seen that we're now using the launchpad resources much more, so if at any point in time you find yourself writing a useful piece of code for the integration of the two that requires changes to ipython, simply publish it in a branch under your username on launchpad that we can access. We'll be happy to review the code, give you feedback, and merge it in if it all works out (we're moving towards a regular cycle of reviewing all code that we put up as much as possible). Cheers, f From laurent.dufrechou at gmail.com Sun Aug 17 05:38:32 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Sun, 17 Aug 2008 11:38:32 +0200 Subject: [IPython-dev] Ipython frontend (async, sync, line or block oriented...) Message-ID: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> Hi barry, I've started to take a look at your work. Seems from my quick review that you've done an asynchroneous frontend, block oriented while ga?l as gone through the opposite :) sync and line oriented. In fact, seems you've used ipython1 while gael has gone ipython0 no? (If I remember well, ipython1 can instanciate remote ipython instance) Can you explain me the difference between block oriented and line oriented? Line oriented is (I think) that you feed ipython instance with line and ipython instance determine by itself block bounds. So I think block oriented is that it is the frontend taht determine the bounds of the block? Cheers, Laurent From vds at aisystems.be Sun Aug 17 06:34:43 2008 From: vds at aisystems.be (Vivian De Smedt) Date: Sun, 17 Aug 2008 12:34:43 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: References: <484A4962.5050606@aisystems.be> Message-ID: <48A7FEC3.3080008@aisystems.be> Hi Fernando, Thanks for the merge in IPython, I'm always very proud to be able to contribute to my favorite python tool ;-) For pyreadline I did what you suggested I have created a tab-insertion branch from the pyreadline trunk I fix the problem in that branch commit and push the result to launchpad. It should be ready for review and merge :-) Vivian. From fperez.net at gmail.com Sun Aug 17 06:38:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 03:38:28 -0700 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <48A7FEC3.3080008@aisystems.be> References: <484A4962.5050606@aisystems.be> <48A7FEC3.3080008@aisystems.be> Message-ID: On Sun, Aug 17, 2008 at 3:34 AM, Vivian De Smedt wrote: > Hi Fernando, > > Thanks for the merge in IPython, I'm always very proud to be able to > contribute to my favorite python tool ;-) Well, we're glad to have you on board and contributing. > For pyreadline I did what you suggested I have created a tab-insertion > branch from the pyreadline trunk > I fix the problem in that branch commit and push the result to launchpad. > > It should be ready for review and merge :-) Great! Keep in mind that Jorgen Stenarson is the one who really runs pyreadline, so I'm afraid many of us here won't be able to help much on that one. But I'm sure Jorgen (and hopefully others who know the win32 platform well) will give you feedback for the merge. Regards, f From fperez.net at gmail.com Sun Aug 17 06:51:23 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 03:51:23 -0700 Subject: [IPython-dev] ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe?? [was: Re: Win32 IPython1?] In-Reply-To: <486EA0A3.9020307@uml.edu> References: <48457029.8020401@uml.edu> <4864549D.2010407@uml.edu> <48659443.4050109@uml.edu> <4865AB18.4040000@uml.edu> <486EA0A3.9020307@uml.edu> Message-ID: 2008/7/4 Alex Brown : > Following your recommendations I'm working with your (merged) trunk in > WinXP. However I am having continuing difficulty getting > ipython-0.9.0.bzr.r1016-py2.5 to work with either Python 2.4 or 2.5 (both > Enthought distributions). It may be that I'm not familiar enough with the > setup and installer tools, or with Windows touchup tricks. Is there any > chance of getting an exe installer, perhaps > ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe? Sorry for the long delay on this, as you may have noticed, it's been a bit hectic around here :) But now at http://ipython.scipy.org/dist/testing/ you can find the 0.9 beta #2 ready: http://ipython.scipy.org/dist/testing/ipython-0.9.beta2.win32-setup.exe We'd greatly appreciate your feedback on what works and what doesn't. Cheers, f From vivainio at gmail.com Sun Aug 17 06:52:58 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 17 Aug 2008 13:52:58 +0300 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <484D3F93.807@aisystems.be> References: <484A4962.5050606@aisystems.be> <200806091242.47835.meine@informatik.uni-hamburg.de> <484D2F59.9080206@aisystems.be> <200806091624.35935.meine@informatik.uni-hamburg.de> <484D3F93.807@aisystems.be> Message-ID: <46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com> 2008/6/9 Vivian De Smedt : > Here is my proposition of patch in a diff form. > + line_cursor = len(self.l_buffer) I think this only works if the cursor is at the end of the line. What if you go in the middle of entered text and press tab? -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Sun Aug 17 06:55:13 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 03:55:13 -0700 Subject: [IPython-dev] 0.9 beta #2 is ready Message-ID: At the usual place: http://ipython.scipy.org/dist/testing/ Feedback very much welcome. Cheers, f From jorgen.stenarson at bostream.nu Sun Aug 17 07:44:45 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Sun, 17 Aug 2008 13:44:45 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <48A7FEC3.3080008@aisystems.be> References: <484A4962.5050606@aisystems.be> <48A7FEC3.3080008@aisystems.be> Message-ID: <48A80F2D.4030901@bostream.nu> Hi Vivian, I'm happy to get patches and will look at this once I'm back from vacation. I'm back 25 aug. J?rgen Vivian De Smedt skrev: > Hi Fernando, > > Thanks for the merge in IPython, I'm always very proud to be able to > contribute to my favorite python tool ;-) > > For pyreadline I did what you suggested I have created a tab-insertion > branch from the pyreadline trunk > I fix the problem in that branch commit and push the result to launchpad. > > It should be ready for review and merge :-) > > Vivian. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From gael.varoquaux at normalesup.org Sun Aug 17 11:10:30 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 17 Aug 2008 17:10:30 +0200 Subject: [IPython-dev] Ipython frontend (async, sync, line or block oriented...) In-Reply-To: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> Message-ID: <20080817151030.GB14087@phare.normalesup.org> On Sun, Aug 17, 2008 at 11:38:32AM +0200, Laurent Dufrechou wrote: > I've started to take a look at your work. Seems from my quick review > that you've done an asynchroneous frontend, block oriented while ga?l > as gone through the opposite :) sync and line oriented. That's exactly it. We try to share a common base object, but as I was still experimenting with my own interfaces, I may not have shared as much as possible. If possible, in the long run, we want to move up methods from the LineFrontend class to the BaseFrontend class. > In fact, seems you've used ipython1 while gael has gone ipython0 no? > (If I remember well, ipython1 can instanciate remote ipython instance) Well, not really. I use an ipython1 instance (the Interpreter), but I also instanciate an ipython0 to prefilter the lines to give the magics and other goodies. In the long run, we should try and get rid of this instance as the magics get abstracted from ipython0. > Can you explain me the difference between block oriented and line oriented? In block-oriented you can edit several blocks at a time. Line-oriented does not know what blocks are, and only knows how to edit the last line (or set of lines, in my case). Line-oriented is weaker than block-oriented. For asynchronuous operation, block-oriented makes much more sens than line-oriented. Cheers, Ga?l From vivian at vdesmedt.com Sun Aug 17 15:06:01 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Sun, 17 Aug 2008 21:06:01 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com> References: <484A4962.5050606@aisystems.be> <200806091242.47835.meine@informatik.uni-hamburg.de> <484D2F59.9080206@aisystems.be> <200806091624.35935.meine@informatik.uni-hamburg.de> <484D3F93.807@aisystems.be> <46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com> Message-ID: <48A87699.3010209@vdesmedt.com> Ville, Thanks for your comment. You are right. Here is an another proposition that seems to address the point that you highlight: + cursor = min(self.l_buffer.point, len(self.l_buffer.line_buffer)) + ws = ' ' * (self.tabstop - (cursor % self.tabstop)) - ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop)) Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.dufrechou at gmail.com Sun Aug 17 15:21:53 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Sun, 17 Aug 2008 21:21:53 +0200 Subject: [IPython-dev] Future of wxIpython Message-ID: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com> Hi guys, I've started to quick review code in frontend. I must admit I don't know where to go in fact. Gael has implemented a wx widget that looks like what I've done with other let say technological choices. My code in /gui/wx is duplicate to this code (IpythonX.py). Where do you want to go with this code? Do you want me, to let it there in /gui or move it to /frontend/??? Seems for me that code base for frontend is in the root of frontend. Barry has an asynchroneous cocoa frontend in ./frontend/cocoa, gael a synchroneous in /frontend/wx. Must I add subdirectory, ./frontend/example/ ./frontend/wx2 ./frontend/wxaui ?_? If possible I would like not to trash my code :), and make it evolve with frontend new features. So what are my options? Cheers, Laurent From gael.varoquaux at normalesup.org Sun Aug 17 15:29:47 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 17 Aug 2008 21:29:47 +0200 Subject: [IPython-dev] Future of wxIpython In-Reply-To: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com> References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com> Message-ID: <20080817192947.GC692@phare.normalesup.org> On Sun, Aug 17, 2008 at 09:21:53PM +0200, Laurent Dufrechou wrote: > My code in /gui/wx is duplicate to this code (IpythonX.py). Where do > you want to go with this code? > Do you want me, to let it there in /gui or move it to /frontend/??? I would like the code in frontend to stay general. Your gui code does more than a frontend, as it introduces menus, and other items that actually get in the way of somebody who wants to reuse the frontend as part of a bigger application, without the bells and whistles. I have gone in my design for a layer structure, with different objects inheriting from eachother. The application designer is welcome to use any one of these. > Seems for me that code base for frontend is in the root of frontend. > Barry has an asynchroneous cocoa frontend in ./frontend/cocoa, gael a > synchroneous in /frontend/wx. > Must I add subdirectory, ./frontend/example/ ./frontend/wx2 ./frontend/wxaui ?_? I would rather not have another directory with Wx code. It will make it very confusing to people. > If possible I would like not to trash my code :), and make it evolve > with frontend new features. > So what are my options? Subclass or reuse either the WxController is wx_frontend, or the IPythonX one in ipythonx, if you want Ctrl-D to quit, as this is the only additional feature (appart from title changing). You have to define what it is that you want to develop: what is the goal of the code you are writing. This should help us figure out how it will fit in the big picture. Ga?l From fperez.net at gmail.com Sun Aug 17 15:43:57 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 12:43:57 -0700 Subject: [IPython-dev] Future of wxIpython In-Reply-To: <20080817192947.GC692@phare.normalesup.org> References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com> <20080817192947.GC692@phare.normalesup.org> Message-ID: On Sun, Aug 17, 2008 at 12:29 PM, Gael Varoquaux wrote: > On Sun, Aug 17, 2008 at 09:21:53PM +0200, Laurent Dufrechou wrote: >> If possible I would like not to trash my code :), and make it evolve >> with frontend new features. >> So what are my options? > > Subclass or reuse either the WxController is wx_frontend, or the IPythonX > one in ipythonx, if you want Ctrl-D to quit, as this is the only > additional feature (appart from title changing). > > You have to define what it is that you want to develop: what is the goal > of the code you are writing. This should help us figure out how it will > fit in the big picture. As I said in an eariler email, I have the impression that Laurent's code is a self-contained WX app, while Gael has built a basic component with an eye for the new architecture. So from where I stand (and I could be missing something, I haven't gone in detail over both codes), Laurent should be able to deploy a nice, full-featured IPython-Wx app, with menus, side panes, etc, built on top of the core component developed by Gael. Gael's is much simpler by design: it is intended to be almost like a 'wx-ipython widget' to be reused elsewhere, in particular for possible embedding into Enthought's Envisage system in the future. This division of concerns seems reasonable to me: one is a widget-like component, one is an end-user app. We can definitely ship both. And Laurent: we are most certainly interested in keeping your code and contributions in the project, no question about that. It's just that as part of the natural process of software evolution, sometimes parts of early prototypes do get scrapped for a different reimplementation/reorganization. That doesn't mean they were wrong or not appreciated, quite the opposite: they are often necessary to better understand the problem and continue making progress. So I'm sure that in the end, you'll end up reusing some of your early code, throwing away other pieces (because you'll be able to use Gael's components), but using your combined understanding of the problem to provide a better solution. Software development is by nature iterative, and in each cycle a little gets tossed out, a little new gets added, and hopefully the result is systematically better :) How does this sound? Cheers, f From fperez.net at gmail.com Sun Aug 17 15:54:43 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 12:54:43 -0700 Subject: [IPython-dev] branch management getting better... In-Reply-To: <9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com> References: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com> <9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com> Message-ID: Hey, On Sun, Aug 17, 2008 at 9:41 AM, St?fan van der Walt wrote: > 2008/8/17 Fernando Perez : >> On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt wrote: >>> 2008/8/16 Fernando Perez : >>>> much more cleanly. For example, if you go to: >>>> >>>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes >>> >>> I can't open this page -- am I doing something stupid? >> >> Sorry, as I just changed the team name, the url moved (after I'd >> written my original email): >> >> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes > > So, the number to click on is now 1102 (not 1101). Did this change > since you wrote the mail? I'm just wondering whether the graph is > ever re-labeled. It shouldn't, but this time it did: in all the storm of doing many things yesterday, I did a pull instead of a merge, which caused again the dreaded revision dropping, so the numbers changed. This is precisely what I was trying to avoid, so it's a bit embarrassing, I was just doing too many things and tripped. If you see now, for example this revision: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1103 got committed (by me) with Gael as author, since I was merging a set of patches by him. In a local log you can see the distinction between committer and author for this one, which is useful: I was committing work that was 100% Gael's, so this lets us track exactly who did what. This message (we've referred to it before) has a nice summary of the workflow I think we're settling into: https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html and I now find that I really am starting to agree with the various reasons he explains there, in particular: """ So why the distinction between a mainline and a merge commit. We have a few use cases for them... 1) "These are the patches reviewed by me". I don't review every single change someone makes. But I *do* review the merge before I commit it. 2) "Every commit on the mainline passes the test suite". This is a pretty big one for our bzr.dev process. 3) "Summary of changes". It gives an obvious place to summarize the many (potentially hundreds or more) commits someone made. You frequently want to keep all of those hundreds of revisions around, because it gives you nice, fine grained details about things that have changed. (Useful for annotate, or any sort of digging that needs to be done). But having a single summary revision, also lets the people who *don't* want to wade through 100 revisions to understand "Implemented bound branches". """ I'm also starting to use the same approach even when summarizing *my own* commits: I work on my branch (which is publicly mirrored) and do lots of small, frequent commits. Then I merge from it into my local mirror and push that upstream, with a single summary message. As we evolve towards more organized code review, this will be useful. Once a set of changes have been reviewed from the developer's branch, they get merged as a single set into the mainline. The only direct work into trunk should be the little tweaks that need to be made at release time to the version numbering files and such. Argh, finally getting this... :) Cheers, f From gael.varoquaux at normalesup.org Sun Aug 17 15:54:53 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 17 Aug 2008 21:54:53 +0200 Subject: [IPython-dev] Future of wxIpython In-Reply-To: References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com> <20080817192947.GC692@phare.normalesup.org> Message-ID: <20080817195453.GE692@phare.normalesup.org> On Sun, Aug 17, 2008 at 12:43:57PM -0700, Fernando Perez wrote: > As I said in an eariler email, I have the impression that Laurent's > code is a self-contained WX app, while Gael has built a basic > component with an eye for the new architecture. So from where I stand > (and I could be missing something, I haven't gone in detail over both > codes), Laurent should be able to deploy a nice, full-featured > IPython-Wx app, with menus, side panes, etc, built on top of the core > component developed by Gael. Gael's is much simpler by design: it is > intended to be almost like a 'wx-ipython widget' to be reused > elsewhere, in particular for possible embedding into Enthought's > Envisage system in the future. That's exactly it. I think the goals of the two code bases are not the same, and thus Laurent can hopefuly make good use of my implementation. In addition, I will not be pursuing Laurent's goals. Ga?l From gael.varoquaux at normalesup.org Sun Aug 17 18:10:00 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 18 Aug 2008 00:10:00 +0200 Subject: [IPython-dev] Bug in ultraTB, in current trunk. Message-ID: <20080817221000.GH692@phare.normalesup.org> Line 495 of ULtraTB.py, there is a bug that is probably due to the merge of the synchronize-editor branch on rev 1001.2.1. The filename variable is not defined anywhere. Ga?l From fperez.net at gmail.com Sun Aug 17 18:40:54 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 15:40:54 -0700 Subject: [IPython-dev] Bug in ultraTB, in current trunk. In-Reply-To: <20080817221000.GH692@phare.normalesup.org> References: <20080817221000.GH692@phare.normalesup.org> Message-ID: On Sun, Aug 17, 2008 at 3:10 PM, Gael Varoquaux wrote: > Line 495 of ULtraTB.py, there is a bug that is probably due to the merge > of the synchronize-editor branch on rev 1001.2.1. The filename variable > is not defined anywhere. Actually it was defined above in the same file, but only conditionally, so there was still a bug. I've fixed it and pushed an updated beta out. Thanks for reporting this. My goal for the sprints next week is to finish the testing machinery so that everyone can run the tests (without special installation or needing twisted/foolscap/anything beyond nose). Once we're there, I'd like to institute a policy of not accepting any code, from *anyone* (that means all of us, starting with me) that is missing tests. Since we have so much code already in place, this will mean that if you touch an existing function that's not already well tested (very likely), the burden will be on you (that's the royal you, starting obviously with myself) to first add tests for the function as it is now, to ensure that your new changes don't break it. It's the only way we'll be able to refactor what we need without endless breakage. Harsh, but IMO necessary. Thoughts, dissent? Cheers, f From fperez.net at gmail.com Sun Aug 17 18:41:31 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 17 Aug 2008 15:41:31 -0700 Subject: [IPython-dev] Bug in ultraTB, in current trunk. In-Reply-To: References: <20080817221000.GH692@phare.normalesup.org> Message-ID: On Sun, Aug 17, 2008 at 3:40 PM, Fernando Perez wrote: > Actually it was defined above in the same file, but only s/file/function/. Sorry f From barrywark at gmail.com Mon Aug 18 09:57:38 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 18 Aug 2008 09:57:38 -0400 Subject: [IPython-dev] Ipython frontend (async, sync, line or block oriented...) In-Reply-To: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> Message-ID: Laurent, Sorry to take a couple of days to get back to you. I imagine you'll see from my responses below that Ga?l and I have differing views on many of the design decisions that have gone into the curent frontend package. That's good, I think. Let me give you a quick overview of our goals in the frontend package and then I'll try to answer your specific questions inline below. The new IPython architecture (previously called ipython1) provides many opportunities to separate the interpreter logic from UI (terminal or GUI) logic. The frontend package is intended to make it easier (though not trivial) to write frontends for the IPython interpreter (where interpreter is IPython.kernel.core.interpreter.Interpreter, the new ipython1 interpreter, or an IPython.kernel.engineservice.IEngineService, the new ipython1 network/remote-aware IPython engine). There is a minimal functional spec in docs/source/development that highlights the many use casess we're trying to support. Briefly, they fall into three categories: 1) terminal-based frontends to a single Interpreter instance; very similar to the current IPython UI experience 2) GUI-based frontends to a single Interpreter instance; this is the category for both your and Ga?l's efforts. Because the current architecture is more separable, it will (hopefully) be easier to write a GUI frontend to the Interpreter using the new architecture. 3) GUI-based frontends that make use of Twisted and the IPython.kernel.engineservice architecture to provide a frontend to one or more local or remote engine services. This is the goal of my (still evolving) Cocoa frontend. I personally think this is a very promissing new possibility for new UI's for interactive computing that we haven't been able to explore with IPython in the ipyhton0 architecture. Clearly, supporting a diverse range of use cases is a difficult task. The goal of frontend is to provide whatever common functionality we can identify that supports all three of these use cases, embodied in a common base class FrontendBase. In addition, Gael has spearheaded creating common base classes for each of these use cases. The intention *is not* to create a common UI widget or event library for IPython. Frontend writiers will still have to make decisions (and, gasp, write code) to do "the right thing" with their UI system's events and widgets. Much of the original architecture for the frontend package was motivated by use case #3 above. Hence, the frontend API is biased towards treating code in blocks, rather than in lines. Gael's work required line-oriented APIs. We're still struggling to resolve this discrepancy. My goal in the next several weeks is to get the Cocoa frontend (asyncrhonous, block-oriented) to a stable state, thus stabilizing the frontend API for use case #3 and then to work on integrating Gael's use case and code in a more seamless way. more answers below... cheers, Barry On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou wrote: > Hi barry, > I've started to take a look at your work. Seems from my quick review > that you've done an asynchroneous frontend, block oriented while ga?l > as gone through the opposite :) sync and line oriented. correct > > In fact, seems you've used ipython1 while gael has gone ipython0 no? > (If I remember well, ipython1 can instanciate remote ipython instance) correct > > Can you explain me the difference between block oriented and line oriented? If you're familiar with Mathematica and Matlab, the UI of Mathematical provides good model for block oriented input whereas the Matlab command line (and the ipython0 terminal UI) provides a good model for line-oriented input. Line-oriented input is often more natural for people who are used to command-line UIs. The distributed nature of the ipython1 architecture (and the associated network latencies, loss of connections, etc.) make line-oriented UIs difficult. In this case, the block-oriented UI is a better model of the underlying architecture and so (I think) a better UI paradigm because it helps the user's mental model come into line with the software model. Having used both Mathematica and Matlab, I've found that my Matlab use patterns have migrated towards more block-like usage, so I personally don't find the block-oriented UI a problem, but personal preferences are, well, personal. We'll see. > > Line oriented is (I think) that you feed ipython instance with line > and ipython instance determine by itself block bounds. > So I think block oriented is that it is the frontend taht determine > the bounds of the block? Correct. This determination is an example of the common code that all block-oriented frontends will require and is therefore included in the frontend package. > > Cheers, > Laurent > From barrywark at gmail.com Mon Aug 18 10:01:43 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 18 Aug 2008 10:01:43 -0400 Subject: [IPython-dev] Ipython frontend (async, sync, line or block oriented...) In-Reply-To: References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com> Message-ID: On Mon, Aug 18, 2008 at 9:57 AM, Barry Wark wrote: > Laurent, > > Sorry to take a couple of days to get back to you. I imagine you'll > see from my responses below that Ga?l and I have differing views on > many of the design decisions that have gone into the curent frontend > package. That's good, I think. Let me give you a quick overview of our > goals in the frontend package and then I'll try to answer your > specific questions inline below. > > The new IPython architecture (previously called ipython1) provides > many opportunities to separate the interpreter logic from UI (terminal > or GUI) logic. The frontend package is intended to make it easier > (though not trivial) to write frontends for the IPython interpreter > (where interpreter is IPython.kernel.core.interpreter.Interpreter, the > new ipython1 interpreter, or an > IPython.kernel.engineservice.IEngineService, the new ipython1 > network/remote-aware IPython engine). There is a minimal functional > spec in docs/source/development that highlights the many use casess > we're trying to support. Briefly, they fall into three categories: > 1) terminal-based frontends to a single Interpreter instance; very > similar to the current IPython UI experience > 2) GUI-based frontends to a single Interpreter instance; this is the > category for both your and Ga?l's efforts. Because the current > architecture is more separable, it will (hopefully) be easier to write > a GUI frontend to the Interpreter using the new architecture. > 3) GUI-based frontends that make use of Twisted and the > IPython.kernel.engineservice architecture to provide a frontend to one > or more local or remote engine services. This is the goal of my (still > evolving) Cocoa frontend. I personally think this is a very promissing > new possibility for new UI's for interactive computing that we haven't > been able to explore with IPython in the ipyhton0 architecture. > > Clearly, supporting a diverse range of use cases is a difficult task. > The goal of frontend is to provide whatever common functionality we > can identify that supports all three of these use cases, embodied in a > common base class FrontendBase. In addition, Gael has spearheaded > creating common base classes for each of these use cases. The > intention *is not* to create a common UI widget or event library for > IPython. Frontend writiers will still have to make decisions (and, > gasp, write code) to do "the right thing" with their UI system's > events and widgets. > > Much of the original architecture for the frontend package was > motivated by use case #3 above. Hence, the frontend API is biased > towards treating code in blocks, rather than in lines. Gael's work > required line-oriented APIs. We're still struggling to resolve this > discrepancy. My goal in the next several weeks is to get the Cocoa > frontend (asyncrhonous, block-oriented) to a stable state, thus > stabilizing the frontend API for use case #3 and then to work on > integrating Gael's use case and code in a more seamless way. > > more answers below... > > cheers, > Barry > > On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou > wrote: >> Hi barry, >> I've started to take a look at your work. Seems from my quick review >> that you've done an asynchroneous frontend, block oriented while ga?l >> as gone through the opposite :) sync and line oriented. > > correct > >> >> In fact, seems you've used ipython1 while gael has gone ipython0 no? >> (If I remember well, ipython1 can instanciate remote ipython instance) > > correct Sorry, not entirely correct. Gael is using both the ipyhon1 and ipython0 APIs and interpreters in his frontend. This is because the ipython1 Interpreter is not yet as full-featured as the ipyhon0 frontend. Gael was under time constraints while writing his frontend. Unfortunatley he didn't have time to bring the ipyhon1 interpreter up to the feature set he needed and so had to go with this hybrid approach. As you might guess, this ultimatley leads to his frontend suffering from some of the tight-integration of UI and Interpreter suffered by old IPython frontends. > >> >> Can you explain me the difference between block oriented and line oriented? > > If you're familiar with Mathematica and Matlab, the UI of Mathematical > provides good model for block oriented input whereas the Matlab > command line (and the ipython0 terminal UI) provides a good model for > line-oriented input. > > Line-oriented input is often more natural for people who are used to > command-line UIs. The distributed nature of the ipython1 architecture > (and the associated network latencies, loss of connections, etc.) make > line-oriented UIs difficult. In this case, the block-oriented UI is a > better model of the underlying architecture and so (I think) a better > UI paradigm because it helps the user's mental model come into line > with the software model. > > Having used both Mathematica and Matlab, I've found that my Matlab use > patterns have migrated towards more block-like usage, so I personally > don't find the block-oriented UI a problem, but personal preferences > are, well, personal. We'll see. > >> >> Line oriented is (I think) that you feed ipython instance with line >> and ipython instance determine by itself block bounds. >> So I think block oriented is that it is the frontend taht determine >> the bounds of the block? > > Correct. This determination is an example of the common code that all > block-oriented frontends will require and is therefore included in the > frontend package. > >> >> Cheers, >> Laurent >> > From barrywark at gmail.com Wed Aug 20 16:12:55 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 20 Aug 2008 16:12:55 -0400 Subject: [IPython-dev] pushing python class definition to engines In-Reply-To: <6ce0ac130807151936o2b8fe47do7ee7900d8df62e4f@mail.gmail.com> References: <487D3A3F.4000304@astraw.com> <6ce0ac130807151936o2b8fe47do7ee7900d8df62e4f@mail.gmail.com> Message-ID: If only we had a language in which code and data were interchangeable... *LISP guru cries in the corner* ~Barry On Tue, Jul 15, 2008 at 10:36 PM, Brian Granger wrote: > Andrew, > > As Robert mentioned, this is really a limitation in how Python > serializes classes and instances. I have dealt with this in a couple > of ways: > > 1. Don't use classes :) More, seriously though, functions, even > those defined interactively can be pushed and pulled using > push_function and pull_function. There are only a few limitations, > like no closures. > > 2. Define your classes in a standalone module that can be imported by > the engines, controller and client. Then, you can push and pull > instances just fine using push and pull. This is mostly how I work - > I develop classes in serial first, put them in a module and then > simply import. > > Ironically, functions work better for this than classes. Until Python > has a different way of serializing classes and instances, we are > stuck. > > Cheers, > > Brian > > > On Tue, Jul 15, 2008 at 6:01 PM, Andrew Straw wrote: >> After seeing Brian Granger's great demo of the parallel abilities in >> IPython last week at the SIAM conference, I'm playing with ipython trunk >> which I just pulled out of launchpad (for this reason, I'm posting on >> the -dev list). >> >> Anyhow, if I start a client in the usual way: >> >> from IPython.kernel import client >> mec = client.MultiEngineClient() >> >> I can easily push Python integers: >> >> a=5 >> mec['a'] = a >> print mec.gather('a') >> >> But pushing classes doesn't work: >> >> class MyObj(object): >> def __init__(self,x): >> print 'PID',os.getpid() >> self.x=x >> >> mec['MyObj'] = MyObj >> print mec.gather('MyObj') >> >> That gives the following error. How can I push a class definition to my >> engines? >> >> Traceback (most recent call last): >> File "flydra/test_ipython.py", line 14, in >> mec.push_function(dict(MyObj= MyObj,)) >> File >> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/multiengineclient.py", >> line 606, in push_function >> return self._blockFromThread(self.smultiengine.push_function, >> namespace, targets=targets, block=block) >> File >> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/multiengineclient.py", >> line 456, in _blockFromThread >> result = blockingCallFromThread(function, *args, **kwargs) >> File >> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/twistedutil.py", >> line 69, in blockingCallFromThread >> return twisted.internet.threads.blockingCallFromThread(reactor, f, >> *a, **kw) >> File >> "/home/astraw/PY_ipython/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-x86_64.egg/twisted/internet/threads.py", >> line 83, in blockingCallFromThread >> result.raiseException() >> File >> "/home/astraw/PY_ipython/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-x86_64.egg/twisted/python/failure.py", >> line 319, in raiseException >> raise self.type, self.value, self.tb >> AttributeError: 'module' object has no attribute 'MyObj' >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Sat Aug 23 21:16:01 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 23 Aug 2008 18:16:01 -0700 Subject: [IPython-dev] Help with win32 installer... Message-ID: Howdy, we haven't received any feedback on the 0.9beta3, and it's looking like we probably had some breakage in the big reorganization of the setup.py file after the ipython0/1 big merge. Right now I don't have a win32 machine at all, and while Brian and Min do, none of us knows windows much at all. Is there any chance that someone could have a crack at seeing if the win32 installer can be made to work correctly? By correctly I mean like the 0.8.x series, which left ipython links in the Start menu in a submenu labelled "IPython", with a few profile shortcuts premade and links to html/pdf versions of the docs. We've really made great progress, so it would be really good to see a solid 0.9 release made... Any help will be very, very welcome. Cheers, f From laurent.dufrechou at gmail.com Sun Aug 24 15:52:19 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Sun, 24 Aug 2008 21:52:19 +0200 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: References: Message-ID: <48b1bc06.06e2660a.0218.7ade@mx.google.com> All seems ok on vista, installer is using privileged right, only html help is not ok: It point to : C:\Python25\share\doc\ipython\manual\ipython.html This file does not exist but index.html exist so... Pdf one is OK. The main issue I have is that as I have used egg_setup.py develop, so when I launch ipython it launch the one in my dev directory... Any trick to disable develop mode and to help you test beta3? Laurent > -----Message d'origine----- > De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- > bounces at scipy.org] De la part de Fernando Perez > Envoy??: dimanche 24 ao?t 2008 03:16 > ??: IPython Development list > Objet?: [IPython-dev] Help with win32 installer... > > Howdy, > > we haven't received any feedback on the 0.9beta3, and it's looking > like we probably had some breakage in the big reorganization of the > setup.py file after the ipython0/1 big merge. Right now I don't have > a win32 machine at all, and while Brian and Min do, none of us knows > windows much at all. > > Is there any chance that someone could have a crack at seeing if the > win32 installer can be made to work correctly? By correctly I mean > like the 0.8.x series, which left ipython links in the Start menu in a > submenu labelled "IPython", with a few profile shortcuts premade and > links to html/pdf versions of the docs. > > We've really made great progress, so it would be really good to see a > solid 0.9 release made... > > Any help will be very, very welcome. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev From laurent.dufrechou at gmail.com Sun Aug 24 16:09:00 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sun, 24 Aug 2008 22:09:00 +0200 Subject: [IPython-dev] ipython0 and sys.displayhook Message-ID: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com> Hello guys, I've run into a weird bug in editra ipython plugin. When instanciating ipython0 shell sys.displayhook was aletred by ipython and that interfered with classical python shell plugin in editra. I've quick workarounded it with saving sys.displayhook, then creating ipython0 instance and finally restoring sys.displayhook. The strange think is that ipython0 is still working. J In shell.py it seems that you do the same trick I do with "class IPShellEmbed" While in iplib.py there is: # I don't like assigning globally to sys, because it means when # embedding instances, each embedded instance overrides the previous # choice. But sys.displayhook seems to be called internally by exec, # so I don't see a way around it. We first save the original and then # overwrite it. self.sys_displayhook = sys.displayhook sys.displayhook = self.outputcache So why this displayhook is used for? Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sun Aug 24 16:13:06 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 24 Aug 2008 22:13:06 +0200 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: <48b1bc06.06e2660a.0218.7ade@mx.google.com> References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> Message-ID: <20080824201306.GC16507@phare.normalesup.org> On Sun, Aug 24, 2008 at 09:52:19PM +0200, Laurent Dufr?chou wrote: > The main issue I have is that as I have used egg_setup.py develop, so when I > launch ipython it launch the one in my dev directory... > Any trick to disable develop mode and to help you test beta3? Remove the IPython.egg-link in your site-packages and edit easy-install.pth to remove the line that references ipython. HTH, Ga?l From laurent.dufrechou at gmail.com Sun Aug 24 16:52:52 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Sun, 24 Aug 2008 22:52:52 +0200 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: <20080824201306.GC16507@phare.normalesup.org> References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> <20080824201306.GC16507@phare.normalesup.org> Message-ID: <48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com> Ok That Helped :) Beta3 install works under vista (so must work under XP, Vista is the worst thing you would like to test no? :p) Only html help is not OK as said before. > -----Message d'origine----- > De?: Gael Varoquaux [mailto:gael.varoquaux at normalesup.org] > Envoy??: dimanche 24 ao?t 2008 22:13 > ??: Laurent Dufr?chou > Cc?: 'Fernando Perez'; 'IPython Development list' > Objet?: Re: [IPython-dev] Help with win32 installer... > > On Sun, Aug 24, 2008 at 09:52:19PM +0200, Laurent Dufr?chou wrote: > > The main issue I have is that as I have used egg_setup.py develop, so > when I > > launch ipython it launch the one in my dev directory... > > Any trick to disable develop mode and to help you test beta3? > > Remove the IPython.egg-link in your site-packages and edit > easy-install.pth to remove the line that references ipython. > > HTH, > > Ga?l From laurent.dufrechou at gmail.com Sun Aug 24 17:21:11 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sun, 24 Aug 2008 23:21:11 +0200 Subject: [IPython-dev] Important bug correction ofr wxPython Message-ID: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com> Hi fernando, I've recently commited some important bug correction for wxIPython. This include, encoding problem, options.conf saved in user directory, sys.displayhook bug correction + addition of wxIpython in ./scripts. Can you include them for next beta or RC? (That does not interfere with ipython itself) Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Aug 24 18:26:52 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 24 Aug 2008 15:26:52 -0700 Subject: [IPython-dev] Important bug correction ofr wxPython In-Reply-To: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com> References: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com> Message-ID: Hi Laurent, On Sun, Aug 24, 2008 at 2:21 PM, Laurent Dufrechou wrote: > Hi fernando, > > I've recently commited some important bug correction for wxIPython. > > This include, encoding problem, options.conf saved in user directory, > sys.displayhook bug correction + addition of wxIpython in ./scripts. > > Can you include them for next beta or RC? (That does not interfere with > ipython itself) Yup, no problem. I'm leaving Los Angeles right now to go back home and won't look at this tomorrow, but the RC won't be cut until Wednesday I think, so no worries. Thanks! f From fperez.net at gmail.com Sun Aug 24 18:33:45 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 24 Aug 2008 15:33:45 -0700 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: <48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com> References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> <20080824201306.GC16507@phare.normalesup.org> <48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com> Message-ID: Hey Laurent, Many thanks for the win32 tests! It will be easy to fix the docs links, I was worried the breakage had been worse. Cheers, f From vivainio at gmail.com Mon Aug 25 03:01:32 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Mon, 25 Aug 2008 10:01:32 +0300 Subject: [IPython-dev] ipython0 and sys.displayhook In-Reply-To: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com> References: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com> Message-ID: <46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com> On Sun, Aug 24, 2008 at 11:09 PM, Laurent Dufrechou wrote: > So why this displayhook is used for? You can see that it's used as outputcache. Also, result_display hooks are hooked to it. IPython may appear to work if you change it, but it really doesn't work properly. So, you don't really want to forget ipythons display hook. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From laurent.dufrechou at gmail.com Mon Aug 25 05:28:14 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Mon, 25 Aug 2008 11:28:14 +0200 Subject: [IPython-dev] ipython0 and sys.displayhook In-Reply-To: <46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com> References: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com> <46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com> Message-ID: <48b27b30.09c5660a.0ff6.ffffd07a@mx.google.com> Hi ville, > > So why this displayhook is used for? > > You can see that it's used as outputcache. Also, result_display hooks > are hooked to it. > > IPython may appear to work if you change it, but it really doesn't > work properly. > > So, you don't really want to forget ipythons display hook. Arf bad news :/ Thx for your quick reply. What's strange is that in "class IPShellEmbed" in Shell.py line 178 the same trick like I did is used. So either, IPShellEmbed could be buggy either there is a trick used inside that permits to restore sys.display hook... Will read this code tonight, there must be a trick if you said that sys.displayhook is important! (in comment it is said it used by 'exec' but so far I haven't seen side effect, perhaps that's because I'm using a recent python interpreter...) Will check result_display/outputcache too... thx Cheers, Laurent From schut at sarvision.nl Mon Aug 25 05:54:03 2008 From: schut at sarvision.nl (Vincent Schut) Date: Mon, 25 Aug 2008 11:54:03 +0200 Subject: [IPython-dev] ipcontroller & ipengine Message-ID: <48B2813B.80203@sarvision.nl> Hi, I'm trying ipython's parallel capabilities once again, but things have changed... a lot apparently, since I last tried... I used to start 'ipcontroller --engine-ip 10.0.0.211' on localhost, and then 'ipengine -n8' on 10.0.0.211 (an 8-core machine). I could then connect from localhost to the controller, which connected to the engines at 10.0.0.211. Or I started ipcluster -n8 on 10.0.0.211, and then started a client connection from ipython specifying 10.0.0.211 as the controller-host to connect to. Neither works anymore. I know I can fiddle with furl files, but it is not convenient for me to have to copy a furl file each time I (re)start a cluster. I don't want to mess with ssh-agent either, if possible. What would be the simplest way to achieve a situation where 1) the engines run on remotehost, 2) I can connect from kernel.client to those engines? Controller might run anywhere it is convenient... Btw this is the error when I try to start a controller on localhost, ready to listen for engines on 10.0.0.211: $ ipcontroller --engine-ip 10.0.0.211 2008-08-22 15:49:19+0200 [-] Log opened. 2008-08-22 15:49:19+0200 [-] foolscap.pb.Listener starting on 45401 2008-08-22 15:49:19+0200 [-] Traceback (most recent call last): 2008-08-22 15:49:19+0200 [-] File "/usr/bin/ipcontroller", line 19, in 2008-08-22 15:49:19+0200 [-] ipcontroller.main() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/IPython/kernel/scripts/ipcontroller.py", line 363, in main 2008-08-22 15:49:19+0200 [-] start_controller() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/IPython/kernel/scripts/ipcontroller.py", line 217, in start_controller 2008-08-22 15:49:19+0200 [-] main_service.startService() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/application/service.py", line 260, in startService 2008-08-22 15:49:19+0200 [-] service.startService() 2008-08-22 15:49:19+0200 [-] File "build/bdist.linux-x86_64/egg/foolscap/pb.py", line 591, in startService 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/application/service.py", line 260, in startService 2008-08-22 15:49:19+0200 [-] service.startService() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/application/internet.py", line 91, in startService 2008-08-22 15:49:19+0200 [-] self._port = self._getPort() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/application/internet.py", line 116, in _getPort 2008-08-22 15:49:19+0200 [-] *self.args, **self.kwargs) 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/internet/posixbase.py", line 328, in listenTCP 2008-08-22 15:49:19+0200 [-] p.startListening() 2008-08-22 15:49:19+0200 [-] File "/usr/lib/python2.5/site-packages/twisted/internet/tcp.py", line 739, in startListening 2008-08-22 15:49:19+0200 [-] raise CannotListenError, (self.interface, self.port, le) 2008-08-22 15:49:19+0200 [-] twisted.internet.error.CannotListenError: Couldn't listen on 10.0.0.211:0: (99, 'Cannot assign requested address'). From jorgen.stenarson at bostream.nu Mon Aug 25 13:15:47 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 25 Aug 2008 19:15:47 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <48A7FEC3.3080008@aisystems.be> References: <484A4962.5050606@aisystems.be> <48A7FEC3.3080008@aisystems.be> Message-ID: <48B2E8C3.7090102@bostream.nu> Vivian, thanks for the patch it has been merged into trunk. /J?rgen Vivian De Smedt skrev: > Hi Fernando, > > Thanks for the merge in IPython, I'm always very proud to be able to > contribute to my favorite python tool ;-) > > For pyreadline I did what you suggested I have created a tab-insertion > branch from the pyreadline trunk > I fix the problem in that branch commit and push the result to launchpad. > > It should be ready for review and merge :-) > > Vivian. > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From jorgen.stenarson at bostream.nu Mon Aug 25 13:30:41 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 25 Aug 2008 19:30:41 +0200 Subject: [IPython-dev] moving a bug Message-ID: <48B2EC41.3050302@bostream.nu> Hi, I would like to move [Bug 257680] over to the pyreadline bugtracker does anyone know if it is possible to do so easily? Or do I have to open a new bug there and copy the contents over? /J?rgen From fperez.net at gmail.com Tue Aug 26 02:54:18 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 25 Aug 2008 23:54:18 -0700 Subject: [IPython-dev] moving a bug In-Reply-To: <48B2EC41.3050302@bostream.nu> References: <48B2EC41.3050302@bostream.nu> Message-ID: Hey, On Mon, Aug 25, 2008 at 10:30 AM, J?rgen Stenarson wrote: > Hi, > > I would like to move [Bug 257680] over to the pyreadline bugtracker does > anyone know if it is possible to do so easily? Or do I have to open a > new bug there and copy the contents over? I just did move it to pyreadline by changing the 'affects' field. Cheers, f From jorgen.stenarson at bostream.nu Tue Aug 26 14:16:15 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 26 Aug 2008 20:16:15 +0200 Subject: [IPython-dev] moving a bug In-Reply-To: References: <48B2EC41.3050302@bostream.nu> Message-ID: <48B4486F.9000302@bostream.nu> Fernando Perez skrev: > Hey, > > On Mon, Aug 25, 2008 at 10:30 AM, J?rgen Stenarson > wrote: >> Hi, >> >> I would like to move [Bug 257680] over to the pyreadline bugtracker does >> anyone know if it is possible to do so easily? Or do I have to open a >> new bug there and copy the contents over? > > I just did move it to pyreadline by changing the 'affects' field. > > Cheers, > > f > Thanks /J?rgen From fperez.net at gmail.com Tue Aug 26 15:28:16 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 26 Aug 2008 12:28:16 -0700 Subject: [IPython-dev] Documenting the recent editor sync extension Message-ID: Hi Vivian, I was today trying to help someone use your new editor sync tool: http://bazaar.launchpad.net/%7Eipython-dev/ipython/trunk/annotate/1121?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1 and I realized that in the review process, I forgot to ask you for any kind of top-level documentation and examples. Could you please add a top-level docstring describing the intended purpose of the tool, its main use cases, and a simple example of how to use it? There should be also a short paragraph about it in the docs/source/interactive/extension_api.txt file, so that users who read the manual can find out about it. We really need to move to ensuring that *all* new code can be used by new users by: - finding its capabilities in the documentation with a high-level view - finding a module-level docstring that explains the purpose of the tool - having good function/class-level docstrings that explain the specific use of each call. Otherwise we'll be forever answering these questions on the mailing list. Cheers, f From sunqiang at gmail.com Tue Aug 26 22:21:33 2008 From: sunqiang at gmail.com (sunqiang) Date: Wed, 27 Aug 2008 10:21:33 +0800 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: <48b1bc06.06e2660a.0218.7ade@mx.google.com> References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> Message-ID: same there, one windows server 2003, on windows xp. woks well except the html link. On Mon, Aug 25, 2008 at 3:52 AM, Laurent Dufr?chou wrote: > All seems ok on vista, installer is using privileged right, only html help > is not ok: > It point to : C:\Python25\share\doc\ipython\manual\ipython.html > This file does not exist but index.html exist so... > Pdf one is OK. > > The main issue I have is that as I have used egg_setup.py develop, so when I > launch ipython it launch the one in my dev directory... > Any trick to disable develop mode and to help you test beta3? > > Laurent > >> -----Message d'origine----- >> De : ipython-dev-bounces at scipy.org [mailto:ipython-dev- >> bounces at scipy.org] De la part de Fernando Perez >> Envoy? : dimanche 24 ao?t 2008 03:16 >> ? : IPython Development list >> Objet : [IPython-dev] Help with win32 installer... >> >> Howdy, >> >> we haven't received any feedback on the 0.9beta3, and it's looking >> like we probably had some breakage in the big reorganization of the >> setup.py file after the ipython0/1 big merge. Right now I don't have >> a win32 machine at all, and while Brian and Min do, none of us knows >> windows much at all. >> >> Is there any chance that someone could have a crack at seeing if the >> win32 installer can be made to work correctly? By correctly I mean >> like the 0.8.x series, which left ipython links in the Start menu in a >> submenu labelled "IPython", with a few profile shortcuts premade and >> links to html/pdf versions of the docs. >> >> We've really made great progress, so it would be really good to see a >> solid 0.9 release made... >> >> Any help will be very, very welcome. >> >> Cheers, >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From fperez.net at gmail.com Tue Aug 26 22:29:00 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 26 Aug 2008 19:29:00 -0700 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> Message-ID: On Tue, Aug 26, 2008 at 7:21 PM, sunqiang wrote: > same there, one windows server 2003, on windows xp. woks well except > the html link. Great, thanks. I'm fixing it literally *right now*. Cheers, f From sunqiang at gmail.com Tue Aug 26 22:34:16 2008 From: sunqiang at gmail.com (sunqiang) Date: Wed, 27 Aug 2008 10:34:16 +0800 Subject: [IPython-dev] Help with win32 installer... In-Reply-To: References: <48b1bc06.06e2660a.0218.7ade@mx.google.com> Message-ID: Fernando, I have reply this to u directly three day before, It looks Gmail label it as a spam. On Wed, Aug 27, 2008 at 10:29 AM, Fernando Perez wrote: > On Tue, Aug 26, 2008 at 7:21 PM, sunqiang wrote: >> same there, one windows server 2003, on windows xp. woks well except >> the html link. > > Great, thanks. I'm fixing it literally *right now*. > > Cheers, > > f > From vivian at vdesmedt.com Wed Aug 27 11:02:33 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Wed, 27 Aug 2008 19:32:33 +0430 Subject: [IPython-dev] Documenting the recent editor sync extension In-Reply-To: References: Message-ID: <48B56C89.2060409@vdesmedt.com> Hi Fernando, > Could you please add a > top-level docstring describing the intended purpose of the tool, its > main use cases, and a simple example of how to use it? There should > be also a short paragraph about it in the > docs/source/interactive/extension_api.txt file, so that users who read > the manual can find out about it. > Of course. I'm in Iran right now and I have a poor internet access. But as soon I come back I'll commit my change in the doc strings and let you know. Cheers, Vivian. From fperez.net at gmail.com Wed Aug 27 14:53:59 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 27 Aug 2008 11:53:59 -0700 Subject: [IPython-dev] Documenting the recent editor sync extension In-Reply-To: <48B56C89.2060409@vdesmedt.com> References: <48B56C89.2060409@vdesmedt.com> Message-ID: On Wed, Aug 27, 2008 at 8:02 AM, Vivian De Smedt wrote: > Hi Fernando, >> >> Could you please add a >> top-level docstring describing the intended purpose of the tool, its >> main use cases, and a simple example of how to use it? There should >> be also a short paragraph about it in the >> docs/source/interactive/extension_api.txt file, so that users who read >> the manual can find out about it. >> > > Of course. I'm in Iran right now and I have a poor internet access. But as > soon I come back I'll commit my change in the doc strings and let you know. Totally understood, no problem. Just push up to your branch as usual, we'll review it and iterate. Have a great trip! Regards, f From ondrej at certik.cz Wed Aug 27 20:17:16 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 28 Aug 2008 02:17:16 +0200 Subject: [IPython-dev] branch management getting better... In-Reply-To: References: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com> <9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com> Message-ID: <85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com> On Sun, Aug 17, 2008 at 9:54 PM, Fernando Perez wrote: > Hey, > > On Sun, Aug 17, 2008 at 9:41 AM, St?fan van der Walt wrote: >> 2008/8/17 Fernando Perez : >>> On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt wrote: >>>> 2008/8/16 Fernando Perez : >>>>> much more cleanly. For example, if you go to: >>>>> >>>>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes >>>> >>>> I can't open this page -- am I doing something stupid? >>> >>> Sorry, as I just changed the team name, the url moved (after I'd >>> written my original email): >>> >>> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes >> >> So, the number to click on is now 1102 (not 1101). Did this change >> since you wrote the mail? I'm just wondering whether the graph is >> ever re-labeled. > > It shouldn't, but this time it did: in all the storm of doing many > things yesterday, I did a pull instead of a merge, which caused again > the dreaded revision dropping, so the numbers changed. This is > precisely what I was trying to avoid, so it's a bit embarrassing, I > was just doing too many things and tripped. > > > If you see now, for example this revision: > > http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1103 > > got committed (by me) with Gael as author, since I was merging a set > of patches by him. In a local log you can see the distinction between > committer and author for this one, which is useful: I was committing > work that was 100% Gael's, so this lets us track exactly who did what. > This message (we've referred to it before) has a nice summary of the > workflow I think we're settling into: > > https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html > > and I now find that I really am starting to agree with the various > reasons he explains there, in particular: > > """ > So why the distinction between a mainline and a merge commit. We have a > few use cases for them... > > 1) "These are the patches reviewed by me". I don't review every single > change someone makes. But I *do* review the merge before I commit it. > > 2) "Every commit on the mainline passes the test suite". This is a > pretty big one for our bzr.dev process. > > 3) "Summary of changes". It gives an obvious place to summarize the many > (potentially hundreds or more) commits someone made. You frequently want > to keep all of those hundreds of revisions around, because it gives you > nice, fine grained details about things that have changed. (Useful for > annotate, or any sort of digging that needs to be done). > > But having a single summary revision, also lets the people who *don't* > want to wade through 100 revisions to understand "Implemented bound > branches". > """ > > I'm also starting to use the same approach even when summarizing *my > own* commits: I work on my branch (which is publicly mirrored) and do > lots of small, frequent commits. Then I merge from it into my local > mirror and push that upstream, with a single summary message. As we > evolve towards more organized code review, this will be useful. Once > a set of changes have been reviewed from the developer's branch, they > get merged as a single set into the mainline. The only direct work > into trunk should be the little tweaks that need to be made at release > time to the version numbering files and such. I have couple more questions to the workflow: So you publish let's say 30 little commits in your branch. Stefan reviews it, let's say he says the commits 15, 20 and 21 are crap and you should rework it. :) So will you add commits 31, 32 and 33 fixing the crap, or will you actually edit the commits 15, 20, 21 directly? Does bzr allow you to easily delete the public branch and repost your reworked 30 little commits? Because you said you merge those 30 little commits into one or a few commits, so people who pulled your branch will have mess in their repos, right? I like the direct editing workflow, i.e. I also like to commit 30 little commits and then merge it in a few well polished patches, send them for a review (e.g. push them into some branch), then fix things couple times depending on the review and finally the commits go in the main trunk. And I realized that mercurial is getting in my way in this workflow, and we switched to git with Kirill (another sympy developer) and it allows me to work in the way I described very easily and also to push the reworked patches to the same public branch (removing the old stuff). Ondrej From laurent.dufrechou at gmail.com Sat Aug 30 12:44:10 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sat, 30 Aug 2008 18:44:10 +0200 Subject: [IPython-dev] Ipython1 sync frontend crash Message-ID: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> Hi Gael, Just integrated your IPythonX widget insde wxIpython, now you can have my shell based on ipython0 and shell side by side by just pulling the notetab. I will use it to make a class based on wxfrontend to try to have same behavior as my previous widget. So here some questions: - How can I be able to be in sync with your branch with bzr. Is there any danger? - If I want to change your class to look/behave like my ipython0 widget, I think I should copy IPythonXController and then modify it to match my needs. Is it the good way to do? Or do you prefer I hack directly inside IPythonXController? Ho I've also just seen a little bug : IN[1]: __IP. Then press tab makes a string index out of range. Should be easy to solve. I think you should allow else iPython completion or Scintilla one not both.(Perhaps this bug come from there?) (On vista, I've got the two completion at the same time) Perhaps it is ever solved because I'm out of sync ^_- By the way, release_output() works well, the two shells don't interact eachother. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sat Aug 30 16:35:49 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 30 Aug 2008 22:35:49 +0200 Subject: [IPython-dev] Ipython1 sync frontend crash In-Reply-To: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> Message-ID: <20080830203549.GE6913@phare.normalesup.org> On Sat, Aug 30, 2008 at 06:44:10PM +0200, Laurent Dufrechou wrote: > - How can I be able to be in sync with your branch with bzr. Is > there any danger? There is danger of me introducing bugs in the frontend, and you finding them :). This would however be useful to QA the frontend. The way you can do it, is simply keep pulling (or merging) from my branch into your branch. Bzr makes this really easy. > - If I want to change your class to look/behave like my ipython0 > widget, I think I should copy IPythonXController and then modify it to > match my needs. Hum, I think you shouldn't. I think you should sub-class it. As a general rule, having to copy something is the sign of bad software design. If you find yourself having to copy, I would be happy if you tell me, as this might be the sign of a design mistake on my side. > Is it the good way to do? Or do you prefer I hack directly inside > IPythonXController? No. However, I am open to suggestions if you find design fault in the frontend. I will not add code taylored to specific needs, subclasses are ment for this, but we may find that the way things that are impossible to do by subclassing, and this may reveal design faults. > Ho I've also just seen a little bug : > IN[1]: __IP. > Then press tab makes a string index out of range. Should be easy to solve. Yes. Thank you. I have fixed that. > I think you should allow else iPython completion or Scintilla one not > both.(Perhaps this bug come from there?) (On vista, I've got the two > completion at the same time) IMHO, this is a feature. Well, not exactly: the fact that the drop-down menu still pops up after pressing tab is not great, but it is the only way I have found yet to keep the drop-down menu up. That drop down menu is really nice, I love it, and I still want it. It should just disappear when the tab key is pressed, and come back when needed. The problem is finding the right heuristic for "when needed". I agree that this still could use some more work. Ga?l From laurent.dufrechou at gmail.com Sat Aug 30 16:46:28 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sat, 30 Aug 2008 22:46:28 +0200 Subject: [IPython-dev] Any user of ipython -wthread over there? Message-ID: <48b9b1b3.095c5e0a.79ba.ffffeb9c@mx.google.com> Hi everybody, Does anybody using ipython -wthread to play with wx inside ipython tells me his use case and send me typical session, playing with wx objects? How do you use it, and why? I'm trying to get the same behavior in a graphical frontend (not console based), so any usecase will be very very helpful! Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.dufrechou at gmail.com Sat Aug 30 17:02:35 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Sat, 30 Aug 2008 23:02:35 +0200 Subject: [IPython-dev] Ipython1 sync frontend crash In-Reply-To: <20080830203549.GE6913@phare.normalesup.org> References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> <20080830203549.GE6913@phare.normalesup.org> Message-ID: <7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com> Ok will go with subclassing, but was thinking (and still ;) )that I add to start subclassing from WxController, because all functions in IPythonXController are specific to your app... I will give you feedback when ready. One day will have to share our skype nick ;) From laurent.dufrechou at gmail.com Sat Aug 30 17:19:35 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sat, 30 Aug 2008 23:19:35 +0200 Subject: [IPython-dev] Ipython1 sync frontend crash In-Reply-To: <20080830203549.GE6913@phare.normalesup.org> References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> <20080830203549.GE6913@phare.normalesup.org> Message-ID: <48b9b976.0405560a.6570.2584@mx.google.com> Ok I've merged your branch, but a stupid question remain... I need then to commit. But will fernando manage easily the fact that my branch is a merge of my work and your work? Does bzr handle that for us? Sorry bzr newbie :) ... From laurent.dufrechou at gmail.com Sat Aug 30 17:47:10 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sat, 30 Aug 2008 23:47:10 +0200 Subject: [IPython-dev] shell command for ipython1 frontend Message-ID: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com> Hi gael, import os import locale def system_call(self, command_string): ########## dirty quick hack J specific for windows patform ############# sp = command_string.split(' ') if sp[0] == 'ls': sp[0]='dir' command_string = ''.join([word+' ' for word in sp]) ############################################## stdin, stdout = os.popen4(command_string) result = stdout.read().decode('cp437').encode(locale.getpreferredencoding()) #"\x01\x1b[1;36m\x02" <-- add colour to the text... self.buffered_write("\x01\x1b[1;36m\x02"+result) self._buffer_flush(event=None) stdout.close() stdin.close() Seems to work better here under vista.(works on linux et osx) This is the code I use in my frontend. The code inside ############# is a quick workaround on top of my original code because seems ipython0 handled the things for me J So need more work bt seems to work faster and avoid the sleep(.1) Willing to use it? Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sat Aug 30 19:15:47 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 31 Aug 2008 01:15:47 +0200 Subject: [IPython-dev] Ipython1 sync frontend crash In-Reply-To: <7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com> References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com> <20080830203549.GE6913@phare.normalesup.org> <7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com> Message-ID: <20080830231547.GA32682@phare.normalesup.org> On Sat, Aug 30, 2008 at 11:02:35PM +0200, Laurent Dufrechou wrote: > Ok will go with subclassing, but was thinking (and still ;) )that I > add to start subclassing from WxController, because all functions in > IPythonXController are specific to your app... Sure, if you think so, your are probably right. My way of doing software is to move forward, and maybe not get the best design from the start, but I try to keep vigilent about my code, and refactor it as soon as I think I am doing something wrong. > I will give you feedback when ready. One day will have to share our > skype nick ;) gael.varoquaux :). I am in the US right now (actually staying at Fernando's place), so I am a bit out of sync with you. Ga?l From gael.varoquaux at normalesup.org Sat Aug 30 19:24:36 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 31 Aug 2008 01:24:36 +0200 Subject: [IPython-dev] shell command for ipython1 frontend In-Reply-To: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com> References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com> Message-ID: <20080830232435.GC32682@phare.normalesup.org> On Sat, Aug 30, 2008 at 11:47:10PM +0200, Laurent Dufrechou wrote: > Seems to work better here under vista.(works on linux et osx) This is the > code I use in my frontend. Hum, how do you deal with IO with the child process? Can you do: !cat and have a behavior more or less consistent with the behavior you would have in a normal terminal? What happens if you do (under linux, as I don't know the syntax for rm under windows): In [1]: !touch foobar In [2]: !rm -i foobar rm: remove regular empty file `foobar'? y In [3]: This is one the difficulties I have addressed in my frontend, and it is not trivial. Ga?l From laurent.dufrechou at gmail.com Sat Aug 30 20:07:09 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Sun, 31 Aug 2008 02:07:09 +0200 Subject: [IPython-dev] shell command for ipython1 frontend In-Reply-To: <20080830232435.GC32682@phare.normalesup.org> References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com> <20080830232435.GC32682@phare.normalesup.org> Message-ID: <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com> Good point ;) !del /P myfile.txt don't works at all with my code. So here is a bug report for you (just to keep a trace) ;) : In [2]: !ls The GUI freeze and I need to push enter to get this message: (under vista) Traceback (most recent call last): File "c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\kernel\core\sync_ traceback_trap.py", line 49, in hook raise TypeError: exceptions must be classes, instances, or strings (deprecated), not NoneType Original exception was: Traceback (most recent call last): File "C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\ipyth onx.py", line 42, in _on_key_down WxController._on_key_down(self, event, skip=skip) File "C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr ontend.py", line 368, in _on_key_down ConsoleWidget._on_key_down(self, event, skip=skip) File "c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\frontend\wx\conso le_widget.py", line 361, in _on_key_down self._on_enter() File "C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr ontend.py", line 440, in _on_enter PrefilterFrontEnd._on_enter(self) File "c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\frontend\linefron tendbase.py", line 274, in _on_enter self.execute(cleaned_buffer, raw_string=current_buffer) File "C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr ontend.py", line 288, in execute wx.Yield() File "C:\Python25\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 7630, in Yield return _core_.Yield(*args) wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at ..\..\src\msw\app.cpp(695) in wxApp::Yield(): wxYield called recursively Laurent From gael.varoquaux at normalesup.org Sat Aug 30 20:13:14 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 31 Aug 2008 02:13:14 +0200 Subject: [IPython-dev] shell command for ipython1 frontend In-Reply-To: <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com> References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com> <20080830232435.GC32682@phare.normalesup.org> <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com> Message-ID: <20080831001314.GF32682@phare.normalesup.org> On Sun, Aug 31, 2008 at 02:07:09AM +0200, Laurent Dufrechou wrote: > !del /P myfile.txt don't works at all with my code. > So here is a bug report for you (just to keep a trace) ;) : Yeah, I have been out of office for two weeks, so I can't test my code under windows (I have a windows VM at the office, but not on my laptop). This issue you have found is most probably trivial to fix (it is due to slightly different event loop behavior under windows and under the other platforms), but I need windows to develop. I'll fix it next week. Thanks for reporting though. Ga?l From laurent.dufrechou at gmail.com Sat Aug 30 20:40:52 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Sun, 31 Aug 2008 02:40:52 +0200 Subject: [IPython-dev] Last mail for the night Message-ID: <48b9e8a4.0437560a.4fc9.2334@mx.google.com> Ok, It?s late, i?m bumping my head on the wall here I?m desperately trying to change the default colors of your widget. Seems you?ve done the things cleaner than me J So If I well understood there is two method to change colors : Modify self.ANSI_STYLE and/or modify self.style, then call self._apply_style() What I want is black background and white text a la mode ipython console. I?ve found no way to get it :/ I?ve also tried to modify prompt (I like a lot the green /red original ones ) I?ve trie with no success, If you could also help me self.prompt_in1 = 'In $number:' ? just to try self.prompt_out = 'Out $number:' self.output_prompt_template = string.Template(self.prompt_out) self.input_prompt_template = string.Template(self.prompt_in1) don?t work, the prompt don?t change >From what I?ve seen from now, I?m quite happy with it, It looks like my old code with the rounded corner, like self.style (good point there) and the promp_template, I like a lot! (If I could modify them!) Subclassing WXController seems ok for now. You just don?t handle by default fonts, but seems easy to add in my class. if wx.Platform == '__WXMSW__': self.faces = { 'times': 'Times New Roman', 'mono' : 'Courier New', 'helv' : 'Arial', 'other': 'Comic Sans MS', 'size' : 10, 'size2': 8, } elif wx.Platform == '__WXMAC__': self.faces = { 'times': 'Times New Roman', 'mono' : 'Monaco', 'helv' : 'Arial', 'other': 'Comic Sans MS', 'size' : 10, 'size2': 8, } else: self.faces = { 'times': 'Times', 'mono' : 'Courier', 'helv' : 'Helvetica', 'other': 'new century schoolbook', 'size' : 10, 'size2': 8, } If I can play with self.style. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sat Aug 30 21:04:39 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 31 Aug 2008 03:04:39 +0200 Subject: [IPython-dev] Last mail for the night In-Reply-To: <48b9e8a4.0437560a.4fc9.2334@mx.google.com> References: <48b9e8a4.0437560a.4fc9.2334@mx.google.com> Message-ID: <20080831010439.GJ32682@phare.normalesup.org> On Sun, Aug 31, 2008 at 02:40:52AM +0200, Laurent Dufr?chou wrote: > So If I well understood there is two method to change colors...: > Modify self.ANSI_STYLE and/or modify self.style, then call > self._apply_style() Actually, to do this, you need to call "_configure_scintilla". Tell me if you can't get this working. This code could be cleaner. If you want to have a go a making a patch to improve this, I would be happy to accept it, as long as you try to keep the code quality high. > I've also tried to modify prompt (I like a lot the green /red original > ones...) > I've trie with no success, If you could also help me... > self.prompt_in1 = 'In $number:' ? just to try > self.prompt_out = 'Out $number:' > self.output_prompt_template = string.Template(self.prompt_out) > self.input_prompt_template = string.Template(self.prompt_in1) > don't work, the prompt don't change... This won't change the existing prompts, but it should new one. I suspect your are not setting these variables at the right time. You need to do this before you call the parent class __init__ as this call print the first prompt. I think this stinks a bit, but this is a direct consequence of having the frontend also being a widget. I think more and more the frontend should be a subobject of the widget, rather than a parent in the class hierarchy of the widget. I want to discuss this with Barry, however, as I know he has spent some time thinking about this. > From what I've seen from now, I'm quite happy with it, It looks like my > old code with the rounded corner, I didn't code this out of the blue. I spent a while studying your code, as well as other python graphical shells. > Subclassing WXController seems ok for now. You just don't handle by > default fonts, but seems easy to add in my class. Great. I am excited about this new devlopment. I really had this kind of usecases in mind for the frontend. A piece of warning, thought, there are still some things that will change with the frontend. Not only is there too much coupling between the model and the view (I still haven't identified well what the model is), but also the code is sometimes too much line-oriented for not good reason, and should be abstracted for a more general block-oriented approach, with the line-oriented being a special case (I know Barry is interested in block-oriented, and I am very much looking forward to working with him on this issue). Ga?l