From fperez.net at gmail.com Sun Jun 1 00:04:47 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 21:04:47 -0700 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. Message-ID: Hi all, A couple of months ago we started the launchpad/bzr experiment, and that has been very successful. I don't think there's any doubt that we'll stick with bzr for the time being, nobody feels like going back to SVN. To get things started, Ville created a clean bzr branch without any SVN history, partly because the scipy server at the time kept timing out and the svn import into launchpad wasn't working. Now that import does function, and one can check out the bzr version of SVN trunk via bzr branch lp:~vcs-imports/ipython/main/ ipython-svn The main ipython dev branch (our new 'trunk') can be obtained with bzr branch lp:ipython The problem I'm having is how to merge the latter into the former while preserving the full history. Because the bzr trunk was initialized without any SVN history, every attempt I've made so far has failed. I've tried bzr merge and rebase with various flags, without any success. I'm not even sure it's possible to do this cleanly, I'm afraid. The SVN trunk has several years of history that I'm not willing to lose (I already made the mistake of losing all project history in the CVS->SVN transition, I won't repeat that). I'd love to hear from anyone who might know how to make this merge, if it is possible. If it can't be made with bzr merge tools, I guess we can try to produce a set of bundles and apply them one by one or as a lump change with one gigantic commit message that preserves the other log... We're probably going to lose history no matter what, because of the 'branch folding' problem I mentioned earlier. The current bzr 'trunk' has a really funky log that shows these, and hopefully we won't make these mistakes with bzr in the future. But I'd like to minimize the losses, so I'd love if a bzr guru amongst us knows the magic trick. Cheers, f From fperez.net at gmail.com Sun Jun 1 00:14:07 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 21:14:07 -0700 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. In-Reply-To: References: Message-ID: On Sat, May 31, 2008 at 9:04 PM, Fernando Perez wrote: > The problem I'm having is how to merge the latter into the former > while preserving the full history. Because the bzr trunk was > initialized without any SVN history, every attempt I've made so far > has failed. I've tried bzr merge and rebase with various flags, > without any success. I'm not even sure it's possible to do this > cleanly, I'm afraid. I forgot to add that I tried to make a bundle containing the history of the entire new bzr trunk and apply that to the svn branch, but it produced 141 conflicts! Cleaning merge conflicts by hand is a huge PITA, cleaning 141 is way more than I think any of us is either interested in doing, or likely to do without making mistakes. I'll keep on trying, but any ideas would be very welcome at this point. Cheers, f From ellisonbg.net at gmail.com Sun Jun 1 01:08:52 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sat, 31 May 2008 23:08:52 -0600 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: References: Message-ID: <6ce0ac130805312208w6ce8d648pf54d05f7e8bad490@mail.gmail.com> One thing you might try is posting a question on the launchpad "answers" section. They were pretty good about answering a question when I asked. They might even be able to help or give good direction - we can't be the first to have faced this. Brian On Sat, May 31, 2008 at 10:04 PM, Fernando Perez wrote: > Hi all, > > A couple of months ago we started the launchpad/bzr experiment, and > that has been very successful. I don't think there's any doubt that > we'll stick with bzr for the time being, nobody feels like going back > to SVN. > > To get things started, Ville created a clean bzr branch without any > SVN history, partly because the scipy server at the time kept timing > out and the svn import into launchpad wasn't working. Now that import > does function, and one can check out the bzr version of SVN trunk via > > bzr branch lp:~vcs-imports/ipython/main/ ipython-svn > > The main ipython dev branch (our new 'trunk') can be obtained with > > bzr branch lp:ipython > > The problem I'm having is how to merge the latter into the former > while preserving the full history. Because the bzr trunk was > initialized without any SVN history, every attempt I've made so far > has failed. I've tried bzr merge and rebase with various flags, > without any success. I'm not even sure it's possible to do this > cleanly, I'm afraid. > > The SVN trunk has several years of history that I'm not willing to > lose (I already made the mistake of losing all project history in the > CVS->SVN transition, I won't repeat that). I'd love to hear from > anyone who might know how to make this merge, if it is possible. If > it can't be made with bzr merge tools, I guess we can try to produce a > set of bundles and apply them one by one or as a lump change with one > gigantic commit message that preserves the other log... > > We're probably going to lose history no matter what, because of the > 'branch folding' problem I mentioned earlier. The current bzr 'trunk' > has a really funky log that shows these, and hopefully we won't make > these mistakes with bzr in the future. But I'd like to minimize the > losses, so I'd love if a bzr guru amongst us knows the magic trick. > > Cheers, > > f > _______________________________________________ > IPython-user mailing list > IPython-user at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-user > From vivainio at gmail.com Sun Jun 1 01:35:04 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 1 Jun 2008 08:35:04 +0300 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. In-Reply-To: References: Message-ID: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> On 6/1/08, Fernando Perez wrote: > The SVN trunk has several years of history that I'm not willing to > lose (I already made the mistake of losing all project history in the We didn't actually lose the history - it's still there on launchpad, albeit on separate branch. We just don't NEED it on our work branch, since no branching/merging/revert is needed for that code. The problem with bzr is that it slows down with long history, so not having it around in our work copies is a net win. As a fun excercise, we might create an ipython repo with full history at some point - but it certainly doesn't yield tangible benefits right now. > We're probably going to lose history no matter what, because of the > 'branch folding' problem I mentioned earlier. The current bzr 'trunk' This doesn't lose history, even if it appears to be so from log messages. Still, it's annoying that bzr doesn't even WARN about pushing a branch over a branch with a completely different view of revisions... We might ask the bzr mailing list for a pre-push hook that does this - OTOH, I think the people with commit access now know to be wary of this little quirk. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From prabhu at aero.iitb.ac.in Sun Jun 1 02:06:49 2008 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 01 Jun 2008 11:36:49 +0530 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: <48423C79.7050901@aero.iitb.ac.in> Hi, Fernando Perez wrote: > This would bring us a number of benefits: [...] > * It would be much easier to explain to people that state of ipython. > "IPython is just IPython and now it has parallel computing" The > ambitious plans for refactoring, notebooks, frontends are underway, > but IPython is still just IPython. > > * The parallel computing stuff would instantly make it into all the > Linux distros. [...] > * Our entire combined effort (limited as it may be, we have some > great people on board) can be focused on a single problem, and we can > all trust that we're working together for the same goal. I agree with the majority of these benefits. I really would like to see the IPython1 features but am too addicted to IPython0 myself. However, I think there are two things that are being mixed up here. One is getting ip1 features in ip0 and the other is the headache of two separate development fronts. I think the idea of "backporting" ip1 features to ip0 is a great idea but I still see benefit in an experimental tree where you experiment on ideas. Too often, the need for stability bogs down interesting work and new developments. If you mix the two you get the benefit of one but loose out on the other. In my experience with mayavi2, I had the following problem, which is somewhat similar. For mayavi, the trunk is where the other great projects that it depended on were being developed and the branches was for stable work (branches are released as part of EPD, and in Debian etc.). This made doing any API breaking improvements a *huge* pain and a constant deterrent. This was incredibly frustrating for me as a developer -- I see warts that I know I can fix but can't! For a while everything was trundling along on the branch, it took a ton of work to first port everything from branches to trunk. Once the trunk worked, it was amazingly liberating. Immediately, I was able to resolve a few issues that plagued the codebase. Once those were done, I was able to cherry pick nice improvements that would not trigger an API break and backport them to the branch. This included a huge amount of functionality and tests. I agree that this can't always be done but the cost of my developer-interest is high and if I loose out interest in programming for the project, I might as well kill the project. What I'm saying is that there is a great advantage to having an official unstable branch. While that may or may not be ip1, I do think it is important to not blindly merge the two into one just for the sake of the benefits. My 50 paise. cheers, prabhu From prabhu at aero.iitb.ac.in Sun Jun 1 02:10:15 2008 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 01 Jun 2008 11:40:15 +0530 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. In-Reply-To: References: Message-ID: <48423D47.4030707@aero.iitb.ac.in> Fernando Perez wrote: > The problem I'm having is how to merge the latter into the former > while preserving the full history. Because the bzr trunk was > initialized without any SVN history, every attempt I've made so far > has failed. I've tried bzr merge and rebase with various flags, > without any success. I'm not even sure it's possible to do this > cleanly, I'm afraid. Not sure if this will work or if you've tried it, but can't you do the reverse? I.e. create a freshly imported bzr tree with the SVN history of the older code in SVN then merge *that* with the zero-history branch? cheers, prabhu From fperez.net at gmail.com Sun Jun 1 02:40:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 23:40:36 -0700 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. In-Reply-To: <48423D47.4030707@aero.iitb.ac.in> References: <48423D47.4030707@aero.iitb.ac.in> Message-ID: On Sat, May 31, 2008 at 11:10 PM, Prabhu Ramachandran wrote: > Fernando Perez wrote: >> >> The problem I'm having is how to merge the latter into the former >> while preserving the full history. Because the bzr trunk was >> initialized without any SVN history, every attempt I've made so far >> has failed. I've tried bzr merge and rebase with various flags, >> without any success. I'm not even sure it's possible to do this >> cleanly, I'm afraid. > > Not sure if this will work or if you've tried it, but can't you do the > reverse? I.e. create a freshly imported bzr tree with the SVN history of > the older code in SVN then merge *that* with the zero-history branch? I've tried that, but bzr merge refuses to apply the merge because it doesn't see the two as having a common ancestor. This seems to do exactly what I'm after: http://spacepants.org/src/bzrgraft/ Unfortunately the warnings about it being badly outdated are a bit worrying. I'm going to give it a try nonetheless, we'll see how it goes. Cheers, f From fperez.net at gmail.com Sun Jun 1 02:44:43 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 23:44:43 -0700 Subject: [IPython-dev] Porting SVN history to Launchpad - help needed. In-Reply-To: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> Message-ID: On Sat, May 31, 2008 at 10:35 PM, Ville M. Vainio wrote: > On 6/1/08, Fernando Perez wrote: > >> The SVN trunk has several years of history that I'm not willing to >> lose (I already made the mistake of losing all project history in the > > We didn't actually lose the history - it's still there on launchpad, > albeit on separate branch. We just don't NEED it on our work branch, > since no branching/merging/revert is needed for that code. The point is that (as per the other message), this branch is now *the* project. Making an arbitrary cut in history at any point in time (Feb 2008 in this case) makes no sense. > The problem with bzr is that it slows down with long history, so not > having it around in our work copies is a net win. As a fun excercise, > we might create an ipython repo with full history at some point - but > it certainly doesn't yield tangible benefits right now. I simply don't like idea of dumping away the whole line of development with the project's early history. If we're going to leave some history aside, I'd rather drop Feb-May 2008 than the previous years. If we can't make this work, I'll apply the recent changes as a single, gigantic change with a huge commit message (the whole log), and refer to the other branch for details. If I have to choose between 3 months and 3 years of history, I lose the three months, not the three years. Period. bzr graft would do the job, we'll see if I can make it run. Cheers, f From fperez.net at gmail.com Sun Jun 1 02:46:59 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 23:46:59 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <88e473830805312024o76df6d8byda0138cd6940f791@mail.gmail.com> References: <88e473830805312024o76df6d8byda0138cd6940f791@mail.gmail.com> Message-ID: On Sat, May 31, 2008 at 8:24 PM, John Hunter wrote: > On Sat, May 31, 2008 at 9:55 PM, Fernando Perez wrote: > >> So, any comments? We'd like to move forward *quickly* with this idea. >> We'd try to make a series of much more frequent releases, one for each >> key component we add in, so that little by little the baby can >> actually grow. There will be an initial period where I would prepare >> the ground in ip0 for the ip1 components to land in while Brian >> finishes a couple of things he has in his local branch, but we're >> talking a couple of weeks, not years. [..] > So I think your proposal is the right one. > Thanks for the feedback. MPL is a project I thought a lot about, because we've talked many times about your refactoring experiences there. So your perspective is actually very welcome on this front, thanks. Michael D. has done a superhuman job on MPL, but it's also true that working off something that works is always more rewarding and easier psychologically. I think I vastly underestimated the importance of that. Cheers, f From fperez.net at gmail.com Sun Jun 1 02:52:00 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 31 May 2008 23:52:00 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <48423C79.7050901@aero.iitb.ac.in> References: <48423C79.7050901@aero.iitb.ac.in> Message-ID: On Sat, May 31, 2008 at 11:06 PM, Prabhu Ramachandran wrote: > However, I think there are two things that are being mixed up here. One is > getting ip1 features in ip0 and the other is the headache of two separate > development fronts. I think the idea of "backporting" ip1 features to ip0 is > a great idea but I still see benefit in an experimental tree where you > experiment on ideas. Too often, the need for stability bogs down > interesting work and new developments. If you mix the two you get the > benefit of one but loose out on the other. > > In my experience with mayavi2, I had the following problem, which is > somewhat similar. For mayavi, the trunk is where the other great projects > that it depended on were being developed and the branches was for stable > work (branches are released as part of EPD, and in Debian etc.). This made > doing any API breaking improvements a *huge* pain and a constant deterrent. > This was incredibly frustrating for me as a developer -- I see warts that I > know I can fix but can't! For a while everything was trundling along on the > branch, it took a ton of work to first port everything from branches to > trunk. Once the trunk worked, it was amazingly liberating. Immediately, I > was able to resolve a few issues that plagued the codebase. Once those were > done, I was able to cherry pick nice improvements that would not trigger an > API break and backport them to the branch. This included a huge amount of > functionality and tests. I agree that this can't always be done but the > cost of my developer-interest is high and if I loose out interest in > programming for the project, I might as well kill the project. > > What I'm saying is that there is a great advantage to having an official > unstable branch. While that may or may not be ip1, I do think it is > important to not blindly merge the two into one just for the sake of the > benefits. Thanks for this take on it: I think we should be OK on that front though. ip1 and ip0 were unfortunately not really experimental/stable versions, they were effectively two projects meant to merge at some point in the future, but with no viable path (with the available time and resources) for that to happen in one gigantic shot. What we want to do now is basically start putting on the trunk of plain ipython the parts and features of ip1 that work well already, and gradually morph ip1 into the architecturally cleaner project (and well tested) that we've always wanted. For experimental development, we *will* have proper branches. Keep in mind that now we're on bzr, we have the technical support for easy and comfortable true branch work. So once this new merged ipython is up and running (a few weeks), we can call it 'trunk' and then have branches *off that* where experimental features can be developed. With this setup, said branches can still merge from trunk as needed while their neat ideas mature. That wasn't really viable with the ip0/ip1 split, since there was no true common ground for merging. So I do appreciate your concern and don't dismiss it offhand, but I think we're OK on that front. But thanks still for the feedback, these are all things I'd like to keep in mind. Cheers, f From fperez.net at gmail.com Sun Jun 1 03:10:01 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 00:10:01 -0700 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: <48424570.4010808@ar.media.kyoto-u.ac.jp> References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> Message-ID: On Sat, May 31, 2008 at 11:45 PM, David Cournapeau wrote: > Fernando Perez wrote: >>> >>> The problem with bzr is that it slows down with long history, so not >>> having it around in our work copies is a net win. As a fun excercise, >>> we might create an ipython repo with full history at some point - but >>> it certainly doesn't yield tangible benefits right now. > > (sorry for the doublon, I always forget reply to all...) > > Every DVCS slows down with long history, but really, if bzr is too slow, > then don't use it: using a DVCS will mean more history than with subversion. > Limiting yourself to less history because of bzr slowness sounds really > wrong to me: you lose the whole point. Yup, I forgot to say exactly that. > Now, I really cannot see how this would be the case for ipython: bzr is > slower than hg, and much slower than git, but ipython is a small project > (not that I want to diminish anybody's work, of course). Hopefully, bzr (or > our computer) will scale better when ipython will be as big as the linux > kernel :) No offense, I think pretty much the same: if bzr can't deal with a project of this size, it's useless. And I know that MUCH larger projects use it, so I'm sure this won't be the problem. > More seriously, I will take a look at this myself. Fernando, are you only > interested in the trunk history ? Yup. As I said above, you can do: bzr branch lp:~vcs-imports/ipython/main/ launchpad-svn-1 bzr branch lp:ipython ipython-main-2 Now the problem is how to produce a valid bzr branch that basically concatenates in time -1 and -2, in that order. bzr graft (http://spacepants.org/src/bzrgraft/) was meant exactly for that purpose, but it indeed doesn't work at all with today's bzr as the developer warned (I already tried). If you can find some combination of bzr merge/bundle/rebase that would do the trick, let me know. I've already written a little python script that can generate the individual changes and log messages as bundles/logfile pairs, but they still don't apply because the target is missing the required base revision. It kind of annoys me that one apparently can't force a bundle to apply (it's just a diff, after all!). There must be a way to do this... Cheers, f From fperez.net at gmail.com Sun Jun 1 03:28:18 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 00:28:18 -0700 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: <48424B1A.1060307@ar.media.kyoto-u.ac.jp> References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> Message-ID: On Sun, Jun 1, 2008 at 12:09 AM, David Cournapeau wrote: > Fernando Perez wrote: >> >> If you can find some combination of bzr merge/bundle/rebase that would >> do the trick, let me know. > > I was thinking about using a bigger hammer (git + bzr export). > >> It kind of annoys me that one apparently can't force a bundle to apply >> (it's just a diff, after all!). There must be a way to do this... >> > > bundle is not just a diff: it records information about file move and the > likes (which is useless in this case, since svn does not know about rename, > it just delete/copy). AFAIK, that's one fundamental difference between git > and bzr. I would not be able to explain the differences, but I know some > people chose git for this exact reasons (and that's why I think using git > for the import will be less hassle here). By all means, if git/bzr does the job, go for it! And yes, I was sloppy above, I know bundles contain extra info beyond the diff. But what I meant was that it should be possible to tell bzr simply to apply a bundle off a given point, much like you can with diff/patch. In fact that's precisely what bzr graft does, but I don't feel like learning the bzr API right now just to update 'bzr graft' for a one-off operation we want to perform. Thanks a lot for being willing to help here! Cheers, f From laurent.dufrechou at gmail.com Sun Jun 1 08:01:14 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Sun, 1 Jun 2008 14:01:14 +0200 Subject: [IPython-dev] Going mad with bzr push Message-ID: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com> Hi guys, Since this morning, i've tryied to push from my recent linux install... without success. I've done: ssh-keygen -t dsa ssh-add id_dsa uploaded the public key to my launchpad account that is laurent.dufrechou and: bzr push bzr+ssh:// laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/ and got: No such Launchpad account: laurent.dufrechou No such Launchpad account: laurent.dufrechou Permission denied (publickey). bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) Any idea? (Sure this is the bzr line that is bad) Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Sun Jun 1 08:40:18 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 1 Jun 2008 15:40:18 +0300 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: <46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com> On 6/1/08, Fernando Perez wrote: > So our current rethinking is: forge ahead with what we've been calling > IPython0, and begin integrating the various key (and functional) > components of IPython1 into it one by one. The IPython0/1 split will > end, and we will use all the good pieces of IPython1 to add > functionality to ip0 without losing its current features. At each 0.X This is definitely a good plan; even if porting of ipython0 code to ipython1 happened some day, the result would not be much "cleaner" than today's ipython0. Cleaning up ipython0's interfaces to allow inclusion of ipython1 is a better scheme overall; there are many places where obvious cleanups are possible (separation of input / output code etc), but have not been feasible because of "maintenance" status and small team - not to mention the questionable future. Essentially, creating an experimental branch of ipython0 where cleanups and ipython1 feature integration happens frees ipython0 from paralyzing conservativeness, and the development effort of everybody actually ends up in the hands of the end users. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Sun Jun 1 15:23:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 12:23:36 -0700 Subject: [IPython-dev] Going mad with bzr push In-Reply-To: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com> References: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com> Message-ID: On Sun, Jun 1, 2008 at 5:01 AM, Laurent Dufrechou wrote: > Hi guys, > Since this morning, i've tryied to push from my recent linux install... > without success. > I've done: > ssh-keygen -t dsa > ssh-add id_dsa > uploaded the public key to my launchpad account that is laurent.dufrechou > and: > > bzr push > bzr+ssh://laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/ > > and got: > No such Launchpad account: laurent.dufrechou > No such Launchpad account: laurent.dufrechou > Permission denied (publickey). > bzr: ERROR: Connection closed: please check connectivity and permissions > (and try -Dhpss if further diagnosis is required) > I see your account as: https://launchpad.net/~laurent-dufrechou There's a '-', not a '.' between your first/last names. That could be the problem. Cheers, f From fperez.net at gmail.com Sun Jun 1 15:27:31 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 12:27:31 -0700 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: <484267EF.5070500@ar.media.kyoto-u.ac.jp> References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> <484267EF.5070500@ar.media.kyoto-u.ac.jp> Message-ID: On Sun, Jun 1, 2008 at 2:12 AM, David Cournapeau wrote: > Fernando Perez wrote: >> >> By all means, if git/bzr does the job, go for it! >> > > Ok, I tried different things without success, but I think I know why you > cannot merge successfully the new branch into the old one: many files are in > DOS format in the new trunk ! > > file IPython/* on the first bzr revision gives me: > > IPython/background_jobs.py: ASCII English text, with CRLF line > terminators > IPython/ColorANSI.py: ASCII English text, with CRLF line > terminators > IPython/completer.py: a python script text executable > IPython/ConfigLoader.py: ASCII English text, with CRLF line > terminators > IPython/CrashHandler.py: ASCII English text, with CRLF line > terminators > IPython/Debugger.py: ASCII English text, with CRLF line > terminators > IPython/deep_reload.py: ASCII Java program text, with CRLF line > terminators > IPython/demo.py: a python script text executable > IPython/DPyGetOpt.py: ASCII English text, with CRLF line > terminators > IPython/dtutils.py: a python script text executable > IPython/excolors.py: ASCII English text > IPython/Extensions: directory > IPython/external: directory > IPython/FakeModule.py: ASCII English text, with CRLF line > terminators > IPython/generics.py: ASCII Java program text > IPython/genutils.py: ASCII English text, with CRLF line > terminators > IPython/Gnuplot2.py: ASCII English text, with CRLF line > terminators > IPython/GnuplotInteractive.py: ASCII English text, with CRLF line > terminators > IPython/GnuplotRuntime.py: ASCII Java program text, with CRLF line > terminators > IPython/gui: directory > IPython/history.py: ASCII Java program text > IPython/hooks.py: a python script text executable > IPython/__init__.py: ASCII English text, with CRLF line > terminators > IPython/ipapi.py: troff or preprocessor input text > IPython/iplib.py: ASCII English text, with CRLF line > terminators > IPython/ipmaker.py: ASCII English text, with CRLF line > terminators > IPython/ipstruct.py: ASCII English text, with CRLF line > terminators > IPython/irunner.py: a python script text executable > IPython/Itpl.py: ASCII English text, with CRLF line > terminators > IPython/Logger.py: ASCII C++ program text, with CRLF line > terminators > IPython/macro.py: a python script text executable > IPython/Magic.py: ASCII English text, with CRLF line > terminators > IPython/numutils.py: ASCII English text, with CRLF line > terminators > IPython/OInspect.py: ASCII English text, with CRLF line > terminators > IPython/OutputTrap.py: ASCII English text, with CRLF line > terminators > IPython/platutils_dummy.py: ASCII English text > IPython/platutils_posix.py: ASCII Java program text > IPython/platutils.py: ASCII English text > IPython/platutils_win32.py: ASCII Java program text > IPython/prefilter.py: ASCII English text > IPython/Prompts.py: ASCII English text, with CRLF line > terminators > IPython/PyColorize.py: ASCII Pascal program text, with CRLF line > terminators > IPython/Release.py: ASCII English text, with CRLF line > terminators > IPython/rlineimpl.py: ASCII English text > IPython/shadowns.py: a python script text executable > IPython/Shell.py: ASCII English text, with CRLF line > terminators > IPython/strdispatch.py: ASCII Java program text > IPython/ultraTB.py: ASCII English text, with CRLF line > terminators > IPython/upgrade_dir.py: a python script text executable > IPython/usage.py: ASCII English text, with CRLF line > terminators > IPython/UserConfig: directory > IPython/wildcard.py: UTF-8 Unicode English text > IPython/winconsole.py: a python script text executable > > I am afraid it will be a nightmare to merge. I am trying to get the first > version without any CRLF line terminator, and diffing from there, Argh!!! I have no idea how that happened, I only work under Linux. But we've had cases before of devs who work under Win32 committing accidentally DOS-formatted files. I used to notice right away because old XEmacs showed the ^M characters at the end of the lines. But these days, Emacs fixes that silently and hides them out (it does show a little 'DOS' marker on the bottom left). But which branch do you see this on? If I look for example at Magic.py on either the launchpad-svn branch (the one from vcs-imports) or on the main stable-dev one, I don't get the DOS marker. I suppose it's possible that there are *mixed* EOL markers in those files, that Emacs is failing to detect. It probably only scans the first few lines to make a decision, so chances are what we have is a mess of files with mixed line endings. I'm leaning towards simply ditching our history for the last three months. I spent a fair amount of time yesterday on it without success (I tried lots of things) and so have you with git. I've just gone on IRC to ask on the bzr channel, I might get a bit of help there. But I have a bunch of 'life' related things to do today, so unless an easy solution materializes, I think we'll just have to move forward. But thanks for trying, and if you do come up with a solution, by all means let us know! Cheers, f From fperez.net at gmail.com Sun Jun 1 15:31:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 12:31:36 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com> References: <46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com> Message-ID: On Sun, Jun 1, 2008 at 5:40 AM, Ville M. Vainio wrote: > On 6/1/08, Fernando Perez wrote: > >> So our current rethinking is: forge ahead with what we've been calling >> IPython0, and begin integrating the various key (and functional) >> components of IPython1 into it one by one. The IPython0/1 split will >> end, and we will use all the good pieces of IPython1 to add >> functionality to ip0 without losing its current features. At each 0.X > > This is definitely a good plan; even if porting of ipython0 code to > ipython1 happened some day, the result would not be much "cleaner" > than today's ipython0. > > Cleaning up ipython0's interfaces to allow inclusion of ipython1 is a > better scheme overall; there are many places where obvious cleanups > are possible (separation of input / output code etc), but have not > been feasible because of "maintenance" status and small team - not to > mention the questionable future. Essentially, creating an experimental > branch of ipython0 where cleanups and ipython1 feature integration > happens frees ipython0 from paralyzing conservativeness, and the > development effort of everybody actually ends up in the hands of the > end users. I'm super happy to see everyone is so positive about the plan, and thanks to all for the feedback. This response is an indicator (and a lesson, at least to me) that the change was overdue :) This new setup will let us all work with better integration towards a common goal. I have urgent, immediate need of the ip1 features being usable in production for research work at Berkeley, and I also want things to be in good shape by the end of the summer: in the fall new grad students arrive, and there are a number of interesting research ideas that Brian and I want to push forward with that will require a workable codebase for others to participate with. Having the support of bzr will hopefully allow us to be flexible about trying out small experimental side branches for new features with regular merges, instead of the 'forever split' situation we were trapped in. So let's move on! Cheers, f From vivainio at gmail.com Sun Jun 1 15:42:38 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 1 Jun 2008 22:42:38 +0300 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> <484267EF.5070500@ar.media.kyoto-u.ac.jp> Message-ID: <46cb515a0806011242u245a348cu9cda24c53d4e160e@mail.gmail.com> On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez wrote: >> file IPython/* on the first bzr revision gives me: Yes, the first revision in bzr indeed har CRLF newlines. This happened because on windows, svn checks files out in "native" line feed format (which sucks), and the bzr repo was created directly from that tree. Few revisions later, the linefeeds were corrected. I'm not sure why this should break the repo combination, though - linefeed change is like any other change, though one that sadly affects every line. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Sun Jun 1 15:45:55 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 1 Jun 2008 22:45:55 +0300 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> <484267EF.5070500@ar.media.kyoto-u.ac.jp> Message-ID: <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com> On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez wrote: > I'm leaning towards simply ditching our history for the last three > months. I spent a fair amount of time yesterday on it without success > (I tried lots of things) and so have you with git. I've just gone on > IRC to ask on the bzr channel, I might get a bit of help there. But I > have a bunch of 'life' related things to do today, so unless an easy > solution materializes, I think we'll just have to move forward. This is a reasonable solution if everything else fails. We just leave the contents of stable-dev dangling around, and mark it as "abandoned" - it's still available for browsing if need be. The commit message should contain full contents of "bzr log" for reference, though, as well as the url for the branch. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Sun Jun 1 15:53:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 12:53:36 -0700 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com> References: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com> <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> <484267EF.5070500@ar.media.kyoto-u.ac.jp> <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com> Message-ID: On Sun, Jun 1, 2008 at 12:45 PM, Ville M. Vainio wrote: > On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez wrote: > >> I'm leaning towards simply ditching our history for the last three >> months. I spent a fair amount of time yesterday on it without success >> (I tried lots of things) and so have you with git. I've just gone on >> IRC to ask on the bzr channel, I might get a bit of help there. But I >> have a bunch of 'life' related things to do today, so unless an easy >> solution materializes, I think we'll just have to move forward. > > This is a reasonable solution if everything else fails. We just leave > the contents of stable-dev dangling around, and mark it as "abandoned" > - it's still available for browsing if need be. > > The commit message should contain full contents of "bzr log" for > reference, though, as well as the url for the branch. Yes, both points were exactly what I had in mind doing. It will still take some manual labor, but the alternatives aren't looking feasible. On the IRC channel all I got was 'try rebase' (which doesn't work), and 'try the list'. I'm running out of patience for this one though, so I think I'll move on. If someone figures out how to do this, or has the energy to resurrect bzr-graft, great. As far as I'm concerned, the above plan is reasonable (if not ideal), and the faster we do it, the less history we end up trapping in this side, frozen branch. Cheers, f From fperez.net at gmail.com Sun Jun 1 16:50:15 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 13:50:15 -0700 Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad - help needed. In-Reply-To: References: <48424570.4010808@ar.media.kyoto-u.ac.jp> <48424B1A.1060307@ar.media.kyoto-u.ac.jp> <484267EF.5070500@ar.media.kyoto-u.ac.jp> <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com> Message-ID: On Sun, Jun 1, 2008 at 12:53 PM, Fernando Perez wrote: > Yes, both points were exactly what I had in mind doing. It will still > take some manual labor, but the alternatives aren't looking feasible. > On the IRC channel all I got was 'try rebase' (which doesn't work), > and 'try the list'. I'm running out of patience for this one though, > so I think I'll move on. I've made one last try by mailing the bzr list. If a magical, 'type this and it works' recipe comes back I'll use it, else I'll go with our sub-optimal-but-acceptable plan B. Cheers, f From stefan at sun.ac.za Sun Jun 1 17:07:27 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 1 Jun 2008 23:07:27 +0200 Subject: [IPython-dev] .. hint:: not support in HTML docs? In-Reply-To: References: <6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com> <3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com> <6ce0ac130805121918t470fbd46icb709523440a9978@mail.gmail.com> <3d375d730805121929r16a72402q1cc83b64beba7867@mail.gmail.com> Message-ID: <9457e7c80806011407r5d4040b5icf82d21c65130dab@mail.gmail.com> 2008/6/1 Fernando Perez : > On Mon, May 12, 2008 at 7:29 PM, Robert Kern wrote: >> On Mon, May 12, 2008 at 9:18 PM, Brian Granger wrote: >>> How about docutils. I am not at my dev computer, but I think I was >>> running 0.4 (not svn) of docutils. Hint is listed in docutils >>> documentation as being a supported directive, so that is odd. I try >>> this out again when I get back to my other computer. >> >> Ah, there we go. I'll have to double-check my SVN checkout. Maybe >> development moved elsewhere. > > If I recall correctly, at the Enthought sprint Ondrej and I ran into > quite a bit of trouble with docutils from SVN when using Sphinx, and > had to back off to the official 0.4 release. It's a problem, since the SVN version has bugs but also fixes some that occurred in 0.4 My solution is to use the Debian patched SVN version. Regards St?fan From fperez.net at gmail.com Sun Jun 1 17:10:58 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 14:10:58 -0700 Subject: [IPython-dev] RFC: Launchpad, Trac and bugs Message-ID: Hi folks, we'll see what we end up doing with the recent bzr history, but the fact that we're moving to bzr/launchpad for all code work is now a done deal. What I'd like to do is to solicit a bit of feedback on what to do with bug tracking, because there I'm a bit less decided. We have informally discussed this already in bits and pieces, but now I'd like to make a final decision. The options seem to be: 1. Keep using Trac for all bugs. Launchpad even explicitly supports linking all bug reports for a project to an external tracker (we'd have to register the IPython Trac somehow, but that should be easy). 2. Move to the Launchpad bug system for all new bugs. We could keep existing open tickets on Trac and gradually close them, but mark the main page indicating that no new bugs should be filed there. #2 has the advantage of integrating with the rest of Launchpad a little better, and this ties us in with other projects, the Ubuntu package database, etc. But I have to admit that so far, I like Trac much more than Launchpad for project management/bug tracking. For all of SVN's flaws, trac is actually really nice and usable, while the Launchpad site's web interface is very, very clunky. Simple things take a lot of clicking around to do, their documentation is hideous, etc. I love the hosting that launchpad provides, but the system feels very, very immature in terms of everyday usability. On the flip side, launchpad has lots of use, hence one hopes lots of development, while I worry that Trac seems to be slowing down (0.11 isn't even out yet, and it has been in that state for a looong time). So I'd like to hear opinions on the most sensible approach forward. One way or another we'll keep all filed tickets we have on both systems, so it's just a matter of deciding, and appropriately informing our users, what the *official* system will be in the future. cheers, f From barrywark at gmail.com Sun Jun 1 17:26:49 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 1 Jun 2008 14:26:49 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: Sorry to jump in late on the discussion. As the token frontend guy, I think this sounds like a good idea too. My understanding is that following the reintegration, ipython0 will instantly be the terminal-based front-end for the ipython1 features. That's great. We can continue efforts to make Twisted-based GUI frontends for ipython1. But, how are we planning to make ipython0 features (such as macros etc.) available via the engineservice interfaces? My (weak) understanding of the ipython0 codebase is that much of the ipython0 Interpreter is tied to the terminal/readline interface. Integrating that with Twisted is (as we've just seen) difficult. So, is there a plan yet for using ipython0's features in non-terminal-based use cases? Barry On Sat, May 31, 2008 at 7:55 PM, Fernando Perez wrote: > Hi all, > > after much thought and hand-wringing, Brian and I would like to bring > up an idea for a change of plans in the development process that will > hopefully make us all happier, more efficient, and will lead to more > usable code sooner, which is after all what we want. Please pitch in > with any comments you may have, ideas, dissent, etc. > > The current ipython development process is, we think, far less > efficient than it could be. Coupled with the fact that we have a > rather small core team, this is leading to sometimes near paralysis. > It is particularly unfair to Ville, who is tasked with maintaining an > actively (and very widely) used project on a codebase with no clear > future, and yet we have in ipython1 a codebase with split-personality > disorder: lovely parallel computing interfaces but a bunch of "we'll > get there soon" components that are all half-finished. > > In all this, Brian and Min try to push ip1 forward, Barry Wark works > on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but > that work is half-repeated in ip0 and ip1, etc. And in the meantime, > I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on > growing wider, with the so far unfulfilled promised of building a > bridge across it, and no realistic plan for such a bridge to really be > built any time soon. I still come back to issues with ip0 on > occasion, and I try to work on ip1, but the split is too much for my > limited time. This has left me personally disenchanted with the > project, feeling that I'm not really doing anything of quality on any > front. > > So our current rethinking is: forge ahead with what we've been calling > IPython0, and begin integrating the various key (and functional) > components of IPython1 into it one by one. The IPython0/1 split will > end, and we will use all the good pieces of IPython1 to add > functionality to ip0 without losing its current features. At each 0.X > release we'll clearly document any api breakage that might happen. > > This would bring us a number of benefits: > > * We would be forced to only commit _finished_ stuff to ipython0 > because otherwise there will be lots of pissed off IPython0 users. > > * We go from a situation where few people are trying our new code, to > one where thousands of people are trying it. > > * If we moved stuff in IPython.* -> IPython.core.*, we could then > move things in ipython1.kernel.* -> IPython.kernel.*. It one simple > step, _every_ IPython user has parallel computing at their finger > tips. With our current approach, the parallel computing stuff will > always be "over there" for your average IPython user and won't be used > until ipython1 is a full replacement for ipython0. > > * It would be sooo much simpler to manage one code base and documentation set. > > * It would be much easier to explain to people that state of ipython. > "IPython is just IPython and now it has parallel computing" The > ambitious plans for refactoring, notebooks, frontends are underway, > but IPython is still just IPython. > > * The parallel computing stuff would instantly make it into all the > Linux distros. > > * Design problems will emerge much faster as we will always have a > completely working terminal based IPython to test everything on. > Things like -pylab can't be broken, not even for a second. Whereas in > ipython1, we are a long way off from even thinking about such things. > > * We don't have to handle the questions like "I want to implement > such and such in IPython, should I use ipython0 or ipython1" > > * Our entire combined effort (limited as it may be, we have some > great people on board) can be focused on a single problem, and we can > all trust that we're working together for the same goal. > > > In retrospect, I take full blame for any mistakes that I pushed for. > While having a clean slate for thinking IPython1 ideas was probably > beneficial, and none of that work is going to be lost (we'll just fold > it piece by piece into the trunk), some of my ideas led to this > paralysis. Live and learn. > > So, any comments? We'd like to move forward *quickly* with this idea. > We'd try to make a series of much more frequent releases, one for each > key component we add in, so that little by little the baby can > actually grow. There will be an initial period where I would prepare > the ground in ip0 for the ip1 components to land in while Brian > finishes a couple of things he has in his local branch, but we're > talking a couple of weeks, not years. > > 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 Jun 1 19:07:00 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Mon, 2 Jun 2008 01:07:00 +0200 Subject: [IPython-dev] Going mad with bzr push In-Reply-To: References: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com> Message-ID: <7ced318f0806011607v437f29b1q654cda713051e160@mail.gmail.com> Yep thx! 2008/6/1 Fernando Perez : > On Sun, Jun 1, 2008 at 5:01 AM, Laurent Dufrechou > wrote: > > Hi guys, > > Since this morning, i've tryied to push from my recent linux install... > > without success. > > I've done: > > ssh-keygen -t dsa > > ssh-add id_dsa > > uploaded the public key to my launchpad account that is laurent.dufrechou > > and: > > > > bzr push > > bzr+ssh:// > laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/ > > > > and got: > > No such Launchpad account: laurent.dufrechou > > No such Launchpad account: laurent.dufrechou > > Permission denied (publickey). > > bzr: ERROR: Connection closed: please check connectivity and permissions > > (and try -Dhpss if further diagnosis is required) > > > > I see your account as: > > https://launchpad.net/~laurent-dufrechou > > There's a '-', not a '.' between your first/last names. That could be > the problem. > > Cheers, > > f > -- Laurent Dufrechou Hardware Engineering Marport 16 Blv Abb? Louis LE CAM 56100 Lorient T?l : +33(0)635028304 Fax : +33(0)297884812 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Jun 1 19:48:36 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 16:48:36 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: Hey Barry, On Sun, Jun 1, 2008 at 2:26 PM, Barry Wark wrote: > Sorry to jump in late on the discussion. As the token frontend guy, I > think this sounds like a good idea too. My understanding is that > following the reintegration, ipython0 will instantly be the > terminal-based front-end for the ipython1 features. That's great. We > can continue efforts to make Twisted-based GUI frontends for ipython1. > But, how are we planning to make ipython0 features (such as macros > etc.) available via the engineservice interfaces? My (weak) > understanding of the ipython0 codebase is that much of the ipython0 > Interpreter is tied to the terminal/readline interface. Integrating > that with Twisted is (as we've just seen) difficult. So, is there a > plan yet for using ipython0's features in non-terminal-based use > cases? Glad you pitched in. Yes, the plan will be simply to gradually morph the current ip0 code so it supports the abstractions needed for things like what you're working on. The code is fairly tied to the terminal, but that doesn't mean we can't untie it :) In fact, various people have hacked it into submission (Laurent for WX, there's a GTK example, I've seen an OpenGL console somewhere...). So what we'll do is simply try to do a series of targeted small releases where we can make these changes in a somewhat controlled manner, but admitting (and advertising) that there WILL be some inevitable API breakages. I took the attitude of keeping the IP0 100% frozen in time and expecting ip1 to eventually become ipython 1.0 with a potentially new API. From a development process perspective, we've seen that turned out to have problems [1]. So now we'll just move on top of what we have, add all the (good) code that had been written for ip1 and morph interfaces as needed. We'll make an honest effort to keep the most user-facing APIs unchanged, but I won't make any promises. If we have to break an API, we'll do it. Some WILL break, period. We'll just need to be diligent with our api_changes.txt document so it's always an honest reference of what has changed and when. Cheers, f [1] I should say that I don't think it was all a mistake: thinking on a clean slate for ip1 let Brian, Min and I have lots of wild-eyed discussions (and boy did we) on a number of topics, that would probably have been much more constrained if we felt we were working within the confines of the must-be-respected-at-all-costs iptyhon0 codebase (and supported by the very rigid workflow of SVN). But still, it is now clear that we made process mistakes. Live and learn... Thanks again for the well thought out feedback from everyone! From fperez.net at gmail.com Sun Jun 1 21:27:57 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 18:27:57 -0700 Subject: [IPython-dev] Please do NOT push to launchpad for a bit. Message-ID: Hi all, I got some help on the bzr list that seems like it's going to help. The history may end up a bit mangled but it will likely not be lost. So please hold off any pushes until a bit later so I don't have to remerge again. thanks f From ellisonbg.net at gmail.com Sun Jun 1 23:02:30 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 1 Jun 2008 21:02:30 -0600 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: <6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com> > Sorry to jump in late on the discussion. As the token frontend guy, I > think this sounds like a good idea too. My understanding is that > following the reintegration, ipython0 will instantly be the > terminal-based front-end for the ipython1 features. That's great. We > can continue efforts to make Twisted-based GUI frontends for ipython1. > But, how are we planning to make ipython0 features (such as macros > etc.) available via the engineservice interfaces? My (weak) > understanding of the ipython0 codebase is that much of the ipython0 > Interpreter is tied to the terminal/readline interface. Integrating > that with Twisted is (as we've just seen) difficult. So, is there a > plan yet for using ipython0's features in non-terminal-based use > cases? Another thing that we should mention, that is relevant to your work on the Cocoa frontend it that all of the stuff in ipython1 that you are depending on for your Cocoa frontend will be moved into ipython0 very soon (mainly ipython1.kernel and ipython1.core). As Fernando mentioned, this doesn't mean that it will magically and immediately grow all the extra ipython0 capabilities. But your Cocoa stuff should work fine with a few import changes. We will keep you posted. Brian > Barry > > > On Sat, May 31, 2008 at 7:55 PM, Fernando Perez wrote: >> Hi all, >> >> after much thought and hand-wringing, Brian and I would like to bring >> up an idea for a change of plans in the development process that will >> hopefully make us all happier, more efficient, and will lead to more >> usable code sooner, which is after all what we want. Please pitch in >> with any comments you may have, ideas, dissent, etc. >> >> The current ipython development process is, we think, far less >> efficient than it could be. Coupled with the fact that we have a >> rather small core team, this is leading to sometimes near paralysis. >> It is particularly unfair to Ville, who is tasked with maintaining an >> actively (and very widely) used project on a codebase with no clear >> future, and yet we have in ipython1 a codebase with split-personality >> disorder: lovely parallel computing interfaces but a bunch of "we'll >> get there soon" components that are all half-finished. >> >> In all this, Brian and Min try to push ip1 forward, Barry Wark works >> on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but >> that work is half-repeated in ip0 and ip1, etc. And in the meantime, >> I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on >> growing wider, with the so far unfulfilled promised of building a >> bridge across it, and no realistic plan for such a bridge to really be >> built any time soon. I still come back to issues with ip0 on >> occasion, and I try to work on ip1, but the split is too much for my >> limited time. This has left me personally disenchanted with the >> project, feeling that I'm not really doing anything of quality on any >> front. >> >> So our current rethinking is: forge ahead with what we've been calling >> IPython0, and begin integrating the various key (and functional) >> components of IPython1 into it one by one. The IPython0/1 split will >> end, and we will use all the good pieces of IPython1 to add >> functionality to ip0 without losing its current features. At each 0.X >> release we'll clearly document any api breakage that might happen. >> >> This would bring us a number of benefits: >> >> * We would be forced to only commit _finished_ stuff to ipython0 >> because otherwise there will be lots of pissed off IPython0 users. >> >> * We go from a situation where few people are trying our new code, to >> one where thousands of people are trying it. >> >> * If we moved stuff in IPython.* -> IPython.core.*, we could then >> move things in ipython1.kernel.* -> IPython.kernel.*. It one simple >> step, _every_ IPython user has parallel computing at their finger >> tips. With our current approach, the parallel computing stuff will >> always be "over there" for your average IPython user and won't be used >> until ipython1 is a full replacement for ipython0. >> >> * It would be sooo much simpler to manage one code base and documentation set. >> >> * It would be much easier to explain to people that state of ipython. >> "IPython is just IPython and now it has parallel computing" The >> ambitious plans for refactoring, notebooks, frontends are underway, >> but IPython is still just IPython. >> >> * The parallel computing stuff would instantly make it into all the >> Linux distros. >> >> * Design problems will emerge much faster as we will always have a >> completely working terminal based IPython to test everything on. >> Things like -pylab can't be broken, not even for a second. Whereas in >> ipython1, we are a long way off from even thinking about such things. >> >> * We don't have to handle the questions like "I want to implement >> such and such in IPython, should I use ipython0 or ipython1" >> >> * Our entire combined effort (limited as it may be, we have some >> great people on board) can be focused on a single problem, and we can >> all trust that we're working together for the same goal. >> >> >> In retrospect, I take full blame for any mistakes that I pushed for. >> While having a clean slate for thinking IPython1 ideas was probably >> beneficial, and none of that work is going to be lost (we'll just fold >> it piece by piece into the trunk), some of my ideas led to this >> paralysis. Live and learn. >> >> So, any comments? We'd like to move forward *quickly* with this idea. >> We'd try to make a series of much more frequent releases, one for each >> key component we add in, so that little by little the baby can >> actually grow. There will be an initial period where I would prepare >> the ground in ip0 for the ip1 components to land in while Brian >> finishes a couple of things he has in his local branch, but we're >> talking a couple of weeks, not years. >> >> 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 Sun Jun 1 23:30:27 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 20:30:27 -0700 Subject: [IPython-dev] Can others push to lp right now? Message-ID: Hi folks, I've got the branch merge ready to go, and now for some reason I can't connect. I'm getting this message: maqroll[lp-svn]> bzr push bzr+ssh://fdo.perez at bazaar.launchpad.net/~ipython/ipython/main ssh: connect to host bazaar.launchpad.net port 22: Connection refused bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) (that -Dhpss option doesn't do anything else). I tried to commit a trivial change to one of the ip1 branches and I still can't commit either right now, and I also tried from my office without success. Is it something on my end, or is LP down just now? Can another dev please try some trivial commit? thanks f From fperez.net at gmail.com Sun Jun 1 23:35:03 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 20:35:03 -0700 Subject: [IPython-dev] Can others push to lp right now? In-Reply-To: References: Message-ID: On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez wrote: > Hi folks, > > I've got the branch merge ready to go, and now for some reason I can't > connect. I'm getting this message: Never mind. I went on IRC and got this: Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance Great timing... Cheers, f From fperez.net at gmail.com Mon Jun 2 01:11:53 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 22:11:53 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com> References: <6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com> Message-ID: On Sun, Jun 1, 2008 at 8:02 PM, Brian Granger wrote: > Another thing that we should mention, that is relevant to your work on > the Cocoa frontend it that all of the stuff in ipython1 that you are > depending on for your Cocoa frontend will be moved into ipython0 very > soon (mainly ipython1.kernel and ipython1.core). As Fernando > mentioned, this doesn't mean that it will magically and immediately > grow all the extra ipython0 capabilities. But your Cocoa stuff should > work fine with a few import changes. We will keep you posted. As soon as we settle down in terms of the infrastructure changes to allow this to move forward (a few days, I hope), we'll all need to look into how exactly to best do all of this. The point is that we want *all* the work that was done on ip1 and that led to useful features (even if incomplete) to come into a single project. We'll work on making that happen. Cheers, f From fperez.net at gmail.com Mon Jun 2 01:25:00 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 22:25:00 -0700 Subject: [IPython-dev] IMPORTANT: Branches merged on launchpad, updates required. Message-ID: Hi everyone, I was able to do a merge of the old SVN history along with the work done from February until today on the stable-dev branch. Now the main branch you download from Launchpad contains the entire project history since the first SVN commit, at least for the trunk (the first 3+ years of history were on CVS and I was dumb enough to lose them in the transition to SVN. Oh well.). But please note: you need to re-download IPython from launchpad, whether you use bzr just to track the tunk or to develop. Please run again bzr branch lp:ipython to get the trunk out. This is the web page for the trunk: https://code.launchpad.net/~ipython/ipython/trunk Note that while the 990 commit swallowed the entire history of the stable-dev branch, that is only the case when viewing it via the launchpad web interface. If you get the branch and view it locally (with bzr viz, for example), you'll see the whole history with individual commits. To developers: please remember the worfklow guidelines from http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines and please update/improve that page if my instructions were in any way incorrect (I'm just now really getting the hang of a good bzr workflow). I have marked the stable-dev branch as "merged", so it doesn't appear by default anymore in most displays at launchpad, but it was NOT deleted (and it won't), it's still here for reference: https://code.launchpad.net/~ipython/ipython/stable-dev So it seems we're fully off SVN! Welcome to the great bright world of DVCS everyone :) Cheers, f From fperez.net at gmail.com Mon Jun 2 02:11:55 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 23:11:55 -0700 Subject: [IPython-dev] For transforming user input In-Reply-To: <6ce0ac130804111506k6af69895pb006e3d3879c4bb9@mail.gmail.com> References: <6ce0ac130804111506k6af69895pb006e3d3879c4bb9@mail.gmail.com> Message-ID: On Fri, Apr 11, 2008 at 3:06 PM, Brian Granger wrote: > Hi, > > I thought this was nice: > > http://pyside.blogspot.com/2008/03/ast-compilation-from-python.html > > We might think about allowing prefilter to do such transformations in ipython1. Nice :) And the context managers could also use this type of transformation... Let's keep this in mind now moving on. Cheers, f From fperez.net at gmail.com Mon Jun 2 02:19:53 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 1 Jun 2008 23:19:53 -0700 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> Message-ID: Hey Laurent, sorry I'm only now digging from under the world :) 2008/3/29 Laurent Dufrechou : > Hi guys, > > I've submitted a pre-plugin for editra as an alternative to pyshell ;) > > All is working except some quirk with ctrl+c (editra interact with it) and > enter under mac osx?. > > (I had never tried under mac osx.) > > So here are my two help request: > > -Can somebody tell if it exist a macosx emulator??? Or is there someone > willing to help me debug this remotely? (else trying to correct the code by > itself with my help or perhaps via a vnc connection?) I think people have hacked OSX into running under virtualization environments, but it's not officially supported as best I know. > Here is what cody saw: > > 2) The plugin loads and shows on Mac OSX but there must be some problem with > the key handling because hitting 'Enter' only inserts a new line in the > control and doesn't execute the command. This problem doesn't exist when > running under wxGTK. > > > > -Cody is asking if it is possible to embed Ipython in the plugin: > > It might also be interesting to try and embed IPython itself into the plugin > so nobody has to worry about dependencies. If IPython is pure python (not a > C extension) this should be as easy as copying the IPython directory into > your plugins __init__.py path and then including it the setup.py's data > files. > > > > Does Ipython as C dependency I'm not aware of??? No, IPython is pure python. So yes, embedding it should be pretty straightforward. See this: http://ipython.scipy.org/doc/manual/ipython.html#embedding-ipython Cheers, f From fperez.net at gmail.com Mon Jun 2 03:27:13 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 00:27:13 -0700 Subject: [IPython-dev] Development on Launchpad, odds and ends Message-ID: Hi everyone, I think we're now in decent shape regarding the transition to Launchpad (I updated the Trac site and the Moin wiki to reflect this). I still find the Launchpad site a PITA to navigate and find information about, but let's hope it will improve as more people use it. We have two official "series" for IPython (these were there before, what I did was change branch structure, not the series): https://launchpad.net/ipython/trunk https://launchpad.net/ipython/stable They are for now basically copies of each other, since 'stable' is also tied to the trunk bzr branch. I suppose from a a project management perspective, we'll just want to make a separate branch for stable maintenance if we ever get into backport mode. We can make series for major releases later if really needed. Right now I think the only key topic to clean things up is the proliferation of ipython1 branches: https://code.launchpad.net/ipython Brian is actively working on -fc, Barry on -cocoa, Min is out of town, and we should keep the ipython1-dev one around until the dust settles. But I'd suggest cleaning up a bit what we can if possible. It will give us a better focus for the integration process. Let's sort out what the best process for that merge will be over the next few days... So let's see how this whole thing moves forward. I'm going to work on preparing the trunk to 'receive' ipython1 code over the next few days, I'll likely do that in a publicly visible branch and periodically merge that into trunk. I'll announce it here as soon as it's up. One last word: please be careful from now on with trunk. We don't have ipython0/1 anymore, but that means the trunk is that much more important. We'll port over the documentation and tests from ip1 and I will add testing support for all the code, so that we can refactor cleanly. We'll also uniformize the code for calling conventions as we go, for documentation quality, docstrings, etc. I've subscribed by email to the trunk to keep an eye out on all commits. Please from now on, let's all try to write clean, documented and well organized code. This is the line of the project that we expect will live for a long time, so we all want it to be as clean and manageable as possible. No files without top-level docstrings, no functions without proper reST docstrings, etc. I'll be backing off improper commits if need be, but hopefully we won't have to get into that. We may eventually consider instituting a formal code review system for all patches, but I'm a bit worried that right now we just don't have the resources for that, especially when we're faced with a period of rapid code merge/churn by only a few people. But let's all try our best to work for the highest standards of code quality. We'll all benefit. IPython0/1 are dead. Long live IPython! ;) Cheers, f From laurent.dufrechou at gmail.com Mon Jun 2 04:12:53 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Mon, 2 Jun 2008 10:12:53 +0200 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> Message-ID: <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> Ho you saw this :) It is solved now! Here is the page for the plugin if anyone has some interest: http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin There still some problems with path interaction etc... that I try to solve with editra developer cody precod. The good point is that he is a macosx dev so he has solved some problem of my code under macosx! All is packed in a an egg thanks to the fact that ipython is only pure python! Chers, Laurent -----Message d'origine----- De?: Fernando Perez [mailto:fperez.net at gmail.com] Envoy??: lundi 2 juin 2008 08:20 ??: Laurent Dufrechou Cc?: ipython-dev Mailing list Objet?: Re: [IPython-dev] Help! TR: TR: Ipython plugin Hey Laurent, sorry I'm only now digging from under the world :) 2008/3/29 Laurent Dufrechou : > Hi guys, > > I've submitted a pre-plugin for editra as an alternative to pyshell ;) > > All is working except some quirk with ctrl+c (editra interact with it) and > enter under mac osx . > > (I had never tried under mac osx.) > > So here are my two help request: > > -Can somebody tell if it exist a macosx emulator??? Or is there someone > willing to help me debug this remotely? (else trying to correct the code by > itself with my help or perhaps via a vnc connection?) I think people have hacked OSX into running under virtualization environments, but it's not officially supported as best I know. > Here is what cody saw: > > 2) The plugin loads and shows on Mac OSX but there must be some problem with > the key handling because hitting 'Enter' only inserts a new line in the > control and doesn't execute the command. This problem doesn't exist when > running under wxGTK. > > > > -Cody is asking if it is possible to embed Ipython in the plugin: > > It might also be interesting to try and embed IPython itself into the plugin > so nobody has to worry about dependencies. If IPython is pure python (not a > C extension) this should be as easy as copying the IPython directory into > your plugins __init__.py path and then including it the setup.py's data > files. > > > > Does Ipython as C dependency I'm not aware of??? No, IPython is pure python. So yes, embedding it should be pretty straightforward. See this: http://ipython.scipy.org/doc/manual/ipython.html#embedding-ipython Cheers, f From fperez.net at gmail.com Mon Jun 2 04:17:14 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 01:17:14 -0700 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> Message-ID: On Mon, Jun 2, 2008 at 1:12 AM, Laurent Dufr?chou wrote: > Ho you saw this :) > It is solved now! > Here is the page for the plugin if anyone has some interest: > > http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin OK, great! Keep the needs of all this in mind as we begin the reorganization/merge, so we can get a set of APIs that make this kind of usage cleaner/easier. Cheers, f From stefan at sun.ac.za Mon Jun 2 04:46:35 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 2 Jun 2008 10:46:35 +0200 Subject: [IPython-dev] Can others push to lp right now? In-Reply-To: References: Message-ID: <9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com> 2008/6/2 Fernando Perez : > On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez wrote: >> Hi folks, >> >> I've got the branch merge ready to go, and now for some reason I can't >> connect. I'm getting this message: > > Never mind. I went on IRC and got this: > > Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance They upgraded Launchpad. The latest version implements branch commenting, which looks like a crude sub-set of a code review tool: Vote and comment on proposed branch mergers -------------------------------------------- Launchpad's merge proposals are a great way for project contributors to get their code considered for inclusion in the main line. Now, branch owners - and anyone else who's interested - can vote and comment on merge proposals. """ Aaron Bentley, who's been working on the feature, says: These changes make it easy to discuss and tweak proposed changes to a branch. You can browse the branch which contains the changes then comment and vote directly on what you've seen. Comments build into a threaded conversation about the branch. You can also vote either on the branch as whole, or use custom tags to apply your vote to a specific aspect of the work. Take a look at one of the first branch merger comments here: https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296/ This is just the start for this feature. Keep an eye on future Launchpad releases! """ Cheers St?fan From cohen at slac.stanford.edu Mon Jun 2 05:04:00 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Mon, 02 Jun 2008 11:04:00 +0200 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: Message-ID: <4843B780.3010806@slac.stanford.edu> hi there, I am even more a spectator than John, but I fully concur with the conclusions that incrementing ipy0 is the right approach. I have been downloading both versions of ipython in order to check where were the features I needed or wanted to explore, and the parallelism is certainly not available to any ipython user as it stands now. I somewhat sheepishly asked in this list a few weeks ago why there were no ipython1 executable to try out the corresponding features! You might even gain in developer's base by proceeding this way ;) So, +1 big time on reconsidering developing ipy1 within ipy0! best, Johann Fernando Perez wrote: > [ Folks: this message was sent to ipython-dev, where the bulk of the > discussion is likely to take place. But I want to make sure all > users see it, and everyone's comments are welcome] > > Hi all, > > after much thought and hand-wringing, Brian and I would like to bring > up an idea for a change of plans in the development process that will > hopefully make us all happier, more efficient, and will lead to more > usable code sooner, which is after all what we want. Please pitch in > with any comments you may have, ideas, dissent, etc. > > The current ipython development process is, we think, far less > efficient than it could be. Coupled with the fact that we have a > rather small core team, this is leading to sometimes near paralysis. > It is particularly unfair to Ville, who is tasked with maintaining an > actively (and very widely) used project on a codebase with no clear > future, and yet we have in ipython1 a codebase with split-personality > disorder: lovely parallel computing interfaces but a bunch of "we'll > get there soon" components that are all half-finished. > > In all this, Brian and Min try to push ip1 forward, Barry Wark works > on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but > that work is half-repeated in ip0 and ip1, etc. And in the meantime, > I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on > growing wider, with the so far unfulfilled promised of building a > bridge across it, and no realistic plan for such a bridge to really be > built any time soon. I still come back to issues with ip0 on > occasion, and I try to work on ip1, but the split is too much for my > limited time. This has left me personally disenchanted with the > project, feeling that I'm not really doing anything of quality on any > front. > > So our current rethinking is: forge ahead with what we've been calling > IPython0, and begin integrating the various key (and functional) > components of IPython1 into it one by one. The IPython0/1 split will > end, and we will use all the good pieces of IPython1 to add > functionality to ip0 without losing its current features. At each 0.X > release we'll clearly document any api breakage that might happen. > > This would bring us a number of benefits: > > * We would be forced to only commit _finished_ stuff to ipython0 > because otherwise there will be lots of pissed off IPython0 users. > > * We go from a situation where few people are trying our new code, to > one where thousands of people are trying it. > > * If we moved stuff in IPython.* -> IPython.core.*, we could then > move things in ipython1.kernel.* -> IPython.kernel.*. It one simple > step, _every_ IPython user has parallel computing at their finger > tips. With our current approach, the parallel computing stuff will > always be "over there" for your average IPython user and won't be used > until ipython1 is a full replacement for ipython0. > > * It would be sooo much simpler to manage one code base and documentation set. > > * It would be much easier to explain to people that state of ipython. > "IPython is just IPython and now it has parallel computing" The > ambitious plans for refactoring, notebooks, frontends are underway, > but IPython is still just IPython. > > * The parallel computing stuff would instantly make it into all the > Linux distros. > > * Design problems will emerge much faster as we will always have a > completely working terminal based IPython to test everything on. > Things like -pylab can't be broken, not even for a second. Whereas in > ipython1, we are a long way off from even thinking about such things. > > * We don't have to handle the questions like "I want to implement > such and such in IPython, should I use ipython0 or ipython1" > > * Our entire combined effort (limited as it may be, we have some > great people on board) can be focused on a single problem, and we can > all trust that we're working together for the same goal. > > > In retrospect, I take full blame for any mistakes that I pushed for. > While having a clean slate for thinking IPython1 ideas was probably > beneficial, and none of that work is going to be lost (we'll just fold > it piece by piece into the trunk), some of my ideas led to this > paralysis. Live and learn. > > So, any comments? We'd like to move forward *quickly* with this idea. > We'd try to make a series of much more frequent releases, one for each > key component we add in, so that little by little the baby can > actually grow. There will be an initial period where I would prepare > the ground in ip0 for the ip1 components to land in while Brian > finishes a couple of things he has in his local branch, but we're > talking a couple of weeks, not years. > > Cheers, > > f > _______________________________________________ > IPython-user mailing list > IPython-user at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-user > From ellisonbg.net at gmail.com Mon Jun 2 10:20:46 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 2 Jun 2008 08:20:46 -0600 Subject: [IPython-dev] Can others push to lp right now? In-Reply-To: <9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com> References: <9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com> Message-ID: <6ce0ac130806020720n6000f5aenb6035200342b80f0@mail.gmail.com> This looks like it could be really useful. Especially as it seems pretty lightweight, which is important for a small team like IPython's Brian On Mon, Jun 2, 2008 at 2:46 AM, St?fan van der Walt wrote: > 2008/6/2 Fernando Perez : >> On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez wrote: >>> Hi folks, >>> >>> I've got the branch merge ready to go, and now for some reason I can't >>> connect. I'm getting this message: >> >> Never mind. I went on IRC and got this: >> >> Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance > > They upgraded Launchpad. The latest version implements branch > commenting, which looks like a crude sub-set of a code review tool: > > Vote and comment on proposed branch mergers > -------------------------------------------- > > Launchpad's merge proposals are a great way for project contributors > to get their code considered for inclusion in the main line. > > Now, branch owners - and anyone else who's interested - can vote and > comment on merge proposals. > > """ > Aaron Bentley, who's been working on the feature, says: > > These changes make it easy to discuss and tweak proposed changes to a > branch. You can browse the branch which contains the changes then > comment and vote directly on what you've seen. > > Comments build into a threaded conversation about the branch. You can > also vote either on the branch as whole, or use custom tags to apply > your vote to a specific aspect of the work. > > Take a look at one of the first branch merger comments here: > > https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296/ > > This is just the start for this feature. Keep an eye on future > Launchpad releases! > """ > > > Cheers > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Mon Jun 2 12:23:43 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 2 Jun 2008 10:23:43 -0600 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: References: Message-ID: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> > I think we're now in decent shape regarding the transition to > Launchpad (I updated the Trac site and the Moin wiki to reflect this). > I still find the Launchpad site a PITA to navigate and find > information about, but let's hope it will improve as more people use > it. > > We have two official "series" for IPython (these were there before, > what I did was change branch structure, not the series): > > https://launchpad.net/ipython/trunk > https://launchpad.net/ipython/stable > > They are for now basically copies of each other, since 'stable' is > also tied to the trunk bzr branch. I suppose from a a project > management perspective, we'll just want to make a separate branch for > stable maintenance if we ever get into backport mode. We can make > series for major releases later if really needed. Thanks for tackling all this Fernando, it needed to be done but it sounds like it was a bit painful. > Right now I think the only key topic to clean things up is the > proliferation of ipython1 branches: > > https://code.launchpad.net/ipython > > Brian is actively working on -fc, Barry on -cocoa, Min is out of town, > and we should keep the ipython1-dev one around until the dust settles. > But I'd suggest cleaning up a bit what we can if possible. It will > give us a better focus for the integration process. Let's sort out > what the best process for that merge will be over the next few days... I will be merging ipython1-fc into ipython1-dev very soon. The ipython1-dev branch will probably remain for quite a long time as it will have all the ipython1 code that is being brought over into IPython and that will take a while, for some of the more unstable portions (like the notebook). There are also some other ipython1 branches that I will 1) either merge into ipython1-dev eventually or 2) delete. > So let's see how this whole thing moves forward. I'm going to work on > preparing the trunk to 'receive' ipython1 code over the next few days, > I'll likely do that in a publicly visible branch and periodically > merge that into trunk. I'll announce it here as soon as it's up. This sounds great. After I merge ipython1-fc into ipython1-dev, I will begin to pull ipython1-dev things into IPython (in a branch). Because both of us will be doing pretty heavy things to IPython, lets make sure we do lots of pushes back to IPython. We can coordinate this further when I start to do this. My initial merging of ipython1 -> IPython will look like this: ipython1.config -> IPython.config ipython1.kernel -> IPython.kernel ipython1.core -> IPython.kernel.core ipython1.external -> IPython.external (we will need to coordinate this as some of the externals are already in IPython. There will be lots of little things to merge in (docs, setup.py) as well. The code in these parts of ipython1 are very well tested and are fairly stable. The other parts of ipython1 (notebook, daemon, frontend) are less stable and will need to be transitions over to appropriate branches IPython trunk development. > One last word: please be careful from now on with trunk. We don't > have ipython0/1 anymore, but that means the trunk is that much more > important. We'll port over the documentation and tests from ip1 and I > will add testing support for all the code, so that we can refactor > cleanly. We'll also uniformize the code for calling conventions as > we go, for documentation quality, docstrings, etc. I have a good start on a rst based developer guidelines in ipython1 that we an bring into IPython and merge with the info on the moin page. > I've subscribed by email to the trunk to keep an eye out on all > commits. Please from now on, let's all try to write clean, documented > and well organized code. This is the line of the project that we > expect will live for a long time, so we all want it to be as clean and > manageable as possible. No files without top-level docstrings, no > functions without proper reST docstrings, etc. I'll be backing off > improper commits if need be, but hopefully we won't have to get into > that. We may eventually consider instituting a formal code review > system for all patches, but I'm a bit worried that right now we just > don't have the resources for that, especially when we're faced with a > period of rapid code merge/churn by only a few people. I agree that we probably don't have the manpower to do code review, but subscribing to trunk at least keeps people in the loop. > But let's all try our best to work for the highest standards of code > quality. We'll all benefit. > > IPython0/1 are dead. Long live IPython! ;) Yes! Brian > 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 Mon Jun 2 12:24:15 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 09:24:15 -0700 Subject: [IPython-dev] Please update the man page always. Message-ID: Hi all, I was writing a response about the new pydb control flag and went to check how it works for the user, only to find out that it's not actually documented in the man page. Please: if you add new flags to the system, it is NOT appropriate to leave them undocumented. Every single flag that is recognized by ipython at the command line should have an entry in the manpage and the manual, period. Having undocumented flags that were simply mentioned in a changelog or release notes is completely unacceptable. Cheers, f From ellisonbg.net at gmail.com Mon Jun 2 13:05:02 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 2 Jun 2008 11:05:02 -0600 Subject: [IPython-dev] RFC: Launchpad, Trac and bugs In-Reply-To: References: Message-ID: <6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com> > we'll see what we end up doing with the recent bzr history, but the > fact that we're moving to bzr/launchpad for all code work is now a > done deal. What I'd like to do is to solicit a bit of feedback on > what to do with bug tracking, because there I'm a bit less decided. > We have informally discussed this already in bits and pieces, but now > I'd like to make a final decision. > > The options seem to be: > > 1. Keep using Trac for all bugs. Launchpad even explicitly supports > linking all bug reports for a project to an external tracker (we'd > have to register the IPython Trac somehow, but that should be easy). -1 > 2. Move to the Launchpad bug system for all new bugs. We could keep > existing open tickets on Trac and gradually close them, but mark the > main page indicating that no new bugs should be filed there. +1 > #2 has the advantage of integrating with the rest of Launchpad a > little better, and this ties us in with other projects, the Ubuntu > package database, etc. But I have to admit that so far, I like Trac > much more than Launchpad for project management/bug tracking. For all > of SVN's flaws, trac is actually really nice and usable, while the > Launchpad site's web interface is very, very clunky. Simple things > take a lot of clicking around to do, their documentation is hideous, > etc. I love the hosting that launchpad provides, but the system feels > very, very immature in terms of everyday usability. I agree with your assesment of Trac vs launchpad in this respect - but launchpad development seems to be moving fast and we can always give them feedback about the interface. Given the fact that we are moving to a development model that has many branches, I think it is really important to be able to associate tickets with branches and have everything integrated. So many of the things that make Trac nice for tickets (timeline, code browser, etc) will go away with our code on launchpad. Plus, I don't like the idea of people going to our Trac site - one of the main ways I assess an open source project is to look at their Trac timeline. Our timeline will be empty, giving the misleading impression that IPython is dead. Also, keeping Trac around means that we are loosing one of the biggest benefits of launchpad - that we don't have to do any admin. Cheers, Brian > On the flip side, launchpad has lots of use, hence one hopes lots of > development, while I worry that Trac seems to be slowing down (0.11 > isn't even out yet, and it has been in that state for a looong time). > > So I'd like to hear opinions on the most sensible approach forward. > One way or another we'll keep all filed tickets we have on both > systems, so it's just a matter of deciding, and appropriately > informing our users, what the *official* system will be in the future. > > cheers, > > f > _______________________________________________ > 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 Jun 2 13:40:12 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 02 Jun 2008 19:40:12 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad Message-ID: <4844307C.80308@bostream.nu> Hi, I just registered pyreadline at launchpad. Considering all the traffic on bzr problems. I just thought I should ask here what is the best way to move svn over to launchpad? How do I handle the branches and tags? By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to go but this year I'm not going to do a presentation. /J?rgen From barrywark at gmail.com Mon Jun 2 14:05:08 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 2 Jun 2008 11:05:08 -0700 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> References: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger wrote: >> I think we're now in decent shape regarding the transition to >> Launchpad (I updated the Trac site and the Moin wiki to reflect this). >> I still find the Launchpad site a PITA to navigate and find >> information about, but let's hope it will improve as more people use >> it. >> >> We have two official "series" for IPython (these were there before, >> what I did was change branch structure, not the series): >> >> https://launchpad.net/ipython/trunk >> https://launchpad.net/ipython/stable >> >> They are for now basically copies of each other, since 'stable' is >> also tied to the trunk bzr branch. I suppose from a a project >> management perspective, we'll just want to make a separate branch for >> stable maintenance if we ever get into backport mode. We can make >> series for major releases later if really needed. > > Thanks for tackling all this Fernando, it needed to be done but it > sounds like it was a bit painful. > >> Right now I think the only key topic to clean things up is the >> proliferation of ipython1 branches: >> >> https://code.launchpad.net/ipython >> >> Brian is actively working on -fc, Barry on -cocoa, Min is out of town, >> and we should keep the ipython1-dev one around until the dust settles. >> But I'd suggest cleaning up a bit what we can if possible. It will >> give us a better focus for the integration process. Let's sort out >> what the best process for that merge will be over the next few days... > > I will be merging ipython1-fc into ipython1-dev very soon. The > ipython1-dev branch will probably remain for quite a long time as it > will have all the ipython1 code that is being brought over into > IPython and that will take a while, for some of the more unstable > portions (like the notebook). There are also some other ipython1 > branches that I will 1) either merge into ipython1-dev eventually or > 2) delete. Feel free to (or I can) merge ipython1-cocoa into ipython1-dev or whatever ipython0 becomes. The only changes in the branch are in frontends, and all tests for other packages pass so it should be safe to merge it in. > >> So let's see how this whole thing moves forward. I'm going to work on >> preparing the trunk to 'receive' ipython1 code over the next few days, >> I'll likely do that in a publicly visible branch and periodically >> merge that into trunk. I'll announce it here as soon as it's up. > > This sounds great. After I merge ipython1-fc into ipython1-dev, I > will begin to pull ipython1-dev things into IPython (in a branch). > Because both of us will be doing pretty heavy things to IPython, lets > make sure we do lots of pushes back to IPython. We can coordinate > this further when I start to do this. > > My initial merging of ipython1 -> IPython will look like this: > > ipython1.config -> IPython.config > ipython1.kernel -> IPython.kernel > ipython1.core -> IPython.kernel.core > ipython1.external -> IPython.external (we will need to coordinate this > as some of the externals are already in IPython. So there will still be a (for now) fundamental difference between ipython1.kernel.core and IPython.iplib.InteractiveShell? > > There will be lots of little things to merge in (docs, setup.py) as well. > > The code in these parts of ipython1 are very well tested and are > fairly stable. The other parts of ipython1 (notebook, daemon, > frontend) are less stable and will need to be transitions over to > appropriate branches IPython trunk development. > >> One last word: please be careful from now on with trunk. We don't >> have ipython0/1 anymore, but that means the trunk is that much more >> important. We'll port over the documentation and tests from ip1 and I >> will add testing support for all the code, so that we can refactor >> cleanly. We'll also uniformize the code for calling conventions as >> we go, for documentation quality, docstrings, etc. > > I have a good start on a rst based developer guidelines in ipython1 > that we an bring into IPython and merge with the info on the moin > page. > >> I've subscribed by email to the trunk to keep an eye out on all >> commits. Please from now on, let's all try to write clean, documented >> and well organized code. This is the line of the project that we >> expect will live for a long time, so we all want it to be as clean and >> manageable as possible. No files without top-level docstrings, no >> functions without proper reST docstrings, etc. I'll be backing off >> improper commits if need be, but hopefully we won't have to get into >> that. We may eventually consider instituting a formal code review >> system for all patches, but I'm a bit worried that right now we just >> don't have the resources for that, especially when we're faced with a >> period of rapid code merge/churn by only a few people. > > I agree that we probably don't have the manpower to do code review, > but subscribing to trunk at least keeps people in the loop. > >> But let's all try our best to work for the highest standards of code >> quality. We'll all benefit. >> >> IPython0/1 are dead. Long live IPython! ;) > > Yes! > > Brian > > >> 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 Mon Jun 2 14:35:23 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 11:35:23 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <4844307C.80308@bostream.nu> References: <4844307C.80308@bostream.nu> Message-ID: Hey, On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson wrote: > Hi, > > I just registered pyreadline at launchpad. Considering all the traffic > on bzr problems. I just thought I should ask here what is the best way > to move svn over to launchpad? How do I handle the branches and tags? Great! I just approved you for the ip team as well. I'm not an expert, but you can follow one of several routes: - use the bzr svn plugin. This will let you do imports of the svn history with a fair bit of control. - Register a branch for their vcs-imports team, typically the trunk. Here's the ipython one: https://code.launchpad.net/~vcs-imports/ipython/main Yesterday what I did was to use that one for the ipython svn->bzr final move, and basically ditch all the svn tags. Our svn repo is not going away, so we can always refer to that for historical purposes. And if there's ever a move to destroy the svn repo on scipy.org, we can also convert the whole thing to bzr. - Do an import from the raw svn repo. I can run an svn dump of the whole repo and put it up for you to download if you want to play with things there (I can probably dump just the pyreadline part so it's smaller). In my case, I just went for easy: launchpad did the original svn import of trunk for us, so it was the least amount of effort to start from there. Unless you really want to keep all branches and tags also in bzr, that will get you off the ground quickly and with full history (as I said, you can keep on referring to SVN for the foreseeable future, and if anything ever changes there I'll let you know). > By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to > go but this year I'm not going to do a presentation. I think John Hunter was considering swinging by, but I'm not sure what his final plans are, check with him. I know some of the Enthought guys will go, and perhaps Ondrej could make it, since he's not too far. I have too much other stuff going on, and no travel budget for that kind of trip right now. Cheers, f From fperez.net at gmail.com Mon Jun 2 14:37:33 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 11:37:33 -0700 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: References: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 11:05 AM, Barry Wark wrote: > Feel free to (or I can) merge ipython1-cocoa into ipython1-dev or > whatever ipython0 becomes. The only changes in the branch are in > frontends, and all tests for other packages pass so it should be safe > to merge it in. Good to hear that one is fairly focalized. > So there will still be a (for now) fundamental difference between > ipython1.kernel.core and IPython.iplib.InteractiveShell? Initially yes, but my hope is that we'll be able to push that merge quickly. That will be the job for the next few weeks: to morph the current monolithic shells into something with a tad more abstraction of i/o so they fit the network/gui/twisted models better. roll up your sleeves :) Cheers, f From fperez.net at gmail.com Mon Jun 2 14:46:17 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 11:46:17 -0700 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> References: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger wrote: > Thanks for tackling all this Fernando, it needed to be done but it > sounds like it was a bit painful. Thanks for the kind words. It wasn't too much fun, and part of it is that the lp web interface is really not very helpful in certain spots. But my ignorance of certain aspects of the tools obviously was the main problem. In the end it worked pretty well I think, and we didn't end up losing any history, which is the key point. The web view is fundamentally not very good since it doesn't know how to show true branches, but at least the full history *is* there (bzr log/viz show it all). This is much better than the alternative of just dumping in a big commit message with the old log but no real merge step-by-step history. > I will be merging ipython1-fc into ipython1-dev very soon. The > ipython1-dev branch will probably remain for quite a long time as it > will have all the ipython1 code that is being brought over into > IPython and that will take a while, for some of the more unstable > portions (like the notebook). There are also some other ipython1 > branches that I will 1) either merge into ipython1-dev eventually or > 2) delete. Sounds like a perfect plan, thanks. > This sounds great. After I merge ipython1-fc into ipython1-dev, I > will begin to pull ipython1-dev things into IPython (in a branch). > Because both of us will be doing pretty heavy things to IPython, lets > make sure we do lots of pushes back to IPython. We can coordinate > this further when I start to do this. Yup. > My initial merging of ipython1 -> IPython will look like this: > > ipython1.config -> IPython.config > ipython1.kernel -> IPython.kernel > ipython1.core -> IPython.kernel.core > ipython1.external -> IPython.external (we will need to coordinate this > as some of the externals are already in IPython. > > There will be lots of little things to merge in (docs, setup.py) as well. Yup. > The code in these parts of ipython1 are very well tested and are > fairly stable. The other parts of ipython1 (notebook, daemon, > frontend) are less stable and will need to be transitions over to > appropriate branches IPython trunk development. I'm thinking first and foremost about how to do better testing on trunk, so we can painlessly absorb all existing ip1 tests, AND improve our testing practices for the old code as well. That will be my immediate focus for the time I can devote to ipython in the coming days. > I have a good start on a rst based developer guidelines in ipython1 > that we an bring into IPython and merge with the info on the moin > page. Great. Soon we should also think about a way to reduce the wiki/docs duplication. The new work on the numpy docs wiki site could be a start. But let's go with what we have for now: that might be a topic for a sprint at scipy, to generalize that machinery for other projects to use. >> IPython0/1 are dead. Long live IPython! ;) > > Yes! I should close this by giving a huge thanks to everyone not only for recent feedback, but especially for keeping the project alive and moving despite the difficult split created by my short-sightedness. In particular, if it weren't for Ville's steady pushing of the trunk, I'm afraid we wouldn't have a live project to merge again back into, and if it weren't for Brian and Min's patience on endless discussions with me for ip1, we would have nothing to bring :) So really, thanks to all for helping this stay alive and interesting, now we'll move forward. Regards, f From stefan at sun.ac.za Mon Jun 2 14:51:44 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 2 Jun 2008 20:51:44 +0200 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> References: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> Message-ID: <9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com> Hey Brian 2008/6/2 Brian Granger : > My initial merging of ipython1 -> IPython will look like this: > > ipython1.config -> IPython.config > ipython1.kernel -> IPython.kernel > ipython1.core -> IPython.kernel.core > ipython1.external -> IPython.external (we will need to coordinate this > as some of the externals are already in IPython. Has the sconfig branch been merged into ipython1? It is fairly close to complete (you'll find the details in the email I sent last time, but as far as I recall, the only missing functionality is a complete roundtrip based on configobj, which should take a further 20 minutes to implement). Regards St?fan From fperez.net at gmail.com Mon Jun 2 14:59:59 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 11:59:59 -0700 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: <9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com> References: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com> <9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 11:51 AM, St?fan van der Walt wrote: > Hey Brian > > 2008/6/2 Brian Granger : >> My initial merging of ipython1 -> IPython will look like this: >> >> ipython1.config -> IPython.config >> ipython1.kernel -> IPython.kernel >> ipython1.core -> IPython.kernel.core >> ipython1.external -> IPython.external (we will need to coordinate this >> as some of the externals are already in IPython. > > Has the sconfig branch been merged into ipython1? It is fairly close > to complete (you'll find the details in the email I sent last time, > but as far as I recall, the only missing functionality is a complete > roundtrip based on configobj, which should take a further 20 minutes > to implement). No, I don't think it's been merged yet, but it obviously will. If you have a chance to finish that little piece, great! Cheers, f From fperez.net at gmail.com Mon Jun 2 15:45:33 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 12:45:33 -0700 Subject: [IPython-dev] RFC: Launchpad, Trac and bugs In-Reply-To: <6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com> References: <6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 10:05 AM, Brian Granger wrote: >> The options seem to be: >> >> 1. Keep using Trac for all bugs. Launchpad even explicitly supports >> linking all bug reports for a project to an external tracker (we'd >> have to register the IPython Trac somehow, but that should be easy). > > -1 > >> 2. Move to the Launchpad bug system for all new bugs. We could keep >> existing open tickets on Trac and gradually close them, but mark the >> main page indicating that no new bugs should be filed there. > > +1 > >> #2 has the advantage of integrating with the rest of Launchpad a >> little better, and this ties us in with other projects, the Ubuntu >> package database, etc. But I have to admit that so far, I like Trac >> much more than Launchpad for project management/bug tracking. For all >> of SVN's flaws, trac is actually really nice and usable, while the >> Launchpad site's web interface is very, very clunky. Simple things >> take a lot of clicking around to do, their documentation is hideous, >> etc. I love the hosting that launchpad provides, but the system feels >> very, very immature in terms of everyday usability. > > I agree with your assesment of Trac vs launchpad in this respect - but > launchpad development seems to be moving fast and we can always give > them feedback about the interface. Given the fact that we are moving > to a development model that has many branches, I think it is really > important to be able to associate tickets with branches and have > everything integrated. So many of the things that make Trac nice for > tickets (timeline, code browser, etc) will go away with our code on > launchpad. Plus, I don't like the idea of people going to our Trac > site - one of the main ways I assess an open source project is to look > at their Trac timeline. Our timeline will be empty, giving the > misleading impression that IPython is dead. Also, keeping Trac around > means that we are loosing one of the biggest benefits of launchpad - > that we don't have to do any admin. Unless anyone else objects, we'll do #2 then. That was also the opinion of Gael and Stefan while at the Paris sprint, and hanging our hat on a possibly-dying project doesn't sound like a very good idea. As you correctly point out, we can always give lp feedback on the more glaring problems, and I'm sure with all the use it's getting, it will improve over time. I'll update the Trac wiki a bit later to reflect this then, yell if you disagree. Cheers, f From laurent.dufrechou at gmail.com Mon Jun 2 16:39:32 2008 From: laurent.dufrechou at gmail.com (=?US-ASCII?Q?Laurent_Dufrechou?=) Date: Mon, 2 Jun 2008 22:39:32 +0200 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> Message-ID: <48445a88.02a1660a.6b17.776d@mx.google.com> Hi Fernando, [Warning very long mail that do a sum-up(?) of all problem I encoutered to make an ipython0 gui interaction] About specific API for GUI devs, Here is my feeling about what was missing in ipython0 and that could be refactored/improved while switching to ipython1: - stdin/stdout/stderr hook (the MOST important): All ipython0 is tightly glued with pyreadline that is not tailored for 'graphical' gui (from my point of view ^_^): We should think about an API where we could send data we get from user: Something like: (ip_output,ip_error) = IP.IO.process_input(user_input) I mean we can stay with pyreadline for console based terminal but I think we need something simpler for "graphical" gui. Pyreadline is thought to handle all user key and process input/output for the console. In a GUI the designer is using a specific widget he has choosed and handle its user input the way he want. So pyreadline is something too much complex for what I needed.(I only use the ASCII coloration output of pyreadline) (Another time, this is my point of view, some other devs will say that this is the job of a readline object: I'm not ok with that because I want to be free and I need something flexible. "Keep it simple" philosophy) By the way it could be interesting to have something like what pyreadline is doing but improved: IP.IO.setOutFilter("html") or IP.IO.setOutFilter("ANSI") that output the result as a 'html' or 'xml' or 'ascii_colored' or user_defined filter hook. My main problems were: #we replace the ipython default pager by our pager self._IP.set_hook('show_in_pager',self._pager) #we replace the ipython default shell command caller by our shell handler self._IP.set_hook('shell_hook',self._shell) #we replace the ipython default input command caller by our method IPython.iplib.raw_input_original = self._raw_input #we replace the ipython default exit command by our method self._IP.exit = ask_exit_handler #we replace the help command self._IP.user_ns['help'] = _Helper(self._pager_help) Most of these lines where mostly ugly hack that could have been avoid if I had the IP.process_input and IP.get_output command. IP.IO.process_input(user_input) <-- this is really important! See 'def _execute(self):' in ipshell_nonblocking to see how I handle that. We can't ask people that want to integrate a new GUI toolkit to write this sort of code. They will run away ;). Hopefully I've totally copied it from GTK port :), that's why I didn't ran away ^_^ - history management API simpler(my current problem): Currently ipython history is completely handled by pyreadline. I feel ipython0 is missing an history API simpler. Something like; IP.History.getHistoryLength() IP.History.loadHistoryFromFile(file) IP.History.getHistory[number] In fact this is something I can get from pyreadline, but it is really complex. I need to access the readline object and then call some function of function of readline API. Can be simpler for ipython0 external user. So perhaps this is just some wrapper around pyreadline to hide the complexity to external and non specialized user. It was so complex for me (based on my poor knowledge of ipython0 and pyreadline) that it was simpler to make my history API. (And this was also the case with gtk port from which I based my work). - Completer API. Sometihng like: IP.Completer.getCompletion(user_input_to_complete) -> return a list of completion : list([completion1,'function'],[completion2,'int'],[completion3,'private'] etc... Check complete function of ipshell_nonblocking to see how I(hum perhaps previous guy in fact :) ) did a simpler thing. That all for the moment ;) Laurent From jorgen.stenarson at bostream.nu Mon Jun 2 17:23:56 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 02 Jun 2008 23:23:56 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> Message-ID: <484464EC.8030502@bostream.nu> Fernando Perez skrev: > Hey, > > On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson > wrote: >> Hi, >> >> I just registered pyreadline at launchpad. Considering all the traffic >> on bzr problems. I just thought I should ask here what is the best way >> to move svn over to launchpad? How do I handle the branches and tags? > > Great! I just approved you for the ip team as well. > > I'm not an expert, but you can follow one of several routes: > I'll look into this tomorrow. Thanks for your input. /J?rgen From vivainio at gmail.com Mon Jun 2 17:39:54 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 00:39:54 +0300 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: <48445a88.02a1660a.6b17.776d@mx.google.com> References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> <48445a88.02a1660a.6b17.776d@mx.google.com> Message-ID: <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou wrote: > I mean we can stay with pyreadline for console based terminal but I think we > need something simpler for "graphical" gui. I agree. However, this can be done as it is now in iplib.py "interact_with_readline" method (which, admittedly, is not excercised in current code but mostly server as proof that ipython can be easily decoupled from raw_input. > (Another time, this is my point of view, some other devs will say that this > is the job of a readline object: I'm not ok with that because I want to be > free and I need something flexible. "Keep it simple" philosophy) I agree with you here. All the direct references to readline should factored out of the logic-running classes. > - Completer API. > Sometihng like: > IP.Completer.getCompletion(user_input_to_complete) -> return a list of > completion : > list([completion1,'function'],[completion2,'int'],[completion3,'private'] > etc... This should be easy. test_completer.py introduces how to "hack" your way aroud the lack of API (so far). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Mon Jun 2 18:26:19 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 01:26:19 +0300 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin Message-ID: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou wrote: > About specific API for GUI devs, > Here is my feeling about what was missing in ipython0 and that could be > refactored/improved while switching to ipython1: Since I have some professional interest to boost my qt skills, I thought that providing qscintilla (and pyqt4) version of ipython might be a good way to really find out what needs to be generalized in IPython. Of course you have already done a good job with wxipython, but it would really help overall ipython architecture if we made the code in GUI's as natural as possible (i.e. without needing the hacks you had to do for wxipython). At least eric4 could then embed ipython instead of vanilla python. As assumedly Fernando now re-assumes the coordinator role for the stable branch, plus the influx of other dev's to ipython0 code base, it should be much easier for me personally to allocate the "ipython time" into playing with a largish feature like this. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From laurent.dufrechou at gmail.com Mon Jun 2 18:47:56 2008 From: laurent.dufrechou at gmail.com (Laurent Dufrechou) Date: Tue, 3 Jun 2008 00:47:56 +0200 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: <7ced318f0806021547m1abfe11cx8c06c8b5d9dd1b20@mail.gmail.com> 2008/6/3 Ville M. Vainio : > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou > wrote: > > > About specific API for GUI devs, > > Here is my feeling about what was missing in ipython0 and that could be > > refactored/improved while switching to ipython1: > > Since I have some professional interest to boost my qt skills, I > thought that providing qscintilla (and pyqt4) version of ipython might > be a good way to really find out what needs to be generalized in > IPython. Of course you have already done a good job with wxipython, > but it would really help overall ipython architecture if we made the > code in GUI's as natural as possible (i.e. without needing the hacks > you had to do for wxipython). At least eric4 could then embed ipython > instead of vanilla python. > > As assumedly Fernando now re-assumes the coordinator role for the > stable branch, plus the influx of other dev's to ipython0 code base, > it should be much easier for me personally to allocate the "ipython > time" into playing with a largish feature like this. > > -- > Ville M. Vainio - vivainio.googlepages.com > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' > Hey ville, that seems quite interesting. If ultimately we could merge a lot of thing I will be more than happy :) So if you find ways to avoid hack drop me emails. QT and WX must not be so different ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Jun 2 19:56:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 16:56:28 -0700 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio wrote: > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou > wrote: > >> About specific API for GUI devs, >> Here is my feeling about what was missing in ipython0 and that could be >> refactored/improved while switching to ipython1: > > Since I have some professional interest to boost my qt skills, I > thought that providing qscintilla (and pyqt4) version of ipython might > be a good way to really find out what needs to be generalized in > IPython. Of course you have already done a good job with wxipython, > but it would really help overall ipython architecture if we made the > code in GUI's as natural as possible (i.e. without needing the hacks > you had to do for wxipython). At least eric4 could then embed ipython > instead of vanilla python. > > As assumedly Fernando now re-assumes the coordinator role for the > stable branch, plus the influx of other dev's to ipython0 code base, > it should be much easier for me personally to allocate the "ipython > time" into playing with a largish feature like this. That is an excellent plan. Let's make sure that as we work on this, we keep in mind: - the work that Barry has been doing on Cocoa - correct integration with twisted's event loop. There's a lot of interest in the -twisted option working right, and twisted has GUI integration mechanisms (as discussed here earlier); we just want the whole thing to play nice with the networking layer used for distributed use. Note that the distributed use is not just for parallel computing: you may also want a Qt/Wx gui working on a remote ipython instance... - the needs for the same abstractions to work over the network from frontends like a web browser that uses JavaScript. Cheers, f From fperez.net at gmail.com Mon Jun 2 20:12:20 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 17:12:20 -0700 Subject: [IPython-dev] google shell Message-ID: Something neat I just saw: http://goosh.org/ IPython would fit right in there... Cheers, f From fperez.net at gmail.com Mon Jun 2 20:31:42 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 17:31:42 -0700 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio wrote: > Since I have some professional interest to boost my qt skills, I > thought that providing qscintilla (and pyqt4) version of ipython might > be a good way to really find out what needs to be generalized in > IPython. Of course you have already done a good job with wxipython, > but it would really help overall ipython architecture if we made the > code in GUI's as natural as possible (i.e. without needing the hacks > you had to do for wxipython). At least eric4 could then embed ipython > instead of vanilla python. I forgot to add that I'm super happy to see you push a Qt gui forward. Having wx, qt and cocoa shells out of the box would be really killer. We'll work on ensuring they all operate on the same api that a terminal-based one would. Cheers, f From barrywark at gmail.com Mon Jun 2 23:10:03 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 2 Jun 2008 20:10:03 -0700 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: On Mon, Jun 2, 2008 at 4:56 PM, Fernando Perez wrote: > On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio wrote: >> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou >> wrote: >> >>> About specific API for GUI devs, >>> Here is my feeling about what was missing in ipython0 and that could be >>> refactored/improved while switching to ipython1: >> >> Since I have some professional interest to boost my qt skills, I >> thought that providing qscintilla (and pyqt4) version of ipython might >> be a good way to really find out what needs to be generalized in >> IPython. Of course you have already done a good job with wxipython, >> but it would really help overall ipython architecture if we made the >> code in GUI's as natural as possible (i.e. without needing the hacks >> you had to do for wxipython). At least eric4 could then embed ipython >> instead of vanilla python. >> >> As assumedly Fernando now re-assumes the coordinator role for the >> stable branch, plus the influx of other dev's to ipython0 code base, >> it should be much easier for me personally to allocate the "ipython >> time" into playing with a largish feature like this. > > That is an excellent plan. Let's make sure that as we work on this, > we keep in mind: > > - the work that Barry has been doing on Cocoa I would encourage you guys to take a look at the ipython1.frontends.frontendbase class. My intention is to develop this into a base class for all GUI frontends. The underlying assumption is that GUI frontends will interact with the ipython interpreter via the ipython1.kernel.engineservice (Twisted) API. The benefits, as I see them for this approach is to avoid rewriting the Wheel of GUI Integration (the Twisted guys have already done this), and to make it _very_ easy to provide remote/parallel capabilities from within the GUI frontend. Of course, code speaks louder than words and I invite you to hack on the frontends package (currently in ipython1-cocoa branch, but I assume soon to be merged inwards towards ipython1-dev or trunk). The frontendbase is currently a work in progress, but I've attempted to make it clear where subclasses (e.g. GUI frontend implementations should subclass particular methods to gain the desired functionality). The intention is that frontends are an aggregate of a frontendbase subclass and a GUI widget or a GUI widget (such as a text widget) that subclasses both the GUI toolkit's widget and the frontendbase. barry > > - correct integration with twisted's event loop. There's a lot of > interest in the -twisted option working right, and twisted has GUI > integration mechanisms (as discussed here earlier); we just want the > whole thing to play nice with the networking layer used for > distributed use. Note that the distributed use is not just for > parallel computing: you may also want a Qt/Wx gui working on a remote > ipython instance... If we stick with developing GUI interfaces through the engineservice interface, we get all this for free. In addition, I think such an approach will help drive the ipython1->ipython0 integration because it will highlight the most pressing areas where we the ipython1's core (exposed via engineservice) is not up-to-par wrt the ipython0 InteractiveShell. > > - the needs for the same abstractions to work over the network from > frontends like a web browser that uses JavaScript. > > 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 Tue Jun 3 02:00:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 2 Jun 2008 23:00:28 -0700 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <4843B780.3010806@slac.stanford.edu> References: <4843B780.3010806@slac.stanford.edu> Message-ID: On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi wrote: > hi there, > I am even more a spectator than John, but I fully concur with the > conclusions that incrementing ipy0 is the right approach. I have been > downloading both versions of ipython in order to check where were the > features I needed or wanted to explore, and the parallelism is certainly > not available to any ipython user as it stands now. I somewhat > sheepishly asked in this list a few weeks ago why there were no ipython1 > executable to try out the corresponding features! > You might even gain in developer's base by proceeding this way ;) That's precisely the plan :) As long as we're careful not to piss people off by breaking too many things at the same time, what users will experience will be the gradual growth of the parallel features inside a tool they already use for everyday work. This is something I was blind enough to overlook for a long time. Yes, I'm kicking myself, you don't need to :) > So, +1 big time on reconsidering developing ipy1 within ipy0! Thanks for the feedback, much appreciated. Cheers, f From fperez.net at gmail.com Tue Jun 3 03:43:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 00:43:28 -0700 Subject: [IPython-dev] message from a launchpad developer In-Reply-To: <481B3596.5020709@astraw.com> References: <481972E7.7070006@astraw.com> <46cb515a0805020156j7a492475i5bd63c685aa7717@mail.gmail.com> <481B3596.5020709@astraw.com> Message-ID: On Fri, May 2, 2008 at 8:39 AM, Andrew Straw wrote: > Ville M. Vainio wrote: >> On Thu, May 1, 2008 at 10:36 AM, Andrew Straw wrote: >> >> >>> I thought you guys might be interested in this blog post i came across >>> -- a launchpad dev is praising the new doctest_mode and suggesting a PPA >>> ("Personal Package Archive" -- .deb repository hosted at launchpad) with >>> the latest IPython: http://elliotmurphy.com/2008/04/23/ipython-and-doctests/ >>> >> >> Anyone know what benefits PPA brings over just uploading the releases >> to launchpad download folder? It would seem easier to just download >> and install the release than it is to edit your apt sources list... >> > The main benefits I can think of: > > * PPAs integrate with the Ubuntu Update Manager -- a new release will > be just like any other update from the user's perspective. According to > their preferences, it will be a single click to install or will be > automatically installed. > > * The .debs will be built by their buildbots for all the architectures > they support, which also ensures that your debian package at least > builds from source. > > Of course, .debs should only be installed for the specific version of > debian (derivative) they were compiled for. Thus, it's not a replacement > for a source tarball (although a debian source package, by definition, > comes with an unmodified source tarball), but something in addition to that. With the new development plans, I think we should do this a bit later in the summer. It will provide users on the various ubuntu derivatives a clean way of getting the new parallel goodies with little pain. Thanks for the idea! Cheers, f From ondrej at certik.cz Tue Jun 3 04:49:20 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Tue, 3 Jun 2008 10:49:20 +0200 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: References: <4843B780.3010806@slac.stanford.edu> Message-ID: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com> On Tue, Jun 3, 2008 at 8:00 AM, Fernando Perez wrote: > On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi > wrote: >> hi there, >> I am even more a spectator than John, but I fully concur with the >> conclusions that incrementing ipy0 is the right approach. I have been >> downloading both versions of ipython in order to check where were the >> features I needed or wanted to explore, and the parallelism is certainly >> not available to any ipython user as it stands now. I somewhat >> sheepishly asked in this list a few weeks ago why there were no ipython1 >> executable to try out the corresponding features! >> You might even gain in developer's base by proceeding this way ;) > > That's precisely the plan :) As long as we're careful not to piss > people off by breaking too many things at the same time, what users > will experience will be the gradual growth of the parallel features > inside a tool they already use for everyday work. This is something I > was blind enough to overlook for a long time. Yes, I'm kicking > myself, you don't need to :) > >> So, +1 big time on reconsidering developing ipy1 within ipy0! > > Thanks for the feedback, much appreciated. > Hi Fernando and other ipython developers, I never fully understood why you started ipython1 as a separate project instead of improving ipython that everyone knows and is in all distributions. So all I can say is a big +1. Another mistake would have been to release something usable in a year. That's too late. However releasing things that are ready in small improvements now is the way to go. Ondrej From stefan at sun.ac.za Tue Jun 3 06:38:50 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 3 Jun 2008 12:38:50 +0200 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com> References: <4843B780.3010806@slac.stanford.edu> <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com> Message-ID: <9457e7c80806030338t79e61747vef067af9d6d41d20@mail.gmail.com> 2008/6/3 Ondrej Certik : > Hi Fernando and other ipython developers, > > I never fully understood why you started ipython1 as a separate > project instead of improving ipython that everyone knows > and is in all distributions. So all I can say is a big +1. I thought it made sense at the time. It wasn't immediately apparent (to me, at least) what the overlap between the new and the old project would be (or whether there would be any). Also, without a proof-of-concept, adding a twistd dependency onto a very lightweight IPython would have been unpopular (I suppose this could have been an "optional dependency"). I am glad that the two development streams have merged. A project without innovation simply waits to die. That said, I think it is easy to overlook the advantages gained by the initial split (that is, giving Brian, Fernando and Min a blank slate to produce innovative ideas, as well as providing a test-bed for implementations). But, hey, all's well that ends well! Happy hacking, St?fan From vds at aisystems.be Tue Jun 3 09:40:00 2008 From: vds at aisystems.be (Vivian De Smedt) Date: Tue, 03 Jun 2008 15:40:00 +0200 Subject: [IPython-dev] Editor Syncrhronization Message-ID: <484549B0.5050301@aisystems.be> Dear All, Few month ago I wrote a small patch for IPython that synchronize IPython and an external text editor or your choice. When this patch is active IPython call a hook whenever it put highlight on a line of code. Typically when: - Some script throw an uncatched exception - We go up and down in the stack in debug mode I find this useful because it let me - Use my editor of choice to view and edit large chunk of code and - Use IPython to debug and analyze the variables. With the new 0.8.3 release I just patch reapply my patch to 0.8.3 to have the functionality and it works well for me. If someone is interested by this functionality I'll be glad to submit a patch. The modifications are: - the definition of a new hook (in hook.py) - some call to these hook in Debugger.py and in ultraTB.py - and two exemple of hook in Extentions\ip_synchronize_with_ue.py and in Extensions\ip_synchronize_with_nppp.py to synchronize with UltraEdit and with Notepad++ respectively. Note: the Notepad++ hook have a flaw it don't synchronize IPython and the text file on the right line if the text file is already opened in the editor (which mean in practice that it synchronize at the correct line only the first time). This is a Notepad++ flaw that I'll try to solve with the Notepad++ peoples. To test it simply import ip_synchronize_with_xxx in you ipy_user_conf IPyhon configuration. I'll be glad to have some feedback about this proposition of extension. If needed I could provide some other implementation of the hook for other text processor. Please tell me what you think about this extension, if you could consider it for inclusion in IPython and if so what should I do for that. Vivian. -------------- next part -------------- A non-text attachment was scrubbed... Name: IPython.zip Type: application/octet-stream Size: 23117 bytes Desc: not available URL: From vivian at vdesmedt.com Tue Jun 3 10:22:41 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue, 03 Jun 2008 16:22:41 +0200 Subject: [IPython-dev] Synchronization with gvim Message-ID: <484553B1.9020405@vdesmedt.com> Dear All, Here is a version of the hook that should work for gvim (it suppose that gvim is in the path). Vivian. -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_synchronize_with_gvim.zip Type: application/octet-stream Size: 501 bytes Desc: not available URL: From vivian at vdesmedt.com Tue Jun 3 10:24:29 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue, 03 Jun 2008 16:24:29 +0200 Subject: [IPython-dev] Editor Syncrhronization Message-ID: <4845541D.9040909@vdesmedt.com> Dear All, Few month ago I wrote a small patch for IPython that synchronize IPython and an external text editor or your choice. When this patch is active IPython call a hook whenever it put highlight on a line of code. Typically when: - Some script throw an uncatched exception - We go up and down in the stack in debug mode I find this useful because it let me - Use my editor of choice to view and edit large chunk of code and - Use IPython to debug and analyze the variables. With the new 0.8.3 release I just patch reapply my patch to 0.8.3 to have the functionality and it works well for me. If someone is interested by this functionality I'll be glad to submit a patch. The modifications are: - the definition of a new hook (in hook.py) - some call to these hook in Debugger.py and in ultraTB.py - and two exemple of hook in Extentions\ip_synchronize_with_ue.py and in Extensions\ip_synchronize_with_nppp.py to synchronize with UltraEdit and with Notepad++ respectively. Note: the Notepad++ hook have a flaw it don't synchronize IPython and the text file on the right line if the text file is already opened in the editor (which mean in practice that it synchronize at the correct line only the first time). This is a Notepad++ flaw that I'll try to solve with the Notepad++ peoples. To test it simply import ip_synchronize_with_xxx in you ipy_user_conf IPyhon configuration. I'll be glad to have some feedback about this proposition of extension. If needed I could provide some other implementation of the hook for other text processor. Please tell me what you think about this extension, if you could consider it for inclusion in IPython and if so what should I do for that. Vivian. -------------- next part -------------- A non-text attachment was scrubbed... Name: IPython.zip Type: application/octet-stream Size: 23598 bytes Desc: not available URL: From vivainio at gmail.com Tue Jun 3 10:37:24 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 17:37:24 +0300 Subject: [IPython-dev] Editor Syncrhronization In-Reply-To: <4845541D.9040909@vdesmedt.com> References: <4845541D.9040909@vdesmedt.com> Message-ID: <46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com> On Tue, Jun 3, 2008 at 5:24 PM, Vivian De Smedt wrote: > Few month ago I wrote a small patch for IPython that synchronize IPython and > an external text editor or your choice. Can you please send a diff for review instead? It seems that your implementation is not "risky" (in the sense of breaking anything), and most of it is in extension there should be no blocks for getting it in. Can you create a launchpad account and submit this in a branch? -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From cohen at slac.stanford.edu Tue Jun 3 10:44:38 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 03 Jun 2008 16:44:38 +0200 Subject: [IPython-dev] NameError: global name 'error' is not defined Message-ID: <484558D6.8090700@slac.stanford.edu> [cohen at jarrett GRBOD]$ ipython Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: %store -d --------------------------------------------------------------------------- NameError Traceback (most recent call last) /home/cohen/data1/WORK/GRBOD/ in () /usr/lib/python2.5/site-packages/IPython/iplib.pyc in ipmagic(self, arg_s) 958 else: 959 magic_args = self.var_expand(magic_args,1) --> 960 return fn(magic_args) 961 962 def ipalias(self,arg_s): /usr/lib/python2.5/site-packages/IPython/Extensions/pspersistence.pyc in magic_store(self, parameter_s) 97 todel = args[0] 98 except IndexError: ---> 99 error('You must provide the variable to forget') 100 else: 101 try: NameError: global name 'error' is not defined I know I forgot the argument (I should have seen the message 'You must provide the variable to forget' right ;) ? ), but still..... best, Johann From ellisonbg.net at gmail.com Tue Jun 3 12:07:50 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 3 Jun 2008 10:07:50 -0600 Subject: [IPython-dev] IPython development: course adjustment required In-Reply-To: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com> References: <4843B780.3010806@slac.stanford.edu> <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com> Message-ID: <6ce0ac130806030907u1ef5b40am77c1d031c4dc86fd@mail.gmail.com> Thanks everyone for the feedback. It definitely seems like this is a very good choice for us and that it will energize the development process. I will begin to merge ipython1 things into IPython soon (hopefully this week). Cheers, Brian On Tue, Jun 3, 2008 at 2:49 AM, Ondrej Certik wrote: > On Tue, Jun 3, 2008 at 8:00 AM, Fernando Perez wrote: >> On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi >> wrote: >>> hi there, >>> I am even more a spectator than John, but I fully concur with the >>> conclusions that incrementing ipy0 is the right approach. I have been >>> downloading both versions of ipython in order to check where were the >>> features I needed or wanted to explore, and the parallelism is certainly >>> not available to any ipython user as it stands now. I somewhat >>> sheepishly asked in this list a few weeks ago why there were no ipython1 >>> executable to try out the corresponding features! >>> You might even gain in developer's base by proceeding this way ;) >> >> That's precisely the plan :) As long as we're careful not to piss >> people off by breaking too many things at the same time, what users >> will experience will be the gradual growth of the parallel features >> inside a tool they already use for everyday work. This is something I >> was blind enough to overlook for a long time. Yes, I'm kicking >> myself, you don't need to :) >> >>> So, +1 big time on reconsidering developing ipy1 within ipy0! >> >> Thanks for the feedback, much appreciated. >> > > Hi Fernando and other ipython developers, > > I never fully understood why you started ipython1 as a separate > project instead of improving ipython that everyone knows > and is in all distributions. So all I can say is a big +1. > > Another mistake would have been to release something usable in a year. > That's too late. However releasing things that are ready in small > improvements now is the way to go. > > Ondrej > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From Alexander_Brown at uml.edu Tue Jun 3 12:24:09 2008 From: Alexander_Brown at uml.edu (Alex Brown) Date: Tue, 03 Jun 2008 12:24:09 -0400 Subject: [IPython-dev] Win32 IPython1? Message-ID: <48457029.8020401@uml.edu> Hello - this may be the wrong list for this question; if so my apologies. My next Python excursion involves a simple "parallel programming" problem - I am trying to put together Python controller and server modules for very coarse-grain parallel processing of GIS and remote sensing data using existing Win32 GIS and remote sensing software tools running in WinXP on a classroom cluster. The Win32 COM Python tools are fine for local control of these interactive applications and I'm trying to find an existing "parallel" network controller toolkit that will work in the Win32 world, either native or through Cygwin. (The controller environment can be Linux of course.) I've tried some of the "grid" style tools for cluster management that claim to run in Cygwin, and found them to be clumsy (batch-oriented) and unreliable. I am now looking into IPython1, and I'd like to know if there is any experience with it in a Win32 environment. Any suggestions would be welcome. Thanks again - Alex Brown http://gis.uml.edu/abrown2 From vivian at vdesmedt.com Tue Jun 3 12:50:16 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue, 03 Jun 2008 18:50:16 +0200 Subject: [IPython-dev] Editor Syncrhronization In-Reply-To: <46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com> References: <4845541D.9040909@vdesmedt.com> <46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com> Message-ID: <48457648.8050703@vdesmedt.com> Thank you for you quick answer. It seems that I can't access launchpad from here probably for security reasons. I'll try to do what you ask from home this week end. Regards, Vivian. PS: I just finalize a synchronization hook for scite. From vivainio at gmail.com Tue Jun 3 14:01:08 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 21:01:08 +0300 Subject: [IPython-dev] Quick launchpad guide for would-be contributors Message-ID: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Here is a short guide to launchpad I wrote for Leo editor. It's applicable to ipython as well, when you substitute "ipython" for "leo-editor" -------- Many users will want to track the development version of Leo, in order to stay on top of the latest features and bugfixes. Running the development version is quite safe and easy, and it's also a requirement if you want to contribute to Leo. 1. First, you need to get Bazaar (bzr) from http://bazaar-vcs.org. For windows users we recommend the standalone installer - the python installer may have problems pushing to Launchpad. Plain bzr installer only contains the command line version, so you might want to augment that with a friendly GUI - qbzr is recommended as it's the easiest one to install. It provides command like ``bzr qlog``, ``bzr qannotate`` etc. 2. Get Leo from launchpad by doing:: bzr branch lp:leo-editor And that's it! You can run leo/src/leo.py directly. When you want to refresh the code with latest modifications from Launchpad, run ``bzr pull``. If you make modifications to Leo (with the interest in sharing them with the Leo community), you can check them in to your local branch by doing ``bzr checkin``. Now, to actually request your changes to be merged to Leo trunk, you need a Launchpad account with RSA keys in place. There is showmedo video about how to accomplish this on Windows using puttygen and pageant at ``http://showmedo.com/videos/video?name=1510070&fromSeriesID=151``. After your Launchpad account is set up, go to ``https://launchpad.net/leo-editor``, choose Code tab -> Register Branch, select Branch type "Hosted" and fill in descriptive details about the branch. After that, go to the branch home page from Code tab again, and copy-paste the push command line to terminal. For example, for branch:: https://code.launchpad.net/~leo-editor-team/leo-editor/mod_rclick The push command is:: bzr push bzr+ssh://my_name at bazaar.launchpad.net/~leo-editor-team/leo-editor/mod_rclick You may wish to add --remember command line option to bzr push, to direct all future pushes to that location. Then, you only need to execute ``bzr push``. After your branch is pushed, you can email the Leo mailing list and request it to be reviewed and merged to trunk. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Tue Jun 3 14:31:58 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 11:31:58 -0700 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio wrote: > Here is a short guide to launchpad I wrote for Leo editor. It's > applicable to ipython as well, when you substitute "ipython" for > "leo-editor" Great, could you please update this in the wiki page we have ? http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines It's important that this is in a permanent location besides the list archives so newcomers find it right away. Cheers, f > -------- > > Many users will want to track the development version of Leo, in order to stay > on top of the latest features and bugfixes. Running the development version is > quite safe and easy, and it's also a requirement if you want to contribute to > Leo. > > 1. First, you need to get Bazaar (bzr) from http://bazaar-vcs.org. For windows > users we recommend the standalone installer - the python installer may have > problems pushing to Launchpad. Plain bzr installer only contains the command > line version, so you might want to augment that with a friendly GUI - qbzr is > recommended as it's the easiest one to install. It provides command like > ``bzr qlog``, ``bzr qannotate`` etc. > > 2. Get Leo from launchpad by doing:: > > bzr branch lp:leo-editor > > And that's it! You can run leo/src/leo.py directly. When you want to refresh the > code with latest modifications from Launchpad, run ``bzr pull``. > > If you make modifications to Leo (with the interest in sharing them with the Leo > community), you can check them in to your local branch by doing ``bzr checkin``. > Now, to actually request your changes to be merged to Leo trunk, you need a > Launchpad account with RSA keys in place. There is showmedo video about how to > accomplish this on Windows using puttygen and pageant at > ``http://showmedo.com/videos/video?name=1510070&fromSeriesID=151``. > > After your Launchpad account is set up, go to > ``https://launchpad.net/leo-editor``, choose Code tab -> Register Branch, select > Branch type "Hosted" and fill in descriptive details about the branch. After > that, go to the branch home page from Code tab again, and copy-paste the push > command line to terminal. For example, for branch:: > > https://code.launchpad.net/~leo-editor-team/leo-editor/mod_rclick > > The push command is:: > > bzr push bzr+ssh://my_name at bazaar.launchpad.net/~leo-editor-team/leo-editor/mod_rclick > > You may wish to add --remember command line option to bzr push, to direct all > future pushes to that location. Then, you only need to execute ``bzr push``. > > After your branch is pushed, you can email the Leo mailing list and request it > to be reviewed and merged to trunk. > > -- > 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 fperez.net at gmail.com Tue Jun 3 14:37:05 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 11:37:05 -0700 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio wrote: > Here is a short guide to launchpad I wrote for Leo editor. It's > applicable to ipython as well, when you substitute "ipython" for > "leo-editor" One more thing: in here, the workflow you describe will lead to the 'history folding' problem we were having, no? You don't indicate keeping the dual-branch approach we'd discussed before and that I put in the version of the guide I uploaded over the weekend. The more I think about it, the more I think that no matter what we do, the web history view will never be 100% correct: lp made the decision to have a flat history view, and for a system that's fundamentally based on branching, there will alyways be cases where the linear view will fail to properly show the branch evolution and remerging. But I do want to clarify (simply because *I* am not 100% sure what the right solution is) if the dual-branch approach advocated earlier is correct, necessary, useful, etc. Cheers, f From ellisonbg.net at gmail.com Tue Jun 3 14:45:02 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 3 Jun 2008 12:45:02 -0600 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Message-ID: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> Also, I have started a rst/Sphinx based developer's guidelines in ipython1. I based it on the wiki initially, but has more info on certain fronts - especially on the stuff that is relevant to ipython1 merging with IPython. When I do the merge of ipython1->IPython, I will also merge the developer related things. This brings up a bigger issue. I would like _all_ of our docs to be Sphinx based. And in my mind, the developer guidelines fall under this. I don't like having to maintain multiple documentation sets (wiki + Sphinx) and I think the Sphinx docs are a better place for all of these things, including the developer related things. We should save the wiki for things like the cookbook and the basic web presence for IPython. How does this sound? Brian On Tue, Jun 3, 2008 at 12:37 PM, Fernando Perez wrote: > On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio wrote: >> Here is a short guide to launchpad I wrote for Leo editor. It's >> applicable to ipython as well, when you substitute "ipython" for >> "leo-editor" > > One more thing: in here, the workflow you describe will lead to the > 'history folding' problem we were having, no? You don't indicate > keeping the dual-branch approach we'd discussed before and that I put > in the version of the guide I uploaded over the weekend. > > The more I think about it, the more I think that no matter what we do, > the web history view will never be 100% correct: lp made the decision > to have a flat history view, and for a system that's fundamentally > based on branching, there will alyways be cases where the linear view > will fail to properly show the branch evolution and remerging. > > But I do want to clarify (simply because *I* am not 100% sure what the > right solution is) if the dual-branch approach advocated earlier is > correct, necessary, useful, etc. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Tue Jun 3 14:50:42 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 3 Jun 2008 12:50:42 -0600 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: <6ce0ac130806031150o31b91c82hfa2911c4f91bf444@mail.gmail.com> > I would encourage you guys to take a look at the > ipython1.frontends.frontendbase class. My intention is to develop this > into a base class for all GUI frontends. The underlying assumption is > that GUI frontends will interact with the ipython interpreter via the > ipython1.kernel.engineservice (Twisted) API. The benefits, as I see > them for this approach is to avoid rewriting the Wheel of GUI > Integration (the Twisted guys have already done this), and to make it > _very_ easy to provide remote/parallel capabilities from within the > GUI frontend. +1 > Of course, code speaks louder than words and I invite you to hack on > the frontends package (currently in ipython1-cocoa branch, but I > assume soon to be merged inwards towards ipython1-dev or trunk). The > frontendbase is currently a work in progress, but I've attempted to > make it clear where subclasses (e.g. GUI frontend implementations > should subclass particular methods to gain the desired functionality). > The intention is that frontends are an aggregate of a frontendbase > subclass and a GUI widget or a GUI widget (such as a text widget) that > subclasses both the GUI toolkit's widget and the frontendbase. > > barry > >> >> - correct integration with twisted's event loop. There's a lot of >> interest in the -twisted option working right, and twisted has GUI >> integration mechanisms (as discussed here earlier); we just want the >> whole thing to play nice with the networking layer used for >> distributed use. Note that the distributed use is not just for >> parallel computing: you may also want a Qt/Wx gui working on a remote >> ipython instance... > > If we stick with developing GUI interfaces through the engineservice > interface, we get all this for free. In addition, I think such an > approach will help drive the ipython1->ipython0 integration because it > will highlight the most pressing areas where we the ipython1's core > (exposed via engineservice) is not up-to-par wrt the ipython0 > InteractiveShell. > >> >> - the needs for the same abstractions to work over the network from >> frontends like a web browser that uses JavaScript. >> >> 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 ellisonbg.net at gmail.com Tue Jun 3 14:57:03 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 3 Jun 2008 12:57:03 -0600 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com> References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> <48445a88.02a1660a.6b17.776d@mx.google.com> <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com> Message-ID: <6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com> Another thing that we will have to move away from is having a Shell that talks to the GUI/frontend through callbacks that the frontend registers. The reason is that the frontend could possibly be in a completely different process, or even a web browser. In that type of setting, it is simply impossible for the Shell to call methods in the frontend. Furthermore, it is too tight of a coupling to have in a distributed system - what happens if the frontend goes away but the Shell persists. Instead, all the methods of the Shell will have to return Python objects (dicts, etcs) that contain the information that the frontend can use for its own purposes. Brian On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio wrote: > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou > wrote: > >> I mean we can stay with pyreadline for console based terminal but I think we >> need something simpler for "graphical" gui. > > I agree. However, this can be done as it is now in iplib.py > "interact_with_readline" method (which, admittedly, is not excercised > in current code but mostly server as proof that ipython can be easily > decoupled from raw_input. > >> (Another time, this is my point of view, some other devs will say that this >> is the job of a readline object: I'm not ok with that because I want to be >> free and I need something flexible. "Keep it simple" philosophy) > > I agree with you here. All the direct references to readline should > factored out of the logic-running classes. > >> - Completer API. >> Sometihng like: >> IP.Completer.getCompletion(user_input_to_complete) -> return a list of >> completion : >> list([completion1,'function'],[completion2,'int'],[completion3,'private'] >> etc... > > This should be easy. test_completer.py introduces how to "hack" your > way aroud the lack of API (so far). > > -- > 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 vivainio at gmail.com Tue Jun 3 15:16:49 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 22:16:49 +0300 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Message-ID: <46cb515a0806031216i48797067uf0c6f53dc3bd75e6@mail.gmail.com> On Tue, Jun 3, 2008 at 9:37 PM, Fernando Perez wrote: > One more thing: in here, the workflow you describe will lead to the > 'history folding' problem we were having, no? You don't indicate > keeping the dual-branch approach we'd discussed before and that I put > in the version of the guide I uploaded over the weekend. That is correct. This is guide for people who do not have push access to the trunk, but rather will create a small branch to be integrated to the trunk. People pushing to the trunk have different responsibilities. This is rather a guide to get started with launchpad, not ipython workflow as such. > But I do want to clarify (simply because *I* am not 100% sure what the > right solution is) if the dual-branch approach advocated earlier is > correct, necessary, useful, etc. Yes, it is necessary and useful; though with a slight clarification: the main idea in keeping safe is to prefer pull instead of merge. Basically, you should not do merges to "remain up to date", pull is for that. merge should be used to move your own changes to the trunk, not to get other people's stuff as with "svn up" (unless you are sure your change actually needs other people's modifications as well). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Tue Jun 3 15:17:36 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 22:17:36 +0300 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> Message-ID: <46cb515a0806031217t6ddaf3c4y312be4dbe6311f76@mail.gmail.com> On Tue, Jun 3, 2008 at 9:45 PM, Brian Granger wrote: > Sphinx based. And in my mind, the developer guidelines fall under > this. I don't like having to maintain multiple documentation sets > (wiki + Sphinx) and I think the Sphinx docs are a better place for all > of these things, including the developer related things. We should > save the wiki for things like the cookbook and the basic web presence > for IPython. How does this sound? +1 -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Tue Jun 3 15:21:07 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 12:21:07 -0700 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 11:45 AM, Brian Granger wrote: > Also, I have started a rst/Sphinx based developer's guidelines in > ipython1. I based it on the wiki initially, but has more info on > certain fronts - especially on the stuff that is relevant to ipython1 > merging with IPython. When I do the merge of ipython1->IPython, I > will also merge the developer related things. > > This brings up a bigger issue. I would like _all_ of our docs to be > Sphinx based. And in my mind, the developer guidelines fall under > this. I don't like having to maintain multiple documentation sets > (wiki + Sphinx) and I think the Sphinx docs are a better place for all > of these things, including the developer related things. We should > save the wiki for things like the cookbook and the basic web presence > for IPython. How does this sound? This has been very much in my mind, I just don't have the bandwidth to deal with all of it simultaneously. But I'm growing increasingly annoyed at having docs in the wiki and in rst that are separate. At the same time, the wiki has the advantage of lowering the barrier to external contributions in a way that rst docs don't quite achieve (they still require source editing and a patch). Ultimately the solution to this problem would be to have something like what is being now used for the numpy docstrings: http://sd-2116.dedibox.fr/pydocweb/wiki/Front Page/ but applied to ALL documentation. This is the ideal solution in the long run: everything in one place, casual users can contribute with a zero-overhead web interface, and the system automatically generates the changesets so that developers can apply them with minimal effort. But integrating all that is more than we should tackle *right now*, I think. So I'm all for the following as a compromise solution: 1. Put our dev guidelines in rst 2. I write a cron job to update nightly docs from the bzr mainline. 3. We make certain key wiki pages simply link to the relevant point in these auto-generated docs. I think it would make a neat topic for a sprint at scipy'08 to work on the full doc integration system... Cheers, f From fperez.net at gmail.com Tue Jun 3 15:22:10 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 12:22:10 -0700 Subject: [IPython-dev] Win32 IPython1? In-Reply-To: <48457029.8020401@uml.edu> References: <48457029.8020401@uml.edu> Message-ID: Hi Alex, On Tue, Jun 3, 2008 at 9:24 AM, Alex Brown wrote: > Hello - this may be the wrong list for this question; if so my > apologies. My next Python excursion involves a simple "parallel > programming" problem - I am trying to put together Python controller and > server modules for very coarse-grain parallel processing of GIS and > remote sensing data using existing Win32 GIS and remote sensing software > tools running in WinXP on a classroom cluster. The Win32 COM Python > tools are fine for local control of these interactive applications and > I'm trying to find an existing "parallel" network controller toolkit > that will work in the Win32 world, either native or through Cygwin. > (The controller environment can be Linux of course.) I've tried some of > the "grid" style tools for cluster management that claim to run in > Cygwin, and found them to be clumsy (batch-oriented) and unreliable. I > am now looking into IPython1, and I'd like to know if there is any > experience with it in a Win32 environment. > > Any suggestions would be welcome. > Yes, some people have used it in a win32 environment, though I haven't myself. We are very interested in feedback. We should caution you that we are starting the process of merging all the ip1 capabilities into 'regular' ipython. So while for now the ipython1 code will continue to exist, we hope that soon (in a few weeks) the key components for distributed computing will be part of the main trunk. In the long run this will make it easier for you: you simply upgrade ipython with each release (or follow the development tree with bzr) and you're done. This is just so you're aware that the location for some things is changing, but we're convinced the change is for the best. Regards, f From fperez.net at gmail.com Tue Jun 3 15:59:09 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 12:59:09 -0700 Subject: [IPython-dev] Synchronization with gvim In-Reply-To: <484553B1.9020405@vdesmedt.com> References: <484553B1.9020405@vdesmedt.com> Message-ID: Hi Vivian, On Tue, Jun 3, 2008 at 7:22 AM, Vivian De Smedt wrote: > Dear All, > > Here is a version of the hook that should work for gvim (it suppose that > gvim is in the path). I imagine from your other post that you'll resend this as a patch against current trunk, correct? You mentioned you'd need to do it from home to access launchpad, so I assume we'll wait for all the editor-related patches to come from you. Just checking so this doesn't get lost... Thanks! f From jorgen.stenarson at bostream.nu Tue Jun 3 16:04:47 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 03 Jun 2008 22:04:47 +0200 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> Message-ID: <4845A3DF.60504@bostream.nu> Ville M. Vainio skrev: > Here is a short guide to launchpad I wrote for Leo editor. It's > applicable to ipython as well, when you substitute "ipython" for > "leo-editor" Hi, nice intro. But do you know of any comprehensive guide to get bzr+launchpad working on windows. With instructions for authentication, creating a project on launchpad and pushing the first content. /J?rgen From ellisonbg.net at gmail.com Tue Jun 3 16:06:12 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 3 Jun 2008 14:06:12 -0600 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> Message-ID: <6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com> On Tue, Jun 3, 2008 at 1:21 PM, Fernando Perez wrote: > On Tue, Jun 3, 2008 at 11:45 AM, Brian Granger wrote: >> Also, I have started a rst/Sphinx based developer's guidelines in >> ipython1. I based it on the wiki initially, but has more info on >> certain fronts - especially on the stuff that is relevant to ipython1 >> merging with IPython. When I do the merge of ipython1->IPython, I >> will also merge the developer related things. >> >> This brings up a bigger issue. I would like _all_ of our docs to be >> Sphinx based. And in my mind, the developer guidelines fall under >> this. I don't like having to maintain multiple documentation sets >> (wiki + Sphinx) and I think the Sphinx docs are a better place for all >> of these things, including the developer related things. We should >> save the wiki for things like the cookbook and the basic web presence >> for IPython. How does this sound? > > This has been very much in my mind, I just don't have the bandwidth to > deal with all of it simultaneously. But I'm growing increasingly > annoyed at having docs in the wiki and in rst that are separate. At > the same time, the wiki has the advantage of lowering the barrier to > external contributions in a way that rst docs don't quite achieve > (they still require source editing and a patch). > > Ultimately the solution to this problem would be to have something > like what is being now used for the numpy docstrings: > > http://sd-2116.dedibox.fr/pydocweb/wiki/Front Page/ > > but applied to ALL documentation. This is the ideal solution in the > long run: everything in one place, casual users can contribute with a > zero-overhead web interface, and the system automatically generates > the changesets so that developers can apply them with minimal effort. Except, I am not sure that having casual users contribute to the docs without any review is a good idea. In fact, with no review, there is the possibility that wiki spam could make it into our docs in a major release. Also, even when you know rst+Sphinx it is easy to mess up links, etc. I would like to move gradually towards code review (but not a formal process, I am thinking of people simply reviewing each others branches before a merge) and a direct wiki->trunk connection is a move in the opposite direction. Here is what I have been thinking of: 1) We (the ipython dev team) use the rst/Sphinx for any/all docs that we are maintaining. 1) We encourage the usage of the wiki for unofficial, user contributed docs, the cookbook, etc. 2) We encourage users to contribute official rst/Sphinx docs by branching trunk, writing the docs and then requesting a review/merge. > But integrating all that is more than we should tackle *right now*, I > think. So I'm all for the following as a compromise solution: > > 1. Put our dev guidelines in rst > 2. I write a cron job to update nightly docs from the bzr mainline. > 3. We make certain key wiki pages simply link to the relevant point in > these auto-generated docs. I think this sounds great. I volunteer to get the docs (IPython+ipython1) in shape if you can setup the cron job afterwards. > I think it would make a neat topic for a sprint at scipy'08 to work on > the full doc integration system... > > Cheers, > > f > From vivainio at gmail.com Tue Jun 3 16:08:28 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 23:08:28 +0300 Subject: [IPython-dev] NameError: global name 'error' is not defined In-Reply-To: <484558D6.8090700@slac.stanford.edu> References: <484558D6.8090700@slac.stanford.edu> Message-ID: <46cb515a0806031308q56a60bf7q2d350b4bfae7ba3a@mail.gmail.com> On Tue, Jun 3, 2008 at 5:44 PM, Johann Cohen-Tanugi wrote: > NameError: global name 'error' is not defined Thanks for the report, fix committed! -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Tue Jun 3 16:11:54 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 23:11:54 +0300 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <4845A3DF.60504@bostream.nu> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <4845A3DF.60504@bostream.nu> Message-ID: <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com> On Tue, Jun 3, 2008 at 11:04 PM, J?rgen Stenarson wrote: > nice intro. But do you know of any comprehensive guide to get bzr+launchpad > working on windows. With instructions for authentication, > creating a project on launchpad and pushing the first content. See that video linked to in my intro, it has just the stuff you are looking for. I'll try to get pyreadline imported to launchpad, stay tuned. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Tue Jun 3 16:17:40 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 13:17:40 -0700 Subject: [IPython-dev] Win32 IPython1? In-Reply-To: <48459D9F.9020900@uml.edu> References: <48457029.8020401@uml.edu> <48459D9F.9020900@uml.edu> Message-ID: On Tue, Jun 3, 2008 at 12:38 PM, Alex Brown wrote: > Should I wait until your merge is complete? I need to at least decide on an > approach in the next week or two. If you can tolerate *minor* code breakage, I'd suggest that you start using ipython1 right away, as if the merge wasn't going to happen. It's perfectly usable today, and all we're doing is moving its functionality into the trunk. So what you'll need to do when we finish the move and *you* are ready (ip1 will remain available for you to install/deploy) will be to change a few imports from from ipython1.blah... to from IPython.blahh.... Your application code will remain the same otherwise. HTH, f From fperez.net at gmail.com Tue Jun 3 16:22:21 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 13:22:21 -0700 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com> <6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 1:06 PM, Brian Granger wrote: > Except, I am not sure that having casual users contribute to the docs > without any review is a good idea. In fact, with no review, there is > the possibility that wiki spam could make it into our docs in a major > release. Also, even when you know rst+Sphinx it is easy to mess up > links, etc. I would like to move gradually towards code review (but > not a formal process, I am thinking of people simply reviewing each > others branches before a merge) and a direct wiki->trunk connection is > a move in the opposite direction. Here is what I have been thinking > of: Ah, but that's the killer feature of the above system: the user contributions do NOT go into the core without prior review. The Turbogears backend behind that site generates a patch per contribution that goes into a private branch of numpy. Periodically (I think Stefan is doing it once or twice a week) those patches get applied or discarded and the site re-synced. There are tools on the site for other editors to review, comment, etc. So I honestly think that system gives us the best of both worlds: trivial for users to contribute, impossible for junk to contaminate the core. The only problem is that the system isn't currently set up to do the rst docs, only docstrings, and I'm too busy to talk to Stefan, Pauli and Emanuelle about generalizing it a bit. I think we should focus on our code merge right now. But a bit later in the summer I think this is really worth looking into. > I think this sounds great. I volunteer to get the docs > (IPython+ipython1) in shape if you can setup the cron job afterwards. Will do. Thanks for kicking in! Cheers, f From Alexander_Brown at uml.edu Tue Jun 3 16:19:58 2008 From: Alexander_Brown at uml.edu (Alex Brown) Date: Tue, 03 Jun 2008 16:19:58 -0400 Subject: [IPython-dev] Win32 IPython1? In-Reply-To: References: <48457029.8020401@uml.edu> <48459D9F.9020900@uml.edu> Message-ID: <4845A76E.4060307@uml.edu> Sounds good - thanks. Fernando Perez wrote: > On Tue, Jun 3, 2008 at 12:38 PM, Alex Brown wrote: > >> Should I wait until your merge is complete? I need to at least decide on an >> approach in the next week or two. >> > > If you can tolerate *minor* code breakage, I'd suggest that you start > using ipython1 right away, as if the merge wasn't going to happen. > It's perfectly usable today, and all we're doing is moving its > functionality into the trunk. So what you'll need to do when we > finish the move and *you* are ready (ip1 will remain available for you > to install/deploy) will be to change a few imports from > > from ipython1.blah... > > to > > from IPython.blahh.... > > Your application code will remain the same otherwise. > > HTH, > > f > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivainio at gmail.com Tue Jun 3 16:39:20 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 23:39:20 +0300 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> Message-ID: <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com> On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark wrote: > I would encourage you guys to take a look at the > ipython1.frontends.frontendbase class. My intention is to develop this > into a base class for all GUI frontends. The underlying assumption is It doesn't seem to be too hard to shoehorn the frontendbase between the gui and ipython; most of the work is really in implementation of the actual gui drawing. Though, at the moment frontendbase can't be directly imported in core ipython due to twisted dependency. I suppose the only real twisted dependency in that class could be removed by creating "result_ready(r)" method and implementing execute_with_callback in engine that does normal callback instead of returning a deferred... obviously the engine can use deferred for actual implementation, for the twisted version. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Tue Jun 3 16:53:10 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 3 Jun 2008 23:53:10 +0300 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <4845A3DF.60504@bostream.nu> <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com> Message-ID: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com> On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio wrote: > I'll try to get pyreadline imported to launchpad, stay tuned. Of course we are having the same problem as with ipython. See my import request: https://answers.launchpad.net/launchpad-bazaar/+question/24416 I assume they can sort this out shortly. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Tue Jun 3 17:00:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 14:00:28 -0700 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <4845A3DF.60504@bostream.nu> <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com> <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 1:53 PM, Ville M. Vainio wrote: > On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio wrote: > >> I'll try to get pyreadline imported to launchpad, stay tuned. > > Of course we are having the same problem as with ipython. See my import request: > > https://answers.launchpad.net/launchpad-bazaar/+question/24416 > > I assume they can sort this out shortly. The scipy server was recently upgraded and now it's a lot more responsive. Even if it times out a little now, it should work shortly. Let me know if it doesn't and we can try to manually fetch a repo dump. f From fperez.net at gmail.com Tue Jun 3 18:57:56 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 15:57:56 -0700 Subject: [IPython-dev] automatic cpaste In-Reply-To: <479FA443.8010406@csail.mit.edu> References: <479FA443.8010406@csail.mit.edu> Message-ID: Hi Ken, 2008/1/29 Ken Schutte : > Hello, > > I've been trying to figure out a way to make cpaste more "automatic". > > The closest I've come is the attached cpaste modification. Using "cpaste > -a" automatically executes the contents of the clipboard; however, it > requires the 'xclip' command, which is run with os.popen3(). (btw, xclip is > a nice command-line utility - I've found it's in most distro's repositories, > but usually not installed by default). > > I'm not sure if you'd want to add this patch because of this dependency, but > it should be backward compatible as is. (or is there a better way to get the > clipbard contents?) > > This is maybe a slight improvement for me, but I'd love something where I > can truly do a simple paste with the mouse and everything is done > automatically. I guess this is basically not possible within ipython? > > I usually use ipython within a Konsole window, so the only other thing I can > think of is to figure out if you can easily do something there to make this > happen, e.g. intercept a mouse paste, and instead paste in the text > "cpaste\n"+$clipboard+"\n--\n". > > If anyone has any suggestions, please let me know. Sorry for the long delay. As you can see, we're now trying to re-energize work around here :) The problem with your patch is that it adds an X11 dependency onto ipython's core, and that's just not OK. We do have platform-specific extensions and features, but not in the very core features, which *must* remain portable. However, if you can figure out a way to abstract out what's basically a get_clipboard() functionality into something for which os-specific backends can be written, this could certainly be done. There may even be already in the freedesktop.org an API for clipboard access that works on reasonably modern linuxes, and I'm sure both OSX and Win32 have APIs for the same thing. In the meantime, you can keep this as a local magic function in your own environment, so you can freely upgrade ipython versions without losing your changes. regards, f From barrywark at gmail.com Tue Jun 3 19:28:44 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 3 Jun 2008 16:28:44 -0700 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com> References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 1:39 PM, Ville M. Vainio wrote: > On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark wrote: > >> I would encourage you guys to take a look at the >> ipython1.frontends.frontendbase class. My intention is to develop this >> into a base class for all GUI frontends. The underlying assumption is > > It doesn't seem to be too hard to shoehorn the frontendbase between > the gui and ipython; most of the work is really in implementation of > the actual gui drawing. Correct. This is the only way to make sure that a terminal frontend, a graphical frontend like Mathematica's or a web-based frontend can all fit into the same framework. This leads to the somewhat simplified M(VC) picture where the FrontendBase acts as the model for an ipython engine, and the front end implementation acts as a combined view and controller in the MVC architecture. > > Though, at the moment frontendbase can't be directly imported in core > ipython due to twisted dependency. I suppose the only real twisted > dependency in that class could be removed by creating > "result_ready(r)" method and implementing execute_with_callback in > engine that does normal callback instead of returning a deferred... > obviously the engine can use deferred for actual implementation, for > the twisted version. Because FrontendBase.__init__ takes an engine parameter, the terminal frontend could use core instead of engineservice for its engine. The only requirement then is to have a small amount of code (I think this already exists somewhere in ipython1.core) for chaining callbacks to the execution result (i.e. creating a pseudo-Deferred). > > -- > Ville M. Vainio - vivainio.googlepages.com > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' > From barrywark at gmail.com Tue Jun 3 19:43:16 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 3 Jun 2008 16:43:16 -0700 Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin In-Reply-To: References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com> <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com> Message-ID: It's also worth mentioning by way of introduction what I'm working on in ipython1.frontend.rendering. The idea is that things like matplotlib/chaco plots, images, or other non-string results may want to be displayed inline by a graphical frontend (like Mathematica's notebook interface). Obviously, this rendering is going to be GUI framework dependent, so I'm trying to make it easier for frontends to create renderers for images, plots etc. and figure what renderer to use for what result. So the rendering module provides a registry, keyed by object type of renderers so a frontend can find the most specific renderer for a result object. I'm not sure this is ultimately worth it... we'll have to see how much utility it provides to frontends. Barry On Tue, Jun 3, 2008 at 4:28 PM, Barry Wark wrote: > On Tue, Jun 3, 2008 at 1:39 PM, Ville M. Vainio wrote: >> On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark wrote: >> >>> I would encourage you guys to take a look at the >>> ipython1.frontends.frontendbase class. My intention is to develop this >>> into a base class for all GUI frontends. The underlying assumption is >> >> It doesn't seem to be too hard to shoehorn the frontendbase between >> the gui and ipython; most of the work is really in implementation of >> the actual gui drawing. > > Correct. This is the only way to make sure that a terminal frontend, > a graphical frontend like Mathematica's or a web-based frontend can > all fit into the same framework. This leads to the somewhat simplified > M(VC) picture where the FrontendBase acts as the model for an ipython > engine, and the front end implementation acts as a combined view and > controller in the MVC architecture. > >> >> Though, at the moment frontendbase can't be directly imported in core >> ipython due to twisted dependency. I suppose the only real twisted >> dependency in that class could be removed by creating >> "result_ready(r)" method and implementing execute_with_callback in >> engine that does normal callback instead of returning a deferred... >> obviously the engine can use deferred for actual implementation, for >> the twisted version. > > Because FrontendBase.__init__ takes an engine parameter, the terminal > frontend could use core instead of engineservice for its engine. The > only requirement then is to have a small amount of code (I think this > already exists somewhere in ipython1.core) for chaining callbacks to > the execution result (i.e. creating a pseudo-Deferred). > > >> >> -- >> Ville M. Vainio - vivainio.googlepages.com >> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' >> > From fperez.net at gmail.com Tue Jun 3 19:47:28 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 16:47:28 -0700 Subject: [IPython-dev] Bzr merge idiosyncracies... Message-ID: Hi folks, since I remain concerned about the issue of how bzr handles history with multiple merges, and how launchpad displays it, I went looking around in the bazaar mailing list. From there I ran into this, that happened to be written today: http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html (btw, that blog seems like it will be a handy reference on DVCS systems). At least I wasn't totally crazy in feeling uncomfortable with the bzr model. I think we can live with it for now, and the benefits of all the launchpad hosting infrastructure are too big for us to ignore, so we'll just have to tweak our development practices to coexist somewhat with bzr's personality quirks. As we all find the pieces of what a good workflow should be, I hope we'll all contribute it back. Now that I'm trying to use the two-branch approach to avoid messy history, I'm getting extremely irritated. I feel like I'm babysitting my VCS instead of it being a tool at my service (way too many steps for normal operation, too many things that need to be done in *just the right order* to avoid a mess, etc). I hope these are just growing pains and that we'll soon settle into something reasonable, otherwise I might revert to basically ignoring the launchpad history tool and having local trees be the only way that we consider the history to be logged. A bit grumpy... f From fperez.net at gmail.com Tue Jun 3 21:03:46 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 18:03:46 -0700 Subject: [IPython-dev] Clearing exception info stored for %debug? In-Reply-To: <200801181746.26728.hans_meine@gmx.net> References: <200801181746.26728.hans_meine@gmx.net> Message-ID: Hi Hans, 2008/1/18 Hans Meine : > Hi! > > I just suffered from a complicated situation; I had a file being clobbered on > IPython quit by a __del__ method from one of the objects in the stack within > an exception that occurred earlier. After the exception, I only ran one > corrected command which stored the right file after a long computation, but > when I quit IPython the data was overwritten by the partial results from the > earlier, broken run. > > This situation is probably a rare one, but I thought that one might want to > introduce "%clear exception" or sth. along that lines. Could you be more specific on how such clearing would be implemented? As far as I know, Python doesn't provide an official API for exception clearing, but I could well be wrong. sys holds certain special objects: In [2]: sys.last sys.last_traceback sys.last_type sys.last_value that only appear after an exception has occurred. One could concievably delete those straight from the sys module dict, but that feels a bit harsh. And in addition, references could be held elsewhere, there's no easy way in python for finding all references held to an object (or is there?). So I'm not opposed in principle to your idea, I'm just not quite sure how to go about it... Regards, f From stefan at sun.ac.za Tue Jun 3 21:29:35 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 4 Jun 2008 03:29:35 +0200 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: References: Message-ID: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> Hi Fernando 2008/6/4 Fernando Perez : > since I remain concerned about the issue of how bzr handles history > with multiple merges, and how launchpad displays it, I went looking > around in the bazaar mailing list. From there I ran into this, that > happened to be written today: > > http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html Interesting post. As far as I recall, "bzr merge --pull" also does fast-forwarding. I wonder if a person can set this to be the default behaviour. Ah, here's the article: http://jameswestby.net/weblog/bzr/01-revision-numbers.html Regards St?fan From fperez.net at gmail.com Tue Jun 3 22:01:45 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 3 Jun 2008 19:01:45 -0700 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 6:29 PM, St?fan van der Walt wrote: > Hi Fernando > > 2008/6/4 Fernando Perez : >> since I remain concerned about the issue of how bzr handles history >> with multiple merges, and how launchpad displays it, I went looking >> around in the bazaar mailing list. From there I ran into this, that >> happened to be written today: >> >> http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html > > Interesting post. As far as I recall, "bzr merge --pull" also does > fast-forwarding. I wonder if a person can set this to be the default > behaviour. > > Ah, here's the article: > > http://jameswestby.net/weblog/bzr/01-revision-numbers.html Wow. And here's the problem (next to last paragraph): The indentation of the merged commits (and the fact they disappear with "--short" and "--line") means that mentally they become of lesser importance. You see "merged performance work from Emma's branch", rather than all of the commits that you got from her. They are still there to look at if you want, but they can be ignored at most times. /quote I can't believe that this is actually something that bazaar considers a 'feature' and they promote as a valid design point. The fact that you've merged someone else's work into your branch because you happen to be a maintainer, for example, doesn't make their work in any way 'second class'. I agree 100% percent with Linus here (post linked to in the vcscompare post): http://www.gelato.unsw.edu.au/archives/git/0611/31361.html Oh well. For me, what really matters right now is that we get the hosting infrastructure of launchpad. I'm less and less enamored with bzr, but that's irrelevant. We have much bigger fish to fry than getting into a bzr-vs-git/hg decision. We stick with bzr, warts and all. All I want to do is to find a workflow that we can use with minimal pain. If that means accomodating bzr's design flaws, so be it. My problem is that I haven't found that workflow yet, and I'm finding myself fighting the tool. I await enlightenment... f From vivainio at gmail.com Wed Jun 4 02:05:12 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 09:05:12 +0300 Subject: [IPython-dev] automatic cpaste In-Reply-To: <479FA443.8010406@csail.mit.edu> References: <479FA443.8010406@csail.mit.edu> Message-ID: <46cb515a0806032305u67b6c5dfl23edbfca3e0945a8@mail.gmail.com> 2008/1/30 Ken Schutte : > I'm not sure if you'd want to add this patch because of this dependency, but > it should be backward compatible as is. (or is there a better way to get the > clipbard contents?) This is not ok "directly", but will be with a bit of tweaking: - Add "get_clipboard" to platutils.py and platutils_posix.py (it should be easy), and an empty stub for windows. - I will add the windows implementation later on. > This is maybe a slight improvement for me, but I'd love something where I > can truly do a simple paste with the mouse and everything is done > automatically. I guess this is basically not possible within ipython? It's possible, but does a different thing. cpaste executes standard python code that is pasted - pasting to ipython prompt does ipython input translation, and may have problems with empty lines. > I usually use ipython within a Konsole window, so the only other thing I can > think of is to figure out if you can easily do something there to make this > happen, e.g. intercept a mouse paste, and instead paste in the text > "cpaste\n"+$clipboard+"\n--\n". This does sound like functionality that will have to reside in the GUI frontends. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Wed Jun 4 02:55:56 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 09:55:56 +0300 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> Message-ID: <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com> On Wed, Jun 4, 2008 at 5:01 AM, Fernando Perez wrote: > I can't believe that this is actually something that bazaar considers > a 'feature' and they promote as a valid design point. The fact that > you've merged someone else's work into your branch because you happen > to be a maintainer, for example, doesn't make their work in any way > 'second class'. I agree 100% percent with Linus here (post linked to > in the vcscompare post): This is something that works very well in practice, provided that the branch work is of reasonable size - one feature, bugfix, etc. The idea is that the log message is detailed enough to describe what was merged. It should not be "merged stuff". This liberates the commit policy in the branch, you can experiment and play around a bit more when the end result will appear as single well-contained commit. In my last project the policy was "single commit per bugfix", using an official commit template. It worked just fine, and you could easily find what bugfix caused a problem, who did it, etc. You are not interested it 10+ micro-commits that the original fixer did. We should pick up a policy where we add the branch owners name as the first thing in the log message, for people who don't have trunk access. As far as linux goes - the development hierarchy is multilayered, which is not the case with us. There are no people who consolidate small branches to big branches that are merged to trunk, but rather the small branches are integrated directly to trunk. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Wed Jun 4 03:02:56 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 00:02:56 -0700 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com> References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com> Message-ID: On Tue, Jun 3, 2008 at 11:55 PM, Ville M. Vainio wrote: > On Wed, Jun 4, 2008 at 5:01 AM, Fernando Perez wrote: > >> I can't believe that this is actually something that bazaar considers >> a 'feature' and they promote as a valid design point. The fact that >> you've merged someone else's work into your branch because you happen >> to be a maintainer, for example, doesn't make their work in any way >> 'second class'. I agree 100% percent with Linus here (post linked to >> in the vcscompare post): > > This is something that works very well in practice, provided that the > branch work is of reasonable size - one feature, bugfix, etc. The idea > is that the log message is detailed enough to describe what was > merged. It should not be "merged stuff". > > This liberates the commit policy in the branch, you can experiment and > play around a bit more when the end result will appear as single > well-contained commit. > > In my last project the policy was "single commit per bugfix", using an > official commit template. It worked just fine, and you could easily > find what bugfix caused a problem, who did it, etc. You are not > interested it 10+ micro-commits that the original fixer did. > > We should pick up a policy where we add the branch owners name as the > first thing in the log message, for people who don't have trunk > access. > > As far as linux goes - the development hierarchy is multilayered, > which is not the case with us. There are no people who consolidate > small branches to big branches that are merged to trunk, but rather > the small branches are integrated directly to trunk. It would be really good if you put some of these 'bzr good workflow practices' in the wiki dev guidelines page. Feel free to make it all rst right away: that way when Brian integrates the docs, he can just grab it from there. Moin renders rest just fine, with a directive: {{{ #rst ... }}} You have a *much* better sense for how to work with, rather than against, bzr. We'd all benefit from that insight before we mangle the ipython tree into a crazy mess... The single commit per bugfix is probably also a good policy because I'm starting to get the feel that there's ONE file that is going to give us grief: the linear ChangeLog. That's the one file where conflicts are likely to appear if we all edit it, so we might be better off probably NOT using it anymore, and relying on the commit logs instead. But for that to be viable, the commit logs must be a suitable replacement of the current Changelog, so they need to have an entry per actual change, and must be more than one-liners. Otherwise there will be no easily human-readable log later anywhere. Does that sound right? Cheers, f From fperez.net at gmail.com Wed Jun 4 03:16:58 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 00:16:58 -0700 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 12:02 AM, Fernando Perez wrote: > {{{ > #rst Typo {{{ #!rst Cheers, f From fperez.net at gmail.com Wed Jun 4 04:21:12 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 01:21:12 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? Message-ID: Howdy, I am now using the two-branch system we discussed earlier, but still when I pull in the changes from trunk and push again, the problem of 'history folding' happens: On Wed, Jun 4, 2008 at 1:11 AM, wrote: > ------------------------------------------------------------ > revno: 994 > committer: Fernando Perez > branch nick: trunk-dev > timestamp: Tue 2008-06-03 14:09:11 -0700 > message: > merge remote > modified: > IPython/Extensions/pspersistence.py > IPython/gui/wx/ipshell_nonblocking.py > IPython/gui/wx/ipython_view.py > doc/ChangeLog > doc/ipython.1 > doc/source/ipython.rst > ------------------------------------------------------------ > revno: 991.1.4 > committer: Ville M. Vainio > branch nick: ipython > timestamp: Tue 2008-06-03 23:05:35 +0300 > message: > changelog: report UsageError on %store -w w/o arg,and other usage pattern errors. Bug report by Johann Cohen-Tanugi. > modified: > doc/ChangeLog > ------------------------------------------------------------ > revno: 991.1.3 > committer: Ville M. Vainio > branch nick: ipython > timestamp: Tue 2008-06-03 23:03:02 +0300 > message: > pspersistence report UsageError's instead of crashing on 'error' > modified: > IPython/Extensions/pspersistence.py etc.. In this case a sequence of commits from Ville got swallowed in by my merge (I did use --pull which is supposed to 'fast forward') but no luck. Obviously next time anyone else commits it will be my changes that get folded in, etc. It seems the notion of a 'shared mainline' with multiple push persons is just not how bzr likes to work, or I'm doing something very, very wrong with it... Cheers, f From fperez.net at gmail.com Wed Jun 4 04:22:33 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 01:22:33 -0700 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Main line of IPython development (stable) In-Reply-To: <8612293437090592870@unknownmsgid> References: <8612293437090592870@unknownmsgid> Message-ID: Aha! On Wed, Jun 4, 2008 at 1:11 AM, wrote: > 4 revisions were removed from the branch. > > > -- > Main line of IPython development (stable) > https://code.launchpad.net/~ipython/ipython/trunk This is what lp thinks: that we've 'removed' revisions, simply because they were merged in my local copy. But I *have* to merge them, because I need to pull in the remote changes made from other committers. Confused... f From laurent.dufrechou at gmail.com Wed Jun 4 04:28:06 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Wed, 4 Jun 2008 10:28:06 +0200 Subject: [IPython-dev] Help! TR: TR: Ipython plugin In-Reply-To: <6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com> References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com> <4843ab8f.1358560a.46cd.ffffde15@mx.google.com> <48445a88.02a1660a.6b17.776d@mx.google.com> <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com> <6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com> Message-ID: <48465218.0ab6660a.4758.7a00@mx.google.com> For the callback, I see it difficult to avoid (but not impossible) When i wrote wxIpython i fall in such a situation, whether to chose callback approach or state machine approach. Has you said, It should be better not to use callback. This is what I did at first place. The only problem was responsiveness because you will do some polling... So the only methods I use currently for call back are: def _askExit(self): wx.CallAfter(self.ask_exit_callback, ()) def _afterExecute(self): wx.CallAfter(self.parent.evtStateExecuteDone, ()) _askExit(self) is called when user type : "Exit()" <-- this callback can be avoid _afterExecute(self) is called for performance reason, to avoid polling of the GUI. So please keep in mind the _afterExecute problem :) Another problem (THE hardest!) If user do: while (1): print "hello" --> problems: display "hello" for each loop --> support ctrl+c I had to use a callback with multithread synchronization (ugghhh) to display all the hello in my gui and be able to do a ctrl+c to break the loop. This was the worst thing for me that condense all the problem with GUI. If you can solve this with your approach without a big hack I'll be more than happy! The inter multithread 'synchro' could be avoid but would have implied ipython core modification, that was not my objective... (the multithread alone can't be avoid if you want to support ctrl+c) I AM VERY VERY VERY interested in a ipython core + twisted with xml rpc + GUI loop: This will permit me to launch an ipython core + wx or qt or ??? in a different process and be able to create graphical apps while the display gui as its own GUI loop! We must find a way to do this ;=) !!!!!!!!!!!!!! Laurent > -----Message d'origine----- > De?: Brian Granger [mailto:ellisonbg.net at gmail.com] > Envoy??: mardi 3 juin 2008 20:57 > ??: Ville M. Vainio > Cc?: Laurent Dufrechou; Fernando Perez; ipython-dev Mailing list > Objet?: Re: [IPython-dev] Help! TR: TR: Ipython plugin > > Another thing that we will have to move away from is having a Shell > that talks to the GUI/frontend through callbacks that the frontend > registers. The reason is that the frontend could possibly be in a > completely different process, or even a web browser. In that type of > setting, it is simply impossible for the Shell to call methods in the > frontend. Furthermore, it is too tight of a coupling to have in a > distributed system - what happens if the frontend goes away but the > Shell persists. > > Instead, all the methods of the Shell will have to return Python > objects (dicts, etcs) that contain the information that the frontend > can use for its own purposes. > > Brian > > > On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio > wrote: > > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou > > wrote: > > > >> I mean we can stay with pyreadline for console based terminal but I > think we > >> need something simpler for "graphical" gui. > > > > I agree. However, this can be done as it is now in iplib.py > > "interact_with_readline" method (which, admittedly, is not excercised > > in current code but mostly server as proof that ipython can be easily > > decoupled from raw_input. > > > >> (Another time, this is my point of view, some other devs will say > that this > >> is the job of a readline object: I'm not ok with that because I want > to be > >> free and I need something flexible. "Keep it simple" philosophy) > > > > I agree with you here. All the direct references to readline should > > factored out of the logic-running classes. > > > >> - Completer API. > >> Sometihng like: > >> IP.Completer.getCompletion(user_input_to_complete) -> return a list > of > >> completion : > >> > list([completion1,'function'],[completion2,'int'],[completion3,'private > '] > >> etc... > > > > This should be easy. test_completer.py introduces how to "hack" your > > way aroud the lack of API (so far). > > > > -- > > 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 vivian at vdesmedt.com Wed Jun 4 04:34:51 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Wed, 04 Jun 2008 10:34:51 +0200 Subject: [IPython-dev] Synchronization with gvim In-Reply-To: References: <484553B1.9020405@vdesmedt.com> Message-ID: <484653AB.7060909@vdesmedt.com> Hi Fernando, > I imagine from your other post that you'll resend this as a patch > against current trunk, correct? Yes, I'll try to create an account, create a branch and "checkin" my change for revision. Since I'm new with bzr it could take me some days before I'll finish with that but I'll try to complete the task before the end of next week. Thanks to Ville and its nice hint I guess it will be easy :-) Regards, Vivian. From vivainio at gmail.com Wed Jun 4 07:36:28 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 14:36:28 +0300 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: Message-ID: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> On Wed, Jun 4, 2008 at 11:21 AM, Fernando Perez wrote: > I am now using the two-branch system we discussed earlier, but still > when I pull in the changes from trunk and push again, the problem of > 'history folding' happens: You are doing something wrong. What you need to do is (iptrunk is your local trunk, ipfix is your change branch): cd /iptrunk bzr pull bzr merge ../ipfix bzr ci bzr push -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Wed Jun 4 07:39:34 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 14:39:34 +0300 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Main line of IPython development (stable) In-Reply-To: References: <8612293437090592870@unknownmsgid> Message-ID: <46cb515a0806040439i28e4e415rfc68f8e37ba7686f@mail.gmail.com> On Wed, Jun 4, 2008 at 11:22 AM, Fernando Perez wrote: > This is what lp thinks: that we've 'removed' revisions, simply because > they were merged in my local copy. But I *have* to merge them, > because I need to pull in the remote changes made from other > committers. Actually, you don't need to merge changes from other developers in your fix branch. "merge" is not "svn up". You should *pull* changes from other developers (in your local trunk), *then* merge your changes from your personal branch to the trunk. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Wed Jun 4 07:43:31 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 14:43:31 +0300 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com> Message-ID: <46cb515a0806040443i438cd561p13b500740c93d3ae@mail.gmail.com> On Wed, Jun 4, 2008 at 10:02 AM, Fernando Perez wrote: > It would be really good if you put some of these 'bzr good workflow > practices' in the wiki dev guidelines page. Feel free to make it all I'll try to do that soon, but I'm rather bogged ATM. > The single commit per bugfix is probably also a good policy because > I'm starting to get the feel that there's ONE file that is going to > give us grief: the linear ChangeLog. That's the one file where > conflicts are likely to appear if we all edit it, so we might be > better off probably NOT using it anymore, and relying on the commit > logs instead. But for that to be viable, the commit logs must be a > suitable replacement of the current Changelog, so they need to have an > entry per actual change, and must be more than one-liners. Otherwise > there will be no easily human-readable log later anywhere. Does that > sound right? It worked well for us (we used perforce which had similar branch/merge philosophy), let's try to follow it. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From darren.dale at cornell.edu Wed Jun 4 09:12:17 2008 From: darren.dale at cornell.edu (Darren Dale) Date: Wed, 4 Jun 2008 09:12:17 -0400 Subject: [IPython-dev] broken link on download page Message-ID: <200806040912.17653.darren.dale@cornell.edu> The "this section" link in the windows section of the download page is broken, and the page is immutable so I can't fix it myself. Darren -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 darren.dale at cornell.edu office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu From fperez.net at gmail.com Wed Jun 4 10:53:14 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 07:53:14 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 4:36 AM, Ville M. Vainio wrote: > On Wed, Jun 4, 2008 at 11:21 AM, Fernando Perez wrote: > >> I am now using the two-branch system we discussed earlier, but still >> when I pull in the changes from trunk and push again, the problem of >> 'history folding' happens: > > You are doing something wrong. > > What you need to do is (iptrunk is your local trunk, ipfix is your > change branch): > > cd /iptrunk > bzr pull > bzr merge ../ipfix > bzr ci > bzr push Ah, OK. I got confused by the post that said that 'merge --pull' was the way to 'fast forward' the history, and was using that. What is the correct mechanism for getting the trunk changes that come from other developer into ipfix? Because at some point you still need to make sure you get those as well, so that you stay in sync with them. Should you do the same as above but iptrunk<->ipfix? Or can you push from iptrunk like this? cd /iptrunk bzr pull # from lp/upstream bzr push ../iptrunk Is this correct? That would be nice, in that it would cleanly (for my mind) split the roles into: 1. cd /iptrunk: all things that involve communicating with launchpad, including sending local changes from ipfix, retrieving upstream changes and pushing them to ipfix 2. cd /ipfix: all things that involve committing local work but do not touch the 'outside world'. Thanks f From fperez.net at gmail.com Wed Jun 4 11:03:37 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 08:03:37 -0700 Subject: [IPython-dev] broken link on download page In-Reply-To: <200806040912.17653.darren.dale@cornell.edu> References: <200806040912.17653.darren.dale@cornell.edu> Message-ID: On Wed, Jun 4, 2008 at 6:12 AM, Darren Dale wrote: > The "this section" link in the windows section of the download page is > broken, and the page is immutable so I can't fix it myself. Now you can, I added you to the editors group :) Cheers, f From vivainio at gmail.com Wed Jun 4 11:09:13 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 18:09:13 +0300 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> Message-ID: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> On Wed, Jun 4, 2008 at 5:53 PM, Fernando Perez wrote: > What is the correct mechanism for getting the trunk changes that come > from other developer into ipfix? Because at some point you still need > to make sure you get those as well, so that you stay in sync with > them. Should you do the same as above but iptrunk<->ipfix? Or can > you push from iptrunk like this? > > cd /iptrunk > bzr pull # from lp/upstream > bzr push ../iptrunk No, there is no point in doing both push and pull because both operations make the repositories equal. After pulling, you can just delete your ipfix branch and create a new branch when you intend to do a change. Let's assume that you start up by NOT having an ipfix branch. You commit the changes directly to iptrunk branch, and attempt to push them: cd /iptrunk hack hack hack bzr ci bzr push BRANCHES HAVE DIVERGED error Now, you need to get the changes from others, so you create the ipfix branch and get a pristine, most recent version of trunk: cd / mv iptrunk ipfix bzr branch lp:ipython iptrunk cd iptrunk bzr merge ../ipfix bzr ci bzr push <== now, this will succeed. The important thing is to minimize the amount of merging, and generally not merge stuff from others - just merge stuff to trunk, not the other way around. Of course you *can* merge stuff from others if you need to, but don't make it a habit "just to be sure". -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Wed Jun 4 11:13:14 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 08:13:14 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 8:09 AM, Ville M. Vainio wrote: > On Wed, Jun 4, 2008 at 5:53 PM, Fernando Perez wrote: > >> What is the correct mechanism for getting the trunk changes that come >> from other developer into ipfix? Because at some point you still need >> to make sure you get those as well, so that you stay in sync with >> them. Should you do the same as above but iptrunk<->ipfix? Or can >> you push from iptrunk like this? >> >> cd /iptrunk >> bzr pull # from lp/upstream >> bzr push ../iptrunk > > No, there is no point in doing both push and pull because both > operations make the repositories equal. > > After pulling, you can just delete your ipfix branch and create a new > branch when you intend to do a change. Mmh, what if you have stuff in your local copy that you're playing with still but not quite ready to commit? I'm not sure I like the idea that the local branch must be immediately gone after each commit. It seems to me that the iptrunk branch should be pretty 'pure' from local work, but I do want a more long-lived area for local work. Or is this just 'going against the grain' of bzr workflow? Cheers, f From ellisonbg.net at gmail.com Wed Jun 4 11:22:56 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 4 Jun 2008 09:22:56 -0600 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> Message-ID: <6ce0ac130806040822h381cc4berf86c6fbd75de2831@mail.gmail.com> > Mmh, what if you have stuff in your local copy that you're playing > with still but not quite ready to commit? I'm not sure I like the > idea that the local branch must be immediately gone after each commit. > It seems to me that the iptrunk branch should be pretty 'pure' from > local work, but I do want a more long-lived area for local work. Or > is this just 'going against the grain' of bzr workflow? I hope not because that is (in my mind) one of the main reasons to use a distributed vcs. Brian > > 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 Wed Jun 4 11:25:00 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 18:25:00 +0300 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> Message-ID: <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> On Wed, Jun 4, 2008 at 6:13 PM, Fernando Perez wrote: > Mmh, what if you have stuff in your local copy that you're playing > with still but not quite ready to commit? I'm not sure I like the > idea that the local branch must be immediately gone after each commit. > It seems to me that the iptrunk branch should be pretty 'pure' from > local work, but I do want a more long-lived area for local work. Or > is this just 'going against the grain' of bzr workflow? For long-lived work you should have a separate "feature branch", e.g. "twisted-exp". Not "fernandos-stuff" where you routinely do all the local stuff and keep merging to it all the time. It's quite ok to merge stuff to your feature branches if it's a long-term undertaking, but for short lived fixes it's an unnecessary complication and should not be done "just to see if your stuff works with the new stuff". To test your branch against the latest codes, run the tests in trunk after "bzr merge ../ipfix", before commit. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Wed Jun 4 11:38:08 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 08:38:08 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 8:25 AM, Ville M. Vainio wrote: > On Wed, Jun 4, 2008 at 6:13 PM, Fernando Perez wrote: > >> Mmh, what if you have stuff in your local copy that you're playing >> with still but not quite ready to commit? I'm not sure I like the >> idea that the local branch must be immediately gone after each commit. >> It seems to me that the iptrunk branch should be pretty 'pure' from >> local work, but I do want a more long-lived area for local work. Or >> is this just 'going against the grain' of bzr workflow? > > For long-lived work you should have a separate "feature branch", e.g. > "twisted-exp". Not "fernandos-stuff" where you routinely do all the > local stuff and keep merging to it all the time. > > It's quite ok to merge stuff to your feature branches if it's a > long-term undertaking, but for short lived fixes it's an unnecessary > complication and should not be done "just to see if your stuff works > with the new stuff". To test your branch against the latest codes, run > the tests in trunk after "bzr merge ../ipfix", before commit. But then how are those 'long lived' feature branches different? If we do merge into them, we're back to the history folding problem, no? If we don't merge into them, they diverge... Basically (as Brian said) a basic feature of DVCS seems to be precisely the ability to keep long (or short)-lived lines of work that track the trunk and where experimental work happens, merging nilly-willy the pieces that make sense and without having to worry about the history. Having to make a distinction between long and short lived branches in terms of workflow for this point sounds weird. I'm not saying there's no use for one-off branches, they're fine on their own. But I don't want to be constrained to that being the only way to merge into trunk, that does feel unduly limiting... cheers, f From vivainio at gmail.com Wed Jun 4 11:44:04 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 18:44:04 +0300 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> Message-ID: <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> On Wed, Jun 4, 2008 at 6:38 PM, Fernando Perez wrote: > But then how are those 'long lived' feature branches different? If we > do merge into them, we're back to the history folding problem, no? If > we don't merge into them, they diverge... There is no history folding problem if you merge to trunk, then push trunk (as opposed to merging to your feature branch and then pushing it over the trunk). > about the history. Having to make a distinction between long and > short lived branches in terms of workflow for this point sounds weird. The point is that you should not merge "by habit", as in "I must always merge to myself before I publish changes". It only complicates the history, without helping anybody... and is just a habit acquired by having to do "svn up" before checkin. > their own. But I don't want to be constrained to that being the only > way to merge into trunk, that does feel unduly limiting... Yes, of course if you think you want/need to do it, by all means do it. It's just good to know you don't have to do it because "it's a good process" or anything like that. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Wed Jun 4 11:55:00 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 4 Jun 2008 18:55:00 +0300 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> Message-ID: <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> On Wed, Jun 4, 2008 at 6:44 PM, Ville M. Vainio wrote: > There is no history folding problem if you merge to trunk, then push > trunk (as opposed to merging to your feature branch and then pushing > it over the trunk). Just to emphasize this: you might use the golden rule that unless you pulled a non-private branch less than one hour ago, do not push that branch. This avoids nuking valuable history entries with "merged from trunk" entries. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Wed Jun 4 12:46:15 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 09:46:15 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 8:55 AM, Ville M. Vainio wrote: > On Wed, Jun 4, 2008 at 6:44 PM, Ville M. Vainio wrote: > >> There is no history folding problem if you merge to trunk, then push >> trunk (as opposed to merging to your feature branch and then pushing >> it over the trunk). > > Just to emphasize this: you might use the golden rule that unless you > pulled a non-private branch less than one hour ago, do not push that > branch. This avoids nuking valuable history entries with "merged from > trunk" entries. OK, thanks for all the feedback on bzr. I'll try to make a little cheat sheet from this discussion and see how it goes. Ultimately we might send that info back to the bzr team for their docs. I feel their 'Workflows' pages and sections of the guide are woefully insufficient in critical details (like a number of things you've clarified here). Cheers, f From stefan at sun.ac.za Wed Jun 4 15:44:37 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 4 Jun 2008 21:44:37 +0200 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> Message-ID: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> 2008/6/4 Fernando Perez : > OK, thanks for all the feedback on bzr. I'll try to make a little > cheat sheet from this discussion and see how it goes. Ultimately we > might send that info back to the bzr team for their docs. I feel > their 'Workflows' pages and sections of the guide are woefully > insufficient in critical details (like a number of things you've > clarified here). I like bzr a lot, but it scares me that we need a cheat sheet to achieve something so simple. Please do provide this feedback to the bzr list or #bzr on freenode.net; I would very much like to know what they have to say. Cheers St?fan From ellisonbg.net at gmail.com Wed Jun 4 16:04:31 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 4 Jun 2008 14:04:31 -0600 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> References: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> Message-ID: <6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com> So.... I have a branch of ipython1-dev (ipython1-fc) that I want to merge back into ipython1-dev. Previously, I had been doing a simple push from my local ipython1-fc to ipython1-dev. But, what is the best way (after all this discussion) of doing the merge that will get the history right? Brian On Wed, Jun 4, 2008 at 1:44 PM, St?fan van der Walt wrote: > 2008/6/4 Fernando Perez : >> OK, thanks for all the feedback on bzr. I'll try to make a little >> cheat sheet from this discussion and see how it goes. Ultimately we >> might send that info back to the bzr team for their docs. I feel >> their 'Workflows' pages and sections of the guide are woefully >> insufficient in critical details (like a number of things you've >> clarified here). > > I like bzr a lot, but it scares me that we need a cheat sheet to > achieve something so simple. Please do provide this feedback to the > bzr list or #bzr on freenode.net; I would very much like to know what > they have to say. > > Cheers > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From barrywark at gmail.com Wed Jun 4 16:43:22 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 4 Jun 2008 13:43:22 -0700 Subject: [IPython-dev] ipython on google app engine In-Reply-To: References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com> <6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com> <6ce0ac130805280754m51475f8ai39dec8e145fd385c@mail.gmail.com> Message-ID: On Sat, May 31, 2008 at 7:17 PM, Fernando Perez wrote: > On Wed, May 28, 2008 at 7:54 AM, Brian Granger wrote: > >> I don't think there is anyway of monitoring the user's namespace for >> changes. But, I can think of a couple different approaches that might >> work: > > > Actually there is, to some extent. The execution user_ns can be a > dict-like object whose methods fire notifications onto listeners. One > can't detect *all* changes (such as in-place modifications of deeply > nested mutable objects), but at least one can detect all variable > reads (__getitem__), new variables (__setitem__) and deletions > (__del__). That's exactly what I was thinking. I know it's not perfect, but as a hint to the frontend, would be very useful. > > Just a side note... > > Cheers, > > f > From fperez.net at gmail.com Wed Jun 4 16:53:49 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 4 Jun 2008 13:53:49 -0700 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> References: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 12:44 PM, St?fan van der Walt wrote: > 2008/6/4 Fernando Perez : >> OK, thanks for all the feedback on bzr. I'll try to make a little >> cheat sheet from this discussion and see how it goes. Ultimately we >> might send that info back to the bzr team for their docs. I feel >> their 'Workflows' pages and sections of the guide are woefully >> insufficient in critical details (like a number of things you've >> clarified here). > > I like bzr a lot, but it scares me that we need a cheat sheet to > achieve something so simple. Please do provide this feedback to the > bzr list or #bzr on freenode.net; I would very much like to know what > they have to say. I've now gone under in swamp mode, but it does worry me too. Thanks for your offer to look into this further! Cheers, f From cournapeau at cslab.kecl.ntt.co.jp Wed Jun 4 22:45:33 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Thu, 05 Jun 2008 11:45:33 +0900 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: References: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com> Message-ID: <1212633933.13915.32.camel@bbc8> On Wed, 2008-06-04 at 07:53 -0700, Fernando Perez wrote: > > Ah, OK. I got confused by the post that said that 'merge --pull' was > the way to 'fast forward' the history, and was using that. You should avoid using this with bzr. I think using it comes from people used to git, and it does not work well with bzr (it leads to those problems you are having with history "folding"). You may like the git's way better, but forcing bzr in git mode is bad. It is like using vim mode in emacs. Possible, but weird. About pull vs merge: https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html This is important to understand well to avoid the problem you got, I think. I find the article you posted typical of someone used to git and do not understand why bzr is different. FWIW, you can get git's log with the --short/--line option (as mentioned above, bzr --short --forward is nice, it is the default on my computer too). About bzr vs other tools, I think it is easy to see problems when using one program, and not seeing the ones brought by another, not used yet, one. Using git effectively wrt history is not trivial either, there would have been the same kind of discussion I believe (on different points, obviously: but rebase is not so easy to understand either). I really believe bzr has its advantages here (as well as its problems too, obviously). Hope the above helps, David From cournapeau at cslab.kecl.ntt.co.jp Wed Jun 4 22:59:38 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Thu, 05 Jun 2008 11:59:38 +0900 Subject: [IPython-dev] bzr - what am I doing wrong? In-Reply-To: <6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com> References: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com> <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com> <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com> <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com> <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com> <6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com> Message-ID: <1212634779.13915.42.camel@bbc8> On Wed, 2008-06-04 at 14:04 -0600, Brian Granger wrote: > So.... > > I have a branch of ipython1-dev (ipython1-fc) that I want to merge > back into ipython1-dev. Previously, I had been doing a simple push > from my local ipython1-fc to ipython1-dev. But, what is the best way > (after all this discussion) of doing the merge that will get the > history right? The easy way I think it to always keep a mirror of the branch you intend to commit to (ipython1-dev here): bzr branch lp:ipython1-dev bzr branch ipython1-dev mybranch # Hack into mybranch When you feel like publishing your changes: cd ipython-dev bzr pull (to be up-to-date) bzr merge ../mybranch bzr ci -m "Summary of the merged branch work" Then, you avoid this folding issue I believe: you keep the mainline as a reference, and do your work in another branch. David From cournapeau at cslab.kecl.ntt.co.jp Thu Jun 5 01:27:48 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Thu, 05 Jun 2008 14:27:48 +0900 Subject: [IPython-dev] Bzr merge idiosyncracies... In-Reply-To: References: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com> Message-ID: <1212643668.13915.53.camel@bbc8> On Tue, 2008-06-03 at 19:01 -0700, Fernando Perez wrote: > > I can't believe that this is actually something that bazaar considers > a 'feature' and they promote as a valid design point. The fact that > you've merged someone else's work into your branch because you happen > to be a maintainer, for example, doesn't make their work in any way > 'second class'. I agree 100% percent with Linus here (post linked to > in the vcscompare post): > > http://www.gelato.unsw.edu.au/archives/git/0611/31361.html > > To see a good explanation why it is a design feature of bzr, you can follow this discussion: https://lists.ubuntu.com/archives/bazaar/2008q1/039144.html Again, both POV are definitely valid, and have their strong points/weaknesses. But bzr's workflow here has *some* advantages, and the above definitely *is* a feature. I am not saying it is important for ipython, I don't know honestly; if people run things from "trunk", it may be. I can definitely see this as a good feature in numpy, where many people do build from trunk I believe. > > I await enlightenment... > I hope it explains why bzr is the way it is at least. Maybe it was not the best choice for ipython, I honestly don't know; git speed and toolbox design is really nice for a unix-inclined guy like me. But the point is that any DVCS is really much better than svn. I can't wait to ditch svn for other projects linked to ipython :) cheers, David From jorgen.stenarson at bostream.nu Thu Jun 5 15:37:21 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 05 Jun 2008 21:37:21 +0200 Subject: [IPython-dev] Quick launchpad guide for would-be contributors In-Reply-To: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com> References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com> <4845A3DF.60504@bostream.nu> <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com> <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com> Message-ID: <48484071.6060407@bostream.nu> Ville M. Vainio skrev: > On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio wrote: > >> I'll try to get pyreadline imported to launchpad, stay tuned. > > Of course we are having the same problem as with ipython. See my import request: > > https://answers.launchpad.net/launchpad-bazaar/+question/24416 > > I assume they can sort this out shortly. > nothing has happend yet. Looks like another try is scheduled for tomorrow. With the showmedo-guide you linked and some googling I got it to work. I have been able to get pyreadline from svn to my computer. But I have been unable to merge to a branch from launchpad. I'm off to a conference for a week now. Will be back June 16. Hopefully launchpad has been able to import by then. /J?rgen C:\python\launchpad\pyreadline-trunk>bzr merge ../pyreadline-svnrepo/trunk bzr: ERROR: Repository KnitPackRepository('file:///C:/python/launchpad/pyreadlin e-trunk/.bzr/repository/') is not compatible with repository KnitPackRepository( 'file:///C:/python/launchpad/pyreadline-svnrepo/.bzr/repository/') C:\python\launchpad\pyreadline-trunk>bzr info Standalone tree (format: pack-0.92) Location: branch root: . Related branches: submit branch: C:/python/launchpad/pyreadline-svnrepo/trunk From jdh2358 at gmail.com Thu Jun 5 18:30:03 2008 From: jdh2358 at gmail.com (John Hunter) Date: Thu, 5 Jun 2008 17:30:03 -0500 Subject: [IPython-dev] cd a little hyper Message-ID: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> To due a readline bug on solaris, cd ~/somedTAB used to insert extra white space after completing directories, which was a major headache when navigating deeply nested directories since I had to backspace after every directory completion. Using the latest ipython rom bzr, this appears to be fixed. I don't know how it was fixed, but it is great. (thanks). But I notice a new buglet. If I am cd-ing into a dir which has a bunch of files and one other dir, cd will take me one level too deep. Eg, I want to cd into "api":: In [18]: !ls -laF /home/titan/johnh/mpl/examples/api/ total 144 drwx------ 3 johnh research 1024 Jun 5 17:21 ./ drwxr----- 13 johnh research 16896 Jun 3 15:55 ../ drwx------ 6 johnh research 512 Jun 5 17:23 .svn/ -rw------- 1 johnh research 1780 Jun 3 15:54 README.txt -rw------- 1 johnh research 400 Jun 3 15:54 agg_oo.py ..snipsnip (lots more plain files but .svn is the only subdir) Now when I do:: In [19]: cd /home/titan/johnh/mpl/examples/ap I get the following completion:: In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/ Ie, it puts me one directory too deep. Any ideas? JDH In [19]: import IPython In [20]: IPython.__version__ Out[20]: '0.8.4' In [21]: !uname -a SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc From fperez.net at gmail.com Thu Jun 5 19:54:55 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 5 Jun 2008 16:54:55 -0700 Subject: [IPython-dev] cd a little hyper In-Reply-To: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 3:30 PM, John Hunter wrote: > To due a readline bug on solaris, cd ~/somedTAB used to insert extra > white space after completing directories, which was a major headache > when navigating deeply nested directories since I had to backspace > after every directory completion. Using the latest ipython rom bzr, > this appears to be fixed. I don't know how it was fixed, but it is > great. (thanks). > > But I notice a new buglet. If I am cd-ing into a dir which has a > bunch of files and one other dir, cd will take me one level too deep. > Eg, I want to cd into "api":: > > In [18]: !ls -laF /home/titan/johnh/mpl/examples/api/ > total 144 > drwx------ 3 johnh research 1024 Jun 5 17:21 ./ > drwxr----- 13 johnh research 16896 Jun 3 15:55 ../ > drwx------ 6 johnh research 512 Jun 5 17:23 .svn/ > -rw------- 1 johnh research 1780 Jun 3 15:54 README.txt > -rw------- 1 johnh research 400 Jun 3 15:54 agg_oo.py > ..snipsnip (lots more plain files but .svn is the only subdir) > > Now when I do:: > > In [19]: cd /home/titan/johnh/mpl/examples/ap > > I get the following completion:: > > In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/ > > Ie, it puts me one directory too deep. > > Any ideas? > JDH > In [19]: import IPython > > In [20]: IPython.__version__ > Out[20]: '0.8.4' > > In [21]: !uname -a > SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc Mhh, I don't see that here. Could you let me know if you see this on BIC? Cheers, f From jdh2358 at gmail.com Thu Jun 5 22:03:36 2008 From: jdh2358 at gmail.com (John Hunter) Date: Thu, 5 Jun 2008 21:03:36 -0500 Subject: [IPython-dev] cd a little hyper In-Reply-To: References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> Message-ID: <88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com> On Thu, Jun 5, 2008 at 6:54 PM, Fernando Perez wrote: >> In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/ > Mhh, I don't see that here. Could you let me know if you see this on BIC? Nope, in the same dir on bic I don't see it. The .svn subdir doesn't show up at all in the completion list, as it shouldn't. Maybe they "upgraded" readline at work or something, hard to say. But the current behavior is still loads better than the old and is not worth expending any effort trying to resolve. i thought maybe it was an ipython change. JDH From fperez.net at gmail.com Thu Jun 5 23:00:18 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 5 Jun 2008 20:00:18 -0700 Subject: [IPython-dev] cd a little hyper In-Reply-To: <88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 7:03 PM, John Hunter wrote: > On Thu, Jun 5, 2008 at 6:54 PM, Fernando Perez wrote: > >>> In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/ >> Mhh, I don't see that here. Could you let me know if you see this on BIC? > > Nope, in the same dir on bic I don't see it. The .svn subdir doesn't > show up at all in the completion list, as it shouldn't. Maybe they > "upgraded" readline at work or something, hard to say. But the > current behavior is still loads better than the old and is not worth > expending any effort trying to resolve. i thought maybe it was an > ipython change. None that I can think of. If it drives you nuts we can look into it further. Cheers, f From vivainio at gmail.com Fri Jun 6 00:41:48 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 6 Jun 2008 07:41:48 +0300 Subject: [IPython-dev] cd a little hyper In-Reply-To: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> Message-ID: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> On Fri, Jun 6, 2008 at 1:30 AM, John Hunter wrote: > To due a readline bug on solaris, cd ~/somedTAB used to insert extra > white space after completing directories, which was a major headache > when navigating deeply nested directories since I had to backspace > after every directory completion. Using the latest ipython rom bzr, > this appears to be fixed. I don't know how it was fixed, but it is > great. (thanks). Yes, I fixed that by introducing the pseudo-annoying behaviour you mention (I noticed the same thing on linux + scratchbox). It's the single_dir_expand call in ipy_completers.py (cd completer) Perhaps we should "special case" the .svn / dot-something thing. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From jdh2358 at gmail.com Fri Jun 6 01:05:05 2008 From: jdh2358 at gmail.com (John Hunter) Date: Fri, 6 Jun 2008 00:05:05 -0500 Subject: [IPython-dev] cd a little hyper In-Reply-To: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> Message-ID: <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com> On Thu, Jun 5, 2008 at 11:41 PM, Ville M. Vainio wrote: > On Fri, Jun 6, 2008 at 1:30 AM, John Hunter wrote: > >> To due a readline bug on solaris, cd ~/somedTAB used to insert extra >> white space after completing directories, which was a major headache >> when navigating deeply nested directories since I had to backspace >> after every directory completion. Using the latest ipython rom bzr, >> this appears to be fixed. I don't know how it was fixed, but it is >> great. (thanks). > > Yes, I fixed that by introducing the pseudo-annoying behaviour you > mention (I noticed the same thing on linux + scratchbox). It's the > single_dir_expand call in ipy_completers.py (cd completer) > > Perhaps we should "special case" the .svn / dot-something thing. Oh, I see. I initially thought I wasn't seeing it on bic (fernando's linux machine on which I have an acct) because I wasn't using a recent bzr ipython there. After I did an update to:: > bzr branch lp:ipython I see the same behavior as I described on my work machine. I don't think this is the behavior you want. *Certainly* you do not want to be completing on hidden dirs unless a user has explicitly requested to do so in your rc file (regardless of whether it is a ".svn" hidden dir). But I don't think you want to (by default) complete on single dirs either, at least not if other nondir files are around. Eg, if as in the original post, I have something like:: In [3]: !mkdir -p somedir/subdir1 In [4]: !touch somedir/file1 In [5]: !touch somedir/file2 In [6]: cd somedi we do not want to go to somedir/subdir1 by default (unless it is an rc choice) because somedir is a perfectly reasonable place to go. On the bzr HEAD (what do you call HEAD in bzr?) I am being taken to subdir1. Ie, In [6]: cd some takes me to:: In [6]: cd somedir/subdir1 /home/jdhunter/somedir/subdir1 Now in the case of somedir containing only a *single* non-hidden dir and *no* plain files, I think the current hyper-completion is a feature. But if there are files and/or dirs in the target dir, I don't think you want to assume a subdir for completion. But many thanks for fixing my trailing space completion bug, however you did it. JDH From jdh2358 at gmail.com Fri Jun 6 01:38:39 2008 From: jdh2358 at gmail.com (John Hunter) Date: Fri, 6 Jun 2008 00:38:39 -0500 Subject: [IPython-dev] cd a little hyper In-Reply-To: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> Message-ID: <88e473830806052238o560cf60aw56d8030a9d2fb4e6@mail.gmail.com> On Thu, Jun 5, 2008 at 11:41 PM, Ville M. Vainio wrote: > Yes, I fixed that by introducing the pseudo-annoying behaviour you > mention (I noticed the same thing on linux + scratchbox). It's the > single_dir_expand call in ipy_completers.py (cd completer) If you are working on completions, here are some features I think would be great: * for 'run' or 'ls' or 'cat' completions, complete only on files, not local python namespaces. Eg, in pylab mode, the localname "hist" is defined in mpl and "histogram", "histogram2d" and "histogramdd" are defined in numpy. But when I do an an "ls" completion on the mpl/examples/hist directory, I want to see the mpl histogram examples. If I expilcitly ask for them, all is well:: In [3]: ls /home/jdhunter/mpl/examples/pylab_examples/hist* /home/jdhunter/mpl/examples/pylab_examples/hist_colormapped.py /home/jdhunter/mpl/examples/pylab_examples/histogram_demo_extended.py /home/jdhunter/mpl/examples/pylab_examples/histogram_demo.py But if I cd into that dir, and do an 'ls hist' In [6]: cd /home/jdhunter/mpl/examples/pylab_examples /home/jdhunter/mpl/examples/pylab_examples In [7]: ls hist hist histogramdd hist_colormapped.py histogram_demo_extended.py histogram histogram_demo.py histogram2d I get files in that dir *and* names in the local namespace. Interestingly, if I cd back to home and give the full path on to "ls" followed by TAB, I get the desired behavior: In [8]: cd /home/jdhunter In [9]: ls mpl/examples/pylab_examples/hist mpl/examples/pylab_examples/hist_colormapped.py mpl/examples/pylab_examples/histogram_demo_extended.py mpl/examples/pylab_examples/histogram_demo.py However, 'run' is working as expected, usggesting this may be an easy fix:: In [14]: cd mpl/examples/pylab_examples/ In [15]: run hist hist_colormapped.py histogram_demo.py histogram_demo_extended.py though 'ls' is not (as before):: In [15]: ls hist hist histogramdd hist_colormapped.py histogram_demo_extended.py histogram histogram_demo.py histogram2d nor is 'cat', which seems to suffer the same problem as 'ls' Thats all for now! JDH From vivainio at gmail.com Fri Jun 6 02:55:03 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Fri, 6 Jun 2008 09:55:03 +0300 Subject: [IPython-dev] cd a little hyper In-Reply-To: <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com> Message-ID: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com> On Fri, Jun 6, 2008 at 8:05 AM, John Hunter wrote: > Now in the case of somedir containing only a *single* non-hidden dir > and *no* plain files, I think the current hyper-completion is a > feature. But if there are files and/or dirs in the target dir, I > don't think you want to assume a subdir for completion. I agree that it's not desirable. However, it was a compromise to get this bug fixed. Perhaps I'll add an option for this, so that it will only be a workaround for those who have the buggy readline. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Fri Jun 6 12:40:23 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 6 Jun 2008 09:40:23 -0700 Subject: [IPython-dev] cd a little hyper In-Reply-To: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com> <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 11:55 PM, Ville M. Vainio wrote: > On Fri, Jun 6, 2008 at 8:05 AM, John Hunter wrote: > >> Now in the case of somedir containing only a *single* non-hidden dir >> and *no* plain files, I think the current hyper-completion is a >> feature. But if there are files and/or dirs in the target dir, I >> don't think you want to assume a subdir for completion. > > I agree that it's not desirable. However, it was a compromise to get > this bug fixed. > > Perhaps I'll add an option for this, so that it will only be a > workaround for those who have the buggy readline. Just here to mention that I saw you seem to have just committed a fix into bzr, so John (or anyone else) can update from bzr and report if they still see any problems. Regards, f From ellisonbg.net at gmail.com Fri Jun 6 13:22:07 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 6 Jun 2008 11:22:07 -0600 Subject: [IPython-dev] How do I do this in bzr? (again) Message-ID: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com> 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? Thanks Brian From ellisonbg.net at gmail.com Fri Jun 6 16:11:08 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 6 Jun 2008 14:11:08 -0600 Subject: [IPython-dev] The merge has begun... Message-ID: <6ce0ac130806061311k422e58fel67cae0996fd912b9@mail.gmail.com> Hi, I have created a ipython-ipython1a branch as the first ("a") branch that is being used to merge ipython1-dev into IPython. I wanted to keep people posted on what exactly I am doing. I am hoping that there will be a series of branches with names like ipython-ipython1a, ipython-ipython1b, etc. Each of these will be used to merge new things from ipython1-dev into IPython. https://code.launchpad.net/~ipython/ipython/ipython-ipython1a Here is what is going on in ipython-ipython1a: 1) Moved the following by hand ipython1.config -> IPython.config ipython1.kernel -> IPython.kernel ipython1.external/* -> IPython.external/* (removing repetitions) ipython1.core -> IPython.kernel.core ipython1.testutils -> IPython.testing ipython1.tools -> IPython.tools 2) Moved IPython.tools.guid -> IPython1.external.guid 3) Renamed: ipython1 -> IPython IPython.core -> IPython.kernel.core IPython.testutils -> IPython.testing These subpackages that have been moved into IPython are relatively stable and well tested and will immediately give IPython all of the parallel computing capabilties of IPython1. The next things I am going to do in this branch is get the setup.py script (and friends into good condition). This is the only thing that is a little scary, as I will be doing quite a bit of refactoring. When I am done with this and ready to merge back into the mainline ipython branch, I will let people know and request lots of testing. After I get these things done, I will merge into ipython and then make a new branch to begin cleaning up other things. Next on my scopes: 1) Merge the documentation for the two projects. 2) Clean up and merge other misc things like COPYRIGHT, etc. IMPORTANT: I am not going to touch, reorganize or refactor any of the "old" stuff in the ipython branch. I don't know this codebase well and I will leave that to other who know that stuff well. My goal is to get things from ipython1 -> ipython as quickly as possible to end this transition. The truly curious, can subscribe to this branch and follow what I am doing. Cheers, Brian From vivian at vdesmedt.com Sat Jun 7 03:32:06 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Sat, 07 Jun 2008 09:32:06 +0200 Subject: [IPython-dev] Synchronization with Editor In-Reply-To: References: <484553B1.9020405@vdesmedt.com> Message-ID: <484A3976.5040207@vdesmedt.com> Dear All, Just to tell you that I just push my "synchronize-editor" branch. Again for the one that don't know the purpose of this submission the goal of it is to let you ask to IPython to synchronize itself with an external editor. If the hook is set: * When IPython raise an uncaught exception the hook synchronize the external editor to the line IPython highlight * When IPython navigate through the stack in debug mode the hook synchronize the external editor to highlight the corresponding part of the code. To set the hook just import the corresponding ip_synchronize_with_xxx extension in your ip_user.conf file. I have developed six hooks for six different editors: * Scite (ip_synchronize_with_scite.py) * GVim (ip_synchronize_with_gvim.py) * Emacs (ip_synchronize_with_emacs.py) * Notepad++ (ip_synchronize_with_nppp.py) * PsPad (ip_synchronize_with_pspad.py) * UltraEdit (ip_synchronize_with_ue.py) The hook are developed on the Windows platform and some of they code is specific to that platform. In particular the small part of the code that give back the focus to the console after the synchronization with the editor took place but it should be possible to adapt it for Linux. I don't have a Linux box and I'm not in the best position to make it but I'll be glad to help. Please tell me what you think of this proposition. Regards, Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vds at aisystems.be Sat Jun 7 04:40:02 2008 From: vds at aisystems.be (Vivian De Smedt) Date: Sat, 07 Jun 2008 10:40:02 +0200 Subject: [IPython-dev] pyreadline and Tab insertion Message-ID: <484A4962.5050606@aisystems.be> 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. Here is the corresponding section ipythonrc.ini #readline_parse_and_bind tab: complete #readline_parse_and_bind tab: menu-complete readline_parse_and_bind tab: tab-insert readline_parse_and_bind Control-space: complete The completion part of that configuration works well but if I hit the tab touch I get a traceback in IPython basically because tabstop and line_cursor are not defined. C:>ipython In [1]: Readline internal error Traceback (most recent call last): File "C:\Python25\lib\site-packages\pyreadline\console\console.py", line 671, in hook_wrapper_23 res = ensure_str(readline_hook(prompt)) File "C:\Python25\lib\site-packages\pyreadline\rlmain.py", line 342, in readli ne return self.mode.readline(prompt) File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 133, in r eadline self._readline_from_keyboard() File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 90, in _r eadline_from_keyboard r = dispatch_func(event) File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 289, in t ab_insert ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop)) AttributeError: 'EmacsMode' object has no attribute 'line_cursor' To address the problem I have define a default for tabstop in rlmain.Readline: class Readline(object): def __init__(self): self.startup_hook = None self.pre_input_hook = None self.completer = None self.completer_delims = " \t\n\"\\'`@$><=;|&{(" self.console = console.Console() self.size = self.console.size() self.prompt_color = None self.command_color = None self.selection_color = self.console.saveattr<<4 self.key_dispatch = {} self.previous_func = None self.first_prompt = True self.next_meta = False # True to force meta on next character self.tabstop = 4 self.allow_ctrl_c=False self.ctrl_c_tap_time_interval=0.3 self.debug=False And slightly change the emacs and notemacs modes: class EmacsMode(basemode.BaseMode): ... def tab_insert(self, e): # (M-TAB) '''Insert a tab character. ''' line_cursor = len(self.l_buffer) ws = ' ' * (self.tabstop - (line_cursor%self.tabstop)) #ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop)) self.insert_text(ws) class NotEmacsMode(basemode.BaseMode): ... def tab_insert(self, e): # (M-TAB) '''Insert a tab character. ''' line_cursor = len(self.l_buffer) ws = ' ' * (self.tabstop - (line_cursor%self.tabstop)) #ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop)) self.insert_text(ws) Please tell if you think about these propositions of changes. Regards, Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vds at aisystems.be Mon Jun 9 09:25:45 2008 From: vds at aisystems.be (Vivian De Smedt) Date: Mon, 09 Jun 2008 15:25:45 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <200806091242.47835.meine@informatik.uni-hamburg.de> References: <484A4962.5050606@aisystems.be> <200806091242.47835.meine@informatik.uni-hamburg.de> Message-ID: <484D2F59.9080206@aisystems.be> Hans, I'll be glad to send you a patch but I don't know from which version control system. I understand from your mail that Bazaar is the one I should care about. But when I try: bzr branch lp:pyreadline I get: Connected (version 2.0, client Twisted) Authentication (publickey) successful! Secsh channel 1 opened. bzr: ERROR: Not a branch: "bzr+ssh://vivian-vdesmedt at bazaar.launchpad.net/~pyrea dline/pyreadline/trunk/". What do you think I should do. Regards, Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Mon Jun 9 09:28:19 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Mon, 9 Jun 2008 15:28:19 +0200 Subject: [IPython-dev] man page errors Message-ID: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com> Hi, while packaging 0.8.4 for Debian, we run into this minor problem with the manpage: $ man --warnings -l doc/ipython.1.gz > /dev/null :55: warning: `wxversion'' not defined :116: warning: `str(43)'' not defined :223: warning: `sh' not defined :234: warning: `snapshot'' not defined One possible way to fix these is attached in the patch. Please apply, or let's discuss how to fix it some other way. The reason is that otherwise we are getting these warnings in Debian: $ lintian ipython_0.8.4-1_i386.changes W: ipython: manpage-has-errors-from-man usr/share/man/man1/ipython.1.gz 55: warning: `wxversion'' not defined All packages should be lintian clean -- but if this is not a bug, we can add a lintian override. Thanks, Ondrej -------------- next part -------------- A non-text attachment was scrubbed... Name: man_fix.patch Type: text/x-patch Size: 1815 bytes Desc: not available URL: From stefan at sun.ac.za Mon Jun 9 10:02:14 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 9 Jun 2008 16:02:14 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <484D2F59.9080206@aisystems.be> References: <484A4962.5050606@aisystems.be> <200806091242.47835.meine@informatik.uni-hamburg.de> <484D2F59.9080206@aisystems.be> Message-ID: <9457e7c80806090702t734e25c6l4096656e89b12fba@mail.gmail.com> Hi Vivian 2008/6/9 Vivian De Smedt : > Hans, > > I'll be glad to send you a patch but I don't know from which version control > system. I understand from your mail that Bazaar is the one I should care > about. > > But when I try: > > bzr branch lp:pyreadline That branch is still empty, for some reason. In the meantime, there is an svn branch here: http://ipython.scipy.org/svn/ipython/pyreadline/trunk Regards St?fan From vds at aisystems.be Mon Jun 9 10:34:59 2008 From: vds at aisystems.be (Vivian De Smedt) Date: Mon, 09 Jun 2008 16:34:59 +0200 Subject: [IPython-dev] pyreadline and Tab insertion In-Reply-To: <200806091624.35935.meine@informatik.uni-hamburg.de> References: <484A4962.5050606@aisystems.be> <200806091242.47835.meine@informatik.uni-hamburg.de> <484D2F59.9080206@aisystems.be> <200806091624.35935.meine@informatik.uni-hamburg.de> Message-ID: <484D3F93.807@aisystems.be> Dear All, Here is my proposition of patch in a diff form. Regards, Vivian. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tab-insertion.patch URL: From vivainio at gmail.com Mon Jun 9 13:09:40 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Mon, 9 Jun 2008 20:09:40 +0300 Subject: [IPython-dev] Synchronization with Editor In-Reply-To: <484A3976.5040207@vdesmedt.com> References: <484553B1.9020405@vdesmedt.com> <484A3976.5040207@vdesmedt.com> Message-ID: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com> On Sat, Jun 7, 2008 at 10:32 AM, Vivian De Smedt wrote: > Dear All, > > Just to tell you that I just push my "synchronize-editor" branch. Thank you, especially for taking the time to create a bzr branch! Makes the process so much cleaner... I have added notes to the whiteboard of the branch on launchpad. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Mon Jun 9 13:43:39 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Mon, 9 Jun 2008 20:43:39 +0300 Subject: [IPython-dev] man page errors In-Reply-To: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com> References: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com> Message-ID: <46cb515a0806091043j4c83d7cbscc4dd9f0287d79a3@mail.gmail.com> On Mon, Jun 9, 2008 at 4:28 PM, Ondrej Certik wrote: > while packaging 0.8.4 for Debian, we run into this minor problem with > the manpage: Thank you, fixed in bzr. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From ondrej at certik.cz Mon Jun 9 14:41:34 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Mon, 9 Jun 2008 20:41:34 +0200 Subject: [IPython-dev] Old 'broken terminal' bug finally fixed In-Reply-To: References: Message-ID: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com> On Sat, Apr 19, 2008 at 12:11 AM, Fernando Perez wrote: > Hi all, > > there's a very old, *extremely* annoying bug that multiple people have > asked about (on list and in person) that is finally just fixed. The > behavior was that at some point during a normal session, after a call > to 'foo?', your terminal would be totally messed up, with no displayed > input. You could (blindly) type !reset to issue the system terminal > reset command, but that would only help until the next time foo? was > called, and the problem would then return. Most of us would end up > just quitting ipython and restarting, often losing useful session > state. > > The problem with this is that we never knew how to reliably reproduce > it... Anyway, it's fixed now in current bzr: Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug indeed goes away in 0.8.4): http://code.google.com/p/sympy/issues/detail?id=822 together with a screenshot how the terminal looks like (see the comment #6 for the exact sympy revision to use). Maybe you could use it to track the bug down in curses, as your patch only seems to be a workaround (albeit working). Ondrej From ellisonbg.net at gmail.com Mon Jun 9 16:10:36 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 9 Jun 2008 14:10:36 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! Message-ID: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> Hello all, I have just merged the ipython-ipython1a branch into ipython trunk. This means that most of the stable stuff from ipython1 is now in IPython. This includes the following new subpackages: IPython.kernel IPython.kernel.core IPython.config IPython.tools The biggest change though is that I have refectored the setup.py script. Because these new subpackages have lots of other dependencies, we needed a nice way of handling these things. Here is a skech of how it is being handled: 1. If setuptools is being used, we declare optional requires for the additional deps 2. If setuptools is not being used, we check for the deps manually and simple tell the user what was found and what is required for what features. While this will likely take some find tuning, it is a start. PLEASE, try out the new setup.py in trunk on various platforms and in various situations. We need to test this well as it is a huge change. But, the bottom line is that IPython trunk now has full parallel computing capabilities. I will also announce on IPython-users Next stop: documentation merge!!! Cheers, Brian From ellisonbg.net at gmail.com Mon Jun 9 16:18:05 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 9 Jun 2008 14:18:05 -0600 Subject: [IPython-dev] ipython1 -> IPython documentation merge about to begin Message-ID: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com> Hello all, I wanted to let all the devs know that I am about to do a major reorganization of the IPython documentation. Part of this will be to merge in the ipython1 documentation. Because of this, I would ask that people stay clear of the doc directory in trunk for a few days. If you have changes in the docs that need to happen please wait for a few days. Feel free to ask me questions if needed. Cheers, Brian From fperez.net at gmail.com Mon Jun 9 18:43:46 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 9 Jun 2008 15:43:46 -0700 Subject: [IPython-dev] ipython1 -> IPython documentation merge about to begin In-Reply-To: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com> References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 1:18 PM, Brian Granger wrote: > Hello all, > > I wanted to let all the devs know that I am about to do a major > reorganization of the IPython documentation. Part of this will be to > merge in the ipython1 documentation. Because of this, I would ask > that people stay clear of the doc directory in trunk for a few days. > If you have changes in the docs that need to happen please wait for a > few days. Feel free to ask me questions if needed. Go for it. While I'm offline for the rest of the week, I'll work on a private branch purely on automatic testing for the old code. So no chance of conflicts. Thanks for the big merge! I'll let you know of any gremlins I may hit. Cheers, f From fperez.net at gmail.com Mon Jun 9 18:44:46 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 9 Jun 2008 15:44:46 -0700 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 1:10 PM, Brian Granger wrote: > Hello all, > PLEASE, try out the new setup.py in trunk on various platforms and in > various situations. We need to test this well as it is a huge change. I will let you know of any problems. Since I'll be offline, any changes I make will happen on a private branch and I'll test the merges locally before any public push. Cheers, f From stefan at sun.ac.za Mon Jun 9 21:26:29 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 10 Jun 2008 03:26:29 +0200 Subject: [IPython-dev] ipython1 -> IPython documentation merge about to begin In-Reply-To: References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com> Message-ID: <9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com> Hey Brian 2008/6/10 Fernando Perez : > On Mon, Jun 9, 2008 at 1:18 PM, Brian Granger wrote: >> Hello all, >> >> I wanted to let all the devs know that I am about to do a major >> reorganization of the IPython documentation. Part of this will be to >> merge in the ipython1 documentation. Because of this, I would ask >> that people stay clear of the doc directory in trunk for a few days. >> If you have changes in the docs that need to happen please wait for a >> few days. Feel free to ask me questions if needed. > > Go for it. While I'm offline for the rest of the week, I'll work on a > private branch purely on automatic testing for the old code. So no > chance of conflicts. I merged the sconfig branch into ipython1b. The tests aren't run automatically at the moment, so do: nosetests -v --with-doctest --doctest-tests IPython.config to make sure everything is OK. I wrote a first implementation of round-tripping, so a person can now: a) Instantiate a new configuration b) Update the configuration from a file c) Modify the configuration d) Dump the configuration back to file The file writing is done using ConfigObj. The one thing I haven't tried yet is to write back to the same file I read from (to see whether comments and structure are preserved). Regards St?fan From ellisonbg.net at gmail.com Mon Jun 9 22:45:22 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 9 Jun 2008 20:45:22 -0600 Subject: [IPython-dev] ipython1 -> IPython documentation merge about to begin In-Reply-To: <9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com> References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com> <9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com> Message-ID: <6ce0ac130806091945s1e94b927m1bb419a4f653a88a@mail.gmail.com> > I merged the sconfig branch into ipython1b. The tests aren't run > automatically at the moment, so do: > > nosetests -v --with-doctest --doctest-tests IPython.config > > to make sure everything is OK. Great! Thanks for doing this. Now I just to find some time to look at this new stuff and begin to use it. > I wrote a first implementation of round-tripping, so a person can now: > > a) Instantiate a new configuration > b) Update the configuration from a file > c) Modify the configuration > d) Dump the configuration back to file This is exactly why going with ConfigObj makes sense for us. I will merge this stuff from ipython-ipython1b into ipython trunk soon. Thanks again Stefan for doing this! Brian > The file writing is done using ConfigObj. The one thing I haven't > tried yet is to write back to the same file I read from (to see > whether comments and structure are preserved). > > Regards > St?fan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From gael.varoquaux at normalesup.org Tue Jun 10 01:51:43 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 10 Jun 2008 07:51:43 +0200 Subject: [IPython-dev] Development on Launchpad, odds and ends In-Reply-To: References: Message-ID: <20080610055143.GB30061@phare.normalesup.org> On Mon, Jun 02, 2008 at 12:27:13AM -0700, Fernando Perez wrote: > IPython0/1 are dead. Long live IPython! ;) I feel I am getting to the battlefield a bit late, but just to give you my gut feeling about this: this feels just right. I think this will help us move forward. Ga?l From fperez.net at gmail.com Tue Jun 10 03:10:23 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 10 Jun 2008 00:10:23 -0700 Subject: [IPython-dev] Old 'broken terminal' bug finally fixed In-Reply-To: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com> References: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 11:41 AM, Ondrej Certik wrote: > Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug > indeed goes away in 0.8.4): > > http://code.google.com/p/sympy/issues/detail?id=822 Thanks! I took the liberty to add your comment to the bug report I'd filed for this at the python tracker: http://bugs.python.org/issue2657 I doubt I'll spend much time myself on it now, but at least they have all the info to reliably reproduce it. That should make it much easier to work on the problem (it was really annoying since we'd never found a reliable way to reproduce it). Regards, f From ondrej at certik.cz Tue Jun 10 04:08:41 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Tue, 10 Jun 2008 10:08:41 +0200 Subject: [IPython-dev] Old 'broken terminal' bug finally fixed In-Reply-To: References: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com> Message-ID: <85b5c3130806100108l25310c32y5b05b6225f2ec967@mail.gmail.com> On Tue, Jun 10, 2008 at 9:10 AM, Fernando Perez wrote: > On Mon, Jun 9, 2008 at 11:41 AM, Ondrej Certik wrote: > >> Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug >> indeed goes away in 0.8.4): >> >> http://code.google.com/p/sympy/issues/detail?id=822 > > Thanks! I took the liberty to add your comment to the bug report I'd > filed for this at the python tracker: > > http://bugs.python.org/issue2657 Thanks. > > I doubt I'll spend much time myself on it now, but at least they have > all the info to reliably reproduce it. That should make it much > easier to work on the problem (it was really annoying since we'd never > found a reliable way to reproduce it). Right. It was extremely annoying, I lost many sessions that way, so I basically stopped using "?". It is very easy to trigger this in sympy (with ipython 0.8.2), so I think it has something to do with unicode printing. Anyway, I don't have time to dig into this either, so I am glad it's finally fixed. Ondrej From jdh2358 at gmail.com Tue Jun 10 12:01:30 2008 From: jdh2358 at gmail.com (John Hunter) Date: Tue, 10 Jun 2008 11:01:30 -0500 Subject: [IPython-dev] pylab executable Message-ID: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com> This came through the mpl feature request tracker (add a "pylab" executable to the bin dir") https://sourceforge.net/tracker/index.php?func=detail&aid=1910613&group_id=80706&atid=560723 SInce this is really an ipython feature request, I'm moving it over here (it is assigned to fer_perez on the mpl tracker). JDH From dfj225 at gmail.com Tue Jun 10 13:02:12 2008 From: dfj225 at gmail.com (Doug Jones) Date: Tue, 10 Jun 2008 13:02:12 -0400 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> Message-ID: <1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com> Hi All, I just gave the newest setup.py a go on my machine and ran into some problems. I've copied its output below. If you need more information, let me know and I will do my best to provide it. Thanks, ~doug python setup.py build ============================================================================ BUILDING IPYTHON python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC 4.1.2 (Gentoo 4.1.2 p1.0.1)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 2.5.0 Foolscap: 0.2.8 OpenSSL: Not found (required if you want security in the parallel computing capabilities) sphinx: 0.3 pygments: 0.10 nose: 0.9.3 pexpect: 2.1 running build running build_py creating build creating build/lib creating build/lib/IPython copying IPython/wildcard.py -> build/lib/IPython copying IPython/deep_reload.py -> build/lib/IPython copying IPython/macro.py -> build/lib/IPython copying IPython/ipapi.py -> build/lib/IPython copying IPython/rlineimpl.py -> build/lib/IPython copying IPython/CrashHandler.py -> build/lib/IPython copying IPython/Shell.py -> build/lib/IPython copying IPython/ultraTB.py -> build/lib/IPython copying IPython/ipmaker.py -> build/lib/IPython copying IPython/upgrade_dir.py -> build/lib/IPython copying IPython/excolors.py -> build/lib/IPython copying IPython/Release.py -> build/lib/IPython copying IPython/demo.py -> build/lib/IPython copying IPython/OutputTrap.py -> build/lib/IPython copying IPython/shadowns.py -> build/lib/IPython copying IPython/__init__.py -> build/lib/IPython copying IPython/ColorANSI.py -> build/lib/IPython copying IPython/platutils_posix.py -> build/lib/IPython copying IPython/strdispatch.py -> build/lib/IPython copying IPython/generics.py -> build/lib/IPython copying IPython/platutils.py -> build/lib/IPython copying IPython/Debugger.py -> build/lib/IPython copying IPython/GnuplotInteractive.py -> build/lib/IPython copying IPython/ipstruct.py -> build/lib/IPython copying IPython/completer.py -> build/lib/IPython copying IPython/FakeModule.py -> build/lib/IPython copying IPython/usage.py -> build/lib/IPython copying IPython/GnuplotRuntime.py -> build/lib/IPython copying IPython/Logger.py -> build/lib/IPython copying IPython/Prompts.py -> build/lib/IPython copying IPython/numutils.py -> build/lib/IPython copying IPython/ConfigLoader.py -> build/lib/IPython copying IPython/platutils_dummy.py -> build/lib/IPython copying IPython/DPyGetOpt.py -> build/lib/IPython copying IPython/platutils_win32.py -> build/lib/IPython copying IPython/background_jobs.py -> build/lib/IPython copying IPython/iplib.py -> build/lib/IPython copying IPython/dtutils.py -> build/lib/IPython copying IPython/prefilter.py -> build/lib/IPython copying IPython/PyColorize.py -> build/lib/IPython copying IPython/twshell.py -> build/lib/IPython copying IPython/history.py -> build/lib/IPython copying IPython/winconsole.py -> build/lib/IPython copying IPython/shellglobals.py -> build/lib/IPython copying IPython/genutils.py -> build/lib/IPython copying IPython/hooks.py -> build/lib/IPython copying IPython/OInspect.py -> build/lib/IPython copying IPython/Magic.py -> build/lib/IPython copying IPython/irunner.py -> build/lib/IPython copying IPython/Gnuplot2.py -> build/lib/IPython copying IPython/Itpl.py -> build/lib/IPython creating build/lib/IPython/config copying IPython/config/api.py -> build/lib/IPython/config copying IPython/config/__init__.py -> build/lib/IPython/config copying IPython/config/cutils.py -> build/lib/IPython/config copying IPython/config/sconfig.py -> build/lib/IPython/config package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) creating build/lib/IPython/config/tests copying IPython/config/tests/simpleconf.py -> build/lib/IPython/config/tests copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests creating build/lib/IPython/Extensions copying IPython/Extensions/ipy_autoreload.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_rehashdir.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_sh.py -> build/lib/IPython/Extensions copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions copying IPython/Extensions/PhysicalQInteractive.py -> build/lib/IPython/Extensions copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_system_conf.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_doctest.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_gnuglobal.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_traits_completer.py -> build/lib/IPython/Extensions copying IPython/Extensions/numeric_formats.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_scipy.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_vimserver.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions copying IPython/Extensions/InterpreterExec.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions copying IPython/Extensions/pspersistence.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions copying IPython/Extensions/PhysicalQInput.py -> build/lib/IPython/Extensions copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_none.py -> build/lib/IPython/Extensions copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_greedycompleter.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_numpy.py -> build/lib/IPython/Extensions copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions copying IPython/Extensions/ext_rescapture.py -> build/lib/IPython/Extensions copying IPython/Extensions/InterpreterPasteInput.py -> build/lib/IPython/Extensions copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_constants.py -> build/lib/IPython/Extensions copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_stock_completers.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_app_completers.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_completers.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_profile_zope.py -> build/lib/IPython/Extensions copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions creating build/lib/IPython/external copying IPython/external/mglob.py -> build/lib/IPython/external copying IPython/external/path.py -> build/lib/IPython/external copying IPython/external/__init__.py -> build/lib/IPython/external copying IPython/external/simplegeneric.py -> build/lib/IPython/external copying IPython/external/validate.py -> build/lib/IPython/external copying IPython/external/configobj.py -> build/lib/IPython/external copying IPython/external/guid.py -> build/lib/IPython/external copying IPython/external/Itpl.py -> build/lib/IPython/external creating build/lib/IPython/gui copying IPython/gui/__init__.py -> build/lib/IPython/gui creating build/lib/IPython/gui/wx copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx creating build/lib/IPython/kernel copying IPython/kernel/client.py -> build/lib/IPython/kernel copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel copying IPython/kernel/map.py -> build/lib/IPython/kernel copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel copying IPython/kernel/contexts.py -> build/lib/IPython/kernel copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel copying IPython/kernel/__init__.py -> build/lib/IPython/kernel copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel copying IPython/kernel/magic.py -> build/lib/IPython/kernel copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel copying IPython/kernel/util.py -> build/lib/IPython/kernel copying IPython/kernel/task.py -> build/lib/IPython/kernel copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel copying IPython/kernel/error.py -> build/lib/IPython/kernel copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel creating build/lib/IPython/kernel/config copying IPython/kernel/config/__init__.py -> build/lib/IPython/kernel/config creating build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_multienginefc.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_controllerservice.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_engineservice.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_task.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_pendingdeferred.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/engineservicetest.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_newserialized.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/multienginetest.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_taskfc.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_enginefc.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/test_multiengine.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/controllertest.py -> build/lib/IPython/kernel/tests copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests creating build/lib/IPython/kernel/scripts copying IPython/kernel/scripts/ipcluster.py -> build/lib/IPython/kernel/scripts copying IPython/kernel/scripts/__init__.py -> build/lib/IPython/kernel/scripts copying IPython/kernel/scripts/ipengine.py -> build/lib/IPython/kernel/scripts copying IPython/kernel/scripts/ipcontroller.py -> build/lib/IPython/kernel/scripts creating build/lib/IPython/kernel/core copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/display_formatter.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/message_cache.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/traceback_trap.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/output_trap.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/display_trap.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/interpreter.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/traceback_formatter.py -> build/lib/IPython/kernel/core copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core creating build/lib/IPython/kernel/core/config copying IPython/kernel/core/config/__init__.py -> build/lib/IPython/kernel/core/config creating build/lib/IPython/kernel/core/tests copying IPython/kernel/core/tests/test_shell.py -> build/lib/IPython/kernel/core/tests copying IPython/kernel/core/tests/__init__.py -> build/lib/IPython/kernel/core/tests creating build/lib/IPython/testing copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing copying IPython/testing/__init__.py -> build/lib/IPython/testing copying IPython/testing/parametric.py -> build/lib/IPython/testing copying IPython/testing/util.py -> build/lib/IPython/testing copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing copying IPython/testing/tutils.py -> build/lib/IPython/testing copying IPython/testing/tstTEMPLATE_doctest.py -> build/lib/IPython/testing copying IPython/testing/tcommon.py -> build/lib/IPython/testing creating build/lib/IPython/testing/tests copying IPython/testing/tests/__init__.py -> build/lib/IPython/testing/tests copying IPython/testing/tests/test_testutils.py -> build/lib/IPython/testing/tests creating build/lib/IPython/tools copying IPython/tools/__init__.py -> build/lib/IPython/tools copying IPython/tools/utils.py -> build/lib/IPython/tools copying IPython/tools/growl.py -> build/lib/IPython/tools creating build/lib/IPython/tools/tests copying IPython/tools/tests/tst_tools_utils_doctest2.py -> build/lib/IPython/tools/tests copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests copying IPython/tools/tests/test_tools_utils.py -> build/lib/IPython/tools/tests copying IPython/tools/tests/tst_tools_utils_doctest.py -> build/lib/IPython/tools/tests package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) creating build/lib/IPython/UserConfig copying IPython/UserConfig/ipy_user_conf.py -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc-physics -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc-tutorial -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc-numeric -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) running build_scripts creating build/scripts-2.5 error: file 'ipython/kernel/scripts/ipengine' does not exist On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger wrote: > Hello all, > > I have just merged the ipython-ipython1a branch into ipython trunk. > This means that most of the stable stuff from ipython1 is now in > IPython. This includes the following new subpackages: > > IPython.kernel > IPython.kernel.core > IPython.config > IPython.tools > > The biggest change though is that I have refectored the setup.py > script. Because these new subpackages have lots of other > dependencies, we needed a nice way of handling these things. Here is > a skech of how it is being handled: > > 1. If setuptools is being used, we declare optional requires for the > additional deps > > 2. If setuptools is not being used, we check for the deps manually > and simple tell the user what was found and what is required for what > features. > > While this will likely take some find tuning, it is a start. > > PLEASE, try out the new setup.py in trunk on various platforms and in > various situations. We need to test this well as it is a huge change. > > But, the bottom line is that IPython trunk now has full parallel > computing capabilities. I will also announce on IPython-users > > Next stop: documentation merge!!! > > Cheers, > > Brian > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Jun 10 13:54:51 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 10 Jun 2008 10:54:51 -0700 Subject: [IPython-dev] pylab executable In-Reply-To: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com> References: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com> Message-ID: On Tue, Jun 10, 2008 at 9:01 AM, John Hunter wrote: > This came through the mpl feature request tracker (add a "pylab" > executable to the bin dir") > > https://sourceforge.net/tracker/index.php?func=detail&aid=1910613&group_id=80706&atid=560723 > > SInce this is really an ipython feature request, I'm moving it over > here (it is assigned to fer_perez on the mpl tracker). I'm not fully opposed, but to some extent I'm not sure it's really needed. It's one of those things along Guido's "not every 2-line function has to be part of the stdlib". But if you think that it would help the beginners, we can certainly include it. I would, however, suggest: - make it a python rather than a shell script, for portability reasons (we have Win32 users for whom a /bin/sh script won't work right). - Make it the equivalent of 'ipython -pylab -p pylab'. I know it sounds a bit confusing, but there's a method to the madness: -pylab should do the absolute minimum: basically load pylab and figure out the threading issues. It's a special option because it encodes a lot of initialization behavior that can't be done afterwards. But by having this script call a pylab *profile*, we can put other customizations that we may think of later in the profile, and it gives users a clean way to tweak it by making a personal profile if they feel like it. Feel free to tag this into ipython's bug tracker: https://bugs.launchpad.net/ipython Cheers, f From cohen at slac.stanford.edu Tue Jun 10 13:54:35 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 19:54:35 +0200 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: References: Message-ID: <484EBFDB.3010500@slac.stanford.edu> Doug, replace ipython by IPython in setupbase.py, at the line where ipengine is called and the 2 next ones. Johann ipython-dev-request at scipy.org wrote: > Send IPython-dev mailing list submissions to > ipython-dev at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > or, via email, send a message with subject or body 'help' to > ipython-dev-request at scipy.org > > You can reach the person managing the list at > ipython-dev-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPython-dev digest..." > > ------------------------------------------------------------------------ > > Today's Topics: > > 1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones) > > > ------------------------------------------------------------------------ > > Subject: > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! > From: > "Doug Jones" > Date: > Tue, 10 Jun 2008 13:02:12 -0400 > To: > "Brian Granger" > > To: > "Brian Granger" > CC: > IPython Development list > > > Hi All, > > I just gave the newest setup.py a go on my machine and ran into some > problems. I've copied its output below. If you need more information, > let me know and I will do my best to provide it. > > Thanks, > ~doug > > > python setup.py build > ============================================================================ > BUILDING IPYTHON > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC > 4.1.2 (Gentoo 4.1.2 p1.0.1)] > platform: linux2 > > OPTIONAL DEPENDENCIES > Zope.Interface: yes > Twisted: 2.5.0 > Foolscap: 0.2.8 > OpenSSL: Not found (required if you want security in the > parallel computing capabilities) > sphinx: 0.3 > pygments: 0.10 > nose: 0.9.3 > pexpect: 2.1 > running build > running build_py > creating build > creating build/lib > creating build/lib/IPython > copying IPython/wildcard.py -> build/lib/IPython > copying IPython/deep_reload.py -> build/lib/IPython > copying IPython/macro.py -> build/lib/IPython > copying IPython/ipapi.py -> build/lib/IPython > copying IPython/rlineimpl.py -> build/lib/IPython > copying IPython/CrashHandler.py -> build/lib/IPython > copying IPython/Shell.py -> build/lib/IPython > copying IPython/ultraTB.py -> build/lib/IPython > copying IPython/ipmaker.py -> build/lib/IPython > copying IPython/upgrade_dir.py -> build/lib/IPython > copying IPython/excolors.py -> build/lib/IPython > copying IPython/Release.py -> build/lib/IPython > copying IPython/demo.py -> build/lib/IPython > copying IPython/OutputTrap.py -> build/lib/IPython > copying IPython/shadowns.py -> build/lib/IPython > copying IPython/__init__.py -> build/lib/IPython > copying IPython/ColorANSI.py -> build/lib/IPython > copying IPython/platutils_posix.py -> build/lib/IPython > copying IPython/strdispatch.py -> build/lib/IPython > copying IPython/generics.py -> build/lib/IPython > copying IPython/platutils.py -> build/lib/IPython > copying IPython/Debugger.py -> build/lib/IPython > copying IPython/GnuplotInteractive.py -> build/lib/IPython > copying IPython/ipstruct.py -> build/lib/IPython > copying IPython/completer.py -> build/lib/IPython > copying IPython/FakeModule.py -> build/lib/IPython > copying IPython/usage.py -> build/lib/IPython > copying IPython/GnuplotRuntime.py -> build/lib/IPython > copying IPython/Logger.py -> build/lib/IPython > copying IPython/Prompts.py -> build/lib/IPython > copying IPython/numutils.py -> build/lib/IPython > copying IPython/ConfigLoader.py -> build/lib/IPython > copying IPython/platutils_dummy.py -> build/lib/IPython > copying IPython/DPyGetOpt.py -> build/lib/IPython > copying IPython/platutils_win32.py -> build/lib/IPython > copying IPython/background_jobs.py -> build/lib/IPython > copying IPython/iplib.py -> build/lib/IPython > copying IPython/dtutils.py -> build/lib/IPython > copying IPython/prefilter.py -> build/lib/IPython > copying IPython/PyColorize.py -> build/lib/IPython > copying IPython/twshell.py -> build/lib/IPython > copying IPython/history.py -> build/lib/IPython > copying IPython/winconsole.py -> build/lib/IPython > copying IPython/shellglobals.py -> build/lib/IPython > copying IPython/genutils.py -> build/lib/IPython > copying IPython/hooks.py -> build/lib/IPython > copying IPython/OInspect.py -> build/lib/IPython > copying IPython/Magic.py -> build/lib/IPython > copying IPython/irunner.py -> build/lib/IPython > copying IPython/Gnuplot2.py -> build/lib/IPython > copying IPython/Itpl.py -> build/lib/IPython > creating build/lib/IPython/config > copying IPython/config/api.py -> build/lib/IPython/config > copying IPython/config/__init__.py -> build/lib/IPython/config > copying IPython/config/cutils.py -> build/lib/IPython/config > copying IPython/config/sconfig.py -> build/lib/IPython/config > package init file 'IPython/config/tests/__init__.py' not found (or not > a regular file) > creating build/lib/IPython/config/tests > copying IPython/config/tests/simpleconf.py -> > build/lib/IPython/config/tests > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests > creating build/lib/IPython/Extensions > copying IPython/Extensions/ipy_autoreload.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_rehashdir.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_sh.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions > copying IPython/Extensions/PhysicalQInteractive.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_system_conf.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_doctest.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_gnuglobal.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_traits_completer.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/numeric_formats.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_scipy.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_vimserver.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions > copying IPython/Extensions/InterpreterExec.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions > copying IPython/Extensions/pspersistence.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions > copying IPython/Extensions/PhysicalQInput.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_none.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_greedycompleter.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_numpy.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ext_rescapture.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/InterpreterPasteInput.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_constants.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_stock_completers.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_app_completers.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_completers.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_zope.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions > creating build/lib/IPython/external > copying IPython/external/mglob.py -> build/lib/IPython/external > copying IPython/external/path.py -> build/lib/IPython/external > copying IPython/external/__init__.py -> build/lib/IPython/external > copying IPython/external/simplegeneric.py -> build/lib/IPython/external > copying IPython/external/validate.py -> build/lib/IPython/external > copying IPython/external/configobj.py -> build/lib/IPython/external > copying IPython/external/guid.py -> build/lib/IPython/external > copying IPython/external/Itpl.py -> build/lib/IPython/external > creating build/lib/IPython/gui > copying IPython/gui/__init__.py -> build/lib/IPython/gui > creating build/lib/IPython/gui/wx > copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx > creating build/lib/IPython/kernel > copying IPython/kernel/client.py -> build/lib/IPython/kernel > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel > copying IPython/kernel/map.py -> build/lib/IPython/kernel > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel > copying IPython/kernel/magic.py -> build/lib/IPython/kernel > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel > copying IPython/kernel/util.py -> build/lib/IPython/kernel > copying IPython/kernel/task.py -> build/lib/IPython/kernel > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel > copying IPython/kernel/error.py -> build/lib/IPython/kernel > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel > creating build/lib/IPython/kernel/config > copying IPython/kernel/config/__init__.py -> > build/lib/IPython/kernel/config > creating build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_multienginefc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_controllerservice.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_engineservice.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_task.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_pendingdeferred.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/engineservicetest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_newserialized.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests > copying IPython/kernel/tests/multienginetest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_taskfc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_enginefc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_multiengine.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/controllertest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests > creating build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipcluster.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/__init__.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipengine.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipcontroller.py -> > build/lib/IPython/kernel/scripts > creating build/lib/IPython/kernel/core > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/display_formatter.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/message_cache.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/traceback_trap.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/output_trap.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/display_trap.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/interpreter.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/traceback_formatter.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core > creating build/lib/IPython/kernel/core/config > copying IPython/kernel/core/config/__init__.py -> > build/lib/IPython/kernel/core/config > creating build/lib/IPython/kernel/core/tests > copying IPython/kernel/core/tests/test_shell.py -> > build/lib/IPython/kernel/core/tests > copying IPython/kernel/core/tests/__init__.py -> > build/lib/IPython/kernel/core/tests > creating build/lib/IPython/testing > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing > copying IPython/testing/__init__.py -> build/lib/IPython/testing > copying IPython/testing/parametric.py -> build/lib/IPython/testing > copying IPython/testing/util.py -> build/lib/IPython/testing > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing > copying IPython/testing/tutils.py -> build/lib/IPython/testing > copying IPython/testing/tstTEMPLATE_doctest.py -> > build/lib/IPython/testing > copying IPython/testing/tcommon.py -> build/lib/IPython/testing > creating build/lib/IPython/testing/tests > copying IPython/testing/tests/__init__.py -> > build/lib/IPython/testing/tests > copying IPython/testing/tests/test_testutils.py -> > build/lib/IPython/testing/tests > creating build/lib/IPython/tools > copying IPython/tools/__init__.py -> build/lib/IPython/tools > copying IPython/tools/utils.py -> build/lib/IPython/tools > copying IPython/tools/growl.py -> build/lib/IPython/tools > creating build/lib/IPython/tools/tests > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> > build/lib/IPython/tools/tests > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests > copying IPython/tools/tests/test_tools_utils.py -> > build/lib/IPython/tools/tests > copying IPython/tools/tests/tst_tools_utils_doctest.py -> > build/lib/IPython/tools/tests > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > creating build/lib/IPython/UserConfig > copying IPython/UserConfig/ipy_user_conf.py -> > build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-physics -> > build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-tutorial -> > build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-numeric -> > build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig > package init file 'IPython/config/tests/__init__.py' not found (or not > a regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > running build_scripts > creating build/scripts-2.5 > error: file 'ipython/kernel/scripts/ipengine' does not exist > > > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger @gmail.com > wrote: > > Hello all, > > I have just merged the ipython-ipython1a branch into ipython trunk. > This means that most of the stable stuff from ipython1 is now in > IPython. This includes the following new subpackages: > > IPython.kernel > IPython.kernel.core > IPython.config > IPython.tools > > The biggest change though is that I have refectored the setup.py > script. Because these new subpackages have lots of other > dependencies, we needed a nice way of handling these things. Here is > a skech of how it is being handled: > > 1. If setuptools is being used, we declare optional requires for the > additional deps > > 2. If setuptools is not being used, we check for the deps manually > and simple tell the user what was found and what is required for what > features. > > While this will likely take some find tuning, it is a start. > > PLEASE, try out the new setup.py in trunk on various platforms and in > various situations. We need to test this well as it is a huge change. > > But, the bottom line is that IPython trunk now has full parallel > computing capabilities. I will also announce on IPython-users > > Next stop: documentation merge!!! > > Cheers, > > Brian > _______________________________________________ > 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 dfj225 at gmail.com Tue Jun 10 14:01:58 2008 From: dfj225 at gmail.com (Doug Jones) Date: Tue, 10 Jun 2008 14:01:58 -0400 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <484EBFDB.3010500@slac.stanford.edu> References: <484EBFDB.3010500@slac.stanford.edu> Message-ID: <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> Johann, Thanks, that seemed to have fixed the problem. I still got the following warnings, not sure if they impact anything or not. package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi < cohen at slac.stanford.edu> wrote: > Doug, > replace ipython by IPython in setupbase.py, at the line where ipengine > is called and the 2 next ones. > Johann > > ipython-dev-request at scipy.org wrote: > > Send IPython-dev mailing list submissions to > > ipython-dev at scipy.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > > or, via email, send a message with subject or body 'help' to > > ipython-dev-request at scipy.org > > > > You can reach the person managing the list at > > ipython-dev-owner at scipy.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of IPython-dev digest..." > > > > ------------------------------------------------------------------------ > > > > Today's Topics: > > > > 1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones) > > > > > > ------------------------------------------------------------------------ > > > > Subject: > > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! > > From: > > "Doug Jones" > > Date: > > Tue, 10 Jun 2008 13:02:12 -0400 > > To: > > "Brian Granger" > > > > To: > > "Brian Granger" > > CC: > > IPython Development list > > > > > > Hi All, > > > > I just gave the newest setup.py a go on my machine and ran into some > > problems. I've copied its output below. If you need more information, > > let me know and I will do my best to provide it. > > > > Thanks, > > ~doug > > > > > > python setup.py build > > > ============================================================================ > > BUILDING IPYTHON > > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC > > 4.1.2 (Gentoo 4.1.2 p1.0.1)] > > platform: linux2 > > > > OPTIONAL DEPENDENCIES > > Zope.Interface: yes > > Twisted: 2.5.0 > > Foolscap: 0.2.8 > > OpenSSL: Not found (required if you want security in the > > parallel computing capabilities) > > sphinx: 0.3 > > pygments: 0.10 > > nose: 0.9.3 > > pexpect: 2.1 > > running build > > running build_py > > creating build > > creating build/lib > > creating build/lib/IPython > > copying IPython/wildcard.py -> build/lib/IPython > > copying IPython/deep_reload.py -> build/lib/IPython > > copying IPython/macro.py -> build/lib/IPython > > copying IPython/ipapi.py -> build/lib/IPython > > copying IPython/rlineimpl.py -> build/lib/IPython > > copying IPython/CrashHandler.py -> build/lib/IPython > > copying IPython/Shell.py -> build/lib/IPython > > copying IPython/ultraTB.py -> build/lib/IPython > > copying IPython/ipmaker.py -> build/lib/IPython > > copying IPython/upgrade_dir.py -> build/lib/IPython > > copying IPython/excolors.py -> build/lib/IPython > > copying IPython/Release.py -> build/lib/IPython > > copying IPython/demo.py -> build/lib/IPython > > copying IPython/OutputTrap.py -> build/lib/IPython > > copying IPython/shadowns.py -> build/lib/IPython > > copying IPython/__init__.py -> build/lib/IPython > > copying IPython/ColorANSI.py -> build/lib/IPython > > copying IPython/platutils_posix.py -> build/lib/IPython > > copying IPython/strdispatch.py -> build/lib/IPython > > copying IPython/generics.py -> build/lib/IPython > > copying IPython/platutils.py -> build/lib/IPython > > copying IPython/Debugger.py -> build/lib/IPython > > copying IPython/GnuplotInteractive.py -> build/lib/IPython > > copying IPython/ipstruct.py -> build/lib/IPython > > copying IPython/completer.py -> build/lib/IPython > > copying IPython/FakeModule.py -> build/lib/IPython > > copying IPython/usage.py -> build/lib/IPython > > copying IPython/GnuplotRuntime.py -> build/lib/IPython > > copying IPython/Logger.py -> build/lib/IPython > > copying IPython/Prompts.py -> build/lib/IPython > > copying IPython/numutils.py -> build/lib/IPython > > copying IPython/ConfigLoader.py -> build/lib/IPython > > copying IPython/platutils_dummy.py -> build/lib/IPython > > copying IPython/DPyGetOpt.py -> build/lib/IPython > > copying IPython/platutils_win32.py -> build/lib/IPython > > copying IPython/background_jobs.py -> build/lib/IPython > > copying IPython/iplib.py -> build/lib/IPython > > copying IPython/dtutils.py -> build/lib/IPython > > copying IPython/prefilter.py -> build/lib/IPython > > copying IPython/PyColorize.py -> build/lib/IPython > > copying IPython/twshell.py -> build/lib/IPython > > copying IPython/history.py -> build/lib/IPython > > copying IPython/winconsole.py -> build/lib/IPython > > copying IPython/shellglobals.py -> build/lib/IPython > > copying IPython/genutils.py -> build/lib/IPython > > copying IPython/hooks.py -> build/lib/IPython > > copying IPython/OInspect.py -> build/lib/IPython > > copying IPython/Magic.py -> build/lib/IPython > > copying IPython/irunner.py -> build/lib/IPython > > copying IPython/Gnuplot2.py -> build/lib/IPython > > copying IPython/Itpl.py -> build/lib/IPython > > creating build/lib/IPython/config > > copying IPython/config/api.py -> build/lib/IPython/config > > copying IPython/config/__init__.py -> build/lib/IPython/config > > copying IPython/config/cutils.py -> build/lib/IPython/config > > copying IPython/config/sconfig.py -> build/lib/IPython/config > > package init file 'IPython/config/tests/__init__.py' not found (or not > > a regular file) > > creating build/lib/IPython/config/tests > > copying IPython/config/tests/simpleconf.py -> > > build/lib/IPython/config/tests > > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests > > creating build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_autoreload.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_rehashdir.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_sh.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/PhysicalQInteractive.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_system_conf.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_doctest.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_gnuglobal.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_traits_completer.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/numeric_formats.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_scipy.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_vimserver.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/InterpreterExec.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_exportdb.py -> > build/lib/IPython/Extensions > > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/pspersistence.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/PhysicalQInput.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_none.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_greedycompleter.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_numpy.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ext_rescapture.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/InterpreterPasteInput.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_constants.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_defaults.py -> > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_stock_completers.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_app_completers.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_completers.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_profile_zope.py -> > > build/lib/IPython/Extensions > > copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions > > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions > > creating build/lib/IPython/external > > copying IPython/external/mglob.py -> build/lib/IPython/external > > copying IPython/external/path.py -> build/lib/IPython/external > > copying IPython/external/__init__.py -> build/lib/IPython/external > > copying IPython/external/simplegeneric.py -> build/lib/IPython/external > > copying IPython/external/validate.py -> build/lib/IPython/external > > copying IPython/external/configobj.py -> build/lib/IPython/external > > copying IPython/external/guid.py -> build/lib/IPython/external > > copying IPython/external/Itpl.py -> build/lib/IPython/external > > creating build/lib/IPython/gui > > copying IPython/gui/__init__.py -> build/lib/IPython/gui > > creating build/lib/IPython/gui/wx > > copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx > > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx > > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx > > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx > > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx > > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx > > creating build/lib/IPython/kernel > > copying IPython/kernel/client.py -> build/lib/IPython/kernel > > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel > > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel > > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel > > copying IPython/kernel/map.py -> build/lib/IPython/kernel > > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel > > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel > > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel > > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel > > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel > > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel > > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel > > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel > > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel > > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel > > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel > > copying IPython/kernel/magic.py -> build/lib/IPython/kernel > > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel > > copying IPython/kernel/util.py -> build/lib/IPython/kernel > > copying IPython/kernel/task.py -> build/lib/IPython/kernel > > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel > > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel > > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel > > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel > > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel > > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel > > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel > > copying IPython/kernel/error.py -> build/lib/IPython/kernel > > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel > > creating build/lib/IPython/kernel/config > > copying IPython/kernel/config/__init__.py -> > > build/lib/IPython/kernel/config > > creating build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_multienginefc.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_controllerservice.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_engineservice.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_task.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_pendingdeferred.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/engineservicetest.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_newserialized.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/__init__.py -> > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/multienginetest.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_taskfc.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_enginefc.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/test_multiengine.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/controllertest.py -> > > build/lib/IPython/kernel/tests > > copying IPython/kernel/tests/tasktest.py -> > build/lib/IPython/kernel/tests > > creating build/lib/IPython/kernel/scripts > > copying IPython/kernel/scripts/ipcluster.py -> > > build/lib/IPython/kernel/scripts > > copying IPython/kernel/scripts/__init__.py -> > > build/lib/IPython/kernel/scripts > > copying IPython/kernel/scripts/ipengine.py -> > > build/lib/IPython/kernel/scripts > > copying IPython/kernel/scripts/ipcontroller.py -> > > build/lib/IPython/kernel/scripts > > creating build/lib/IPython/kernel/core > > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/display_formatter.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/message_cache.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/traceback_trap.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/output_trap.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/display_trap.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/interpreter.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core > > copying IPython/kernel/core/traceback_formatter.py -> > > build/lib/IPython/kernel/core > > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core > > creating build/lib/IPython/kernel/core/config > > copying IPython/kernel/core/config/__init__.py -> > > build/lib/IPython/kernel/core/config > > creating build/lib/IPython/kernel/core/tests > > copying IPython/kernel/core/tests/test_shell.py -> > > build/lib/IPython/kernel/core/tests > > copying IPython/kernel/core/tests/__init__.py -> > > build/lib/IPython/kernel/core/tests > > creating build/lib/IPython/testing > > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing > > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing > > copying IPython/testing/__init__.py -> build/lib/IPython/testing > > copying IPython/testing/parametric.py -> build/lib/IPython/testing > > copying IPython/testing/util.py -> build/lib/IPython/testing > > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing > > copying IPython/testing/tutils.py -> build/lib/IPython/testing > > copying IPython/testing/tstTEMPLATE_doctest.py -> > > build/lib/IPython/testing > > copying IPython/testing/tcommon.py -> build/lib/IPython/testing > > creating build/lib/IPython/testing/tests > > copying IPython/testing/tests/__init__.py -> > > build/lib/IPython/testing/tests > > copying IPython/testing/tests/test_testutils.py -> > > build/lib/IPython/testing/tests > > creating build/lib/IPython/tools > > copying IPython/tools/__init__.py -> build/lib/IPython/tools > > copying IPython/tools/utils.py -> build/lib/IPython/tools > > copying IPython/tools/growl.py -> build/lib/IPython/tools > > creating build/lib/IPython/tools/tests > > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> > > build/lib/IPython/tools/tests > > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests > > copying IPython/tools/tests/test_tools_utils.py -> > > build/lib/IPython/tools/tests > > copying IPython/tools/tests/tst_tools_utils_doctest.py -> > > build/lib/IPython/tools/tests > > package init file 'IPython/UserConfig/__init__.py' not found (or not a > > regular file) > > creating build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipy_user_conf.py -> > > build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc-physics -> > > build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc-tutorial -> > > build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc-numeric -> > > build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig > > copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig > > package init file 'IPython/config/tests/__init__.py' not found (or not > > a regular file) > > package init file 'IPython/UserConfig/__init__.py' not found (or not a > > regular file) > > running build_scripts > > creating build/scripts-2.5 > > error: file 'ipython/kernel/scripts/ipengine' does not exist > > > > > > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger > @gmail.com > wrote: > > > > Hello all, > > > > I have just merged the ipython-ipython1a branch into ipython trunk. > > This means that most of the stable stuff from ipython1 is now in > > IPython. This includes the following new subpackages: > > > > IPython.kernel > > IPython.kernel.core > > IPython.config > > IPython.tools > > > > The biggest change though is that I have refectored the setup.py > > script. Because these new subpackages have lots of other > > dependencies, we needed a nice way of handling these things. Here is > > a skech of how it is being handled: > > > > 1. If setuptools is being used, we declare optional requires for the > > additional deps > > > > 2. If setuptools is not being used, we check for the deps manually > > and simple tell the user what was found and what is required for what > > features. > > > > While this will likely take some find tuning, it is a start. > > > > PLEASE, try out the new setup.py in trunk on various platforms and in > > various situations. We need to test this well as it is a huge > change. > > > > But, the bottom line is that IPython trunk now has full parallel > > computing capabilities. I will also announce on IPython-users > > > > Next stop: documentation merge!!! > > > > Cheers, > > > > Brian > > _______________________________________________ > > 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 > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohen at slac.stanford.edu Tue Jun 10 14:02:55 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 20:02:55 +0200 Subject: [IPython-dev] building current bzr trunk : Message-ID: <484EC1CF.90602@slac.stanford.edu> hi there, after the modif to setupbase of my earlier post, I get: [cohen at jarrett ipython]$ python setup.py build ============================================================================ BUILDING IPYTHON python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 2.5.0 Foolscap: Not found (required for parallel computing capabilities) OpenSSL: 0.6 sphinx: Not found (required for building documentation) pygments: Not found (required for syntax highlighting documentation) nose: 0.10.0 pexpect: 2.3 running build running build_py package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) running build_scripts So the first thing I want to try then is to get Foolscap.... but: [root at jarrett ~]# easy_install Foolscap Searching for Foolscap Reading http://pypi.python.org/simple/Foolscap/ Couldn't find index page for 'Foolscap' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Reading http://pypi.python.org/simple/foolscap/ Reading http://foolscap.lothar.com/ Reading http://foolscap.lothar.com/trac Best match: foolscap 0.2.8 Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz Processing foolscap-0.2.8.tar.gz Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 zip_safe flag not set; analyzing archive contents... Adding foolscap 0.2.8 to easy-install.pth file Installing flogtool script to /usr/bin Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg Processing dependencies for Foolscap Searching for twisted>=2.4.0 Reading http://pypi.python.org/simple/twisted/ Reading http://pypi.python.org/simple/Twisted/ Reading http://twistedmatrix.com/ Reading http://www.twistedmatrix.com Reading http://twistedmatrix.com/products/download Reading http://twistedmatrix.com/projects/core/ Best match: Twisted 8.1.0 Downloading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 Processing Twisted-8.1.0.tar.bz2 Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu twisted/protocols/_c_urlarg.c: In function ?unquote?: twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing argument 2 of ?PycStringIO->cwrite? differ in signedness twisted/python/_epoll.c: In function ?__pyx_f_6_epoll_5epoll___dealloc__?: twisted/python/_epoll.c:168: attention : label ?__pyx_L1? defined but not used twisted/python/_epoll.c: In function ?__pyx_f_6_epoll_5epoll_wait?: twisted/python/_epoll.c:432: attention : label ?__pyx_L7? defined but not used twisted/python/_epoll.c:430: attention : label ?__pyx_L6? defined but not used twisted/python/_epoll.c: In function ?__pyx_tp_new_6_epoll_epoll?: twisted/python/_epoll.c:508: attention : unused variable ?p? twisted/python/_epoll.c: In function ?__pyx_tp_dealloc_6_epoll_epoll?: twisted/python/_epoll.c:513: attention : unused variable ?p? twisted/python/_epoll.c: In function ?__pyx_tp_traverse_6_epoll_epoll?: twisted/python/_epoll.c:528: attention : unused variable ?p? twisted/python/_epoll.c:527: attention : unused variable ?e? twisted/python/_epoll.c: In function ?__pyx_tp_clear_6_epoll_epoll?: twisted/python/_epoll.c:533: attention : unused variable ?p? twisted/python/_epoll.c: Hors de toute fonction : twisted/python/_epoll.c:32: attention : ?__Pyx_UnpackItem? declared ?static? but never defined twisted/python/_epoll.c:33: attention : ?__Pyx_EndUnpack? declared ?static? but never defined twisted/python/_epoll.c:34: attention : ?__Pyx_PrintItem? declared ?static? but never defined twisted/python/_epoll.c:35: attention : ?__Pyx_PrintNewline? declared ?static? but never defined twisted/python/_epoll.c:37: attention : ?__Pyx_ReRaise? declared ?static? but never defined twisted/python/_epoll.c:38: attention : ?__Pyx_Import? declared ?static? but never defined twisted/python/_epoll.c:39: attention : ?__Pyx_GetExcValue? declared ?static? but never defined twisted/python/_epoll.c:40: attention : ?__Pyx_ArgTypeTest? declared ?static? but never defined twisted/python/_epoll.c:41: attention : ?__Pyx_TypeTest? declared ?static? but never defined twisted/python/_epoll.c:42: attention : ?__Pyx_GetStarArgs? declared ?static? but never defined twisted/python/_epoll.c:43: attention : ?__Pyx_WriteUnraisable? declared ?static? but never defined twisted/python/_epoll.c:45: attention : ?__Pyx_ImportType? declared ?static? but never defined twisted/python/_epoll.c:46: attention : ?__Pyx_SetVtable? declared ?static? but never defined twisted/python/_epoll.c:47: attention : ?__Pyx_GetVtable? declared ?static? but never defined twisted/python/_epoll.c:48: attention : ?__Pyx_CreateClass? declared ?static? but never defined twisted/python/_epoll.c:50: attention : ?__Pyx_InitStrings? declared ?static? but never defined twisted/python/_epoll.c:51: attention : ?__Pyx_InitCApi? declared ?static? but never defined twisted/python/_epoll.c:52: attention : ?__Pyx_ImportModuleCApi? declared ?static? but never defined Adding Twisted 8.1.0 to easy-install.pth file Installing mailmail script to /usr/bin Installing cftp script to /usr/bin Installing tkconch script to /usr/bin Installing im script to /usr/bin Installing pyhtmlizer script to /usr/bin Installing lore script to /usr/bin Installing tapconvert script to /usr/bin Installing tap2deb script to /usr/bin Installing ckeygen script to /usr/bin Installing t-im script to /usr/bin Installing twistd script to /usr/bin Installing trial script to /usr/bin Installing tap2rpm script to /usr/bin Installing bookify script to /usr/bin Installing mktap script to /usr/bin Installing manhole script to /usr/bin Installing conch script to /usr/bin Installed /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg Searching for zope.interface Reading http://pypi.python.org/simple/zope.interface/ Reading http://zope.org/Wikis/Interfaces/FrontPage Best match: zope.interface 3.4.1 Downloading http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e Processing zope.interface-3.4.1.tar.gz Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm Traceback (most recent call last): File "/usr/bin/easy_install", line 8, in load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1670, in main with_ei_usage(lambda: File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1674, in distclass=DistributionWithoutHelpCommands, **kw File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 473, in install_item self.process_distribution(spec, dist, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 519, in process_distribution [requirement], self.local_index, self.easy_install File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in best_match return self.obtain(req, installer) # try and download/install File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in obtain return installer(requirement) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 471, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, in run_setup lambda: execfile( File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, in run return func() File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, in {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 85, in File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 174, in run cmd = self.call_command('install_lib', warn_dir=0) File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 161, in call_command self.run_command(cmdname) File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", line 20, in run self.build() File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in build self.run_command('build_ext') File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 46, in run _build_ext.run(self) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run self.build_extensions() File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", line 82, in build_extensions self.build_extension(ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 175, in build_extension _build_ext.build_extension(self,ext) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in build_extension sources = self.swig_sources(sources, ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 77, in swig_sources sources = _build_ext.swig_sources(self, sources) or sources TypeError: swig_sources() takes exactly 3 arguments (2 given) and that I do not know what to do with it :) Her is what I have for swig: [root at jarrett ~]# rpm -qa | grep -i swig swig-1.3.33-1.fc8 [root at jarrett ~]# From cohen at slac.stanford.edu Tue Jun 10 14:15:19 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 20:15:19 +0200 Subject: [IPython-dev] feature? Message-ID: <484EC4B7.6010309@slac.stanford.edu> More on my issues with current bzr trunk : I installed sphinx without trouble so only Foolscap seems to be a problem. But when I try to build ipython again, just for the sake of it, it now outputs : [cohen at jarrett ipython]$ python setup.py build ============================================================================ BUILDING IPYTHON python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 8.1.0 Foolscap: 0.2.8 OpenSSL: 0.6 sphinx: 0.3 pygments: 0.10 nose: 0.10.0 pexpect: 2.3 running build running build_py package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) package init file 'IPython/config/tests/__init__.py' not found (or not a regular file) package init file 'IPython/UserConfig/__init__.py' not found (or not a regular file) running build_scripts Only the Foolscap egg is there, which seems to be enough for ipython at this stage. Do we really want that behavior? best, Johann From ellisonbg.net at gmail.com Tue Jun 10 14:23:12 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:23:12 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <484EBFDB.3010500@slac.stanford.edu> References: <484EBFDB.3010500@slac.stanford.edu> Message-ID: <6ce0ac130806101123q580da9adha3bdbb32042ea11f@mail.gmail.com> I will fix this ASAP! Thanks for trying this out! I run OS X (which is case insensitive) so this didn't show up for me. Brian On Tue, Jun 10, 2008 at 11:54 AM, Johann Cohen-Tanugi wrote: > Doug, > replace ipython by IPython in setupbase.py, at the line where ipengine > is called and the 2 next ones. > Johann > > ipython-dev-request at scipy.org wrote: >> Send IPython-dev mailing list submissions to >> ipython-dev at scipy.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> or, via email, send a message with subject or body 'help' to >> ipython-dev-request at scipy.org >> >> You can reach the person managing the list at >> ipython-dev-owner at scipy.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of IPython-dev digest..." >> >> ------------------------------------------------------------------------ >> >> Today's Topics: >> >> 1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones) >> >> >> ------------------------------------------------------------------------ >> >> Subject: >> Re: [IPython-dev] First merge of ipython1 -> IPython is completed! >> From: >> "Doug Jones" >> Date: >> Tue, 10 Jun 2008 13:02:12 -0400 >> To: >> "Brian Granger" >> >> To: >> "Brian Granger" >> CC: >> IPython Development list >> >> >> Hi All, >> >> I just gave the newest setup.py a go on my machine and ran into some >> problems. I've copied its output below. If you need more information, >> let me know and I will do my best to provide it. >> >> Thanks, >> ~doug >> >> >> python setup.py build >> ============================================================================ >> BUILDING IPYTHON >> python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC >> 4.1.2 (Gentoo 4.1.2 p1.0.1)] >> platform: linux2 >> >> OPTIONAL DEPENDENCIES >> Zope.Interface: yes >> Twisted: 2.5.0 >> Foolscap: 0.2.8 >> OpenSSL: Not found (required if you want security in the >> parallel computing capabilities) >> sphinx: 0.3 >> pygments: 0.10 >> nose: 0.9.3 >> pexpect: 2.1 >> running build >> running build_py >> creating build >> creating build/lib >> creating build/lib/IPython >> copying IPython/wildcard.py -> build/lib/IPython >> copying IPython/deep_reload.py -> build/lib/IPython >> copying IPython/macro.py -> build/lib/IPython >> copying IPython/ipapi.py -> build/lib/IPython >> copying IPython/rlineimpl.py -> build/lib/IPython >> copying IPython/CrashHandler.py -> build/lib/IPython >> copying IPython/Shell.py -> build/lib/IPython >> copying IPython/ultraTB.py -> build/lib/IPython >> copying IPython/ipmaker.py -> build/lib/IPython >> copying IPython/upgrade_dir.py -> build/lib/IPython >> copying IPython/excolors.py -> build/lib/IPython >> copying IPython/Release.py -> build/lib/IPython >> copying IPython/demo.py -> build/lib/IPython >> copying IPython/OutputTrap.py -> build/lib/IPython >> copying IPython/shadowns.py -> build/lib/IPython >> copying IPython/__init__.py -> build/lib/IPython >> copying IPython/ColorANSI.py -> build/lib/IPython >> copying IPython/platutils_posix.py -> build/lib/IPython >> copying IPython/strdispatch.py -> build/lib/IPython >> copying IPython/generics.py -> build/lib/IPython >> copying IPython/platutils.py -> build/lib/IPython >> copying IPython/Debugger.py -> build/lib/IPython >> copying IPython/GnuplotInteractive.py -> build/lib/IPython >> copying IPython/ipstruct.py -> build/lib/IPython >> copying IPython/completer.py -> build/lib/IPython >> copying IPython/FakeModule.py -> build/lib/IPython >> copying IPython/usage.py -> build/lib/IPython >> copying IPython/GnuplotRuntime.py -> build/lib/IPython >> copying IPython/Logger.py -> build/lib/IPython >> copying IPython/Prompts.py -> build/lib/IPython >> copying IPython/numutils.py -> build/lib/IPython >> copying IPython/ConfigLoader.py -> build/lib/IPython >> copying IPython/platutils_dummy.py -> build/lib/IPython >> copying IPython/DPyGetOpt.py -> build/lib/IPython >> copying IPython/platutils_win32.py -> build/lib/IPython >> copying IPython/background_jobs.py -> build/lib/IPython >> copying IPython/iplib.py -> build/lib/IPython >> copying IPython/dtutils.py -> build/lib/IPython >> copying IPython/prefilter.py -> build/lib/IPython >> copying IPython/PyColorize.py -> build/lib/IPython >> copying IPython/twshell.py -> build/lib/IPython >> copying IPython/history.py -> build/lib/IPython >> copying IPython/winconsole.py -> build/lib/IPython >> copying IPython/shellglobals.py -> build/lib/IPython >> copying IPython/genutils.py -> build/lib/IPython >> copying IPython/hooks.py -> build/lib/IPython >> copying IPython/OInspect.py -> build/lib/IPython >> copying IPython/Magic.py -> build/lib/IPython >> copying IPython/irunner.py -> build/lib/IPython >> copying IPython/Gnuplot2.py -> build/lib/IPython >> copying IPython/Itpl.py -> build/lib/IPython >> creating build/lib/IPython/config >> copying IPython/config/api.py -> build/lib/IPython/config >> copying IPython/config/__init__.py -> build/lib/IPython/config >> copying IPython/config/cutils.py -> build/lib/IPython/config >> copying IPython/config/sconfig.py -> build/lib/IPython/config >> package init file 'IPython/config/tests/__init__.py' not found (or not >> a regular file) >> creating build/lib/IPython/config/tests >> copying IPython/config/tests/simpleconf.py -> >> build/lib/IPython/config/tests >> copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests >> creating build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_autoreload.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_rehashdir.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_sh.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/PhysicalQInteractive.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_system_conf.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_doctest.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_gnuglobal.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_traits_completer.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/numeric_formats.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_scipy.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_vimserver.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/InterpreterExec.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/pspersistence.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/PhysicalQInput.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_none.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_greedycompleter.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_numpy.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ext_rescapture.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/InterpreterPasteInput.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_constants.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_stock_completers.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_app_completers.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_completers.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_profile_zope.py -> >> build/lib/IPython/Extensions >> copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions >> copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions >> creating build/lib/IPython/external >> copying IPython/external/mglob.py -> build/lib/IPython/external >> copying IPython/external/path.py -> build/lib/IPython/external >> copying IPython/external/__init__.py -> build/lib/IPython/external >> copying IPython/external/simplegeneric.py -> build/lib/IPython/external >> copying IPython/external/validate.py -> build/lib/IPython/external >> copying IPython/external/configobj.py -> build/lib/IPython/external >> copying IPython/external/guid.py -> build/lib/IPython/external >> copying IPython/external/Itpl.py -> build/lib/IPython/external >> creating build/lib/IPython/gui >> copying IPython/gui/__init__.py -> build/lib/IPython/gui >> creating build/lib/IPython/gui/wx >> copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx >> copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx >> copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx >> copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx >> copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx >> copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx >> creating build/lib/IPython/kernel >> copying IPython/kernel/client.py -> build/lib/IPython/kernel >> copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel >> copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel >> copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel >> copying IPython/kernel/map.py -> build/lib/IPython/kernel >> copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel >> copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel >> copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel >> copying IPython/kernel/contexts.py -> build/lib/IPython/kernel >> copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel >> copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel >> copying IPython/kernel/__init__.py -> build/lib/IPython/kernel >> copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel >> copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel >> copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel >> copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel >> copying IPython/kernel/magic.py -> build/lib/IPython/kernel >> copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel >> copying IPython/kernel/util.py -> build/lib/IPython/kernel >> copying IPython/kernel/task.py -> build/lib/IPython/kernel >> copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel >> copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel >> copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel >> copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel >> copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel >> copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel >> copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel >> copying IPython/kernel/error.py -> build/lib/IPython/kernel >> copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel >> creating build/lib/IPython/kernel/config >> copying IPython/kernel/config/__init__.py -> >> build/lib/IPython/kernel/config >> creating build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_multienginefc.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_controllerservice.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_engineservice.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_task.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_pendingdeferred.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/engineservicetest.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_newserialized.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/multienginetest.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_taskfc.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_enginefc.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/test_multiengine.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/controllertest.py -> >> build/lib/IPython/kernel/tests >> copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests >> creating build/lib/IPython/kernel/scripts >> copying IPython/kernel/scripts/ipcluster.py -> >> build/lib/IPython/kernel/scripts >> copying IPython/kernel/scripts/__init__.py -> >> build/lib/IPython/kernel/scripts >> copying IPython/kernel/scripts/ipengine.py -> >> build/lib/IPython/kernel/scripts >> copying IPython/kernel/scripts/ipcontroller.py -> >> build/lib/IPython/kernel/scripts >> creating build/lib/IPython/kernel/core >> copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/display_formatter.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/message_cache.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/traceback_trap.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/output_trap.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/display_trap.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/interpreter.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core >> copying IPython/kernel/core/traceback_formatter.py -> >> build/lib/IPython/kernel/core >> copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core >> creating build/lib/IPython/kernel/core/config >> copying IPython/kernel/core/config/__init__.py -> >> build/lib/IPython/kernel/core/config >> creating build/lib/IPython/kernel/core/tests >> copying IPython/kernel/core/tests/test_shell.py -> >> build/lib/IPython/kernel/core/tests >> copying IPython/kernel/core/tests/__init__.py -> >> build/lib/IPython/kernel/core/tests >> creating build/lib/IPython/testing >> copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing >> copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing >> copying IPython/testing/__init__.py -> build/lib/IPython/testing >> copying IPython/testing/parametric.py -> build/lib/IPython/testing >> copying IPython/testing/util.py -> build/lib/IPython/testing >> copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing >> copying IPython/testing/tutils.py -> build/lib/IPython/testing >> copying IPython/testing/tstTEMPLATE_doctest.py -> >> build/lib/IPython/testing >> copying IPython/testing/tcommon.py -> build/lib/IPython/testing >> creating build/lib/IPython/testing/tests >> copying IPython/testing/tests/__init__.py -> >> build/lib/IPython/testing/tests >> copying IPython/testing/tests/test_testutils.py -> >> build/lib/IPython/testing/tests >> creating build/lib/IPython/tools >> copying IPython/tools/__init__.py -> build/lib/IPython/tools >> copying IPython/tools/utils.py -> build/lib/IPython/tools >> copying IPython/tools/growl.py -> build/lib/IPython/tools >> creating build/lib/IPython/tools/tests >> copying IPython/tools/tests/tst_tools_utils_doctest2.py -> >> build/lib/IPython/tools/tests >> copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests >> copying IPython/tools/tests/test_tools_utils.py -> >> build/lib/IPython/tools/tests >> copying IPython/tools/tests/tst_tools_utils_doctest.py -> >> build/lib/IPython/tools/tests >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> creating build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipy_user_conf.py -> >> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc-physics -> >> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc-tutorial -> >> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc-numeric -> >> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig >> copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig >> package init file 'IPython/config/tests/__init__.py' not found (or not >> a regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> running build_scripts >> creating build/scripts-2.5 >> error: file 'ipython/kernel/scripts/ipengine' does not exist >> >> >> On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger > @gmail.com > wrote: >> >> Hello all, >> >> I have just merged the ipython-ipython1a branch into ipython trunk. >> This means that most of the stable stuff from ipython1 is now in >> IPython. This includes the following new subpackages: >> >> IPython.kernel >> IPython.kernel.core >> IPython.config >> IPython.tools >> >> The biggest change though is that I have refectored the setup.py >> script. Because these new subpackages have lots of other >> dependencies, we needed a nice way of handling these things. Here is >> a skech of how it is being handled: >> >> 1. If setuptools is being used, we declare optional requires for the >> additional deps >> >> 2. If setuptools is not being used, we check for the deps manually >> and simple tell the user what was found and what is required for what >> features. >> >> While this will likely take some find tuning, it is a start. >> >> PLEASE, try out the new setup.py in trunk on various platforms and in >> various situations. We need to test this well as it is a huge change. >> >> But, the bottom line is that IPython trunk now has full parallel >> computing capabilities. I will also announce on IPython-users >> >> Next stop: documentation merge!!! >> >> Cheers, >> >> Brian >> _______________________________________________ >> 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 >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Tue Jun 10 14:23:57 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:23:57 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> References: <484EBFDB.3010500@slac.stanford.edu> <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> Message-ID: <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com> I will fix this as well. Thanks. Brian On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones wrote: > Johann, > > Thanks, that seemed to have fixed the problem. I still got the following > warnings, not sure if they impact anything or not. > > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > > > On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi > wrote: >> >> Doug, >> replace ipython by IPython in setupbase.py, at the line where ipengine >> is called and the 2 next ones. >> Johann >> >> ipython-dev-request at scipy.org wrote: >> > Send IPython-dev mailing list submissions to >> > ipython-dev at scipy.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > or, via email, send a message with subject or body 'help' to >> > ipython-dev-request at scipy.org >> > >> > You can reach the person managing the list at >> > ipython-dev-owner at scipy.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of IPython-dev digest..." >> > >> > ------------------------------------------------------------------------ >> > >> > Today's Topics: >> > >> > 1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones) >> > >> > >> > ------------------------------------------------------------------------ >> > >> > Subject: >> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! >> > From: >> > "Doug Jones" >> > Date: >> > Tue, 10 Jun 2008 13:02:12 -0400 >> > To: >> > "Brian Granger" >> > >> > To: >> > "Brian Granger" >> > CC: >> > IPython Development list >> > >> > >> > Hi All, >> > >> > I just gave the newest setup.py a go on my machine and ran into some >> > problems. I've copied its output below. If you need more information, >> > let me know and I will do my best to provide it. >> > >> > Thanks, >> > ~doug >> > >> > >> > python setup.py build >> > >> > ============================================================================ >> > BUILDING IPYTHON >> > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC >> > 4.1.2 (Gentoo 4.1.2 p1.0.1)] >> > platform: linux2 >> > >> > OPTIONAL DEPENDENCIES >> > Zope.Interface: yes >> > Twisted: 2.5.0 >> > Foolscap: 0.2.8 >> > OpenSSL: Not found (required if you want security in the >> > parallel computing capabilities) >> > sphinx: 0.3 >> > pygments: 0.10 >> > nose: 0.9.3 >> > pexpect: 2.1 >> > running build >> > running build_py >> > creating build >> > creating build/lib >> > creating build/lib/IPython >> > copying IPython/wildcard.py -> build/lib/IPython >> > copying IPython/deep_reload.py -> build/lib/IPython >> > copying IPython/macro.py -> build/lib/IPython >> > copying IPython/ipapi.py -> build/lib/IPython >> > copying IPython/rlineimpl.py -> build/lib/IPython >> > copying IPython/CrashHandler.py -> build/lib/IPython >> > copying IPython/Shell.py -> build/lib/IPython >> > copying IPython/ultraTB.py -> build/lib/IPython >> > copying IPython/ipmaker.py -> build/lib/IPython >> > copying IPython/upgrade_dir.py -> build/lib/IPython >> > copying IPython/excolors.py -> build/lib/IPython >> > copying IPython/Release.py -> build/lib/IPython >> > copying IPython/demo.py -> build/lib/IPython >> > copying IPython/OutputTrap.py -> build/lib/IPython >> > copying IPython/shadowns.py -> build/lib/IPython >> > copying IPython/__init__.py -> build/lib/IPython >> > copying IPython/ColorANSI.py -> build/lib/IPython >> > copying IPython/platutils_posix.py -> build/lib/IPython >> > copying IPython/strdispatch.py -> build/lib/IPython >> > copying IPython/generics.py -> build/lib/IPython >> > copying IPython/platutils.py -> build/lib/IPython >> > copying IPython/Debugger.py -> build/lib/IPython >> > copying IPython/GnuplotInteractive.py -> build/lib/IPython >> > copying IPython/ipstruct.py -> build/lib/IPython >> > copying IPython/completer.py -> build/lib/IPython >> > copying IPython/FakeModule.py -> build/lib/IPython >> > copying IPython/usage.py -> build/lib/IPython >> > copying IPython/GnuplotRuntime.py -> build/lib/IPython >> > copying IPython/Logger.py -> build/lib/IPython >> > copying IPython/Prompts.py -> build/lib/IPython >> > copying IPython/numutils.py -> build/lib/IPython >> > copying IPython/ConfigLoader.py -> build/lib/IPython >> > copying IPython/platutils_dummy.py -> build/lib/IPython >> > copying IPython/DPyGetOpt.py -> build/lib/IPython >> > copying IPython/platutils_win32.py -> build/lib/IPython >> > copying IPython/background_jobs.py -> build/lib/IPython >> > copying IPython/iplib.py -> build/lib/IPython >> > copying IPython/dtutils.py -> build/lib/IPython >> > copying IPython/prefilter.py -> build/lib/IPython >> > copying IPython/PyColorize.py -> build/lib/IPython >> > copying IPython/twshell.py -> build/lib/IPython >> > copying IPython/history.py -> build/lib/IPython >> > copying IPython/winconsole.py -> build/lib/IPython >> > copying IPython/shellglobals.py -> build/lib/IPython >> > copying IPython/genutils.py -> build/lib/IPython >> > copying IPython/hooks.py -> build/lib/IPython >> > copying IPython/OInspect.py -> build/lib/IPython >> > copying IPython/Magic.py -> build/lib/IPython >> > copying IPython/irunner.py -> build/lib/IPython >> > copying IPython/Gnuplot2.py -> build/lib/IPython >> > copying IPython/Itpl.py -> build/lib/IPython >> > creating build/lib/IPython/config >> > copying IPython/config/api.py -> build/lib/IPython/config >> > copying IPython/config/__init__.py -> build/lib/IPython/config >> > copying IPython/config/cutils.py -> build/lib/IPython/config >> > copying IPython/config/sconfig.py -> build/lib/IPython/config >> > package init file 'IPython/config/tests/__init__.py' not found (or not >> > a regular file) >> > creating build/lib/IPython/config/tests >> > copying IPython/config/tests/simpleconf.py -> >> > build/lib/IPython/config/tests >> > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests >> > creating build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_autoreload.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_rehashdir.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_sh.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/pickleshare.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/PhysicalQInteractive.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_system_conf.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_doctest.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_gnuglobal.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_traits_completer.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/numeric_formats.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_scipy.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_lookfor.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_vimserver.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/InterpreterExec.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_exportdb.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_signals.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/pspersistence.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/PhysicalQInput.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_none.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_greedycompleter.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_numpy.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ext_rescapture.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/InterpreterPasteInput.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_constants.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_defaults.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_stock_completers.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_app_completers.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_workdir.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_extutil.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_completers.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_profile_zope.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/ipy_editors.py -> >> > build/lib/IPython/Extensions >> > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions >> > creating build/lib/IPython/external >> > copying IPython/external/mglob.py -> build/lib/IPython/external >> > copying IPython/external/path.py -> build/lib/IPython/external >> > copying IPython/external/__init__.py -> build/lib/IPython/external >> > copying IPython/external/simplegeneric.py -> build/lib/IPython/external >> > copying IPython/external/validate.py -> build/lib/IPython/external >> > copying IPython/external/configobj.py -> build/lib/IPython/external >> > copying IPython/external/guid.py -> build/lib/IPython/external >> > copying IPython/external/Itpl.py -> build/lib/IPython/external >> > creating build/lib/IPython/gui >> > copying IPython/gui/__init__.py -> build/lib/IPython/gui >> > creating build/lib/IPython/gui/wx >> > copying IPython/gui/wx/ipshell_nonblocking.py -> >> > build/lib/IPython/gui/wx >> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx >> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx >> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx >> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx >> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx >> > creating build/lib/IPython/kernel >> > copying IPython/kernel/client.py -> build/lib/IPython/kernel >> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel >> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel >> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel >> > copying IPython/kernel/map.py -> build/lib/IPython/kernel >> > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel >> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel >> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel >> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel >> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel >> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel >> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel >> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel >> > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel >> > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel >> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel >> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel >> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel >> > copying IPython/kernel/util.py -> build/lib/IPython/kernel >> > copying IPython/kernel/task.py -> build/lib/IPython/kernel >> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel >> > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel >> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel >> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel >> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel >> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel >> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel >> > copying IPython/kernel/error.py -> build/lib/IPython/kernel >> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel >> > creating build/lib/IPython/kernel/config >> > copying IPython/kernel/config/__init__.py -> >> > build/lib/IPython/kernel/config >> > creating build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_multienginefc.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_controllerservice.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_engineservice.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_task.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_pendingdeferred.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/engineservicetest.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_newserialized.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/__init__.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/multienginetest.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_taskfc.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_enginefc.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/test_multiengine.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/controllertest.py -> >> > build/lib/IPython/kernel/tests >> > copying IPython/kernel/tests/tasktest.py -> >> > build/lib/IPython/kernel/tests >> > creating build/lib/IPython/kernel/scripts >> > copying IPython/kernel/scripts/ipcluster.py -> >> > build/lib/IPython/kernel/scripts >> > copying IPython/kernel/scripts/__init__.py -> >> > build/lib/IPython/kernel/scripts >> > copying IPython/kernel/scripts/ipengine.py -> >> > build/lib/IPython/kernel/scripts >> > copying IPython/kernel/scripts/ipcontroller.py -> >> > build/lib/IPython/kernel/scripts >> > creating build/lib/IPython/kernel/core >> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/display_formatter.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/message_cache.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/traceback_trap.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/output_trap.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/display_trap.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/interpreter.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core >> > copying IPython/kernel/core/traceback_formatter.py -> >> > build/lib/IPython/kernel/core >> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core >> > creating build/lib/IPython/kernel/core/config >> > copying IPython/kernel/core/config/__init__.py -> >> > build/lib/IPython/kernel/core/config >> > creating build/lib/IPython/kernel/core/tests >> > copying IPython/kernel/core/tests/test_shell.py -> >> > build/lib/IPython/kernel/core/tests >> > copying IPython/kernel/core/tests/__init__.py -> >> > build/lib/IPython/kernel/core/tests >> > creating build/lib/IPython/testing >> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing >> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing >> > copying IPython/testing/__init__.py -> build/lib/IPython/testing >> > copying IPython/testing/parametric.py -> build/lib/IPython/testing >> > copying IPython/testing/util.py -> build/lib/IPython/testing >> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing >> > copying IPython/testing/tutils.py -> build/lib/IPython/testing >> > copying IPython/testing/tstTEMPLATE_doctest.py -> >> > build/lib/IPython/testing >> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing >> > creating build/lib/IPython/testing/tests >> > copying IPython/testing/tests/__init__.py -> >> > build/lib/IPython/testing/tests >> > copying IPython/testing/tests/test_testutils.py -> >> > build/lib/IPython/testing/tests >> > creating build/lib/IPython/tools >> > copying IPython/tools/__init__.py -> build/lib/IPython/tools >> > copying IPython/tools/utils.py -> build/lib/IPython/tools >> > copying IPython/tools/growl.py -> build/lib/IPython/tools >> > creating build/lib/IPython/tools/tests >> > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> >> > build/lib/IPython/tools/tests >> > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests >> > copying IPython/tools/tests/test_tools_utils.py -> >> > build/lib/IPython/tools/tests >> > copying IPython/tools/tests/tst_tools_utils_doctest.py -> >> > build/lib/IPython/tools/tests >> > package init file 'IPython/UserConfig/__init__.py' not found (or not a >> > regular file) >> > creating build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipy_user_conf.py -> >> > build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc-physics -> >> > build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc-tutorial -> >> > build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc-numeric -> >> > build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc-pysh -> >> > build/lib/IPython/UserConfig >> > copying IPython/UserConfig/ipythonrc-math -> >> > build/lib/IPython/UserConfig >> > package init file 'IPython/config/tests/__init__.py' not found (or not >> > a regular file) >> > package init file 'IPython/UserConfig/__init__.py' not found (or not a >> > regular file) >> > running build_scripts >> > creating build/scripts-2.5 >> > error: file 'ipython/kernel/scripts/ipengine' does not exist >> > >> > >> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger > > @gmail.com > wrote: >> > >> > Hello all, >> > >> > I have just merged the ipython-ipython1a branch into ipython trunk. >> > This means that most of the stable stuff from ipython1 is now in >> > IPython. This includes the following new subpackages: >> > >> > IPython.kernel >> > IPython.kernel.core >> > IPython.config >> > IPython.tools >> > >> > The biggest change though is that I have refectored the setup.py >> > script. Because these new subpackages have lots of other >> > dependencies, we needed a nice way of handling these things. Here >> > is >> > a skech of how it is being handled: >> > >> > 1. If setuptools is being used, we declare optional requires for >> > the >> > additional deps >> > >> > 2. If setuptools is not being used, we check for the deps manually >> > and simple tell the user what was found and what is required for >> > what >> > features. >> > >> > While this will likely take some find tuning, it is a start. >> > >> > PLEASE, try out the new setup.py in trunk on various platforms and >> > in >> > various situations. We need to test this well as it is a huge >> > change. >> > >> > But, the bottom line is that IPython trunk now has full parallel >> > computing capabilities. I will also announce on IPython-users >> > >> > Next stop: documentation merge!!! >> > >> > Cheers, >> > >> > Brian >> > _______________________________________________ >> > 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 >> > >> _______________________________________________ >> 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 ellisonbg.net at gmail.com Tue Jun 10 14:26:51 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:26:51 -0600 Subject: [IPython-dev] building current bzr trunk : In-Reply-To: <484EC1CF.90602@slac.stanford.edu> References: <484EC1CF.90602@slac.stanford.edu> Message-ID: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> This issue is in the building of zope.interface, which we have never had any problems with. Can you just try the following easy_install zope.interface On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi wrote: > hi there, > after the modif to setupbase of my earlier post, I get: > [cohen at jarrett ipython]$ python setup.py build > ============================================================================ > BUILDING IPYTHON > python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC > 4.1.2 20070925 (Red Hat 4.1.2-33)] > platform: linux2 > > OPTIONAL DEPENDENCIES > Zope.Interface: yes > Twisted: 2.5.0 > Foolscap: Not found (required for parallel computing > capabilities) > OpenSSL: 0.6 > sphinx: Not found (required for building documentation) > pygments: Not found (required for syntax highlighting > documentation) > nose: 0.10.0 > pexpect: 2.3 > running build > running build_py > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > running build_scripts > > So the first thing I want to try then is to get Foolscap.... but: > [root at jarrett ~]# easy_install Foolscap > Searching for Foolscap > Reading http://pypi.python.org/simple/Foolscap/ > Couldn't find index page for 'Foolscap' (maybe misspelled?) > Scanning index of all packages (this may take a while) > Reading http://pypi.python.org/simple/ > Reading http://pypi.python.org/simple/foolscap/ > Reading http://foolscap.lothar.com/ > Reading http://foolscap.lothar.com/trac > Best match: foolscap 0.2.8 > Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz > Processing foolscap-0.2.8.tar.gz > Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 > zip_safe flag not set; analyzing archive contents... > Adding foolscap 0.2.8 to easy-install.pth file > Installing flogtool script to /usr/bin > > Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg > Processing dependencies for Foolscap > Searching for twisted>=2.4.0 > Reading http://pypi.python.org/simple/twisted/ > Reading http://pypi.python.org/simple/Twisted/ > Reading http://twistedmatrix.com/ > Reading http://www.twistedmatrix.com > Reading http://twistedmatrix.com/products/download > Reading http://twistedmatrix.com/projects/core/ > Best match: Twisted 8.1.0 > Downloading > http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 > Processing Twisted-8.1.0.tar.bz2 > Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu > twisted/protocols/_c_urlarg.c: In function 'unquote': > twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing > argument 2 of 'PycStringIO->cwrite' differ in signedness > twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__': > twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but > not used > twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait': > twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but > not used > twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but > not used > twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll': > twisted/python/_epoll.c:508: attention : unused variable 'p' > twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll': > twisted/python/_epoll.c:513: attention : unused variable 'p' > twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll': > twisted/python/_epoll.c:528: attention : unused variable 'p' > twisted/python/_epoll.c:527: attention : unused variable 'e' > twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll': > twisted/python/_epoll.c:533: attention : unused variable 'p' > twisted/python/_epoll.c: Hors de toute fonction : > twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared > 'static' but never defined > twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared > 'static' but never defined > twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared > 'static' but never defined > twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared > 'static' but never defined > twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared > 'static' but never defined > twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static' > but never defined > twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared > 'static' but never defined > twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared > 'static' but never defined > twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared > 'static' but never defined > twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared > 'static' but never defined > twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared > 'static' but never defined > twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared > 'static' but never defined > twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared > 'static' but never defined > twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared > 'static' but never defined > twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared > 'static' but never defined > twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared > 'static' but never defined > twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared > 'static' but never defined > twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi' > declared 'static' but never defined > Adding Twisted 8.1.0 to easy-install.pth file > Installing mailmail script to /usr/bin > Installing cftp script to /usr/bin > Installing tkconch script to /usr/bin > Installing im script to /usr/bin > Installing pyhtmlizer script to /usr/bin > Installing lore script to /usr/bin > Installing tapconvert script to /usr/bin > Installing tap2deb script to /usr/bin > Installing ckeygen script to /usr/bin > Installing t-im script to /usr/bin > Installing twistd script to /usr/bin > Installing trial script to /usr/bin > Installing tap2rpm script to /usr/bin > Installing bookify script to /usr/bin > Installing mktap script to /usr/bin > Installing manhole script to /usr/bin > Installing conch script to /usr/bin > > Installed > /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg > Searching for zope.interface > Reading http://pypi.python.org/simple/zope.interface/ > Reading http://zope.org/Wikis/Interfaces/FrontPage > Best match: zope.interface 3.4.1 > Downloading > http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e > Processing zope.interface-3.4.1.tar.gz > Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm > Traceback (most recent call last): > File "/usr/bin/easy_install", line 8, in > load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 1670, in main > with_ei_usage(lambda: > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 1659, in with_ei_usage > return f() > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 1674, in > distclass=DistributionWithoutHelpCommands, **kw > File "/usr/lib/python2.5/distutils/core.py", line 151, in setup > dist.run_commands() > File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 211, in run > self.easy_install(spec, not self.no_deps) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 446, in easy_install > return self.install_item(spec, dist.location, tmpdir, deps) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 473, in install_item > self.process_distribution(spec, dist, deps) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 519, in process_distribution > [requirement], self.local_index, self.easy_install > File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in > resolve > dist = best[req.key] = env.best_match(req, self, installer) > File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in > best_match > return self.obtain(req, installer) # try and download/install > File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in > obtain > return installer(requirement) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 446, in easy_install > return self.install_item(spec, dist.location, tmpdir, deps) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 471, in install_item > dists = self.install_eggs(spec, download, tmpdir) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 655, in install_eggs > return self.build_and_install(setup_script, setup_base) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 930, in build_and_install > self.run_setup(setup_script, setup_base, args) > File > "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", > line 919, in run_setup > run_setup(setup_script, args) > File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, > in run_setup > lambda: execfile( > File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, > in run > return func() > File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, > in > {'__file__':setup_script, '__name__':'__main__'} > File "setup.py", line 85, in > File "/usr/lib/python2.5/distutils/core.py", line 151, in setup > dist.run_commands() > File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", > line 174, in run > cmd = self.call_command('install_lib', warn_dir=0) > File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", > line 161, in call_command > self.run_command(cmdname) > File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File > "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", > line 20, in run > self.build() > File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in > build > self.run_command('build_ext') > File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", > line 46, in run > _build_ext.run(self) > File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run > self.build_extensions() > File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", > line 82, in build_extensions > self.build_extension(ext) > File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", > line 175, in build_extension > _build_ext.build_extension(self,ext) > File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in > build_extension > sources = self.swig_sources(sources, ext) > File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", > line 77, in swig_sources > sources = _build_ext.swig_sources(self, sources) or sources > TypeError: swig_sources() takes exactly 3 arguments (2 given) > > > and that I do not know what to do with it :) Her is what I have for swig: > [root at jarrett ~]# rpm -qa | grep -i swig > swig-1.3.33-1.fc8 > [root at jarrett ~]# > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From cohen at slac.stanford.edu Tue Jun 10 14:30:08 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 20:30:08 +0200 Subject: [IPython-dev] building current bzr trunk : In-Reply-To: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> References: <484EC1CF.90602@slac.stanford.edu> <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> Message-ID: <484EC830.2020309@slac.stanford.edu> same punishment : [root at jarrett ~]# easy_install zope.interface Searching for zope.interface Reading http://pypi.python.org/simple/zope.interface/ Reading http://zope.org/Wikis/Interfaces/FrontPage Best match: zope.interface 3.4.1 Downloading http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e Processing zope.interface-3.4.1.tar.gz Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-hfnp7Q/zope.interface-3.4.1/egg-dist-tmp-wxiD_u Traceback (most recent call last): File "/usr/bin/easy_install", line 8, in load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1670, in main with_ei_usage(lambda: File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1674, in distclass=DistributionWithoutHelpCommands, **kw File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 471, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, in run_setup lambda: execfile( File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, in run return func() File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, in {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 85, in File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 174, in run cmd = self.call_command('install_lib', warn_dir=0) File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 161, in call_command self.run_command(cmdname) File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", line 20, in run self.build() File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in build self.run_command('build_ext') File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 46, in run _build_ext.run(self) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run self.build_extensions() File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", line 82, in build_extensions self.build_extension(ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 175, in build_extension _build_ext.build_extension(self,ext) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in build_extension sources = self.swig_sources(sources, ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 77, in swig_sources sources = _build_ext.swig_sources(self, sources) or sources TypeError: swig_sources() takes exactly 3 arguments (2 given) Johann Brian Granger wrote: > This issue is in the building of zope.interface, which we have never > had any problems with. Can you just try the following > > easy_install zope.interface > > > > On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi > wrote: > >> hi there, >> after the modif to setupbase of my earlier post, I get: >> [cohen at jarrett ipython]$ python setup.py build >> ============================================================================ >> BUILDING IPYTHON >> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC >> 4.1.2 20070925 (Red Hat 4.1.2-33)] >> platform: linux2 >> >> OPTIONAL DEPENDENCIES >> Zope.Interface: yes >> Twisted: 2.5.0 >> Foolscap: Not found (required for parallel computing >> capabilities) >> OpenSSL: 0.6 >> sphinx: Not found (required for building documentation) >> pygments: Not found (required for syntax highlighting >> documentation) >> nose: 0.10.0 >> pexpect: 2.3 >> running build >> running build_py >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> running build_scripts >> >> So the first thing I want to try then is to get Foolscap.... but: >> [root at jarrett ~]# easy_install Foolscap >> Searching for Foolscap >> Reading http://pypi.python.org/simple/Foolscap/ >> Couldn't find index page for 'Foolscap' (maybe misspelled?) >> Scanning index of all packages (this may take a while) >> Reading http://pypi.python.org/simple/ >> Reading http://pypi.python.org/simple/foolscap/ >> Reading http://foolscap.lothar.com/ >> Reading http://foolscap.lothar.com/trac >> Best match: foolscap 0.2.8 >> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz >> Processing foolscap-0.2.8.tar.gz >> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 >> zip_safe flag not set; analyzing archive contents... >> Adding foolscap 0.2.8 to easy-install.pth file >> Installing flogtool script to /usr/bin >> >> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg >> Processing dependencies for Foolscap >> Searching for twisted>=2.4.0 >> Reading http://pypi.python.org/simple/twisted/ >> Reading http://pypi.python.org/simple/Twisted/ >> Reading http://twistedmatrix.com/ >> Reading http://www.twistedmatrix.com >> Reading http://twistedmatrix.com/products/download >> Reading http://twistedmatrix.com/projects/core/ >> Best match: Twisted 8.1.0 >> Downloading >> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 >> Processing Twisted-8.1.0.tar.bz2 >> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu >> twisted/protocols/_c_urlarg.c: In function 'unquote': >> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__': >> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but >> not used >> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait': >> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but >> not used >> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but >> not used >> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll': >> twisted/python/_epoll.c:508: attention : unused variable 'p' >> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll': >> twisted/python/_epoll.c:513: attention : unused variable 'p' >> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll': >> twisted/python/_epoll.c:528: attention : unused variable 'p' >> twisted/python/_epoll.c:527: attention : unused variable 'e' >> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll': >> twisted/python/_epoll.c:533: attention : unused variable 'p' >> twisted/python/_epoll.c: Hors de toute fonction : >> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared >> 'static' but never defined >> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared >> 'static' but never defined >> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared >> 'static' but never defined >> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared >> 'static' but never defined >> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared >> 'static' but never defined >> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static' >> but never defined >> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared >> 'static' but never defined >> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared >> 'static' but never defined >> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared >> 'static' but never defined >> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared >> 'static' but never defined >> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared >> 'static' but never defined >> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared >> 'static' but never defined >> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared >> 'static' but never defined >> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared >> 'static' but never defined >> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared >> 'static' but never defined >> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared >> 'static' but never defined >> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared >> 'static' but never defined >> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi' >> declared 'static' but never defined >> Adding Twisted 8.1.0 to easy-install.pth file >> Installing mailmail script to /usr/bin >> Installing cftp script to /usr/bin >> Installing tkconch script to /usr/bin >> Installing im script to /usr/bin >> Installing pyhtmlizer script to /usr/bin >> Installing lore script to /usr/bin >> Installing tapconvert script to /usr/bin >> Installing tap2deb script to /usr/bin >> Installing ckeygen script to /usr/bin >> Installing t-im script to /usr/bin >> Installing twistd script to /usr/bin >> Installing trial script to /usr/bin >> Installing tap2rpm script to /usr/bin >> Installing bookify script to /usr/bin >> Installing mktap script to /usr/bin >> Installing manhole script to /usr/bin >> Installing conch script to /usr/bin >> >> Installed >> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg >> Searching for zope.interface >> Reading http://pypi.python.org/simple/zope.interface/ >> Reading http://zope.org/Wikis/Interfaces/FrontPage >> Best match: zope.interface 3.4.1 >> Downloading >> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e >> Processing zope.interface-3.4.1.tar.gz >> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm >> Traceback (most recent call last): >> File "/usr/bin/easy_install", line 8, in >> load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1670, in main >> with_ei_usage(lambda: >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1659, in with_ei_usage >> return f() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1674, in >> distclass=DistributionWithoutHelpCommands, **kw >> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >> dist.run_commands() >> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >> self.run_command(cmd) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 211, in run >> self.easy_install(spec, not self.no_deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 446, in easy_install >> return self.install_item(spec, dist.location, tmpdir, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 473, in install_item >> self.process_distribution(spec, dist, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 519, in process_distribution >> [requirement], self.local_index, self.easy_install >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in >> resolve >> dist = best[req.key] = env.best_match(req, self, installer) >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in >> best_match >> return self.obtain(req, installer) # try and download/install >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in >> obtain >> return installer(requirement) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 446, in easy_install >> return self.install_item(spec, dist.location, tmpdir, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 471, in install_item >> dists = self.install_eggs(spec, download, tmpdir) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 655, in install_eggs >> return self.build_and_install(setup_script, setup_base) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 930, in build_and_install >> self.run_setup(setup_script, setup_base, args) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 919, in run_setup >> run_setup(setup_script, args) >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, >> in run_setup >> lambda: execfile( >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, >> in run >> return func() >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, >> in >> {'__file__':setup_script, '__name__':'__main__'} >> File "setup.py", line 85, in >> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >> dist.run_commands() >> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >> self.run_command(cmd) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >> line 174, in run >> cmd = self.call_command('install_lib', warn_dir=0) >> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >> line 161, in call_command >> self.run_command(cmdname) >> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >> self.distribution.run_command(command) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", >> line 20, in run >> self.build() >> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in >> build >> self.run_command('build_ext') >> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >> self.distribution.run_command(command) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 46, in run >> _build_ext.run(self) >> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run >> self.build_extensions() >> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", >> line 82, in build_extensions >> self.build_extension(ext) >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 175, in build_extension >> _build_ext.build_extension(self,ext) >> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in >> build_extension >> sources = self.swig_sources(sources, ext) >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 77, in swig_sources >> sources = _build_ext.swig_sources(self, sources) or sources >> TypeError: swig_sources() takes exactly 3 arguments (2 given) >> >> >> and that I do not know what to do with it :) Her is what I have for swig: >> [root at jarrett ~]# rpm -qa | grep -i swig >> swig-1.3.33-1.fc8 >> [root at jarrett ~]# >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> >> From cohen at slac.stanford.edu Tue Jun 10 14:31:43 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 20:31:43 +0200 Subject: [IPython-dev] building current bzr trunk : In-Reply-To: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> References: <484EC1CF.90602@slac.stanford.edu> <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> Message-ID: <484EC88F.6010006@slac.stanford.edu> note that I have a zope installation seemingly : [root at jarrett ~]# rpm -qa | grep zope python-zope-interface-3.0.1-8.fc8 [root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8 erreur: D?pendances requises: python-zope-interface est n?cessaire pour (d?j? install?) python-twisted-core-2.5.0-2.fc8.i386 Johann Brian Granger wrote: > This issue is in the building of zope.interface, which we have never > had any problems with. Can you just try the following > > easy_install zope.interface > > > > On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi > wrote: > >> hi there, >> after the modif to setupbase of my earlier post, I get: >> [cohen at jarrett ipython]$ python setup.py build >> ============================================================================ >> BUILDING IPYTHON >> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC >> 4.1.2 20070925 (Red Hat 4.1.2-33)] >> platform: linux2 >> >> OPTIONAL DEPENDENCIES >> Zope.Interface: yes >> Twisted: 2.5.0 >> Foolscap: Not found (required for parallel computing >> capabilities) >> OpenSSL: 0.6 >> sphinx: Not found (required for building documentation) >> pygments: Not found (required for syntax highlighting >> documentation) >> nose: 0.10.0 >> pexpect: 2.3 >> running build >> running build_py >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> running build_scripts >> >> So the first thing I want to try then is to get Foolscap.... but: >> [root at jarrett ~]# easy_install Foolscap >> Searching for Foolscap >> Reading http://pypi.python.org/simple/Foolscap/ >> Couldn't find index page for 'Foolscap' (maybe misspelled?) >> Scanning index of all packages (this may take a while) >> Reading http://pypi.python.org/simple/ >> Reading http://pypi.python.org/simple/foolscap/ >> Reading http://foolscap.lothar.com/ >> Reading http://foolscap.lothar.com/trac >> Best match: foolscap 0.2.8 >> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz >> Processing foolscap-0.2.8.tar.gz >> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 >> zip_safe flag not set; analyzing archive contents... >> Adding foolscap 0.2.8 to easy-install.pth file >> Installing flogtool script to /usr/bin >> >> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg >> Processing dependencies for Foolscap >> Searching for twisted>=2.4.0 >> Reading http://pypi.python.org/simple/twisted/ >> Reading http://pypi.python.org/simple/Twisted/ >> Reading http://twistedmatrix.com/ >> Reading http://www.twistedmatrix.com >> Reading http://twistedmatrix.com/products/download >> Reading http://twistedmatrix.com/projects/core/ >> Best match: Twisted 8.1.0 >> Downloading >> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 >> Processing Twisted-8.1.0.tar.bz2 >> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu >> twisted/protocols/_c_urlarg.c: In function 'unquote': >> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing >> argument 2 of 'PycStringIO->cwrite' differ in signedness >> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__': >> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but >> not used >> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait': >> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but >> not used >> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but >> not used >> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll': >> twisted/python/_epoll.c:508: attention : unused variable 'p' >> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll': >> twisted/python/_epoll.c:513: attention : unused variable 'p' >> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll': >> twisted/python/_epoll.c:528: attention : unused variable 'p' >> twisted/python/_epoll.c:527: attention : unused variable 'e' >> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll': >> twisted/python/_epoll.c:533: attention : unused variable 'p' >> twisted/python/_epoll.c: Hors de toute fonction : >> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared >> 'static' but never defined >> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared >> 'static' but never defined >> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared >> 'static' but never defined >> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared >> 'static' but never defined >> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared >> 'static' but never defined >> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static' >> but never defined >> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared >> 'static' but never defined >> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared >> 'static' but never defined >> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared >> 'static' but never defined >> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared >> 'static' but never defined >> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared >> 'static' but never defined >> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared >> 'static' but never defined >> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared >> 'static' but never defined >> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared >> 'static' but never defined >> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared >> 'static' but never defined >> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared >> 'static' but never defined >> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared >> 'static' but never defined >> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi' >> declared 'static' but never defined >> Adding Twisted 8.1.0 to easy-install.pth file >> Installing mailmail script to /usr/bin >> Installing cftp script to /usr/bin >> Installing tkconch script to /usr/bin >> Installing im script to /usr/bin >> Installing pyhtmlizer script to /usr/bin >> Installing lore script to /usr/bin >> Installing tapconvert script to /usr/bin >> Installing tap2deb script to /usr/bin >> Installing ckeygen script to /usr/bin >> Installing t-im script to /usr/bin >> Installing twistd script to /usr/bin >> Installing trial script to /usr/bin >> Installing tap2rpm script to /usr/bin >> Installing bookify script to /usr/bin >> Installing mktap script to /usr/bin >> Installing manhole script to /usr/bin >> Installing conch script to /usr/bin >> >> Installed >> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg >> Searching for zope.interface >> Reading http://pypi.python.org/simple/zope.interface/ >> Reading http://zope.org/Wikis/Interfaces/FrontPage >> Best match: zope.interface 3.4.1 >> Downloading >> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e >> Processing zope.interface-3.4.1.tar.gz >> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir >> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm >> Traceback (most recent call last): >> File "/usr/bin/easy_install", line 8, in >> load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1670, in main >> with_ei_usage(lambda: >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1659, in with_ei_usage >> return f() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 1674, in >> distclass=DistributionWithoutHelpCommands, **kw >> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >> dist.run_commands() >> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >> self.run_command(cmd) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 211, in run >> self.easy_install(spec, not self.no_deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 446, in easy_install >> return self.install_item(spec, dist.location, tmpdir, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 473, in install_item >> self.process_distribution(spec, dist, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 519, in process_distribution >> [requirement], self.local_index, self.easy_install >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in >> resolve >> dist = best[req.key] = env.best_match(req, self, installer) >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in >> best_match >> return self.obtain(req, installer) # try and download/install >> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in >> obtain >> return installer(requirement) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 446, in easy_install >> return self.install_item(spec, dist.location, tmpdir, deps) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 471, in install_item >> dists = self.install_eggs(spec, download, tmpdir) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 655, in install_eggs >> return self.build_and_install(setup_script, setup_base) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 930, in build_and_install >> self.run_setup(setup_script, setup_base, args) >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >> line 919, in run_setup >> run_setup(setup_script, args) >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, >> in run_setup >> lambda: execfile( >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, >> in run >> return func() >> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, >> in >> {'__file__':setup_script, '__name__':'__main__'} >> File "setup.py", line 85, in >> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >> dist.run_commands() >> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >> self.run_command(cmd) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >> line 174, in run >> cmd = self.call_command('install_lib', warn_dir=0) >> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >> line 161, in call_command >> self.run_command(cmdname) >> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >> self.distribution.run_command(command) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File >> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", >> line 20, in run >> self.build() >> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in >> build >> self.run_command('build_ext') >> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >> self.distribution.run_command(command) >> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >> cmd_obj.run() >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 46, in run >> _build_ext.run(self) >> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run >> self.build_extensions() >> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", >> line 82, in build_extensions >> self.build_extension(ext) >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 175, in build_extension >> _build_ext.build_extension(self,ext) >> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in >> build_extension >> sources = self.swig_sources(sources, ext) >> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >> line 77, in swig_sources >> sources = _build_ext.swig_sources(self, sources) or sources >> TypeError: swig_sources() takes exactly 3 arguments (2 given) >> >> >> and that I do not know what to do with it :) Her is what I have for swig: >> [root at jarrett ~]# rpm -qa | grep -i swig >> swig-1.3.33-1.fc8 >> [root at jarrett ~]# >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> >> From ellisonbg.net at gmail.com Tue Jun 10 14:35:14 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:35:14 -0600 Subject: [IPython-dev] building current bzr trunk : In-Reply-To: <484EC88F.6010006@slac.stanford.edu> References: <484EC1CF.90602@slac.stanford.edu> <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> <484EC88F.6010006@slac.stanford.edu> Message-ID: <6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com> IPython should run fine with these older version of twisted and zope.interface. But, I would like to try to understand what the problem is. I am going to look at this and get back to you shortly. Two other questions: 1) What version of setuptools are you running? 2) Can you retry with swig uninstalled? Thanks Brian On Tue, Jun 10, 2008 at 12:31 PM, Johann Cohen-Tanugi wrote: > note that I have a zope installation seemingly : > [root at jarrett ~]# rpm -qa | grep zope > python-zope-interface-3.0.1-8.fc8 > [root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8 > erreur: D?pendances requises: > python-zope-interface est n?cessaire pour (d?j? install?) > python-twisted-core-2.5.0-2.fc8.i386 > > Johann > > Brian Granger wrote: >> >> This issue is in the building of zope.interface, which we have never >> had any problems with. Can you just try the following >> >> easy_install zope.interface >> >> >> >> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi >> wrote: >> >>> >>> hi there, >>> after the modif to setupbase of my earlier post, I get: >>> [cohen at jarrett ipython]$ python setup.py build >>> >>> ============================================================================ >>> BUILDING IPYTHON >>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC >>> 4.1.2 20070925 (Red Hat 4.1.2-33)] >>> platform: linux2 >>> >>> OPTIONAL DEPENDENCIES >>> Zope.Interface: yes >>> Twisted: 2.5.0 >>> Foolscap: Not found (required for parallel computing >>> capabilities) >>> OpenSSL: 0.6 >>> sphinx: Not found (required for building documentation) >>> pygments: Not found (required for syntax highlighting >>> documentation) >>> nose: 0.10.0 >>> pexpect: 2.3 >>> running build >>> running build_py >>> package init file 'IPython/config/tests/__init__.py' not found (or not a >>> regular file) >>> package init file 'IPython/UserConfig/__init__.py' not found (or not a >>> regular file) >>> package init file 'IPython/config/tests/__init__.py' not found (or not a >>> regular file) >>> package init file 'IPython/UserConfig/__init__.py' not found (or not a >>> regular file) >>> running build_scripts >>> >>> So the first thing I want to try then is to get Foolscap.... but: >>> [root at jarrett ~]# easy_install Foolscap >>> Searching for Foolscap >>> Reading http://pypi.python.org/simple/Foolscap/ >>> Couldn't find index page for 'Foolscap' (maybe misspelled?) >>> Scanning index of all packages (this may take a while) >>> Reading http://pypi.python.org/simple/ >>> Reading http://pypi.python.org/simple/foolscap/ >>> Reading http://foolscap.lothar.com/ >>> Reading http://foolscap.lothar.com/trac >>> Best match: foolscap 0.2.8 >>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz >>> Processing foolscap-0.2.8.tar.gz >>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir >>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 >>> zip_safe flag not set; analyzing archive contents... >>> Adding foolscap 0.2.8 to easy-install.pth file >>> Installing flogtool script to /usr/bin >>> >>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg >>> Processing dependencies for Foolscap >>> Searching for twisted>=2.4.0 >>> Reading http://pypi.python.org/simple/twisted/ >>> Reading http://pypi.python.org/simple/Twisted/ >>> Reading http://twistedmatrix.com/ >>> Reading http://www.twistedmatrix.com >>> Reading http://twistedmatrix.com/products/download >>> Reading http://twistedmatrix.com/projects/core/ >>> Best match: Twisted 8.1.0 >>> Downloading >>> >>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 >>> Processing Twisted-8.1.0.tar.bz2 >>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir >>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu >>> twisted/protocols/_c_urlarg.c: In function 'unquote': >>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing >>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>> twisted/python/_epoll.c: In function >>> '__pyx_f_6_epoll_5epoll___dealloc__': >>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but >>> not used >>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait': >>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but >>> not used >>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but >>> not used >>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll': >>> twisted/python/_epoll.c:508: attention : unused variable 'p' >>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll': >>> twisted/python/_epoll.c:513: attention : unused variable 'p' >>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll': >>> twisted/python/_epoll.c:528: attention : unused variable 'p' >>> twisted/python/_epoll.c:527: attention : unused variable 'e' >>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll': >>> twisted/python/_epoll.c:533: attention : unused variable 'p' >>> twisted/python/_epoll.c: Hors de toute fonction : >>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static' >>> but never defined >>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared >>> 'static' but never defined >>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi' >>> declared 'static' but never defined >>> Adding Twisted 8.1.0 to easy-install.pth file >>> Installing mailmail script to /usr/bin >>> Installing cftp script to /usr/bin >>> Installing tkconch script to /usr/bin >>> Installing im script to /usr/bin >>> Installing pyhtmlizer script to /usr/bin >>> Installing lore script to /usr/bin >>> Installing tapconvert script to /usr/bin >>> Installing tap2deb script to /usr/bin >>> Installing ckeygen script to /usr/bin >>> Installing t-im script to /usr/bin >>> Installing twistd script to /usr/bin >>> Installing trial script to /usr/bin >>> Installing tap2rpm script to /usr/bin >>> Installing bookify script to /usr/bin >>> Installing mktap script to /usr/bin >>> Installing manhole script to /usr/bin >>> Installing conch script to /usr/bin >>> >>> Installed >>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg >>> Searching for zope.interface >>> Reading http://pypi.python.org/simple/zope.interface/ >>> Reading http://zope.org/Wikis/Interfaces/FrontPage >>> Best match: zope.interface 3.4.1 >>> Downloading >>> >>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e >>> Processing zope.interface-3.4.1.tar.gz >>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir >>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm >>> Traceback (most recent call last): >>> File "/usr/bin/easy_install", line 8, in >>> load_entry_point('setuptools==0.6c7', 'console_scripts', >>> 'easy_install')() >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 1670, in main >>> with_ei_usage(lambda: >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 1659, in with_ei_usage >>> return f() >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 1674, in >>> distclass=DistributionWithoutHelpCommands, **kw >>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >>> dist.run_commands() >>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >>> self.run_command(cmd) >>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>> cmd_obj.run() >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 211, in run >>> self.easy_install(spec, not self.no_deps) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 446, in easy_install >>> return self.install_item(spec, dist.location, tmpdir, deps) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 473, in install_item >>> self.process_distribution(spec, dist, deps) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 519, in process_distribution >>> [requirement], self.local_index, self.easy_install >>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in >>> resolve >>> dist = best[req.key] = env.best_match(req, self, installer) >>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in >>> best_match >>> return self.obtain(req, installer) # try and download/install >>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in >>> obtain >>> return installer(requirement) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 446, in easy_install >>> return self.install_item(spec, dist.location, tmpdir, deps) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 471, in install_item >>> dists = self.install_eggs(spec, download, tmpdir) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 655, in install_eggs >>> return self.build_and_install(setup_script, setup_base) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 930, in build_and_install >>> self.run_setup(setup_script, setup_base, args) >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>> line 919, in run_setup >>> run_setup(setup_script, args) >>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, >>> in run_setup >>> lambda: execfile( >>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, >>> in run >>> return func() >>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, >>> in >>> {'__file__':setup_script, '__name__':'__main__'} >>> File "setup.py", line 85, in >>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >>> dist.run_commands() >>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >>> self.run_command(cmd) >>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>> cmd_obj.run() >>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >>> line 174, in run >>> cmd = self.call_command('install_lib', warn_dir=0) >>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >>> line 161, in call_command >>> self.run_command(cmdname) >>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >>> self.distribution.run_command(command) >>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>> cmd_obj.run() >>> File >>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", >>> line 20, in run >>> self.build() >>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in >>> build >>> self.run_command('build_ext') >>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >>> self.distribution.run_command(command) >>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>> cmd_obj.run() >>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>> line 46, in run >>> _build_ext.run(self) >>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in >>> run >>> self.build_extensions() >>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", >>> line 82, in build_extensions >>> self.build_extension(ext) >>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>> line 175, in build_extension >>> _build_ext.build_extension(self,ext) >>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in >>> build_extension >>> sources = self.swig_sources(sources, ext) >>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>> line 77, in swig_sources >>> sources = _build_ext.swig_sources(self, sources) or sources >>> TypeError: swig_sources() takes exactly 3 arguments (2 given) >>> >>> >>> and that I do not know what to do with it :) Her is what I have for swig: >>> [root at jarrett ~]# rpm -qa | grep -i swig >>> swig-1.3.33-1.fc8 >>> [root at jarrett ~]# >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>> >>> > From ellisonbg.net at gmail.com Tue Jun 10 14:37:29 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:37:29 -0600 Subject: [IPython-dev] feature? In-Reply-To: <484EC4B7.6010309@slac.stanford.edu> References: <484EC4B7.6010309@slac.stanford.edu> Message-ID: <6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com> On Tue, Jun 10, 2008 at 12:15 PM, Johann Cohen-Tanugi wrote: > More on my issues with current bzr trunk : I installed sphinx without > trouble so only Foolscap seems to be a problem. But when I try to build > ipython again, just for the sake of it, it now outputs : > [cohen at jarrett ipython]$ python setup.py build > ============================================================================ > BUILDING IPYTHON > python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC > 4.1.2 20070925 (Red Hat 4.1.2-33)] > platform: linux2 > > OPTIONAL DEPENDENCIES > Zope.Interface: yes > Twisted: 8.1.0 > Foolscap: 0.2.8 > OpenSSL: 0.6 > sphinx: 0.3 > pygments: 0.10 > nose: 0.10.0 > pexpect: 2.3 > running build > running build_py > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > running build_scripts > > Only the Foolscap egg is there, which seems to be enough for ipython at > this stage. Do we really want that behavior? > best, I am not sure that I follow you. The dependency check shows that it has found acceptable versions of all the dependencies. Can you just run: $ trial IPython or nosetests IPython To run the test suite and see what you get? Thanks Brian From cohen at slac.stanford.edu Tue Jun 10 14:49:22 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 20:49:22 +0200 Subject: [IPython-dev] building current bzr trunk : In-Reply-To: <6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com> References: <484EC1CF.90602@slac.stanford.edu> <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com> <484EC88F.6010006@slac.stanford.edu> <6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com> Message-ID: <484ECCB2.2020703@slac.stanford.edu> Brian Granger wrote: > IPython should run fine with these older version of twisted and > zope.interface. But, I would like to try to understand what the > problem is. I am going to look at this and get back to you shortly. > Two other questions: > > 1) What version of setuptools are you running? > [root at jarrett ~]# rpm -qa | grep setuptools python-setuptools-0.6c7-2.fc8 python-setuptools-devel-0.6c7-2.fc8 > 2) Can you retry with swig uninstalled? > > same thing : [root at jarrett ~]# rpm -qa | grep swig swig-1.3.33-1.fc8 [root at jarrett ~]# rpm --erase swig-1.3.33-1.fc8 [root at jarrett ~]# easy_install Foolscap Searching for Foolscap Best match: foolscap 0.2.8 Processing foolscap-0.2.8-py2.5.egg foolscap 0.2.8 is already the active version in easy-install.pth Installing flogtool script to /usr/bin Using /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg Processing dependencies for Foolscap Searching for zope.interface Reading http://pypi.python.org/simple/zope.interface/ Reading http://zope.org/Wikis/Interfaces/FrontPage Best match: zope.interface 3.4.1 Downloading http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e Processing zope.interface-3.4.1.tar.gz Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-wHIZ1P/zope.interface-3.4.1/egg-dist-tmp-xJAIQI Traceback (most recent call last): File "/usr/bin/easy_install", line 8, in load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1670, in main with_ei_usage(lambda: File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1674, in distclass=DistributionWithoutHelpCommands, **kw File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 476, in install_item self.process_distribution(spec, dists[0], deps, "Using") File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 519, in process_distribution [requirement], self.local_index, self.easy_install File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in best_match return self.obtain(req, installer) # try and download/install File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in obtain return installer(requirement) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 471, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, in run_setup lambda: execfile( File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, in run return func() File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, in {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 85, in File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 174, in run cmd = self.call_command('install_lib', warn_dir=0) File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 161, in call_command self.run_command(cmdname) File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", line 20, in run self.build() File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in build self.run_command('build_ext') File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 46, in run _build_ext.run(self) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run self.build_extensions() File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", line 82, in build_extensions self.build_extension(ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 175, in build_extension _build_ext.build_extension(self,ext) File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in build_extension sources = self.swig_sources(sources, ext) File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 77, in swig_sources sources = _build_ext.swig_sources(self, sources) or sources TypeError: swig_sources() takes exactly 3 arguments (2 given) > Thanks > > > > Brian > > On Tue, Jun 10, 2008 at 12:31 PM, Johann Cohen-Tanugi > wrote: > >> note that I have a zope installation seemingly : >> [root at jarrett ~]# rpm -qa | grep zope >> python-zope-interface-3.0.1-8.fc8 >> [root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8 >> erreur: D?pendances requises: >> python-zope-interface est n?cessaire pour (d?j? install?) >> python-twisted-core-2.5.0-2.fc8.i386 >> >> Johann >> >> Brian Granger wrote: >> >>> This issue is in the building of zope.interface, which we have never >>> had any problems with. Can you just try the following >>> >>> easy_install zope.interface >>> >>> >>> >>> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi >>> wrote: >>> >>> >>>> hi there, >>>> after the modif to setupbase of my earlier post, I get: >>>> [cohen at jarrett ipython]$ python setup.py build >>>> >>>> ============================================================================ >>>> BUILDING IPYTHON >>>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC >>>> 4.1.2 20070925 (Red Hat 4.1.2-33)] >>>> platform: linux2 >>>> >>>> OPTIONAL DEPENDENCIES >>>> Zope.Interface: yes >>>> Twisted: 2.5.0 >>>> Foolscap: Not found (required for parallel computing >>>> capabilities) >>>> OpenSSL: 0.6 >>>> sphinx: Not found (required for building documentation) >>>> pygments: Not found (required for syntax highlighting >>>> documentation) >>>> nose: 0.10.0 >>>> pexpect: 2.3 >>>> running build >>>> running build_py >>>> package init file 'IPython/config/tests/__init__.py' not found (or not a >>>> regular file) >>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a >>>> regular file) >>>> package init file 'IPython/config/tests/__init__.py' not found (or not a >>>> regular file) >>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a >>>> regular file) >>>> running build_scripts >>>> >>>> So the first thing I want to try then is to get Foolscap.... but: >>>> [root at jarrett ~]# easy_install Foolscap >>>> Searching for Foolscap >>>> Reading http://pypi.python.org/simple/Foolscap/ >>>> Couldn't find index page for 'Foolscap' (maybe misspelled?) >>>> Scanning index of all packages (this may take a while) >>>> Reading http://pypi.python.org/simple/ >>>> Reading http://pypi.python.org/simple/foolscap/ >>>> Reading http://foolscap.lothar.com/ >>>> Reading http://foolscap.lothar.com/trac >>>> Best match: foolscap 0.2.8 >>>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz >>>> Processing foolscap-0.2.8.tar.gz >>>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir >>>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8 >>>> zip_safe flag not set; analyzing archive contents... >>>> Adding foolscap 0.2.8 to easy-install.pth file >>>> Installing flogtool script to /usr/bin >>>> >>>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg >>>> Processing dependencies for Foolscap >>>> Searching for twisted>=2.4.0 >>>> Reading http://pypi.python.org/simple/twisted/ >>>> Reading http://pypi.python.org/simple/Twisted/ >>>> Reading http://twistedmatrix.com/ >>>> Reading http://www.twistedmatrix.com >>>> Reading http://twistedmatrix.com/products/download >>>> Reading http://twistedmatrix.com/projects/core/ >>>> Best match: Twisted 8.1.0 >>>> Downloading >>>> >>>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3 >>>> Processing Twisted-8.1.0.tar.bz2 >>>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir >>>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu >>>> twisted/protocols/_c_urlarg.c: In function 'unquote': >>>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing >>>> argument 2 of 'PycStringIO->cwrite' differ in signedness >>>> twisted/python/_epoll.c: In function >>>> '__pyx_f_6_epoll_5epoll___dealloc__': >>>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but >>>> not used >>>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait': >>>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but >>>> not used >>>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but >>>> not used >>>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll': >>>> twisted/python/_epoll.c:508: attention : unused variable 'p' >>>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll': >>>> twisted/python/_epoll.c:513: attention : unused variable 'p' >>>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll': >>>> twisted/python/_epoll.c:528: attention : unused variable 'p' >>>> twisted/python/_epoll.c:527: attention : unused variable 'e' >>>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll': >>>> twisted/python/_epoll.c:533: attention : unused variable 'p' >>>> twisted/python/_epoll.c: Hors de toute fonction : >>>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static' >>>> but never defined >>>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared >>>> 'static' but never defined >>>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi' >>>> declared 'static' but never defined >>>> Adding Twisted 8.1.0 to easy-install.pth file >>>> Installing mailmail script to /usr/bin >>>> Installing cftp script to /usr/bin >>>> Installing tkconch script to /usr/bin >>>> Installing im script to /usr/bin >>>> Installing pyhtmlizer script to /usr/bin >>>> Installing lore script to /usr/bin >>>> Installing tapconvert script to /usr/bin >>>> Installing tap2deb script to /usr/bin >>>> Installing ckeygen script to /usr/bin >>>> Installing t-im script to /usr/bin >>>> Installing twistd script to /usr/bin >>>> Installing trial script to /usr/bin >>>> Installing tap2rpm script to /usr/bin >>>> Installing bookify script to /usr/bin >>>> Installing mktap script to /usr/bin >>>> Installing manhole script to /usr/bin >>>> Installing conch script to /usr/bin >>>> >>>> Installed >>>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg >>>> Searching for zope.interface >>>> Reading http://pypi.python.org/simple/zope.interface/ >>>> Reading http://zope.org/Wikis/Interfaces/FrontPage >>>> Best match: zope.interface 3.4.1 >>>> Downloading >>>> >>>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e >>>> Processing zope.interface-3.4.1.tar.gz >>>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir >>>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm >>>> Traceback (most recent call last): >>>> File "/usr/bin/easy_install", line 8, in >>>> load_entry_point('setuptools==0.6c7', 'console_scripts', >>>> 'easy_install')() >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 1670, in main >>>> with_ei_usage(lambda: >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 1659, in with_ei_usage >>>> return f() >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 1674, in >>>> distclass=DistributionWithoutHelpCommands, **kw >>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >>>> dist.run_commands() >>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >>>> self.run_command(cmd) >>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>>> cmd_obj.run() >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 211, in run >>>> self.easy_install(spec, not self.no_deps) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 446, in easy_install >>>> return self.install_item(spec, dist.location, tmpdir, deps) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 473, in install_item >>>> self.process_distribution(spec, dist, deps) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 519, in process_distribution >>>> [requirement], self.local_index, self.easy_install >>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in >>>> resolve >>>> dist = best[req.key] = env.best_match(req, self, installer) >>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in >>>> best_match >>>> return self.obtain(req, installer) # try and download/install >>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in >>>> obtain >>>> return installer(requirement) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 446, in easy_install >>>> return self.install_item(spec, dist.location, tmpdir, deps) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 471, in install_item >>>> dists = self.install_eggs(spec, download, tmpdir) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 655, in install_eggs >>>> return self.build_and_install(setup_script, setup_base) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 930, in build_and_install >>>> self.run_setup(setup_script, setup_base, args) >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", >>>> line 919, in run_setup >>>> run_setup(setup_script, args) >>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, >>>> in run_setup >>>> lambda: execfile( >>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, >>>> in run >>>> return func() >>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, >>>> in >>>> {'__file__':setup_script, '__name__':'__main__'} >>>> File "setup.py", line 85, in >>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup >>>> dist.run_commands() >>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands >>>> self.run_command(cmd) >>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>>> cmd_obj.run() >>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >>>> line 174, in run >>>> cmd = self.call_command('install_lib', warn_dir=0) >>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", >>>> line 161, in call_command >>>> self.run_command(cmdname) >>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >>>> self.distribution.run_command(command) >>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>>> cmd_obj.run() >>>> File >>>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", >>>> line 20, in run >>>> self.build() >>>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in >>>> build >>>> self.run_command('build_ext') >>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command >>>> self.distribution.run_command(command) >>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command >>>> cmd_obj.run() >>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>>> line 46, in run >>>> _build_ext.run(self) >>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in >>>> run >>>> self.build_extensions() >>>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", >>>> line 82, in build_extensions >>>> self.build_extension(ext) >>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>>> line 175, in build_extension >>>> _build_ext.build_extension(self,ext) >>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in >>>> build_extension >>>> sources = self.swig_sources(sources, ext) >>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", >>>> line 77, in swig_sources >>>> sources = _build_ext.swig_sources(self, sources) or sources >>>> TypeError: swig_sources() takes exactly 3 arguments (2 given) >>>> >>>> >>>> and that I do not know what to do with it :) Her is what I have for swig: >>>> [root at jarrett ~]# rpm -qa | grep -i swig >>>> swig-1.3.33-1.fc8 >>>> [root at jarrett ~]# >>>> >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> IPython-dev at scipy.org >>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>>> >>>> >>>> From ellisonbg.net at gmail.com Tue Jun 10 14:54:11 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:54:11 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com> References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com> <1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com> Message-ID: <6ce0ac130806101154p763fbd2aq2eb72024653c04a1@mail.gmail.com> This is now fixed in trunk. Please pull the latest and try again and let us know how it goes. Brian On Tue, Jun 10, 2008 at 11:02 AM, Doug Jones wrote: > Hi All, > > I just gave the newest setup.py a go on my machine and ran into some > problems. I've copied its output below. If you need more information, let me > know and I will do my best to provide it. > > Thanks, > ~doug > > > python setup.py build > ============================================================================ > BUILDING IPYTHON > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC > 4.1.2 (Gentoo 4.1.2 p1.0.1)] > platform: linux2 > > OPTIONAL DEPENDENCIES > Zope.Interface: yes > Twisted: 2.5.0 > Foolscap: 0.2.8 > OpenSSL: Not found (required if you want security in the > parallel computing capabilities) > sphinx: 0.3 > pygments: 0.10 > nose: 0.9.3 > pexpect: 2.1 > running build > running build_py > creating build > creating build/lib > creating build/lib/IPython > copying IPython/wildcard.py -> build/lib/IPython > copying IPython/deep_reload.py -> build/lib/IPython > copying IPython/macro.py -> build/lib/IPython > copying IPython/ipapi.py -> build/lib/IPython > copying IPython/rlineimpl.py -> build/lib/IPython > copying IPython/CrashHandler.py -> build/lib/IPython > copying IPython/Shell.py -> build/lib/IPython > copying IPython/ultraTB.py -> build/lib/IPython > copying IPython/ipmaker.py -> build/lib/IPython > copying IPython/upgrade_dir.py -> build/lib/IPython > copying IPython/excolors.py -> build/lib/IPython > copying IPython/Release.py -> build/lib/IPython > copying IPython/demo.py -> build/lib/IPython > copying IPython/OutputTrap.py -> build/lib/IPython > copying IPython/shadowns.py -> build/lib/IPython > copying IPython/__init__.py -> build/lib/IPython > copying IPython/ColorANSI.py -> build/lib/IPython > copying IPython/platutils_posix.py -> build/lib/IPython > copying IPython/strdispatch.py -> build/lib/IPython > copying IPython/generics.py -> build/lib/IPython > copying IPython/platutils.py -> build/lib/IPython > copying IPython/Debugger.py -> build/lib/IPython > copying IPython/GnuplotInteractive.py -> build/lib/IPython > copying IPython/ipstruct.py -> build/lib/IPython > copying IPython/completer.py -> build/lib/IPython > copying IPython/FakeModule.py -> build/lib/IPython > copying IPython/usage.py -> build/lib/IPython > copying IPython/GnuplotRuntime.py -> build/lib/IPython > copying IPython/Logger.py -> build/lib/IPython > copying IPython/Prompts.py -> build/lib/IPython > copying IPython/numutils.py -> build/lib/IPython > copying IPython/ConfigLoader.py -> build/lib/IPython > copying IPython/platutils_dummy.py -> build/lib/IPython > copying IPython/DPyGetOpt.py -> build/lib/IPython > copying IPython/platutils_win32.py -> build/lib/IPython > copying IPython/background_jobs.py -> build/lib/IPython > copying IPython/iplib.py -> build/lib/IPython > copying IPython/dtutils.py -> build/lib/IPython > copying IPython/prefilter.py -> build/lib/IPython > copying IPython/PyColorize.py -> build/lib/IPython > copying IPython/twshell.py -> build/lib/IPython > copying IPython/history.py -> build/lib/IPython > copying IPython/winconsole.py -> build/lib/IPython > copying IPython/shellglobals.py -> build/lib/IPython > copying IPython/genutils.py -> build/lib/IPython > copying IPython/hooks.py -> build/lib/IPython > copying IPython/OInspect.py -> build/lib/IPython > copying IPython/Magic.py -> build/lib/IPython > copying IPython/irunner.py -> build/lib/IPython > copying IPython/Gnuplot2.py -> build/lib/IPython > copying IPython/Itpl.py -> build/lib/IPython > creating build/lib/IPython/config > copying IPython/config/api.py -> build/lib/IPython/config > copying IPython/config/__init__.py -> build/lib/IPython/config > copying IPython/config/cutils.py -> build/lib/IPython/config > copying IPython/config/sconfig.py -> build/lib/IPython/config > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > creating build/lib/IPython/config/tests > copying IPython/config/tests/simpleconf.py -> build/lib/IPython/config/tests > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests > creating build/lib/IPython/Extensions > copying IPython/Extensions/ipy_autoreload.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_rehashdir.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_sh.py -> build/lib/IPython/Extensions > copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions > copying IPython/Extensions/PhysicalQInteractive.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_system_conf.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_doctest.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_gnuglobal.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_traits_completer.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/numeric_formats.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_scipy.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_vimserver.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions > copying IPython/Extensions/InterpreterExec.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions > copying IPython/Extensions/pspersistence.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions > copying IPython/Extensions/PhysicalQInput.py -> build/lib/IPython/Extensions > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_none.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_greedycompleter.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_numpy.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ext_rescapture.py -> build/lib/IPython/Extensions > copying IPython/Extensions/InterpreterPasteInput.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_constants.py -> build/lib/IPython/Extensions > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_stock_completers.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_app_completers.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_completers.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions > copying IPython/Extensions/ipy_profile_zope.py -> > build/lib/IPython/Extensions > copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions > creating build/lib/IPython/external > copying IPython/external/mglob.py -> build/lib/IPython/external > copying IPython/external/path.py -> build/lib/IPython/external > copying IPython/external/__init__.py -> build/lib/IPython/external > copying IPython/external/simplegeneric.py -> build/lib/IPython/external > copying IPython/external/validate.py -> build/lib/IPython/external > copying IPython/external/configobj.py -> build/lib/IPython/external > copying IPython/external/guid.py -> build/lib/IPython/external > copying IPython/external/Itpl.py -> build/lib/IPython/external > creating build/lib/IPython/gui > copying IPython/gui/__init__.py -> build/lib/IPython/gui > creating build/lib/IPython/gui/wx > copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx > creating build/lib/IPython/kernel > copying IPython/kernel/client.py -> build/lib/IPython/kernel > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel > copying IPython/kernel/map.py -> build/lib/IPython/kernel > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel > copying IPython/kernel/magic.py -> build/lib/IPython/kernel > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel > copying IPython/kernel/util.py -> build/lib/IPython/kernel > copying IPython/kernel/task.py -> build/lib/IPython/kernel > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel > copying IPython/kernel/error.py -> build/lib/IPython/kernel > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel > creating build/lib/IPython/kernel/config > copying IPython/kernel/config/__init__.py -> build/lib/IPython/kernel/config > creating build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_multienginefc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_controllerservice.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_engineservice.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_task.py -> build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_pendingdeferred.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/engineservicetest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_newserialized.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests > copying IPython/kernel/tests/multienginetest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_taskfc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_enginefc.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/test_multiengine.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/controllertest.py -> > build/lib/IPython/kernel/tests > copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests > creating build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipcluster.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/__init__.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipengine.py -> > build/lib/IPython/kernel/scripts > copying IPython/kernel/scripts/ipcontroller.py -> > build/lib/IPython/kernel/scripts > creating build/lib/IPython/kernel/core > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/display_formatter.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/message_cache.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/traceback_trap.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/output_trap.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/display_trap.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/interpreter.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core > copying IPython/kernel/core/traceback_formatter.py -> > build/lib/IPython/kernel/core > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core > creating build/lib/IPython/kernel/core/config > copying IPython/kernel/core/config/__init__.py -> > build/lib/IPython/kernel/core/config > creating build/lib/IPython/kernel/core/tests > copying IPython/kernel/core/tests/test_shell.py -> > build/lib/IPython/kernel/core/tests > copying IPython/kernel/core/tests/__init__.py -> > build/lib/IPython/kernel/core/tests > creating build/lib/IPython/testing > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing > copying IPython/testing/__init__.py -> build/lib/IPython/testing > copying IPython/testing/parametric.py -> build/lib/IPython/testing > copying IPython/testing/util.py -> build/lib/IPython/testing > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing > copying IPython/testing/tutils.py -> build/lib/IPython/testing > copying IPython/testing/tstTEMPLATE_doctest.py -> build/lib/IPython/testing > copying IPython/testing/tcommon.py -> build/lib/IPython/testing > creating build/lib/IPython/testing/tests > copying IPython/testing/tests/__init__.py -> build/lib/IPython/testing/tests > copying IPython/testing/tests/test_testutils.py -> > build/lib/IPython/testing/tests > creating build/lib/IPython/tools > copying IPython/tools/__init__.py -> build/lib/IPython/tools > copying IPython/tools/utils.py -> build/lib/IPython/tools > copying IPython/tools/growl.py -> build/lib/IPython/tools > creating build/lib/IPython/tools/tests > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> > build/lib/IPython/tools/tests > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests > copying IPython/tools/tests/test_tools_utils.py -> > build/lib/IPython/tools/tests > copying IPython/tools/tests/tst_tools_utils_doctest.py -> > build/lib/IPython/tools/tests > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > creating build/lib/IPython/UserConfig > copying IPython/UserConfig/ipy_user_conf.py -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-physics -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-tutorial -> > build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-numeric -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig > copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig > package init file 'IPython/config/tests/__init__.py' not found (or not a > regular file) > package init file 'IPython/UserConfig/__init__.py' not found (or not a > regular file) > running build_scripts > creating build/scripts-2.5 > error: file 'ipython/kernel/scripts/ipengine' does not exist > > > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger > wrote: >> >> Hello all, >> >> I have just merged the ipython-ipython1a branch into ipython trunk. >> This means that most of the stable stuff from ipython1 is now in >> IPython. This includes the following new subpackages: >> >> IPython.kernel >> IPython.kernel.core >> IPython.config >> IPython.tools >> >> The biggest change though is that I have refectored the setup.py >> script. Because these new subpackages have lots of other >> dependencies, we needed a nice way of handling these things. Here is >> a skech of how it is being handled: >> >> 1. If setuptools is being used, we declare optional requires for the >> additional deps >> >> 2. If setuptools is not being used, we check for the deps manually >> and simple tell the user what was found and what is required for what >> features. >> >> While this will likely take some find tuning, it is a start. >> >> PLEASE, try out the new setup.py in trunk on various platforms and in >> various situations. We need to test this well as it is a huge change. >> >> But, the bottom line is that IPython trunk now has full parallel >> computing capabilities. I will also announce on IPython-users >> >> Next stop: documentation merge!!! >> >> Cheers, >> >> Brian >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > > From ellisonbg.net at gmail.com Tue Jun 10 14:54:52 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 12:54:52 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com> References: <484EBFDB.3010500@slac.stanford.edu> <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com> Message-ID: <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com> This is fixed in trunk. Please pull the latest and try again. Cheers, Brian On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger wrote: > I will fix this as well. Thanks. > > Brian > > On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones wrote: >> Johann, >> >> Thanks, that seemed to have fixed the problem. I still got the following >> warnings, not sure if they impact anything or not. >> >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> >> >> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi >> wrote: >>> >>> Doug, >>> replace ipython by IPython in setupbase.py, at the line where ipengine >>> is called and the 2 next ones. >>> Johann >>> >>> ipython-dev-request at scipy.org wrote: >>> > Send IPython-dev mailing list submissions to >>> > ipython-dev at scipy.org >>> > >>> > To subscribe or unsubscribe via the World Wide Web, visit >>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>> > or, via email, send a message with subject or body 'help' to >>> > ipython-dev-request at scipy.org >>> > >>> > You can reach the person managing the list at >>> > ipython-dev-owner at scipy.org >>> > >>> > When replying, please edit your Subject line so it is more specific >>> > than "Re: Contents of IPython-dev digest..." >>> > >>> > ------------------------------------------------------------------------ >>> > >>> > Today's Topics: >>> > >>> > 1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones) >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > >>> > Subject: >>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! >>> > From: >>> > "Doug Jones" >>> > Date: >>> > Tue, 10 Jun 2008 13:02:12 -0400 >>> > To: >>> > "Brian Granger" >>> > >>> > To: >>> > "Brian Granger" >>> > CC: >>> > IPython Development list >>> > >>> > >>> > Hi All, >>> > >>> > I just gave the newest setup.py a go on my machine and ran into some >>> > problems. I've copied its output below. If you need more information, >>> > let me know and I will do my best to provide it. >>> > >>> > Thanks, >>> > ~doug >>> > >>> > >>> > python setup.py build >>> > >>> > ============================================================================ >>> > BUILDING IPYTHON >>> > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) [GCC >>> > 4.1.2 (Gentoo 4.1.2 p1.0.1)] >>> > platform: linux2 >>> > >>> > OPTIONAL DEPENDENCIES >>> > Zope.Interface: yes >>> > Twisted: 2.5.0 >>> > Foolscap: 0.2.8 >>> > OpenSSL: Not found (required if you want security in the >>> > parallel computing capabilities) >>> > sphinx: 0.3 >>> > pygments: 0.10 >>> > nose: 0.9.3 >>> > pexpect: 2.1 >>> > running build >>> > running build_py >>> > creating build >>> > creating build/lib >>> > creating build/lib/IPython >>> > copying IPython/wildcard.py -> build/lib/IPython >>> > copying IPython/deep_reload.py -> build/lib/IPython >>> > copying IPython/macro.py -> build/lib/IPython >>> > copying IPython/ipapi.py -> build/lib/IPython >>> > copying IPython/rlineimpl.py -> build/lib/IPython >>> > copying IPython/CrashHandler.py -> build/lib/IPython >>> > copying IPython/Shell.py -> build/lib/IPython >>> > copying IPython/ultraTB.py -> build/lib/IPython >>> > copying IPython/ipmaker.py -> build/lib/IPython >>> > copying IPython/upgrade_dir.py -> build/lib/IPython >>> > copying IPython/excolors.py -> build/lib/IPython >>> > copying IPython/Release.py -> build/lib/IPython >>> > copying IPython/demo.py -> build/lib/IPython >>> > copying IPython/OutputTrap.py -> build/lib/IPython >>> > copying IPython/shadowns.py -> build/lib/IPython >>> > copying IPython/__init__.py -> build/lib/IPython >>> > copying IPython/ColorANSI.py -> build/lib/IPython >>> > copying IPython/platutils_posix.py -> build/lib/IPython >>> > copying IPython/strdispatch.py -> build/lib/IPython >>> > copying IPython/generics.py -> build/lib/IPython >>> > copying IPython/platutils.py -> build/lib/IPython >>> > copying IPython/Debugger.py -> build/lib/IPython >>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython >>> > copying IPython/ipstruct.py -> build/lib/IPython >>> > copying IPython/completer.py -> build/lib/IPython >>> > copying IPython/FakeModule.py -> build/lib/IPython >>> > copying IPython/usage.py -> build/lib/IPython >>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython >>> > copying IPython/Logger.py -> build/lib/IPython >>> > copying IPython/Prompts.py -> build/lib/IPython >>> > copying IPython/numutils.py -> build/lib/IPython >>> > copying IPython/ConfigLoader.py -> build/lib/IPython >>> > copying IPython/platutils_dummy.py -> build/lib/IPython >>> > copying IPython/DPyGetOpt.py -> build/lib/IPython >>> > copying IPython/platutils_win32.py -> build/lib/IPython >>> > copying IPython/background_jobs.py -> build/lib/IPython >>> > copying IPython/iplib.py -> build/lib/IPython >>> > copying IPython/dtutils.py -> build/lib/IPython >>> > copying IPython/prefilter.py -> build/lib/IPython >>> > copying IPython/PyColorize.py -> build/lib/IPython >>> > copying IPython/twshell.py -> build/lib/IPython >>> > copying IPython/history.py -> build/lib/IPython >>> > copying IPython/winconsole.py -> build/lib/IPython >>> > copying IPython/shellglobals.py -> build/lib/IPython >>> > copying IPython/genutils.py -> build/lib/IPython >>> > copying IPython/hooks.py -> build/lib/IPython >>> > copying IPython/OInspect.py -> build/lib/IPython >>> > copying IPython/Magic.py -> build/lib/IPython >>> > copying IPython/irunner.py -> build/lib/IPython >>> > copying IPython/Gnuplot2.py -> build/lib/IPython >>> > copying IPython/Itpl.py -> build/lib/IPython >>> > creating build/lib/IPython/config >>> > copying IPython/config/api.py -> build/lib/IPython/config >>> > copying IPython/config/__init__.py -> build/lib/IPython/config >>> > copying IPython/config/cutils.py -> build/lib/IPython/config >>> > copying IPython/config/sconfig.py -> build/lib/IPython/config >>> > package init file 'IPython/config/tests/__init__.py' not found (or not >>> > a regular file) >>> > creating build/lib/IPython/config/tests >>> > copying IPython/config/tests/simpleconf.py -> >>> > build/lib/IPython/config/tests >>> > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests >>> > creating build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_autoreload.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_rehashdir.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_sh.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/pickleshare.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/PhysicalQInteractive.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_system_conf.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_doctest.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_gnuglobal.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_traits_completer.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/numeric_formats.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_scipy.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_lookfor.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_vimserver.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/InterpreterExec.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_exportdb.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_signals.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/pspersistence.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/PhysicalQInput.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_none.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_greedycompleter.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_numpy.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ext_rescapture.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/InterpreterPasteInput.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_constants.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_defaults.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_stock_completers.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_app_completers.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_workdir.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_extutil.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_completers.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_profile_zope.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/ipy_editors.py -> >>> > build/lib/IPython/Extensions >>> > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions >>> > creating build/lib/IPython/external >>> > copying IPython/external/mglob.py -> build/lib/IPython/external >>> > copying IPython/external/path.py -> build/lib/IPython/external >>> > copying IPython/external/__init__.py -> build/lib/IPython/external >>> > copying IPython/external/simplegeneric.py -> build/lib/IPython/external >>> > copying IPython/external/validate.py -> build/lib/IPython/external >>> > copying IPython/external/configobj.py -> build/lib/IPython/external >>> > copying IPython/external/guid.py -> build/lib/IPython/external >>> > copying IPython/external/Itpl.py -> build/lib/IPython/external >>> > creating build/lib/IPython/gui >>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui >>> > creating build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/ipshell_nonblocking.py -> >>> > build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx >>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx >>> > creating build/lib/IPython/kernel >>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel >>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel >>> > creating build/lib/IPython/kernel/config >>> > copying IPython/kernel/config/__init__.py -> >>> > build/lib/IPython/kernel/config >>> > creating build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_multienginefc.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_controllerservice.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_engineservice.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_task.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_pendingdeferred.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/engineservicetest.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_newserialized.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/__init__.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/multienginetest.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_taskfc.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_enginefc.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/test_multiengine.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/controllertest.py -> >>> > build/lib/IPython/kernel/tests >>> > copying IPython/kernel/tests/tasktest.py -> >>> > build/lib/IPython/kernel/tests >>> > creating build/lib/IPython/kernel/scripts >>> > copying IPython/kernel/scripts/ipcluster.py -> >>> > build/lib/IPython/kernel/scripts >>> > copying IPython/kernel/scripts/__init__.py -> >>> > build/lib/IPython/kernel/scripts >>> > copying IPython/kernel/scripts/ipengine.py -> >>> > build/lib/IPython/kernel/scripts >>> > copying IPython/kernel/scripts/ipcontroller.py -> >>> > build/lib/IPython/kernel/scripts >>> > creating build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/display_formatter.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/message_cache.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/traceback_trap.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/output_trap.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/display_trap.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/interpreter.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/traceback_formatter.py -> >>> > build/lib/IPython/kernel/core >>> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core >>> > creating build/lib/IPython/kernel/core/config >>> > copying IPython/kernel/core/config/__init__.py -> >>> > build/lib/IPython/kernel/core/config >>> > creating build/lib/IPython/kernel/core/tests >>> > copying IPython/kernel/core/tests/test_shell.py -> >>> > build/lib/IPython/kernel/core/tests >>> > copying IPython/kernel/core/tests/__init__.py -> >>> > build/lib/IPython/kernel/core/tests >>> > creating build/lib/IPython/testing >>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing >>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing >>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing >>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing >>> > copying IPython/testing/util.py -> build/lib/IPython/testing >>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing >>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing >>> > copying IPython/testing/tstTEMPLATE_doctest.py -> >>> > build/lib/IPython/testing >>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing >>> > creating build/lib/IPython/testing/tests >>> > copying IPython/testing/tests/__init__.py -> >>> > build/lib/IPython/testing/tests >>> > copying IPython/testing/tests/test_testutils.py -> >>> > build/lib/IPython/testing/tests >>> > creating build/lib/IPython/tools >>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools >>> > copying IPython/tools/utils.py -> build/lib/IPython/tools >>> > copying IPython/tools/growl.py -> build/lib/IPython/tools >>> > creating build/lib/IPython/tools/tests >>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> >>> > build/lib/IPython/tools/tests >>> > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests >>> > copying IPython/tools/tests/test_tools_utils.py -> >>> > build/lib/IPython/tools/tests >>> > copying IPython/tools/tests/tst_tools_utils_doctest.py -> >>> > build/lib/IPython/tools/tests >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a >>> > regular file) >>> > creating build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipy_user_conf.py -> >>> > build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc-physics -> >>> > build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc-tutorial -> >>> > build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc-numeric -> >>> > build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc-pysh -> >>> > build/lib/IPython/UserConfig >>> > copying IPython/UserConfig/ipythonrc-math -> >>> > build/lib/IPython/UserConfig >>> > package init file 'IPython/config/tests/__init__.py' not found (or not >>> > a regular file) >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a >>> > regular file) >>> > running build_scripts >>> > creating build/scripts-2.5 >>> > error: file 'ipython/kernel/scripts/ipengine' does not exist >>> > >>> > >>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger >> > @gmail.com > wrote: >>> > >>> > Hello all, >>> > >>> > I have just merged the ipython-ipython1a branch into ipython trunk. >>> > This means that most of the stable stuff from ipython1 is now in >>> > IPython. This includes the following new subpackages: >>> > >>> > IPython.kernel >>> > IPython.kernel.core >>> > IPython.config >>> > IPython.tools >>> > >>> > The biggest change though is that I have refectored the setup.py >>> > script. Because these new subpackages have lots of other >>> > dependencies, we needed a nice way of handling these things. Here >>> > is >>> > a skech of how it is being handled: >>> > >>> > 1. If setuptools is being used, we declare optional requires for >>> > the >>> > additional deps >>> > >>> > 2. If setuptools is not being used, we check for the deps manually >>> > and simple tell the user what was found and what is required for >>> > what >>> > features. >>> > >>> > While this will likely take some find tuning, it is a start. >>> > >>> > PLEASE, try out the new setup.py in trunk on various platforms and >>> > in >>> > various situations. We need to test this well as it is a huge >>> > change. >>> > >>> > But, the bottom line is that IPython trunk now has full parallel >>> > computing capabilities. I will also announce on IPython-users >>> > >>> > Next stop: documentation merge!!! >>> > >>> > Cheers, >>> > >>> > Brian >>> > _______________________________________________ >>> > 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 >>> > >>> _______________________________________________ >>> 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 dfj225 at gmail.com Tue Jun 10 14:57:10 2008 From: dfj225 at gmail.com (Doug Jones) Date: Tue, 10 Jun 2008 14:57:10 -0400 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient Message-ID: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> Hi all, I tried a simple test of the latest IPython branch and the MultiEngineClient. When I attempted to connect to a running cluster on my local machine, I got the following error: mec = client.MultiEngineClient(('localhost', 10105)) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /home/djones/svn/basin_remote/trunk/scripts/ in () /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc in get_multiengine_client(furl_or_file) 67 """ 68 client = blockingCallFromThread(_client_tub.get_multiengine_client, ---> 69 furl_or_file) 70 return client.adapt_to_blocking_client() 71 /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc in blockingCallFromThread(f, *a, **kw) 97 result.raiseException() 98 except Exception, e: ---> 99 raise e 100 return result 101 TypeError: coercing to Unicode: need string or buffer, tuple found Thanks, ~Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfj225 at gmail.com Tue Jun 10 14:58:59 2008 From: dfj225 at gmail.com (Doug Jones) Date: Tue, 10 Jun 2008 14:58:59 -0400 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com> References: <484EBFDB.3010500@slac.stanford.edu> <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com> <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com> Message-ID: <1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com> Done. No errors this time with a 'python setup.py build'. Thanks, ~doug On Tue, Jun 10, 2008 at 2:54 PM, Brian Granger wrote: > This is fixed in trunk. Please pull the latest and try again. > > Cheers, > > Brian > > On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger > wrote: > > I will fix this as well. Thanks. > > > > Brian > > > > On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones wrote: > >> Johann, > >> > >> Thanks, that seemed to have fixed the problem. I still got the following > >> warnings, not sure if they impact anything or not. > >> > >> package init file 'IPython/config/tests/__init__.py' not found (or not a > >> regular file) > >> package init file 'IPython/UserConfig/__init__.py' not found (or not a > >> regular file) > >> package init file 'IPython/config/tests/__init__.py' not found (or not a > >> regular file) > >> package init file 'IPython/UserConfig/__init__.py' not found (or not a > >> regular file) > >> > >> > >> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi > >> wrote: > >>> > >>> Doug, > >>> replace ipython by IPython in setupbase.py, at the line where ipengine > >>> is called and the 2 next ones. > >>> Johann > >>> > >>> ipython-dev-request at scipy.org wrote: > >>> > Send IPython-dev mailing list submissions to > >>> > ipython-dev at scipy.org > >>> > > >>> > To subscribe or unsubscribe via the World Wide Web, visit > >>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > >>> > or, via email, send a message with subject or body 'help' to > >>> > ipython-dev-request at scipy.org > >>> > > >>> > You can reach the person managing the list at > >>> > ipython-dev-owner at scipy.org > >>> > > >>> > When replying, please edit your Subject line so it is more specific > >>> > than "Re: Contents of IPython-dev digest..." > >>> > > >>> > > ------------------------------------------------------------------------ > >>> > > >>> > Today's Topics: > >>> > > >>> > 1. Re: First merge of ipython1 -> IPython is completed! (Doug > Jones) > >>> > > >>> > > >>> > > ------------------------------------------------------------------------ > >>> > > >>> > Subject: > >>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! > >>> > From: > >>> > "Doug Jones" > >>> > Date: > >>> > Tue, 10 Jun 2008 13:02:12 -0400 > >>> > To: > >>> > "Brian Granger" > >>> > > >>> > To: > >>> > "Brian Granger" > >>> > CC: > >>> > IPython Development list > >>> > > >>> > > >>> > Hi All, > >>> > > >>> > I just gave the newest setup.py a go on my machine and ran into some > >>> > problems. I've copied its output below. If you need more information, > >>> > let me know and I will do my best to provide it. > >>> > > >>> > Thanks, > >>> > ~doug > >>> > > >>> > > >>> > python setup.py build > >>> > > >>> > > ============================================================================ > >>> > BUILDING IPYTHON > >>> > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) > [GCC > >>> > 4.1.2 (Gentoo 4.1.2 p1.0.1)] > >>> > platform: linux2 > >>> > > >>> > OPTIONAL DEPENDENCIES > >>> > Zope.Interface: yes > >>> > Twisted: 2.5.0 > >>> > Foolscap: 0.2.8 > >>> > OpenSSL: Not found (required if you want security in > the > >>> > parallel computing capabilities) > >>> > sphinx: 0.3 > >>> > pygments: 0.10 > >>> > nose: 0.9.3 > >>> > pexpect: 2.1 > >>> > running build > >>> > running build_py > >>> > creating build > >>> > creating build/lib > >>> > creating build/lib/IPython > >>> > copying IPython/wildcard.py -> build/lib/IPython > >>> > copying IPython/deep_reload.py -> build/lib/IPython > >>> > copying IPython/macro.py -> build/lib/IPython > >>> > copying IPython/ipapi.py -> build/lib/IPython > >>> > copying IPython/rlineimpl.py -> build/lib/IPython > >>> > copying IPython/CrashHandler.py -> build/lib/IPython > >>> > copying IPython/Shell.py -> build/lib/IPython > >>> > copying IPython/ultraTB.py -> build/lib/IPython > >>> > copying IPython/ipmaker.py -> build/lib/IPython > >>> > copying IPython/upgrade_dir.py -> build/lib/IPython > >>> > copying IPython/excolors.py -> build/lib/IPython > >>> > copying IPython/Release.py -> build/lib/IPython > >>> > copying IPython/demo.py -> build/lib/IPython > >>> > copying IPython/OutputTrap.py -> build/lib/IPython > >>> > copying IPython/shadowns.py -> build/lib/IPython > >>> > copying IPython/__init__.py -> build/lib/IPython > >>> > copying IPython/ColorANSI.py -> build/lib/IPython > >>> > copying IPython/platutils_posix.py -> build/lib/IPython > >>> > copying IPython/strdispatch.py -> build/lib/IPython > >>> > copying IPython/generics.py -> build/lib/IPython > >>> > copying IPython/platutils.py -> build/lib/IPython > >>> > copying IPython/Debugger.py -> build/lib/IPython > >>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython > >>> > copying IPython/ipstruct.py -> build/lib/IPython > >>> > copying IPython/completer.py -> build/lib/IPython > >>> > copying IPython/FakeModule.py -> build/lib/IPython > >>> > copying IPython/usage.py -> build/lib/IPython > >>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython > >>> > copying IPython/Logger.py -> build/lib/IPython > >>> > copying IPython/Prompts.py -> build/lib/IPython > >>> > copying IPython/numutils.py -> build/lib/IPython > >>> > copying IPython/ConfigLoader.py -> build/lib/IPython > >>> > copying IPython/platutils_dummy.py -> build/lib/IPython > >>> > copying IPython/DPyGetOpt.py -> build/lib/IPython > >>> > copying IPython/platutils_win32.py -> build/lib/IPython > >>> > copying IPython/background_jobs.py -> build/lib/IPython > >>> > copying IPython/iplib.py -> build/lib/IPython > >>> > copying IPython/dtutils.py -> build/lib/IPython > >>> > copying IPython/prefilter.py -> build/lib/IPython > >>> > copying IPython/PyColorize.py -> build/lib/IPython > >>> > copying IPython/twshell.py -> build/lib/IPython > >>> > copying IPython/history.py -> build/lib/IPython > >>> > copying IPython/winconsole.py -> build/lib/IPython > >>> > copying IPython/shellglobals.py -> build/lib/IPython > >>> > copying IPython/genutils.py -> build/lib/IPython > >>> > copying IPython/hooks.py -> build/lib/IPython > >>> > copying IPython/OInspect.py -> build/lib/IPython > >>> > copying IPython/Magic.py -> build/lib/IPython > >>> > copying IPython/irunner.py -> build/lib/IPython > >>> > copying IPython/Gnuplot2.py -> build/lib/IPython > >>> > copying IPython/Itpl.py -> build/lib/IPython > >>> > creating build/lib/IPython/config > >>> > copying IPython/config/api.py -> build/lib/IPython/config > >>> > copying IPython/config/__init__.py -> build/lib/IPython/config > >>> > copying IPython/config/cutils.py -> build/lib/IPython/config > >>> > copying IPython/config/sconfig.py -> build/lib/IPython/config > >>> > package init file 'IPython/config/tests/__init__.py' not found (or > not > >>> > a regular file) > >>> > creating build/lib/IPython/config/tests > >>> > copying IPython/config/tests/simpleconf.py -> > >>> > build/lib/IPython/config/tests > >>> > copying IPython/config/tests/sctst.py -> > build/lib/IPython/config/tests > >>> > creating build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_autoreload.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_rehashdir.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_sh.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/pickleshare.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/PhysicalQInteractive.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_system_conf.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_doctest.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_gnuglobal.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_traits_completer.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/numeric_formats.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_scipy.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_lookfor.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/win32clip.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_pydb.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_legacy.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_render.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/__init__.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_vimserver.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/InterpreterExec.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_exportdb.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_signals.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/pspersistence.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_server.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/PhysicalQInput.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_none.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/clearcmd.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_greedycompleter.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_numpy.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ext_rescapture.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/InterpreterPasteInput.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_winpdb.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_constants.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_defaults.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_kitcfg.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_stock_completers.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_which.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_app_completers.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_workdir.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_fsops.py -> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_extutil.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_completers.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_profile_zope.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/ipy_editors.py -> > >>> > build/lib/IPython/Extensions > >>> > copying IPython/Extensions/envpersist.py -> > build/lib/IPython/Extensions > >>> > creating build/lib/IPython/external > >>> > copying IPython/external/mglob.py -> build/lib/IPython/external > >>> > copying IPython/external/path.py -> build/lib/IPython/external > >>> > copying IPython/external/__init__.py -> build/lib/IPython/external > >>> > copying IPython/external/simplegeneric.py -> > build/lib/IPython/external > >>> > copying IPython/external/validate.py -> build/lib/IPython/external > >>> > copying IPython/external/configobj.py -> build/lib/IPython/external > >>> > copying IPython/external/guid.py -> build/lib/IPython/external > >>> > copying IPython/external/Itpl.py -> build/lib/IPython/external > >>> > creating build/lib/IPython/gui > >>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui > >>> > creating build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/ipshell_nonblocking.py -> > >>> > build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx > >>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx > >>> > creating build/lib/IPython/kernel > >>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/clientinterfaces.py -> > build/lib/IPython/kernel > >>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/multiengineclient.py -> > build/lib/IPython/kernel > >>> > copying IPython/kernel/controllerservice.py -> > build/lib/IPython/kernel > >>> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/parallelfunction.py -> > build/lib/IPython/kernel > >>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel > >>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel > >>> > creating build/lib/IPython/kernel/config > >>> > copying IPython/kernel/config/__init__.py -> > >>> > build/lib/IPython/kernel/config > >>> > creating build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_multienginefc.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_controllerservice.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_engineservice.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_task.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_pendingdeferred.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/engineservicetest.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_newserialized.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/__init__.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/multienginetest.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_taskfc.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_enginefc.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/test_multiengine.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/controllertest.py -> > >>> > build/lib/IPython/kernel/tests > >>> > copying IPython/kernel/tests/tasktest.py -> > >>> > build/lib/IPython/kernel/tests > >>> > creating build/lib/IPython/kernel/scripts > >>> > copying IPython/kernel/scripts/ipcluster.py -> > >>> > build/lib/IPython/kernel/scripts > >>> > copying IPython/kernel/scripts/__init__.py -> > >>> > build/lib/IPython/kernel/scripts > >>> > copying IPython/kernel/scripts/ipengine.py -> > >>> > build/lib/IPython/kernel/scripts > >>> > copying IPython/kernel/scripts/ipcontroller.py -> > >>> > build/lib/IPython/kernel/scripts > >>> > creating build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/display_formatter.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/message_cache.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/ultraTB.py -> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/__init__.py -> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/traceback_trap.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/prompts.py -> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/output_trap.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/display_trap.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/interpreter.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/history.py -> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/traceback_formatter.py -> > >>> > build/lib/IPython/kernel/core > >>> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core > >>> > creating build/lib/IPython/kernel/core/config > >>> > copying IPython/kernel/core/config/__init__.py -> > >>> > build/lib/IPython/kernel/core/config > >>> > creating build/lib/IPython/kernel/core/tests > >>> > copying IPython/kernel/core/tests/test_shell.py -> > >>> > build/lib/IPython/kernel/core/tests > >>> > copying IPython/kernel/core/tests/__init__.py -> > >>> > build/lib/IPython/kernel/core/tests > >>> > creating build/lib/IPython/testing > >>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing > >>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing > >>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing > >>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing > >>> > copying IPython/testing/util.py -> build/lib/IPython/testing > >>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing > >>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing > >>> > copying IPython/testing/tstTEMPLATE_doctest.py -> > >>> > build/lib/IPython/testing > >>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing > >>> > creating build/lib/IPython/testing/tests > >>> > copying IPython/testing/tests/__init__.py -> > >>> > build/lib/IPython/testing/tests > >>> > copying IPython/testing/tests/test_testutils.py -> > >>> > build/lib/IPython/testing/tests > >>> > creating build/lib/IPython/tools > >>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools > >>> > copying IPython/tools/utils.py -> build/lib/IPython/tools > >>> > copying IPython/tools/growl.py -> build/lib/IPython/tools > >>> > creating build/lib/IPython/tools/tests > >>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> > >>> > build/lib/IPython/tools/tests > >>> > copying IPython/tools/tests/__init__.py -> > build/lib/IPython/tools/tests > >>> > copying IPython/tools/tests/test_tools_utils.py -> > >>> > build/lib/IPython/tools/tests > >>> > copying IPython/tools/tests/tst_tools_utils_doctest.py -> > >>> > build/lib/IPython/tools/tests > >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not > a > >>> > regular file) > >>> > creating build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipy_user_conf.py -> > >>> > build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc-physics -> > >>> > build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc-tutorial -> > >>> > build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc-numeric -> > >>> > build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc-pysh -> > >>> > build/lib/IPython/UserConfig > >>> > copying IPython/UserConfig/ipythonrc-math -> > >>> > build/lib/IPython/UserConfig > >>> > package init file 'IPython/config/tests/__init__.py' not found (or > not > >>> > a regular file) > >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not > a > >>> > regular file) > >>> > running build_scripts > >>> > creating build/scripts-2.5 > >>> > error: file 'ipython/kernel/scripts/ipengine' does not exist > >>> > > >>> > > >>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger >>> > @gmail.com > wrote: > >>> > > >>> > Hello all, > >>> > > >>> > I have just merged the ipython-ipython1a branch into ipython > trunk. > >>> > This means that most of the stable stuff from ipython1 is now in > >>> > IPython. This includes the following new subpackages: > >>> > > >>> > IPython.kernel > >>> > IPython.kernel.core > >>> > IPython.config > >>> > IPython.tools > >>> > > >>> > The biggest change though is that I have refectored the setup.py > >>> > script. Because these new subpackages have lots of other > >>> > dependencies, we needed a nice way of handling these things. > Here > >>> > is > >>> > a skech of how it is being handled: > >>> > > >>> > 1. If setuptools is being used, we declare optional requires for > >>> > the > >>> > additional deps > >>> > > >>> > 2. If setuptools is not being used, we check for the deps > manually > >>> > and simple tell the user what was found and what is required for > >>> > what > >>> > features. > >>> > > >>> > While this will likely take some find tuning, it is a start. > >>> > > >>> > PLEASE, try out the new setup.py in trunk on various platforms > and > >>> > in > >>> > various situations. We need to test this well as it is a huge > >>> > change. > >>> > > >>> > But, the bottom line is that IPython trunk now has full parallel > >>> > computing capabilities. I will also announce on IPython-users > >>> > > >>> > Next stop: documentation merge!!! > >>> > > >>> > Cheers, > >>> > > >>> > Brian > >>> > _______________________________________________ > >>> > 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 > >>> > > >>> _______________________________________________ > >>> 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 > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Tue Jun 10 15:02:19 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 13:02:19 -0600 Subject: [IPython-dev] First merge of ipython1 -> IPython is completed! In-Reply-To: <1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com> References: <484EBFDB.3010500@slac.stanford.edu> <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com> <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com> <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com> <1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com> Message-ID: <6ce0ac130806101202l7f019228j4e22b0a5074de0c1@mail.gmail.com> Great, thanks for testing this. Please let me know if you have other questions about the new security stuff. I am in the process on moving our docs over to IPython trunk. Until then the docs on how to run things are a bit minimal. Cheers, Brian On Tue, Jun 10, 2008 at 12:58 PM, Doug Jones wrote: > Done. No errors this time with a 'python setup.py build'. > > Thanks, > ~doug > > On Tue, Jun 10, 2008 at 2:54 PM, Brian Granger > wrote: >> >> This is fixed in trunk. Please pull the latest and try again. >> >> Cheers, >> >> Brian >> >> On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger >> wrote: >> > I will fix this as well. Thanks. >> > >> > Brian >> > >> > On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones wrote: >> >> Johann, >> >> >> >> Thanks, that seemed to have fixed the problem. I still got the >> >> following >> >> warnings, not sure if they impact anything or not. >> >> >> >> package init file 'IPython/config/tests/__init__.py' not found (or not >> >> a >> >> regular file) >> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> >> regular file) >> >> package init file 'IPython/config/tests/__init__.py' not found (or not >> >> a >> >> regular file) >> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> >> regular file) >> >> >> >> >> >> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi >> >> wrote: >> >>> >> >>> Doug, >> >>> replace ipython by IPython in setupbase.py, at the line where ipengine >> >>> is called and the 2 next ones. >> >>> Johann >> >>> >> >>> ipython-dev-request at scipy.org wrote: >> >>> > Send IPython-dev mailing list submissions to >> >>> > ipython-dev at scipy.org >> >>> > >> >>> > To subscribe or unsubscribe via the World Wide Web, visit >> >>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> >>> > or, via email, send a message with subject or body 'help' to >> >>> > ipython-dev-request at scipy.org >> >>> > >> >>> > You can reach the person managing the list at >> >>> > ipython-dev-owner at scipy.org >> >>> > >> >>> > When replying, please edit your Subject line so it is more specific >> >>> > than "Re: Contents of IPython-dev digest..." >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------------ >> >>> > >> >>> > Today's Topics: >> >>> > >> >>> > 1. Re: First merge of ipython1 -> IPython is completed! (Doug >> >>> > Jones) >> >>> > >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------------ >> >>> > >> >>> > Subject: >> >>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed! >> >>> > From: >> >>> > "Doug Jones" >> >>> > Date: >> >>> > Tue, 10 Jun 2008 13:02:12 -0400 >> >>> > To: >> >>> > "Brian Granger" >> >>> > >> >>> > To: >> >>> > "Brian Granger" >> >>> > CC: >> >>> > IPython Development list >> >>> > >> >>> > >> >>> > Hi All, >> >>> > >> >>> > I just gave the newest setup.py a go on my machine and ran into some >> >>> > problems. I've copied its output below. If you need more >> >>> > information, >> >>> > let me know and I will do my best to provide it. >> >>> > >> >>> > Thanks, >> >>> > ~doug >> >>> > >> >>> > >> >>> > python setup.py build >> >>> > >> >>> > >> >>> > ============================================================================ >> >>> > BUILDING IPYTHON >> >>> > python: 2.5.1 (r251:54863, Nov 1 2007, 13:29:57) >> >>> > [GCC >> >>> > 4.1.2 (Gentoo 4.1.2 p1.0.1)] >> >>> > platform: linux2 >> >>> > >> >>> > OPTIONAL DEPENDENCIES >> >>> > Zope.Interface: yes >> >>> > Twisted: 2.5.0 >> >>> > Foolscap: 0.2.8 >> >>> > OpenSSL: Not found (required if you want security in >> >>> > the >> >>> > parallel computing capabilities) >> >>> > sphinx: 0.3 >> >>> > pygments: 0.10 >> >>> > nose: 0.9.3 >> >>> > pexpect: 2.1 >> >>> > running build >> >>> > running build_py >> >>> > creating build >> >>> > creating build/lib >> >>> > creating build/lib/IPython >> >>> > copying IPython/wildcard.py -> build/lib/IPython >> >>> > copying IPython/deep_reload.py -> build/lib/IPython >> >>> > copying IPython/macro.py -> build/lib/IPython >> >>> > copying IPython/ipapi.py -> build/lib/IPython >> >>> > copying IPython/rlineimpl.py -> build/lib/IPython >> >>> > copying IPython/CrashHandler.py -> build/lib/IPython >> >>> > copying IPython/Shell.py -> build/lib/IPython >> >>> > copying IPython/ultraTB.py -> build/lib/IPython >> >>> > copying IPython/ipmaker.py -> build/lib/IPython >> >>> > copying IPython/upgrade_dir.py -> build/lib/IPython >> >>> > copying IPython/excolors.py -> build/lib/IPython >> >>> > copying IPython/Release.py -> build/lib/IPython >> >>> > copying IPython/demo.py -> build/lib/IPython >> >>> > copying IPython/OutputTrap.py -> build/lib/IPython >> >>> > copying IPython/shadowns.py -> build/lib/IPython >> >>> > copying IPython/__init__.py -> build/lib/IPython >> >>> > copying IPython/ColorANSI.py -> build/lib/IPython >> >>> > copying IPython/platutils_posix.py -> build/lib/IPython >> >>> > copying IPython/strdispatch.py -> build/lib/IPython >> >>> > copying IPython/generics.py -> build/lib/IPython >> >>> > copying IPython/platutils.py -> build/lib/IPython >> >>> > copying IPython/Debugger.py -> build/lib/IPython >> >>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython >> >>> > copying IPython/ipstruct.py -> build/lib/IPython >> >>> > copying IPython/completer.py -> build/lib/IPython >> >>> > copying IPython/FakeModule.py -> build/lib/IPython >> >>> > copying IPython/usage.py -> build/lib/IPython >> >>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython >> >>> > copying IPython/Logger.py -> build/lib/IPython >> >>> > copying IPython/Prompts.py -> build/lib/IPython >> >>> > copying IPython/numutils.py -> build/lib/IPython >> >>> > copying IPython/ConfigLoader.py -> build/lib/IPython >> >>> > copying IPython/platutils_dummy.py -> build/lib/IPython >> >>> > copying IPython/DPyGetOpt.py -> build/lib/IPython >> >>> > copying IPython/platutils_win32.py -> build/lib/IPython >> >>> > copying IPython/background_jobs.py -> build/lib/IPython >> >>> > copying IPython/iplib.py -> build/lib/IPython >> >>> > copying IPython/dtutils.py -> build/lib/IPython >> >>> > copying IPython/prefilter.py -> build/lib/IPython >> >>> > copying IPython/PyColorize.py -> build/lib/IPython >> >>> > copying IPython/twshell.py -> build/lib/IPython >> >>> > copying IPython/history.py -> build/lib/IPython >> >>> > copying IPython/winconsole.py -> build/lib/IPython >> >>> > copying IPython/shellglobals.py -> build/lib/IPython >> >>> > copying IPython/genutils.py -> build/lib/IPython >> >>> > copying IPython/hooks.py -> build/lib/IPython >> >>> > copying IPython/OInspect.py -> build/lib/IPython >> >>> > copying IPython/Magic.py -> build/lib/IPython >> >>> > copying IPython/irunner.py -> build/lib/IPython >> >>> > copying IPython/Gnuplot2.py -> build/lib/IPython >> >>> > copying IPython/Itpl.py -> build/lib/IPython >> >>> > creating build/lib/IPython/config >> >>> > copying IPython/config/api.py -> build/lib/IPython/config >> >>> > copying IPython/config/__init__.py -> build/lib/IPython/config >> >>> > copying IPython/config/cutils.py -> build/lib/IPython/config >> >>> > copying IPython/config/sconfig.py -> build/lib/IPython/config >> >>> > package init file 'IPython/config/tests/__init__.py' not found (or >> >>> > not >> >>> > a regular file) >> >>> > creating build/lib/IPython/config/tests >> >>> > copying IPython/config/tests/simpleconf.py -> >> >>> > build/lib/IPython/config/tests >> >>> > copying IPython/config/tests/sctst.py -> >> >>> > build/lib/IPython/config/tests >> >>> > creating build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_autoreload.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_bzr.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_rehashdir.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_sh.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/pickleshare.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/PhysicalQInteractive.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_system_conf.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_doctest.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_gnuglobal.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_traits_completer.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/numeric_formats.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_scipy.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_leo.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_lookfor.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/win32clip.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_pydb.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_legacy.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_render.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/__init__.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_vimserver.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_jot.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/InterpreterExec.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_exportdb.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_signals.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/pspersistence.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_server.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/PhysicalQInput.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/jobctrl.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_none.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/clearcmd.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_greedycompleter.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_numpy.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ibrowse.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ext_rescapture.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/InterpreterPasteInput.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_winpdb.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_constants.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_defaults.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_kitcfg.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_stock_completers.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_which.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_app_completers.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_workdir.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_fsops.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_extutil.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_completers.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_profile_zope.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/ipy_editors.py -> >> >>> > build/lib/IPython/Extensions >> >>> > copying IPython/Extensions/envpersist.py -> >> >>> > build/lib/IPython/Extensions >> >>> > creating build/lib/IPython/external >> >>> > copying IPython/external/mglob.py -> build/lib/IPython/external >> >>> > copying IPython/external/path.py -> build/lib/IPython/external >> >>> > copying IPython/external/__init__.py -> build/lib/IPython/external >> >>> > copying IPython/external/simplegeneric.py -> >> >>> > build/lib/IPython/external >> >>> > copying IPython/external/validate.py -> build/lib/IPython/external >> >>> > copying IPython/external/configobj.py -> build/lib/IPython/external >> >>> > copying IPython/external/guid.py -> build/lib/IPython/external >> >>> > copying IPython/external/Itpl.py -> build/lib/IPython/external >> >>> > creating build/lib/IPython/gui >> >>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui >> >>> > creating build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/ipshell_nonblocking.py -> >> >>> > build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/ipython_history.py -> >> >>> > build/lib/IPython/gui/wx >> >>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx >> >>> > creating build/lib/IPython/kernel >> >>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/clientinterfaces.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/clientconnector.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/multiengineclient.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/controllerservice.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/pendingdeferred.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/engineconnector.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/parallelfunction.py -> >> >>> > build/lib/IPython/kernel >> >>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel >> >>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel >> >>> > creating build/lib/IPython/kernel/config >> >>> > copying IPython/kernel/config/__init__.py -> >> >>> > build/lib/IPython/kernel/config >> >>> > creating build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_multienginefc.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_controllerservice.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_engineservice.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_task.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_pendingdeferred.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/engineservicetest.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_newserialized.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/__init__.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/multienginetest.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_taskfc.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_enginefc.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/test_multiengine.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/controllertest.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > copying IPython/kernel/tests/tasktest.py -> >> >>> > build/lib/IPython/kernel/tests >> >>> > creating build/lib/IPython/kernel/scripts >> >>> > copying IPython/kernel/scripts/ipcluster.py -> >> >>> > build/lib/IPython/kernel/scripts >> >>> > copying IPython/kernel/scripts/__init__.py -> >> >>> > build/lib/IPython/kernel/scripts >> >>> > copying IPython/kernel/scripts/ipengine.py -> >> >>> > build/lib/IPython/kernel/scripts >> >>> > copying IPython/kernel/scripts/ipcontroller.py -> >> >>> > build/lib/IPython/kernel/scripts >> >>> > creating build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/macro.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/display_formatter.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/message_cache.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/ultraTB.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/__init__.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/magic.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/shell.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/traceback_trap.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/prompts.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/output_trap.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/display_trap.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/interpreter.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/history.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/traceback_formatter.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > copying IPython/kernel/core/error.py -> >> >>> > build/lib/IPython/kernel/core >> >>> > creating build/lib/IPython/kernel/core/config >> >>> > copying IPython/kernel/core/config/__init__.py -> >> >>> > build/lib/IPython/kernel/core/config >> >>> > creating build/lib/IPython/kernel/core/tests >> >>> > copying IPython/kernel/core/tests/test_shell.py -> >> >>> > build/lib/IPython/kernel/core/tests >> >>> > copying IPython/kernel/core/tests/__init__.py -> >> >>> > build/lib/IPython/kernel/core/tests >> >>> > creating build/lib/IPython/testing >> >>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/util.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing >> >>> > copying IPython/testing/tstTEMPLATE_doctest.py -> >> >>> > build/lib/IPython/testing >> >>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing >> >>> > creating build/lib/IPython/testing/tests >> >>> > copying IPython/testing/tests/__init__.py -> >> >>> > build/lib/IPython/testing/tests >> >>> > copying IPython/testing/tests/test_testutils.py -> >> >>> > build/lib/IPython/testing/tests >> >>> > creating build/lib/IPython/tools >> >>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools >> >>> > copying IPython/tools/utils.py -> build/lib/IPython/tools >> >>> > copying IPython/tools/growl.py -> build/lib/IPython/tools >> >>> > creating build/lib/IPython/tools/tests >> >>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py -> >> >>> > build/lib/IPython/tools/tests >> >>> > copying IPython/tools/tests/__init__.py -> >> >>> > build/lib/IPython/tools/tests >> >>> > copying IPython/tools/tests/test_tools_utils.py -> >> >>> > build/lib/IPython/tools/tests >> >>> > copying IPython/tools/tests/tst_tools_utils_doctest.py -> >> >>> > build/lib/IPython/tools/tests >> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not >> >>> > a >> >>> > regular file) >> >>> > creating build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipy_user_conf.py -> >> >>> > build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc-physics -> >> >>> > build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc-tutorial -> >> >>> > build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc-numeric -> >> >>> > build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc-pysh -> >> >>> > build/lib/IPython/UserConfig >> >>> > copying IPython/UserConfig/ipythonrc-math -> >> >>> > build/lib/IPython/UserConfig >> >>> > package init file 'IPython/config/tests/__init__.py' not found (or >> >>> > not >> >>> > a regular file) >> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not >> >>> > a >> >>> > regular file) >> >>> > running build_scripts >> >>> > creating build/scripts-2.5 >> >>> > error: file 'ipython/kernel/scripts/ipengine' does not exist >> >>> > >> >>> > >> >>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger > >>> > @gmail.com > wrote: >> >>> > >> >>> > Hello all, >> >>> > >> >>> > I have just merged the ipython-ipython1a branch into ipython >> >>> > trunk. >> >>> > This means that most of the stable stuff from ipython1 is now in >> >>> > IPython. This includes the following new subpackages: >> >>> > >> >>> > IPython.kernel >> >>> > IPython.kernel.core >> >>> > IPython.config >> >>> > IPython.tools >> >>> > >> >>> > The biggest change though is that I have refectored the setup.py >> >>> > script. Because these new subpackages have lots of other >> >>> > dependencies, we needed a nice way of handling these things. >> >>> > Here >> >>> > is >> >>> > a skech of how it is being handled: >> >>> > >> >>> > 1. If setuptools is being used, we declare optional requires >> >>> > for >> >>> > the >> >>> > additional deps >> >>> > >> >>> > 2. If setuptools is not being used, we check for the deps >> >>> > manually >> >>> > and simple tell the user what was found and what is required for >> >>> > what >> >>> > features. >> >>> > >> >>> > While this will likely take some find tuning, it is a start. >> >>> > >> >>> > PLEASE, try out the new setup.py in trunk on various platforms >> >>> > and >> >>> > in >> >>> > various situations. We need to test this well as it is a huge >> >>> > change. >> >>> > >> >>> > But, the bottom line is that IPython trunk now has full parallel >> >>> > computing capabilities. I will also announce on IPython-users >> >>> > >> >>> > Next stop: documentation merge!!! >> >>> > >> >>> > Cheers, >> >>> > >> >>> > Brian >> >>> > _______________________________________________ >> >>> > 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 >> >>> > >> >>> _______________________________________________ >> >>> 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 ellisonbg.net at gmail.com Tue Jun 10 15:55:57 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 10 Jun 2008 13:55:57 -0600 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient In-Reply-To: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> Message-ID: <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> This is not a unicode error, but rather, our API for starting the client has changed due to the new security stuff. This is the stuff that I am working on documenting as we speak. Here is a minimal description: 1) When the controller now starts, it creates a set of files (in your .ipython directory by default) ipcontroller-tc.furl ipcontroller-mec.furl ipcontroller-engine.furl 2) These files contain a secure URL that 1) tells the engine and clients where the controller is running and 2) gives the engine and clients authority to connect to the controller in a secure manner. 3) To use these files, they have to be available to the client and engines when they start. The easiest way of handling this is to a) copy ipcontroller-engine.furl to the .ipython directory on the machine(s) where the engines will run b) copy ipcontroller-tc and -mec to the .ipython dir of the machine where the clients will run. Then everything will "just work". By this, I mean that you can create the clients with no arguments: mec = client.MultiEngineClient() If you have put the .furl files in different locations you can do: mec = client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl') In all of this, you can think of the furl files as being keys (just like a house key) that grants an entity access to a particular resource. The controller creates the keys and the engines/client must present/use them to use the capabilities of the controller. See if you can use this to get things working. The big benefit of using all this is: 1) Users don't have to track what ip/port the controller is running on. 2) Everything is secure by default - authentication + encryption (if you have pyOpenSSL installed 3) The controller now uses random port numbers, making it even more difficult for hostiles to discover. Let me know if you have any more problems getting this working. We would love feedback if you have ideas of how things could be made easier. Also, check out the new command line flags on the ipcontroller and ipengine scripts to control where the furl files are created and looked for. Cheers, Brian On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones wrote: > Hi all, > > I tried a simple test of the latest IPython branch and the > MultiEngineClient. When I attempted to connect to a running cluster on my > local machine, I got the following error: > > mec = client.MultiEngineClient(('localhost', 10105)) > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > > /home/djones/svn/basin_remote/trunk/scripts/ in () > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc > in get_multiengine_client(furl_or_file) > 67 """ > 68 client = > blockingCallFromThread(_client_tub.get_multiengine_client, > ---> 69 furl_or_file) > 70 return client.adapt_to_blocking_client() > 71 > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc > in blockingCallFromThread(f, *a, **kw) > 97 result.raiseException() > 98 except Exception, e: > ---> 99 raise e > 100 return result > 101 > > TypeError: coercing to Unicode: need string or buffer, tuple found > > > > Thanks, > ~Doug > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > > From cohen at slac.stanford.edu Tue Jun 10 16:49:06 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Tue, 10 Jun 2008 22:49:06 +0200 Subject: [IPython-dev] feature? In-Reply-To: <6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com> References: <484EC4B7.6010309@slac.stanford.edu> <6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com> Message-ID: <484EE8C2.4010006@slac.stanford.edu> well, with Brian great help, we figured out offline that the problem is a faulty setuptools in my system (FC8), so Brian suggested: easy_install -U setuptools and it then worked! After installation, I get : [cohen at jarrett ~]$ nosetests IPython ...................................................................................................................................................................................................................................................................................................................... ---------------------------------------------------------------------- Ran 310 tests in 40.059s OK hth, Johann Brian Granger wrote: > On Tue, Jun 10, 2008 at 12:15 PM, Johann Cohen-Tanugi > wrote: > >> More on my issues with current bzr trunk : I installed sphinx without >> trouble so only Foolscap seems to be a problem. But when I try to build >> ipython again, just for the sake of it, it now outputs : >> [cohen at jarrett ipython]$ python setup.py build >> ============================================================================ >> BUILDING IPYTHON >> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC >> 4.1.2 20070925 (Red Hat 4.1.2-33)] >> platform: linux2 >> >> OPTIONAL DEPENDENCIES >> Zope.Interface: yes >> Twisted: 8.1.0 >> Foolscap: 0.2.8 >> OpenSSL: 0.6 >> sphinx: 0.3 >> pygments: 0.10 >> nose: 0.10.0 >> pexpect: 2.3 >> running build >> running build_py >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/config/tests/__init__.py' not found (or not a >> regular file) >> package init file 'IPython/UserConfig/__init__.py' not found (or not a >> regular file) >> running build_scripts >> >> Only the Foolscap egg is there, which seems to be enough for ipython at >> this stage. Do we really want that behavior? >> best, >> > > > I am not sure that I follow you. The dependency check shows that it > has found acceptable versions of all the dependencies. Can you just > run: > > $ trial IPython > > or > > nosetests IPython > > To run the test suite and see what you get? > > Thanks > > Brian > From barrywark at gmail.com Tue Jun 10 19:43:59 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 10 Jun 2008 16:43:59 -0700 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient In-Reply-To: <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> Message-ID: Brian, This looks like a great system! Thanks for implementing a security model. This will make deploying IPython on "open" networks much less scary! Barry On Tue, Jun 10, 2008 at 12:55 PM, Brian Granger wrote: > This is not a unicode error, but rather, our API for starting the > client has changed due to the new security stuff. This is the stuff > that I am working on documenting as we speak. > > Here is a minimal description: > > 1) When the controller now starts, it creates a set of files (in your > .ipython directory by default) > > ipcontroller-tc.furl > ipcontroller-mec.furl > ipcontroller-engine.furl > > 2) These files contain a secure URL that 1) tells the engine and > clients where the controller is running and 2) gives the engine and > clients authority to connect to the controller in a secure manner. > > 3) To use these files, they have to be available to the client and > engines when they start. The easiest way of handling this is to > > a) copy ipcontroller-engine.furl to the .ipython directory on the > machine(s) where the engines will run > > b) copy ipcontroller-tc and -mec to the .ipython dir of the machine > where the clients will run. > > Then everything will "just work". By this, I mean that you can create > the clients with no arguments: > > mec = client.MultiEngineClient() > > If you have put the .furl files in different locations you can do: > > mec = client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl') > > In all of this, you can think of the furl files as being keys (just > like a house key) that grants an entity access to a particular > resource. The controller creates the keys and the engines/client must > present/use them to use the capabilities of the controller. > > See if you can use this to get things working. The big benefit of > using all this is: > > 1) Users don't have to track what ip/port the controller is running on. > > 2) Everything is secure by default - authentication + encryption (if > you have pyOpenSSL installed > > 3) The controller now uses random port numbers, making it even more > difficult for hostiles to discover. > > Let me know if you have any more problems getting this working. We > would love feedback if you have ideas of how things could be made > easier. > > Also, check out the new command line flags on the ipcontroller and > ipengine scripts to control where the furl files are created and > looked for. > > Cheers, > > Brian > > On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones wrote: >> Hi all, >> >> I tried a simple test of the latest IPython branch and the >> MultiEngineClient. When I attempted to connect to a running cluster on my >> local machine, I got the following error: >> >> mec = client.MultiEngineClient(('localhost', 10105)) >> --------------------------------------------------------------------------- >> TypeError Traceback (most recent call last) >> >> /home/djones/svn/basin_remote/trunk/scripts/ in () >> >> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc >> in get_multiengine_client(furl_or_file) >> 67 """ >> 68 client = >> blockingCallFromThread(_client_tub.get_multiengine_client, >> ---> 69 furl_or_file) >> 70 return client.adapt_to_blocking_client() >> 71 >> >> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc >> in blockingCallFromThread(f, *a, **kw) >> 97 result.raiseException() >> 98 except Exception, e: >> ---> 99 raise e >> 100 return result >> 101 >> >> TypeError: coercing to Unicode: need string or buffer, tuple found >> >> >> >> Thanks, >> ~Doug >> >> _______________________________________________ >> 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 ellisonbg.net at gmail.com Wed Jun 11 18:35:15 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 11 Jun 2008 16:35:15 -0600 Subject: [IPython-dev] IPython documentation Message-ID: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> Hello all, So, I have finished merging in the ipython1 documentation into IPython proper. Now all the docs are in one place. In addition to doing this merge, I have taken the liberty of completely reorganizing the docs. Previously, the IPython docs were a single rst file, which was really awkward and didn't take advantage of Sphinx's nice features. In the process of doing all this, I realized that the IPython docs (not the parallel computing stuff) need quite a bit of care and attention. I would like to see if we can get people to put in time to get our docs back up to where they should be. Here is what I am thinking: The docs are now organized into the following sections (these are either files or subdirectories in docs/source): Introduction Installation Using IPython for interactive work Using IPython for parallel computing Configuration and customization What's new Development Frequently asked questions History License and Copyright Credits Each of these sections needs someone to go through it and do the following things: 1) Read through and make sure that the content is up to date and correct. For some sections this will be a lot of work. For example, because of the ipython1 -> IPython merge, our installation docs are completely outdated. 2) Make sure that all the internal links are working correctly. For this we are using Shinx's "ref" capability. See the Sphinx docs for more details. In some cases, this will require that you make new labels for things. If people need doc-writing inspiration check out your favorite well documented project. Some of my favorites are django and sqlalchemy. The good news is that we now have lots of docs. The bad news is that I can't do all of this myself. I can take the following sections though: Installation Using IPython for parallel computing Development If you are interested in helping improve our docs, let us know and we will figure out the best way for you to contribute. Some of the sections will probably need to be worked on by specific people. But we can surely find a way for eager people to help out. Cheers, Brian From ellisonbg.net at gmail.com Wed Jun 11 18:40:02 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 11 Jun 2008 16:40:02 -0600 Subject: [IPython-dev] IPython 0.9 release... Message-ID: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com> Hello all, So, everything that is coming in from ipython1-dev is now in ipython trunk. Barry is going to merge in the cocoa frontend and frontendbase from his ipython1-cocoa branch. I would like us to think about doing a 0.9 release of IPython sometime in the next few weeks. The sooner the better, because I don't want to leave ipython1 users in limbo. I am wondering what else needs to be done before we but the release. Here are some things that I can think of: 1. Update the docs (see my other email on what needs to be done). 2. Test, test, test all the new stuff 3. Fernando and I need to finish a few more things in the kernel to make it easier to use for parallel computing Is there anything else that people can think of. Because 0.8.4 came out, I imagine that not much has changed with the old stuff. But that is fine - the main purpose of this release is to get the ipython1 -> IPython stuff info people's hands. Cheers, Brian From fperez.net at gmail.com Wed Jun 11 20:55:48 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 11 Jun 2008 17:55:48 -0700 Subject: [IPython-dev] IPython 0.9 release... In-Reply-To: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com> References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com> Message-ID: On Wed, Jun 11, 2008 at 3:40 PM, Brian Granger wrote: > Hello all, > > So, everything that is coming in from ipython1-dev is now in ipython > trunk. Barry is going to merge in the cocoa frontend and frontendbase > from his ipython1-cocoa branch. I would like us to think about doing > a 0.9 release of IPython sometime in the next few weeks. The sooner > the better, because I don't want to leave ipython1 users in limbo. > > I am wondering what else needs to be done before we but the release. > Here are some things that I can think of: > > 1. Update the docs (see my other email on what needs to be done). > > 2. Test, test, test all the new stuff > > 3. Fernando and I need to finish a few more things in the kernel to > make it easier to use for parallel computing I'm mostly offline til next week, but I'm +1 on a quick release. I'll be working on the test stuff for the next few days, I'd like to have at least the scaffolding for testing everything together (that means, to coherently test both all the new code AND the old) for 0.9. That way we'll get off the ground with the new series with solid testing across the board (even if the actual amount of tests for the old code is small, I want to put in the machinery). Min just got back too, and I'll meet up with him next week when I return to California (we missed each other today). That will put us all on the same page. Question: did you merge sconfig? I missed the details of that with Stefan... Cheers, f From fperez.net at gmail.com Wed Jun 11 20:58:47 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 11 Jun 2008 17:58:47 -0700 Subject: [IPython-dev] IPython documentation In-Reply-To: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> Message-ID: On Wed, Jun 11, 2008 at 3:35 PM, Brian Granger wrote: > Hello all, > > So, I have finished merging in the ipython1 documentation into IPython > proper. Now all the docs are in one place. > > In addition to doing this merge, I have taken the liberty of > completely reorganizing the docs. Previously, the IPython docs were a > single rst file, which was really awkward and didn't take advantage of > Sphinx's nice features. In the process of doing all this, I realized > that the IPython docs (not the parallel computing stuff) need quite a > bit of care and attention. I would like to see if we can get people > to put in time to get our docs back up to where they should be. Here > is what I am thinking: Thanks for doing this, it was needed. For one thing, search was broken with the single-file one. One thing that I've been mulling is using the new scipy doc system http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/ for the manuals as well. I know it's doable, I just don't know right now how closely tied to docstring editing (the original purpose) it is. Stefan can tell us... Cheers, f From stefan at sun.ac.za Wed Jun 11 21:12:11 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 12 Jun 2008 03:12:11 +0200 Subject: [IPython-dev] IPython 0.9 release... In-Reply-To: References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com> Message-ID: <9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com> 2008/6/12 Fernando Perez : > Question: did you merge sconfig? I missed the details of that with Stefan... I merged it into Brian's branch, so I assume it went in. If you could give me a couple of common use cases, I shall make sure they are implemented. Run the tests in the current version with: nosetests -v --with-doctest --doctest-tests IPython.config Regards St?fan From ellisonbg.net at gmail.com Wed Jun 11 23:05:10 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 11 Jun 2008 21:05:10 -0600 Subject: [IPython-dev] IPython 0.9 release... In-Reply-To: <9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com> References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com> <9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com> Message-ID: <6ce0ac130806112005n7b56fa65g926f51b6b3d28161@mail.gmail.com> Yep, the sconfig stuff made it in. Barry is also going to clean up and commit the frontendbase and the cocoa frontend. The only major things from ipython1 that won't be in yet are the notebook and the daemon. Brian On Wed, Jun 11, 2008 at 7:12 PM, St?fan van der Walt wrote: > 2008/6/12 Fernando Perez : >> Question: did you merge sconfig? I missed the details of that with Stefan... > > I merged it into Brian's branch, so I assume it went in. If you could > give me a couple of common use cases, I shall make sure they are > implemented. Run the tests in the current version with: > > nosetests -v --with-doctest --doctest-tests IPython.config > > Regards > St?fan > From vivian at vdesmedt.com Wed Jun 11 23:41:20 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Thu, 12 Jun 2008 05:41:20 +0200 Subject: [IPython-dev] Synchronization with Editor In-Reply-To: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com> References: <484553B1.9020405@vdesmedt.com> <484A3976.5040207@vdesmedt.com> <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com> Message-ID: <48509AE0.3040200@vdesmedt.com> Ville, I have updated my branch according to the comment you put on the white board. I have removed the ip_synchronize_with_xxx.py file and add a ipy_synchronize_with.py version that contains the code for each supported editor. Now if you want that IPython synchronize the code it highlight and your favorite editor you have to add the following line to your ip_user_conf.py file: import ipy_synchronize_with py_synchronize_with.scite() Supposing the that scite is your favorite editor. Currently emacs, gvim, scite, notepadplusplus, pspad and ultraedit are supported but it should be easy to add some more. Please tell what should I do to help you testing or reviewing my propositions. Regards, Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cohen at slac.stanford.edu Thu Jun 12 04:01:30 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Thu, 12 Jun 2008 10:01:30 +0200 Subject: [IPython-dev] an issue in replaying logs with profile Message-ID: <4850D7DA.2090903@slac.stanford.edu> hi there, I am using a very recent bazaar build of ipython and python 2.5. I have the following profile in my IPYTHONDIR: [cohen at jarrett ~]$ more .ipython/ipy_profile_test.py import IPython.ipapi ip = IPython.ipapi.get() ip.ex("print '*****************************************************'") ip.ex("print '* TEST *'") ip.ex("print '*****************************************************'") ip.ex("import os") I then run the following : [cohen at jarrett ~]$ ipython -profile test -log Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : rotate Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: n=5.2 In [2]: os Out[2]: after exiting the session, the log looks like : [cohen at jarrett ~]$ more ipython_log.py #log# Automatic Logger file. *** THIS MUST BE THE FIRST LINE *** #log# DO NOT CHANGE THIS LINE OR THE TWO BELOW #log# opts = Struct({'__allownew': True, 'log': 1, 'logfile': 'ipython_log.py', 'profile': ''}) #log# args = [] #log# It is safe to make manual edits below here. #log#----------------------------------------------------------------------- n=5.2 os That does *not* look good because the 'profile' value is blank, and indeed : [cohen at jarrett ~]$ ipython -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active Replaying log... Loading log file one line at a time... Finished replaying log file The following lines/blocks in file reported errors: os Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: os --------------------------------------------------------------------------- NameError Traceback (most recent call last) /home/cohen/ in () NameError: name 'os' is not defined There was no 'TEST' banner and no importing of os, as anticipated as the profile is not filled in the log. Even more problematic : [cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active Replaying log... Loading log file one line at a time... Finished replaying log file The following lines/blocks in file reported errors: os Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. Here the -profile argument request is not even honored.... If I add test as the profile in the log file, then I get the correct behavior in both cases : [cohen at jarrett ~]$ ipython -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Replaying log... Loading log file one line at a time... Finished replaying log file Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: os Out[1]: In [2]: n Out[2]: 5.2000000000000002 In [3]: Do you really want to exit ([y]/n)? [cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Replaying log... Loading log file one line at a time... Finished replaying log file Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: os Out[1]: In [2]: n Out[2]: 5.2000000000000002 So to make a long story short : there is a faulty behavior of the logger that does not correctly save the profile used. I am trying to read the code (Logger.py and ipilib.py seem to be the natural candidates) but if someone finds the correct patch more quickly, I will be happy too :). cheers, Johann From vivainio at gmail.com Thu Jun 12 07:37:46 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 12 Jun 2008 14:37:46 +0300 Subject: [IPython-dev] IPython documentation In-Reply-To: References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> Message-ID: <46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com> On Thu, Jun 12, 2008 at 3:58 AM, Fernando Perez wrote: > Thanks for doing this, it was needed. For one thing, search was > broken with the single-file one. Actually, with single file, search is just ctrl + F away ;-) Additional advantage of a single big file is that it's easy to print (both the source and built documentation), if need be (e.g. if you don't happen have the pdf handy). The .rst document is usable as a documentation as such, on systems that don't have viewers for other file systems. It's true, though, that Sphinx is optimized for multiple source files, so either way is fine. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From fperez.net at gmail.com Thu Jun 12 08:41:35 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 12 Jun 2008 05:41:35 -0700 Subject: [IPython-dev] Synchronization with Editor In-Reply-To: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com> References: <484553B1.9020405@vdesmedt.com> <484A3976.5040207@vdesmedt.com> <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 10:09 AM, Ville M. Vainio wrote: > On Sat, Jun 7, 2008 at 10:32 AM, Vivian De Smedt wrote: > >> Dear All, >> >> Just to tell you that I just push my "synchronize-editor" branch. > > Thank you, especially for taking the time to create a bzr branch! > Makes the process so much cleaner... Yes, extra brownie points to Vivian for doing it this way. We really appreciate it. Cheers, f From vivainio at gmail.com Thu Jun 12 11:00:33 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 12 Jun 2008 18:00:33 +0300 Subject: [IPython-dev] cd a little hyper In-Reply-To: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com> References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com> <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com> <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com> <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com> Message-ID: <46cb515a0806120800s3e3c5916ob0854774985fecf3@mail.gmail.com> On Fri, Jun 6, 2008 at 9:55 AM, Ville M. Vainio wrote: >> Now in the case of somedir containing only a *single* non-hidden dir >> and *no* plain files, I think the current hyper-completion is a >> feature. But if there are files and/or dirs in the target dir, I >> don't think you want to assume a subdir for completion. > > I agree that it's not desirable. However, it was a compromise to get > this bug fixed. > > Perhaps I'll add an option for this, so that it will only be a > workaround for those who have the buggy readline. I have now disabled this "feature". The only thing we can do for people with buggy readline is to suggest them to re-enable it by import ipy_completers ipy_completer.greedy_cd_completer = True -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From ellisonbg.net at gmail.com Thu Jun 12 13:03:39 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 11:03:39 -0600 Subject: [IPython-dev] IPython documentation In-Reply-To: <46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com> References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> <46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com> Message-ID: <6ce0ac130806121003n53e84893t6705fa1c30e444f@mail.gmail.com> > > Actually, with single file, search is just ctrl + F away ;-) > > Additional advantage of a single big file is that it's easy to print > (both the source and built documentation), if need be (e.g. if you > don't happen have the pdf handy). The .rst document is usable as a > documentation as such, on systems that don't have viewers for other > file systems. > > It's true, though, that Sphinx is optimized for multiple source files, > so either way is fine. The main reason that I did this is that the size of the single file was becoming a bit crazy with all of the new parallel computing docs merged in. I really want the docs to be easy for us devs to maintain and having multiple files really help a lot. Brian > -- > Ville M. Vainio - vivainio.googlepages.com > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' > From pav at iki.fi Thu Jun 12 14:32:16 2008 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 12 Jun 2008 21:32:16 +0300 Subject: [IPython-dev] Fwd: IPython documentation In-Reply-To: <9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com> References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> <9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com> Message-ID: <1213295536.10989.27.camel@localhost.localdomain> On ?2008/6/12 ?Fernando Perez wrote: [clip] > One thing that I've been mulling is using the new scipy doc system > > http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/ > > for the manuals as well. I know it's doable, I just don't know right > now how closely tied to docstring editing (the original purpose) it > is. Stefan can tell us... Actually using it also for manuals could be in the interest of the Scipy documentation project too. The system itself is not really tied to docstring editing: what needs to be done depends on whether you need 3-way merging with SVN (or bzr or whatever) or not. If yes, it's probably easiest to modify the docstring collector script to also collect text from given .rst files, implement support for text files in the patch generation, and adjust the logic in the web interface slightly so that it knows that the docstring standard shouldn't be enforced for some entries. All of this is not a lot of extra work. If 3-way merges are not needed, one could simply use the wiki functionality in the program as an RST editor, and possibly write some code to easily export multiple wiki pages at once. For writing Sphinx documents, some amount of work would probably be needed in adding support for the Sphinx special directives. Writing this code is probably the hardest part as it requires some familiarity with the internals of the docutils package. Pauli From ellisonbg.net at gmail.com Thu Jun 12 14:36:50 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 12:36:50 -0600 Subject: [IPython-dev] ChangLog vs changes.txt Message-ID: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com> Hi, In the process of reorganizing the IPython documentation, I ran into something related to the ChangeLog. In the past, IPython has used a traditional ChangeLog for devs to record the changes they have made to the project. This was used to keep track of who has done what and what things have been done since the last release. In IPython1 on the other hand, I had moved away from using the ChangeLog for the following reasons: 1. A linear ChangeLog is a poor reflection of what happens to the core when a distributed VCS is used. In fact, I would say it could potentially be downright confusing. 2. The ChangeLog really is a repetition of the information that is contained in the commit messages (which in a DVCS do reflect the distributed/parallel nature of development). 3. The ChangeLog doesn't really give users anything useful. Sure they could read it, but it is not written in a user focused manner and they would have to sift through a lot of irrelevant information. 4. To generate things like release notes, what's new, api changes etc. (user focused docs), someone has to do the tedious task of looking through the ChangeLog and summarizing the changes in user friendly form. The success of this is shown in the lack of user focued high quality release notes, what new and api change documentation for IPython. 5. For those of us who don't use emacs, the format of the ChangeLog leaves something to be desired. 6. The ChangeLog format does not integrate with our Sphinx docs as it is not rst. To address these issue with IPython1, we recently went the following route: 1. We no longer maintain a ChangeLog 2. We instead have a changes.txt files that is 1) regular rst and 2) part of our Sphinx based docs. This document lists changes for each release of IPython separately and for each release, includes three sections: new features, bug fixes and backward incompatible changes. The goal of this document is to record in a user focused way all of the changes to IPython. I was inspired to create this after looking at how a number of different projects handle this issue. So, for now I have left the IPython ChangeLog in place, but I propose that we abandon it (move it to docs/attic) and begin using the new document that I have created: docs/source/changes.txt At some level, I picture this file as part of our contract with users. If there is something new that a user needs to know about IPython, this is where they should look. Also note that the file immediately provides a usable release notes for our releases. Here is what that document looks like currently, to give you an idea: ########################## changes.txt .. _changes: ========== What's new ========== .. contents:: Release 0.9 =========== New features ------------ * All of the parallel computing capabilities from `ipython1-dev` have been merged into IPython proper. This resulted in the following new subpackages: :mod:`IPython.kernel`, :mod:`IPython.kernel.core`, :mod:`IPython.config`, :mod:`IPython.tools` and :mod:`IPython.testing`. * As part of merging in the `ipython1-dev` stuff, the `setup.py` script and friends have been completely refactored. Now we are checking for dependencies using the approach that matplotlib uses. * The documentation has been completely reorganized to accept the documentation from `ipython1-dev`. * We have switched to using Foolscap for all of our network protocols in :mod:`IPython.kernel`. This gives us secure connections that are both encrypted and authenticated. * We have a brand new `COPYING.txt` files that describes the IPython license and copyright. The biggest change is that we are putting "The IPython Development Team" as the copyright holder. We give more details about exactly what this means in this file. All developer should read this and use the new banner in all IPython source code files. Bug fixes --------- * A few subpackages has missing `__init__.py` files. * The documentation is only created is Sphinx is found. Previously, the `setup.py` script would fail if it was missing. Backwards incompatible changes ------------------------------ * IPython has a larger set of dependencies if you want all of its capabilities. See the `setup.py` script for details. * The constructors for :class:`IPython.kernel.client.MultiEngineClient` and :class:`IPython.kernel.client.TaskClient` no longer take the (ip,port) tuple. Instead they take the filename of a file that contains the FURL for that client. If the FURL file is in your IPYTHONDIR, it will be found automatically and the constructor can be left empty. * The asynchronous clients in :mod:`IPython.kernel.asyncclient` are now created using the factory functions :func:`get_multiengine_client` and :func:`get_task_client`. These return a `Deferred` to the actual client. * The command line options to `ipcontroller` and `ipengine` have changed to reflect the new Foolscap network protocol and the FURL files. Please see the help for these scripts for details. * The configuration files for the kernel have changed because of the Foolscap stuff. If you were using custom config files before, you should delete them and regenerate new ones. Changes merged in from IPython1 ------------------------------- New features ............ * Much improved ``setup.py`` and ``setupegg.py`` scripts. Because Twisted and zope.interface are now easy installable, we can declare them as dependencies in our setupegg.py script. * IPython is now compatible with Twisted 2.5.0 and 8.x. * Added a new example of how to use :mod:`ipython1.kernel.asynclient`. * Initial draft of a process daemon in :mod:`ipython1.daemon`. This has not been merged into IPython and is still in `ipython1-dev`. * The ``TaskController`` now has methods for getting the queue status. * The ``TaskResult`` objects not have information about how long the task took to run. * We are attaching additional attributes to exceptions ``(_ipython_*)`` that we use to carry additional info around. * New top-level module :mod:`asyncclient` that has asynchronous versions (that return deferreds) of the client classes. This is designed to users who want to run their own Twisted reactor * All the clients in :mod:`client` are now based on Twisted. This is done by running the Twisted reactor in a separate thread and using the :func:`blockingCallFromThread` function that is in recent versions of Twisted. * Functions can now be pushed/pulled to/from engines using :meth:`MultiEngineClient.push_function` and :meth:`MultiEngineClient.pull_function`. * Gather/scatter are now implemented in the client to reduce the work load of the controller and improve performance. * Complete rewrite of the IPython docuementation. All of the documentation from the IPython website has been moved into docs/source as restructured text documents. PDF and HTML documentation are being generated using Sphinx. * New developer oriented documentation: development guidelines and roadmap. * Traditional ``ChangeLog`` has been changed to a more useful ``changes.txt`` file that is organized by release and is meant to provide something more relevant for users. Bug fixes ......... * Created a proper ``MANIFEST.in`` file to create source distributions. * Fixed a bug in the ``MultiEngine`` interface. Previously, multi-engine actions were being collected with a :class:`DeferredList` with ``fireononeerrback=1``. This meant that methods were returning before all engines had given their results. This was causing extremely odd bugs in certain cases. To fix this problem, we have 1) set ``fireononeerrback=0`` to make sure all results (or exceptions) are in before returning and 2) introduced a :exc:`CompositeError` exception that wraps all of the engine exceptions. This is a huge change as it means that users will have to catch :exc:`CompositeError` rather than the actual exception. Backwards incompatible changes .............................. * All names have been renamed to conform to the lowercase_with_underscore convention. This will require users to change references to all names like ``queueStatus`` to ``queue_status``. * Previously, methods like :meth:`MultiEngineClient.push` and :meth:`MultiEngineClient.push` used ``*args`` and ``**kwargs``. This was becoming a problem as we weren't able to introduce new keyword arguments into the API. Now these methods simple take a dict or sequence. This has also allowed us to get rid of the ``*All`` methods like :meth:`pushAll` and :meth:`pullAll`. These things are now handled with the ``targets`` keyword argument that defaults to ``'all'``. * The :attr:`MultiEngineClient.magicTargets` has been renamed to :attr:`MultiEngineClient.targets`. * All methods in the MultiEngine interface now accept the optional keyword argument ``block``. * Renamed :class:`RemoteController` to :class:`MultiEngineClient` and :class:`TaskController` to :class:`TaskClient`. * Renamed the top-level module from :mod:`api` to :mod:`client`. * Most methods in the multiengine interface now raise a :exc:`CompositeError` exception that wraps the user's exceptions, rather than just raising the raw user's exception. * Changed the ``setupNS`` and ``resultNames`` in the ``Task`` class to ``push`` and ``pull``. Release 0.8.4 ============= Someone needs to describe what went into 0.8.4. Release 0.8.2 ============= * %pushd/%popd behave differently; now "pushd /foo" pushes CURRENT directory and jumps to /foo. The current behaviour is closer to the documented behaviour, and should not trip anyone. Release 0.8.3 ============= * pydb is now disabled by default (due to %run -d problems). You can enable it by passing -pydb command line argument to IPython. Note that setting it in config file won't work. Older releases ============== Changes in earlier releases of IPython are described in the older file ``ChangeLog``. Please refer to this document for details. ########################## /changes.txt So, what do people think about this proposal? Cheers, Brian From ellisonbg.net at gmail.com Thu Jun 12 14:41:07 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 12:41:07 -0600 Subject: [IPython-dev] IPython documentation In-Reply-To: References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> Message-ID: <6ce0ac130806121141k696d3f3bx8537db46dade79c@mail.gmail.com> On Wed, Jun 11, 2008 at 6:58 PM, Fernando Perez wrote: > On Wed, Jun 11, 2008 at 3:35 PM, Brian Granger wrote: >> Hello all, >> >> So, I have finished merging in the ipython1 documentation into IPython >> proper. Now all the docs are in one place. >> >> In addition to doing this merge, I have taken the liberty of >> completely reorganizing the docs. Previously, the IPython docs were a >> single rst file, which was really awkward and didn't take advantage of >> Sphinx's nice features. In the process of doing all this, I realized >> that the IPython docs (not the parallel computing stuff) need quite a >> bit of care and attention. I would like to see if we can get people >> to put in time to get our docs back up to where they should be. Here >> is what I am thinking: > > Thanks for doing this, it was needed. For one thing, search was > broken with the single-file one. > > One thing that I've been mulling is using the new scipy doc system > > http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/ > > for the manuals as well. I know it's doable, I just don't know right > now how closely tied to docstring editing (the original purpose) it > is. Stefan can tell us... Something like this would be a huge help. I agree with you that it is likely that it can be done, but we would need to make sure that it can handle all of the custom Sphinx rst directives. I would be very curious to heard from Stefan on this At the same time, I strongly feel that our new Sphinx/rst based docs are nice enough that we have no excuses for not writing great documentation :) Brian > Cheers, > > f > From dfj225 at gmail.com Thu Jun 12 15:33:22 2008 From: dfj225 at gmail.com (Doug Jones) Date: Thu, 12 Jun 2008 15:33:22 -0400 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient In-Reply-To: <6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com> References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> <1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com> <6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com> <1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com> <6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com> Message-ID: <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com> Hi Brian, I ran into some more issues installing IPython on a different machine. This machine runs Python 2.4 and it seems that some of the IPython code is now using the 'with' statement, which I don't think is included in Python 2.4. Is 2.4 no longer supported? The trace from my setup.py install attempt has been copied at the end of the message. Thanks, ~Doug Note: I'd already executed a python setup.py build without error. python setup.py install --prefix=$HOME/local ============================================================================ BUILDING IPYTHON python: 2.4.4 (#1, Jul 29 2007, 19:42:10) [GCC 4.1.1 (Gentoo 4.1.1-r3)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 2.5.0 Foolscap: 0.2.8 OpenSSL: 0.6 sphinx: 0.3 pygments: 0.10 nose: 0.10.3 pexpect: 0.999 running install running build running build_py running build_scripts running install_lib byte-compiling /home/djones/local/lib/python2.4/site-packages/IPython/config/config.py to config.pyc File "/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py", line 49 with raw(self): ^ SyntaxError: invalid syntax byte-compiling /home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py to contexts.pyc File "/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py", line 171 with parallel as pr: ^ SyntaxError: invalid syntax running install_scripts changing mode of /home/djones/local/bin/pycolor to 755 changing mode of /home/djones/local/bin/ipengine to 755 changing mode of /home/djones/local/bin/ipcontroller to 755 changing mode of /home/djones/local/bin/ipcluster to 755 changing mode of /home/djones/local/bin/ipython to 755 changing mode of /home/djones/local/bin/irunner to 755 running install_data Traceback (most recent call last): File "setup.py", line 174, in ? setup(**setup_args) File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/distutils/command/install.py", line 510, in run self.run_command(cmd_name) File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line 75, in run (out, _) = self.copy_file(f, dir) File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file dry_run=self.dry_run) File "/usr/lib/python2.4/distutils/file_util.py", line 117, in copy_file if not os.path.isfile(src): File "/usr/lib/python2.4/posixpath.py", line 208, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, list found On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger wrote: > > Connecting with the MultiEngineClient is working now. It seems that it > was > > simply from passing the wrong arguments to the constructor that I was > having > > problems before. > > > > All in all, I think the furl files are an improvement and the addition of > > secure connections is certainly appreciated. > > Thanks for the feedback. We _really_ needed to address the security > issue and I think Foolscap and the furls really work well. They give > a high level of security, but make it pretty easy to setup. > > Brian > > > Thanks, > > ~doug > > > > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger > > wrote: > >> > >> > Thanks for the information. I thought I had used the configuration > >> > creation > >> > command to create .furl files in my home directory. Right now, i'm > using > >> > mpiexec to start the engines, so perhaps this is creating some sort of > >> > issue > >> > with the shell environment the engines are created in. I'll double > check > >> > and > >> > let you know if I continue to have problems. > >> > >> Hmm, if you are editing the ipython config files to set the locations > >> of the furl files, that should work. Maybe the only thing you need to > >> change is how you are creating the MultiEngineClient. > >> > >> It no longer takes the (ip, port) tuple. It now takes the name of the > >> furl file, or if empty it will use the location given in the config > >> files. > >> > >> Keep me posted. > >> > >> Brian > >> > >> > ~doug > >> > > >> > > >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger gmail.com> > >> > wrote: > >> >> > >> >> This is not a unicode error, but rather, our API for starting the > >> >> client has changed due to the new security stuff. This is the stuff > >> >> that I am working on documenting as we speak. > >> >> > >> >> Here is a minimal description: > >> >> > >> >> 1) When the controller now starts, it creates a set of files (in your > >> >> .ipython directory by default) > >> >> > >> >> ipcontroller-tc.furl > >> >> ipcontroller-mec.furl > >> >> ipcontroller-engine.furl > >> >> > >> >> 2) These files contain a secure URL that 1) tells the engine and > >> >> clients where the controller is running and 2) gives the engine and > >> >> clients authority to connect to the controller in a secure manner. > >> >> > >> >> 3) To use these files, they have to be available to the client and > >> >> engines when they start. The easiest way of handling this is to > >> >> > >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the > >> >> machine(s) where the engines will run > >> >> > >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine > >> >> where the clients will run. > >> >> > >> >> Then everything will "just work". By this, I mean that you can > create > >> >> the clients with no arguments: > >> >> > >> >> mec = client.MultiEngineClient() > >> >> > >> >> If you have put the .furl files in different locations you can do: > >> >> > >> >> mec = > >> >> client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl') > >> >> > >> >> In all of this, you can think of the furl files as being keys (just > >> >> like a house key) that grants an entity access to a particular > >> >> resource. The controller creates the keys and the engines/client > must > >> >> present/use them to use the capabilities of the controller. > >> >> > >> >> See if you can use this to get things working. The big benefit of > >> >> using all this is: > >> >> > >> >> 1) Users don't have to track what ip/port the controller is running > on. > >> >> > >> >> 2) Everything is secure by default - authentication + encryption (if > >> >> you have pyOpenSSL installed > >> >> > >> >> 3) The controller now uses random port numbers, making it even more > >> >> difficult for hostiles to discover. > >> >> > >> >> Let me know if you have any more problems getting this working. We > >> >> would love feedback if you have ideas of how things could be made > >> >> easier. > >> >> > >> >> Also, check out the new command line flags on the ipcontroller and > >> >> ipengine scripts to control where the furl files are created and > >> >> looked for. > >> >> > >> >> Cheers, > >> >> > >> >> Brian > >> >> > >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones > wrote: > >> >> > Hi all, > >> >> > > >> >> > I tried a simple test of the latest IPython branch and the > >> >> > MultiEngineClient. When I attempted to connect to a running cluster > >> >> > on > >> >> > my > >> >> > local machine, I got the following error: > >> >> > > >> >> > mec = client.MultiEngineClient(('localhost', 10105)) > >> >> > > >> >> > > >> >> > > --------------------------------------------------------------------------- > >> >> > TypeError Traceback (most recent > call > >> >> > last) > >> >> > > >> >> > /home/djones/svn/basin_remote/trunk/scripts/ in > >> >> > () > >> >> > > >> >> > > >> >> > > >> >> > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc > >> >> > in get_multiengine_client(furl_or_file) > >> >> > 67 """ > >> >> > 68 client = > >> >> > blockingCallFromThread(_client_tub.get_multiengine_client, > >> >> > ---> 69 furl_or_file) > >> >> > 70 return client.adapt_to_blocking_client() > >> >> > 71 > >> >> > > >> >> > > >> >> > > >> >> > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc > >> >> > in blockingCallFromThread(f, *a, **kw) > >> >> > 97 result.raiseException() > >> >> > 98 except Exception, e: > >> >> > ---> 99 raise e > >> >> > 100 return result > >> >> > 101 > >> >> > > >> >> > TypeError: coercing to Unicode: need string or buffer, tuple found > >> >> > > >> >> > > >> >> > > >> >> > Thanks, > >> >> > ~Doug > >> >> > > >> >> > _______________________________________________ > >> >> > IPython-dev mailing list > >> >> > IPython-dev at scipy.org > >> >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Thu Jun 12 16:05:20 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:05:20 -0600 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient In-Reply-To: <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com> References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> <1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com> <6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com> <1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com> <6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com> <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com> Message-ID: <6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com> Doug, We haven't thought about this yet and it is a big issue. I will make another post about this that we can all use to work out this issue. Brian On Thu, Jun 12, 2008 at 1:33 PM, Doug Jones wrote: > Hi Brian, > > I ran into some more issues installing IPython on a different machine. This > machine runs Python 2.4 and it seems that some of the IPython code is now > using the 'with' statement, which I don't think is included in Python 2.4. > Is 2.4 no longer supported? > > The trace from my setup.py install attempt has been copied at the end of the > message. > > Thanks, > ~Doug > > Note: I'd already executed a python setup.py build without error. > > python setup.py install --prefix=$HOME/local > ============================================================================ > BUILDING IPYTHON > python: 2.4.4 (#1, Jul 29 2007, 19:42:10) [GCC 4.1.1 > (Gentoo 4.1.1-r3)] > platform: linux2 > > OPTIONAL DEPENDENCIES > Zope.Interface: yes > Twisted: 2.5.0 > Foolscap: 0.2.8 > OpenSSL: 0.6 > sphinx: 0.3 > pygments: 0.10 > nose: 0.10.3 > pexpect: 0.999 > running install > running build > running build_py > running build_scripts > running install_lib > byte-compiling > /home/djones/local/lib/python2.4/site-packages/IPython/config/config.py to > config.pyc > File > "/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py", > line 49 > with raw(self): > ^ > SyntaxError: invalid syntax > byte-compiling > /home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py to > contexts.pyc > File > "/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py", > line 171 > with parallel as pr: > ^ > SyntaxError: invalid syntax > running install_scripts > changing mode of /home/djones/local/bin/pycolor to 755 > changing mode of /home/djones/local/bin/ipengine to 755 > changing mode of /home/djones/local/bin/ipcontroller to 755 > changing mode of /home/djones/local/bin/ipcluster to 755 > changing mode of /home/djones/local/bin/ipython to 755 > changing mode of /home/djones/local/bin/irunner to 755 > running install_data > Traceback (most recent call last): > File "setup.py", line 174, in ? > setup(**setup_args) > File "/usr/lib/python2.4/distutils/core.py", line 149, in setup > dist.run_commands() > File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File "/usr/lib/python2.4/distutils/command/install.py", line 510, in run > self.run_command(cmd_name) > File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line > 75, in run > (out, _) = self.copy_file(f, dir) > File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file > dry_run=self.dry_run) > File "/usr/lib/python2.4/distutils/file_util.py", line 117, in copy_file > if not os.path.isfile(src): > File "/usr/lib/python2.4/posixpath.py", line 208, in isfile > st = os.stat(path) > TypeError: coercing to Unicode: need string or buffer, list found > > > > > On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger > wrote: >> >> > Connecting with the MultiEngineClient is working now. It seems that it >> > was >> > simply from passing the wrong arguments to the constructor that I was >> > having >> > problems before. >> > >> > All in all, I think the furl files are an improvement and the addition >> > of >> > secure connections is certainly appreciated. >> >> Thanks for the feedback. We _really_ needed to address the security >> issue and I think Foolscap and the furls really work well. They give >> a high level of security, but make it pretty easy to setup. >> >> Brian >> >> > Thanks, >> > ~doug >> > >> > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger >> > wrote: >> >> >> >> > Thanks for the information. I thought I had used the configuration >> >> > creation >> >> > command to create .furl files in my home directory. Right now, i'm >> >> > using >> >> > mpiexec to start the engines, so perhaps this is creating some sort >> >> > of >> >> > issue >> >> > with the shell environment the engines are created in. I'll double >> >> > check >> >> > and >> >> > let you know if I continue to have problems. >> >> >> >> Hmm, if you are editing the ipython config files to set the locations >> >> of the furl files, that should work. Maybe the only thing you need to >> >> change is how you are creating the MultiEngineClient. >> >> >> >> It no longer takes the (ip, port) tuple. It now takes the name of the >> >> furl file, or if empty it will use the location given in the config >> >> files. >> >> >> >> Keep me posted. >> >> >> >> Brian >> >> >> >> > ~doug >> >> > >> >> > >> >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger >> >> > >> >> > wrote: >> >> >> >> >> >> This is not a unicode error, but rather, our API for starting the >> >> >> client has changed due to the new security stuff. This is the stuff >> >> >> that I am working on documenting as we speak. >> >> >> >> >> >> Here is a minimal description: >> >> >> >> >> >> 1) When the controller now starts, it creates a set of files (in >> >> >> your >> >> >> .ipython directory by default) >> >> >> >> >> >> ipcontroller-tc.furl >> >> >> ipcontroller-mec.furl >> >> >> ipcontroller-engine.furl >> >> >> >> >> >> 2) These files contain a secure URL that 1) tells the engine and >> >> >> clients where the controller is running and 2) gives the engine and >> >> >> clients authority to connect to the controller in a secure manner. >> >> >> >> >> >> 3) To use these files, they have to be available to the client and >> >> >> engines when they start. The easiest way of handling this is to >> >> >> >> >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the >> >> >> machine(s) where the engines will run >> >> >> >> >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine >> >> >> where the clients will run. >> >> >> >> >> >> Then everything will "just work". By this, I mean that you can >> >> >> create >> >> >> the clients with no arguments: >> >> >> >> >> >> mec = client.MultiEngineClient() >> >> >> >> >> >> If you have put the .furl files in different locations you can do: >> >> >> >> >> >> mec = >> >> >> >> >> >> client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl') >> >> >> >> >> >> In all of this, you can think of the furl files as being keys (just >> >> >> like a house key) that grants an entity access to a particular >> >> >> resource. The controller creates the keys and the engines/client >> >> >> must >> >> >> present/use them to use the capabilities of the controller. >> >> >> >> >> >> See if you can use this to get things working. The big benefit of >> >> >> using all this is: >> >> >> >> >> >> 1) Users don't have to track what ip/port the controller is running >> >> >> on. >> >> >> >> >> >> 2) Everything is secure by default - authentication + encryption (if >> >> >> you have pyOpenSSL installed >> >> >> >> >> >> 3) The controller now uses random port numbers, making it even more >> >> >> difficult for hostiles to discover. >> >> >> >> >> >> Let me know if you have any more problems getting this working. We >> >> >> would love feedback if you have ideas of how things could be made >> >> >> easier. >> >> >> >> >> >> Also, check out the new command line flags on the ipcontroller and >> >> >> ipengine scripts to control where the furl files are created and >> >> >> looked for. >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Brian >> >> >> >> >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones >> >> >> wrote: >> >> >> > Hi all, >> >> >> > >> >> >> > I tried a simple test of the latest IPython branch and the >> >> >> > MultiEngineClient. When I attempted to connect to a running >> >> >> > cluster >> >> >> > on >> >> >> > my >> >> >> > local machine, I got the following error: >> >> >> > >> >> >> > mec = client.MultiEngineClient(('localhost', 10105)) >> >> >> > >> >> >> > >> >> >> > >> >> >> > --------------------------------------------------------------------------- >> >> >> > TypeError Traceback (most recent >> >> >> > call >> >> >> > last) >> >> >> > >> >> >> > /home/djones/svn/basin_remote/trunk/scripts/ in >> >> >> > () >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc >> >> >> > in get_multiengine_client(furl_or_file) >> >> >> > 67 """ >> >> >> > 68 client = >> >> >> > blockingCallFromThread(_client_tub.get_multiengine_client, >> >> >> > ---> 69 furl_or_file) >> >> >> > 70 return client.adapt_to_blocking_client() >> >> >> > 71 >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc >> >> >> > in blockingCallFromThread(f, *a, **kw) >> >> >> > 97 result.raiseException() >> >> >> > 98 except Exception, e: >> >> >> > ---> 99 raise e >> >> >> > 100 return result >> >> >> > 101 >> >> >> > >> >> >> > TypeError: coercing to Unicode: need string or buffer, tuple found >> >> >> > >> >> >> > >> >> >> > >> >> >> > Thanks, >> >> >> > ~Doug >> >> >> > >> >> >> > _______________________________________________ >> >> >> > 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 Jun 12 16:11:29 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:11:29 -0600 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this Message-ID: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Hi, Now that all of the stuff from ipython1 has moved into IPython, IPython has new fancy parallel computing capabilities.....and..... a dependency on Python 2.5. Here is the story. In IPython.kernel there is a likely lots of code that requires python 2.4, and a little that requires 2.5. At this point, it is probably too late to get rid of the 2.4 specific stuff, but we still have to figure out what to do about 2.5 specific syntax and features. The main things are our usage of the with statement. Currently building IPython with <2.5 gives a syntax error because of this. We clearly need to fix this as IPython definitely needs to run under 2.4. But, how do we want to handle these things? Requires 2.4 and make 2.5 features optional? Thoughts? Brian From dfj225 at gmail.com Thu Jun 12 16:24:22 2008 From: dfj225 at gmail.com (Doug Jones) Date: Thu, 12 Jun 2008 16:24:22 -0400 Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient In-Reply-To: <6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com> References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com> <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com> <1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com> <6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com> <1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com> <6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com> <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com> <6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com> Message-ID: <1315be7e0806121324s25d6ac77g1499c14218356750@mail.gmail.com> Ok. The traceback at the end of my last message also seems to occur with Python 2.5 now. This issue seems to have cropped up in one of the most recent commits, since I didn't notice it yesterday. ~doug python setup.py install --prefix=$HOME/local ============================================================================ BUILDING IPYTHON python: 2.5.2 (r252:60911, Jun 10 2008, 15:09:04) [GCC 4.1.2 (Gentoo 4.1.2 p1.0.1)] platform: linux2 OPTIONAL DEPENDENCIES Zope.Interface: yes Twisted: 2.5.0 Foolscap: 0.2.8 OpenSSL: 0.7 sphinx: 0.3 pygments: 0.10 nose: 0.9.3 pexpect: 2.1 running install running build running build_py running build_scripts running install_lib copying build/lib/IPython/Extensions/ipy_completers.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/Extensions copying build/lib/IPython/Release.py -> /home/djones/local/lib64/python2.5/site-packages/IPython copying build/lib/IPython/config/api.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config copying build/lib/IPython/config/tests/sample_config.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests copying build/lib/IPython/config/tests/test_config.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests copying build/lib/IPython/config/tests/__init__.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests copying build/lib/IPython/config/config.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config copying build/lib/IPython/config/traitlets.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/config copying build/lib/IPython/UserConfig/__init__.py -> /home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig copying build/lib/IPython/UserConfig/__init__.pyc -> /home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig copying build/lib/IPython/UserConfig/ipy_user_conf.pyc -> /home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/Extensions/ipy_completers.py to ipy_completers.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/Release.py to Release.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/api.py to api.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/sample_config.py to sample_config.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/test_config.py to test_config.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/__init__.py to __init__.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/config.py to config.pyc byte-compiling /home/djones/local/lib64/python2.5/site-packages/IPython/config/traitlets.py to traitlets.pyc running install_scripts copying build/scripts-2.5/ipengine -> /home/djones/local/bin copying build/scripts-2.5/irunner -> /home/djones/local/bin copying build/scripts-2.5/pycolor -> /home/djones/local/bin copying build/scripts-2.5/ipcluster -> /home/djones/local/bin copying build/scripts-2.5/ipcontroller -> /home/djones/local/bin copying build/scripts-2.5/ipython -> /home/djones/local/bin changing mode of /home/djones/local/bin/ipengine to 755 changing mode of /home/djones/local/bin/irunner to 755 changing mode of /home/djones/local/bin/pycolor to 755 changing mode of /home/djones/local/bin/ipcluster to 755 changing mode of /home/djones/local/bin/ipcontroller to 755 changing mode of /home/djones/local/bin/ipython to 755 running install_data Traceback (most recent call last): File "setup.py", line 174, in setup(**setup_args) File "/usr/lib64/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib64/python2.5/distutils/command/install.py", line 510, in run self.run_command(cmd_name) File "/usr/lib64/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line 75, in run (out, _) = self.copy_file(f, dir) File "/usr/lib64/python2.5/distutils/cmd.py", line 376, in copy_file dry_run=self.dry_run) File "/usr/lib64/python2.5/distutils/file_util.py", line 117, in copy_file if not os.path.isfile(src): File "/usr/lib64/python2.5/posixpath.py", line 208, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, list found On Thu, Jun 12, 2008 at 4:05 PM, Brian Granger wrote: > Doug, > > We haven't thought about this yet and it is a big issue. I will make > another post about this that we can all use to work out this issue. > > Brian > > On Thu, Jun 12, 2008 at 1:33 PM, Doug Jones wrote: > > Hi Brian, > > > > I ran into some more issues installing IPython on a different machine. > This > > machine runs Python 2.4 and it seems that some of the IPython code is now > > using the 'with' statement, which I don't think is included in Python > 2.4. > > Is 2.4 no longer supported? > > > > The trace from my setup.py install attempt has been copied at the end of > the > > message. > > > > Thanks, > > ~Doug > > > > Note: I'd already executed a python setup.py build without error. > > > > python setup.py install --prefix=$HOME/local > > > ============================================================================ > > BUILDING IPYTHON > > python: 2.4.4 (#1, Jul 29 2007, 19:42:10) [GCC 4.1.1 > > (Gentoo 4.1.1-r3)] > > platform: linux2 > > > > OPTIONAL DEPENDENCIES > > Zope.Interface: yes > > Twisted: 2.5.0 > > Foolscap: 0.2.8 > > OpenSSL: 0.6 > > sphinx: 0.3 > > pygments: 0.10 > > nose: 0.10.3 > > pexpect: 0.999 > > running install > > running build > > running build_py > > running build_scripts > > running install_lib > > byte-compiling > > /home/djones/local/lib/python2.4/site-packages/IPython/config/config.py > to > > config.pyc > > File > > > "/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py", > > line 49 > > with raw(self): > > ^ > > SyntaxError: invalid syntax > > byte-compiling > > /home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py > to > > contexts.pyc > > File > > > "/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py", > > line 171 > > with parallel as pr: > > ^ > > SyntaxError: invalid syntax > > running install_scripts > > changing mode of /home/djones/local/bin/pycolor to 755 > > changing mode of /home/djones/local/bin/ipengine to 755 > > changing mode of /home/djones/local/bin/ipcontroller to 755 > > changing mode of /home/djones/local/bin/ipcluster to 755 > > changing mode of /home/djones/local/bin/ipython to 755 > > changing mode of /home/djones/local/bin/irunner to 755 > > running install_data > > Traceback (most recent call last): > > File "setup.py", line 174, in ? > > setup(**setup_args) > > File "/usr/lib/python2.4/distutils/core.py", line 149, in setup > > dist.run_commands() > > File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands > > self.run_command(cmd) > > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > > cmd_obj.run() > > File "/usr/lib/python2.4/distutils/command/install.py", line 510, in > run > > self.run_command(cmd_name) > > File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command > > self.distribution.run_command(command) > > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > > cmd_obj.run() > > File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", > line > > 75, in run > > (out, _) = self.copy_file(f, dir) > > File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file > > dry_run=self.dry_run) > > File "/usr/lib/python2.4/distutils/file_util.py", line 117, in > copy_file > > if not os.path.isfile(src): > > File "/usr/lib/python2.4/posixpath.py", line 208, in isfile > > st = os.stat(path) > > TypeError: coercing to Unicode: need string or buffer, list found > > > > > > > > > > On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger > > wrote: > >> > >> > Connecting with the MultiEngineClient is working now. It seems that it > >> > was > >> > simply from passing the wrong arguments to the constructor that I was > >> > having > >> > problems before. > >> > > >> > All in all, I think the furl files are an improvement and the addition > >> > of > >> > secure connections is certainly appreciated. > >> > >> Thanks for the feedback. We _really_ needed to address the security > >> issue and I think Foolscap and the furls really work well. They give > >> a high level of security, but make it pretty easy to setup. > >> > >> Brian > >> > >> > Thanks, > >> > ~doug > >> > > >> > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger gmail.com> > >> > wrote: > >> >> > >> >> > Thanks for the information. I thought I had used the configuration > >> >> > creation > >> >> > command to create .furl files in my home directory. Right now, i'm > >> >> > using > >> >> > mpiexec to start the engines, so perhaps this is creating some sort > >> >> > of > >> >> > issue > >> >> > with the shell environment the engines are created in. I'll double > >> >> > check > >> >> > and > >> >> > let you know if I continue to have problems. > >> >> > >> >> Hmm, if you are editing the ipython config files to set the locations > >> >> of the furl files, that should work. Maybe the only thing you need > to > >> >> change is how you are creating the MultiEngineClient. > >> >> > >> >> It no longer takes the (ip, port) tuple. It now takes the name of > the > >> >> furl file, or if empty it will use the location given in the config > >> >> files. > >> >> > >> >> Keep me posted. > >> >> > >> >> Brian > >> >> > >> >> > ~doug > >> >> > > >> >> > > >> >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> This is not a unicode error, but rather, our API for starting the > >> >> >> client has changed due to the new security stuff. This is the > stuff > >> >> >> that I am working on documenting as we speak. > >> >> >> > >> >> >> Here is a minimal description: > >> >> >> > >> >> >> 1) When the controller now starts, it creates a set of files (in > >> >> >> your > >> >> >> .ipython directory by default) > >> >> >> > >> >> >> ipcontroller-tc.furl > >> >> >> ipcontroller-mec.furl > >> >> >> ipcontroller-engine.furl > >> >> >> > >> >> >> 2) These files contain a secure URL that 1) tells the engine and > >> >> >> clients where the controller is running and 2) gives the engine > and > >> >> >> clients authority to connect to the controller in a secure manner. > >> >> >> > >> >> >> 3) To use these files, they have to be available to the client and > >> >> >> engines when they start. The easiest way of handling this is to > >> >> >> > >> >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the > >> >> >> machine(s) where the engines will run > >> >> >> > >> >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the > machine > >> >> >> where the clients will run. > >> >> >> > >> >> >> Then everything will "just work". By this, I mean that you can > >> >> >> create > >> >> >> the clients with no arguments: > >> >> >> > >> >> >> mec = client.MultiEngineClient() > >> >> >> > >> >> >> If you have put the .furl files in different locations you can do: > >> >> >> > >> >> >> mec = > >> >> >> > >> >> >> > client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl') > >> >> >> > >> >> >> In all of this, you can think of the furl files as being keys > (just > >> >> >> like a house key) that grants an entity access to a particular > >> >> >> resource. The controller creates the keys and the engines/client > >> >> >> must > >> >> >> present/use them to use the capabilities of the controller. > >> >> >> > >> >> >> See if you can use this to get things working. The big benefit of > >> >> >> using all this is: > >> >> >> > >> >> >> 1) Users don't have to track what ip/port the controller is > running > >> >> >> on. > >> >> >> > >> >> >> 2) Everything is secure by default - authentication + encryption > (if > >> >> >> you have pyOpenSSL installed > >> >> >> > >> >> >> 3) The controller now uses random port numbers, making it even > more > >> >> >> difficult for hostiles to discover. > >> >> >> > >> >> >> Let me know if you have any more problems getting this working. > We > >> >> >> would love feedback if you have ideas of how things could be made > >> >> >> easier. > >> >> >> > >> >> >> Also, check out the new command line flags on the ipcontroller and > >> >> >> ipengine scripts to control where the furl files are created and > >> >> >> looked for. > >> >> >> > >> >> >> Cheers, > >> >> >> > >> >> >> Brian > >> >> >> > >> >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones > >> >> >> wrote: > >> >> >> > Hi all, > >> >> >> > > >> >> >> > I tried a simple test of the latest IPython branch and the > >> >> >> > MultiEngineClient. When I attempted to connect to a running > >> >> >> > cluster > >> >> >> > on > >> >> >> > my > >> >> >> > local machine, I got the following error: > >> >> >> > > >> >> >> > mec = client.MultiEngineClient(('localhost', 10105)) > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > --------------------------------------------------------------------------- > >> >> >> > TypeError Traceback (most recent > >> >> >> > call > >> >> >> > last) > >> >> >> > > >> >> >> > /home/djones/svn/basin_remote/trunk/scripts/ in > >> >> >> > () > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc > >> >> >> > in get_multiengine_client(furl_or_file) > >> >> >> > 67 """ > >> >> >> > 68 client = > >> >> >> > blockingCallFromThread(_client_tub.get_multiengine_client, > >> >> >> > ---> 69 furl_or_file) > >> >> >> > 70 return client.adapt_to_blocking_client() > >> >> >> > 71 > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc > >> >> >> > in blockingCallFromThread(f, *a, **kw) > >> >> >> > 97 result.raiseException() > >> >> >> > 98 except Exception, e: > >> >> >> > ---> 99 raise e > >> >> >> > 100 return result > >> >> >> > 101 > >> >> >> > > >> >> >> > TypeError: coercing to Unicode: need string or buffer, tuple > found > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Thanks, > >> >> >> > ~Doug > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > IPython-dev mailing list > >> >> >> > IPython-dev at scipy.org > >> >> >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Jun 12 16:27:40 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 12 Jun 2008 13:27:40 -0700 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger wrote: > Hi, > > Now that all of the stuff from ipython1 has moved into IPython, > IPython has new fancy parallel computing capabilities.....and..... a > dependency on Python 2.5. > > Here is the story. In IPython.kernel there is a likely lots of code > that requires python 2.4, and a little that requires 2.5. At this > point, it is probably too late to get rid of the 2.4 specific stuff, > but we still have to figure out what to do about 2.5 specific syntax > and features. > > The main things are our usage of the with statement. Currently > building IPython with <2.5 gives a syntax error because of this. We > clearly need to fix this as IPython definitely needs to run under 2.4. > But, how do we want to handle these things? Requires 2.4 and make > 2.5 features optional? Thoughts? I have a few minutes of network... I can't test which step fails right now, because the setup.py install is crashing for me with all versions: Traceback (most recent call last): File "setup.py", line 174, in setup(**setup_args) File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run self.run_command(cmd_name) File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py", line 75, in run (out, _) = self.copy_file(f, dir) File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file dry_run=self.dry_run) File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file if not os.path.isfile(src): File "/usr/lib/python2.5/posixpath.py", line 208, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, list found In a couple of hours I may be able to pull bzr again and will test. I can play with alternatives for the 2.5 dependency. I think we'll have to be OK with 2.4 as a dependency for versions >= 0.9, but 2.5 is definitely a little harsh. I *really* want those cool context managers in there, the idea is too cool not to put it in. But we need them to be optional. The trick is to exclude them from the build process if the setup.py file is processed with python2.4, since they simply won't compile at all (the with statement is a syntax error). It may require a bit of distutils hackery with the MANIFEST.in, but I don't think it's impossible to make them optional. Cheers, f From ellisonbg.net at gmail.com Thu Jun 12 16:29:37 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:29:37 -0600 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: <6ce0ac130806121329m22ad7ecfo17b90a48fe751adb@mail.gmail.com> Yep, Doug just pointed this problem out to me. I will fix right now. I think I am the responsible one for this. Sorry. Brian On Thu, Jun 12, 2008 at 2:27 PM, Fernando Perez wrote: > On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger wrote: >> Hi, >> >> Now that all of the stuff from ipython1 has moved into IPython, >> IPython has new fancy parallel computing capabilities.....and..... a >> dependency on Python 2.5. >> >> Here is the story. In IPython.kernel there is a likely lots of code >> that requires python 2.4, and a little that requires 2.5. At this >> point, it is probably too late to get rid of the 2.4 specific stuff, >> but we still have to figure out what to do about 2.5 specific syntax >> and features. >> >> The main things are our usage of the with statement. Currently >> building IPython with <2.5 gives a syntax error because of this. We >> clearly need to fix this as IPython definitely needs to run under 2.4. >> But, how do we want to handle these things? Requires 2.4 and make >> 2.5 features optional? Thoughts? > > I have a few minutes of network... > > I can't test which step fails right now, because the setup.py install > is crashing for me with all versions: > > Traceback (most recent call last): > File "setup.py", line 174, in > setup(**setup_args) > File "/usr/lib/python2.5/distutils/core.py", line 151, in setup > dist.run_commands() > File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run > self.run_command(cmd_name) > File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py", > line 75, in run > (out, _) = self.copy_file(f, dir) > File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file > dry_run=self.dry_run) > File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file > if not os.path.isfile(src): > File "/usr/lib/python2.5/posixpath.py", line 208, in isfile > st = os.stat(path) > TypeError: coercing to Unicode: need string or buffer, list found > > > In a couple of hours I may be able to pull bzr again and will test. I > can play with alternatives for the 2.5 dependency. > > I think we'll have to be OK with 2.4 as a dependency for versions >= > 0.9, but 2.5 is definitely a little harsh. I *really* want those cool > context managers in there, the idea is too cool not to put it in. > But we need them to be optional. The trick is to exclude them from > the build process if the setup.py file is processed with python2.4, > since they simply won't compile at all (the with statement is a syntax > error). > > It may require a bit of distutils hackery with the MANIFEST.in, but I > don't think it's impossible to make them optional. > > Cheers, > > f > From robert.kern at gmail.com Thu Jun 12 16:34:43 2008 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 12 Jun 2008 15:34:43 -0500 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: Fernando Perez wrote: > I think we'll have to be OK with 2.4 as a dependency for versions >= > 0.9, but 2.5 is definitely a little harsh. I *really* want those cool > context managers in there, the idea is too cool not to put it in. You can define the context managers all you like as long as you don't use them in the library code itself. As far as I can tell, the only place you actually use a with statement is in the demo code at the bottom of context.py which, as noted in the comments, really ought to be moved into a real test suite. > But we need them to be optional. The trick is to exclude them from > the build process if the setup.py file is processed with python2.4, > since they simply won't compile at all (the with statement is a syntax > error). I have seen this give warnings, but I don't think it stops the build, usually. -- 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 Thu Jun 12 16:41:37 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 12 Jun 2008 13:41:37 -0700 Subject: [IPython-dev] ChangLog vs changes.txt In-Reply-To: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com> References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com> Message-ID: On Thu, Jun 12, 2008 at 11:36 AM, Brian Granger wrote: > Hi, > > In the process of reorganizing the IPython documentation, I ran into > something related to the ChangeLog. In the past, IPython has used a > traditional ChangeLog for devs to record the changes they have made to > the project. This was used to keep track of who has done what and > what things have been done since the last release. In IPython1 on the > other hand, I had moved away from using the ChangeLog for the > following reasons: > > 1. A linear ChangeLog is a poor reflection of what happens to the > core when a distributed VCS is used. In fact, I would say it could > potentially be downright confusing. > > 2. The ChangeLog really is a repetition of the information that is > contained in the commit messages (which in a DVCS do reflect the > distributed/parallel nature of development). > > 3. The ChangeLog doesn't really give users anything useful. Sure > they could read it, but it is not written in a user focused manner and > they would have to sift through a lot of irrelevant information. > > 4. To generate things like release notes, what's new, api changes > etc. (user focused docs), someone has to do the tedious task of > looking through the ChangeLog and summarizing the changes in user > friendly form. The success of this is shown in the lack of user > focued high quality release notes, what new and api change > documentation for IPython. > > 5. For those of us who don't use emacs, the format of the ChangeLog > leaves something to be desired. > > 6. The ChangeLog format does not integrate with our Sphinx docs as it > is not rst. > > To address these issue with IPython1, we recently went the following route: > > 1. We no longer maintain a ChangeLog > > 2. We instead have a changes.txt files that is 1) regular rst and 2) > part of our Sphinx based docs. > > This document lists changes for each release of IPython separately and > for each release, includes three sections: new features, bug fixes and > backward incompatible changes. The goal of this document is to record > in a user focused way all of the changes to IPython. I was inspired > to create this after looking at how a number of different projects > handle this issue. > > So, for now I have left the IPython ChangeLog in place, but I propose > that we abandon it (move it to docs/attic) and begin using the new > document that I have created: > > docs/source/changes.txt > > At some level, I picture this file as part of our contract with users. > If there is something new that a user needs to know about IPython, > this is where they should look. Also note that the file immediately > provides a usable release notes for our releases. Yup, when I did the big bzr merge I mentioned that the old-style changelog was likely the only file that would probably cause recurrent merge conflicts if we tried to use it, so it would be best to stop now. Ville concurred, if I recall correctly. One comment on this: with SVN, we were used to very terse commit messages and the more detailed info in the changelog. I'd like to encourage everyone now to do the following, since the commit log will be *the* history: use a docstring-like approach in the commit messages: """Single line summary of changes being committed. # BLANK LINE - more - details - when - warranted ... - including crediting outside contributors if they sent the code/bug/idea! """ If we couple this with a policy of making single commits for each reasonably atomic change, the bzr log should give an excellent view of the project, and the --short log option becomes a nice summary. I've added this to the rst dev guidelines now. Cheers, f From ellisonbg.net at gmail.com Thu Jun 12 16:45:37 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:45:37 -0600 Subject: [IPython-dev] ChangLog vs changes.txt In-Reply-To: References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com> Message-ID: <6ce0ac130806121345v3af7afb3t7ab6bdb61d630358@mail.gmail.com> On Thu, Jun 12, 2008 at 2:41 PM, Fernando Perez wrote: > On Thu, Jun 12, 2008 at 11:36 AM, Brian Granger wrote: >> Hi, >> >> In the process of reorganizing the IPython documentation, I ran into >> something related to the ChangeLog. In the past, IPython has used a >> traditional ChangeLog for devs to record the changes they have made to >> the project. This was used to keep track of who has done what and >> what things have been done since the last release. In IPython1 on the >> other hand, I had moved away from using the ChangeLog for the >> following reasons: >> >> 1. A linear ChangeLog is a poor reflection of what happens to the >> core when a distributed VCS is used. In fact, I would say it could >> potentially be downright confusing. >> >> 2. The ChangeLog really is a repetition of the information that is >> contained in the commit messages (which in a DVCS do reflect the >> distributed/parallel nature of development). >> >> 3. The ChangeLog doesn't really give users anything useful. Sure >> they could read it, but it is not written in a user focused manner and >> they would have to sift through a lot of irrelevant information. >> >> 4. To generate things like release notes, what's new, api changes >> etc. (user focused docs), someone has to do the tedious task of >> looking through the ChangeLog and summarizing the changes in user >> friendly form. The success of this is shown in the lack of user >> focued high quality release notes, what new and api change >> documentation for IPython. >> >> 5. For those of us who don't use emacs, the format of the ChangeLog >> leaves something to be desired. >> >> 6. The ChangeLog format does not integrate with our Sphinx docs as it >> is not rst. >> >> To address these issue with IPython1, we recently went the following route: >> >> 1. We no longer maintain a ChangeLog >> >> 2. We instead have a changes.txt files that is 1) regular rst and 2) >> part of our Sphinx based docs. >> >> This document lists changes for each release of IPython separately and >> for each release, includes three sections: new features, bug fixes and >> backward incompatible changes. The goal of this document is to record >> in a user focused way all of the changes to IPython. I was inspired >> to create this after looking at how a number of different projects >> handle this issue. >> >> So, for now I have left the IPython ChangeLog in place, but I propose >> that we abandon it (move it to docs/attic) and begin using the new >> document that I have created: >> >> docs/source/changes.txt >> >> At some level, I picture this file as part of our contract with users. >> If there is something new that a user needs to know about IPython, >> this is where they should look. Also note that the file immediately >> provides a usable release notes for our releases. > > > Yup, when I did the big bzr merge I mentioned that the old-style > changelog was likely the only file that would probably cause recurrent > merge conflicts if we tried to use it, so it would be best to stop > now. Ville concurred, if I recall correctly. > > One comment on this: with SVN, we were used to very terse commit > messages and the more detailed info in the changelog. I'd like to > encourage everyone now to do the following, since the commit log will > be *the* history: use a docstring-like approach in the commit > messages: > > """Single line summary of changes being committed. > # BLANK LINE > - more > - details > - when > - warranted ... > - including crediting outside contributors if they sent the code/bug/idea! > """ > > If we couple this with a policy of making single commits for each > reasonably atomic change, the bzr log should give an excellent view of > the project, and the --short log option becomes a nice summary. > > I've added this to the rst dev guidelines now. Great! Brian > > Cheers, > > f > From fperez.net at gmail.com Thu Jun 12 16:46:46 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 12 Jun 2008 13:46:46 -0700 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: On Thu, Jun 12, 2008 at 1:34 PM, Robert Kern wrote: > Fernando Perez wrote: > >> I think we'll have to be OK with 2.4 as a dependency for versions >= >> 0.9, but 2.5 is definitely a little harsh. I *really* want those cool >> context managers in there, the idea is too cool not to put it in. > > You can define the context managers all you like as long as you don't use them > in the library code itself. As far as I can tell, the only place you actually > use a with statement is in the demo code at the bottom of context.py which, as > noted in the comments, really ought to be moved into a real test suite. Yup, correct, I forgot that the actual managers do NOT use 'with', they only define the special methods the with protocol uses. We just need to move that code into the tests and make sure they get cleanly skipped with 2.4, and we're clear. Thanks for the reminder. Since I'll be working on the tests, I'll take care of this. Cheers, f From ellisonbg.net at gmail.com Thu Jun 12 16:48:27 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:48:27 -0600 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: <6ce0ac130806121348l49a37110kabcc9f7de3b58242@mail.gmail.com> >> You can define the context managers all you like as long as you don't use them >> in the library code itself. As far as I can tell, the only place you actually >> use a with statement is in the demo code at the bottom of context.py which, as >> noted in the comments, really ought to be moved into a real test suite. This is true, I don't think we actually need to use the with statement at this point in library code. We just need to be able to define the context managers. > Since I'll be working on the tests, I'll take care of this. Thanks. Brian > Cheers, > > f > _______________________________________________ > 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 Jun 12 16:51:16 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 12 Jun 2008 14:51:16 -0600 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: <6ce0ac130806121351q1f909facs970db886e8a34f35@mail.gmail.com> I have removed the offending code in setupbase.find_data_files. My fix is only temporary, for now the method returns an empty list so no data_files will be installed. But I am doing a full audit/fix of this code. Cheers and sorry about this. Brian On Thu, Jun 12, 2008 at 2:27 PM, Fernando Perez wrote: > On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger wrote: >> Hi, >> >> Now that all of the stuff from ipython1 has moved into IPython, >> IPython has new fancy parallel computing capabilities.....and..... a >> dependency on Python 2.5. >> >> Here is the story. In IPython.kernel there is a likely lots of code >> that requires python 2.4, and a little that requires 2.5. At this >> point, it is probably too late to get rid of the 2.4 specific stuff, >> but we still have to figure out what to do about 2.5 specific syntax >> and features. >> >> The main things are our usage of the with statement. Currently >> building IPython with <2.5 gives a syntax error because of this. We >> clearly need to fix this as IPython definitely needs to run under 2.4. >> But, how do we want to handle these things? Requires 2.4 and make >> 2.5 features optional? Thoughts? > > I have a few minutes of network... > > I can't test which step fails right now, because the setup.py install > is crashing for me with all versions: > > Traceback (most recent call last): > File "setup.py", line 174, in > setup(**setup_args) > File "/usr/lib/python2.5/distutils/core.py", line 151, in setup > dist.run_commands() > File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run > self.run_command(cmd_name) > File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command > cmd_obj.run() > File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py", > line 75, in run > (out, _) = self.copy_file(f, dir) > File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file > dry_run=self.dry_run) > File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file > if not os.path.isfile(src): > File "/usr/lib/python2.5/posixpath.py", line 208, in isfile > st = os.stat(path) > TypeError: coercing to Unicode: need string or buffer, list found > > > In a couple of hours I may be able to pull bzr again and will test. I > can play with alternatives for the 2.5 dependency. > > I think we'll have to be OK with 2.4 as a dependency for versions >= > 0.9, but 2.5 is definitely a little harsh. I *really* want those cool > context managers in there, the idea is too cool not to put it in. > But we need them to be optional. The trick is to exclude them from > the build process if the setup.py file is processed with python2.4, > since they simply won't compile at all (the with statement is a syntax > error). > > It may require a bit of distutils hackery with the MANIFEST.in, but I > don't think it's impossible to make them optional. > > Cheers, > > f > From benjaminrk at gmail.com Thu Jun 12 16:54:32 2008 From: benjaminrk at gmail.com (MinRK) Date: Thu, 12 Jun 2008 13:54:32 -0700 Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we need to fix this In-Reply-To: References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com> Message-ID: I just did a test install in 2.4, and it works fine. It throws SyntaxErrors during setup, but the install still completes and regular IPython works fine. I get the SyntaxErrors again (in kernel.config) if I try to import kernel.client, but it's certainly not a widespread problem. Only kernel/config and kernel/contexts seem to have the issue, which should be easy to remedy. -MinRK On Thu, Jun 12, 2008 at 1:34 PM, Robert Kern wrote: > Fernando Perez wrote: > > > I think we'll have to be OK with 2.4 as a dependency for versions >= > > 0.9, but 2.5 is definitely a little harsh. I *really* want those cool > > context managers in there, the idea is too cool not to put it in. > > You can define the context managers all you like as long as you don't use > them > in the library code itself. As far as I can tell, the only place you > actually > use a with statement is in the demo code at the bottom of context.py which, > as > noted in the comments, really ought to be moved into a real test suite. > > > But we need them to be optional. The trick is to exclude them from > > the build process if the setup.py file is processed with python2.4, > > since they simply won't compile at all (the with statement is a syntax > > error). > > I have seen this give warnings, but I don't think it stops the build, > usually. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Jun 12 16:57:56 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 12 Jun 2008 13:57:56 -0700 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1012: Merging edits to development.txt In-Reply-To: <-5364037501704686174@unknownmsgid> References: <-5364037501704686174@unknownmsgid> Message-ID: Hey guys, we're still getting this 'folding' problem it seems. I think with true merges we can't avoid it, but I thought if we all used pull on our local copy of the trunk we could minimize it, no? That's what I was trying to use (bzr pull instead of bzr merge) and it seemed to be working... No big deal, but I'd like to keep our log linear when the underlying development was indeed linear (as this little change was). Let's see if the pull approach works better. Anyway, I'm offline now again... Cheers, f On Thu, Jun 12, 2008 at 1:47 PM, wrote: > ------------------------------------------------------------ > revno: 1012 > committer: Brian E Granger > branch nick: ipython > timestamp: Thu 2008-06-12 14:46:16 -0600 > message: > Merging edits to development.txt > modified: > docs/source/development/development.txt > ------------------------------------------------------------ > revno: 1010.1.1 > committer: Fernando Perez > branch nick: trunk-dev > timestamp: Thu 2008-06-12 13:39:18 -0700 > message: > Update dev guide with commit message guidelines > modified: > docs/source/development/development.txt > > === modified file 'docs/source/development/development.txt' > --- a/docs/source/development/development.txt 2008-06-12 19:44:12 +0000 > +++ b/docs/source/development/development.txt 2008-06-12 20:39:18 +0000 > @@ -137,6 +137,22 @@ > $ ...do work in ipython-mybranch... > $ bzr ci -m "the commit message goes here" > > +Please note that since we now don't use an old-style linear ChangeLog > +(that tends to cause problems with distributed version control > +systems), you should ensure that your log messages are reasonably > +detailed. Use a docstring-like approach in the commit messages > +(including the second line being left *blank*):: > + > + Single line summary of changes being committed. > + > + - more details when warranted ... > + - including crediting outside contributors if they sent the > + code/bug/idea! > + > +If we couple this with a policy of making single commits for each > +reasonably atomic change, the bzr log should give an excellent view of > +the project, and the `--short` log option becomes a nice summary. > + > While working with this branch, it is a good idea to merge in changes that have been > made upstream in the parent branch. This can be done by doing:: > > > > > -- > Main line of IPython development (stable) > https://code.launchpad.net/~ipython/ipython/trunk > > You are receiving this branch notification because you are subscribed to it. > To unsubscribe from this branch go to https://code.launchpad.net/~ipython/ipython/trunk/+edit-subscription. > From stefan at sun.ac.za Thu Jun 12 17:32:21 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 12 Jun 2008 23:32:21 +0200 Subject: [IPython-dev] ChangLog vs changes.txt In-Reply-To: References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com> Message-ID: <9457e7c80806121432v5556714didc9ece238d1707a6@mail.gmail.com> 2008/6/12 Fernando Perez : > If we couple this with a policy of making single commits for each > reasonably atomic change, the bzr log should give an excellent view of > the project, and the --short log option becomes a nice summary. I spoke to some Launchpad guys last night, and they assured me that they are working on an improved log display, like the one in olive. While not ideal, the following view is marginally more useful: http://bazaar.launchpad.net/~ipython/ipython/trunk/changes As for the folding back: - The 'pull' command is really only for mirroring branches. If you don't want an identical copy of a branch, you shouldn't need to pull. - If two branches diverge (which happens when you add revisions to *both* branches at the node where they were split), a merge is necessary to bring them together again. In SVN, we were used to doing "svn update", which then brought all the changes from the trunk into your local working copy. Only if there was a conflict were you required to do a merge. In bzr, these merges are no longer optional (and you are forced to check in before merging, which is a good idea!). Since bzr needs to track those merges, you can also see them in the log file. If you prefer, you may choose to suppress these log entries, but with sensical merge messages (as David suggested), they become useful. I suspect they bother us mainly because merging has become such a scary word in the SVN world. In the end, it is more of a display issue, that, to some extent, you have worked around by having an external release notes file. I've satisfied my own concerns about bzr, but if you have any further concerns, I'd gladly research the issue further. Regards St?fan From fperez.net at gmail.com Fri Jun 13 08:41:15 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 13 Jun 2008 05:41:15 -0700 Subject: [IPython-dev] Fwd: EuroSciPy Early Registration Reminder Message-ID: # From Travis Vaught @ Enthought: Greetings, This is a friendly reminder that the Early Registration deadline for the EuroSciPy Conference is June 15th. If you're interested in attending, but have not yet registered, please visit: http://www.scipy.org/EuroSciPy2008 The talks schedule is also now available there. Also, the keynote speaker this year will be Travis Oliphant, the primary author of the recent NumPy rewrite. For those doing scientific computing using Python, this is a conference you'll not want to miss. See you there. Travis From barrywark at gmail.com Sun Jun 15 19:03:31 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 15 Jun 2008 16:03:31 -0700 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: References: Message-ID: I'm getting close to being ready to merge the ipython-frontend branch into trunk. At this point, I would like to update folks on the status of IPython.frontend and solicit comments and review before things get merged to trunk.. ==== Overview ==== IPython's InteractiveShell (in 0.8.4) is currently tied to the terminal. Thus, alternative frontends that integrate with native GUI toolkits and provide alternative rendering functionality (something like a Mathematica notebook-style interface) are currently very difficult implement with the IPython InteractiveShell. With the integration of ipython1 into IPython, we now have the opportunity to separate the interpreter/engine from the UI and to make it easier to write other types of frontends for IPython. In the IPython.frontend package, we intend to provide base functionality to make writing these frontends easier. As a proof of concept, I've written a frontend for IPython in the Cocoa toolkit for OS X. This Cocoa frontend is implemented as a drop-in component that can be included by devleopers of Cocoa apps. I've also written a demo application that provides a Matlab-style workspace (command-line and user namespace browser) using this Cocoa frontend. With the IPython.frontend.frontend.FrontEndBase and the GUI-integration provided by Twisted, the Cocoa frontend requires about 400 lines of code (including managing the text widget to simulate a CLI interface). If you would like to try out the Cocoa interface on OSX, you will currently need OS X 10.5 or greater with Developer Tools installed. Download the ipython-frontend branch from launchpad.net. In the IPython/frontend/cocoa/examples/ folder, you will find an Xcode project for IPython1Sandbox. Building and running this app should get you started. Feel free to ask me if you have any questions. Of course the normal caveats apply: this is VERY new code and many things may not work. Use at your own risk. When you find bugs, please report them on launchpad.net/ipython. ==== For Developers ==== The purpose of IPython.frontend is to provide a base class (frontend.frontendbase.FrontEndBase) for frontend writers to use in developing GUI frontends for IPython. FrontendBase provides all of the basic functionality required by the front end (testing for block completeness, managing history, executing blocks on an IPython.kernel.engineservice.IEngineBasic-implementing engine, and rendering results and errors asynchronously (via Twisted deferreds)). GUI frontends will want to subclass FrontEndBase and override the render methods (render_result and render_error) to render results and errors respectively. Each execute request can be assigned a "blockID" to allow the frontend to identify the block corresponding to the result/error. The frontend can assign this blockID or a UUID will be assigned automatically. Frontends may also override update_prompt to update the input prompt for a block once it's number is known (it may not be known until the engine executes the block if more than one client is using the same engine). The subclass must also decide when to send a block to the engine. For this, FrontEndBase provides is_complete to test whether a block is a complete statement. Once a block is complete, the frontend can send it to the engine by passing it to FrontEndBase's execute method. The result of execute is a twisted.internet.deferred.Deferred result of the execution of that block. At this point, I would appreciate comments on the entire frontend package before we consider merging ipython-frontend into trunk. There aren't any changes in the ipython-frontend branch outside of the IPython.frontend package EXCEPT to IPython.kernel.engineservice.ThreadedEngineService. I updated I.kernel.engineservice.ThreadedEngineService so that it now works and added associated tests in I.kernel.tests.test_engineservice.py. All tests pass on my Mac. ThreadedEngineService is required to prevent long-running execute calls from blocking the main GUI thread. There currently isn't any method for canceling or interrupting an executing block, but at least it doesn't block the GUI thread. Moving to a TaskClient instead of ThreadedEngineService might fix this... but that's for the future. I'm currently working to improve the documentation/comments, but the code in there are at least tests for most of the code in frontend.frontendbase at this point. - Barry From barrywark at gmail.com Mon Jun 16 01:46:35 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 15 Jun 2008 22:46:35 -0700 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <20080616025814.GA31696@phare.normalesup.org> References: <20080616025814.GA31696@phare.normalesup.org> Message-ID: Ga?l, I hope you don't mind me cc-ing this to the list, in case anyone else is curious. You'll need Mac OS X 10.5 and the Apple Developer Tools (Xcode >= 3.0), which come with the OS (or can be downloaded from developer.apple.com). You can play with the frontend by getting the ipython-frontend branch from launchpad ('bzr branch lp:~barrywark/ipython/ipython-frontend'). The demo application depends on ipython-frontend being installed in the system site-packages, so install ('sudo setupegg.py install' or 'sudo setupegg.py develop' in the ipython-frontend/ directory) the ipython-frontend branch. On OS X 10.5, it's best to use setuptools to make sure that the ipython-frontend installation plays nicely with Apple's system python. Once installed, you can open the Xcode project file in ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/. Running the project from within Xcode _should_ (fingers crossed!) start the demo frontend. You'll quickly find that the Cocoa frontend is still quite rough around the edges. For example, failures are not rendered very intelligently. There may be many other rendering/UI errors in my text view-related code. There's also no way to cancel a long-running task (except by quitting the app), there's no easy way to start an IPython cluster via Xgrid (though that's an obvious thing to do).... the list goes on. It's intended (at this point) as just a proof-of-concept for the frontend package. Eventually, I would like to get away from the CLI-based frontend and move to a more notebook-like interface. Barry On Sun, Jun 15, 2008 at 7:58 PM, Gael Varoquaux wrote: > Hi Barry, > > Just a quick question: how can we try out your work (on an Apple box, > obviously)? > > Cheers, > > Ga?l > From hans_meine at gmx.net Mon Jun 16 08:30:14 2008 From: hans_meine at gmx.net (Hans Meine) Date: Mon, 16 Jun 2008 14:30:14 +0200 Subject: [IPython-dev] Close to giving up (was: Re: Synchronization with Editor) Message-ID: <200806161430.15508.hans_meine@gmx.net> Hi Vivian, this is my Nth try to send you a little feedback, where N must be > 4 I think.. Obviously, I always sent from the wrong address. Ciao, / / /--/ / / ANS -------------- next part -------------- An embedded message was scrubbed... From: Hans Meine Subject: Re: [IPython-dev] Synchronization with Editor Date: Mon, 9 Jun 2008 16:42:24 +0200 Size: 8871 URL: From vivian at vdesmedt.com Mon Jun 16 09:50:20 2008 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Mon, 16 Jun 2008 15:50:20 +0200 Subject: [IPython-dev] Close to giving up (was: Re: Synchronization with Editor) In-Reply-To: <200806161430.15508.hans_meine@gmx.net> References: <200806161430.15508.hans_meine@gmx.net> Message-ID: <48566F9C.6070203@vdesmedt.com> Hi Heinz, Thanks for your technical feedback. Here are my answer to the three points I have isolated in your mails. Tell me if I have missed one. > * IMO hooks.synchronize_with_editor should be merged with > hooks.fix_error_editor. > I suspect IPython to assume that when fix_error_editor hook will return the error will be fixed. So that hook should be synchronous. It should give back the hand to the editor and wait that the user validate the changes by closing the editor or sending a signal (e.g. emacs). The synchronize_with_editor hook don't have to be synchronous. It has to synchronize the editor with IPython, opening the script file at the right line, and return (no user input needed). So if we merge both hooks I think we should at least add a parameter to tell what should be the action of the hook: - synchronize and wait for validation before returning or - synchronize only and return. With the multi tab editor or multi buffer editor the first kind of hooks are not so easy to write. You don't want to quit the editor at the end of the edition and you have no built in way to signal that you have finish with the edition of a particular file opened in the editor (emacs is the exception). > * I think the win32 imports should be wrapped in a conditional block > for *nix users to benefit from this. > About the unix version I'll be glad to improve the code to support them what I think should be improved is the following: - The .exe extention should be removed (I just remove them) - The name of the executables should be checked (scite, emacsclient, gvim, ...) - We should provide alternative for runCommand, sleep and restoreConsoleFocus Unfortunately I have no access to a linux box to test possible alternatives. If someone could propose something I'll be glad to incorporate it into the ip_synchronize_width.py propositions of hooks. > * Nearly the same code can be used for XEmacs/gnuserv (using gnuclient instead > of gvim as command). > In the emacs version of the hook I have implemented something based on emacsclient that seems to works well for emacs at least on the win32 platform. Tell me what you think. Did you had a chance to test the hooks for some editor. Did you find it useful or handy? Kindest regards, Vivian. From gael.varoquaux at normalesup.org Mon Jun 16 10:02:52 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 16 Jun 2008 16:02:52 +0200 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: References: <20080616025814.GA31696@phare.normalesup.org> Message-ID: <20080616140252.GA3938@phare.normalesup.org> On Sun, Jun 15, 2008 at 10:46:35PM -0700, Barry Wark wrote: > I hope you don't mind me cc-ing this to the list, in case anyone else > is curious. No, not replying to the list was actually unintended. > Running the project from within Xcode _should_ (fingers crossed!) > start the demo frontend. That was the part that took us a while to get: we just tried to "python foobar.py" the thing, but apparently Apple likes to "think different", and this does not work. > You'll quickly find that the Cocoa frontend is still quite rough > around the edges. My one question is: what is the plan for interacting with the GUI mainloop. For example how to I open matlplotlib windows? I guess this is a more general question: what is the road forward on frontends for this problem? Ga?l From barrywark at gmail.com Mon Jun 16 11:30:02 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 16 Jun 2008 08:30:02 -0700 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <20080616140252.GA3938@phare.normalesup.org> References: <20080616025814.GA31696@phare.normalesup.org> <20080616140252.GA3938@phare.normalesup.org> Message-ID: On Mon, Jun 16, 2008 at 7:02 AM, Gael Varoquaux wrote: > On Sun, Jun 15, 2008 at 10:46:35PM -0700, Barry Wark wrote: >> I hope you don't mind me cc-ing this to the list, in case anyone else >> is curious. > > No, not replying to the list was actually unintended. > >> Running the project from within Xcode _should_ (fingers crossed!) >> start the demo frontend. > > That was the part that took us a while to get: we just tried to "python > foobar.py" the thing, but apparently Apple likes to "think different", > and this does not work. You can write Cocoa apps with this method (PyObjCTools.AppHelper includes functions to start/stop the main loop and you can build the entire Cocoa stack in code), but the Xcode project wraps the whole thing in a true native OS X app. It includes one compiled file (main.m) which loads the python interpreter, adds any application-specific python packages/modules (which are included in the app bundle) to the sys.path and exec's the main.py file. My guess is that using 'python main.py' with an appropriate PYTHONPATH would do the trick, though I haven't tried it. The "benefit" of Apple's approach is that the app is a native OS X application bundle with all the associated LaunchServices support, icons, ability to include frameworks/python/resources/plugins in the app bundle etc. > >> You'll quickly find that the Cocoa frontend is still quite rough >> around the edges. > > My one question is: what is the plan for interacting with the GUI > mainloop. For example how to I open matlplotlib windows? That's a great question. You can currently use matplotlib exactly as you would from a standard python prompt (ie with show()). The caveat is that all of the matplotlib backends on OS X think they are being run from a CLI, not GUI and so attempt to create/hijack their own event loop, often by instantiating a run loop in backend's toolkit. Since Wx, Tk, and Qt are implemented in Carbon on OS X, they don't mix very well with the Cocoa run loop. This leads to some weird menu bar behavior etc. and, with some backends, causes the matplotlib windows to get stuck on screen. This is a general problem with matplotlib, not with the Cocoa front end, per-se (the same problems crop up using the PyInterpreter example in the Developer Tools/Examples folder). So, how can we get all this working? There are really two parts of this question... > > I guess this is a more general question: what is the road forward on > frontends for this problem? 1. There's no reason that matplotlib needs to create its own run loop. I've been working off and on on a true Cocoa backend form Matplotlib. My intention is to make it play nicely with an existing Cocoa run loop etc. This would address the issue you asked about above, namely using matplotlib interactively from the frontend's own engine. 2. There's a deeper issue in the ipython1 architecture that Brian and I have just started to have a couple of discussions about (he may have had similar conversations with other folks too, of course). What happens if a client executes code on a remote engine such as "pyplot.plot([1,2,3]);show()" that produces something besides stout output? What do we want to happen? One possibility is that we'd like the resulting plot to be displayed to the user by their client, either in-line in a notebook style interface or in a separate window in a command-line style interface. Brian and I discussed adding a rendering package to IPython.kernel.core. Renderers would be registered by object type, so that a specific renderer could be registered for matplotlib figure or Lines2D or whatever. A default, pprint renderer would catch all cases of types that don't have a registered renderer. When the core returns the result of an exec, it could instead substitute the renderer for that result. Alternatively, the client could explicty request the renderer for a particular object in the engine's namespace. In the case of matplotlib plots that renderer could produce a static image of the plot to be passed to the client (easy) or a proxy object that could continue to interact with the plot remotely (harder, but doable). Objects might also be able to specify their own rederer via a __renderer__ property, for example. In this way, the matplotlib or chaco or MayaVi etc. developers could add IPython renderer support to their library directly. Well, at least that's the idea... as always, there's a lot to do and a real functional/technical spec or code will speak much louder than words. Cheers, Barry From barrywark at gmail.com Mon Jun 16 11:33:18 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 16 Jun 2008 08:33:18 -0700 Subject: [IPython-dev] Error in cocoa frontend build. In-Reply-To: <76D322BD-A981-454A-944E-B4A09B995A89@tamu.edu> References: <76D322BD-A981-454A-944E-B4A09B995A89@tamu.edu> Message-ID: Hi Rob! It looks to me like you're somehow getting PyObjC 1.4 rather than PyObjC2. Do you have the python.org framework installed in /Library/Frameworks and/or have you installed PyObjC 1.4 into the system python? In my experience, Xcode and/or the compiled app gets confused when there's the /Library/Frameworks python. I've removed /Library/Frameowrks/Python.framework completely and haven't looked back. Barry On Mon, Jun 16, 2008 at 12:04 AM, Rob Hetland wrote: > > I'm pretty excited about the development you've been doing on a cocoa > frontend. I got the code, and tried to compile, but it fails on run. > Here's what the concol says after a debug compile: > > I'm not sure how to fix this, but figure you might know. > > I'm on 10.5 now (previously when we were exchanging emails about kd-trees, I > was still on 10.4), use the system python, and have successfully tried out > ipython1 stuff (so Twisted and all that are there and working.) > > Any ideas? > > -Rob > > > > 6/16/08 8:55:58 AM IPython1Sandbox[1201] *** Terminating app due to uncaught > exception 'NSInternalInconsistencyException', reason: > '/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/main.m:44 > main() PyRun_SimpleFile failed with file > '/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/main.py'. > See console for errors.' > 6/16/08 8:55:58 AM IPython1Sandbox[1201] Stack: ( > 2497098059, > 2518483195, > 2497097515, > 2497097578 > ) > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > Traceback (most recent call last): > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > File > "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/main.py", > line 20, in > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > import IPython1SandboxAppDelegate > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > File > "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/IPython1SandboxAppDelegate.py", > line 17, in > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > class IPython1SandboxAppDelegate(NSObject): > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > File > "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/IPython1SandboxAppDelegate.py", > line 18, in IPython1SandboxAppDelegate > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > ipythonController = objc.IBOutlet() > 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201] > TypeError: IBOutlet() takes exactly 1 argument (0 given) > 6/16/08 8:56:01 AM com.apple.launchd[115] > ([0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]) Exited abnormally: > Trace/BPT trap > > > > ---- > Rob Hetland, Associate Professor > Dept. of Oceanography, Texas A&M University > http://pong.tamu.edu/~rob > phone: 979-458-0096, fax: 979-845-6331 > > > > From jorgen.stenarson at bostream.nu Mon Jun 16 14:52:10 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 16 Jun 2008 20:52:10 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> Message-ID: <4856B65A.1000903@bostream.nu> Fernando Perez skrev: > Hey, > > On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson > wrote: >> Hi, >> >> I just registered pyreadline at launchpad. Considering all the traffic >> on bzr problems. I just thought I should ask here what is the best way >> to move svn over to launchpad? How do I handle the branches and tags? > ... > > - Do an import from the raw svn repo. I can run an svn dump of the > whole repo and put it up for you to download if you want to play with > things there (I can probably dump just the pyreadline part so it's > smaller). > > I've tried a few different ways that didn't work out satisfactorily. The launchpad-import branch that Ville created doesn't seem to work. So I would like to try to work from a svn dump. If you can do a dump of pyreadline/trunk and put it somewhere I can download it I'd be happy. /J?rgen From fperez.net at gmail.com Tue Jun 17 02:34:40 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 16 Jun 2008 23:34:40 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <4856B65A.1000903@bostream.nu> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> Message-ID: Hey, On Mon, Jun 16, 2008 at 11:52 AM, J?rgen Stenarson wrote: > I've tried a few different ways that didn't work out satisfactorily. The > launchpad-import branch that Ville created doesn't seem to work. So I would > like to try to work from a svn dump. If you can do a dump of > pyreadline/trunk and put it somewhere I can download it I'd be happy. I just dumped the whole ipython repo here: http://ipython.scipy.org/dist/iprepo.svndump.bz2 Let me know how it goes. Note that this is the entire repo (as best I could see, svnadmind dump doesn't take any path options, only revisions). This should give you all the data needed to play locally with the bzr import tools. Cheers, f From ondrej at certik.cz Tue Jun 17 06:28:20 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Tue, 17 Jun 2008 12:28:20 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> Message-ID: <85b5c3130806170328k27858a4bl7b371de112c4c320@mail.gmail.com> On Mon, Jun 2, 2008 at 8:35 PM, Fernando Perez wrote: > Hey, > > On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson > wrote: >> Hi, >> >> I just registered pyreadline at launchpad. Considering all the traffic >> on bzr problems. I just thought I should ask here what is the best way >> to move svn over to launchpad? How do I handle the branches and tags? > > Great! I just approved you for the ip team as well. > > I'm not an expert, but you can follow one of several routes: > > - use the bzr svn plugin. This will let you do imports of the svn > history with a fair bit of control. > > - Register a branch for their vcs-imports team, typically the trunk. > Here's the ipython one: > > https://code.launchpad.net/~vcs-imports/ipython/main > > Yesterday what I did was to use that one for the ipython svn->bzr > final move, and basically ditch all the svn tags. Our svn repo is not > going away, so we can always refer to that for historical purposes. > And if there's ever a move to destroy the svn repo on scipy.org, we > can also convert the whole thing to bzr. > > - Do an import from the raw svn repo. I can run an svn dump of the > whole repo and put it up for you to download if you want to play with > things there (I can probably dump just the pyreadline part so it's > smaller). > > > In my case, I just went for easy: launchpad did the original svn > import of trunk for us, so it was the least amount of effort to start > from there. Unless you really want to keep all branches and tags also > in bzr, that will get you off the ground quickly and with full history > (as I said, you can keep on referring to SVN for the foreseeable > future, and if anything ever changes there I'll let you know). > >> By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to >> go but this year I'm not going to do a presentation. > > I think John Hunter was considering swinging by, but I'm not sure what > his final plans are, check with him. I know some of the Enthought > guys will go, and perhaps Ondrej could make it, since he's not too > far. I have too much other stuff going on, and no travel budget for > that kind of trip right now. I am definitely going and we'll have a presentation about sfepy and sympy with Robert Cimrman: http://www.scipy.org/EuroSciPy2008Abstracts#rcimrman It'd be great of some ipython developers could come too. Ondrej From jorgen.stenarson at bostream.nu Tue Jun 17 14:09:10 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 17 Jun 2008 20:09:10 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> Message-ID: <4857FDC6.7050202@bostream.nu> Fernando Perez skrev: > Hey, > > On Mon, Jun 16, 2008 at 11:52 AM, J?rgen Stenarson > wrote: > >> I've tried a few different ways that didn't work out satisfactorily. The >> launchpad-import branch that Ville created doesn't seem to work. So I would >> like to try to work from a svn dump. If you can do a dump of >> pyreadline/trunk and put it somewhere I can download it I'd be happy. > > I just dumped the whole ipython repo here: > > http://ipython.scipy.org/dist/iprepo.svndump.bz2 > > Let me know how it goes. Note that this is the entire repo (as best I > could see, svnadmind dump doesn't take any path options, only > revisions). This should give you all the data needed to play locally > with the bzr import tools. Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3 for svn 1.5? I used svn2bzr from 'bzr branch lp:svn2bzr'. My svndumpfilter command (svn 1.4.6) also complains that dumpfile format 3 is not supported. /J?rgen From fperez.net at gmail.com Tue Jun 17 14:25:13 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 17 Jun 2008 11:25:13 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <4857FDC6.7050202@bostream.nu> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> Message-ID: On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson wrote: > Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile > you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3 > for svn 1.5? Mmh, that's weird. The svn version on that machine is very old: ipython at scipy[~]$ svn --version svn, version 1.2.3 (r15833) compiled Aug 26 2005, 03:42:45 I did a dump with --deltas to make it a bit smaller, let me try again without deltas and see if that helps. I'll be back as soon as it completes. f From fperez.net at gmail.com Tue Jun 17 14:47:54 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 17 Jun 2008 11:47:54 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> Message-ID: On Tue, Jun 17, 2008 at 11:25 AM, Fernando Perez wrote: > On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson > wrote: > >> Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile >> you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3 >> for svn 1.5? > > Mmh, that's weird. The svn version on that machine is very old: > > ipython at scipy[~]$ svn --version > svn, version 1.2.3 (r15833) > compiled Aug 26 2005, 03:42:45 > > I did a dump with --deltas to make it a bit smaller, let me try again > without deltas and see if that helps. OK, here it is. Note that this file is 50MB large, but it's the plain 'svn dump' output without any --deltas, so it might be easier to process. http://ipython.scipy.org/dist/iprepo.svndump-full.bz2 Let me know if that still doesn't work, I could also make a tarball of the raw repo. Since nobody is committing to it and we use the FSFS backend, that should be safe to simply dump to a file and transport over to another machine. Cheers, f From jorgen.stenarson at bostream.nu Tue Jun 17 16:13:32 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 17 Jun 2008 22:13:32 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> Message-ID: <48581AEC.1070803@bostream.nu> Fernando Perez skrev: > On Tue, Jun 17, 2008 at 11:25 AM, Fernando Perez wrote: >> On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson >> wrote: >> >>> Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile >>> you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3 >>> for svn 1.5? >> Mmh, that's weird. The svn version on that machine is very old: >> >> ipython at scipy[~]$ svn --version >> svn, version 1.2.3 (r15833) >> compiled Aug 26 2005, 03:42:45 >> >> I did a dump with --deltas to make it a bit smaller, let me try again >> without deltas and see if that helps. > > OK, here it is. Note that this file is 50MB large, but it's the plain > 'svn dump' output without any --deltas, so it might be easier to > process. > > http://ipython.scipy.org/dist/iprepo.svndump-full.bz2 > > Let me know if that still doesn't work, I could also make a tarball of > the raw repo. Since nobody is committing to it and we use the FSFS > backend, that should be safe to simply dump to a file and transport > over to another machine. > Argh, this is frustrating. The full dump worked better. But I had to change svn2bzr to open files in binary mode. But then it barfs when there is a Node-action: change in the dump file. Apparently svn2bzr does not support the full dump file format or there is some other problem. Can you run svn2bzr on the dumpfile without problems? I could try the other svn2bzr branch which is supposed to work directly on the repo. But that will have to wait until tomorrow. Well I did a quick test but that branch crashes hard when I try to work directly to the repo on ipython.scipy.org. Perhaps we could try to do the tarball of the whole repo. It seems these more advanced problems are tricky to do on windows. I sure hope it is easier to work with bzr in a normal situation. /J?rgen From eyecat at gmail.com Tue Jun 17 16:27:23 2008 From: eyecat at gmail.com (Yuhui H) Date: Tue, 17 Jun 2008 13:27:23 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <48581AEC.1070803@bostream.nu> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> Message-ID: On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson wrote: > It seems these more advanced problems are tricky to do on windows. I > sure hope it is easier to work with bzr in a normal situation. Hi, I'm not an expert on either bzr or IPython/PyReadline, But branching from svn to bzr seems to work without a hitch for me (for this svn repo anyway). I'm using Windows, python2.5 with bzr source distribution 1.6b2, and bzr-svn from http://d5190871.u44.websitesource.net/bzr-svn/ (and official win32 subversion binary). All I need to do to is: bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline If you want, I can upload my bzr branch somewhere as a zip package. Or I can push it to launchpad somewhere. Yuhui From jorgen.stenarson at bostream.nu Tue Jun 17 16:50:12 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 17 Jun 2008 22:50:12 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> Message-ID: <48582384.5040100@bostream.nu> Yuhui H skrev: > On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson > wrote: >> It seems these more advanced problems are tricky to do on windows. I >> sure hope it is easier to work with bzr in a normal situation. > > Hi, > > I'm not an expert on either bzr or IPython/PyReadline, But branching > from svn to bzr seems to work without a hitch for me (for this svn > repo anyway). > > I'm using Windows, python2.5 with bzr source distribution 1.6b2, and > bzr-svn from > http://d5190871.u44.websitesource.net/bzr-svn/ > (and official win32 subversion binary). > > All I need to do to is: > > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline > > If you want, I can upload my bzr branch somewhere as a zip package. Or > I can push it to launchpad somewhere. > > Yuhui > I'll try to use 1.6 tomorrow. If it doesn't work out for me I'll let you know and we can try to use your branch. Thanks for the tip. /J?rgen From fperez.net at gmail.com Tue Jun 17 19:26:51 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 17 Jun 2008 16:26:51 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <48581AEC.1070803@bostream.nu> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> Message-ID: Hey, On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson wrote: > Argh, this is frustrating. The full dump worked better. But I had to change > svn2bzr to open files in binary mode. But then it barfs when there is a > Node-action: change in the dump file. Apparently svn2bzr does not support > the full dump file format or there is some other problem. Can you run > svn2bzr on the dumpfile without problems? > > I could try the other svn2bzr branch which is supposed to work directly on > the repo. But that will have to wait until tomorrow. Well I did a quick test > but that branch crashes hard when I try to work directly to the repo on > ipython.scipy.org. Perhaps we could try to do the tarball of the whole repo. > > It seems these more advanced problems are tricky to do on windows. I sure > hope it is easier to work with bzr in a normal situation. OK, in order to give you all the possible options, I just made a dump of the raw filesystem directory containing the repo: http://ipython.scipy.org/dist/iprepo.svnraw.tar.bz2 This file is 14MB. I hope one of these works... Cheers, f From fperez.net at gmail.com Tue Jun 17 20:17:50 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 17 Jun 2008 17:17:50 -0700 Subject: [IPython-dev] Fwd: IPython documentation In-Reply-To: <1213295536.10989.27.camel@localhost.localdomain> References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com> <9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com> <1213295536.10989.27.camel@localhost.localdomain> Message-ID: On Thu, Jun 12, 2008 at 11:32 AM, Pauli Virtanen wrote: > If yes, it's probably easiest to modify the docstring collector script > to also collect text from given .rst files, implement support for text > files in the patch generation, and adjust the logic in the web interface > slightly so that it knows that the docstring standard shouldn't be > enforced for some entries. All of this is not a lot of extra work. > > If 3-way merges are not needed, one could simply use the wiki > functionality in the program as an RST editor, and possibly write some > code to easily export multiple wiki pages at once. > > For writing Sphinx documents, some amount of work would probably be > needed in adding support for the Sphinx special directives. Writing this > code is probably the hardest part as it requires some familiarity with > the internals of the docutils package. I'm focusing right now on all the testing machinery (not completely trivial, given that 'ipython is not python'), so I won't touch any of this yet. And I agree with Brian that at least our current system is eminently functional, and we can write nice docs with little overhead beyond the writing itself. But if you do want to contribute on any of this (which sooner or later ipython, numpy, scipy, matplotlib, proably sympy, etc will want), I think that a solution that integrates with the version control backend naturally would be the easiest. I don't know how you guys implemented it, but I'd think that simply: - producing one wiki page per .rst/.txt in a given directory - generating one local commit into a special branch per user-visible change should be enough, no? Then, the editors can merge/reject those individual commits into the trunk. But if this is too much work, the simple 'wiki as rst editor' approach would suffice initially, as long as the user changes can be applied into the tree with some near-zero-overhead process (beyond reading the actual patch). Still, I wouldn't worry too much about this for now. You guys are using this heavily for numpy/scipy and that's the current focus. Experience gained there will be reused by the other projects later. A good target would be to work on this at the Scipy'08 sprint; will you be there? Cheers, f From vivainio at gmail.com Wed Jun 18 12:25:37 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 18 Jun 2008 19:25:37 +0300 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> Message-ID: <46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com> On Tue, Jun 17, 2008 at 11:27 PM, Yuhui H wrote: > If you want, I can upload my bzr branch somewhere as a zip package. Or > I can push it to launchpad somewhere. Just push it to launchpad somewhere, the problem is basically solved by that. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From eyecat at gmail.com Wed Jun 18 13:33:12 2008 From: eyecat at gmail.com (Yuhui H) Date: Wed, 18 Jun 2008 10:33:12 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> <46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com> Message-ID: On Wed, Jun 18, 2008 at 9:25 AM, Ville M. Vainio wrote: > Just push it to launchpad somewhere, the problem is basically solved by that. > See if this works: lp:~eyecat/pyreadline/svnimport Yuhui From jorgen.stenarson at bostream.nu Wed Jun 18 13:56:38 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 18 Jun 2008 19:56:38 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> Message-ID: <48594C56.9060409@bostream.nu> Yuhui H skrev: > > All I need to do to is: > > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline > Yuhui, thanks for your pointers it worked finally. There were some additional problems caused by the configuration of my machine (my home directory has both spaces and non-ascii characters, I really should change that). Now there is an official launchpad branch for pyreadline!! /J?rgen From cournapeau at cslab.kecl.ntt.co.jp Wed Jun 18 22:18:36 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Thu, 19 Jun 2008 11:18:36 +0900 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <48594C56.9060409@bostream.nu> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> <48594C56.9060409@bostream.nu> Message-ID: <1213841916.29726.3.camel@bbc8> On Wed, 2008-06-18 at 19:56 +0200, J?rgen Stenarson wrote: > Yuhui H skrev: > > > > All I need to do to is: > > > > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline > > For the record, if the need appears again: in my experience, the fastest and most reliable way to import svn into bzr is to use fast-import bzr plugin. It uses the same format as git-export, which means you can use a lot of exporters (git, svn, cvs, hg): svn-export file:///repo | (cd bzr-rep && bzr fast-import - -v) The only drawback is it requires you to have a fast access to the repo, which is trivial if you have the svn dump. But the code is stable, much better than bzr-svn which tries to be too smart IMHO for this kind of tasks (one time import). cheers, David From fperez.net at gmail.com Thu Jun 19 00:08:19 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 18 Jun 2008 21:08:19 -0700 Subject: [IPython-dev] Moving pyreadline to launchpad In-Reply-To: <1213841916.29726.3.camel@bbc8> References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu> <4857FDC6.7050202@bostream.nu> <48581AEC.1070803@bostream.nu> <48594C56.9060409@bostream.nu> <1213841916.29726.3.camel@bbc8> Message-ID: Hey David, On Wed, Jun 18, 2008 at 7:18 PM, David Cournapeau wrote: > On Wed, 2008-06-18 at 19:56 +0200, J?rgen Stenarson wrote: >> Yuhui H skrev: >> > >> > All I need to do to is: >> > >> > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline >> > > > For the record, if the need appears again: in my experience, the fastest > and most reliable way to import svn into bzr is to use fast-import bzr > plugin. It uses the same format as git-export, which means you can use a > lot of exporters (git, svn, cvs, hg): > > svn-export file:///repo | (cd bzr-rep && bzr fast-import - -v) > > The only drawback is it requires you to have a fast access to the repo, > which is trivial if you have the svn dump. But the code is stable, much > better than bzr-svn which tries to be too smart IMHO for this kind of > tasks (one time import). Thanks for the pointer. In this case it seems that bzr-svn ended up working OK for Jorgen's needs, but if anything funky turns up after closer examination, the raw dumps are still up so he could use your tip. Regards, f From vishal.vatsa at gmail.com Fri Jun 20 06:46:45 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Fri, 20 Jun 2008 11:46:45 +0100 Subject: [IPython-dev] async taskclient Message-ID: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com> Hi Guys, I have a question about how to use the async task client. Given the following code: def job_runner(code): def submit(task_client, cmd): t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a']) d = task_client.run(t1) d.addCallback(lambda tid: task_client.get_task_result(taskid=tid, block=True)) d.addBoth(printer) d = asyncclient.get_task_client() d.addCallback(lambda tc: submit(tc, code)) where code is some python code in a string. Is it ok to get a new instance of async task client for every job I want to submit? From hans_meine at gmx.net Fri Jun 20 08:00:35 2008 From: hans_meine at gmx.net (Hans Meine) Date: Fri, 20 Jun 2008 14:00:35 +0200 Subject: [IPython-dev] Moving pyreadline to launchpad Message-ID: <200806201400.35629.hans_meine@gmx.net> Am Donnerstag, 19. Juni 2008 04:18:36 schrieb David Cournapeau: > The only drawback is it requires you to have a fast access to the repo, > which is trivial if you have the svn dump. For the records: I have had success with using svnsync for fast conversion (to mercurial in my case) in order to try out different conversion options. Here's a quick walk-through: FROMREPO="https://spacenav.svn.sourceforge.net/svnroot/spacenav" TOREPO="file://`pwd`/spacenav-sf" svnadmin create spacenav-sf svnsync init "$TOREPO" "$FROMREPO" svnsync --non-interactive sync "$TOREPO" Ciao, / / /--/ / / ANS From ellisonbg.net at gmail.com Fri Jun 20 10:08:12 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 20 Jun 2008 08:08:12 -0600 Subject: [IPython-dev] async taskclient In-Reply-To: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com> References: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com> Message-ID: <6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com> > I have a question about how to use the async task client. > Given the following code: > > def job_runner(code): > > def submit(task_client, cmd): > t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a']) > d = task_client.run(t1) > d.addCallback(lambda tid: > task_client.get_task_result(taskid=tid, block=True)) > d.addBoth(printer) > > d = asyncclient.get_task_client() > d.addCallback(lambda tc: submit(tc, code)) > > > where code is some python code in a string. > > Is it ok to get a new instance of async task client for every > job I want to submit? You can do this but for each new client there will be a new connection to the controller. Thus it is best for performance reasons to use a single TaskClient instance for all of your tasks in a sessions. Is there a reason you want to use a TaskClient for each task? Cheers, Brian From vishal.vatsa at gmail.com Fri Jun 20 10:22:08 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Fri, 20 Jun 2008 15:22:08 +0100 Subject: [IPython-dev] async taskclient In-Reply-To: <6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com> References: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com> <6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com> Message-ID: <7ea8f2ed0806200722v6ff30ad8tfe6264161f319758@mail.gmail.com> 2008/6/20 Brian Granger : >> I have a question about how to use the async task client. >> Given the following code: >> >> def job_runner(code): >> >> def submit(task_client, cmd): >> t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a']) >> d = task_client.run(t1) >> d.addCallback(lambda tid: >> task_client.get_task_result(taskid=tid, block=True)) >> d.addBoth(printer) >> >> d = asyncclient.get_task_client() >> d.addCallback(lambda tc: submit(tc, code)) >> >> >> where code is some python code in a string. >> >> Is it ok to get a new instance of async task client for every >> job I want to submit? > > You can do this but for each new client there will be a new connection > to the controller. Thus it is best for performance reasons to use a > single TaskClient instance for all of your tasks in a sessions. > > Is there a reason you want to use a TaskClient for each task? > > Cheers, > > Brian > I tried to reuse the defered that get_task_client() gets me but I was not sure how to reuse the async task client. Would you have a suggestion on how to go about this? Cheers Vishal From gael.varoquaux at normalesup.org Mon Jun 23 13:11:40 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 23 Jun 2008 19:11:40 +0200 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: References: Message-ID: <20080623171140.GD13966@phare.normalesup.org> On Sun, Jun 15, 2008 at 04:03:31PM -0700, Barry Wark wrote: > At this point, I would appreciate comments on the entire frontend > package before we consider merging ipython-frontend into trunk. OK, some first impression comments: conding standards: * Some lines are longer than 80 characters. I don't like this as I keep all my windows open at 80 characters width, and I don't like lines wrapping. * The function naming convention is not systematic (eg frontendbase.py, line 101, there is a method with a CamelCase name, but right under there is one with underscore-sperated names. CamelCase is reserved for classes. I don't care what twisted, apple modules or wx does, they go against pep 8. On the code side of things, a lot of the methods in cocoa_frontend look like they are not Cocoa-specific. They should be moved in the frontendbase, IMHO. More will probably come, but I wanted to post this right now, less I never do it. Just a stupid question: is their a good reason for not merging this branch with trunk? It will probably get us more people running the code or reviewing it, though I must admit that the fact that the only available frontend is a cocoa one prevents me totally forom trying the code out. Ga?l From ellisonbg.net at gmail.com Mon Jun 23 13:44:27 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 23 Jun 2008 11:44:27 -0600 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <20080623171140.GD13966@phare.normalesup.org> References: <20080623171140.GD13966@phare.normalesup.org> Message-ID: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com> >> At this point, I would appreciate comments on the entire frontend >> package before we consider merging ipython-frontend into trunk. > > OK, some first impression comments: > > conding standards: > > * Some lines are longer than 80 characters. I don't like this as I > keep all my windows open at 80 characters width, and I don't like > lines wrapping. True, when possible, we should stick to 80 chars. > * The function naming convention is not systematic (eg > frontendbase.py, line 101, there is a method with a CamelCase name, > but right under there is one with underscore-sperated names. > CamelCase is reserved for classes. I don't care what twisted, apple > modules or wx does, they go against pep 8. For the most part we do want to follow pep 8 conventions for IPython code. But, there are cases (I don't know if things in the Cocoa frontend fall into this case), like subclassing, where you have to use the conventions established by a third party (twisted or pyobjc in Barry's case). These other projects may go against pep 8, but we do have to live with their conventions if we want to use their software. In that sense, they don't care that we don't care :) > On the code side of things, a lot of the methods in cocoa_frontend look > like they are not Cocoa-specific. They should be moved in the > frontendbase, IMHO. > > More will probably come, but I wanted to post this right now, less I > never do it. > > Just a stupid question: is their a good reason for not merging this > branch with trunk? It will probably get us more people running the code > or reviewing it, though I must admit that the fact that the only > available frontend is a cocoa one prevents me totally forom trying the > code out. The plan is to do a merge very soon. Barry is just doing good development by 1) doing his work in a branch and 2) asking for code review before merging. Kudos for that! Brian > Ga?l > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From gael.varoquaux at normalesup.org Mon Jun 23 13:56:57 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 23 Jun 2008 19:56:57 +0200 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com> References: <20080623171140.GD13966@phare.normalesup.org> <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com> Message-ID: <20080623175657.GE13966@phare.normalesup.org> On Mon, Jun 23, 2008 at 11:44:27AM -0600, Brian Granger wrote: > For the most part we do want to follow pep 8 conventions for IPython > code. But, there are cases (I don't know if things in the Cocoa > frontend fall into this case), like subclassing, where you have to use > the conventions established by a third party (twisted or pyobjc in > Barry's case). These other projects may go against pep 8, but we do > have to live with their conventions if we want to use their software. > In that sense, they don't care that we don't care :) Fare enough, but for generic stuff (like the frontentbase), we should stick to pep 8. I do realise that the cocoa frontend inherits both from the FrontEndBase, and the apple NSObject, but I gather that the interface are separate, and that none of the FrontEndBase method overrides an NSObject lethod. > > Just a stupid question: is their a good reason for not merging this > > branch with trunk? It will probably get us more people running the code > > or reviewing it, though I must admit that the fact that the only > > available frontend is a cocoa one prevents me totally forom trying the > > code out. > The plan is to do a merge very soon. Barry is just doing good > development by 1) doing his work in a branch and 2) asking for code > review before merging. Kudos for that! Yes, this is good. I do think we will want to move forward pretty soon. I think I might want to reuse that code, and it sitting in a different branch might not help. Cheers, Ga?l From gael.varoquaux at normalesup.org Mon Jun 23 14:16:32 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 23 Jun 2008 20:16:32 +0200 Subject: [IPython-dev] Moving forward with the frontends Message-ID: <20080623181632.GF13966@phare.normalesup.org> Hi all, This is just a heads up to say that I have been allowed to devote some of my day work's time to working on a frontend for iPython. We want to integrate IPython in Mayavi and other similar projects. The requirements are: * We want something fast, not after three months of work * We do not want it multithreaded. The reason being that this shell will be used to manipulate existing Wx objects. As Wx is not multithreaded, we cannot execute the code the user enters in a separate thread. As we want to manipulate objects displayed by the GUI, we cannot run in a seperate process. In the long run we can think of a "%bg" like magic to execute in a seperate thread, but on the short term I will make my life easier and run everything in one thread. * We are interested in wx. I am of course happy sharing the code with other frontends, but I will not be developping them. * The feature of ipython we are interested in are magics, "?" and "??", tab completion, history, and alike... I am currently reviewing the existing code. I see three code bases for front end: * Laurent Dufrechou's WxIpython, living in the trunk, in IPython/gui/wx * Barry Wark's cocoa frontend, living in a separate branch; ipython-frontend * The code Fernando, Eric Jones and myself started a year ago, living * in the old ipython1 branch (in ipython1/frontend). >From a first quick review, they all have there stength and their weakness. I am probably going to take from all three. I have not decided where my effort will live. I will keep on review the code, and exploring better the ipython codebase. I am interested in any pointers you have, or advice on how to move forward. I will keep the list posted as things move along. Cheers, Ga?l From fperez.net at gmail.com Mon Jun 23 14:58:52 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 23 Jun 2008 11:58:52 -0700 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: <20080623181632.GF13966@phare.normalesup.org> References: <20080623181632.GF13966@phare.normalesup.org> Message-ID: On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux wrote: > Hi all, > > This is just a heads up to say that I have been allowed to devote some of > my day work's time to working on a frontend for iPython. We want to > integrate IPython in Mayavi and other similar projects. The requirements > are: > > * We want something fast, not after three months of work Great! Real quick (I'll respond to your message in full later): we can make this an IPAM project, in the end I *will* make it there after the SIAM conference, so put it in your schedule for those two weeks after the talks end. IPAM is a great place to work anyways... Timeline for everyone else (the previous paragraph was a bit cryptic): Gael and I will be physically together for 2 weeks at a workshop at UCLA July 14-25, and we'll work on this as time allows around scheduled talks. If Barry, Laurent or anyone else is interested, we could schedule irc/skype sessions occasionally to coordinate the frontend progress during that period (in addition to on-list discussions). Gael will likely also visit with me at Berkeley afterwards, so July/August is a good timeline for this to happen. I'm working on the nose testing stuff right now, we'll likely have to ship our own ipython nose plugin for all our testing to work with nose. I'll try to have that finished in the next day or so, since I want us to have that layer in place as we refactor things. Cheers, f From fperez.net at gmail.com Mon Jun 23 15:19:00 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 23 Jun 2008 12:19:00 -0700 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com> References: <20080623171140.GD13966@phare.normalesup.org> <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com> Message-ID: On Mon, Jun 23, 2008 at 10:44 AM, Brian Granger wrote: >>> At this point, I would appreciate comments on the entire frontend >>> package before we consider merging ipython-frontend into trunk. >> >> OK, some first impression comments: >> >> conding standards: >> >> * Some lines are longer than 80 characters. I don't like this as I >> keep all my windows open at 80 characters width, and I don't like >> lines wrapping. > > True, when possible, we should stick to 80 chars. Again, just follow PEP-8 (http://www.python.org/dev/peps/pep-0008/) """ Maximum Line Length Limit all lines to a maximum of 79 characters.""" The default python mode for emacs does this, as I imagine do the python modes for other editors if they've been written to be pep-8 conformant. Unless there's a very good reason not to, we stick to pep-8 for everything. The case of subclassing existing interfaces is an obvious case where we have to do whatever the parent class does and not what pep8/we want. Cheers, f From barrywark at gmail.com Mon Jun 23 15:40:08 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 23 Jun 2008 12:40:08 -0700 Subject: [IPython-dev] IPython.fronend progress In-Reply-To: <20080623171140.GD13966@phare.normalesup.org> References: <20080623171140.GD13966@phare.normalesup.org> Message-ID: On Mon, Jun 23, 2008 at 10:11 AM, Gael Varoquaux wrote: > On Sun, Jun 15, 2008 at 04:03:31PM -0700, Barry Wark wrote: >> At this point, I would appreciate comments on the entire frontend >> package before we consider merging ipython-frontend into trunk. > > OK, some first impression comments: > > conding standards: > > * Some lines are longer than 80 characters. I don't like this as I > keep all my windows open at 80 characters width, and I don't like > lines wrapping. Quite right. Sorry. That will definitely be fixed. > > * The function naming convention is not systematic (eg > frontendbase.py, line 101, there is a method with a CamelCase name, > but right under there is one with underscore-sperated names. > CamelCase is reserved for classes. I don't care what twisted, apple > modules or wx does, they go against pep 8. I thought I had cleaned up everything that didn't override Twisted or Cocoa methods to be PEP 8 compliant. I will double check that again. > > On the code side of things, a lot of the methods in cocoa_frontend look > like they are not Cocoa-specific. They should be moved in the > frontendbase, IMHO. Good point. I will have an other look at that separation. Some things ended up in the cocoa-specific frontend because they are specific to how the cocoa frontend renders its UI -- a notebook based frontend would be very different. In fact, the cocoa frontend is more a test fixture at this point. Ultimately I would like to move it towards a notebook-like interface. I will see whether there's anything in there that is generall applicable to ALL frontend UIs, but I suspect there isn't. > > More will probably come, but I wanted to post this right now, less I > never do it. > > Just a stupid question: is their a good reason for not merging this > branch with trunk? It will probably get us more people running the code > or reviewing it, though I must admit that the fact that the only > available frontend is a cocoa one prevents me totally forom trying the > code out. My intention was to merge as soon as some other eyes had taken a look at, and OK'd, the code. It sounds like resolving the issues you raise here will get me to being ready to merge. I will announce on the list as soon as the merge to trunk is complete. Thanks for your comments! Barry > > Ga?l > > From barrywark at gmail.com Mon Jun 23 16:26:18 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 23 Jun 2008 13:26:18 -0700 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: <20080623181632.GF13966@phare.normalesup.org> References: <20080623181632.GF13966@phare.normalesup.org> Message-ID: On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux wrote: > Hi all, > > This is just a heads up to say that I have been allowed to devote some of > my day work's time to working on a frontend for iPython. We want to > integrate IPython in Mayavi and other similar projects. The requirements > are: > > * We want something fast, not after three months of work > > * We do not want it multithreaded. The reason being that this shell will > be used to manipulate existing Wx objects. As Wx is not multithreaded, > we cannot execute the code the user enters in a separate thread. As we > want to manipulate objects displayed by the GUI, we cannot run in a > seperate process. In the long run we can think of a "%bg" like magic > to execute in a seperate thread, but on the short term I will make my > life easier and run everything in one thread. I don't want to sound like a broken record and I don't have personal pride staked on this solution so it's OK if you choose otherwise, but I think going with a Twisted-based approach is the right plan. I would look forward to working with you to make FrontEndBase work for your use. There's a WX reactor for Twisted so we can guarantee that code gets executed in the WX runloop thread. Using Twisted's deferToThread (eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it possible for long-running code to not block the UI. > > * We are interested in wx. I am of course happy sharing the code with > other frontends, but I will not be developping them. > > * The feature of ipython we are interested in are magics, "?" and "??", > tab completion, history, and alike... As soon as we can refactor the IPython 0.8 core so that it plays nicely with the IPython.kernel.engineservice.IEngineBase interface, all frontends could get this behavior for free. If you can't wait for that refactoring, going with the existing Wx frontend is your only option at this point. > > I am currently reviewing the existing code. I see three code bases for > front end: > > * Laurent Dufrechou's WxIpython, living in the trunk, in > IPython/gui/wx Like I said above, this is the only option if you can't wait for the refactoring of the current core to work with I.k.e.IEngineBase [1] > > * Barry Wark's cocoa frontend, living in a separate branch; > ipython-frontend As we discussed in a separate thread, this will hoepfully be merged into trunk soon. > > * The code Fernando, Eric Jones and myself started a year ago, living > * in the old ipython1 branch (in ipython1/frontend). The frontend that I will merge into trunk does not include your original code. I would like to revisit whether your line-oriented approach could be incorporated into a FrontEndBase subclass specifiically for line-oriented frontends. > > >From a first quick review, they all have there stength and their > weakness. I am probably going to take from all three. I have not decided > where my effort will live. > > I will keep on review the code, and exploring better the ipython > codebase. I am interested in any pointers you have, or advice on how to > move forward. I will keep the list posted as things move along. > > Cheers, > > Ga?l > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From barrywark at gmail.com Mon Jun 23 16:28:40 2008 From: barrywark at gmail.com (Barry Wark) Date: Mon, 23 Jun 2008 13:28:40 -0700 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: References: <20080623181632.GF13966@phare.normalesup.org> Message-ID: 8 AM, Fernando Perez wrote: > On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux > wrote: >> Hi all, >> >> This is just a heads up to say that I have been allowed to devote some of >> my day work's time to working on a frontend for iPython. We want to >> integrate IPython in Mayavi and other similar projects. The requirements >> are: >> >> * We want something fast, not after three months of work > > Great! Real quick (I'll respond to your message in full later): we > can make this an IPAM project, in the end I *will* make it there after > the SIAM conference, so put it in your schedule for those two weeks > after the talks end. IPAM is a great place to work anyways... > > Timeline for everyone else (the previous paragraph was a bit cryptic): > Gael and I will be physically together for 2 weeks at a workshop at > UCLA July 14-25, and we'll work on this as time allows around > scheduled talks. If Barry, Laurent or anyone else is interested, we > could schedule irc/skype sessions occasionally to coordinate the > frontend progress during that period (in addition to on-list > discussions). Gael will likely also visit with me at Berkeley > afterwards, so July/August is a good timeline for this to happen. I am stuck in Seattle, then Woods Hole, MA over this period but would be happy to irc/skype as the need arises. Hopefully Gael and I can touch base some time late this week and come to a united front on the frontend tactics. [1] Is it acceptable to abreviate IPython.kernel.engineservice.[blah] as I.k.e.blah as the Twisted folks do? Since we now have a somewhat deep namespace, it's getting a tiny bit tiresome to write it all out every time...? > > I'm working on the nose testing stuff right now, we'll likely have to > ship our own ipython nose plugin for all our testing to work with > nose. I'll try to have that finished in the next day or so, since I > want us to have that layer in place as we refactor things. > > 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 Mon Jun 23 16:36:36 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 23 Jun 2008 22:36:36 +0200 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: References: <20080623181632.GF13966@phare.normalesup.org> Message-ID: <20080623203636.GL13966@phare.normalesup.org> On Mon, Jun 23, 2008 at 01:26:18PM -0700, Barry Wark wrote: > > * We do not want it multithreaded. The reason being that this shell will > > be used to manipulate existing Wx objects. As Wx is not multithreaded, > > we cannot execute the code the user enters in a separate thread. As we > > want to manipulate objects displayed by the GUI, we cannot run in a > > seperate process. In the long run we can think of a "%bg" like magic > > to execute in a seperate thread, but on the short term I will make my > > life easier and run everything in one thread. > I don't want to sound like a broken record and I don't have personal > pride staked on this solution so it's OK if you choose otherwise, but > I think going with a Twisted-based approach is the right plan. I would > look forward to working with you to make FrontEndBase work for your > use. There's a WX reactor for Twisted so we can guarantee that code > gets executed in the WX runloop thread. Using Twisted's deferToThread > (eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it > possible for long-running code to not block the UI. OK, I am not sure I understand fully this approach. The name made me think there were threads involved, and thus it wouldn't work in the context of Wx. I guess I need to do some googling/reading to find out more about the reactors. > > * The feature of ipython we are interested in are magics, "?" and "??", > > tab completion, history, and alike... > As soon as we can refactor the IPython 0.8 core so that it plays > nicely with the IPython.kernel.engineservice.IEngineBase interface, > all frontends could get this behavior for free. If you can't wait for > that refactoring, going with the existing Wx frontend is your only > option at this point. Fernando, Brian, Ville, what is the timeframe for this? What is the amount of work required? Ga?l From fperez.net at gmail.com Mon Jun 23 21:10:07 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 23 Jun 2008 18:10:07 -0700 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: <20080623203636.GL13966@phare.normalesup.org> References: <20080623181632.GF13966@phare.normalesup.org> <20080623203636.GL13966@phare.normalesup.org> Message-ID: Hey, On Mon, Jun 23, 2008 at 1:36 PM, Gael Varoquaux wrote: > On Mon, Jun 23, 2008 at 01:26:18PM -0700, Barry Wark wrote: > >> > * The feature of ipython we are interested in are magics, "?" and "??", >> > tab completion, history, and alike... > >> As soon as we can refactor the IPython 0.8 core so that it plays >> nicely with the IPython.kernel.engineservice.IEngineBase interface, >> all frontends could get this behavior for free. If you can't wait for >> that refactoring, going with the existing Wx frontend is your only >> option at this point. > > Fernando, Brian, Ville, what is the timeframe for this? What is the > amount of work required? The way I see things right now, this can be done gradually. Min, Brian and I just spent several hours today working on the foolscap/security integration for the daemon work to be merged in the next couple of weeks. I'm also working on the testing code, writing a custom Nose plugin to suit all our (rather complicated) testing needs. Those two features are what I see as being next in line for our 0.9 release. Brian and I will meet at a conference July 7-11, so that would be a good time to make the release, and it looks like both Min and I can finish what we're doing for that time. In the meantime, you can consider the WX integration work, in conjunction with Barry, as being precisely the beginning of this refactoring. I don't want to draw us again into the 'once the *huge* refactoring is done, we can do X' mindset, because that's precisely what was paralyzing us with ipython0/1. Instead, try to find a light way of using the existing bits of Wx code (which you've already identified) and work with Barry on the Twisted ideas. Envisage already has a million nasty dependencies, so I don't see Twisted being a problem there. The way I hope we'll be able to build this whole thing will be: 1. A NON-Twisted using terminal frontend like today, that is fully blocking (no deferreds since there's no twisted). But it uses the same interfaces the Twisted ones will use. 2. We keep the threading hacks we have today to provide terminal-based acccess to GUIs (the -Xthread options). Note that this is NOT meant to be the way to develop full GUI clients that use ipython, simply a way to use the terminal to run GUI code like many people do today. It's not perfect but it's lightweight and useful, and I see no need to get rid of it. 3. For building full-blown GUI clients, we use the Twisted reactors that know how to integrate with the various toolkits in existence, including Cocoa. With that as a long-term view, I'd suggest you hack away incrementally so that you can build something that mimics what Barry is doing. If not all the pieces are fully elegantly refactored yet, big deal. As long as you have something that works, we can incrementally fix it up. Don't let the idea of a 'big refactor' hold back the work you and Barry can do *now*. Note: I'll be at a conference Wed-Saturday, mostly offline. Cheers, f From gael.varoquaux at normalesup.org Tue Jun 24 00:11:39 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 24 Jun 2008 06:11:39 +0200 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: References: <20080623181632.GF13966@phare.normalesup.org> <20080623203636.GL13966@phare.normalesup.org> Message-ID: <20080624041138.GA2269@phare.normalesup.org> On Mon, Jun 23, 2008 at 06:10:07PM -0700, Fernando Perez wrote: > >> As soon as we can refactor the IPython 0.8 core so that it plays > >> nicely with the IPython.kernel.engineservice.IEngineBase interface, > >> all frontends could get this behavior for free. If you can't wait for > >> that refactoring, going with the existing Wx frontend is your only > >> option at this point. > > Fernando, Brian, Ville, what is the timeframe for this? What is the > > amount of work required? > The way I see things right now, this can be done gradually. Cool. I think that is indeed the way to go. > In the meantime, you can consider the WX integration work, in > conjunction with Barry, as being precisely the beginning of this > refactoring. I don't want to draw us again into the 'once the *huge* > refactoring is done, we can do X' mindset, I have started working on that today. Currently what I am doing is not Ipython specific (though I hope it will go in the ipython repository), it can be adapted to ipython0 or to ipython1. Hopefully the work on ipython0/ipython1 will move fast-enough so that I will be able to use that, rather than pushing string to an ipython0 terminal. > Envisage already has a million nasty dependencies, so I don't see > Twisted being a problem there. As long as it brings us something. I have read a bit about the twisted reactor, and I must admit I haven't understood how it will allow us to run arbitrary code without blocking the gui loop, but in a thread-safe way with Wx. I am probably just being heavy. Anyway, I think in the long run we will want twisted integrated in all this. I am just saying I have the feeling this is outside the current scope of my work. Though, if I have understood well, switching from an engine abstracted through twisted to one running in the same thread as the calls should be simply a matter of replacing an instance by another, right? > The way I hope we'll be able to build this whole thing will be: > 1. A NON-Twisted using terminal frontend like today, that is fully > blocking (no deferreds since there's no twisted). But it uses the > same interfaces the Twisted ones will use. I see it slightly differently. I think it is the engine who should come in different flavors, exposing the same interface. Line 39 of http://bazaar.launchpad.net/~barrywark/ipython/ipython-frontend/annotate/barrywark%40gmail.com-20080616054258-7jjo8w1tt7sc1zfg?file_id=cocoa_frontend.py-20080611225339-bjp8mnnd2tnxj9n5-8 makes me believe this might already be the case, but I still haven't wrapped my head around the code, and I can't execute it, as it is Mac only. > 2. We keep the threading hacks we have today to provide terminal-based > acccess to GUIs (the -Xthread options). Note that this is NOT meant > to be the way to develop full GUI clients that use ipython, simply a > way to use the terminal to run GUI code like many people do today. > It's not perfect but it's lightweight and useful, and I see no need to > get rid of it. Sure, I agree the are useful. I can't however worry about them right now. > 3. For building full-blown GUI clients, we use the Twisted reactors > that know how to integrate with the various toolkits in existence, > including Cocoa. Will this allow me to execute arbitrary wx commands without killing the application? Can somebody point me to a document hinting how to do this. I am kind of lost here because I don't really understand how the reactors works. Anyhow, hopefully this can also be hidden in an object presenting the same interface as an EngineService. I think we are on the same wavelength. I am going to focus on trying to get something done, clean and hopefully extendable, but maybe with a reduce feature-set. This can be the basis of future work. Ga?l From vivainio at gmail.com Tue Jun 24 02:03:40 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 24 Jun 2008 09:03:40 +0300 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: <20080623181632.GF13966@phare.normalesup.org> References: <20080623181632.GF13966@phare.normalesup.org> Message-ID: <46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com> On Mon, Jun 23, 2008 at 9:16 PM, Gael Varoquaux wrote: > integrate IPython in Mayavi and other similar projects. The requirements > are: > > * We want something fast, not after three months of work > * We are interested in wx. I am of course happy sharing the code with > other frontends, but I will not be developping them. > * The feature of ipython we are interested in are magics, "?" and "??", > tab completion, history, and alike... > I am currently reviewing the existing code. I see three code bases for > front end: > > * Laurent Dufrechou's WxIpython, living in the trunk, in > IPython/gui/wx I think this is the winner here, given the preconditions above. It seems it would be pretty easy to integrate. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From barrywark at gmail.com Tue Jun 24 03:09:37 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 00:09:37 -0700 Subject: [IPython-dev] ipython-frontend branch merged to trunk Message-ID: After cleaning up the code in ipython-frontend to be fully pep 8 compliant (except when overriding non-PEP 8 compliant methods from Cocoa or Twisted), I've merged the ipython-frontend branch into trunk and marked the ipython-frontend branch as "merged" on launchpad. I expect all further work on the IPython.frontend package to happen from trunk. I'll try to work up a tutorial on writing a frontend in the next few days. In the mean time, happy hacking. Cheers, Barry From stefan at sun.ac.za Tue Jun 24 05:50:28 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 24 Jun 2008 11:50:28 +0200 Subject: [IPython-dev] Questin regarding pager Message-ID: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> Hi all, Doing TAB-completion makes use of the readline pager, which isn't All That Great. With pyreadline available, is there an easy way to default to a more advanced completion pager? Regards St?fan From gael.varoquaux at normalesup.org Tue Jun 24 08:56:45 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 24 Jun 2008 14:56:45 +0200 Subject: [IPython-dev] ipython-frontend branch merged to trunk In-Reply-To: References: Message-ID: <20080624125645.GA27589@phare.normalesup.org> Thanks for all the work, Barry, and thank you for being receptive to comments. Ga?l On Tue, Jun 24, 2008 at 12:09:37AM -0700, Barry Wark wrote: > After cleaning up the code in ipython-frontend to be fully pep 8 > compliant (except when overriding non-PEP 8 compliant methods from > Cocoa or Twisted), I've merged the ipython-frontend branch into trunk > and marked the ipython-frontend branch as "merged" on launchpad. I > expect all further work on the IPython.frontend package to happen from > trunk. I'll try to work up a tutorial on writing a frontend in the > next few days. In the mean time, happy hacking. From ellisonbg.net at gmail.com Tue Jun 24 11:40:34 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 24 Jun 2008 09:40:34 -0600 Subject: [IPython-dev] ipython-frontend branch merged to trunk In-Reply-To: References: Message-ID: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> Barry, I don't have time to look at this yet, but thanks for the great work! In addition to having basic Cocoa frontend (which I most definitely want as an OS X user) we also have a great start on the more general frontend work because of your efforts. Thanks! Brian On Tue, Jun 24, 2008 at 1:09 AM, Barry Wark wrote: > After cleaning up the code in ipython-frontend to be fully pep 8 > compliant (except when overriding non-PEP 8 compliant methods from > Cocoa or Twisted), I've merged the ipython-frontend branch into trunk > and marked the ipython-frontend branch as "merged" on launchpad. I > expect all further work on the IPython.frontend package to happen from > trunk. I'll try to work up a tutorial on writing a frontend in the > next few days. In the mean time, happy hacking. > > Cheers, > Barry > _______________________________________________ > 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 Jun 24 12:59:48 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 24 Jun 2008 09:59:48 -0700 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017: Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.ker... In-Reply-To: <4425715799121846470@unknownmsgid> References: <4425715799121846470@unknownmsgid> Message-ID: Wow Barry, huge commit :) On Tue, Jun 24, 2008 at 12:06 AM, wrote: > ------------------------------------------------------------ > revno: 1017 > committer: Barry Wark > branch nick: ipython > timestamp: Tue 2008-06-24 00:02:30 -0700 > message: > Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.kernel.engineservice.ThreadedEngineService and associated tests. > added: > IPython/frontend/cocoa/examples/.DS_Store > IPython/frontend/cocoa/examples/IPython1Sandbox/ > IPython/frontend/cocoa/examples/IPython1Sandbox/.DS_Store Please don't commit those .DS_Store files. As a general rule, before making a large commit, open it in your editor/GUI of choice and check carefully every file you're about to commit. Perhaps adding a proper .bzrignore is what we need right now. Volunteer? > IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/ > IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/InfoPlist.strings > IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/MainMenu.xib I assume these others are indeed needed for your Cocoa work, but given the omission above, I'd appreciate if you double-checked the entire log of added files and made sure nothing else made it in that shouldn't have. Thanks, f From fperez.net at gmail.com Tue Jun 24 13:01:20 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 24 Jun 2008 10:01:20 -0700 Subject: [IPython-dev] Questin regarding pager In-Reply-To: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> Message-ID: On Tue, Jun 24, 2008 at 2:50 AM, St?fan van der Walt wrote: > Hi all, > > Doing TAB-completion makes use of the readline pager, which isn't All > That Great. With pyreadline available, is there an easy way to > default to a more advanced completion pager? Ville recently added an option to *disable* the pager altogether, but I don't know if one can hook a different pager into readline. When ipython pages, it honors the $PAGER variable, but I have no idea if readline does as well. Have you tried setting $PAGER to what you want to use? Cheers, f From fperez.net at gmail.com Tue Jun 24 13:02:31 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 24 Jun 2008 10:02:31 -0700 Subject: [IPython-dev] ipython-frontend branch merged to trunk In-Reply-To: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> References: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> Message-ID: On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger wrote: > Barry, > > I don't have time to look at this yet, but thanks for the great work! > In addition to having basic Cocoa frontend (which I most definitely > want as an OS X user) we also have a great start on the more general > frontend work because of your efforts. Seconded from here. Other than the minor .DS_Store commit mixup which is easy to fix, many many thanks both for this work, and for being active/interested in the design discussion! Glad to have you on board :) Cheers, f From gael.varoquaux at normalesup.org Tue Jun 24 14:03:33 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 24 Jun 2008 20:03:33 +0200 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017: Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.ker... In-Reply-To: References: <4425715799121846470@unknownmsgid> Message-ID: <20080624180333.GA935@phare.normalesup.org> On Tue, Jun 24, 2008 at 09:59:48AM -0700, Fernando Perez wrote: > As a general rule, before making a large commit, open it in your > editor/GUI of choice and check carefully every file you're about to > commit. Meld is a fantastic tool for reviewing local changes before commiting. Ga?l From vivainio at gmail.com Tue Jun 24 14:15:49 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 24 Jun 2008 21:15:49 +0300 Subject: [IPython-dev] Questin regarding pager In-Reply-To: References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> Message-ID: <46cb515a0806241115w4dc5a92bwd2ef73e517179bc5@mail.gmail.com> On Tue, Jun 24, 2008 at 8:01 PM, Fernando Perez wrote: > Ville recently added an option to *disable* the pager altogether, but > I don't know if one can hook a different pager into readline. When I don't really see the point in pager at all, since you can page up / page down in terminal window anyway... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From jorgen.stenarson at bostream.nu Tue Jun 24 15:28:58 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 24 Jun 2008 21:28:58 +0200 Subject: [IPython-dev] Questin regarding pager In-Reply-To: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com> Message-ID: <48614AFA.2050703@bostream.nu> St?fan van der Walt skrev: > Hi all, > > Doing TAB-completion makes use of the readline pager, which isn't All > That Great. With pyreadline available, is there an easy way to > default to a more advanced completion pager? > > Regards > St?fan St?fan, in pyreadline there is currently no way to easily choose a more advanced pager. However if you feel like working on a patch the relevant method is _display_completions in pyreadline.modes.basemode /J?rgen ps. the official repository for pyreadline is now on launchpad From barrywark at gmail.com Tue Jun 24 15:41:25 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 12:41:25 -0700 Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017: Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.ker... In-Reply-To: References: <4425715799121846470@unknownmsgid> Message-ID: On Tue, Jun 24, 2008 at 9:59 AM, Fernando Perez wrote: > Wow Barry, > > huge commit :) > > On Tue, Jun 24, 2008 at 12:06 AM, wrote: >> ------------------------------------------------------------ >> revno: 1017 >> committer: Barry Wark >> branch nick: ipython >> timestamp: Tue 2008-06-24 00:02:30 -0700 >> message: >> Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.kernel.engineservice.ThreadedEngineService and associated tests. >> added: > >> IPython/frontend/cocoa/examples/.DS_Store >> IPython/frontend/cocoa/examples/IPython1Sandbox/ >> IPython/frontend/cocoa/examples/IPython1Sandbox/.DS_Store > > Please don't commit those .DS_Store files. Oops. Those ones slipped by. I'll remove them. > > As a general rule, before making a large commit, open it in your > editor/GUI of choice and check carefully every file you're about to > commit. Perhaps adding a proper .bzrignore is what we need right now. > Volunteer? > >> IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/ >> IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/InfoPlist.strings >> IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/MainMenu.xib > > I assume these others are indeed needed for your Cocoa work, but given > the omission above, I'd appreciate if you double-checked the entire > log of added files and made sure nothing else made it in that > shouldn't have. Yes, these are all for the Cocoa frontend example. > > Thanks, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From jorgen.stenarson at bostream.nu Tue Jun 24 15:42:05 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 24 Jun 2008 21:42:05 +0200 Subject: [IPython-dev] pyreadline refactoring Message-ID: <48614E0D.30901@bostream.nu> Hi, I have started to work on a refactoring of pyreadline with the goal to untangle the class interactions that have made it difficult to reuse pyreadline in other circumstances than a shell on win32. The basic idea is that it should be possible to call a readline object with keypress events containing (control, shift, meta, char, keyname) where keyname is for special keys like space, f1, return etc. The readline object would be responsible for keeping track of current prompt, line_buffer, cursor_position and selection_position. But the caller of the object will have to render the buffer. I have also merged the callback branch I worked on a few months back. The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor If anyone has any ideas or suggestions on how things should work please let me know. /J?rgen From barrywark at gmail.com Tue Jun 24 17:54:27 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 14:54:27 -0700 Subject: [IPython-dev] ipython-frontend branch merged to trunk In-Reply-To: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> References: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> Message-ID: On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger wrote: > Barry, > > I don't have time to look at this yet, but thanks for the great work! > In addition to having basic Cocoa frontend (which I most definitely > want as an OS X user) we also have a great start on the more general > frontend work because of your efforts. > > Thanks! > > Brian Brian, No worries... as a mac user, I have a bit of interest in a good frontend too ;) I'm just having fun. cheers, Barry > > On Tue, Jun 24, 2008 at 1:09 AM, Barry Wark wrote: >> After cleaning up the code in ipython-frontend to be fully pep 8 >> compliant (except when overriding non-PEP 8 compliant methods from >> Cocoa or Twisted), I've merged the ipython-frontend branch into trunk >> and marked the ipython-frontend branch as "merged" on launchpad. I >> expect all further work on the IPython.frontend package to happen from >> trunk. I'll try to work up a tutorial on writing a frontend in the >> next few days. In the mean time, happy hacking. >> >> Cheers, >> Barry >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > From barrywark at gmail.com Tue Jun 24 17:57:33 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 14:57:33 -0700 Subject: [IPython-dev] ipython-frontend branch merged to trunk In-Reply-To: References: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com> Message-ID: On Tue, Jun 24, 2008 at 10:02 AM, Fernando Perez wrote: > On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger wrote: >> Barry, >> >> I don't have time to look at this yet, but thanks for the great work! >> In addition to having basic Cocoa frontend (which I most definitely >> want as an OS X user) we also have a great start on the more general >> frontend work because of your efforts. > > Seconded from here. Other than the minor .DS_Store commit mixup which > is easy to fix, many many thanks both for this work, and for being > active/interested in the design discussion! Glad to have you on board > :) Happy to be aboard. This is a very exciting time and I really appreciate how welcoming you all have been! Barry > > Cheers, > > f > From barrywark at gmail.com Tue Jun 24 17:58:20 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 14:58:20 -0700 Subject: [IPython-dev] Bazaar on OS X Message-ID: Just a side note on the VCS side of things... Bazaar appears to have a bunch of problems on OS X with directories that are reached via AFP (Apple's file sharing protocol). I've filed a bug with the bazaar folks, but as we start to push towards having a more full featured Cocoa frontend for ipython, it's worth remembering that some potential developers on OS X will have trouble using bazaar. I'll keep the list posted on progress resolving this issue. Barry From fperez.net at gmail.com Tue Jun 24 18:13:29 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 24 Jun 2008 15:13:29 -0700 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: References: Message-ID: On Tue, Jun 24, 2008 at 2:58 PM, Barry Wark wrote: > Just a side note on the VCS side of things... > > Bazaar appears to have a bunch of problems on OS X with directories > that are reached via AFP (Apple's file sharing protocol). I've filed a > bug with the bazaar folks, but as we start to push towards having a > more full featured Cocoa frontend for ipython, it's worth remembering > that some potential developers on OS X will have trouble using bazaar. > I'll keep the list posted on progress resolving this issue. Bummer! Please keep us posted. I have to say that I've given up on the whole 'history folding' problem, so I'm not 100% happy with bzr/lp either. Basically if you have truly diverged lines of work where you did work and committed locally while other devs pushed, a merge is inevitable (even if you keep several branches and push only from one that you don't develop in). And at that point, bzr does the whole 'dropped revisions' dance and folds history. But on the whole we do gain from the ability to flexibly merge (even with ugly history) and the support for contributors from launchpad is vastly better than manually managing accounts on scipy.org and playing admin-by-night, so it's a net gain. Just not a perfect one :) But definitely keep us posted on the nature of the OSX issues. Cheers, f From barrywark at gmail.com Tue Jun 24 18:25:30 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 15:25:30 -0700 Subject: [IPython-dev] Bug? in cocoa_frontend In-Reply-To: <20080624221156.GC26559@phare.normalesup.org> References: <20080624220401.GB26559@phare.normalesup.org> <20080624221156.GC26559@phare.normalesup.org> Message-ID: On Tue, Jun 24, 2008 at 3:11 PM, Gael Varoquaux wrote: > On Tue, Jun 24, 2008 at 03:08:58PM -0700, Barry Wark wrote: >> No, you're absolutely right. It should be >> currentIndent = len(lines[-1]) - len(lines[-1].lstrip()) > > OK, now I understand what it is supposed to do. Thanks (PS; code review > rocks !). I agree. That's why I wanted a review ;) I'm cc'ing this to ipython-dev to propose that we set up a code review tool for IPython. GvR's rietveld (http://code.google.com/appengine/articles/rietveld.html) seems like an option, as does http://review-board.org/. I don't think either tool works natively with bzr, but it might be worth looking into... I know we're not looking for a rigid code-review process, but an easy code review tool couldn't hurt... just a thought. Barry > > Ga?l > From barrywark at gmail.com Tue Jun 24 18:36:43 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 15:36:43 -0700 Subject: [IPython-dev] pyreadline refactoring In-Reply-To: <48614E0D.30901@bostream.nu> References: <48614E0D.30901@bostream.nu> Message-ID: On Tue, Jun 24, 2008 at 12:42 PM, J?rgen Stenarson wrote: > Hi, > > I have started to work on a refactoring of pyreadline with the goal to > untangle the class interactions that have made it difficult to reuse > pyreadline in other circumstances than a shell on win32. > > The basic idea is that it should be possible to call a readline object > with keypress events containing (control, shift, meta, char, keyname) > where keyname is for special keys like space, f1, return etc. > > The readline object would be responsible for keeping track of current > prompt, line_buffer, cursor_position and selection_position. But the > caller of the object will have to render the buffer. > > I have also merged the callback branch I worked on a few months back. > The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor > > If anyone has any ideas or suggestions on how things should work please > let me know. J?rgen, Wow, this is an exciting move in view of the plans to separate ipython0's core from the terminal/readline. I am still learning about pyreadline, but your description above makes me think that you, me, and Ga?l should think about using the new (refactored) pyreadline in developing a base class for front ends that are based on a line-oriented interface (i.e. mimicking the terminal interface). Barry > > /J?rgen > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Tue Jun 24 18:41:50 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 24 Jun 2008 16:41:50 -0600 Subject: [IPython-dev] Bug? in cocoa_frontend In-Reply-To: References: <20080624220401.GB26559@phare.normalesup.org> <20080624221156.GC26559@phare.normalesup.org> Message-ID: <6ce0ac130806241541u13d9b63dw32cfe10ea4261c69@mail.gmail.com> We have actually talked about establishing a slightly formal code review policy. I too like the idea. While I think rietveld looks very nice, launchpad recently add some features that basically let you do code review on launchpad. I have tried this out (OK, I just "reviewed" my own branch) and it worked rather well and is very well integrated with everything else we are doing with launchpad/bzr. I encourage others to have a look at these launchpad capabilities and see if they think they would help us. If I remember correctly, if you click on a branches "propose for merging" link, you can 1) provide comments about the branch and 2) vote in merging. Simple, but probably enough for what we need. Cheers, Brian On Tue, Jun 24, 2008 at 4:25 PM, Barry Wark wrote: > On Tue, Jun 24, 2008 at 3:11 PM, Gael Varoquaux > wrote: >> On Tue, Jun 24, 2008 at 03:08:58PM -0700, Barry Wark wrote: >>> No, you're absolutely right. It should be >>> currentIndent = len(lines[-1]) - len(lines[-1].lstrip()) >> >> OK, now I understand what it is supposed to do. Thanks (PS; code review >> rocks !). > > I agree. That's why I wanted a review ;) I'm cc'ing this to > ipython-dev to propose that we set up a code review tool for IPython. > GvR's rietveld (http://code.google.com/appengine/articles/rietveld.html) > seems like an option, as does http://review-board.org/. I don't think > either tool works natively with bzr, but it might be worth looking > into... > > I know we're not looking for a rigid code-review process, but an easy > code review tool couldn't hurt... just a thought. > > Barry > > >> >> Ga?l >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Tue Jun 24 18:47:08 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 24 Jun 2008 16:47:08 -0600 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: References: Message-ID: <6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com> > Bummer! Please keep us posted. > > I have to say that I've given up on the whole 'history folding' > problem, so I'm not 100% happy with bzr/lp either. Basically if you > have truly diverged lines of work where you did work and committed > locally while other devs pushed, a merge is inevitable (even if you > keep several branches and push only from one that you don't develop > in). And at that point, bzr does the whole 'dropped revisions' dance > and folds history. > But on the whole we do gain from the ability to flexibly merge (even > with ugly history) and the support for contributors from launchpad is > vastly better than manually managing accounts on scipy.org and playing > admin-by-night, so it's a net gain. Just not a perfect one :) Definitely not perfect, but I do agree that it is a net gain from before. I would characterize this in the "Just Works" category, but with a "Not always quite the way you want it to" clause. Judging from past experience (CVS-> SVN->bzr) these decisions are likely not final for all eternity. Cheers, Brian > But definitely keep us posted on the nature of the OSX issues. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From stefan at sun.ac.za Tue Jun 24 18:56:50 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 25 Jun 2008 00:56:50 +0200 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: References: Message-ID: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> 2008/6/25 Fernando Perez : > On Tue, Jun 24, 2008 at 2:58 PM, Barry Wark wrote: >> Just a side note on the VCS side of things... >> >> Bazaar appears to have a bunch of problems on OS X with directories >> that are reached via AFP (Apple's file sharing protocol). I've filed a >> bug with the bazaar folks, but as we start to push towards having a >> more full featured Cocoa frontend for ipython, it's worth remembering >> that some potential developers on OS X will have trouble using bazaar. >> I'll keep the list posted on progress resolving this issue. What kind of trouble? I haven't come across any, but it would be good to know what to watch out for. > I have to say that I've given up on the whole 'history folding' > problem, so I'm not 100% happy with bzr/lp either. Basically if you > have truly diverged lines of work where you did work and committed > locally while other devs pushed, a merge is inevitable (even if you > keep several branches and push only from one that you don't develop > in). And at that point, bzr does the whole 'dropped revisions' dance > and folds history. When branches diverge, a merge is necessary. Some revision control systems hide the merges, others (like bzr) don't. How does mercurial handle the issue? Maybe I'm missing the whole point (feel free to tell me so): why is it such a problem that there is extra information in the log? Do any of the log formats alleviate the problem? Or is it mainly the issue that launchpad has such a sucky log display? Sorry if these are stupid questions, but I'd like to get to the bottom of the whole thing. Cheers! St?fan From barrywark at gmail.com Tue Jun 24 19:03:46 2008 From: barrywark at gmail.com (Barry Wark) Date: Tue, 24 Jun 2008 16:03:46 -0700 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com> References: <6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com> Message-ID: On Tue, Jun 24, 2008 at 3:47 PM, Brian Granger wrote: >> Bummer! Please keep us posted. >> >> I have to say that I've given up on the whole 'history folding' >> problem, so I'm not 100% happy with bzr/lp either. Basically if you >> have truly diverged lines of work where you did work and committed >> locally while other devs pushed, a merge is inevitable (even if you >> keep several branches and push only from one that you don't develop >> in). And at that point, bzr does the whole 'dropped revisions' dance >> and folds history. > >> But on the whole we do gain from the ability to flexibly merge (even >> with ugly history) and the support for contributors from launchpad is >> vastly better than manually managing accounts on scipy.org and playing >> admin-by-night, so it's a net gain. Just not a perfect one :) > > Definitely not perfect, but I do agree that it is a net gain from > before. I would characterize this in the "Just Works" category, but > with a "Not always quite the way you want it to" clause. Judging from > past experience (CVS-> SVN->bzr) these decisions are likely not final > for all eternity. I agree that it's not perfect, but much better than before. Progress is always a bumpy road, and as Brian says, we can always choose to go through this again in the future :) > > Cheers, > > Brian > >> But definitely keep us posted on the nature of the OSX issues. >> >> Cheers, >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > From hans_meine at gmx.net Wed Jun 25 08:14:25 2008 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 25 Jun 2008 14:14:25 +0200 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> References: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> Message-ID: <200806251414.26194.hans_meine@gmx.net> Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt: > When branches diverge, a merge is necessary. Some revision control > systems hide the merges, others (like bzr) don't. How does mercurial > handle the issue? (Background: I have recently switched to Mercurial with many of my projects and am constantly using it a lot, incl. many extensions and following the mailing list. My bzr experience is near zero though.) Mercurial does not handle any line of development special, i.e. you get to see the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg view"). AFAICS, bzr decides that one path from this graphs "root" to the tip is somehow special (IIRC called the "mainline") and only displays this by default (i.e. you see only one changeset when a branch is merged). For example, here's an excerpt from an actual "hg log" output of mine, in which branching and merging occured: ... changeset: 228:765851775ca5 user: Hans Meine date: Fri Apr 04 22:19:40 2008 +0200 summary: Added tag release_0_4 for changeset 4180934dce9d changeset: 227:4180934dce9d tag: release_0_4 parent: 226:fc47fb9bf558 parent: 225:29273fb40578 user: Hans Meine date: Fri Apr 04 22:04:00 2008 +0200 summary: merged branch/dist.sh changes from Qt3 version changeset: 226:fc47fb9bf558 parent: 222:1b6fee2f3be2 user: Hans Meine date: Fri Apr 04 22:03:13 2008 +0200 summary: get rid of necessary VigraQt symlink changeset: 225:29273fb40578 user: Hans Meine date: Fri Apr 04 21:59:46 2008 +0200 summary: don't delete vigraqt.testing changeset: 224:5d6c94f6de48 user: Hans Meine date: Thu Apr 03 14:14:00 2008 +0200 summary: adapt script to mercurial needs (remove CVS stuff) changeset: 223:c478238d5ec0 parent: 179:776243786443 user: Hans Meine date: Thu Apr 03 14:13:39 2008 +0200 summary: Added tag release_0_4 for changeset 776243786443 changeset: 222:1b6fee2f3be2 user: Hans Meine date: Fri Apr 04 21:54:42 2008 +0200 summary: remove old autotools-README ... All changesets are displayed in the same format, no matter on which branch they occured. (If I had used named branches, the above would include "branch: somebranch" though.) The parent: lines indicate a) branching, e.g. a specified parent that is != the previous revision (in which case "hg log" omits the line for brevity) and b) merging, e.g. more than one parent. Of course, graphical tools display this more nicely. There's also "glog" ("graphical log") which uses ASCII art: ... | o changeset: 228:765851775ca5 | user: Hans Meine | date: Fri Apr 04 22:19:40 2008 +0200 | summary: Added tag release_0_4 for changeset 4180934dce9d | o changeset: 227:4180934dce9d |\ tag: release_0_4 | | parent: 226:fc47fb9bf558 | | parent: 225:29273fb40578 | | user: Hans Meine | | date: Fri Apr 04 22:04:00 2008 +0200 | | summary: merged branch/dist.sh changes from Qt3 version | | | o changeset: 226:fc47fb9bf558 | | parent: 222:1b6fee2f3be2 | | user: Hans Meine | | date: Fri Apr 04 22:03:13 2008 +0200 | | summary: get rid of necessary VigraQt symlink | | o | changeset: 225:29273fb40578 | | user: Hans Meine | | date: Fri Apr 04 21:59:46 2008 +0200 | | summary: don't delete vigraqt.testing | | o | changeset: 224:5d6c94f6de48 | | user: Hans Meine | | date: Thu Apr 03 14:14:00 2008 +0200 | | summary: adapt script to mercurial needs (remove CVS stuff) | | o | changeset: 223:c478238d5ec0 | | parent: 179:776243786443 | | user: Hans Meine | | date: Thu Apr 03 14:13:39 2008 +0200 | | summary: Added tag release_0_4 for changeset 776243786443 | | | | ... | | | o changeset: 181:d90cf77766a5 | | user: Hans Meine | | date: Thu Apr 03 15:40:18 2008 +0200 | | summary: Qt4 porting: | | | o changeset: 180:f1910ad7c12b |/ user: Hans Meine | date: Thu Apr 03 15:36:49 2008 +0200 | summary: Qt4 porting: QImage format stuff, add v2qc | o changeset: 179:776243786443 | user: Hans Meine | date: Thu Apr 03 14:03:26 2008 +0200 | summary: version bump -> 0.4 | ... (BTW: This looks much better in a terminal than in a mailer who thinks that "|" starts a quote...) In summary, I am extremely happy with mercurial and find it very easy to understand and work with. I believe bzr is not much different, and launchpad looks nice, but I see the discussed history folding as the only serious reason why I would currently recommend hg over bzr. OTOH, the situation could be much improved if lp would (allow to) display the complete history instead of only the "mainline" one AFAICS. Hope that helped, Hans From barrywark at gmail.com Wed Jun 25 10:38:37 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 25 Jun 2008 07:38:37 -0700 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <200806251414.26194.hans_meine@gmx.net> References: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> <200806251414.26194.hans_meine@gmx.net> Message-ID: It does sound like hg has nice behavior in this regard. It wasn't my intention, however, to restart the debate on DVCS systems. The hosting and services provided by launchpad.net tip the benefits strongly in favor of bzr for now and I think that's a good decision. Of course, it's always nice to keep up with the options. I'm looking forward to trying hg in the future. On Wed, Jun 25, 2008 at 5:14 AM, Hans Meine wrote: > Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt: >> When branches diverge, a merge is necessary. Some revision control >> systems hide the merges, others (like bzr) don't. How does mercurial >> handle the issue? > > (Background: I have recently switched to Mercurial with many of my projects > and am constantly using it a lot, incl. many extensions and following the > mailing list. My bzr experience is near zero though.) > > Mercurial does not handle any line of development special, i.e. you get to see > the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg > view"). AFAICS, bzr decides that one path from this graphs "root" to the tip > is somehow special (IIRC called the "mainline") and only displays this by > default (i.e. you see only one changeset when a branch is merged). > > For example, here's an excerpt from an actual "hg log" output of mine, in > which branching and merging occured: > > ... > > changeset: 228:765851775ca5 > user: Hans Meine > date: Fri Apr 04 22:19:40 2008 +0200 > summary: Added tag release_0_4 for changeset 4180934dce9d > > changeset: 227:4180934dce9d > tag: release_0_4 > parent: 226:fc47fb9bf558 > parent: 225:29273fb40578 > user: Hans Meine > date: Fri Apr 04 22:04:00 2008 +0200 > summary: merged branch/dist.sh changes from Qt3 version > > changeset: 226:fc47fb9bf558 > parent: 222:1b6fee2f3be2 > user: Hans Meine > date: Fri Apr 04 22:03:13 2008 +0200 > summary: get rid of necessary VigraQt symlink > > changeset: 225:29273fb40578 > user: Hans Meine > date: Fri Apr 04 21:59:46 2008 +0200 > summary: don't delete vigraqt.testing > > changeset: 224:5d6c94f6de48 > user: Hans Meine > date: Thu Apr 03 14:14:00 2008 +0200 > summary: adapt script to mercurial needs (remove CVS stuff) > > changeset: 223:c478238d5ec0 > parent: 179:776243786443 > user: Hans Meine > date: Thu Apr 03 14:13:39 2008 +0200 > summary: Added tag release_0_4 for changeset 776243786443 > > changeset: 222:1b6fee2f3be2 > user: Hans Meine > date: Fri Apr 04 21:54:42 2008 +0200 > summary: remove old autotools-README > > ... > > All changesets are displayed in the same format, no matter on which branch > they occured. (If I had used named branches, the above would > include "branch: somebranch" though.) The parent: lines indicate > a) branching, e.g. a specified parent that is != the previous revision (in > which case "hg log" omits the line for brevity) and > b) merging, e.g. more than one parent. > > Of course, graphical tools display this more nicely. There's also "glog" > ("graphical log") which uses ASCII art: > > ... > | > o changeset: 228:765851775ca5 > | user: Hans Meine > | date: Fri Apr 04 22:19:40 2008 +0200 > | summary: Added tag release_0_4 for changeset 4180934dce9d > | > o changeset: 227:4180934dce9d > |\ tag: release_0_4 > | | parent: 226:fc47fb9bf558 > | | parent: 225:29273fb40578 > | | user: Hans Meine > | | date: Fri Apr 04 22:04:00 2008 +0200 > | | summary: merged branch/dist.sh changes from Qt3 version > | | > | o changeset: 226:fc47fb9bf558 > | | parent: 222:1b6fee2f3be2 > | | user: Hans Meine > | | date: Fri Apr 04 22:03:13 2008 +0200 > | | summary: get rid of necessary VigraQt symlink > | | > o | changeset: 225:29273fb40578 > | | user: Hans Meine > | | date: Fri Apr 04 21:59:46 2008 +0200 > | | summary: don't delete vigraqt.testing > | | > o | changeset: 224:5d6c94f6de48 > | | user: Hans Meine > | | date: Thu Apr 03 14:14:00 2008 +0200 > | | summary: adapt script to mercurial needs (remove CVS stuff) > | | > o | changeset: 223:c478238d5ec0 > | | parent: 179:776243786443 > | | user: Hans Meine > | | date: Thu Apr 03 14:13:39 2008 +0200 > | | summary: Added tag release_0_4 for changeset 776243786443 > | | > | | ... > | | > | o changeset: 181:d90cf77766a5 > | | user: Hans Meine > | | date: Thu Apr 03 15:40:18 2008 +0200 > | | summary: Qt4 porting: > | | > | o changeset: 180:f1910ad7c12b > |/ user: Hans Meine > | date: Thu Apr 03 15:36:49 2008 +0200 > | summary: Qt4 porting: QImage format stuff, add v2qc > | > o changeset: 179:776243786443 > | user: Hans Meine > | date: Thu Apr 03 14:03:26 2008 +0200 > | summary: version bump -> 0.4 > | > ... > > (BTW: This looks much better in a terminal than in a mailer who thinks > that "|" starts a quote...) > > In summary, I am extremely happy with mercurial and find it very easy to > understand and work with. I believe bzr is not much different, and launchpad > looks nice, but I see the discussed history folding as the only serious > reason why I would currently recommend hg over bzr. OTOH, the situation > could be much improved if lp would (allow to) display the complete history > instead of only the "mainline" one AFAICS. > > Hope that helped, > Hans > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Wed Jun 25 11:39:47 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 25 Jun 2008 09:39:47 -0600 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <200806251414.26194.hans_meine@gmx.net> References: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> <200806251414.26194.hans_meine@gmx.net> Message-ID: <6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com> Thanks for the comments on hg. As Barry said, I don't think we want to revisit our choice of DVCS at this point. That said, it actually seems to be quite difficult to get a fair and accurate evaluation of the various DVCS systems. Here is what I have observed (taking the liberty to make generalizations): 1. _All_ of the DVCS make design decisions that make certain things nice and other things less nice. It is a question of trade offs. 2. You almost never see the less nice things when you casually try one of them out. You really have to "get your hands dirty" before these things come up. By then you have already made the decision :) 3. It is easy to get someone to detail the pros of one choice or the cons of another, but it is really difficult to get someone to give a fair and accurate survey of the pros and cons of all the choices. 4. The few people who can give such an fair and accurate survey of the choices know so much about DVCS that I can't understand half the things they are talking about. Cheers, Brian On Wed, Jun 25, 2008 at 6:14 AM, Hans Meine wrote: > Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt: >> When branches diverge, a merge is necessary. Some revision control >> systems hide the merges, others (like bzr) don't. How does mercurial >> handle the issue? > > (Background: I have recently switched to Mercurial with many of my projects > and am constantly using it a lot, incl. many extensions and following the > mailing list. My bzr experience is near zero though.) > > Mercurial does not handle any line of development special, i.e. you get to see > the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg > view"). AFAICS, bzr decides that one path from this graphs "root" to the tip > is somehow special (IIRC called the "mainline") and only displays this by > default (i.e. you see only one changeset when a branch is merged). > > For example, here's an excerpt from an actual "hg log" output of mine, in > which branching and merging occured: > > ... > > changeset: 228:765851775ca5 > user: Hans Meine > date: Fri Apr 04 22:19:40 2008 +0200 > summary: Added tag release_0_4 for changeset 4180934dce9d > > changeset: 227:4180934dce9d > tag: release_0_4 > parent: 226:fc47fb9bf558 > parent: 225:29273fb40578 > user: Hans Meine > date: Fri Apr 04 22:04:00 2008 +0200 > summary: merged branch/dist.sh changes from Qt3 version > > changeset: 226:fc47fb9bf558 > parent: 222:1b6fee2f3be2 > user: Hans Meine > date: Fri Apr 04 22:03:13 2008 +0200 > summary: get rid of necessary VigraQt symlink > > changeset: 225:29273fb40578 > user: Hans Meine > date: Fri Apr 04 21:59:46 2008 +0200 > summary: don't delete vigraqt.testing > > changeset: 224:5d6c94f6de48 > user: Hans Meine > date: Thu Apr 03 14:14:00 2008 +0200 > summary: adapt script to mercurial needs (remove CVS stuff) > > changeset: 223:c478238d5ec0 > parent: 179:776243786443 > user: Hans Meine > date: Thu Apr 03 14:13:39 2008 +0200 > summary: Added tag release_0_4 for changeset 776243786443 > > changeset: 222:1b6fee2f3be2 > user: Hans Meine > date: Fri Apr 04 21:54:42 2008 +0200 > summary: remove old autotools-README > > ... > > All changesets are displayed in the same format, no matter on which branch > they occured. (If I had used named branches, the above would > include "branch: somebranch" though.) The parent: lines indicate > a) branching, e.g. a specified parent that is != the previous revision (in > which case "hg log" omits the line for brevity) and > b) merging, e.g. more than one parent. > > Of course, graphical tools display this more nicely. There's also "glog" > ("graphical log") which uses ASCII art: > > ... > | > o changeset: 228:765851775ca5 > | user: Hans Meine > | date: Fri Apr 04 22:19:40 2008 +0200 > | summary: Added tag release_0_4 for changeset 4180934dce9d > | > o changeset: 227:4180934dce9d > |\ tag: release_0_4 > | | parent: 226:fc47fb9bf558 > | | parent: 225:29273fb40578 > | | user: Hans Meine > | | date: Fri Apr 04 22:04:00 2008 +0200 > | | summary: merged branch/dist.sh changes from Qt3 version > | | > | o changeset: 226:fc47fb9bf558 > | | parent: 222:1b6fee2f3be2 > | | user: Hans Meine > | | date: Fri Apr 04 22:03:13 2008 +0200 > | | summary: get rid of necessary VigraQt symlink > | | > o | changeset: 225:29273fb40578 > | | user: Hans Meine > | | date: Fri Apr 04 21:59:46 2008 +0200 > | | summary: don't delete vigraqt.testing > | | > o | changeset: 224:5d6c94f6de48 > | | user: Hans Meine > | | date: Thu Apr 03 14:14:00 2008 +0200 > | | summary: adapt script to mercurial needs (remove CVS stuff) > | | > o | changeset: 223:c478238d5ec0 > | | parent: 179:776243786443 > | | user: Hans Meine > | | date: Thu Apr 03 14:13:39 2008 +0200 > | | summary: Added tag release_0_4 for changeset 776243786443 > | | > | | ... > | | > | o changeset: 181:d90cf77766a5 > | | user: Hans Meine > | | date: Thu Apr 03 15:40:18 2008 +0200 > | | summary: Qt4 porting: > | | > | o changeset: 180:f1910ad7c12b > |/ user: Hans Meine > | date: Thu Apr 03 15:36:49 2008 +0200 > | summary: Qt4 porting: QImage format stuff, add v2qc > | > o changeset: 179:776243786443 > | user: Hans Meine > | date: Thu Apr 03 14:03:26 2008 +0200 > | summary: version bump -> 0.4 > | > ... > > (BTW: This looks much better in a terminal than in a mailer who thinks > that "|" starts a quote...) > > In summary, I am extremely happy with mercurial and find it very easy to > understand and work with. I believe bzr is not much different, and launchpad > looks nice, but I see the discussed history folding as the only serious > reason why I would currently recommend hg over bzr. OTOH, the situation > could be much improved if lp would (allow to) display the complete history > instead of only the "mainline" one AFAICS. > > Hope that helped, > Hans > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From hans_meine at gmx.net Wed Jun 25 12:52:06 2008 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 25 Jun 2008 18:52:06 +0200 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com> References: <200806251414.26194.hans_meine@gmx.net> <6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com> Message-ID: <200806251852.07200.hans_meine@gmx.net> Am Mittwoch, 25. Juni 2008 17:39:47 schrieb Brian Granger: > Thanks for the comments on hg. As Barry said, I don't think we want > to revisit our choice of DVCS at this point. Sure, I just took the opportunity to document the different for future reference (maybe I put that up on some Wiki/Blog some day, but even now it will get archived). There are already lots of (mostly outdated) DVCS comparisons out there, but I did not see this particular aspect (the presence of a "mainline" concept) discussed anywhere. > 4. The few people who can give such an fair and accurate survey of > the choices know so much about DVCS that I can't understand half the > things they are talking about. And then people like to improve "their" DVCS such that every such survey becomes outdated sooner than you understood it... Bottom line: I learned a lot from your public discussion of the particular warts bzr/lp posed on IPython, but I did not and will not propose a hg switch, don't worry.. ;-) Greetings, Hans (who is looking forward to the frontend stuff, esp. for Qt4) From vivainio at gmail.com Wed Jun 25 13:22:30 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 25 Jun 2008 20:22:30 +0300 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <200806251414.26194.hans_meine@gmx.net> References: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com> <200806251414.26194.hans_meine@gmx.net> Message-ID: <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> On Wed, Jun 25, 2008 at 3:14 PM, Hans Meine wrote: > Mercurial does not handle any line of development special, i.e. you get to see > the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg > view"). AFAICS, bzr decides that one path from this graphs "root" to the tip And the same works with bzr (bzr qlog / bzr viz). It's just about revision numbers (that mean much more in bzr than they do in hg), and what you see on launchpad revision history page. This is actually a feature in bzr, and something that makes the UI of bzr simpler than hg's. The big advantage of hg over bzr is speed, so as long as we get decent performance out of bzr, this discussion is not worth spending too much time/brain energy on. We are investigating the use of hg at workplace, just because we'd like to have one version control system that is suitable for projects of all sizes. If we were only working on small projects (~ ipython size), I would have recommended bzr - it does the "just works" thing quite well. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From barrywark at gmail.com Wed Jun 25 14:33:52 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 25 Jun 2008 11:33:52 -0700 Subject: [IPython-dev] frontend plans Message-ID: Ga?l and I had a very nice talk this morning on future directions for the frontend package and IPython frontends in general and I'd like to let you all know what we were thinking. I appologize that this summary is somewhat terse. Writing about software development is not (yet) one of my strengths. I don't have much time to dedicate to this today and thought that a brief summary was better than a smoother??but unsent?write-up. Our discussion centered around Ga?l's use case. He's planning to write a Wx frontend for IPython that has some concurency (or lack thereof) guarantees. Namely, he wants everything to happen synchronously. Furthermore, he would like to remove the Twisted dependency from IPython.frontend if possible?if there's no asynchronous results in his frontend, there appears to be no need for Twisted. By way of contrast, my Cocoa frontend is written to be fully asynchronous, ultimately looking more like a Mathematica notebook than a terminal, and Twisted is an acceptable dependency. Ga?l's requirements are very similar to those of the basic terminal frontend, so I think it's in everyone's interest to think about how to best meet those requirements. There seem to be two ways to get synchronous, Twisted-free frontends: 1 We could write an IPython.frontend.frontendbase.IFrontEnd implementation that talks directly with IPython.kernel.core. A little bit of trickery would easily remove the twisted.python.failure.Failure dependency from IPython.frontend.frontendbase. 2, Write an implementation of IEngineCore that does not depend on Twisted and returns results synchronously. Because the IEngine* interface specifies that all methods return t.i.d.Deferred results, we will need a mock Deferred object. The Synchronous-deferred project (lp;syncrhonous-deferred) appears to fit the bill. License is public domain, and it's two pure python files (one implementation, one test). The project appears to be effectively "complete" -- no activity in several months. I propose we include the syncrhonous deferred as an external dependency in the IPython distribution. We could then write an IEngineBase implementation that returns SynchronousDeferreds. This engine implementation could be passed to FrontEndBase's constructor and we get synchronous, twisted-free frontends [1] Since the IEngine* interface is much more stable than the IFrontEnd interface, I propose going with solution #2. Although it adds an additional python file as external dependency, it seems conceptually cleaner (all frontends go through the engine interface) and allows frontends to decide between synchronous and asynchronous behavior without any code changes. If anyone has comments, let's have 'em. If folks think it's a good idea, I'll create a branch and start making the changes outlined in #2 above. The second issue Ga?l and I discussed was code completion in the front end. As I understand it, Brian and Fernando want completion to happen on the frontend to avoid network latency (and possible blocking engine latency). In order to do this, however, the frontend needs a complete copy of the user_ns. This means a large memory overhead and a lot of synchronization issues. We don't have a very good solution at this point. In the Cocoa frontend, I've played with mirroring the user_ns top-level keys for completion but going to the engine after that, not a very satisfying solution. We need ideas. Barry [1] Removing the Twisted dependence completely will require moving the IEngine* interfaces to a separate module from the implementations. I propose moving them to IPython.kernel.engineinterface.py. From ellisonbg.net at gmail.com Wed Jun 25 18:59:04 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Wed, 25 Jun 2008 16:59:04 -0600 Subject: [IPython-dev] frontend plans In-Reply-To: References: Message-ID: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> > Ga?l and I had a very nice talk this morning on future directions for > the frontend package and IPython frontends in general and I'd like to > let you all know what we were thinking. I appologize that this > summary is somewhat terse. Writing about software development is not > (yet) one of my strengths. I don't have much time to dedicate to this > today and thought that a brief summary was better than a smoother??but > unsent?write-up. Glad you two were able to talk. > Our discussion centered around Ga?l's use case. He's planning to write > a Wx frontend for IPython that has some concurency (or lack thereof) > guarantees. Namely, he wants everything to happen synchronously. > Furthermore, he would like to remove the Twisted dependency from > IPython.frontend if possible?if there's no asynchronous results in his > frontend, there appears to be no need for Twisted. By way of > contrast, my Cocoa frontend is written to be fully asynchronous, > ultimately looking more like a Mathematica notebook than a terminal, > and Twisted is an acceptable dependency. Ga?l's requirements are very > similar to those of the basic terminal frontend, so I think it's in > everyone's interest to think about how to best meet those > requirements. I think this is very true that a terminal based frontend and a synchronous GUI frontend will be very similar in design. > There seem to be two ways to get synchronous, Twisted-free frontends: > > 1 We could write an IPython.frontend.frontendbase.IFrontEnd > implementation that talks directly with IPython.kernel.core. A little > bit of trickery would easily remove the twisted.python.failure.Failure > dependency from IPython.frontend.frontendbase. I think that we could have a single base class that implements the actual frontend logic and then have multiple subclasses that handle the calls to the various types of backends (kernel.core or kernel.engineservice). I need to look more at how the frontend is implemented, but Barry, do you think this would work. The other idea would be to play around with using adaptors to handle the impedance mismatches in the interfaces. > 2, Write an implementation of IEngineCore that does not depend on > Twisted and returns results synchronously. Because the IEngine* > interface specifies that all methods return t.i.d.Deferred results, we > will need a mock Deferred object. The Synchronous-deferred project > (lp;syncrhonous-deferred) appears to fit the bill. License is public > domain, and it's two pure python files (one implementation, one test). > The project appears to be effectively "complete" -- no activity in > several months. I propose we include the syncrhonous deferred as an > external dependency in the IPython distribution. We could then write > an IEngineBase implementation that returns SynchronousDeferreds. This > engine implementation could be passed to FrontEndBase's constructor > and we get synchronous, twisted-free frontends [1] I am not sure about this one. The dependency is not just twisted, but also zope.interface and these two can't really be separated from each other or things in i.k. Because zope.interface has C code, we can't depend on it in the core of IPython or the terminal based IPython (we want it to work on non CPython implementations). This can be worked around by simply not having the implementation declare that it implements the z.i IEngineCore interface. But, in either case, that version of the IEngineCore should not live in i.k as there are twisted imports _everywhere_. [as an aside, I think we really need to use subpackages to encapsulate dependencies like twisted.] Also, the Synchronous deferred does not present the exact same interface as a true deferred or make the same promises about when things will happen. Thus, I my mind, the new IEngineCore implementation _couldn't_ possible really implement the interface. In fact, if I remember correctly, we have a test that can be run on any IEngineCore implementer. It actually calls all the methods of the interface and checks: self.assert_(isinstance(return_value, t.i.Deferred) A fake deferred won't pass such tests. So, in summary, I think more discussion is needed before commiting to #2. I am crazy busy, but I will try to have a look at IFrontEnd tonight. > Since the IEngine* interface is much more stable than the IFrontEnd > interface, I propose going with solution #2. Although it adds an > additional python file as external dependency, it seems conceptually > cleaner (all frontends go through the engine interface) and allows > frontends to decide between synchronous and asynchronous behavior > without any code changes. I think it is conceptually convoluted because the only significant way that IEngireCore different from the underlying core is that its methods return deferreds (and Failures). Thus to use IEngineCore, but then try to get rid of the (true) Deferreds by using fake ones seems like double work (why not just call the class whose methods don't return deferreds in the first place). > If anyone has comments, let's have 'em. If folks think it's a good > idea, I'll create a branch and start making the changes outlined in #2 > above. > > The second issue Ga?l and I discussed was code completion in the front > end. As I understand it, Brian and Fernando want completion to happen > on the frontend to avoid network latency (and possible blocking engine > latency). In order to do this, however, the frontend needs a complete > copy of the user_ns. This means a large memory overhead and a lot of > synchronization issues. We don't have a very good solution at this > point. In the Cocoa frontend, I've played with mirroring the user_ns > top-level keys for completion but going to the engine after that, not > a very satisfying solution. We need ideas. Actually, I think we are in agreement that tab completion (the part that actually looks up things in the users namespace) needs to be done in the engine/core through its complete method. There is just no way it is reasonable to mirror the user_ns in the frontend for the reasons you mention. Sorry if we have said anything confusion on this front. So I guess the complete method of the frontend should just call the complete method of the engine/core? Cheers, Brian > Barry > > [1] Removing the Twisted dependence completely will require moving the > IEngine* interfaces to a separate module from the implementations. I > propose moving them to IPython.kernel.engineinterface.py. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From laurent.dufrechou at gmail.com Thu Jun 26 08:43:20 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Thu, 26 Jun 2008 14:43:20 +0200 Subject: [IPython-dev] Moving forward with the frontends In-Reply-To: <46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com> References: <20080623181632.GF13966@phare.normalesup.org> <46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com> Message-ID: <48638eef.02578c0a.5d98.0aee@mx.google.com> Hi Gael,All I'm in Canada right now for business, so I missed some email :) Don't know if it could be interesting but I think you could try to add ipython1 handling in ipshell_nonblocking.py, Thus we could share this part of code and improve it together. (It's up to you :) ) Basically if you go this way, I think you'll have to define an ipython1 init and ipython1_execute command, and you should be done. (That is indeed a lot of work :) ). (Modifying doExecute function should permit you to be or not multithreaded) Perhaps we can think about doing a base class and deriavate from it to work with either ipython0 or ipython1 to get a cleaner code... don't know) Do you plan to use scintilla widget? 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??: mardi 24 juin 2008 08:04 > ??: Gael Varoquaux > Cc?: ipython-dev Mailing list > Objet?: Re: [IPython-dev] Moving forward with the frontends > > On Mon, Jun 23, 2008 at 9:16 PM, Gael Varoquaux > wrote: > > > integrate IPython in Mayavi and other similar projects. The > requirements > > are: > > > > * We want something fast, not after three months of work > > > * We are interested in wx. I am of course happy sharing the code > with > > other frontends, but I will not be developping them. > > > * The feature of ipython we are interested in are magics, "?" and > "??", > > tab completion, history, and alike... > > > I am currently reviewing the existing code. I see three code bases > for > > front end: > > > > * Laurent Dufrechou's WxIpython, living in the trunk, in > > IPython/gui/wx > > I think this is the winner here, given the preconditions above. It > seems it would be pretty easy to integrate. > > -- > 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 laurent.dufrechou at gmail.com Thu Jun 26 09:05:51 2008 From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=) Date: Thu, 26 Jun 2008 15:05:51 +0200 Subject: [IPython-dev] pyreadline refactoring In-Reply-To: References: <48614E0D.30901@bostream.nu> Message-ID: <48639436.1f588c0a.5ade.15d5@mx.google.com> Hi Jorgen, Good news :) When i wrote ipython0 wx frontend i ran into some problem with readline. (And perhaps I ran in these problems because I don't enter enough in pyreadline code who knows...) - History (the biggest one): It was not that easy to get these information: HistoryBack and HistoryForward, and history current length. So if you could add some simple and direct method that permit to load a history from file, and manage an history pointer I'll be very very happy. If you don't understand what I mean just have a look at line 300 of ipshell_nonblocking.py in /gui/wx I think you'll see what I didn't found in pyreadline. I fact should be good to have some simple function to get easily an history. Currently to get history I use....: IP.input_hist_raw[self._history_level].strip('\n') That is far from ideal... - In my code I used pyreadline capabilities to get ascii colored outputted datas. Do you think it could be possible to add some other output formatter like for example an xml formatter or html for example. Perhaps just a method to bypass classical readline formatter and people could add their formatter (thus we could step by step add new formatter to readline code) Just an idea... - Can it be possible to use readline only for history and output formating? I mean without key handling and cursor management? (If for example I want for any reason manage them myself) Laurent > -----Message d'origine----- > De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev- > bounces at scipy.org] De la part de Barry Wark > Envoy??: mercredi 25 juin 2008 00:37 > ??: J?rgen Stenarson > Cc?: IPython-dev List > Objet?: Re: [IPython-dev] pyreadline refactoring > > On Tue, Jun 24, 2008 at 12:42 PM, J?rgen Stenarson > wrote: > > Hi, > > > > I have started to work on a refactoring of pyreadline with the goal > to > > untangle the class interactions that have made it difficult to reuse > > pyreadline in other circumstances than a shell on win32. > > > > The basic idea is that it should be possible to call a readline > object > > with keypress events containing (control, shift, meta, char, keyname) > > where keyname is for special keys like space, f1, return etc. > > > > The readline object would be responsible for keeping track of current > > prompt, line_buffer, cursor_position and selection_position. But the > > caller of the object will have to render the buffer. > > > > I have also merged the callback branch I worked on a few months back. > > The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor > > > > If anyone has any ideas or suggestions on how things should work > please > > let me know. > > J?rgen, > > Wow, this is an exciting move in view of the plans to separate > ipython0's core from the terminal/readline. I am still learning about > pyreadline, but your description above makes me think that you, me, > and Ga?l should think about using the new (refactored) pyreadline in > developing a base class for front ends that are based on a > line-oriented interface (i.e. mimicking the terminal interface). > > Barry > > > > > /J?rgen > > > > _______________________________________________ > > 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 vivainio at gmail.com Thu Jun 26 12:49:02 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 26 Jun 2008 19:49:02 +0300 Subject: [IPython-dev] pyreadline refactoring In-Reply-To: <48639436.1f588c0a.5ade.15d5@mx.google.com> References: <48614E0D.30901@bostream.nu> <48639436.1f588c0a.5ade.15d5@mx.google.com> Message-ID: <46cb515a0806260949k1ede361dq3791754dcb9ac940@mail.gmail.com> On Thu, Jun 26, 2008 at 4:05 PM, Laurent Dufr?chou wrote: > I fact should be good to have some simple function to get easily an history. > Currently to get history I use....: > IP.input_hist_raw[self._history_level].strip('\n') > That is far from ideal... It's trivial to wrap; it just needs to be done :). > - In my code I used pyreadline capabilities to get ascii colored outputted > datas. > Do you think it could be possible to add some other output formatter like > for example an xml formatter or html for example. Perhaps just a method to Yes, but you will still need to support the colored output from system commands, so the ANSI code handling needs to be there in the end. Someone could write a html/xml colorizer to allow convenient/readable color coding, of course, but it could as well be a simple function that converts stuff to ANSI color codes. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From vivainio at gmail.com Thu Jun 26 12:56:40 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 26 Jun 2008 19:56:40 +0300 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <200806261341.14255.hans_meine@gmx.net> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> Message-ID: <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> On Thu, Jun 26, 2008 at 2:41 PM, Hans Meine wrote: > I tend to think it's again the Zen of Python (explicit is better than > implicit). I would reconsider it as a "good" feature if you had explicit > control over which path through history is considered to be the mainline. You have explicit control of that - I guess that's what is the reason for the history folding problem ;-) The sole cause of the history folding problem is that people push the wrong branch to the wrong place. Once you observe some caution as to what you push and where, it's a non-issue. We wouldn't even be talking about this if launchpad had a checkbox somewhere that prevented pushing to the wrong branch, or at least required some kind of --force option to do it. That not being the case, we have to observe some caution. I guess this is comparable to python vs. C++ - we don't have a compiler, so we can't count on our tools to safeguard us against something, but we get by. This should be pretty easy to fix by bzr developers, but I'm not sure how much it has been talked about (and am rather too busy to engage in the conversation on bzr mailing list ATM). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From jorgen.stenarson at bostream.nu Thu Jun 26 13:37:18 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 26 Jun 2008 19:37:18 +0200 Subject: [IPython-dev] pyreadline refactoring In-Reply-To: References: <48614E0D.30901@bostream.nu> Message-ID: <4863D3CE.2010707@bostream.nu> Barry Wark skrev: > > Wow, this is an exciting move in view of the plans to separate > ipython0's core from the terminal/readline. I am still learning about > pyreadline, but your description above makes me think that you, me, > and Ga?l should think about using the new (refactored) pyreadline in > developing a base class for front ends that are based on a > line-oriented interface (i.e. mimicking the terminal interface). > > Barry > I'm happy to hear you would like to help out. Attached is a mockup of a gui calling readline, does this approach seem reasonable to you as a starting point. I'm inexperienced in building guis so I would appreciate some help in improving the eventhandler to translate keyevents to a KeyEvent object. At a first glance at the event handling in Tk it seems it requires some work to get the control, shift, meta modifiers that were used for a certain keypress. So right now this example needs improvement so we can handle those modifiers. This is where I would appreciate to get some assistance, I would prefer to have such an example in Tk or Wx since those are the systems I use the most. It would also be nice to able to draw the cursor and also to mark a text selection as well. best regards, J?rgen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tk_gui.py URL: From jorgen.stenarson at bostream.nu Thu Jun 26 16:17:49 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 26 Jun 2008 22:17:49 +0200 Subject: [IPython-dev] pyreadline tkgui example Message-ID: <4863F96D.8020304@bostream.nu> Hi, in the lp:~jorgen-stenarson/pyreadline/pyreadline-refactor branch there is now an example in pyreadline/examples/tk_gui.py. It uses the BaseReadline class to implement readline. The basic edit functionality is there. But there is now cursor or selection marking. /J?rgen From barrywark at gmail.com Thu Jun 26 16:54:52 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 26 Jun 2008 13:54:52 -0700 Subject: [IPython-dev] frontend plans In-Reply-To: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> Message-ID: On Wed, Jun 25, 2008 at 3:59 PM, Brian Granger wrote: >> Ga?l and I had a very nice talk this morning on future directions for >> the frontend package and IPython frontends in general and I'd like to >> let you all know what we were thinking. I appologize that this >> summary is somewhat terse. Writing about software development is not >> (yet) one of my strengths. I don't have much time to dedicate to this >> today and thought that a brief summary was better than a smoother??but >> unsent?write-up. > > Glad you two were able to talk. > >> Our discussion centered around Ga?l's use case. He's planning to write >> a Wx frontend for IPython that has some concurency (or lack thereof) >> guarantees. Namely, he wants everything to happen synchronously. >> Furthermore, he would like to remove the Twisted dependency from >> IPython.frontend if possible?if there's no asynchronous results in his >> frontend, there appears to be no need for Twisted. By way of >> contrast, my Cocoa frontend is written to be fully asynchronous, >> ultimately looking more like a Mathematica notebook than a terminal, >> and Twisted is an acceptable dependency. Ga?l's requirements are very >> similar to those of the basic terminal frontend, so I think it's in >> everyone's interest to think about how to best meet those >> requirements. > > I think this is very true that a terminal based frontend and a > synchronous GUI frontend will be very similar in design. > >> There seem to be two ways to get synchronous, Twisted-free frontends: >> >> 1 We could write an IPython.frontend.frontendbase.IFrontEnd >> implementation that talks directly with IPython.kernel.core. A little >> bit of trickery would easily remove the twisted.python.failure.Failure >> dependency from IPython.frontend.frontendbase. > > I think that we could have a single base class that implements the > actual frontend logic and then have multiple subclasses that handle > the calls to the various types of backends (kernel.core or > kernel.engineservice). I need to look more at how the frontend is > implemented, but Barry, do you think this would work. Yes, I think this would work. I thought zope.interface was pure python. Since we can't require zope.interface in the stripped-down ipython, I now think option 1 is the best approach. I'll work on that. > > The other idea would be to play around with using adaptors to handle > the impedance mismatches in the interfaces. > >> 2, Write an implementation of IEngineCore that does not depend on >> Twisted and returns results synchronously. Because the IEngine* >> interface specifies that all methods return t.i.d.Deferred results, we >> will need a mock Deferred object. The Synchronous-deferred project >> (lp;syncrhonous-deferred) appears to fit the bill. License is public >> domain, and it's two pure python files (one implementation, one test). >> The project appears to be effectively "complete" -- no activity in >> several months. I propose we include the syncrhonous deferred as an >> external dependency in the IPython distribution. We could then write >> an IEngineBase implementation that returns SynchronousDeferreds. This >> engine implementation could be passed to FrontEndBase's constructor >> and we get synchronous, twisted-free frontends [1] > > I am not sure about this one. The dependency is not just twisted, but > also zope.interface and these two can't really be separated from each > other or things in i.k. Because zope.interface has C code, we can't > depend on it in the core of IPython or the terminal based IPython (we > want it to work on non CPython implementations). I didn't realize this. I thought zope.interface was pure Python. That seems to be a show-stopper for option 2. This can be worked > around by simply not having the implementation declare that it > implements the z.i IEngineCore interface. But, in either case, that > version of the IEngineCore should not live in i.k as there are twisted > imports _everywhere_. [as an aside, I think we really need to use > subpackages to encapsulate dependencies like twisted.] By moving the interfaces to a separate module, we could import i.k.engineinterfaces.py without needing twisted, though obviously zope.interface would still be required. > > Also, the Synchronous deferred does not present the exact same > interface as a true deferred or make the same promises about when > things will happen. What is your understanding of the differences? Thus, I my mind, the new IEngineCore > implementation _couldn't_ possible really implement the interface. In > fact, if I remember correctly, we have a test that can be run on any > IEngineCore implementer. It actually calls all the methods of the > interface and checks: > > self.assert_(isinstance(return_value, t.i.Deferred) > > A fake deferred won't pass such tests. I don't think this is an appropriate test then. The interface should specify the behavior of the returned object, not its implementation. If the Synchronous Deferred behaves the same as a t.i.defer.Deferred, then it should pass the test. The fact that it may not behave the same is a bigger issue. > > So, in summary, I think more discussion is needed before commiting to > #2. I am crazy busy, but I will try to have a look at IFrontEnd > tonight. > > >> Since the IEngine* interface is much more stable than the IFrontEnd >> interface, I propose going with solution #2. Although it adds an >> additional python file as external dependency, it seems conceptually >> cleaner (all frontends go through the engine interface) and allows >> frontends to decide between synchronous and asynchronous behavior >> without any code changes. > > I think it is conceptually convoluted because the only significant way > that IEngireCore different from the underlying core is that its > methods return deferreds (and Failures). Thus to use IEngineCore, but > then try to get rid of the (true) Deferreds by using fake ones seems > like double work (why not just call the class whose methods don't > return deferreds in the first place). It feels weird that there are two ways to interact with ipython?engine and core directly. It seemed that making a common interface was cleaner in that it allowed users of that interface to be able to use engine or core without modification of the frontend. Since that's not really an option anymore (because of zope.interface), I'm happy to give up that opinion and move on. > >> If anyone has comments, let's have 'em. If folks think it's a good >> idea, I'll create a branch and start making the changes outlined in #2 >> above. >> >> The second issue Ga?l and I discussed was code completion in the front >> end. As I understand it, Brian and Fernando want completion to happen >> on the frontend to avoid network latency (and possible blocking engine >> latency). In order to do this, however, the frontend needs a complete >> copy of the user_ns. This means a large memory overhead and a lot of >> synchronization issues. We don't have a very good solution at this >> point. In the Cocoa frontend, I've played with mirroring the user_ns >> top-level keys for completion but going to the engine after that, not >> a very satisfying solution. We need ideas. > > Actually, I think we are in agreement that tab completion (the part > that actually looks up things in the users namespace) needs to be done > in the engine/core through its complete method. There is just no way > it is reasonable to mirror the user_ns in the frontend for the reasons > you mention. Sorry if we have said anything confusion on this front. > So I guess the complete method of the frontend should just call the > complete method of the engine/core? Yes. I agree. frontend.complete() calls engine/core.complete(). > > Cheers, > > Brian > >> Barry >> >> [1] Removing the Twisted dependence completely will require moving the >> IEngine* interfaces to a separate module from the implementations. I >> propose moving them to IPython.kernel.engineinterface.py. >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > From fperez.net at gmail.com Thu Jun 26 17:32:01 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 26 Jun 2008 14:32:01 -0700 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> Message-ID: On Thu, Jun 26, 2008 at 9:56 AM, Ville M. Vainio wrote: > The sole cause of the history folding problem is that people push the > wrong branch to the wrong place. Once you observe some caution as to > what you push and where, it's a non-issue. Mmh, then there's something I've missed. Because even though I'm using the two-branch model, one to keep pulling/pushing upstream and one for local development, I'm *still* getting the same folding issue when true merging is required. Basically if there's the need for a real merge, because I've done work in my local branch while someone else has pushed to trunk, we get that. In that case, --pull fails with the 'branches have diverged' message and one is forced to merge. I think that we only have a small issue, and it's one I'm willing to ignore from now on: Launchpad (*not* bzr, since bzr viz/log is faithful to the full history) ignores all but one branch when showing history, and what it actually shows can change with each commit. When they improve their display, great, but until then let's just ignore that point (we're all too busy here to spend time fixing lp). But the fact that sometimes one *must* merge is unavoidable with distributed development: even using a special branch for communicating with upstream, merges sometimes are unavoidable. Else I'm really missing something here. Cheers, f From ellisonbg.net at gmail.com Thu Jun 26 19:03:35 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 26 Jun 2008 17:03:35 -0600 Subject: [IPython-dev] frontend plans In-Reply-To: References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> Message-ID: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> Barry, >> I think that we could have a single base class that implements the >> actual frontend logic and then have multiple subclasses that handle >> the calls to the various types of backends (kernel.core or >> kernel.engineservice). I need to look more at how the frontend is >> implemented, but Barry, do you think this would work. > > Yes, I think this would work. I thought zope.interface was pure > python. Since we can't require zope.interface in the stripped-down > ipython, I now think option 1 is the best approach. I'll work on that. Great, I think that will be best, even though it has its own downsides. >> Also, the Synchronous deferred does not present the exact same >> interface as a true deferred or make the same promises about when >> things will happen. > > What is your understanding of the differences? For Deferreds, I think the interface is not a complete specification of the objects behavior. For Deferreds, there are subtle cases that arise when you chain them together. The behavior exhibited in complex Deferred chaining _can_ depend on whether or a given Deferred has fired or not when the chaining is setup. We have in various places that handles these odd edge cases. Also, we sometimes access the semi-private attributes of Deferreds. Another thing is that if you have multiple unfired Deferreds, the order in which they will fire is not deterministic. For the synchronous deferreds, I think the ordering has to be deterministic. But in my mind, this constitues a different behavior and thus "interface" in the board sense of the word. We might be able to get the synchronous deferreds to work, but I am a little hesitant to go down that route simply because all of these things are _super_ subtle and nearly impossible to debug. > Thus, I my mind, the new IEngineCore >> implementation _couldn't_ possible really implement the interface. In >> fact, if I remember correctly, we have a test that can be run on any >> IEngineCore implementer. It actually calls all the methods of the >> interface and checks: >> >> self.assert_(isinstance(return_value, t.i.Deferred) >> >> A fake deferred won't pass such tests. > > I don't think this is an appropriate test then. The interface should > specify the behavior of the returned object, not its implementation. > If the Synchronous Deferred behaves the same as a t.i.defer.Deferred, > then it should pass the test. The fact that it may not behave the same > is a bigger issue. True, I could write a better test for this. The current test is only a super weak test behavior wise, but given the fact that there are no other objects that truly act like a Deferred, the test suffices. >> >> So, in summary, I think more discussion is needed before commiting to >> #2. I am crazy busy, but I will try to have a look at IFrontEnd >> tonight. > >> >> >>> Since the IEngine* interface is much more stable than the IFrontEnd >>> interface, I propose going with solution #2. Although it adds an >>> additional python file as external dependency, it seems conceptually >>> cleaner (all frontends go through the engine interface) and allows >>> frontends to decide between synchronous and asynchronous behavior >>> without any code changes. >> >> I think it is conceptually convoluted because the only significant way >> that IEngireCore different from the underlying core is that its >> methods return deferreds (and Failures). Thus to use IEngineCore, but >> then try to get rid of the (true) Deferreds by using fake ones seems >> like double work (why not just call the class whose methods don't >> return deferreds in the first place). > > It feels weird that there are two ways to interact with ipython?engine > and core directly. It seemed that making a common interface was > cleaner in that it allowed users of that interface to be able to use > engine or core without modification of the frontend. Since that's not > really an option anymore (because of zope.interface), I'm happy to > give up that opinion and move on. I do sort of agree with this, but I think having two interfaces is appropriate because they have vastly different behaviors (synchronous vs asynchronous). >> Actually, I think we are in agreement that tab completion (the part >> that actually looks up things in the users namespace) needs to be done >> in the engine/core through its complete method. There is just no way >> it is reasonable to mirror the user_ns in the frontend for the reasons >> you mention. Sorry if we have said anything confusion on this front. >> So I guess the complete method of the frontend should just call the >> complete method of the engine/core? > > Yes. I agree. frontend.complete() calls engine/core.complete(). Cool, Cheers, Brian >> >> Cheers, >> >> Brian >> >>> Barry >>> >>> [1] Removing the Twisted dependence completely will require moving the >>> IEngine* interfaces to a separate module from the implementations. I >>> propose moving them to IPython.kernel.engineinterface.py. >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>> >> > From gael.varoquaux at normalesup.org Thu Jun 26 22:12:12 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 27 Jun 2008 04:12:12 +0200 Subject: [IPython-dev] frontend plans In-Reply-To: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> Message-ID: <20080627021212.GA11323@phare.normalesup.org> Hey guys, And wanted to thank you very much for hashing down the ideas to get this working. I have no understanding of the code we are talking about and it is very valuable to have you around. I am sorry I haven't contributed much to the discussion. I just taught a class on Mayavi and preparing it and teaching it got me out of order for a day and a half. I am time sharing between this project and another one, and the rest of this week will be spent on the other project, so I won't come up with interesting questions or comments, but don't worry, I'll switch back to this next week. Cheers, Ga?l From barrywark at gmail.com Thu Jun 26 23:12:39 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 26 Jun 2008 20:12:39 -0700 Subject: [IPython-dev] frontend plans In-Reply-To: <20080627021212.GA11323@phare.normalesup.org> References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> <20080627021212.GA11323@phare.normalesup.org> Message-ID: On Thu, Jun 26, 2008 at 7:12 PM, Gael Varoquaux wrote: > Hey guys, > > And wanted to thank you very much for hashing down the ideas to get this > working. I have no understanding of the code we are talking about and it > is very valuable to have you around. I am sorry I haven't contributed > much to the discussion. I just taught a class on Mayavi and preparing it > and teaching it got me out of order for a day and a half. > > I am time sharing between this project and another one, and the rest of > this week will be spent on the other project, so I won't come up with > interesting questions or comments, but don't worry, I'll switch back to > this next week. No worries. I'm not likely to get to this in ernest until then either. We can walk blindly into the abyss together :) cheers, barry > > Cheers, > > Ga?l > From barrywark at gmail.com Thu Jun 26 23:18:27 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 26 Jun 2008 20:18:27 -0700 Subject: [IPython-dev] frontend plans In-Reply-To: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> Message-ID: On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger wrote: > Barry, > >>> I think that we could have a single base class that implements the >>> actual frontend logic and then have multiple subclasses that handle >>> the calls to the various types of backends (kernel.core or >>> kernel.engineservice). I need to look more at how the frontend is >>> implemented, but Barry, do you think this would work. >> >> Yes, I think this would work. I thought zope.interface was pure >> python. Since we can't require zope.interface in the stripped-down >> ipython, I now think option 1 is the best approach. I'll work on that. > > Great, I think that will be best, even though it has its own downsides. We're in agreement then. I'll try option 1 and see how that shakes out. > >>> Also, the Synchronous deferred does not present the exact same >>> interface as a true deferred or make the same promises about when >>> things will happen. >> >> What is your understanding of the differences? > > For Deferreds, I think the interface is not a complete specification > of the objects behavior. For Deferreds, there are subtle cases that > arise when you chain them together. The behavior exhibited in complex > Deferred chaining _can_ depend on whether or a given Deferred has > fired or not when the chaining is setup. We have in various places > that handles these odd edge cases. Also, we sometimes access the > semi-private attributes of Deferreds. Another thing is that if you > have multiple unfired Deferreds, the order in which they will fire is > not deterministic. For the synchronous deferreds, I think the > ordering has to be deterministic. But in my mind, this constitues a > different behavior and thus "interface" in the board sense of the > word. > > We might be able to get the synchronous deferreds to work, but I am a > little hesitant to go down that route simply because all of these > things are _super_ subtle and nearly impossible to debug. I see the issues. Too bad; the Twisted universe seems to want to swallow its victims whole. I should have really seen this coming--I've worked on a Cocoa framework that uses OS X's NSOperationQueue to emulate the Twisted reactor/Deferred system. You're exactly right that the Deferred behavior is _very_ complicated when you dig into it. Oh, well. As long as we're willing to skip the engineservice layer for synchronous interface to core, it's not an issue and we can forget about Synchronous Deferreds. > >> Thus, I my mind, the new IEngineCore >>> implementation _couldn't_ possible really implement the interface. In >>> fact, if I remember correctly, we have a test that can be run on any >>> IEngineCore implementer. It actually calls all the methods of the >>> interface and checks: >>> >>> self.assert_(isinstance(return_value, t.i.Deferred) >>> >>> A fake deferred won't pass such tests. >> >> I don't think this is an appropriate test then. The interface should >> specify the behavior of the returned object, not its implementation. >> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred, >> then it should pass the test. The fact that it may not behave the same >> is a bigger issue. > > True, I could write a better test for this. The current test is only > a super weak test behavior wise, but given the fact that there are no > other objects that truly act like a Deferred, the test suffices. > >>> >>> So, in summary, I think more discussion is needed before commiting to >>> #2. I am crazy busy, but I will try to have a look at IFrontEnd >>> tonight. >> >>> >>> >>>> Since the IEngine* interface is much more stable than the IFrontEnd >>>> interface, I propose going with solution #2. Although it adds an >>>> additional python file as external dependency, it seems conceptually >>>> cleaner (all frontends go through the engine interface) and allows >>>> frontends to decide between synchronous and asynchronous behavior >>>> without any code changes. >>> >>> I think it is conceptually convoluted because the only significant way >>> that IEngireCore different from the underlying core is that its >>> methods return deferreds (and Failures). Thus to use IEngineCore, but >>> then try to get rid of the (true) Deferreds by using fake ones seems >>> like double work (why not just call the class whose methods don't >>> return deferreds in the first place). >> >> It feels weird that there are two ways to interact with ipython?engine >> and core directly. It seemed that making a common interface was >> cleaner in that it allowed users of that interface to be able to use >> engine or core without modification of the frontend. Since that's not >> really an option anymore (because of zope.interface), I'm happy to >> give up that opinion and move on. > > I do sort of agree with this, but I think having two interfaces is > appropriate because they have vastly different behaviors (synchronous > vs asynchronous). Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core is still the 'real' IPython. I.kernel is just a Twised wrapper around that core. Naturally anything that doesn't want what Twisted has to offer should talk directly with I.kernel.core and the price they pay is that they loose all the goodies that come with the I.kernel layer. Now that I just wrote this out, it seems wrong that I.kernel.core is a subpackage of I.kernel. I know that it's there to isolate the ipython1 stuff from ipython0 stuff, but before too many people start writing code using I.kernel.core, is it worth discussing if there's a better spot for it in the IPython tree? > >>> Actually, I think we are in agreement that tab completion (the part >>> that actually looks up things in the users namespace) needs to be done >>> in the engine/core through its complete method. There is just no way >>> it is reasonable to mirror the user_ns in the frontend for the reasons >>> you mention. Sorry if we have said anything confusion on this front. >>> So I guess the complete method of the frontend should just call the >>> complete method of the engine/core? >> >> Yes. I agree. frontend.complete() calls engine/core.complete(). > > Cool, > > Cheers, > > Brian > >>> >>> Cheers, >>> >>> Brian >>> >>>> Barry >>>> >>>> [1] Removing the Twisted dependence completely will require moving the >>>> IEngine* interfaces to a separate module from the implementations. I >>>> propose moving them to IPython.kernel.engineinterface.py. >>>> _______________________________________________ >>>> 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 Jun 26 23:31:19 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 26 Jun 2008 21:31:19 -0600 Subject: [IPython-dev] frontend plans In-Reply-To: References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> Message-ID: <6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com> On Thu, Jun 26, 2008 at 9:18 PM, Barry Wark wrote: > On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger wrote: >> Barry, >> >>>> I think that we could have a single base class that implements the >>>> actual frontend logic and then have multiple subclasses that handle >>>> the calls to the various types of backends (kernel.core or >>>> kernel.engineservice). I need to look more at how the frontend is >>>> implemented, but Barry, do you think this would work. >>> >>> Yes, I think this would work. I thought zope.interface was pure >>> python. Since we can't require zope.interface in the stripped-down >>> ipython, I now think option 1 is the best approach. I'll work on that. >> >> Great, I think that will be best, even though it has its own downsides. > > We're in agreement then. I'll try option 1 and see how that shakes out. > >> >>>> Also, the Synchronous deferred does not present the exact same >>>> interface as a true deferred or make the same promises about when >>>> things will happen. >>> >>> What is your understanding of the differences? >> >> For Deferreds, I think the interface is not a complete specification >> of the objects behavior. For Deferreds, there are subtle cases that >> arise when you chain them together. The behavior exhibited in complex >> Deferred chaining _can_ depend on whether or a given Deferred has >> fired or not when the chaining is setup. We have in various places >> that handles these odd edge cases. Also, we sometimes access the >> semi-private attributes of Deferreds. Another thing is that if you >> have multiple unfired Deferreds, the order in which they will fire is >> not deterministic. For the synchronous deferreds, I think the >> ordering has to be deterministic. But in my mind, this constitues a >> different behavior and thus "interface" in the board sense of the >> word. >> >> We might be able to get the synchronous deferreds to work, but I am a >> little hesitant to go down that route simply because all of these >> things are _super_ subtle and nearly impossible to debug. > > I see the issues. Too bad; the Twisted universe seems to want to > swallow its victims whole. I should have really seen this coming--I've > worked on a Cocoa framework that uses OS X's NSOperationQueue to > emulate the Twisted reactor/Deferred system. You're exactly right that > the Deferred behavior is _very_ complicated when you dig into it. Oh, > well. As long as we're willing to skip the engineservice layer for > synchronous interface to core, it's not an issue and we can forget > about Synchronous Deferreds. > >> >>> Thus, I my mind, the new IEngineCore >>>> implementation _couldn't_ possible really implement the interface. In >>>> fact, if I remember correctly, we have a test that can be run on any >>>> IEngineCore implementer. It actually calls all the methods of the >>>> interface and checks: >>>> >>>> self.assert_(isinstance(return_value, t.i.Deferred) >>>> >>>> A fake deferred won't pass such tests. >>> >>> I don't think this is an appropriate test then. The interface should >>> specify the behavior of the returned object, not its implementation. >>> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred, >>> then it should pass the test. The fact that it may not behave the same >>> is a bigger issue. >> >> True, I could write a better test for this. The current test is only >> a super weak test behavior wise, but given the fact that there are no >> other objects that truly act like a Deferred, the test suffices. >> >>>> >>>> So, in summary, I think more discussion is needed before commiting to >>>> #2. I am crazy busy, but I will try to have a look at IFrontEnd >>>> tonight. >>> >>>> >>>> >>>>> Since the IEngine* interface is much more stable than the IFrontEnd >>>>> interface, I propose going with solution #2. Although it adds an >>>>> additional python file as external dependency, it seems conceptually >>>>> cleaner (all frontends go through the engine interface) and allows >>>>> frontends to decide between synchronous and asynchronous behavior >>>>> without any code changes. >>>> >>>> I think it is conceptually convoluted because the only significant way >>>> that IEngireCore different from the underlying core is that its >>>> methods return deferreds (and Failures). Thus to use IEngineCore, but >>>> then try to get rid of the (true) Deferreds by using fake ones seems >>>> like double work (why not just call the class whose methods don't >>>> return deferreds in the first place). >>> >>> It feels weird that there are two ways to interact with ipython?engine >>> and core directly. It seemed that making a common interface was >>> cleaner in that it allowed users of that interface to be able to use >>> engine or core without modification of the frontend. Since that's not >>> really an option anymore (because of zope.interface), I'm happy to >>> give up that opinion and move on. >> >> I do sort of agree with this, but I think having two interfaces is >> appropriate because they have vastly different behaviors (synchronous >> vs asynchronous). > > Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core > is still the 'real' IPython. I.kernel is just a Twised wrapper around > that core. Naturally anything that doesn't want what Twisted has to > offer should talk directly with I.kernel.core and the price they pay > is that they loose all the goodies that come with the I.kernel layer. > Now that I just wrote this out, it seems wrong that I.kernel.core is a > subpackage of I.kernel. I know that it's there to isolate the ipython1 > stuff from ipython0 stuff, but before too many people start writing > code using I.kernel.core, is it worth discussing if there's a better > spot for it in the IPython tree? Yes, probably. I had originally thoughts about moving it to IPython.core. But the problem with that is I am afraid that it suggests that it is a complete and working core. My plan originally was thus: 1. Move the old core IPython.*.py -> IPython.core.*.py 2. Refactor that stuff until it looks more like IPython.kernel.core 3. At that point, get rid of IPython.kernel.core But maybe the better approach is: 1. Just move IPython.kernel.core -> IPython.core 2. Also move IPython.*.py -< IPython.core 3. Refactor/combine the two inplace What do you think? This probably needs more disucssion in a separate thread on the list. Cheers, Brian >> >>>> Actually, I think we are in agreement that tab completion (the part >>>> that actually looks up things in the users namespace) needs to be done >>>> in the engine/core through its complete method. There is just no way >>>> it is reasonable to mirror the user_ns in the frontend for the reasons >>>> you mention. Sorry if we have said anything confusion on this front. >>>> So I guess the complete method of the frontend should just call the >>>> complete method of the engine/core? >>> >>> Yes. I agree. frontend.complete() calls engine/core.complete(). >> >> Cool, >> >> Cheers, >> >> Brian >> >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>>> Barry >>>>> >>>>> [1] Removing the Twisted dependence completely will require moving the >>>>> IEngine* interfaces to a separate module from the implementations. I >>>>> propose moving them to IPython.kernel.engineinterface.py. >>>>> _______________________________________________ >>>>> IPython-dev mailing list >>>>> IPython-dev at scipy.org >>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>>>> >>>> >>> >> > From barrywark at gmail.com Thu Jun 26 23:38:25 2008 From: barrywark at gmail.com (Barry Wark) Date: Thu, 26 Jun 2008 20:38:25 -0700 Subject: [IPython-dev] Moving IPython.kernel.core Message-ID: Brian and I thought it would be good to bring this discussion to everyone's attention, separate from the frontend plans. Below is the entire thread, but I've copied the relevant bits just here: >> It seems wrong that I.kernel.core is a >> subpackage of I.kernel. I know that it's there to isolate the ipython1 >> stuff from ipython0 stuff, but before too many people start writing >> code using I.kernel.core, is it worth discussing if there's a better >> spot for it in the IPython tree? > > Yes, probably. I had originally thoughts about moving it to > IPython.core. But the problem with that is I am afraid that it > suggests that it is a complete and working core. My plan originally > was thus: > > 1. Move the old core IPython.*.py -> IPython.core.*.py > > 2. Refactor that stuff until it looks more like IPython.kernel.core > > 3. At that point, get rid of IPython.kernel.core > > But maybe the better approach is: > > 1. Just move IPython.kernel.core -> IPython.core > > 2. Also move IPython.*.py -< IPython.core > > 3. Refactor/combine the two inplace > > What do you think? This probably needs more disucssion in a separate > thread on the list. Since I don't have any significant code that depends on ipython0, I'd vote for 1. Move IPython.kernel.core -> IPython.core 2. Move IPython.*.py -> IPython.old_core 3. Deprecate IPython.old_core as soon as IPython.core is capable of replacing ipython0 I'm sure others who have legacy code that depends on ipython0 will have an opinion... Barry On Thu, Jun 26, 2008 at 8:31 PM, Brian Granger wrote: > On Thu, Jun 26, 2008 at 9:18 PM, Barry Wark wrote: >> On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger wrote: >>> Barry, >>> >>>>> I think that we could have a single base class that implements the >>>>> actual frontend logic and then have multiple subclasses that handle >>>>> the calls to the various types of backends (kernel.core or >>>>> kernel.engineservice). I need to look more at how the frontend is >>>>> implemented, but Barry, do you think this would work. >>>> >>>> Yes, I think this would work. I thought zope.interface was pure >>>> python. Since we can't require zope.interface in the stripped-down >>>> ipython, I now think option 1 is the best approach. I'll work on that. >>> >>> Great, I think that will be best, even though it has its own downsides. >> >> We're in agreement then. I'll try option 1 and see how that shakes out. >> >>> >>>>> Also, the Synchronous deferred does not present the exact same >>>>> interface as a true deferred or make the same promises about when >>>>> things will happen. >>>> >>>> What is your understanding of the differences? >>> >>> For Deferreds, I think the interface is not a complete specification >>> of the objects behavior. For Deferreds, there are subtle cases that >>> arise when you chain them together. The behavior exhibited in complex >>> Deferred chaining _can_ depend on whether or a given Deferred has >>> fired or not when the chaining is setup. We have in various places >>> that handles these odd edge cases. Also, we sometimes access the >>> semi-private attributes of Deferreds. Another thing is that if you >>> have multiple unfired Deferreds, the order in which they will fire is >>> not deterministic. For the synchronous deferreds, I think the >>> ordering has to be deterministic. But in my mind, this constitues a >>> different behavior and thus "interface" in the board sense of the >>> word. >>> >>> We might be able to get the synchronous deferreds to work, but I am a >>> little hesitant to go down that route simply because all of these >>> things are _super_ subtle and nearly impossible to debug. >> >> I see the issues. Too bad; the Twisted universe seems to want to >> swallow its victims whole. I should have really seen this coming--I've >> worked on a Cocoa framework that uses OS X's NSOperationQueue to >> emulate the Twisted reactor/Deferred system. You're exactly right that >> the Deferred behavior is _very_ complicated when you dig into it. Oh, >> well. As long as we're willing to skip the engineservice layer for >> synchronous interface to core, it's not an issue and we can forget >> about Synchronous Deferreds. >> >>> >>>> Thus, I my mind, the new IEngineCore >>>>> implementation _couldn't_ possible really implement the interface. In >>>>> fact, if I remember correctly, we have a test that can be run on any >>>>> IEngineCore implementer. It actually calls all the methods of the >>>>> interface and checks: >>>>> >>>>> self.assert_(isinstance(return_value, t.i.Deferred) >>>>> >>>>> A fake deferred won't pass such tests. >>>> >>>> I don't think this is an appropriate test then. The interface should >>>> specify the behavior of the returned object, not its implementation. >>>> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred, >>>> then it should pass the test. The fact that it may not behave the same >>>> is a bigger issue. >>> >>> True, I could write a better test for this. The current test is only >>> a super weak test behavior wise, but given the fact that there are no >>> other objects that truly act like a Deferred, the test suffices. >>> >>>>> >>>>> So, in summary, I think more discussion is needed before commiting to >>>>> #2. I am crazy busy, but I will try to have a look at IFrontEnd >>>>> tonight. >>>> >>>>> >>>>> >>>>>> Since the IEngine* interface is much more stable than the IFrontEnd >>>>>> interface, I propose going with solution #2. Although it adds an >>>>>> additional python file as external dependency, it seems conceptually >>>>>> cleaner (all frontends go through the engine interface) and allows >>>>>> frontends to decide between synchronous and asynchronous behavior >>>>>> without any code changes. >>>>> >>>>> I think it is conceptually convoluted because the only significant way >>>>> that IEngireCore different from the underlying core is that its >>>>> methods return deferreds (and Failures). Thus to use IEngineCore, but >>>>> then try to get rid of the (true) Deferreds by using fake ones seems >>>>> like double work (why not just call the class whose methods don't >>>>> return deferreds in the first place). >>>> >>>> It feels weird that there are two ways to interact with ipython?engine >>>> and core directly. It seemed that making a common interface was >>>> cleaner in that it allowed users of that interface to be able to use >>>> engine or core without modification of the frontend. Since that's not >>>> really an option anymore (because of zope.interface), I'm happy to >>>> give up that opinion and move on. >>> >>> I do sort of agree with this, but I think having two interfaces is >>> appropriate because they have vastly different behaviors (synchronous >>> vs asynchronous). >> >> Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core >> is still the 'real' IPython. I.kernel is just a Twised wrapper around >> that core. Naturally anything that doesn't want what Twisted has to >> offer should talk directly with I.kernel.core and the price they pay >> is that they loose all the goodies that come with the I.kernel layer. >> Now that I just wrote this out, it seems wrong that I.kernel.core is a >> subpackage of I.kernel. I know that it's there to isolate the ipython1 >> stuff from ipython0 stuff, but before too many people start writing >> code using I.kernel.core, is it worth discussing if there's a better >> spot for it in the IPython tree? > > Yes, probably. I had originally thoughts about moving it to > IPython.core. But the problem with that is I am afraid that it > suggests that it is a complete and working core. My plan originally > was thus: > > 1. Move the old core IPython.*.py -> IPython.core.*.py > > 2. Refactor that stuff until it looks more like IPython.kernel.core > > 3. At that point, get rid of IPython.kernel.core > > But maybe the better approach is: > > 1. Just move IPython.kernel.core -> IPython.core > > 2. Also move IPython.*.py -< IPython.core > > 3. Refactor/combine the two inplace > > What do you think? This probably needs more disucssion in a separate > thread on the list. > > Cheers, > > Brian > >>> >>>>> Actually, I think we are in agreement that tab completion (the part >>>>> that actually looks up things in the users namespace) needs to be done >>>>> in the engine/core through its complete method. There is just no way >>>>> it is reasonable to mirror the user_ns in the frontend for the reasons >>>>> you mention. Sorry if we have said anything confusion on this front. >>>>> So I guess the complete method of the frontend should just call the >>>>> complete method of the engine/core? >>>> >>>> Yes. I agree. frontend.complete() calls engine/core.complete(). >>> >>> Cool, >>> >>> Cheers, >>> >>> Brian >>> >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>>>> Barry >>>>>> >>>>>> [1] Removing the Twisted dependence completely will require moving the >>>>>> IEngine* interfaces to a separate module from the implementations. I >>>>>> propose moving them to IPython.kernel.engineinterface.py. >>>>>> _______________________________________________ >>>>>> 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 Jun 27 01:18:47 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 27 Jun 2008 07:18:47 +0200 Subject: [IPython-dev] Student sponsorship for the SciPy08 conference Message-ID: <20080627051847.GM11323@phare.normalesup.org> We are delighted to announce that the Python Software Foundation has answered our call and is providing sponsoring to the SciPy08 conference. We will use this money to sponsor the registration fees and travel for up to 10 college or graduate students to attend the conference. The PSF did not provide all the founds required for all 10 students and once again Enthought Inc. (http://www.enthought.com) is stepping up to fill in. To apply, please send a short description of what you are studying and why you?d like to attend to info at enthought.com. Please include telephone contact information. Thanks a lot to Travis Vaught from Enthought for bringing this project to a success. Please don't hesitate to forward this announcement to anybody who might be interested. Ga?l, on behalf of the Scipy08 organisation committee SciPy coneference site: http://conference.scipy.org From cohen at slac.stanford.edu Fri Jun 27 05:00:26 2008 From: cohen at slac.stanford.edu (Johann Cohen-Tanugi) Date: Fri, 27 Jun 2008 02:00:26 -0700 Subject: [IPython-dev] Reposting : an issue in replaying logs with profile Message-ID: <4864AC2A.3030004@slac.stanford.edu> hello, my problem below did not get addressed. Can someone help me understand what I am doing wrong? thanks in advance, Johann ------------------- hi there, I am using a very recent bazaar build of ipython and python 2.5. I have the following profile in my IPYTHONDIR: [cohen at jarrett ~]$ more .ipython/ipy_profile_test.py import IPython.ipapi ip = IPython.ipapi.get() ip.ex("print '*****************************************************'") ip.ex("print '* TEST *'") ip.ex("print '*****************************************************'") ip.ex("import os") I then run the following : [cohen at jarrett ~]$ ipython -profile test -log Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : rotate Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: n=5.2 In [2]: os Out[2]: after exiting the session, the log looks like : [cohen at jarrett ~]$ more ipython_log.py #log# Automatic Logger file. *** THIS MUST BE THE FIRST LINE *** #log# DO NOT CHANGE THIS LINE OR THE TWO BELOW #log# opts = Struct({'__allownew': True, 'log': 1, 'logfile': 'ipython_log.py', 'profile': ''}) #log# args = [] #log# It is safe to make manual edits below here. #log#----------------------------------------------------------------------- n=5.2 os That does *not* look good because the 'profile' value is blank, and indeed : [cohen at jarrett ~]$ ipython -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active Replaying log... Loading log file one line at a time... Finished replaying log file The following lines/blocks in file reported errors: os Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: os --------------------------------------------------------------------------- NameError Traceback (most recent call last) /home/cohen/ in () NameError: name 'os' is not defined There was no 'TEST' banner and no importing of os, as anticipated as the profile is not filled in the log. Even more problematic : [cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active Replaying log... Loading log file one line at a time... Finished replaying log file The following lines/blocks in file reported errors: os Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. Here the -profile argument request is not even honored.... If I add test as the profile in the log file, then I get the correct behavior in both cases : [cohen at jarrett ~]$ ipython -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Replaying log... Loading log file one line at a time... Finished replaying log file Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: os Out[1]: In [2]: n Out[2]: 5.2000000000000002 In [3]: Do you really want to exit ([y]/n)? [cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py Activating auto-logging. Current session state plus future input saved. Filename : ipython_log.py Mode : append Output logging : False Raw input log : False Timestamping : False State : active ***************************************************** * TEST * ***************************************************** Replaying log... Loading log file one line at a time... Finished replaying log file Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) Type "copyright", "credits" or "license" for more information. IPython 0.8.4 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. IPython profile: test In [1]: os Out[1]: In [2]: n Out[2]: 5.2000000000000002 So to make a long story short : there is a faulty behavior of the logger that does not correctly save the profile used. I am trying to read the code (Logger.py and ipilib.py seem to be the natural candidates) but if someone finds the correct patch more quickly, I will be happy too :) . cheers, Johann ------------------------------------------------------------------------ From gael.varoquaux at normalesup.org Fri Jun 27 14:24:29 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Fri, 27 Jun 2008 20:24:29 +0200 Subject: [IPython-dev] Scipy08 Paper submission deadline extention to Monday 30th Message-ID: <20080627182429.GH5103@phare.normalesup.org> The deadline for submitting abstracts to the Scipy conference was tonight. In order to give you more time to submit excellent abstracts, the review committee is extending the deadline to Monday (June 30th), and will work hastily to get all of them reviewed in time for the program announcement, on Thursday July 3rd. ---- The SciPy 2008 Conference will be held 21-22 August 2008 at the California Institute of Technology, Pasadena, California. SciPy is a scientific computing package, written in the Python language. It is widely used in research, the industry and academia. The program features tutorials, contributed papers, lightning talks, and bird-of-a-feather sessions. We are soliciting talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics which center around scientific computing using Python. These include applications, teaching, future development directions and research. A collection of peer-reviewed articles will be published as part of the proceedings. Proposals for talks are submitted as extended abstracts. There are two categories of talks: Lightning talks These talks are 10 minutes in duration. An abstract of between 300 and 700 words should describe the topic and motivate its relevance to scientific computing. Lightning talks do not require an accompanying article (although, if submitted, these will still be published). Paper presentations These talks are 35 minutes in duration (including questions). A one page abstract of no less than 500 words (excluding figures and references) should give an outline of the final paper. Papers are due two weeks before the conference, and may be in a formal academic style, or in a more relaxed magazine-style format. If you wish to present a talk at the conference, please create an account on the website http://conference.scipy.org. You may then submit an abstract by logging in, clicking on your profile and following the " Submit an abstract " link. Ga?l, on behalf on the SciPy08 organizing committee. From robert.kern at gmail.com Fri Jun 27 17:04:29 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 27 Jun 2008 16:04:29 -0500 Subject: [IPython-dev] Moving IPython.kernel.core In-Reply-To: References: Message-ID: Barry Wark wrote: > Brian and I thought it would be good to bring this discussion to > everyone's attention, separate from the frontend plans. Below is the > entire thread, but I've copied the relevant bits just here: > >>> It seems wrong that I.kernel.core is a >>> subpackage of I.kernel. I know that it's there to isolate the ipython1 >>> stuff from ipython0 stuff, but before too many people start writing >>> code using I.kernel.core, is it worth discussing if there's a better >>> spot for it in the IPython tree? >> Yes, probably. I had originally thoughts about moving it to >> IPython.core. But the problem with that is I am afraid that it >> suggests that it is a complete and working core. My plan originally >> was thus: >> >> 1. Move the old core IPython.*.py -> IPython.core.*.py >> >> 2. Refactor that stuff until it looks more like IPython.kernel.core >> >> 3. At that point, get rid of IPython.kernel.core >> >> But maybe the better approach is: >> >> 1. Just move IPython.kernel.core -> IPython.core >> >> 2. Also move IPython.*.py -< IPython.core >> >> 3. Refactor/combine the two inplace >> >> What do you think? This probably needs more disucssion in a separate >> thread on the list. > > Since I don't have any significant code that depends on ipython0, I'd vote for > 1. Move IPython.kernel.core -> IPython.core > 2. Move IPython.*.py -> IPython.old_core > 3. Deprecate IPython.old_core as soon as IPython.core is capable of > replacing ipython0 When I started working on IPython.kernel.core, I copied over a bunch of the utilities like InputList. Do we want to change all of the IPython[.old_core].utils to import the duplicated functions from there so we have one copy to modify (and test!)? I ask because I would like to add a feature to InputList. For the curious, I would like to make InputList allow this behavior: In[2:4,6,8] == In[2:4] + In[6] + In[8] -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From robert.kern at gmail.com Fri Jun 27 19:59:38 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 27 Jun 2008 18:59:38 -0500 Subject: [IPython-dev] Replacing the user context with a non-dict Message-ID: In iplib.py, we have this piece of code # Embedded instances require separate global/local namespaces # so they can see both the surrounding (local) namespace and # the module-level globals when called inside another function. if self.embedded: exec code_obj in self.user_global_ns, self.user_ns # Normal (non-embedded) instances should only have a single # namespace for user code execution, otherwise functions won't # see interactive top-level globals. else: exec code_obj in self.user_ns Can we add a hook in here to allow the namespace to be more flexible? For some background: Python 2.4 allows one to use a non-dict mapping for the locals namespace in an exec statement, but a real dict is necessary for the globals. If there is only one namespace, it is considered a globals dict. I would like to replace the namespace with a non-dict mapping to issue notifications when the namespace is changed. If the latter exec statement were changed to always execute in both namespaces (if the shell is not embedded, by default both user_global_ns and user_ns would point to the same dictionary), then I think I could replace user_ns with my non-dict and user_globals_ns with the real dict that underlies my non-dict. This would give me my feature while still avoiding the problem noted in the comment. I've tested this locally. -- 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 Jun 27 21:04:33 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 27 Jun 2008 18:04:33 -0700 Subject: [IPython-dev] Replacing the user context with a non-dict In-Reply-To: References: Message-ID: On Fri, Jun 27, 2008 at 4:59 PM, Robert Kern wrote: > Can we add a hook in here to allow the namespace to be more flexible? For some > background: Python 2.4 allows one to use a non-dict mapping for the locals > namespace in an exec statement, but a real dict is necessary for the globals. If > there is only one namespace, it is considered a globals dict. Sorry I haven't been more responsive, I'm at a conference and the talks have actually been very good :) But the answer is absolutely yes to your request, after the whole context/with discusson with Eric, it became clear that this is something we should support, it just hadn't been done yet. Please just make the lp ipython team membership request so we can add you right away. Cheers, f From fperez.net at gmail.com Sat Jun 28 14:38:02 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 28 Jun 2008 11:38:02 -0700 Subject: [IPython-dev] Win32 IPython1? In-Reply-To: <4865AB18.4040000@uml.edu> References: <48457029.8020401@uml.edu> <48459D9F.9020900@uml.edu> <4864549D.2010407@uml.edu> <48659443.4050109@uml.edu> <4865AB18.4040000@uml.edu> Message-ID: Hi Alex, again, please send these messages on-list, so they get properly archived and others may also help you if I'm not available (I'm at a conference right now). On Fri, Jun 27, 2008 at 8:08 PM, Alex Brown wrote: > I could not find a way to uninstall a module either with setup.py or > easy_install > (http://mail.python.org/pipermail/python-list/2004-December/294789.html) - easy_install and distutils have no automated uninstallation, unfortunately. > I've simply moved ipython1* out of the tree, OK? I can't find anything > other than comment and docstring references to ipython1 after removal. That is OK. Cheers, f From barrywark at gmail.com Sat Jun 28 14:53:59 2008 From: barrywark at gmail.com (Barry Wark) Date: Sat, 28 Jun 2008 11:53:59 -0700 Subject: [IPython-dev] Win32 IPython1? In-Reply-To: References: <48457029.8020401@uml.edu> <48459D9F.9020900@uml.edu> <4864549D.2010407@uml.edu> <48659443.4050109@uml.edu> <4865AB18.4040000@uml.edu> Message-ID: On Sat, Jun 28, 2008 at 11:38 AM, Fernando Perez wrote: > Hi Alex, > > again, please send these messages on-list, so they get properly > archived and others may also help you if I'm not available (I'm at a > conference right now). > > On Fri, Jun 27, 2008 at 8:08 PM, Alex Brown wrote: > >> I could not find a way to uninstall a module either with setup.py or >> easy_install >> (http://mail.python.org/pipermail/python-list/2004-December/294789.html) - > > easy_install and distutils have no automated uninstallation, unfortunately. I believe you can do easy_install -m to effectively uninstall an app that was installed using setuptools (not one that was installed via distutils). The -m (or --multi-version) flag removes the package from the setuptools .pth file, but doesn't remove it from the site-directory. This way, anyone that wants to use it has to explicitly require it from setuptools but everything else will not know it's there. This is one way to have multiple versions of setuptools-installed packages available or to "uninstall" a package without breaking any other packages that depend on that package. > >> I've simply moved ipython1* out of the tree, OK? I can't find anything >> other than comment and docstring references to ipython1 after removal. > > That is OK. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From stefan at sun.ac.za Sat Jun 28 18:43:52 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 29 Jun 2008 00:43:52 +0200 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> Message-ID: <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> 2008/6/26 Fernando Perez : > I think that we only have a small issue, and it's one I'm willing to > ignore from now on: Launchpad (*not* bzr, since bzr viz/log is > faithful to the full history) ignores all but one branch when showing > history, and what it actually shows can change with each commit. When > they improve their display, great, but until then let's just ignore > that point (we're all too busy here to spend time fixing lp). > > But the fact that sometimes one *must* merge is unavoidable with > distributed development: even using a special branch for communicating > with upstream, merges sometimes are unavoidable. Else I'm really > missing something here. The above two paragraphs give a good summary of the "problem" and the solution, which corresponds with my understanding of the situation. Cheers St?fan From vivainio at gmail.com Sun Jun 29 06:02:40 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 29 Jun 2008 13:02:40 +0300 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> Message-ID: <46cb515a0806290302k528a7928nd8a09fcad3ec67b0@mail.gmail.com> On Fri, Jun 27, 2008 at 12:32 AM, Fernando Perez wrote: > Mmh, then there's something I've missed. Because even though I'm > using the two-branch model, one to keep pulling/pushing upstream and > one for local development, I'm *still* getting the same folding issue > when true merging is required. Basically if there's the need for a There is only a short time window when this can happen - between "bzr pull" and "bzr push". Between those operations, you should only do ONE merge operation (from your work branch to the trunk branch). If you get diverged branches error when trying to push, just uncommit until you can pull again (i.e. your local trunk is exact copy of server trunk), then merge from your work branch, commit and push. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' From cournapeau at cslab.kecl.ntt.co.jp Sun Jun 29 22:12:23 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Mon, 30 Jun 2008 11:12:23 +0900 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> Message-ID: <1214791943.7956.33.camel@bbc8> On Sun, 2008-06-29 at 00:43 +0200, St?fan van der Walt wrote: > 2008/6/26 Fernando Perez : > > I think that we only have a small issue, and it's one I'm willing to > > ignore from now on: Launchpad (*not* bzr, since bzr viz/log is > > faithful to the full history) ignores all but one branch when showing > > history, and what it actually shows can change with each commit. When > > they improve their display, great, but until then let's just ignore > > that point (we're all too busy here to spend time fixing lp). > > > > But the fact that sometimes one *must* merge is unavoidable with > > distributed development: even using a special branch for communicating > > with upstream, merges sometimes are unavoidable. Else I'm really > > missing something here. > > The above two paragraphs give a good summary of the "problem" and the > solution, which corresponds with my understanding of the situation. I think the problem is kind of different, actually. At first, I got the same understanding of the issue as you, but I realized later that that's not the problem at all. The 'ugly' history is inherent to bzr way of doing things; as Villo noted, it more a trade off than a weakness of bzr. bzr emphasizes the current branch (mainline) as special. That's the fundamental difference between bzr and hg/git here. In git and hg, what happens when you merge a branch is that you 'append' the new revisions to the DAG. It means you have a flat log, and you can see every commit at the same level: /------B ----- C ------\ A - -----> merge -> F \------D ------ E -----/ Here is what you get with git (and hg, too, I think; I am more into git ATM, for an alternative to hg): commit a1effecf343bb69e931670eedf3e68c1b6e135b6 Merge: be91f09... 0745401... Author: David Cournapeau Date: Mon Jun 30 10:35:27 2008 +0900 Merge branch 'b1' into b2 commit be91f099bb570f381bb79d6091f7453cac05c857 Author: David Cournapeau Date: Mon Jun 30 10:35:13 2008 +0900 Commit E. commit 0745401f2601c0595e294f3cb29f58c94b57292f Author: David Cournapeau Date: Mon Jun 30 10:35:00 2008 +0900 Commit C. commit da6b022593196cf15b9491b23efad3003f6a60fe Author: David Cournapeau Date: Mon Jun 30 10:34:36 2008 +0900 commit D commit 1a1b17e4b48861b3d29b184d9ea65736a8a4ed30 Author: David Cournapeau Date: Mon Jun 30 10:33:44 2008 +0900 Commit B commit 66bfd488a0848e10e677eba2c26a56e02413b686 Author: David Cournapeau Date: Mon Jun 30 10:32:47 2008 +0900 Commit A With bzr, you have something quite different: ------------------------------------------------------------ revno: 4 committer: David Cournapeau branch nick: b1 timestamp: Mon 2008-06-30 10:39:49 +0900 message: Merge b2. ------------------------------------------------------------ revno: 1.1.2 committer: David Cournapeau branch nick: b2 timestamp: Mon 2008-06-30 10:39:27 +0900 message: Commit E. ------------------------------------------------------------ revno: 1.1.1 committer: David Cournapeau branch nick: b2 timestamp: Mon 2008-06-30 10:38:57 +0900 message: Commit D. ------------------------------------------------------------ revno: 3 committer: David Cournapeau branch nick: b1 timestamp: Mon 2008-06-30 10:39:13 +0900 message: Commit C. ------------------------------------------------------------ revno: 2 committer: David Cournapeau branch nick: b1 timestamp: Mon 2008-06-30 10:38:30 +0900 message: Commit B. ------------------------------------------------------------ revno: 1 committer: David Cournapeau branch nick: trunk timestamp: Mon 2008-06-30 10:37:56 +0900 message: Commit A. The 'ugly' history, to use Fernando's words. The difference: - the log does look confusing if you are used to git/hg - you can *not* have a flat log ala git/hg, contrary to what I thought previously. I was confused by the description of some bzr developers, when they mentioned merge --pull. It is actually not really useful, and does not do what git/hg do at all when you merge. Better forget it, I think. - but this has a nice property: at any revision of the mainline, the tree is in a workable state. In bzr development itself, the merge to the mainline are not done manually, but through a gatekeeper: in particular, the merge will be refused if it does not pass the test suite. You cannot do that with git/hg I think (at least not as naturally). bzr developers call this the merge-review-commit workflow. Honestly, I don't really see the problem with the code browsing on launchpad: I just never use it and don't see a big use for it. Since now you have the whole history, what's the point (as a regular developer, at least, that is if you have the branch on your computer) ? Having the DAG displayed would be much better, yes. But since again, you can do it locally (bzr visualize)... The problem is more the availability of those tools on non free OS (windows and mac os X). Concerning history folding, it can become really ugly when you work on several branches at the same time and need to merge one from the other (typically, I encountered this in the following quite usual scenario: start a feature branch, then see a bug in this branch, fix the bug in another branch, and then merge the fix into mainline and merge mainline into feature branch). You can do with rebase, but it does not work that well with bzr (I think this is because contrary to git, which essentially guesses everything, bzr uses a lot of meta-data; again, this has advantages and disadvantages); and rebase has its own problem, too. There is no win-win scenario that I am aware of. I think what Brian said is really important (you never the nice things of the tools you are using, you never see the bad things of the tools you are not using). The only way is to use the tools on a daily basis. cheers, David From stefan at sun.ac.za Mon Jun 30 02:06:34 2008 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 30 Jun 2008 08:06:34 +0200 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <1214791943.7956.33.camel@bbc8> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> <1214791943.7956.33.camel@bbc8> Message-ID: <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com> 2008/6/30 David Cournapeau : > bzr emphasizes the current branch (mainline) as special. That's the > fundamental difference between bzr and hg/git here. In git and hg, what > happens when you merge a branch is that you 'append' the new revisions > to the DAG. It means you have a flat log, and you can see every commit > at the same level: > > /------B ----- C ------\ > A - -----> merge -> F > \------D ------ E -----/ Knowing that bzr preserves the mainline, looks like you did: /------B ----- C -------.------> merge -> F A - / \------D ------ E ------/ Otherwise you get something like: ------------------------------------------------------------ revno: 2 committer: Stefan van der Walt branch nick: bzrtest timestamp: Mon 2008-06-30 07:25:43 +0200 message: Merge dev branches. ------------------------------------------------------------ revno: 1.2.2 committer: Stefan van der Walt branch nick: bzrtest1 timestamp: Mon 2008-06-30 07:24:39 +0200 message: C ------------------------------------------------------------ revno: 1.2.1 committer: Stefan van der Walt branch nick: bzrtest1 timestamp: Mon 2008-06-30 07:24:31 +0200 message: B ------------------------------------------------------------ revno: 1.1.2 committer: Stefan van der Walt branch nick: bzrtest2 timestamp: Mon 2008-06-30 07:24:57 +0200 message: E ------------------------------------------------------------ revno: 1.1.1 committer: Stefan van der Walt branch nick: bzrtest2 timestamp: Mon 2008-06-30 07:24:50 +0200 message: D ------------------------------------------------------------ revno: 1 committer: Stefan van der Walt branch nick: bzrtest timestamp: Mon 2008-06-30 07:22:17 +0200 message: A (I just merged both branches at the same time) `pull` and `push` should only be used when you want to create an exact copy of another branch. It has the effect of flattening out the log, so I'd imagine it is a bad idea to "force" through merges that way. > Concerning history folding, it can become really ugly when you work on > several branches at the same time and need to merge one from the other > (typically, I encountered this in the following quite usual scenario: > start a feature branch, then see a bug in this branch, fix the bug in > another branch, and then merge the fix into mainline and merge mainline > into feature branch). You can do with rebase, but it does not work that > well with bzr (I think this is because contrary to git, which > essentially guesses everything, bzr uses a lot of meta-data; again, this > has advantages and disadvantages); and rebase has its own problem, too. > There is no win-win scenario that I am aware of. Do you know whether other systems try to work around this, and how they do it? Here is what I see under bzr: $ bzr log ------------------------------------------------------------ revno: 3 committer: Stefan van der Walt branch nick: bzrtest timestamp: Mon 2008-06-30 07:55:32 +0200 message: Merge changes from interface branch into mainline. ------------------------------------------------------------ revno: 1.2.3 committer: Stefan van der Walt branch nick: bzrtest_interface timestamp: Mon 2008-06-30 07:55:14 +0200 message: Make some more changes to the interface branch. ------------------------------------------------------------ revno: 1.2.2 committer: Stefan van der Walt branch nick: bzrtest_interface timestamp: Mon 2008-06-30 07:54:33 +0200 message: Merge changes from mainline with the interface branch. ------------------------------------------------------------ revno: 1.2.1 committer: Stefan van der Walt branch nick: bzrtest_interface timestamp: Mon 2008-06-30 07:54:06 +0200 message: Checkin to improve the calculator interface. Branch: interface. ------------------------------------------------------------ revno: 2 committer: Stefan van der Walt branch nick: bzrtest timestamp: Mon 2008-06-30 07:53:24 +0200 message: Merge in calculator engine fixes into "mainline". ------------------------------------------------------------ revno: 1.1.1 committer: Stefan van der Walt branch nick: bzrtest_addition timestamp: Mon 2008-06-30 07:53:10 +0200 message: Fix addition in calculator. Branch: addition. ------------------------------------------------------------ revno: 1 committer: Stefan van der Walt branch nick: bzrtest timestamp: Mon 2008-06-30 07:52:31 +0200 message: Project root is here. It is a fake pocket calculator. I don't see any history folding as such; I *do* see a log message saying that I committed changes from the main branch into the addition branch, but those changes *themselves* were not re-merged with mainline. > I think what Brian said is really important (you never the nice things > of the tools you are using, you never see the bad things of the tools > you are not using). The only way is to use the tools on a daily basis. That's true. I am trying to understand these issues, so that I can tell whether the "bad things" I see are due to the tool or my abuse of it. Cheers St?fan From cournapeau at cslab.kecl.ntt.co.jp Mon Jun 30 02:55:03 2008 From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau) Date: Mon, 30 Jun 2008 15:55:03 +0900 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> <1214791943.7956.33.camel@bbc8> <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com> Message-ID: <1214808903.7956.54.camel@bbc8> On Mon, 2008-06-30 at 08:06 +0200, St?fan van der Walt wrote: > > Knowing that bzr preserves the mainline, looks like you did: > > /------B ----- C -------.------> merge -> F > A - / > \------D ------ E ------/ > Yes, I merged D/E into the top branch in both git and bzr cases, I should have been clearer here. > > `pull` and `push` should only be used when you want to create an exact > copy of another branch. It has the effect of flattening out the log, > so I'd imagine it is a bad idea to "force" through merges that way. I don't think it is right to see pull as "flattening" the log. That's what I thought first too, but it is wrong. In particular, in the case above, it is not possible to get a flat log in bzr (wo using rebase, that is). > > Do you know whether other systems try to work around this, and how they do it? git does not have a mainline concept at all. It is just a DAG at both implementation and UI levels, and the log is just time-sorted as far as I understand (contrary to bzr where the log is topologically sorted, which is one of the reason why it is much slower, BTW). If you look at git output, there is only one indentation, whatever the branch a commit is coming from. Git does not work around this, because they don't need to: there is not version in git, just the sha-1 of each commit. Contrary to version, sha-1 does not have any order concept. What happens a lot in git is the use of rebase, that is changing the order of the commits of a branch, to make the history 'nicer'. But you have to be careful when using rebase because obviously, since you cut/paste in the DAG, once the branch is published, other people cannot depend on your branch if you rebase. See for example: http://kerneltrap.org/Linux/Git_Management Another solution, albeit with a different purpose, is the patchqueue concept (loom in bzr, mercurial queues in hg, I don't know in git), but I still haven't got my head around this one properly to really talk about it. > I don't see any history folding as such; I *do* see a log message > saying that I committed changes from the main branch into the addition > branch, but those changes *themselves* were not re-merged with > mainline. Maybe I don't understand exactly what Fernando meant by history folding, then. For me, the above log is a typical example of history folding, because you have two levels of log (one for the mainline, one for the merged branch). cheers, David From fperez.net at gmail.com Mon Jun 30 18:12:40 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 30 Jun 2008 15:12:40 -0700 Subject: [IPython-dev] Python/Sage minisymposium at SIAM Annual meeting July 9/10 2008 Message-ID: Hi all, this is just a reminder, in case you'll be attending the SIAM 2008 annual meeting next week in San Diego, that there will be a 3-part minisymposium focusing on the uses of Python and Sage in scientific computing: http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447 We hope to see many of you there! Regards, Fernando and Randy From fperez.net at gmail.com Mon Jun 30 19:00:16 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 30 Jun 2008 16:00:16 -0700 Subject: [IPython-dev] Bazaar on OS X In-Reply-To: <1214808903.7956.54.camel@bbc8> References: <200806251414.26194.hans_meine@gmx.net> <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com> <200806261341.14255.hans_meine@gmx.net> <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com> <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com> <1214791943.7956.33.camel@bbc8> <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com> <1214808903.7956.54.camel@bbc8> Message-ID: Howdy, > Maybe I don't understand exactly what Fernando meant by history folding, > then. For me, the above log is a typical example of history folding, > because you have two levels of log (one for the mainline, one for the > merged branch). I just meant the fact that lp only shows the 'mainline' in its history view, and what mainline is shown actually changes depending on who does the last push. The last person to merge and push gets 'his' view of the world to appear in lp's view. We've seen that type of change very frequently already, but I've just decided to ignore that 'feature' of lp and move on. Otherwise ipython-dev is going to turn into a parallel version of bzr/lp-dev :) Cheers, f From fperez.net at gmail.com Mon Jun 30 20:37:44 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 30 Jun 2008 17:37:44 -0700 Subject: [IPython-dev] frontend plans In-Reply-To: <6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com> References: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com> <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com> <6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com> Message-ID: Hey folks, I'm sorry that I failed to respond during this thread, but as it happened I was at a conference with only micro-breaks for 'easy' emails, but not to digest all of this :) Having said that, here are a few thoughts on what has been said so far: - Gael: as Brian asked, what are your design parameters regarding GUI blocking? If you put the exec calls in a thread (like ipython -Xthread does) you have some hope of interface responsiveness, if you put them in a process you get full GUI responsiveness at the cost of other complexities. Are you OK with a non-responsive GUI while exec() is busy? - Zope interfaces: what do they exactly bring us? Nose uses interfaces in a non-enforcing way by making them pure python classes that are meant to document behavior but *not* to be subclassed. Perhaps we could have something similar for the pure python version and then a ZI version for the rest of the twisted layer: class BasicInterface(object): def foo(self,x,y): """does z with x and y""" raise NotImplementedError() class RealInterface(BasicInterface,zope.interfaces.whatever): pass Code NOT using twisted would inherit from the first type of functions, and all twisted-based code would inherit from the second. - basic observation: exec() is fundamentally a blocking primitive. At the end of the day, you have to wait for that particular chunk of code to finish, and that's the python interpreter itself you're waiting for. For this reason, it makes sense that the lowest level abstractions we have should be blocking, and asynchronous interfaces are wrapped around those for systems that are 'removed' from this execution core (by being out of process, in another computer, etc). Yes, I know that exec() could be calling threaded code, but that simply means that exec(x) can finish quickly and some of the results will be ready later. But the overall operation of completing the execution of 'x' is still a blocking one. - Because of the above, I'm not crazy about the whole "synchronous deferred" use. In my mind, the logical containment chain is: (0 - python VM - fundamentally synchronous object) < (1 - Ipython layer that manages this) < (2 - Asynchronous wrappers for systems that will work out of process, over the network, etc). - Tab completion: this is just one case of the more generic case of how to represent out-of-process information. We have to assume that in general, only the core has true access to the real in-memory objects of the user's namespace. Clients may request information about this for display purposes, and some communication of reduced data may happen with such clients, but we can't expect to copy the user's namespace across the wire in a general sense. So yes, tab completion and similar introspection will always happen by clients requesting the operation on the core, and the core sending back something reasonable back (a list of strings, for example). In summary: it seems from what Barry said in the end, as well as Gael, that we're all happy with the notion of a core, blocking system that ultimately is just a bells-and-whistles version of python's "exec code in namespace" statement. It lets you manage that namespace, introspect it, it offers extensions, history, etc, but ultimately it's just wrapping that one single statement. Because that statement *fundamentally* blocks, this system blocks. You can embed it in a GUI or use it in a terminal, but it still blocks. Beyond that, it makes sense to wrap this in a Twisted layer that turns the result of exec() into a deferred. This makes complete sense when the process doing exec() is different than your own (gui, network, etc) and you actively want to move on with your life, while having a notification mechanism for handling results/errors arising from the exec call. At this point, the Twisted callback/errback system seems well tailored for this. And I certainly want to ensure that Gael finds the code that's in there sufficient for him to use in his WX project. It seems to me that's the case, but have we left any question unanswered on that front? Cheers, f From fperez.net at gmail.com Mon Jun 30 20:41:08 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 30 Jun 2008 17:41:08 -0700 Subject: [IPython-dev] Reposting : an issue in replaying logs with profile In-Reply-To: <4864AC2A.3030004@slac.stanford.edu> References: <4864AC2A.3030004@slac.stanford.edu> Message-ID: Hi Jonathan, On Fri, Jun 27, 2008 at 2:00 AM, Johann Cohen-Tanugi wrote: > hello, > my problem below did not get addressed. Can someone help me understand > what I am doing wrong? I'm sorry if it appears we're ignoring you: this is a bit of a subtle problem and noone has simply had the time to dig into it. If you do come up with a patch, great! Else, please file it as an actual bug report so we don't forget it. All the 'core' people are right now knee deep in the huge amount of work that the merge is bringing upon us, so there's a good chance an issue like this may go unattended for longer than we'd like. I hope that once the dust settles and our merged codes are functioning, we could start scheduling a few bug days as part of our release plans. One more reason to encourage you to file it on LP, even if we don't act on it right away. If you do figure out a fix/patch, by all means send it in! Cheers, f