From fperez.net at gmail.com Thu Apr 8 21:11:16 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 8 Apr 2010 18:11:16 -0700 Subject: [IPython-dev] GSoc Ideas Message-ID: Hi all, rather in the nick of time, but a couple of students have been working on proposals to work off the recent zmq effort as part of this year's gsoc program. The scipy server conveniently has been very flaky today, so the versions on the wiki are a bit old: http://ipython.scipy.org/moin/GSoC2010/IPythonQt http://ipython.scipy.org/moin/GSoC2010/IPythonZmq but the work-in-progress is in Google docs: https://docs.google.com/Doc?docid=0AYxL328I15VNZGhjdGo4OGJfNThmMm54bTljcg&hl=en https://docs.google.com/Doc?docid=0Abqq0nDYtAPSZGdjOGpjZGZfMTNndDJtem5oYw&hl=en Feedback/ideas welcome (even if it's unfortunately kind of late..) Cheers, f From muzgash.lists at gmail.com Fri Apr 9 01:09:10 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Fri, 9 Apr 2010 00:09:10 -0500 Subject: [IPython-dev] Qt/Curses interfaces future: results of the weekend mini-sprint (or having fun with 0mq) In-Reply-To: References: <12aaa0811003242015l7d758507h7d04d9df4587c28d@mail.gmail.com> <12aaa0811003251116u5a729d87t19f8112769b73f58@mail.gmail.com> Message-ID: Hi all. We Gerardo and Omar, (two of the new developers of ipython) are applying for GSoC this year with some of the projects mentioned here. So we ask you to please send us some feedback about the proposals linked below so we have a better chance to participate and also to have a better understanding of what do you want to see on these projects. http://ipython.scipy.org/moin/GSoC2010/IPythonZmq http://ipython.scipy.org/moin/GSoC2010/IPythonQt The deadline for student application is apr 9, 19GMT, sorry for the delay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Apr 12 00:16:46 2010 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 11 Apr 2010 23:16:46 -0500 Subject: [IPython-dev] In-place %editing of methods Message-ID: It just occurred to me that someone could write a very useful magic for editing methods and functions in-place. The following is a loose sketch to record my thoughts in public. Workflow: You think you have a problem with a particular method. You use Foo.bar?? to view its source. You realize that you need a print statement somewhere in there. What to do?! Solution: %inplace Foo.bar This will inspect the source for just the method and open it in your editor. When you are finished, it will create a new module object with an ad hoc name (maybe inplace_.py) with a corresponding fake entry in the linecache for tracebacks and future %inplaces. The globals dict is populated with the entries from the method object's globals dict (.im_func.func_globals) in order to ensure that you have the appropriate global referents (be sure to fix the __file__ entry to the ad hoc name). If the new function needs extra imports or other module-level functions, that's fine (untested). No new methods, though. Execute the code in this module's namespace. Extract the function object by name. If the original is a method, look up the class and assign the new function object to it. If the original is a function, look up the module and assign it. None of this is particularly difficult or problematic. Only when you need to edit whole classes and adjust living objects to use the new type do you run into difficulties. There are solutions on PyPI, but they are larger and more error-prone than we probably care for. %inplace should keep a record of these modifications. Many of them are going to be throwaway debugging things, but some will be genuine modifications that should be propagated into the actual source code. A SQLite database in ~/.ipython/ is a nice, robust location to keep them. Upon exit, IPython should print out the final versions of the modified functions. Additionally, you can have a couple of --options for %inplace that let you view/clean up the database instead of editing something. For bonus points, generate a unified diff against the actual files. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From fperez.net at gmail.com Mon Apr 12 14:13:40 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Apr 2010 11:13:40 -0700 Subject: [IPython-dev] In-place %editing of methods In-Reply-To: References: Message-ID: On Sun, Apr 11, 2010 at 9:16 PM, Robert Kern wrote: > It just occurred to me that someone could write a very useful magic for editing > methods and functions in-place. The following is a loose sketch to record my > thoughts in public. Thanks, great idea. Filed for tracking: https://bugs.launchpad.net/ipython/+bug/561693 Cheers, f From fperez.net at gmail.com Mon Apr 12 16:21:38 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 12 Apr 2010 13:21:38 -0700 Subject: [IPython-dev] GSoC applicants: patch and blog required Message-ID: Hi folks, this is mostly for the gsoc applicants, but I want to make sure that soc communications are, within reason, always managed on the dev list (if nothing else, it serves as a record for future years of the process). Please note a few important points from the application page: http://wiki.python.org/moin/SummerOfCode/Application Specifically, it says """ Even if you haven't worked on anything before this, please engage with the project you're proposing to work on and submitting some kind of patch (minor code patch, documentation patch, etc.) showing that you can work through the technical issues necessary to contribute. Applicants that do this will be prioritized over those that don't. """ Since the gsoc proposals are actually pieces of the development plan for IPython, you can fulfill this requirement by submitting a branch for merge review that has your proposal as a development document. I would suggest that you make a different document each (so you don't step on each other with version control), in the development section of the documentation. Make sure the docs build in html and pdf before submitting the branch for review. Note that if you don't do this *soon*, there's a very good chance your application will not get a good score in the final evaluation process, as all applicants are expected to have submitted some small contribution to their project. You already have written up most of it, so it should be just a matter of creating it as a doc in the sphinx tree and making sure things build, we'll review it by simply branching from you, doing make html && make pdf in the docs directory and ensuring the resulting document contains the full proposal. Feedback will be done as a regular branch review on launchpad. Also note that the page says: - include a blog URL So please do get a blog started up for this. This page has the rest of the expectations from the Python software foundation for students, so give it a good read because if your proposal is accepted, this is the standard you'll have to meet (in addition to producing good code): http://wiki.python.org/moin/SummerOfCode/Expectations Regards, f From robert.kern at gmail.com Tue Apr 13 17:04:27 2010 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 13 Apr 2010 16:04:27 -0500 Subject: [IPython-dev] In-place %editing of methods In-Reply-To: References: Message-ID: On 2010-04-12 13:13 PM, Fernando Perez wrote: > On Sun, Apr 11, 2010 at 9:16 PM, Robert Kern wrote: >> It just occurred to me that someone could write a very useful magic for editing >> methods and functions in-place. The following is a loose sketch to record my >> thoughts in public. > > Thanks, great idea. Filed for tracking: > > https://bugs.launchpad.net/ipython/+bug/561693 I have an implementation in my kernmagic package. http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/ No persistence or unified diffs, but I think that's fine. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From fperez.net at gmail.com Wed Apr 14 01:22:09 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Apr 2010 22:22:09 -0700 Subject: [IPython-dev] GSoC applicants: patch and blog required In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 1:21 PM, Fernando Perez wrote: > Hi folks, > > this is mostly for the gsoc applicants, but I want to make sure that > soc communications are, within reason, always managed on the dev list > (if nothing else, it serves as a record for future years of the > process). Bringing back the discussion on-list... 2010/4/13 Omar Andr?s Zapata Mesa : > a ya! > que pena Fernando fue que gerardo me confundio. > > ya le hice el push voy a empezar a organizar el codigo de > http://github.com/fperez/pyzmq/ The official pyzmq repo is this one, mine is just a fork: http://github.com/ellisonbg/pyzmq The code we want as a starter is in the completer branch. > para montarlo al branch y hacer de una manera sistematica las pruebas para > conocer bien el sistema. > seria bueno incluir ahi los modulos pyzmq? o suponemos que el usuario los > tiene ya en su maquina, por mi no hay problema por que ya lo tengo cuadrado, > pero alguien que quiera ver el codigo demas que le tomaria un trabajo extra > cuadrarlo y seria maluco o que dcies? > seguimos en contacto Gracias. No, users will have to install zmq separately. Once this system stabilizes, we'll probably make releases of pyzmq to ease things, but it will be a dependency (just like twisted or nose). It's a separate project. Cheers, f From fperez.net at gmail.com Wed Apr 14 02:30:49 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Apr 2010 23:30:49 -0700 Subject: [IPython-dev] Moving to git/github Message-ID: Hi all, over the last couple of weeks, pretty much every time I've tried to do something recently with ipython I've wasted the first two hours dealing with bzr repository problems (corrupted repos, version incompatibilities, ...). Once bzr decided to corrupt my repo (I'd never seen that from any other VC system!), I had to re-clone all the branches, but I just realized that I need to do it with the old format so I can push. And the old format is slow as molasses. We could upgrade the lp repos, but frankly, rather than invest more time dealing with a broken tool, let's just move to one that works. I've tested converting our bzr repo into git and it works beautifully (this will NOT be our official git repo, I was just testing things out): http://github.com/fperez/ip see for example: http://github.com/fperez/ip/network where you can scroll and view all the merges and history. If we get GSOC project(s) approved, having a smooth collaboration machinery will be even more important. So a proposed plan for the migration is: - merge all the branches that are in-flight and ready into trunk (it's not a lot right now). - I repeat the conversion, and upload the new repo to github, we close up shop on bzr. Ideally, that would be it for the code. So I'd like to ask anyone with pending work to put up your branches for merging, so that we can review them and merge them as soon as is reasonable. If we have unmerged branches when we make the transition they can be moved separately, but the extra steps needed the better. I'm deliberately *not* addressing here the question of what to do with bugs, we have a ton of important history in the LP bugtracker so I'm not sold on the idea of switching yet to the github one, at least until we discuss it more carefully. Any thoughts, feedback, holes in the above plan? Cheers, f ps - anyone know what the format of our lp:ipython repo is? I can't seem to clone it in a way that allows me to push later again using a shared repo because I don't know what format to use for init-repo. Any help with that info would be much appreciated. From fperez.net at gmail.com Wed Apr 14 02:59:30 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 13 Apr 2010 23:59:30 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: On Tue, Apr 13, 2010 at 11:30 PM, Fernando Perez wrote: > ps - anyone know what the format of our lp:ipython repo is? ?I can't > seem to clone it in a way that allows me to push later again using a > shared repo because I don't know what format to use for init-repo. > Any help with that info would be much appreciated. For future reference, the magic incantation needed (many thanks to lifeless on #bzr on irc!) was: bzr info -v nosmart+lp:ipython This was the only way to figure out the remote LP branch format, so I could make a new, clean local shared repo with the same format from scratch, to start doing branch work. Whew. I'm putting this here in case it saves someone time in the future (or even another one of us during the transition). Cheers, f From Chris.Barker at noaa.gov Wed Apr 14 12:26:22 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 14 Apr 2010 09:26:22 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: <4BC5ECAE.40904@noaa.gov> Fernando Perez wrote: > I've tested converting our bzr repo into git I don't suppose you'd consider Mercurial? It seems the more "Pythonic" option, and I'm really not looking forward to keeping track how to use four different VCSs. Oh well. I probably won't need to do more than pull the latest anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From willmaier at ml1.net Wed Apr 14 12:39:39 2010 From: willmaier at ml1.net (Will Maier) Date: Wed, 14 Apr 2010 11:39:39 -0500 Subject: [IPython-dev] Moving to git/github In-Reply-To: <4BC5ECAE.40904@noaa.gov> References: <4BC5ECAE.40904@noaa.gov> Message-ID: <20100414163939.GM32724@burko.lfod.us> Hi Christopher- On Wed, Apr 14, 2010 at 09:26:22AM -0700, Christopher Barker wrote: > Fernando Perez wrote: > > I've tested converting our bzr repo into git > > I don't suppose you'd consider Mercurial? It seems the more "Pythonic" > option, and I'm really not looking forward to keeping track how to use > four different VCSs. Fortunately, you don't have to. Even though I've never installed git on any of my systems, I've just migrated my Mercurial projects to github[0]. With the hg-git[1] plugin (developed by github), it's easy to use Mercurial for hacking and push my work back to github. I'm sure you could do the same when IPython finishes its migration. [0] FWIW, I also have mirrors on bitbucket (a service catering directly to Mercurial). I keep the mirrors in sync with the following in a clone's hgrc: [hooks] changegroup.bitbucket = hg push bitbucket changegroup.github = hg push github When I push to the clone, it in turn sends the changes to bitbucket and github (the actual paths are defined elsewhere in the hgrc). [1] http://hg-git.github.com/ -- [Will Maier]-----------------[willmaier at ml1.net|http://www.lfod.us/] From fperez.net at gmail.com Wed Apr 14 14:11:39 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 11:11:39 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: <4BC5ECAE.40904@noaa.gov> References: <4BC5ECAE.40904@noaa.gov> Message-ID: Hi Chris, On Wed, Apr 14, 2010 at 9:26 AM, Christopher Barker wrote: > > I don't suppose you'd consider Mercurial? It seems the more "Pythonic" > option, and I'm really not looking forward to keeping track how to use > four different VCSs. > > Oh well. I probably won't need to do more than pull the latest anyway. Fortunately as Will points out (thanks!), there's good hg <-> git support. I think the reality is that we'll live with git AND hg for a while, as both seem to have crossed a threshold of interest, activity and quality that can sustain them. Personally I really like git, all of my current public and private work is git-hosted, Brian also uses git extensively, matplotlib is moving to git, the nipy project from my work is partly git hosted and the rest of it is moving to git soon, etc. I find git's branching model fabulous, and I love the github interface. So I don't see a compelling reason to go to hg, despite the fact that I'm sure it's a perfectly good tool. I do like the fact that hg is there and is good, I have the impression that the competition between hg and git is benefiting both projects and they are learning from each other. It's true that it's a little annoying to use all systems, but hopefully soon we'll be down to hg and git: I don't see bzr going anywhere, and git-svn is a pretty good option to use for svn repos once you're familiar with git. And as those two converge even further, it should get even easier. Regards, f From fperez.net at gmail.com Wed Apr 14 14:37:04 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 11:37:04 -0700 Subject: [IPython-dev] Upgrading the bzr repo at LP? Message-ID: Hi all, after my fight with lp yesterday, it became clear that the only reasonable way to manage the merges from the remaining branches that are in flight (especially those in ~ipython-contrib) is to upgrade the lp:ipython main repo. The reason is that otherwise it's impossible to merge from ~ipython-contrib and push back to trunk: the contrib repo is version 2a and trunk is 0.92, and one can only push to a 0.92 from a 0.92 repo, but one can't pull from a 2a into a 0.92 one (even locally). So even as we move out of LP, it's inevitable that we upgrade the repo. You had all OK'd the move back in February (when I had to stop because it was taking too long and I was traveling), so I'm going to push the process now. The only consequence of this is that you will need to then go to your locally housed repos at home and do bzr upgrade --2a before you can push again. I'm starting the upgrade on LP now from a machine with a solid and persistent connection (as they recommend) I'll post when it's finished. Cheers, f From erik.tollerud at gmail.com Wed Apr 14 14:46:36 2010 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 14 Apr 2010 11:46:36 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: <4BC5ECAE.40904@noaa.gov> Message-ID: As a "casual" developer/power user of ipython, I have something to add here... > So I don't see a compelling reason to go to hg, despite the fact that > I'm sure it's a perfectly good tool. ?I do like the fact that hg is > there and is good, I have the impression that the competition between > hg and git is benefiting both projects and they are learning from each > other. There is one compelling reason to choose hg over git: simplicity. My experience between bzr, hg, and git has been that they are in exactly that order of increasing complexity... but hg and bzr are both *way* easier than git. Frankly, it shows that git was written by someone who wrote the linux kernel - yes you can do a lot of things, but the simplest of things are just more complicated or have surprising gotchas. The hg<->git bridge makes things easier, but the times I've used it, it seems to negate all the advantages of hg or git (speed and/or the advanced features), although that's only based on a couple data points. And anyway, if the goal is simplicity, adding an additional conceptual layer is far worse than taking a few-percent speed hit. Now given that ipython is a somewhat "low-level" utility in that it seems rather difficult to just do some quick hacks on without really understanding what's going on, maybe this isn't an issue, as maybe all the core devs are fine with a more complex system... but git would certainly be a barrier to someone like me contributing. > It's true that it's a little annoying to use all systems, but > hopefully soon we'll be down to hg and git: I don't see bzr going > anywhere, and git-svn is a pretty good option to use for svn repos > once you're familiar with git. ?And as those two converge even > further, it should get even easier. I personally use bzr for all of my projects that I have a choice in the matter... I think it's not at all clear-cut that bzr is going to disappear any sooner than hg or git unless Canonical and Ubuntu disappear - they're committed to launchpad and it is very closely tied to bzr - a lot of people will stick with it for exactly those reasons. That's certainly not a reason to stick with bzr if most of the ipython devs aren't happy with it, but it's not fair to say it's dying by any stretch. I'd also add that it looks like you're using the pack-0.92 format... the more recent 2a format works quite a bit faster in my experience, and I've never had any conversion problems... From fperez.net at gmail.com Wed Apr 14 15:24:30 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 12:24:30 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: <4BC5ECAE.40904@noaa.gov> Message-ID: Hi Erik, On Wed, Apr 14, 2010 at 11:46 AM, Erik Tollerud wrote: > As a "casual" developer/power user of ipython, I have something to add here... Thanks a lot for your feedback! >> So I don't see a compelling reason to go to hg, despite the fact that >> I'm sure it's a perfectly good tool. ?I do like the fact that hg is >> there and is good, I have the impression that the competition between >> hg and git is benefiting both projects and they are learning from each >> other. > > There is one compelling reason to choose hg over git: simplicity. ?My > experience between bzr, hg, and git has been that they are in exactly > that order of increasing complexity... but hg and bzr are both *way* > easier than git. ?Frankly, it shows that git was written by someone > who wrote the linux kernel - yes you can do a lot of things, but the > simplest of things are just more complicated or have surprising > gotchas. ?The hg<->git bridge makes things easier, but the times I've > used it, it seems to negate all the advantages of hg or git (speed > and/or the advanced features), although that's only based on a couple > data points. ?And anyway, if the goal is simplicity, adding an > additional conceptual layer is far worse than taking a few-percent > speed hit. > > Now given that ipython is a somewhat "low-level" utility in that it > seems rather difficult to just do some quick hacks on without really > understanding what's going on, maybe this isn't an issue, as maybe all > the core devs are fine with a more complex system... but git would > certainly be a barrier to someone like me contributing. I really hope that git does not become a barrier to you nor anyone else. I think git is improving, and that part of the problem with git is that a lot of the existing documentation exposes all of its flexibility (and hence complexity) up front. The man pages (I'll be the first to admit) are very opaque, and a few choices of the interface are downright wrong (for commit, -a *should* have been the default like everywhere else, and --some-option should be used to only commit manually staged changes). But things do get better (e.g. the new --set-upstream in 1.7 which is like bzr's great --remember for push/pull). I do take your comment to heart though (esp. since the same issue is about to hit us on ipython, matplotlib and nipy!). I am personally committed to writing up a *clear* workflow document for ipython/nipy that can be followed nicely by anyone who starts by: - getting the sources for ipython via version control - from there, makes a small change to fix/improve something - then, wants to share that change with minimal effort. The key will be, I think, not to point people to multiple tutorials they can read and then assemble things in their head, but instead to give them *our workflow*, with all the choices explicitly indicated and made for them. Once they learn more about git they can change those decisions and lay their workflow differently if desired, but initially they have no criterion of their own to choose, so we might as well pick good choices for them to let them get up and running without much pain. So I'm not discounting your comment, I just hope that for ipython, nipy and others I'm involved with, we'll be able to provide a clear enough guide that git's extensive flexibility is not an upfront hindrance to anyone. We'll see if we succeed :) >> It's true that it's a little annoying to use all systems, but >> hopefully soon we'll be down to hg and git: I don't see bzr going >> anywhere, and git-svn is a pretty good option to use for svn repos >> once you're familiar with git. ?And as those two converge even >> further, it should get even easier. > > I personally use bzr for all of my projects that I have a choice in > the matter... I think it's not at all clear-cut that bzr is going to > disappear any sooner than hg or git unless Canonical and Ubuntu > disappear - they're committed to launchpad and it is very closely tied > to bzr - a lot of people will stick with it for exactly those reasons. > ?That's certainly not a reason to stick with bzr if most of the > ipython devs aren't happy with it, but it's not fair to say it's dying > by any stretch. I said 'not going anywhere', not 'disappear'. I simply don't see major bzr uptake in new projects, and I do see people moving away from it (anecdotal evidence from blog posts, no statistical study here :), so I don't see it growing significantly, especially with the rapid rise in popularity of hg/git. But with the weight of LP/canonical and other existing projects behind it, I'm sure it will remain viable for those who like it (and I hope it will continue to improve, its developers have certainly been super-friendly to me on irc and for that I thank them profusely). > I'd also add that it looks like you're using the pack-0.92 format... > the more recent 2a format works quite a bit faster in my experience, > and I've never had any conversion problems... The conversion is ongoing right now at LP, so hopefully it will finish soon and we'll have all repos on 2a, to ease the transition. Cheers, f From benjaminrk at gmail.com Wed Apr 14 15:30:37 2010 From: benjaminrk at gmail.com (MinRK) Date: Wed, 14 Apr 2010 12:30:37 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: <4BC5ECAE.40904@noaa.gov> Message-ID: I fully support moving to git, as almost every new project I encounter is on git, and IPython is the only thing I have had occasion to touch with bzr. In particular, github makes forking/proposing contributions easier than anything I have observed, and I have seen many projects on github benefit from that. Moreover, the fork/contribute behavior is very active in the git community, and I think just being on github is likely to prompt more contribution than living at LP. -MinRK On Wed, Apr 14, 2010 at 11:46, Erik Tollerud wrote: > As a "casual" developer/power user of ipython, I have something to add > here... > > > So I don't see a compelling reason to go to hg, despite the fact that > > I'm sure it's a perfectly good tool. I do like the fact that hg is > > there and is good, I have the impression that the competition between > > hg and git is benefiting both projects and they are learning from each > > other. > > There is one compelling reason to choose hg over git: simplicity. My > experience between bzr, hg, and git has been that they are in exactly > that order of increasing complexity... but hg and bzr are both *way* > easier than git. Frankly, it shows that git was written by someone > who wrote the linux kernel - yes you can do a lot of things, but the > simplest of things are just more complicated or have surprising > gotchas. The hg<->git bridge makes things easier, but the times I've > used it, it seems to negate all the advantages of hg or git (speed > and/or the advanced features), although that's only based on a couple > data points. And anyway, if the goal is simplicity, adding an > additional conceptual layer is far worse than taking a few-percent > speed hit. > > Now given that ipython is a somewhat "low-level" utility in that it > seems rather difficult to just do some quick hacks on without really > understanding what's going on, maybe this isn't an issue, as maybe all > the core devs are fine with a more complex system... but git would > certainly be a barrier to someone like me contributing. > > > > It's true that it's a little annoying to use all systems, but > > hopefully soon we'll be down to hg and git: I don't see bzr going > > anywhere, and git-svn is a pretty good option to use for svn repos > > once you're familiar with git. And as those two converge even > > further, it should get even easier. > > I personally use bzr for all of my projects that I have a choice in > the matter... I think it's not at all clear-cut that bzr is going to > disappear any sooner than hg or git unless Canonical and Ubuntu > disappear - they're committed to launchpad and it is very closely tied > to bzr - a lot of people will stick with it for exactly those reasons. > That's certainly not a reason to stick with bzr if most of the > ipython devs aren't happy with it, but it's not fair to say it's dying > by any stretch. > > I'd also add that it looks like you're using the pack-0.92 format... > the more recent 2a format works quite a bit faster in my experience, > and I've never had any conversion problems... > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed Apr 14 16:03:05 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 14 Apr 2010 13:03:05 -0700 Subject: [IPython-dev] Upgrading the bzr repo at LP? In-Reply-To: References: Message-ID: This sounds like a good plan. Thanks for doing this. Brian On Wed, Apr 14, 2010 at 11:37 AM, Fernando Perez wrote: > Hi all, > > after my fight with lp yesterday, it became clear that the only > reasonable way to manage the merges from the remaining branches that > are in flight (especially those in ~ipython-contrib) is to upgrade the > lp:ipython main repo. ?The reason is that otherwise it's impossible to > merge from ~ipython-contrib and push back to trunk: the contrib repo > is version 2a and trunk is 0.92, and one can only push to a 0.92 from > a 0.92 repo, but one can't pull from a 2a into a 0.92 one (even > locally). > > So even as we move out of LP, it's inevitable that we upgrade the > repo. ?You had all OK'd the move back in February (when I had to stop > because it was taking too long and I was traveling), so I'm going to > push the process now. > > The only consequence of this is that you will need to then go to your > locally housed repos at home and do > > bzr upgrade --2a > > before you can push again. > > I'm starting the upgrade on LP now from a machine with a solid and > persistent connection (as they recommend) I'll post when it's > finished. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From willmaier at ml1.net Wed Apr 14 17:22:11 2010 From: willmaier at ml1.net (Will Maier) Date: Wed, 14 Apr 2010 16:22:11 -0500 Subject: [IPython-dev] Moving to git/github In-Reply-To: <20100414163939.GM32724@burko.lfod.us> References: <4BC5ECAE.40904@noaa.gov> <20100414163939.GM32724@burko.lfod.us> Message-ID: <20100414212211.GO32724@burko.lfod.us> A quick addendum... On Wed, Apr 14, 2010 at 11:39:39AM -0500, Will Maier wrote: > [0] FWIW, I also have mirrors on bitbucket (a service catering directly to > Mercurial). I keep the mirrors in sync with the following in a clone's hgrc: > > [hooks] I just noticed that it is necessary to run the following hook before changegroup.github: changegroup.updatemaster = hg bookmark -f -r default master hg-git uses the master revision to decide what changesets need to be sent to the remote git repository. Since the bookmark isn't updated when the mirror repo receives a push, the above hook is necessary. > changegroup.bitbucket = hg push bitbucket > changegroup.github = hg push github > > When I push to the clone, it in turn sends the changes to bitbucket and > github (the actual paths are defined elsewhere in the hgrc). -- [Will Maier]-----------------[willmaier at ml1.net|http://www.lfod.us/] From Chris.Barker at noaa.gov Wed Apr 14 17:35:12 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 14 Apr 2010 14:35:12 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: <4BC5ECAE.40904@noaa.gov> Message-ID: <4BC63510.4010805@noaa.gov> Fernando Perez wrote: > Fortunately as Will points out (thanks!), there's good hg <-> git > support. I think the reality is that we'll live with git AND hg for a > while, as both seem to have crossed a threshold of interest, activity > and quality that can sustain them. fair enough. As it happens, I haven't had to use git at all yet, but I'm sure it won't be long. > Personally I really like git, What's most important is that the folks doing most of the work are suing the tools they are productive in. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From fperez.net at gmail.com Wed Apr 14 19:34:00 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 16:34:00 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: <4BC63510.4010805@noaa.gov> References: <4BC5ECAE.40904@noaa.gov> <4BC63510.4010805@noaa.gov> Message-ID: On Wed, Apr 14, 2010 at 2:35 PM, Christopher Barker wrote: > What's most important is that the folks doing most of the work are suing > the tools they are productive in. I hadn't considered suing the git developers quite yet, but that may be a good idea to keep in mind as a business model moving forward ;) Cheers, f From fperez.net at gmail.com Wed Apr 14 20:40:23 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 17:40:23 -0700 Subject: [IPython-dev] Upgrade to repository format 2a in launchpad finished Message-ID: Hi all, the repo upgrade on LP is done. You will need to update any local shared repos you may have with bzr upgrade --2a In addition, you will also need to upgrade you branches hosted on launchpad so you can push back to them, just like I did with the trunk repo. For example, for my trunk-dev branch on LP I just did: bzr upgrade --2a lp:~fdo.perez/ipython/trunk-dev This upgrade on LP takes a good while (an hour, perhaps two), so do it from a machine with a stable connection, as it entails constant network traffic. I once had mine interrupted and was left with a 'wedged' upgrade because the backup file is in the way: https://bugs.launchpad.net/bzr/+bug/300001 The lp team on IRC helped me delete the backup file using hitchhiker: bzr branch lp:hitchhiker Then: uqbar[hitchhiker]> ./hitchhiker lp:ipython Opened bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/trunk/ (Cmd) ls .bzr backup.bzr (Cmd) rmtree backup.bzr (Cmd) ls .bzr Done. I only mention this in case somebody wedges their upgrade, it took me a bit to find what the solution should be. Apparently this problem is fixed in the most recent (beta) bzr release, but getting hitchhiker was easier than updating all of bzr just for this. OK, I hope this upgrade doesn't cause anyone any troubles, let me know if it does. Cheers, f From fperez.net at gmail.com Wed Apr 14 20:49:23 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 17:49:23 -0700 Subject: [IPython-dev] In-place %editing of methods In-Reply-To: References: Message-ID: On Tue, Apr 13, 2010 at 2:04 PM, Robert Kern wrote: > I have an implementation in my kernmagic package. > > http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/ > > No persistence or unified diffs, but I think that's fine. Duly noted on bug page, thanks! Cheers, f From fperez.net at gmail.com Wed Apr 14 22:01:30 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 14 Apr 2010 19:01:30 -0700 Subject: [IPython-dev] GSoC applicants: patch and blog required In-Reply-To: References: Message-ID: Hey, [ you forgot 'reply to all' for the list, putting it back in ] On Wed, Apr 14, 2010 at 6:08 PM, Gerardo Gutierrez wrote: > Hi Fernando. > When I type make pdf in the trunk working copy (without any changes, and > obviously the trunk installed) i get this: > reading sources... [ ?2%] api/generated/IPython.ColorANSI > Exception occurred: > ??File > "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py", > line 107, in _import_class_or_module > ?? ?"Could not import class or module '%s' specified for inheritance > diagram" % name) > ValueError: Could not import class or module 'IPython.ColorANSI' specified > for inheritance diagram Mmh, this can *not* be coming from trunk: the module IPython.ColorANSI was from the 0.10 series, while in trunk the generated file should be: source/api/generated/IPython.utils.coloransi.txt It looks like you have an ipython 0.10 being pulled in somewhere... > I Have the documentation ready and some code that need to be cleaned to > commit and also, I think I don't know how to merge because when I try i get > this: > muzgash at he1:~/MyProjects$ ls > ipython ?qt-frontend ?qt-frontend-bk > muzgash at he1:~/MyProjects$ cd qt-frontend > muzgash at he1:~/MyProjects/qt-frontend$ bzr merge ../ipython/ > Doing on-the-fly conversion from RepositoryFormat2a() to > RepositoryFormatKnitPack1(). > This may take some time. Upgrade the repositories to the same format for > better performance. > bzr: ERROR: > KnitPackRepository('file:///home/muzgash/MyProjects/qt-frontend/.bzr/repository/') > is not compatible with > CHKInventoryRepository('file:///home/muzgash/MyProjects/ipython/.bzr/repository/') > different rich-root support > muzgash at he1:~/MyProjects/qt-frontend$ bzr merge ../ipython/ --force > --uncommitted > All changes applied successfully. > But with the last command ?there's no changes at all, the same error I got > yesterday is there. > I just need to fix those things, and begin writing the pyzmq module. Aha, the fun I was dealing with last night. Sorry to hear that... I would suggest you start with a clean repo: bzr init-repo --2a repo cd repo bzr branch lp:ipython bzr branch lp:~ipython-contrib/ipython/qt-frontend cd qt-frontend/ bzr merge ../ipython This should give you a fully merged version of the qt-frontend branch up to date with trunk, which you can commit and push back. You can then apply your changes to the qt-frontend branch and push again your new changes. Similarly for the zmq stuff, except Omar needs to create the branch, since that one doesn't exist yet. Cheers, f From vivainio at gmail.com Thu Apr 15 12:25:52 2010 From: vivainio at gmail.com (Ville M. Vainio) Date: Thu, 15 Apr 2010 19:25:52 +0300 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: On Wed, Apr 14, 2010 at 9:30 AM, Fernando Perez wrote: > incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd > never seen that from any other VC system!), I had to re-clone all the Aside: I have absolutely seen git repository (a remote one!) get corrupted accidentally. Was gitorious (a truly free service, as opposed to github) considered? -- Ville M. Vainio http://tinyurl.com/vainio From fperez.net at gmail.com Thu Apr 15 12:49:36 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 09:49:36 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 9:25 AM, Ville M. Vainio wrote: > >> incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd >> never seen that from any other VC system!), I had to re-clone all the > > Aside: I have absolutely seen git repository (a remote one!) get > corrupted accidentally. Ouch, that's bad news, and worrysome. > Was gitorious (a truly free service, as opposed to github) considered? Honestly I have only played lightly with it. I have more github experience than with gitorious simply because several projects I follow were already on github and I very much like their interface. My experience with gitorious has been minimal. They do have a project/person/team model that's very similar to the LP one, while github has no 'teams'. I really like how github allows individual users to offer write access to branches, how the site can follow the network of forks, their comment system, and overall their interface: it's fluid and gets completely out of your way. I have no experience with gitorious at that level, but I'd be happy to hear comments on this front. Being fully free is certainly a plus for gitorious, though since we're not planning on hosting it ourselves, the weight of this consideration is secondary. Workflow, support and features are more important in this case (LP was not free for a long time while we used it and that didn't really stop us). I certainly don't want to appear to be imposing a decision, so by all means do offer any contrasting views so we can come to an informed final choice. Cheers, f From fperez.net at gmail.com Thu Apr 15 13:54:44 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 10:54:44 -0700 Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython Crash Report] Message-ID: Howdy, below is a crash report from a windows user (full report attached). I tested with 0.10 on linux and can't reproduce the problem, what I get is: In [1]: 'esth'.startswith(None) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /home/fperez/tmp/junk/ in () TypeError: expected a character buffer object and the session continues OK, but I don't have a windows box right now that I can test on. Can anyone see it on windows? Jorgen, do you think this could be a pyreadline problem? Thanks for any feedback, f On Tue, Apr 13, 2010 at 4:30 PM, Tom Plunket wrote: > IPython rocks, thanks for developing it.? Sorry for any stupid formatting > this email may bring; work requirements y'know? > > Anyway- I've never seen an IPython crash before so this was surprising to > say the least.? I looked at the crash report and it appeared to have no > history.? I was curious what some_string.startswith(None) would do. > > The beginning of my IPython session looks like this.? The last lines?here > are?in the crash report preceding a bunch of blank-but-numbered lines.? On > Windows Vista x64 with pyreadline installed. > > Python 2.6.4 (r264:75706, Jan 22 2010, 17:24:21) [MSC v.1500 64 bit (AMD64)] > Type "copyright", "credits" or "license" for more information. > > IPython 0.10 -- 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]: 'esth'.startswith(None) > --------------------------------------------------------------------------- > WindowsError?????????????????????????? Python 2.6.4: c:\python26\python.exe > ?????????????????????????????????????????????????? Tue Apr 13 16:20:03 2010 > A problem occured executing Python code.? Here is the sequence of function > calls leading up to the error, with the most recent (innermost) call last. > > C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'() > ??? 280 > ??? 281 -------------- next part -------------- *************************************************************************** IPython post-mortem report IPython version: 0.10 BZR revision : 1210 Platform info : os.name -> nt, sys.platform -> win32 *************************************************************************** Current user configuration structure: {'Version': 0, '__allownew': True, 'alias': [], 'args': [], 'autocall': 1, 'autoedit_syntax': 0, 'autoexec': [], 'autoindent': 1, 'automagic': 1, 'banner': 1, 'c': '', 'cache_size': 1000, 'classic': 0, 'color_info': 1, 'colors': 'Linux', 'confirm_exit': 1, 'debug': 0, 'deep_reload': 0, 'editor': 'notepad', 'embedded': False, 'execfile': [], 'execute': [''], 'gthread': 0, 'help': 0, 'import_all': [], 'import_mod': [], 'import_some': [[]], 'include': [], 'interact': 0, 'ipythondir': u'C:\\Users\\Tom\\_ipython', 'log': 0, 'logfile': '', 'logplay': '', 'magic_docstrings': 0, 'messages': 1, 'multi_line_specials': 1, 'nosep': 0, 'object_info_string_level': 0, 'opts': Struct({'__allownew': True}), 'pdb': 0, 'pprint': 1, 'profile': '', 'prompt_in1': 'In [\\#]: ', 'prompt_in2': ' .\\D.: ', 'prompt_out': 'Out[\\#]: ', 'prompts_pad_left': 1, 'pydb': 0, 'pylab': 0, 'pylab_import_all': 1, 'q4thread': 0, 'qthread': 0, 'quick': 0, 'quiet': 0, 'rcfile': 'ipythonrc.ini', 'readline': 1, 'readline_merge_completions': 1, 'readline_omit__names': 0, 'readline_parse_and_bind': ['tab: complete', '"\\C-l": possible-completions', 'set show-all-if-ambiguous on', '"\\C-o": tab-insert', '"\\M-i": " "', '"\\M-o": "\\d\\d\\d\\d"', '"\\M-I": "\\d\\d\\d\\d"', '"\\C-r": reverse-search-history', '"\\C-s": forward-search-history', '"\\C-p": history-search-backward', '"\\C-n": history-search-forward', '"\\e[A": history-search-backward', '"\\e[B": history-search-forward', '"\\C-k": kill-line', '"\\C-u": unix-line-discard'], 'readline_remove_delims': '-/~', 'screen_length': -2, 'separate_in': '\n', 'separate_out': '', 'separate_out2': '', 'system_header': 'IPython system call: ', 'system_verbose': 0, 'term_title': 1, 'tk': 0, 'upgrade': 0, 'wildcards_case_sensitive': 1, 'wthread': 0, 'wxversion': '0', 'xmode': 'Context'} *************************************************************************** Crash traceback: --------------------------------------------------------------------------- WindowsError Python 2.6.4: c:\python26\python.exe Tue Apr 13 16:20:03 2010 A problem occured executing Python code. Here is the sequence of function calls leading up to the error, with the most recent (innermost) call last. C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'() 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 --> 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 c:\python26\lib\site-packages\pyreadline-1.5.dev_r0-py2.6.egg\pyreadline\console\console.pyc in hook_wrapper_23(stdin=1905849808L, stdout=1905849856L, prompt='\n\x01\x1b[0;32m\x02In [\x01\x1b[1;32m\x021\x01\x1b[0;32m\x02]: \x01\x1b[0m\x02') 666 if res and not isinstance(res, str): 667 raise TypeError, 'readline must return a string.' 668 except KeyboardInterrupt: 669 # GNU readline returns 0 on keyboard interrupt 670 return 0 671 except EOFError: 672 # It returns an empty string on EOF 673 res = '' 674 except: 675 print >>sys.stderr, 'Readline internal error' 676 traceback.print_exc() 677 res = '\n' 678 # we have to make a copy because the caller expects to free the result 679 n = len(res) 680 p = Console.PyMem_Malloc(n+1) --> 681 cdll.msvcrt.strncpy(p, res, n+1) 682 return p 683 684 def hook_wrapper(prompt): 685 '''Wrap a Python readline so it behaves like GNU readline.''' 686 try: 687 # call the Python hook 688 res = ensure_str(readline_hook(prompt)) 689 # make sure it returned the right sort of thing 690 if res and not isinstance(res, str): 691 raise TypeError, 'readline must return a string.' 692 except KeyboardInterrupt: 693 # GNU readline returns 0 on keyboard interrupt 694 return 0 695 except EOFError: 696 # It returns an empty string on EOF WindowsError: exception: access violation writing 0x0000000000000000 *************************************************************************** History of session input: *** Last line of input (may not be in above history): From ellisonbg at gmail.com Thu Apr 15 14:00:31 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Apr 2010 11:00:31 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: In my mind, the commercial nature of github is an advantage: * I *want* to have paid, private repos as well. * Because I am a paying customer, if something goes wrong, there is (hopefully) a stronger chance that they will be motivated to fix the issue. Another point is that github itself is one of the main reasons that I am in favor of the transition to git. Launchpad drives me absolutely crazy, github gives me warm fuzzy feelings and sets my mind at peace. Cheers, Brian On Thu, Apr 15, 2010 at 9:49 AM, Fernando Perez wrote: > On Thu, Apr 15, 2010 at 9:25 AM, Ville M. Vainio wrote: >> >>> incompatibilities, ...). ?Once bzr decided to corrupt my repo (I'd >>> never seen that from any other VC system!), I had to re-clone all the >> >> Aside: I have absolutely seen git repository (a remote one!) get >> corrupted accidentally. > > Ouch, that's bad news, and worrysome. > >> Was gitorious (a truly free service, as opposed to github) considered? > > Honestly I have only played lightly with it. ?I have more github > experience than with gitorious simply because several projects I > follow were already on github and I very much like their interface. > My experience with gitorious has been minimal. ?They do have a > project/person/team model that's very similar to the LP one, while > github has no 'teams'. > > I really like how github allows individual users to offer write access > to branches, how the site can follow the network of forks, their > comment system, and overall their interface: it's fluid and gets > completely out of your way. I have no experience with gitorious at > that level, but I'd be happy to hear comments on this front. > > Being fully free is certainly a plus for gitorious, though since we're > not planning on hosting it ourselves, the weight of this consideration > is secondary. ?Workflow, support and features are more important in > this case (LP was not free for a long time while we used it and that > didn't really stop us). > > I certainly don't want to appear to be imposing a decision, so by all > means do offer any contrasting views so we can come to an informed > final choice. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Thu Apr 15 14:08:13 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 11:08:13 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 11:00 AM, Brian Granger wrote: > In my mind, the commercial nature of github is an advantage: > > * I *want* to have paid, private repos as well. > * Because I am a paying customer, if something goes wrong, there is > (hopefully) a stronger chance that they will be motivated to fix the > issue. Very valid points, I just want to add that despite not being a paying customer, I've had *excellent* response from the github admins with questions I've asked so far. > Another point is that github itself is one of the main reasons that I > am in favor of the transition to git. ?Launchpad drives me absolutely > crazy, github gives me warm fuzzy feelings and sets my mind at peace. :) Cheers, f From jorgen.stenarson at bostream.nu Thu Apr 15 14:14:23 2010 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 15 Apr 2010 20:14:23 +0200 Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython Crash Report] In-Reply-To: References: Message-ID: <4BC7577F.2060209@bostream.nu> Fernando Perez skrev 2010-04-15 19:54: > Howdy, > > below is a crash report from a windows user (full report attached). I > tested with 0.10 on linux and can't reproduce the problem, what I get > is: > > In [1]: 'esth'.startswith(None) > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > > /home/fperez/tmp/junk/ in() > > TypeError: expected a character buffer object > > > and the session continues OK, but I don't have a windows box right now > that I can test on. > > Can anyone see it on windows? > Jorgen, do you think this could be a pyreadline problem? > I can not reproduce this problem but I'm on XP on 32 bit machine. However I see the c:\python26\script directory in the traceback and this made me think that it could be a setuptools problem. I have seen strange things if you launch ipython using the exe file that setuptools generates. Can you confirm wether you are using that exe file? If you are can you try launching ipython without it. /J?rgen > Thanks for any feedback, > > f > > On Tue, Apr 13, 2010 at 4:30 PM, Tom Plunket wrote: >> IPython rocks, thanks for developing it. Sorry for any stupid formatting >> this email may bring; work requirements y'know? >> >> Anyway- I've never seen an IPython crash before so this was surprising to >> say the least. I looked at the crash report and it appeared to have no >> history. I was curious what some_string.startswith(None) would do. >> >> The beginning of my IPython session looks like this. The last lines here >> are in the crash report preceding a bunch of blank-but-numbered lines. On >> Windows Vista x64 with pyreadline installed. >> >> Python 2.6.4 (r264:75706, Jan 22 2010, 17:24:21) [MSC v.1500 64 bit (AMD64)] >> Type "copyright", "credits" or "license" for more information. >> >> IPython 0.10 -- 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]: 'esth'.startswith(None) >> --------------------------------------------------------------------------- >> WindowsError Python 2.6.4: c:\python26\python.exe >> Tue Apr 13 16:20:03 2010 >> A problem occured executing Python code. Here is the sequence of function >> calls leading up to the error, with the most recent (innermost) call last. >> >> C:\Python26\Scripts\_ctypes\callbacks.c in 'calling callback function'() >> 280 >> 281 >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Thu Apr 15 14:25:55 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 11:25:55 -0700 Subject: [IPython-dev] Merging all branches that we can for git transition... Message-ID: Hi all, the cleanest way to make the transition from bzr to git will be to merge into trunk various branches we may have in flight. We can create the git repo with extra branches if need be, and I'll be the one doing that, but it is a little simpler if things have been merged, and it makes for a good cleanup point as we look to what's needed for 0.11. I just merged Laurent's 0.10 bugfixes and Dav's traitlets renames branches, these are the only two active merge reviews that were ready for merge. So I would like anyone who has any branch with work in-flight that they'd like merged to post and let us know. Make a merge request if the changes are substantial, or just reply here if they are small. I promise to review all changes and do the merge work once we're satisfied with the review. At that point, we'll be ready to simply make the transition to git and reopen for business :) Cheers, f From fperez.net at gmail.com Thu Apr 15 17:43:55 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 14:43:55 -0700 Subject: [IPython-dev] Code hosting: github, gitorious, ...? Message-ID: Hi all, there were some questions about git hosting, so I want to make sure that we allow for any points on that front to be clarified. I'll send a separate email about bug management to keep each discussion focused and easy to follow. For code hosting with git, the basic options are: * github: - Brian and I use it heavily and we like it a lot. Having core developers experienced with a tool is an important factor, though obviously not the only one. - It is free for free projects and has a commercial option; Brian and I expressed some views on this already, other opinions welcome. - they explicitly allowed us to host project repos on a 'project' account, as I don't want to make the main repo be something like 'fperez/ipython'. I think it's healthier to have 'gtihub.com/ipython/reponame' so that the project has an identity separate from that of any one developer. Here is their explicit acknowledgment of this: http://support.github.com/discussions/email/6289-contact-per-project-account-for-open-source-projects?anon_token=5139fe18a00792fd470a9fe3b7bca187b64ddb8d - The user interface is *really nice*, very fluid and efficient. The team is responsive to user requests and the site continues to improve. The code review system allows precise, in-line comments on commits, their tracking of forks (for new contributors) is very useful, and their pull request system is great. - It offers integrated bug tracking. See more on this below, though. * gitorious: - It's fully open source, a plus. Though realistically I don't think we're looking at self-hosting. - I know it very little. I opened an account and played a little with it, but I have no real usage experience. - It doesn't offer bug tracking, as far as I can tell. * other sites, self-hosting: - I host my private git repos using a self-installed indefero, but I really don't want to rely on something like this for an open source project. We have very limited time for admin work, and hosting always does take time. - Beyond gitorious and github, I don't know the other git hosting platforms at all. Feedback on this, critical or otherwise, much appreciated. Based on this we'll decide how to move forward. Cheers, f From fperez.net at gmail.com Thu Apr 15 17:45:27 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 14:45:27 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? Message-ID: Hi all, We've been fairly diligent about using the LP tracker and I actually don't mind it too much (it's slow, but I got used to opening many tabs in parallel so each tab does its thing while I work on the others). The point is that we do have very valuable information there, which we're not going to ignore. But as we change from bzr to git for hosting, what to do with bugs merits an informed decision. In my mind the options moving forward are: 1. Stay with launchpad for bug handling, just start pointing to github urls instead of internal LP ones. + less work to do. - no integration with the source control system - the interface is slow and a bit clunky (Brian has mentioned here how it drives him mad) 2. Move to github for bugs. + good integration with the source control, e.g. bugs can be closed from commit messages. - We'd have to link LP bugs for a while, so the existing ones can be tracked until completion. - **The big negative one in my mind** I'm not convinced the 'tags only' approach is a good idea: Github only offers labels for bugs, so all other information (ownership, category, status, etc) has to be created via labels. Effectively every project ends up making up a syntax for how to track bugs. While I think that approach is OK for something like email, I think bug management is a well-defined enough problem that *some* generic key/value pairs should exist. That is, bug management is a problem for which we know a basic model, and by not offering *any* model, a labels-only system forces everyone to re-invent a known wheel. By having a common model, the user interface can offer efficient access to certain information, like all tickets targeted to a milestone, or open and owned by someone, etc. These have to be manually re-created as label-based queries for every project, and every single time you want them even for one project. Now, bug tracking at github isn't very old, so it's possible that it will grow a few key/value fields for the most common uses, but we can't rely on that happening. So I'd like to have some thought put into this, especially if anyone has *actual experience* with labels-only bug management. Is it as clunky as I am making it to be, or am I overly worried? 3. Other? Gitorious has no bug hosting that I can see, it seems all projects hosted on gitorious have separate bug trackers. Indefero has bug tracking, but I think the platform is a bit young for hosting (I do use it for self-hosting, but for private projects my requirements are minimal). I don't know other tools. I'm a little torn here: I tend to prefer the tight integration between bugs and source control, so I'm inclined to want to move out of lp. But I'm not sold on the github approach quite yet. Again, feedback much appreciated. Cheers, f From robert.kern at gmail.com Thu Apr 15 18:23:36 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Apr 2010 17:23:36 -0500 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On 2010-04-15 16:45 PM, Fernando Perez wrote: > Hi all, > > We've been fairly diligent about using the LP tracker and I actually > don't mind it too much (it's slow, but I got used to opening many tabs > in parallel so each tab does its thing while I work on the others). > The point is that we do have very valuable information there, which > we're not going to ignore. > > But as we change from bzr to git for hosting, what to do with bugs > merits an informed decision. In my mind the options moving forward > are: > > 1. Stay with launchpad for bug handling, just start pointing to github > urls instead of internal LP ones. > > + less work to do. > - no integration with the source control system > - the interface is slow and a bit clunky (Brian has mentioned here > how it drives him mad) It drives me mad, too. > 2. Move to github for bugs. > > + good integration with the source control, e.g. bugs can be closed > from commit messages. > - We'd have to link LP bugs for a while, so the existing ones can be > tracked until completion. > > - **The big negative one in my mind** I'm not convinced the 'tags > only' approach is a good idea: > > Github only offers labels for bugs, so all other information > (ownership, category, status, etc) has to be created via labels. > Effectively every project ends up making up a syntax for how to track > bugs. While I think that approach is OK for something like email, I > think bug management is a well-defined enough problem that *some* > generic key/value pairs should exist. That is, bug management is a > problem for which we know a basic model, and by not offering *any* > model, a labels-only system forces everyone to re-invent a known > wheel. By having a common model, the user interface can offer > efficient access to certain information, like all tickets targeted to > a milestone, or open and owned by someone, etc. These have to be > manually re-created as label-based queries for every project, and > every single time you want them even for one project. Another option would be to use Google Code's issue tracker. While it is sort of label-based, that's mostly just an illusion of the data entry UI. Labels of the form CamelCaseKey-value basically create new key/value metadata pairs, and the project admin can control the taxonomy. I believe it comes with a sensible default set. http://code.google.com/p/support/wiki/IssueTracker It looks like you can set up Google Code Subversion repo as a read-only mirror of the git trunk. This would probably permit the VCS-issue tracker integration. http://code.google.com/p/support/wiki/ImportingFromGit http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs, so perhaps you could migrate the individual issues. http://code.google.com/p/support/wiki/IssueTrackerAPIPython https://help.launchpad.net/API -- 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 Apr 15 20:53:41 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 17:53:41 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern wrote: > Another option would be to use Google Code's issue tracker. While it is sort of > label-based, that's mostly just an illusion of the data entry UI. Labels of the > form CamelCaseKey-value basically create new key/value metadata pairs, and the > project admin can control the taxonomy. I believe it comes with a sensible > default set. > > ? http://code.google.com/p/support/wiki/IssueTracker Unfortunately google has decided to unconditionally block Cuba from access to all of code.google.com. There are US export laws that Google must follow, but for example Sourceforge has allowed individual project admins to select whether their project contains export-restricted code (mostly crypto-related tools), so that most projects on SF are accessible to Cuba. Google, on the other hand, makes this restriction site-wide. My colleague Matthew Brett, who travels often to Cuba and collaborates with scientists there, has pointed this out before and I would like to support the access to open source projects for Cuban residents. We have in fact been discussing how to encourage the uptake of scientific python tools in Cuba (heavily matlab-dominated, at least in some fields) and it would be good to make sure they can access the tools we're promoting in the first place. But it does seem like the Google team did a good job thinking about this: the apparent simplicity of a labels-only approach with just enough of an underlying model to provide some useful structure. If we end up with GH, these are good references to have, if nothing else, to file as requests with their system. > It looks like you can set up Google Code Subversion repo as a read-only mirror > of the git trunk. This would probably permit the VCS-issue tracker integration. > > ? http://code.google.com/p/support/wiki/ImportingFromGit > > http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control > > Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs, > so perhaps you could migrate the individual issues. > > ? http://code.google.com/p/support/wiki/IssueTrackerAPIPython > ? https://help.launchpad.net/API The github one has a web api: http://develop.github.com/p/issues.html which for example someone used to write a ruby-based lighthouse-to-github conversion script: http://github.com/suitmymind/lighthouse-to-github/blob/master/migrate-lh-to-gh.rb It looks easy enough to use it as a starting point and do a lp2gh bug migrator. Thanks! f From fperez.net at gmail.com Thu Apr 15 21:15:05 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 18:15:05 -0700 Subject: [IPython-dev] GSoC applicants: patch and blog required In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 2:29 PM, Gerardo Gutierrez wrote: > Hi again, this is really strange, I've done all the steps you show above but > there's another problem :'( ... > /home/muzgash/MyProjects/ipython/docs/sphinxext/docscrape.py:117: > UserWarning: Unknown section Options > ??warn("Unknown section %s" % key) > reading sources... [ 19%] api/generated/IPython.kernel.clientconnector > Exception occurred: > ??File > "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py", > line 107, in _import_class_or_module > ?? ?"Could not import class or module '%s' specified for inheritance > diagram" % name) > ValueError: Could not import class or module > 'IPython.kernel.clientconnector' specified for inheritance diagram > The full traceback has been saved in /tmp/sphinx-err-L_nA3u.log, if you want > to report the issue to the developers. > Please also report this if it was a user error, so that a better error > message can be provided next time. > Either send bugs to the mailing list at > , > or report them in the tracker at > . Thanks! > make: *** [latex] Error 1 > And i'm doing this with the trunk (installed). You needed to have installed python-foolscap python-nose Basically, to build the docs you need to have an install of IPython with full dependencies, not just the command-line client. This is because to build the api docs, Sphinx needs to be able to import all of the modules. I've just added them in your system (I just logged in and did it from here), and the docs now build, you can have a look at the pdfs there: muzgash at he1:~/MyProjects/ipython/docs/build/latex$ ls -ltr *pdf -rw-r--r-- 1 muzgash muzgash 74773 Apr 15 16:21 two_digit_counts.pdf -rw-r--r-- 1 muzgash muzgash 41799 Apr 15 16:21 single_digits.pdf -rw-r--r-- 1 muzgash muzgash 48750 Apr 15 16:21 mec_simple.pdf -rw-r--r-- 1 muzgash muzgash 50227 Apr 15 16:21 ipython_shell.pdf -rw-r--r-- 1 muzgash muzgash 95697 Apr 15 16:21 ipcluster_start.pdf -rw-r--r-- 1 muzgash muzgash 39558 Apr 15 16:21 ipcluster_create.pdf -rw-r--r-- 1 muzgash muzgash 80828 Apr 15 16:21 hpc_job_manager.pdf -rw-r--r-- 1 muzgash muzgash 42631 Apr 15 16:21 asian_put.pdf -rw-r--r-- 1 muzgash muzgash 41078 Apr 15 16:21 asian_call.pdf -rw-r--r-- 1 muzgash muzgash 4938311 Apr 15 20:13 ipython.pdf -rw-r--r-- 1 muzgash muzgash 688836 Apr 15 20:14 winhpc_whitepaper.pdf Cheers, f From fperez.net at gmail.com Thu Apr 15 21:16:59 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 18:16:59 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern wrote: > It looks like you can set up Google Code Subversion repo as a read-only mirror > of the git trunk. I forgot to mention that github also just added this feature: http://github.com/blog/626-announcing-svn-support Cheers, f From fperez.net at gmail.com Thu Apr 15 21:21:18 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 18:21:18 -0700 Subject: [IPython-dev] GSoC applicants: patch and blog required In-Reply-To: References: Message-ID: Hi, On Thu, Apr 15, 2010 at 6:15 PM, Fernando Perez wrote: >> Hi again, this is really strange, I've done all the steps you show above but >> there's another problem :'( ... >> /home/muzgash/MyProjects/ipython/docs/sphinxext/docscrape.py:117: >> UserWarning: Unknown section Options >> ??warn("Unknown section %s" % key) >> reading sources... [ 19%] api/generated/IPython.kernel.clientconnector >> Exception occurred: >> ??File >> "/home/muzgash/MyProjects/ipython/docs/sphinxext/inheritance_diagram.py", >> line 107, in _import_class_or_module >> ?? ?"Could not import class or module '%s' specified for inheritance >> diagram" % name) >> ValueError: Could not import class or module >> 'IPython.kernel.clientconnector' specified for inheritance diagram >> The full traceback has been saved in /tmp/sphinx-err-L_nA3u.log, if you want >> to report the issue to the developers. I should have also added that you need to get used to debugging these kinds of problems, as they are a common occurrence. The error message there says pretty much everything you need to do, as it says: : Could not import class or module 'IPython.kernel.clientconnector' With that, you go into ipython and try to import IPython.kernel.clientconnector, which shows you the underlying error: ImportError Traceback (most recent call last) /home/muzgash/MyProjects/ipython/docs/ in () /usr/lib/python2.5/site-packages/IPython/kernel/clientconnector.py in () 16 import os 17 ---> 18 from IPython.kernel.fcutil import ( 19 Tub, 20 find_furl, /usr/lib/python2.5/site-packages/IPython/kernel/fcutil.py in () 24 from twisted.python import log 25 ---> 26 import foolscap 27 try: 28 from foolscap.api import Tub, UnauthenticatedTub ImportError: No module named foolscap Aha, you need something called 'foolscap'. Then a bit of searching will tell you that the actual package name is 'python-foolscap', so you type: apt-get install python-foolscap and the problem is solved. Debugging these types of errors may look nasty, but it's a basic survival skill wen developing code, which you must acquire. Cheers, f From robert.kern at gmail.com Thu Apr 15 22:01:39 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 15 Apr 2010 21:01:39 -0500 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On 2010-04-15 19:53 , Fernando Perez wrote: > But it does seem like the Google team did a good job thinking about > this: the apparent simplicity of a labels-only approach with just > enough of an underlying model to provide some useful structure. > > If we end up with GH, these are good references to have, if nothing > else, to file as requests with their system. Well, not quite. Like I said, Google Code's labels only look like labels. They are actually flexible, possibly ad hoc, field-based metadata (or can be; some of the labels are just labels). For example, you could have a DueBy field with labels like DueBy-2010-04-15. In the table view, a DueBy column would appear, and 2010-04-15 would appear in the cell for that issue. With GitHub's labels, every single DueBy- label would appear in the list of available labels. That would quickly make an unusable UI. -- 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 Apr 15 23:17:43 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 15 Apr 2010 20:17:43 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 7:01 PM, Robert Kern wrote: >> >> If we end up with GH, these are good references to have, if nothing >> else, to file as requests with their system. > > Well, not quite. Like I said, Google Code's labels only look like labels. They > are actually flexible, possibly ad hoc, field-based metadata (or can be; some of > the labels are just labels). For example, you could have a DueBy field with > labels like DueBy-2010-04-15. In the table view, a DueBy column would appear, > and 2010-04-15 would appear in the cell for that issue. With GitHub's labels, > every single DueBy- label would appear in the list of available labels. > That would quickly make an unusable UI. I perhaps didn't express myself clearly, what I meant was: asking GH to provide support for the Google model of 'labels' that actually hide key/value pairs in CamelCase-value syntax. I actually really like this solution by google: people who just want labels can have them, and those who would like a real key/value structure can also define it quite simply. They've even thought of single/multi valued label handling, and apparently provide control over that. In summary, I really really do like that issue tracker design a lot, many thanks for pointing that out. Take care, f From ellisonbg at gmail.com Fri Apr 16 01:09:53 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 15 Apr 2010 22:09:53 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern wrote: > On 2010-04-15 16:45 PM, Fernando Perez wrote: >> Hi all, >> >> We've been fairly diligent about using the LP tracker and I actually >> don't mind it too much (it's slow, but I got used to opening many tabs >> in parallel so each tab does its thing while I work on the others). >> The point is that we do have very valuable information there, which >> we're not going to ignore. >> >> But as we change from bzr to git for hosting, what to do with bugs >> merits an informed decision. In my mind the options moving forward >> are: >> >> 1. Stay with launchpad for bug handling, just start pointing to github >> urls instead of internal LP ones. >> >> ? ?+ less work to do. >> ? ?- no integration with the source control system >> ? ?- the interface is slow and a bit clunky (Brian has mentioned here >> how it drives him mad) > > It drives me mad, too. > >> 2. Move to github for bugs. >> >> ? ?+ good integration with the source control, e.g. bugs can be closed >> from commit messages. >> ? ?- We'd have to link LP bugs for a while, so the existing ones can be >> tracked until completion. >> >> ? ?- **The big negative one in my mind** ?I'm not convinced the 'tags >> only' approach is a good idea: >> >> Github only offers labels for bugs, so all other information >> (ownership, category, status, etc) has to be created via labels. >> Effectively every project ends up making up a syntax for how to track >> bugs. ?While I think that approach is OK for something like email, I >> think bug management is a well-defined enough problem that *some* >> generic key/value pairs should exist. ?That is, bug management is a >> problem for which we know a basic model, and by not offering *any* >> model, a labels-only system forces everyone to re-invent a known >> wheel. ?By having a common model, the user interface can offer >> efficient access to certain information, like all tickets targeted to >> a milestone, or open and owned by someone, etc. These have to be >> manually re-created as label-based queries for every project, and >> every single time you want them even for one project. > > Another option would be to use Google Code's issue tracker. While it is sort of > label-based, that's mostly just an illusion of the data entry UI. Labels of the > form CamelCaseKey-value basically create new key/value metadata pairs, and the > project admin can control the taxonomy. I believe it comes with a sensible > default set. > > ? http://code.google.com/p/support/wiki/IssueTracker I too like the google issue tracker. That and the one for github are probably my favorites. Brian > It looks like you can set up Google Code Subversion repo as a read-only mirror > of the git trunk. This would probably permit the VCS-issue tracker integration. > > ? http://code.google.com/p/support/wiki/ImportingFromGit > > http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control > > Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs, > so perhaps you could migrate the individual issues. > > ? http://code.google.com/p/support/wiki/IssueTrackerAPIPython > ? https://help.launchpad.net/API > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > ?that is made terrible by our own mad attempt to interpret it as though it had > ?an underlying truth." > ? -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From dwf at cs.toronto.edu Fri Apr 16 13:15:47 2010 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Fri, 16 Apr 2010 13:15:47 -0400 Subject: [IPython-dev] Moving to git/github In-Reply-To: References: Message-ID: <43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu> On 15-Apr-10, at 2:00 PM, Brian Granger wrote: > Another point is that github itself is one of the main reasons that I > am in favor of the transition to git. Launchpad drives me absolutely > crazy, github gives me warm fuzzy feelings and sets my mind at peace. +1 on git and GitHub in general. I think I've only ever submitted one patch to IPython but I think I'd be more inclined to do so if not for the albatross of learning Launchpad hanging over my head. Every time I try to do something as simple as report a bug or browse the source I can't seem to find the right bloody menu. David From andresete.chaos at gmail.com Fri Apr 16 13:55:55 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Fri, 16 Apr 2010 12:55:55 -0500 Subject: [IPython-dev] ipython-zmp Message-ID: Hi Guys. I am applying to GSoc with a projetc ipython-zmq, please read de documentation in http://ipython.scipy.org/moin/GSoC2010/IPythonZmq or http://ipythonzmq.blogspot.com/ and let me know your suggestions to improve this... The new branch with doc was create in contrib-dev download : bzr clone lp:~ipython-contrib/+junk/ipython-zmq Thanks guys!! -- Omar Andres Zapata Mesa Integrante Grupo de F?sica y Astrof?sica Computacional Division Ciencias de la Computaci?n (FACom Dev) Universidad de Antioquia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andresete.chaos at gmail.com Fri Apr 16 16:41:10 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Fri, 16 Apr 2010 15:41:10 -0500 Subject: [IPython-dev] About contrib-dev branch Message-ID: hi all. Why my branch in contrib-dev has +junk in the path? -- Omar Andres Zapata Mesa Integrante Grupo de F?sica y Astrof?sica Computacional Division Ciencias de la Computaci?n (FACom Dev) Universidad de Antioquia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzgash.lists at gmail.com Fri Apr 16 16:51:19 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Fri, 16 Apr 2010 15:51:19 -0500 Subject: [IPython-dev] IPythonQt GSoC update Message-ID: Hi guys. I'm upgrading the branch to the format 2a (or something, and it's awfully slow), when this is over i'm going to push the documentation about the project, it's still a little raw but since it's a prerequisite it is pretty urgent. Ii'm goint to write something deeper during the day but please, atl least go into the blog and make some comments to help me with this. I'm listing the links (they're practicaly the same): https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend http://ipythonqt.blogspot.com/ http://ipython.scipy.org/moin/GSoC2010/IPythonQt http://he1.udea.edu.co/gweb/projects/index.html#ipqt Thanks. Best regards. -- Gerardo Guti?rrez Guti?rrez Physics student Universidad de Antioquia Computationalphysics and astrophysics group (FACom ) Computational science and development branch(FACom-dev ) Usuario Linux #492295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Fri Apr 16 18:55:18 2010 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 16 Apr 2010 17:55:18 -0500 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On 2010-04-15 16:45 PM, Fernando Perez wrote: > 3. Other? BitBucket's issue tracker is pretty nice. :-) -- 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 muzgash.lists at gmail.com Fri Apr 16 19:31:30 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Fri, 16 Apr 2010 18:31:30 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. Message-ID: Hi all. I want to resume a discussion that I had with Fernando here in Medell?n a month or 2 ago and we agreed that it was an importatn part of the design of this project that has to be asked here. That is about the format in wich IPythonQt should save sessions for reloading. We were thinking ahead with the project trying to make a help widget similar to the one in mathematica(that is the best characteristic of it) so the help widget would read form a website like python's tutorial and put the code blocks in IPythonQt's cells of code and the text in text cells, this will be then writing a parser for plain text or HTML(it's better the first option i think) because those are natural ways for a QTextEdit to interpret a webpage. Then it will be natural to write the notebook sessions as plain text or HTML. We talked also about saving the sessions in rst format that will be native for ipython's documentation. I've not really evaluated the pros and cons of this choice. This is an important part for the design of every client/interface that'll talk to ipython's kernel, so they can share the same type of documentation. Have a good day. Best regards. https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend http://ipythonqt.blogspot.com/ http://ipython.scipy.org/moin/GSoC2010/IPythonQt -- Gerardo Guti?rrez Guti?rrez Physics student Universidad de Antioquia Computational physics and astrophysics group (FACom ) Computational science and development branch(FACom-dev ) Usuario Linux #492295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzgash.lists at gmail.com Sat Apr 17 20:02:01 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Sat, 17 Apr 2010 19:02:01 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: Ok i'm going to paste a fragment of a document about this topic (that I've not noticed until today) *The frontend would store, for now, 5 types of data: #. Input: this is python/ipython code to be executed. #. Output (python): result of executing Inputs. #. Standard output: from subprocesses. #. Standard error: from subprocesses. #. Text: arbitrary text. For now, we'll just store plain text and will defer to the user on how to format it, though it should be valid reST if it is later to be converted into html/pdf. The non-text cells would be stored on-disk as follows:: .. input-cell:: :id: 1 3+3 .. output-cell:: :id: 1 6 .. input-cell:: :id: 2 ls .. stdout-cell:: :id: 2 a.py b.py .. input-cell:: :id: 3 !askdfj .. stderr-cell:: :id: 3 sh: askdfj: command not found* This document clears some ideas, since the natural way for an IPython's frontend (not only IPythonQt) to load data is rst in wich Python's and IPython's documentation is written. Still I want to resume this discussion because there are still some points to clear such exporting and importing formats or if the saved session should write also the output, etc. I want to do this because I think it is not so difficult to implement and it should be part of the first release. best regards. On 16 April 2010 18:31, Gerardo Gutierrez wrote: > Hi all. > > I want to resume a discussion that I had with Fernando here in Medell?n a > month or 2 ago and we agreed that it was an importatn part of the design of > this project that has to be asked here. > > That is about the format in wich IPythonQt should save sessions for > reloading. > We were thinking ahead with the project trying to make a help widget > similar to the one in mathematica(that is the best characteristic of it) so > the help widget would read form a website like python's tutorial and put the > code blocks in IPythonQt's cells of code and the text in text cells, this > will be then writing a parser for plain text or HTML(it's better the first > option i think) because those are natural ways for a QTextEdit to interpret > a webpage. > Then it will be natural to write the notebook sessions as plain text or > HTML. > We talked also about saving the sessions in rst format that will be native > for ipython's documentation. I've not really evaluated the pros and cons of > this choice. > > This is an important part for the design of every client/interface that'll > talk to ipython's kernel, so they can share the same type of documentation. > > Have a good day. > > > Best regards. > > > https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend > http://ipythonqt.blogspot.com/ > http://ipython.scipy.org/moin/GSoC2010/IPythonQt > -- > Gerardo Guti?rrez Guti?rrez > Physics student > Universidad de Antioquia > Computational physics and astrophysics group (FACom > ) > Computational science and development branch(FACom-dev > ) > Usuario Linux #492295 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Sat Apr 17 21:08:50 2010 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 17 Apr 2010 20:08:50 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: On 2010-04-17 19:02 , Gerardo Gutierrez wrote: > Ok i'm going to paste a fragment of a document about this topic (that > I've not noticed until today) > > > /The frontend would store, for now, 5 types of data: > > #. Input: this is python/ipython code to be executed. > > #. Output (python): result of executing Inputs. > > #. Standard output: from subprocesses. > > #. Standard error: from subprocesses. > > #. Text: arbitrary text. For now, we'll just store plain text and will defer > to the user on how to format it, though it should be valid reST if it is > later to be converted into html/pdf. > > The non-text cells would be stored on-disk as follows:: > > .. input-cell:: > :id: 1 > > 3+3 > > .. output-cell:: > :id: 1 > > 6 > > .. input-cell:: > :id: 2 > > ls > > .. stdout-cell:: > :id: 2 > > a.py b.py > > .. input-cell:: > :id: 3 > > !askdfj > > .. stderr-cell:: > :id: 3 > > sh: askdfj: command not found/ > > > This document clears some ideas, since the natural way for an IPython's > frontend (not only IPythonQt) to load data is rst in wich Python's and > IPython's documentation is written. I would not say that it is natural, no. reST is a fine text markup, but not a very good datastore. The parser is difficult to work with, and there aren't any tools for generating valid reST from a parsed description. I highly recommend using xml.etree to parse and generate a simple XML format. -- 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 andresete.chaos at gmail.com Sat Apr 17 22:16:03 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Sat, 17 Apr 2010 19:16:03 -0700 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: I think xml is a good idea, because you can set data in tags, referencing different types of inputs and outputs in the ipython-qt?s editor, like stdout, stderr, ipython err, ipython out, etc. some like ============================= rst docuemnation example in ipython-qt ============================= subtitle example ------------------------ etc.... %run hello.py hello world ! #some python/iptyhon comment code 2010/4/17 Robert Kern > On 2010-04-17 19:02 , Gerardo Gutierrez wrote: > > Ok i'm going to paste a fragment of a document about this topic (that > > I've not noticed until today) > > > > > > /The frontend would store, for now, 5 types of data: > > > > #. Input: this is python/ipython code to be executed. > > > > #. Output (python): result of executing Inputs. > > > > #. Standard output: from subprocesses. > > > > #. Standard error: from subprocesses. > > > > #. Text: arbitrary text. For now, we'll just store plain text and will > defer > > to the user on how to format it, though it should be valid reST if it is > > later to be converted into html/pdf. > > > > The non-text cells would be stored on-disk as follows:: > > > > .. input-cell:: > > :id: 1 > > > > 3+3 > > > > .. output-cell:: > > :id: 1 > > > > 6 > > > > .. input-cell:: > > :id: 2 > > > > ls > > > > .. stdout-cell:: > > :id: 2 > > > > a.py b.py > > > > .. input-cell:: > > :id: 3 > > > > !askdfj > > > > .. stderr-cell:: > > :id: 3 > > > > sh: askdfj: command not found/ > > > > > > This document clears some ideas, since the natural way for an IPython's > > frontend (not only IPythonQt) to load data is rst in wich Python's and > > IPython's documentation is written. > > I would not say that it is natural, no. reST is a fine text markup, but not > a > very good datastore. The parser is difficult to work with, and there aren't > any > tools for generating valid reST from a parsed description. > > I highly recommend using xml.etree to parse and generate a simple XML > format. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andresete.chaos at gmail.com Sun Apr 18 16:14:27 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Sun, 18 Apr 2010 15:14:27 -0500 Subject: [IPython-dev] Porting python3 Message-ID: Hi all, I am working in port iplib and some core files of ipython to python3, to make some test in the system zmq, but is better know if we have some plan to do this or some especail repo with someting writed. Thanks! -- Omar Andres Zapata Mesa Auxiliar programmer in Phenomenology of Fundamental Interactions Group ( Gfif ) Programmer Computational Physics and Astrophysics Group Division of computer science (FACom ) Ingenier?a de Sistemas Universidad de Antioquia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzgash.lists at gmail.com Mon Apr 19 02:35:23 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Mon, 19 Apr 2010 01:35:23 -0500 Subject: [IPython-dev] IPythonQt GSoC update In-Reply-To: References: Message-ID: Hi all. Some later updates: *Mark Summerfield wrote on the blog: I think you will find QPlainTextEdit more suitable that QTextEdit. Its layout engine is much faster and it supports colors, bold, etc. (It doesn't support tables, lists & frames, but presumably you don't need them.) Also, you can use QSyntaxHighlighter with QPlainTextEdit just the same as QTextEdit. I don't really had that in mind just because of the easiness of exporting the entire session to html, but the differences between QPlainTextEdit and QTextEdit are minimal. so the design can be initially with a QPlainTextEdit and if something comes up the update to a QTextEdit should be easy enough to not to worry for now since the exporting and saving of sessions are still in discussion. *The documentation (in the blog, wiki and branch) has been updated, it has more details about each one of the two main parts of the project and a required piece of documentation for the event ("possible future directions"). Please let us know your ideas or questions writing ni the blog or through here, we'll appreciate your support. Best regards. -- Gerardo Guti?rrez Guti?rrez Physics student Universidad de Antioquia Computational physics and astrophysics group (FACom ) Computational science and development branch(FACom-dev ) Usuario Linux #492295 On 16 April 2010 15:51, Gerardo Gutierrez wrote: > Hi guys. > > I'm upgrading the branch to the format 2a (or something, and it's awfully > slow), when this is over i'm going to push the documentation about the > project, it's still a little raw but since it's a prerequisite it is pretty > urgent. > Ii'm goint to write something deeper during the day but please, atl least > go into the blog and make some comments to help me with this. > > I'm listing the links (they're practicaly the same): > > https://code.launchpad.net/~ipython-contrib/ipython/qt-frontend > http://ipythonqt.blogspot.com/ > http://ipython.scipy.org/moin/GSoC2010/IPythonQt > http://he1.udea.edu.co/gweb/projects/index.html#ipqt > Thanks. > > Best regards. > -- > Gerardo Guti?rrez Guti?rrez > Physics student > Universidad de Antioquia > Computationalphysics and astrophysics group (FACom > ) > Computational science and development branch(FACom-dev > ) > Usuario Linux #492295 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzgash.lists at gmail.com Mon Apr 19 03:37:17 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Mon, 19 Apr 2010 02:37:17 -0500 Subject: [IPython-dev] IPythonQt GSoC update In-Reply-To: References: Message-ID: Here I'm forwarding another couple of e-mails from a discussion with Mark Summerfield. It is pretty exciting to have the interest (I think) and the opinion of such a great programmer. Hi Mark, as always a pleasure to receive your comments. *On 19 April 2010 01:25, Mark Summerfield wrote: Hi Gerardo, It took me a moment or so but I think I understand. "In [1]" is the first input, then comes the first output "NameError...", then the next input "In [2]", then the second output "Out [2]...".* Out[2] would mean the output of In[2]. There are various types of otputs in IPython like that error from the first output that will not be referenced, I'll explain below. *But I don't understand why you need to name the outputs? Also "In [1]:", "In [2]:" etc., seems a bit long, I'd have thought that "#1:", "#2", etc. would be sufficient for input, and no label for output? (Unless of course the output can be referred to?)* * *This type of reference is to keep the notation of IPython. Also in IPython all outputs are stored in a dictionary named Out, so you can type Out[2] or the alias _2 to get the output of the second input for example. *Regarding the GUI, how can the user navigate to earlier in/out sequences since there is no scrollbar?* In the snapshot there's no scrolling bar yet, because it is a prototype of the front view (and because there are no enough cells), so it still doesn't do anything at all(but being nice) but definitively it has to have a scrollbar. *Also, it looks like only the File menu has a keyboard accelerator. I very much hope that you will make the entire user interface keyboard navigable for those who cannot use the mouse (and for fast typists who don't want to use the mouse).* * *Sure, I myself am not a fan of mouse and the goal is to reach a lot of end-users. *I haven't used ipython, but from your screenshot I'm guessing that "Magic Commands" are shell-like commands that are understood alongside pure python in an input editor? Might there not be more than 6 of these? Shouldn't they be in a QScrollArea (or maybe they are already?)* * *Magic commands are IPython's functions which allow you to control the behaviour of IPython itself and also a lot of system-type features. They are used typing a % before the magic command, you can list them with %lsmagic and view the documentation with %magic. Yes, there would be a scrollbar too, but as I said above this is just a protoype. *Good luck!* Thanks again Mark, all this important details are going directly into my TODO list. And most importantly I have come to realize that that kind of information should be explained in a better way for Qt developers, people who don't use IPython or a curious non-related plausible user. I hope I have answered your questions and as always, any comment that you have about this project would be very welcome. P.D. About the last e-mail, the second paragraph ("I don't really...") is my answer to what Mark commented in the blog. Best regards. -- Gerardo Guti?rrez Guti?rrez Physics student Universidad de Antioquia Computational physics and astrophysics group (FACom ) Computational science and development branch(FACom-dev ) Usuario Linux #492295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Apr 19 16:37:06 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 19 Apr 2010 22:37:06 +0200 Subject: [IPython-dev] Engineering formatting Message-ID: Hi all, This is probably an easy question, but how do I tweak IPython to display my numerical results in engineering notation? Regards St?fan From wackywendell at gmail.com Tue Apr 20 08:55:00 2010 From: wackywendell at gmail.com (Wendell Smith) Date: Tue, 20 Apr 2010 14:55:00 +0200 Subject: [IPython-dev] Curses Frontend Update Message-ID: <4BCDA424.1080609@gmail.com> Hello! I have been busy coding away, trying to get two prototypes written for the eventual curses frontend. They are EXTREMELY basic - they don't even interpret code, just spit it back out (although in the right place and correctly colored). They are full of bugs, don't resize well, etc. - but, well, they are prototypes. What they do: They both have 3 windows: completions, output, and input. The completions window shows some default text, the input window accepts text input, and after hitting enter or , the entered code is highlighted and displayed in the output window. I wrote these both mainly to compare urwid and curses, which I think they do fairly well. the urwid library is quite nice, and although documentation is not perfect, it is good, and the whole thing provides far more than curses - curses requires you to manually handle resizing, for example. The code for the urwid part is therefore far simpler, and was written much faster. It of course requires urwid (easy_install urwid), and both require pygments (also available with easy_install). Urwid is much nicer... but development is only semi-active, and they don't seem at all prepared to port to python3, which is of course important. Anyways, please download the code, run the prototypes, tell me what you think! Code is on github here: git://github.com/wackywendell/ipyurwid.git git://github.com/wackywendell/ipycurses.git -Wendell From robert.kern at gmail.com Tue Apr 20 13:46:05 2010 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 20 Apr 2010 12:46:05 -0500 Subject: [IPython-dev] Engineering formatting In-Reply-To: References: Message-ID: On 4/19/10 3:37 PM, St?fan van der Walt wrote: > Hi all, > > This is probably an easy question, but how do I tweak IPython to > display my numerical results in engineering notation? Use the pretty extension! In your ipy_user_conf.py: from IPython.Extensions import ipy_pretty ipy_pretty.activate() def float_eng_pprinter(obj, p, cycle): p.text('%e' % obj) def array_eng_pprinter(obj, p, cycle): # ... Left as exercise for the reader. ipy_pretty.for_type(float, float_eng_pprinter) ipy_pretty.for_type_by_name('numpy', 'ndarray', array_eng_pprinter) -- 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 warren.weckesser at enthought.com Wed Apr 21 12:17:59 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Wed, 21 Apr 2010 11:17:59 -0500 Subject: [IPython-dev] Engineering formatting In-Reply-To: References: Message-ID: <4BCF2537.9000500@enthought.com> (I might have sent already sent a slight variation of this email--if so, sorry for the spam.) Robert Kern wrote: > On 4/19/10 3:37 PM, St?fan van der Walt wrote: > >> Hi all, >> >> This is probably an easy question, but how do I tweak IPython to >> display my numerical results in engineering notation? >> > > Use the pretty extension! In your ipy_user_conf.py: > > > from IPython.Extensions import ipy_pretty > > ipy_pretty.activate() > > def float_eng_pprinter(obj, p, cycle): > p.text('%e' % obj) > That shows the printing 'hook' that is needed, but for engineering notation, one wants the power of 10 to be a multiple of three. Attached is some code that I have used to do this. Following Robert's example, but defining float_eng_pprinter like this: def float_eng_pprinter(obj, p, cycle): p.text(eng_format(obj)) scalar floats are printed in engineering format. E.g. In [25]: x = 12345.67 In [26]: y = 3.451e-7 In [27]: x Out[27]: 12.346e3 In [28]: y Out[28]: 345.100e-9 Making this work for arrays still remains as an exercise for the reader. :) Warren -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: eng.py URL: From fperez.net at gmail.com Wed Apr 21 22:58:57 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Apr 2010 19:58:57 -0700 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: <4BCDA424.1080609@gmail.com> References: <4BCDA424.1080609@gmail.com> Message-ID: Hi Wendell, On Tue, Apr 20, 2010 at 5:55 AM, Wendell Smith wrote: > Hello! > > I have been busy coding away, trying to get two prototypes written for > the eventual curses frontend. > > They are EXTREMELY basic - they don't even interpret code, just spit it > back out (although in the right place and correctly colored). They are > full of bugs, don't resize well, etc. - but, well, they are prototypes. > > What they do: > They both have 3 windows: completions, output, and input. The > completions window shows some default text, the input window accepts > text input, and after hitting enter or , the entered code is > highlighted and displayed in the output window. > > I wrote these both mainly to compare urwid and curses, which I think > they do fairly well. the urwid library is quite nice, and although > documentation is not perfect, it is good, and the whole thing provides > far more than curses - curses requires you to manually handle resizing, > for example. The code for the urwid part is therefore far simpler, and > was written much faster. It of course requires urwid (easy_install > urwid), and both require pygments (also available with easy_install). > Urwid is much nicer... but development is only semi-active, and they > don't seem at all prepared to port to python3, which is of course important. > > Anyways, please download the code, run the prototypes, tell me what you > think! > > Code is on github here: > git://github.com/wackywendell/ipyurwid.git > git://github.com/wackywendell/ipycurses.git Great! A few comments: - On ubuntu 9.10, I get this for the urwid code: (master)amirbar[ipyurwid]> python interpreterwidget.py Traceback (most recent call last): File "interpreterwidget.py", line 112, in interp = fakeinterpreter(mainwin) File "interpreterwidget.py", line 81, in __init__ self.formatter = UrwidFormatter(style=s) File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line 29, in __init__ self._setup_styles(colors) File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line 92, in _setup_styles fgcolstr, bgcolstr, othersettings, colors) File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line 72, in findclosestattr fg = self.findclosest(fgcolstr, colors) File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line 54, in findclosest bestcol = urwid.AttrSpec('h0','default') AttributeError: 'module' object has no attribute 'AttrSpec' I have: In [2]: urwid.__version__ Out[2]: '0.9.8.4' Do I need a newer urwid to test out? Still, this is a tough one: I am genuinely worried about depending on a possibly undeveloped project. Have you contacted the urwid devs to find out a little bit about future plans/py3 development ideas? Using curses when urwid is around may feel painful, but at this point closing the door on py3k development possibilities sounds a little dangerous for us. On the other hand, I do see the differences: amirbar[wendell]> wc -l ipyurwid/*py 117 ipyurwid/interpreterwidget.py 252 ipyurwid/palette_test.py 105 ipyurwid/urwidpygments.py 474 total amirbar[wendell]> wc -l ipycurses/*py 151 ipycurses/basicsequence.py 142 ipycurses/cursesextras.py 71 ipycurses/cursesparser.py 347 ipycurses/cursespygments.py 32 ipycurses/interpreterwidget.py 11 ipycurses/ipythontest.py 18 ipycurses/keytester.py 57 ipycurses/prototype.py 66 ipycurses/tester.py 241 ipycurses/vipad.py 123 ipycurses/vipadtester.py 1259 total Since I can't run the urwid code right now, how equivalent are the two in terms of functionality? I'm basically trying to gauge if the above line counts can be fairly compared... Cheers, f From fperez.net at gmail.com Thu Apr 22 01:16:58 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Apr 2010 22:16:58 -0700 Subject: [IPython-dev] IPythonQt GSoC update In-Reply-To: References: Message-ID: On Sun, Apr 18, 2010 at 11:35 PM, Gerardo Gutierrez wrote: > > *Mark Summerfield wrote on the blog: > > I think you will find QPlainTextEdit more suitable that QTextEdit. Its > layout engine is much faster and it supports colors, bold, etc. (It doesn't > support tables, lists & frames, but presumably you don't need them.) Also, > you can use QSyntaxHighlighter with QPlainTextEdit just the same as > QTextEdit. > > I don't really had that in mind just because of the easiness of exporting > the entire session to html, but the differences between QPlainTextEdit and > QTextEdit are minimal. so the design can be initially with a QPlainTextEdit > and if something comes up the update to a QTextEdit should be easy enough to > not to worry for now since the exporting and saving of sessions are still in > discussion. Mark's comments on speed of layout may be worth keeping in mind though: once a session has hundreds of cells, speed may start to matter. > *The documentation (in the blog, wiki and branch) has been updated, it has > more details about each one of the two main parts of the project and a > required piece of documentation for the event ("possible future > directions"). Please let us know your ideas or questions writing ni the blog > or through here, we'll appreciate your support. Thanks for updating the branch. I'll try to get to the reviews ASAP (both this one and the zmq one) so that you can stop using Bzr and spend your energy on git instead. Cheers, f From fperez.net at gmail.com Thu Apr 22 01:19:30 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Apr 2010 22:19:30 -0700 Subject: [IPython-dev] Porting python3 In-Reply-To: References: Message-ID: Hi Omar, 2010/4/18 Omar Andr?s Zapata Mesa : > Hi all, > I am working in port iplib and some core files of ipython to python3, to > make some test in the system zmq, > but is better know if we have some plan to do this or some especail repo > with someting writed. It's important to note that the zmq project would provide the *foundation* for a python3 port, but it's not tasked directly with porting anything at all. For this project, you should focus on creating the zmq support and the 2-process implementation that retains 100% of IPython's functionality. Once that is done, we'll have ahead of us the task of moving from Twisted to zmq for the distributed computing aspects, a non-trivial problem but one that will be very interesting to tackle. Only once twisted is out of the picture will we be able to consider a full py3 port. Let me know if any of this isn't clear to you. Best, f From fperez.net at gmail.com Thu Apr 22 01:20:32 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 21 Apr 2010 22:20:32 -0700 Subject: [IPython-dev] Windows crash - pyreadline? [was Re: IPython Crash Report] In-Reply-To: References: Message-ID: On Sun, Apr 18, 2010 at 9:05 AM, Tom Plunket wrote: > I finally tried this again on another machine, with different versions of > things and on 32-bit Python.? The crash did not happen.? So, maybe it's > 64-bit only?? I get the same output as Fernando.? I just realized, I should > try the same thing at the stock Python prompt; why that hadn't come to mind > earlier I don't know. I suppose it could be a windows-64 bit specific problem, I'm afraid I won't be able to help much on that front... Cheers, f From andresete.chaos at gmail.com Thu Apr 22 10:55:13 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Thu, 22 Apr 2010 09:55:13 -0500 Subject: [IPython-dev] Porting python3 In-Reply-To: References: Message-ID: Hi Fernando. Ok not problem I am working hardly in zmq prototypes writing a good implementation of json library, and I am having frequent meetings with Jorge Zuluaga to refine the ipython-zmq`s design. I had talked to Brian about a howto I'm doing and a new branch for experimental ipython-zmq code. Brian suggested me to write the howto on the blog then I am writing a "howto" to test ipython-zmq in my blog http://ipythonzmq.blogspot.com/ and I create a new branch lp:~ipython-contrib/+junk/ipython-zmq-dev but has nothing yet, because I am ordering code. I will upload some code tonight. The ipython-zmq`s documentation branch is lp:~ipython-contrib/+junk/ipython-zmq. Thanks!! El 22 de abril de 2010 00:19, Fernando Perez escribi?: > Hi Omar, > > 2010/4/18 Omar Andr?s Zapata Mesa : > > Hi all, > > I am working in port iplib and some core files of ipython to python3, to > > make some test in the system zmq, > > but is better know if we have some plan to do this or some especail repo > > with someting writed. > > It's important to note that the zmq project would provide the > *foundation* for a python3 port, but it's not tasked directly with > porting anything at all. For this project, you should focus on > creating the zmq support and the 2-process implementation that retains > 100% of IPython's functionality. > > Once that is done, we'll have ahead of us the task of moving from > Twisted to zmq for the distributed computing aspects, a non-trivial > problem but one that will be very interesting to tackle. > > Only once twisted is out of the picture will we be able to consider a > full py3 port. > > Let me know if any of this isn't clear to you. > > Best, > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Apr 22 12:52:18 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Apr 2010 09:52:18 -0700 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern wrote: > I would not say that it is natural, no. reST is a fine text markup, but not a > very good datastore. The parser is difficult to work with, and there aren't any > tools for generating valid reST from a parsed description. > > I highly recommend using xml.etree to parse and generate a simple XML format. This does have the advantage of using good tools already in the stdlib, a huge plus. I'm growing warmer to the xml idea, I have to admit... Cheers, f From fperez.net at gmail.com Thu Apr 22 12:53:36 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Apr 2010 09:53:36 -0700 Subject: [IPython-dev] About contrib-dev branch In-Reply-To: References: Message-ID: Hi Omar, 2010/4/16 Omar Andr?s Zapata Mesa : > hi all. > Why my branch in contrib-dev has +junk in the path? It's just how it got created, and Launchpad uses +junk to denote branches that were not directly attached to a project. It's easy to fix but don't worry about it: it won't get deleted or anything, and since we'll move to github soon, there's no point in spending time on it. I can still review it and merge from it there, so don't worry. Cheers, f From fperez.net at gmail.com Thu Apr 22 12:56:32 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Apr 2010 09:56:32 -0700 Subject: [IPython-dev] Moving to git/github In-Reply-To: <43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu> References: <43577B5A-8D7F-42C0-A27C-E583F4161D49@cs.toronto.edu> Message-ID: On Fri, Apr 16, 2010 at 10:15 AM, David Warde-Farley wrote: > > > +1 on git and GitHub in general. I think I've only ever submitted one > patch to IPython but I think I'd be more inclined to do so if not for > the albatross of learning Launchpad hanging over my head. Every time I > try to do something as simple as report a bug or browse the source I > can't seem to find the right bloody menu. Thanks David, it seems we have clear support (if not unanimous) for a github-based solution, and most certainly for moving away from LP. The proof will be in the pudding, but I certainly hope this will make it easier for people such as yourself to have a lower barrier to making contributions, without the tools and interface getting in your way. I'm going to spend a bit of time writing a bug transition script so we can move our bugs from LP to Github without data loss, and I'll report back when things are ready to move. Cheers, f From andresete.chaos at gmail.com Thu Apr 22 17:49:44 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Thu, 22 Apr 2010 16:49:44 -0500 Subject: [IPython-dev] About contrib-dev branch In-Reply-To: References: Message-ID: Hi Fernando. Thanks for the help, very soon I will give you more news on how the project will work, tomorrow I have meeting with Zuluaga and I have to hand over the homework ( a diagram with more detailed design work). Thanks El 22 de abril de 2010 11:53, Fernando Perez escribi?: > Hi Omar, > > 2010/4/16 Omar Andr?s Zapata Mesa : > > hi all. > > Why my branch in contrib-dev has +junk in the path? > > It's just how it got created, and Launchpad uses +junk to denote > branches that were not directly attached to a project. > > It's easy to fix but don't worry about it: it won't get deleted or > anything, and since we'll move to github soon, there's no point in > spending time on it. I can still review it and merge from it there, > so don't worry. > > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Apr 22 23:53:27 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Apr 2010 20:53:27 -0700 Subject: [IPython-dev] autocall print() bug finally fixed! Message-ID: Hi everyone, I just wanted to mention this because this bug is *extremely* annoying; thanks to Robert's tip, we've been able to finally close the bug where autocall would misfire on print statements for python 2.6 and newer like this: In [1]: print 1, 2, 3 ------> print(1, 2, 3) (1, 2, 3) The full report is here: https://bugs.launchpad.net/ipython/+bug/414967 now things work OK: In [1]: print 1,2,3 1 2 3 In [2]: from __future__ import print_function In [3]: print 1,2,3 ------> print(1,2,3) 1 2 3 You do need to be running from bzr, but I did apply the fix both to 0.10.1 and trunk, so this particularly annoying problem is finally gone. Cheers, f From wackywendell at gmail.com Fri Apr 23 03:37:52 2010 From: wackywendell at gmail.com (Wendell Smith) Date: Fri, 23 Apr 2010 09:37:52 +0200 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: <4BD14DC0.9080202@gmail.com> References: <4BCDA424.1080609@gmail.com> <4BD14DC0.9080202@gmail.com> Message-ID: <4BD14E50.6000800@gmail.com> Hi! Yes, you do need to upgrade urwid. I have 0.9.9.1, which is also the latest in pypi, so 'easy_install -U urwid' should do it. Secondly, I agree about dropping Urwid. I hate to do it... but, well, python 3 support is definitely something I want, and when I asked them... they basically said they hadn't thought much about it. As for line counts... they are pretty accurate. Both versions come with some testing code that is unnecessary ('keytester.py' and 'vipadtester.py' in curses, 'palette_test.py' in urwid), but if you removed those, the line counts would be even more skewed in favor of urwid. As for functionality, they are quite close - except that the urwid version handles resizing events just from the library, and the curses code looks terrible / would crash after resizing, and I'll need to write that. So... yes, it would be really nice to use urwid... but I may never be able to with python3, so I guess I can't, unfortunately. That's OK, and as my curses implementation shows, it may be more difficult with the built in curses library, but its definitely possible. I still have a long todo list before I start doing any interpreter stuff: - rewrite vipad (in curses - my current implementation is cool, but not that useful) - write a nice editbox window (needed for either urwid or curses if we want coloring as you type) - get scrolling to work (needed either way, although I believe urwid has a widget for that) - allow for resizing (in curses) - handle adjustable-size completions box (done in urwid, not too hard in curses once resizing is handled) I'm sure there's more... but that's all I've thought of so far. Anyways, thanks for the comments! -Wendell On 04/22/2010 04:58 AM, Fernando Perez wrote: > Hi Wendell, > > On Tue, Apr 20, 2010 at 5:55 AM, Wendell > Smith wrote: >> Hello! >> >> I have been busy coding away, trying to get two prototypes written for >> the eventual curses frontend. >> >> They are EXTREMELY basic - they don't even interpret code, just spit it >> back out (although in the right place and correctly colored). They are >> full of bugs, don't resize well, etc. - but, well, they are prototypes. >> >> What they do: >> They both have 3 windows: completions, output, and input. The >> completions window shows some default text, the input window accepts >> text input, and after hitting enter or, the entered code is >> highlighted and displayed in the output window. >> >> I wrote these both mainly to compare urwid and curses, which I think >> they do fairly well. the urwid library is quite nice, and although >> documentation is not perfect, it is good, and the whole thing provides >> far more than curses - curses requires you to manually handle resizing, >> for example. The code for the urwid part is therefore far simpler, and >> was written much faster. It of course requires urwid (easy_install >> urwid), and both require pygments (also available with easy_install). >> Urwid is much nicer... but development is only semi-active, and they >> don't seem at all prepared to port to python3, which is of course >> important. >> >> Anyways, please download the code, run the prototypes, tell me what you >> think! >> >> Code is on github here: >> git://github.com/wackywendell/ipyurwid.git >> git://github.com/wackywendell/ipycurses.git > Great! A few comments: > > - On ubuntu 9.10, I get this for the urwid code: > > (master)amirbar[ipyurwid]> python interpreterwidget.py > Traceback (most recent call last): > File "interpreterwidget.py", line 112, in > interp = fakeinterpreter(mainwin) > File "interpreterwidget.py", line 81, in __init__ > self.formatter = UrwidFormatter(style=s) > File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line > 29, in __init__ > self._setup_styles(colors) > File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line > 92, in _setup_styles > fgcolstr, bgcolstr, othersettings, colors) > File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line > 72, in findclosestattr > fg = self.findclosest(fgcolstr, colors) > File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line > 54, in findclosest > bestcol = urwid.AttrSpec('h0','default') > AttributeError: 'module' object has no attribute 'AttrSpec' > > I have: > > In [2]: urwid.__version__ > Out[2]: '0.9.8.4' > > Do I need a newer urwid to test out? > > Still, this is a tough one: I am genuinely worried about depending on > a possibly undeveloped project. Have you contacted the urwid devs to > find out a little bit about future plans/py3 development ideas? > > Using curses when urwid is around may feel painful, but at this point > closing the door on py3k development possibilities sounds a little > dangerous for us. On the other hand, I do see the differences: > > amirbar[wendell]> wc -l ipyurwid/*py > 117 ipyurwid/interpreterwidget.py > 252 ipyurwid/palette_test.py > 105 ipyurwid/urwidpygments.py > 474 total > > amirbar[wendell]> wc -l ipycurses/*py > 151 ipycurses/basicsequence.py > 142 ipycurses/cursesextras.py > 71 ipycurses/cursesparser.py > 347 ipycurses/cursespygments.py > 32 ipycurses/interpreterwidget.py > 11 ipycurses/ipythontest.py > 18 ipycurses/keytester.py > 57 ipycurses/prototype.py > 66 ipycurses/tester.py > 241 ipycurses/vipad.py > 123 ipycurses/vipadtester.py > 1259 total > > Since I can't run the urwid code right now, how equivalent are the two > in terms of functionality? I'm basically trying to gauge if the above > line counts can be fairly compared... > > Cheers, > > f From antont at an.org Sat Apr 24 00:09:05 2010 From: antont at an.org (Toni Alatalo) Date: Sat, 24 Apr 2010 07:09:05 +0300 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: References: <4BCDA424.1080609@gmail.com> Message-ID: <4BD26EE1.3030606@an.org> Fernando Perez kirjoitti: >> they do fairly well. the urwid library is quite nice, and although >> documentation is not perfect, it is good, and the whole thing provides >> far more than curses - curses requires you to manually handle resizing, >> for example. The code for the urwid part is therefore far simpler, and > Still, this is a tough one: I am genuinely worried about depending on > a possibly undeveloped project. Have you contacted the urwid devs to > find out a little bit about future plans/py3 development ideas? One way to think about it is to compare the efforts of: a) reimplementing things that urwid does, like handling resizing mentioned above etc., in the ipython curses frontend vs b) converting urwid to py3k yourself (shouldn't that be relatively easy with 2to3 for a small pure py lib?) I do agree it's a tough one. There is the danger that the person doing that ends up being the urwid maintainer in general if other devs are not active. That has been happening with my and PythonQt (the qtscript like thing for embedded py in qt apps) now, kind of, 'cause am so far the only one who has made it to work on Qt 4.6 (with an ugly hack) and haven't heard back from questions nor patches etc., that's not fun when you have a lot of other things todo .. but another story alltogether. > Using curses when urwid is around may feel painful, but at this point > closing the door on py3k development possibilities sounds a little There are few closed doors with open source :) I guess depends on how useful Urwid is in general, and whether there are other uses and devs who fix etc. it otherwise and are eventually switching over to py3k too. So what Fernando suggested about asking around seems to be the thing to do indeed. 2cently yours, ~Toni > dangerous for us. On the other hand, I do see the differences: > > amirbar[wendell]> wc -l ipyurwid/*py > 117 ipyurwid/interpreterwidget.py > 252 ipyurwid/palette_test.py > 105 ipyurwid/urwidpygments.py > 474 total > > amirbar[wendell]> wc -l ipycurses/*py > 151 ipycurses/basicsequence.py > 142 ipycurses/cursesextras.py > 71 ipycurses/cursesparser.py > 347 ipycurses/cursespygments.py > 32 ipycurses/interpreterwidget.py > 11 ipycurses/ipythontest.py > 18 ipycurses/keytester.py > 57 ipycurses/prototype.py > 66 ipycurses/tester.py > 241 ipycurses/vipad.py > 123 ipycurses/vipadtester.py > 1259 total > > Since I can't run the urwid code right now, how equivalent are the two > in terms of functionality? I'm basically trying to gauge if the above > line counts can be fairly compared... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From stefan at sun.ac.za Sat Apr 24 14:35:42 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 24 Apr 2010 20:35:42 +0200 Subject: [IPython-dev] Engineering formatting In-Reply-To: <4BCF2537.9000500@enthought.com> References: <4BCF2537.9000500@enthought.com> Message-ID: Hey Warren, Robert On 21 April 2010 18:17, Warren Weckesser wrote: > Robert Kern wrote: >> On 4/19/10 3:37 PM, St?fan van der Walt wrote: >> >>> Hi all, >>> >>> This is probably an easy question, but how do I tweak IPython to >>> display my numerical results in engineering notation? >>> >> >> Use the pretty extension! In your ipy_user_conf.py: [...] > Following Robert's example, but defining float_eng_pprinter like this: > > def float_eng_pprinter(obj, p, cycle): > ? p.text(eng_format(obj)) [...] Thanks for the code snippets! I've put them into a profile and added array printing (attached). Maybe a useful profile to distribute? Regards St?fan -------------- next part -------------- A non-text attachment was scrubbed... Name: ipython_config_eng.py Type: text/x-python-script Size: 1672 bytes Desc: not available URL: From stefan at sun.ac.za Sat Apr 24 14:42:42 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 24 Apr 2010 20:42:42 +0200 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: <4BCDA424.1080609@gmail.com> References: <4BCDA424.1080609@gmail.com> Message-ID: Hi Wendell On 20 April 2010 14:55, Wendell Smith wrote: > Anyways, please download the code, run the prototypes, tell me what you > think! > > Code is on github here: > git://github.com/wackywendell/ipyurwid.git Cool idea! I see the code being copied from the input box to the text box, but on my terminal everything is flashing after being syntax-highlighted---is this normal? I assume the completions window isn't working yet, since TAB and ENTER does the same for me. Cheers St?fan From stefan at sun.ac.za Sat Apr 24 15:27:32 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 24 Apr 2010 21:27:32 +0200 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On 17 April 2010 00:55, Robert Kern wrote: > On 2010-04-15 16:45 PM, Fernando Perez wrote: > >> 3. Other? > > BitBucket's issue tracker is pretty nice. > > ?:-) Talking about strange bug trackers, I've noticed that IPython is even used as part of one! http://pitz.tplus1.com/main-idea.html#what-is-pitz (see bottom of page) In a similar vein, there is: http://bugseverywhere.org/be/show/HomePage What interests me about this approach is the handy way of merging bugs on branches along with code. St?fan From fperez.net at gmail.com Sat Apr 24 21:23:37 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 24 Apr 2010 18:23:37 -0700 Subject: [IPython-dev] Bug triage frenzy Message-ID: Hi all, if you are on the -dev team, you may see a flurry of emails from LP. I'm in the process of triaging what I can in LP, so we only import into github valid bugs. I'm being fairly liberal, marking as invalid/won't fix only things I'm convinced are fixed in trunk or truly invalid, as I'd rather let a few false positives through than ignore good reports. If you are feeling generous and want to help, anything you do to triage new open bugs: https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search will be appreciated. I've now succeded in downloading to local python objects the entire ipython bug database from LP, now I just need to figure out how to programatically upload them to github (I'm using this ruby script as a guide: http://github.com/suitmymind/lighthouse-to-github/raw/master/migrate-lh-to-gh.rb). Then we'll be able to make the transition to GH without losing any bug history for open bugs. All new issues on GH will have a link to their parent on LP for details, though I'm trying to preserve as much metadata as I can. Cheers, f From vivainio at gmail.com Sun Apr 25 12:32:56 2010 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 25 Apr 2010 19:32:56 +0300 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: 2010/4/24 St?fan van der Walt : > > What interests me about this approach is the handy way of merging bugs > on branches along with code. Incidentally, launchpad + bzr does the same thing ;-) (--fixes option). -- Ville M. Vainio http://tinyurl.com/vainio From fperez.net at gmail.com Sun Apr 25 13:47:39 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 10:47:39 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: 2010/4/24 St?fan van der Walt : > Talking about strange bug trackers, I've noticed that IPython is even > used as part of one! > > http://pitz.tplus1.com/main-idea.html#what-is-pitz > > (see bottom of page) Cool! It's listed here: http://ipython.scipy.org/moin/About/Projects_Using_IPython But I don't remember if I added it to the page or someone else did... [ Goes and realizes that moin has history: 2009-04-14 05:51:39 FernandoPerez Add links to pitz ] OK, I guess I added that a while ago, I'd totally forgotten about it. Cheers, From fperez.net at gmail.com Sun Apr 25 13:50:10 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 10:50:10 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: 2010/4/25 Ville M. Vainio : > > Incidentally, launchpad + bzr does the same thing ;-) (--fixes option). Grumble, grumble: I should really have noticed that option :) I typically use 'closes' comments, but never noticed that --fixes existed... Thanks, I'll start using it now! f From fperez.net at gmail.com Sun Apr 25 14:07:26 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 11:07:26 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 10:50 AM, Fernando Perez wrote: > 2010/4/25 Ville M. Vainio : >> >> Incidentally, launchpad + bzr does the same thing ;-) (--fixes option). > > Grumble, grumble: I should really have noticed that option :) ?I > typically use 'closes' comments, but never noticed that --fixes > existed... > > Thanks, I'll start using it now! And indeed: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1255 It's nice that it creates the link to the bug in the commit page, it would be cool if the bug page also picked up a link to the commit automatically (like github does when you use 'closes #XX' messages, where *both* the commit page and the bug page get linked to each other). This is a nice feature, and I see they have support not just for lp but for other trackers as well, with a reasonably generic interface. Thanks again for the pointer. Cheers, f From fperez.net at gmail.com Sun Apr 25 14:17:15 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 11:17:15 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Fri, Apr 16, 2010 at 3:55 PM, Robert Kern wrote: > >> 3. Other? > > BitBucket's issue tracker is pretty nice. > > ?:-) No need to duck, nobody's shooting :) I think that integration between the source control system and the bug tracker is really useful and thus I'd rather not consider bitbucket (and I think we've settled on git by now). But it's good to see these other trackers moving forward: that will keep a fire lit under github's behind on this front, and I'm sure such pressure will help their tracker improve over time. Bitbucket does look very nice as well, with a clean interface and what appears to be a solid feature set (though ironically, everything but their front page is inaccessible to me right now with "Internal Server Error" messages :) It seems clear that both hg and git are solid, mature projects with enough large and important users to continue forward, much like Gnome and KDE never 'killed' each other, despite all the silly flamewars of the linux lists on that topic in the 90's. And I'm sure bzr will continue alive as a distant but useful third, since it also has Canonical and many projects behind it; again using the desktop/window manager analogies, XFCE and others continue to live even as Gnome/KDE are the 'big ones' in the linux world. We seem to be settling on a good set of solutions, and let's hope the Github admins prove responsive to our requests... Cheers, f From fperez.net at gmail.com Sun Apr 25 14:18:49 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 11:18:49 -0700 Subject: [IPython-dev] Bug handling: launchpad, github, other? In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 11:07 AM, Fernando Perez wrote: > It's nice that it creates the link to the bug in the commit page, it > would be cool if the bug page also picked up a link to the commit > automatically (like github does when you use 'closes #XX' messages, > where *both* the commit page and the bug page get linked to each > other). ?This is a nice feature, and I see they have support not just > for lp but for other trackers as well, with a reasonably generic > interface. ?Thanks again for the pointer. Never mind: it just took LP a while to create the backlinks, but now the bug page has been updated with links to the branches. So they do the two-way linking, great! I really should have known about this long ago, I feel silly... Thanks! f From piotr.zolnierczuk at gmail.com Sun Apr 25 14:29:35 2010 From: piotr.zolnierczuk at gmail.com (Piotr Zolnierczuk) Date: Sun, 25 Apr 2010 14:29:35 -0400 Subject: [IPython-dev] embedding ipython Message-ID: Hi, I have been using an embedded IPython shell (sorry I am still at 0.9.1) in a wxPython app for quite some time and I (and my users) like very much. I cloned IPython.gui.wx.ipython_view to customize look-and-feel with the rest of my app. My app has a bunch of "GUI" tabs that control physics experiment hardware (neutron scattering at Oak Ridge National Lab) and one tab that is the IPython shell that allows for "custom" scripts. The main app needs to "pass" some objects into the shell, for example an object that is responsible for communication with the control hardware, so it can be used in the interactive shell. I used user_ns dictionary for it and it works for me. Now I have a bunch of questions, so please bear with me: a) what is the difference between user_ns and user_global_ns (in particular in IPython.gui.wx.ipshell_nonblocking)? b) the example (wxIPython) as well I my embedded shell do not fill _oh dictionary and '_' is always empty so users cannot "recall" the results of the previous statement. The ipython shell works fine in that respect. Why wxIPython does not? c) could "passing" of the objects be done via 'configuration' file? If yes, how?. d) could an external app execute a script (function) via IPython shell? e) some users suggested a capability where user "queues" scripts and then some kernel executes them one-by-one. Anybody knows a good python solution for that? Thanks for your patience :) Any help, directions, etc greatly appreciated Piotr -- Piotr Adam Zolnierczuk e-mail: piotr at zolnierczuk.net www: http://www.zolnierczuk.net _____________________________________ written on recycled electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Apr 25 15:31:23 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 12:31:23 -0700 Subject: [IPython-dev] Demo.py on trunk In-Reply-To: <8CC88437E319138-5DFC-537@webmail-d060.sysops.aol.com> References: <8CC88437E319138-5DFC-537@webmail-d060.sysops.aol.com> Message-ID: Hi there, On Tue, Mar 2, 2010 at 10:18 AM, wrote: > Looking a trunk to test out demo.py, I've changed the import statements to > reflect the moves due to the reorganization, but I'm running into problems > in the Demo class init method. It peeks at some of the internals of IPython > to store some information. > > specifically: > > self.ip_colorize = __IPYTHON__.pycolorize > self.ip_runlines = __IPYTHON__.runlines > self.ip_showtb = __IPYTHON__.showtraceback > self.ip_runlines = __IPYTHON__.runlines > self.shell = __IPYTHON__ > > this info is not stored at __IPYTHON__ any more, does someone know where it > is & how to get/set it? > By the way, I just fixed this yesterday in trunk during the bug blitz. Cheers, f -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Apr 25 16:34:46 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 13:34:46 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review Message-ID: Hi all, Matthew Brett has just finished writing up a first draft of a simple, *self-contained* description of how to download, contribute to and develop a github-hosted project: - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ - source repo: http://github.com/matthew-brett/gitwash We expect to use this to help the nipy project transition from bzr to git/github, and also to use it for IPython. So we'd like to submit it for further feedback here, in your minds replace the hypothetical 'gitwash' with 'IPython' and that's what we would ultimately use as our intro document for anyone wanting to work from the sources. This document should: - be easy to read in a short amount of time, without users new to git/github having to read 10 different Git tutorials (which may be very good, but may also overwhelm a newcomer with information that he or she initially doesn't know how to prioritize for relevance). - enable a newcomer to the project to download it with no complications, but to later transition to doing development with a minimal threshold. - enable someone who knows they want to develop (or existing ipython/nipy developers) to get started right away. Obviously once people are comfortable with the basics they will want (and should) read some of the excellent git/gh documentation out there. But at that point they will be in a position to digest it and benefit from it, which may not be true at the raw start. If the document fails in *any* way at this, please let us know. Any lack of clarity, any confusion, any dark spots should be pointed out, we want to make this as painless as possible for everyone involved. Cheers, f From fperez.net at gmail.com Sun Apr 25 16:42:43 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 13:42:43 -0700 Subject: [IPython-dev] Porting python3 In-Reply-To: References: Message-ID: 2010/4/22 Omar Andr?s Zapata Mesa : > Ok not problem I am working hardly in zmq prototypes writing a good > implementation of json library, and? I am having frequent meetings with > Jorge Zuluaga to refine the ipython-zmq`s design. Do you mean you are writing a *new* json library? Why? Python 2.6 ships with a json module out of the box: http://docs.python.org/library/json.html and for 2.5 it is available externally as simplejson: http://pypi.python.org/pypi/simplejson We don't need a new one... > ?I had talked to Brian about a howto I'm doing and a new branch for > experimental ipython-zmq code. > ?Brian suggested me to write the howto on the blog then I am writing a > "howto" to test ipython-zmq in my blog http://ipythonzmq.blogspot.com/? and > I create a new branch lp:~ipython-contrib/+junk/ipython-zmq-dev > but has nothing yet, because I am ordering code. I will upload some code > tonight. > > The ipython-zmq`s documentation branch is > lp:~ipython-contrib/+junk/ipython-zmq. Yes, I'm plowing through the git transition work and will review both of your branches (zmq/qt) as soon as possible. Needless to say, anyone else is invited and welcome to review this (please do so!). Cheers, f From fperez.net at gmail.com Sun Apr 25 16:55:06 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 13:55:06 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. Message-ID: Hi Omar, I just realized that because you first pushed the zmq branch on +junk (the 'private' workspace for ~ipython-contrib), Launchpad won't let us make a normal merge proposal. It seems LP only makes proper proposal for branches that are linked to a project, not on +junk. It's not worth spending time on learning this from your side, so I just went ahead and fixed it, but *you must re-branch* your work. The official zmq branch is now this one: https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq If you had no local changes unpushed, simply delete the branch you had and do bzr branch lp:~ipython-contrib/ipython/ipython-zmq to continue. This branch is now listed for merge: https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq/+merge/24087 so it can be properly reviewed. If you had any changes, just don't delete your copy yet. Do the above, then merge your local changes into the new one, push from the new one, and then destroy the other one. Cheers, f From fperez.net at gmail.com Sun Apr 25 19:04:12 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 16:04:12 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? Message-ID: Hey guys, I see you've been active on this one: https://bugs.launchpad.net/ipython/+bug/400600 It's the last remaining bug on LP that both has a patch and is still open, everything else with patches I've already committed. Since bugs with patches will be harder to auto-migrate to Gh, I'd like to close them for good while still on LP where the patch is tracked, to simplify life. If you guys have a chance to clarify the status of this one before we make the transition, it would be great. Cheers, f From andresete.chaos at gmail.com Sun Apr 25 21:03:20 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Sun, 25 Apr 2010 20:03:20 -0500 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: References: Message-ID: Hi Fernando. Ok The new code will be mounted in the new branch. talking about something else in last meeting with Zuluaga we have two problems to solve on ipython-zmq's desing. 1) is tab completion a process into Queue of zmq kernels or is a simple thread? 2) is good idea make a daemon to crash recovery system? Regards! 2010/4/25 Fernando Perez > Hi Omar, > > I just realized that because you first pushed the zmq branch on +junk > (the 'private' workspace for ~ipython-contrib), Launchpad won't let us > make a normal merge proposal. It seems LP only makes proper proposal > for branches that are linked to a project, not on +junk. > > It's not worth spending time on learning this from your side, so I > just went ahead and fixed it, but *you must re-branch* your work. The > official zmq branch is now this one: > > https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq > > If you had no local changes unpushed, simply delete the branch you had and > do > > bzr branch lp:~ipython-contrib/ipython/ipython-zmq > > to continue. This branch is now listed for merge: > > > https://code.launchpad.net/~ipython-contrib/ipython/ipython-zmq/+merge/24087 > > so it can be properly reviewed. > > If you had any changes, just don't delete your copy yet. Do the > above, then merge your local changes into the new one, push from the > new one, and then destroy the other one. > > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andresete.chaos at gmail.com Sun Apr 25 21:15:52 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Sun, 25 Apr 2010 20:15:52 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: Hi I think xml is easy way because we can write some module to ipthyton that let me read this content directly from ipython-qt' s xml file. regards. 2010/4/22 Fernando Perez > On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern > wrote: > > I would not say that it is natural, no. reST is a fine text markup, but > not a > > very good datastore. The parser is difficult to work with, and there > aren't any > > tools for generating valid reST from a parsed description. > > > > I highly recommend using xml.etree to parse and generate a simple XML > format. > > This does have the advantage of using good tools already in the > stdlib, a huge plus. > > I'm growing warmer to the xml idea, I have to admit... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Sun Apr 25 23:55:18 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 25 Apr 2010 20:55:18 -0700 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern wrote: > On 2010-04-17 19:02 , Gerardo Gutierrez wrote: >> Ok i'm going to paste a fragment of a document about this topic (that >> I've not noticed until today) >> >> >> /The frontend would store, for now, 5 types of data: >> >> #. Input: this is python/ipython code to be executed. >> >> #. Output (python): result of executing Inputs. >> >> #. Standard output: from subprocesses. >> >> #. Standard error: from subprocesses. >> >> #. Text: arbitrary text. For now, we'll just store plain text and will defer >> to the user on how to format it, though it should be valid reST if it is >> later to be converted into html/pdf. >> >> The non-text cells would be stored on-disk as follows:: >> >> .. input-cell:: >> :id: 1 >> >> 3+3 >> >> .. output-cell:: >> :id: 1 >> >> 6 >> >> .. input-cell:: >> :id: 2 >> >> ls >> >> .. stdout-cell:: >> :id: 2 >> >> a.py b.py >> >> .. input-cell:: >> :id: 3 >> >> !askdfj >> >> .. stderr-cell:: >> :id: 3 >> >> sh: askdfj: command not found/ >> >> >> This document clears some ideas, since the natural way for an IPython's >> frontend (not only IPythonQt) to load data is rst in wich Python's and >> IPython's documentation is written. > > I would not say that it is natural, no. reST is a fine text markup, but not a > very good datastore. The parser is difficult to work with, and there aren't any > tools for generating valid reST from a parsed description. I agree with Robert that reST is probably not the best option for this. > I highly recommend using xml.etree to parse and generate a simple XML format. I am not quite as excited about XML as Robert, but my feeling is this: it should be XML unless someone comes up with an option that beats it. Cheers, Brian > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > ?that is made terrible by our own mad attempt to interpret it as though it had > ?an underlying truth." > ? -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From ellisonbg at gmail.com Sun Apr 25 23:56:24 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 25 Apr 2010 20:56:24 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: This patch can be applied. Brian On Sun, Apr 25, 2010 at 4:04 PM, Fernando Perez wrote: > Hey guys, > > I see you've been active on this one: > > https://bugs.launchpad.net/ipython/+bug/400600 > > It's the last remaining bug on LP that both has a patch and is still > open, everything else with patches I've already committed. ?Since bugs > with patches will be harder to auto-migrate to Gh, I'd like to close > them for good while still on LP where the patch is tracked, to > simplify life. > > If you guys have a chance to clarify the status of this one before we > make the transition, it would be great. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From ellisonbg at gmail.com Mon Apr 26 00:11:37 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 25 Apr 2010 21:11:37 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: Message-ID: Fernando, A nice lightweight way for dev's to contribute code is to use git format-patch. I like how Sympy encourages contributions using this approach as it is super easy. I almost think that this document will have the tendency to become a larger and more involved - and eventually start to overlap with things like the progit book. In my experience, the most useful thing for new devs is having an *exact*, project specific (the real project like ipython, not gitwash) list of commands that cover %80 of the usage cases. Like: # Get your fork: git clone git at github.com:ellisonbg/ipython.git # Create a feature branch git branch foo git checkout foo # edit files, # for each file do: git add [filename] git commit # rinse and repeate # To post branch to github git push origin foo I am thinking like more of a single concise cheatsheet that covers everything a new user would want. Basically a "what to type" guide that fits on 1 page. The reason I say this is that existing references like the progit book are so extremely good, there is not reason to spend time describing the concepts. Also, I think for a new user, it will be confusing that the docs are about gitwash rather than ipython or nipy. Sorry if this is a bit pessimistic. Cheers, Brian On Sun, Apr 25, 2010 at 1:34 PM, Fernando Perez wrote: > Hi all, > > Matthew Brett has just finished writing up a first draft of a simple, > *self-contained* description of how to download, contribute to and > develop a github-hosted project: > > - rendered version of the docs: https://cirl.berkeley.edu/mb312/gitwash/ > - source repo: http://github.com/matthew-brett/gitwash > > We expect to use this to help the nipy project transition from bzr to > git/github, and also to use it for IPython. ?So we'd like to submit it > for further feedback here, in your minds replace the hypothetical > 'gitwash' with 'IPython' and that's what we would ultimately use as > our intro document for anyone wanting to work from the sources. > > This document should: > > - be easy to read in a short amount of time, without users new to > git/github having to read 10 different Git tutorials (which may be > very good, but may also overwhelm a newcomer with information that he > or she initially doesn't know how to prioritize for relevance). > > - enable a newcomer to the project to download it with no > complications, but to later transition to doing development with a > minimal threshold. > > - enable someone who knows they want to develop (or existing > ipython/nipy developers) to get started right away. > > > Obviously once people are comfortable with the basics they will want > (and should) read some of the excellent git/gh documentation out > there. ?But at that point they will be in a position to digest it and > benefit from it, which may not be true at the raw start. > > If the document fails in *any* way at this, please let us know. ?Any > lack of clarity, any confusion, any dark spots should be pointed out, > we want to make this as painless as possible for everyone involved. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From ellisonbg at gmail.com Mon Apr 26 00:19:37 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 25 Apr 2010 21:19:37 -0700 Subject: [IPython-dev] Bug triage frenzy In-Reply-To: References: Message-ID: Fernando, Wow, thanks for doing this! > if you are on the -dev team, you may see a flurry of emails from LP. > I'm in the process of triaging what I can in LP, so we only import > into github valid bugs. ?I'm being fairly liberal, marking as > invalid/won't fix only things I'm convinced are fixed in trunk or > truly invalid, as I'd rather let a few false positives through than > ignore good reports. > > If you are feeling generous and want to help, anything you do to > triage new open bugs: > > https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search > > will be appreciated. I am super busy right now so I don't think I will have a chance to do much, but I am definitely watching the progress. Please let me know if there are specific tickets you want me to look at. > I've now succeded in downloading to local python objects the entire > ipython bug database from LP, now I just need to figure out how to > programatically upload them to github (I'm using this ruby script as a > guide: http://github.com/suitmymind/lighthouse-to-github/raw/master/migrate-lh-to-gh.rb). > ?Then we'll be able to make the transition to GH without losing any > bug history for open bugs. ?All new issues on GH will have a link to > their parent on LP for details, though I'm trying to preserve as much > metadata as I can. This is great. Cheers, Brian > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From ellisonbg at gmail.com Mon Apr 26 00:25:55 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 25 Apr 2010 21:25:55 -0700 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: <4BD14E50.6000800@gmail.com> References: <4BCDA424.1080609@gmail.com> <4BD14DC0.9080202@gmail.com> <4BD14E50.6000800@gmail.com> Message-ID: Wendell, Another thing that should be considered is what the event loops look like for both curses and urwid. The reason that I saw this is that I think it will make the most sense to use 0MQ to get your frontend talking to ipython. For that, you will definitely want something of a real event loop. If urwid makes that easier then that is worth giving urwid extra consideration. Cheers, Brian On Fri, Apr 23, 2010 at 12:37 AM, Wendell Smith wrote: > Hi! > > Yes, you do need to upgrade urwid. I have 0.9.9.1, which is also the > latest in pypi, so 'easy_install -U urwid' should do it. > > Secondly, I agree about dropping Urwid. I hate to do it... but, well, > python 3 support is definitely something I want, and when I asked > them... they basically said they hadn't thought much about it. > > As for line counts... they are pretty accurate. Both versions come with > some testing code that is unnecessary ('keytester.py' and > 'vipadtester.py' in curses, 'palette_test.py' in urwid), but if you > removed those, the line counts would be even more skewed in favor of > urwid. As for functionality, they are quite close - except that the > urwid version handles resizing events just from the library, and the > curses code looks terrible / would crash after resizing, and I'll need > to write that. > > So... yes, it would be really nice to use urwid... but I may never be > able to with python3, so I guess I can't, unfortunately. That's OK, and > as my curses implementation shows, it may be more difficult with the > built in curses library, but its definitely possible. > > I still have a long todo list before I start doing any interpreter stuff: > ?- rewrite vipad (in curses - my current implementation is cool, but > not that useful) > ?- write a nice editbox window (needed for either urwid or curses if we > want coloring as you type) > ?- get scrolling to work (needed either way, although I believe urwid > has a widget for that) > ?- allow for resizing (in curses) > ?- handle adjustable-size completions box (done in urwid, not too hard > in curses once resizing is handled) > > I'm sure there's more... but that's all I've thought of so far. > > Anyways, thanks for the comments! > > -Wendell > > > On 04/22/2010 04:58 AM, Fernando Perez wrote: >> Hi Wendell, >> >> On Tue, Apr 20, 2010 at 5:55 AM, Wendell >> Smith ?wrote: >>> Hello! >>> >>> I have been busy coding away, trying to get two prototypes written for >>> the eventual curses frontend. >>> >>> They are EXTREMELY basic - they don't even interpret code, just spit it >>> back out (although in the right place and correctly colored). They are >>> full of bugs, don't resize well, etc. - but, well, they are prototypes. >>> >>> What they do: >>> They both have 3 windows: completions, output, and input. The >>> completions window shows some default text, the input window accepts >>> text input, and after hitting enter or, the entered code is >>> highlighted and displayed in the output window. >>> >>> I wrote these both mainly to compare urwid and curses, which I think >>> they do fairly well. the urwid library is quite nice, and although >>> documentation is not perfect, it is good, and the whole thing provides >>> far more than curses - curses requires you to manually handle resizing, >>> for example. The code for the urwid part is therefore far simpler, and >>> was written much faster. It of course requires urwid (easy_install >>> urwid), and both require pygments (also available with easy_install). >>> Urwid is much nicer... but development is only semi-active, and they >>> don't seem at all prepared to port to python3, which is of course >>> important. >>> >>> Anyways, please download the code, run the prototypes, tell me what you >>> think! >>> >>> Code is on github here: >>> git://github.com/wackywendell/ipyurwid.git >>> git://github.com/wackywendell/ipycurses.git >> Great! ?A few comments: >> >> - On ubuntu 9.10, I get this for the urwid code: >> >> (master)amirbar[ipyurwid]> ?python interpreterwidget.py >> Traceback (most recent call last): >> ? ?File "interpreterwidget.py", line 112, in >> ? ? ?interp = fakeinterpreter(mainwin) >> ? ?File "interpreterwidget.py", line 81, in __init__ >> ? ? ?self.formatter = UrwidFormatter(style=s) >> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line >> 29, in __init__ >> ? ? ?self._setup_styles(colors) >> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line >> 92, in _setup_styles >> ? ? ?fgcolstr, bgcolstr, othersettings, colors) >> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line >> 72, in findclosestattr >> ? ? ?fg = self.findclosest(fgcolstr, colors) >> ? ?File "/home/fperez/ipython/wendell/ipyurwid/urwidpygments.py", line >> 54, in findclosest >> ? ? ?bestcol = urwid.AttrSpec('h0','default') >> AttributeError: 'module' object has no attribute 'AttrSpec' >> >> I have: >> >> In [2]: urwid.__version__ >> Out[2]: '0.9.8.4' >> >> Do I need a newer urwid to test out? >> >> Still, this is a tough one: I am genuinely worried about depending on >> a possibly undeveloped project. Have you contacted the urwid devs to >> find out a little bit about future plans/py3 development ideas? >> >> Using curses when urwid is around may feel painful, but at this point >> closing the door on py3k development possibilities sounds a little >> dangerous for us. ?On the other hand, I do see the differences: >> >> amirbar[wendell]> ?wc -l ipyurwid/*py >> ? ?117 ipyurwid/interpreterwidget.py >> ? ?252 ipyurwid/palette_test.py >> ? ?105 ipyurwid/urwidpygments.py >> ? ?474 total >> >> amirbar[wendell]> ?wc -l ipycurses/*py >> ? ?151 ipycurses/basicsequence.py >> ? ?142 ipycurses/cursesextras.py >> ? ? 71 ipycurses/cursesparser.py >> ? ?347 ipycurses/cursespygments.py >> ? ? 32 ipycurses/interpreterwidget.py >> ? ? 11 ipycurses/ipythontest.py >> ? ? 18 ipycurses/keytester.py >> ? ? 57 ipycurses/prototype.py >> ? ? 66 ipycurses/tester.py >> ? ?241 ipycurses/vipad.py >> ? ?123 ipycurses/vipadtester.py >> ? 1259 total >> >> Since I can't run the urwid code right now, how equivalent are the two >> in terms of functionality? I'm basically trying to gauge if the above >> line counts can be fairly compared... >> >> Cheers, >> >> f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From gael.varoquaux at normalesup.org Mon Apr 26 01:10:52 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 26 Apr 2010 07:10:52 +0200 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: Message-ID: <20100426051052.GA14566@phare.normalesup.org> On Sun, Apr 25, 2010 at 01:34:46PM -0700, Fernando Perez wrote: > This document should: > - be easy to read in a short amount of time, without users new to > git/github having to read 10 different Git tutorials (which may be > very good, but may also overwhelm a newcomer with information that he > or she initially doesn't know how to prioritize for relevance). > - enable a newcomer to the project to download it with no > complications, but to later transition to doing development with a > minimal threshold. What is your target audience? The document starts right away with editing a config file, which is way above the abilities of one of my target audience, but I understand that if you target developers, this might not be a problem. Thanks for working on that, Matthew, Ga?l From fperez.net at gmail.com Mon Apr 26 01:45:35 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 22:45:35 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: Message-ID: Hey, On Sun, Apr 25, 2010 at 9:11 PM, Brian Granger wrote: > A nice lightweight way for dev's to contribute code is to use git > format-patch. I like how Sympy encourages contributions using this > approach as it is super easy. Ah, thanks for that. I've never used it before, do you have a reference from the sympy guys on how they guide new users in this direction? We can just copy theirs. > Also, I think for a new > user, it will be confusing that the docs are about gitwash rather than > ipython or nipy. ?Sorry if this is a bit pessimistic. Oh, the name 'gitwash' was precisely so Matthew could draft something, and then we could do a search and replace and put ipython in there :) We do want it to be a copy/paste worksheet, most definitely, and 100% specific to getting started for ipython and nipy. Ideally we can use the same workflow for both, but eventually this will be pasted into each project's doc tree and used with project-specific urls, names, etc. So think of 'ipython' wherever you read 'gitwash' and critique away as something we'll want for IPython itself. The gitwash repo is just a drafting/staging place to get the doc ready to move into nipy and ipython. Hopefully we can get it in decent shape first, before each project takes it and makes it specific to each workflow. And we completely agree that we do *not* want it to become a 'book-lite'. There are plenty of great tutorials with concepts, pictures, etc. for that. We just want it to be the 'tell me what to copy/paste to get started with IPython/nipy' worksheet. Cheers, f From fperez.net at gmail.com Mon Apr 26 01:51:31 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 22:51:31 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: <20100426051052.GA14566@phare.normalesup.org> References: <20100426051052.GA14566@phare.normalesup.org> Message-ID: On Sun, Apr 25, 2010 at 10:10 PM, Gael Varoquaux wrote: > What is your target audience? > > The document starts right away with editing a config file, which is way > above the abilities of one of my target audience, but I understand that > if you target developers, this might not be a problem. Well, you *do* have to configure git right off the bat before you use it. So do you with bzr, by the way. We gave both the config file and the copy-paste at the command-line commands, do you think the command-line version is friendlier? Matthew had that first and I thought the file one would be easier. Remember that with bzr you have the same thing, as the 'bazaar in five minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc says: Before you start working, it is good to tell Bazaar who you are. That way your work is properly identified in revision logs. Using your name and email address, instead of John Doe?s, type: $ bzr whoami "John Doe " This is the exact same thing as with git, it's just that Matthew also provided a few aliases. Do you think it would be best to only provide this, just like bzr? git config --global user.email you at yourdomain.example.com git config --global user.name "Your Name Comes Here" That would be *identical* to bzr, which you say is OK for your users who can't edit files. Would this then be OK for them? Cheers, f From fperez.net at gmail.com Mon Apr 26 02:00:46 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 23:00:46 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger wrote: > This patch can be applied. > Mmmh, are you sure? The patch reads: === modified file 'IPython/kernel/core/interpreter.py' --- IPython/kernel/core/interpreter.py 2009-04-20 22:44:50 +0000 +++ IPython/kernel/core/interpreter.py 2009-07-17 09:46:18 +0000 @@ -375,7 +375,7 @@ exec code in self.user_ns outflag = 0 except SystemExit: - self.resetbuffer() + self.reset() self.traceback_trap.args = sys.exc_info() except: self.traceback_trap.args = sys.exc_info() but the code at that location now reads: try: exec code in self.user_ns outflag = 0 except SystemExit: self.traceback_trap.args = sys.exc_info() except: self.traceback_trap.args = sys.exc_info() There is not even a self.resetbuffer() call anymore. So the patch does not apply anymore. The question is, should I put in the self.reset() the patch had added, or should I lseave the code like it is now? Thanks for the help, it does look at least like this one is simple enough that we'll be able to finish it off before the transition. Cheers, f From fperez.net at gmail.com Mon Apr 26 02:55:52 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 25 Apr 2010 23:55:52 -0700 Subject: [IPython-dev] Bug blitz: a weekend report Message-ID: Hi folks, my little bug blitz has been fairly successful. I forgot to write the numbers down yesterday morning when I started, but I think we had around 100 new bugs, most of which hadn't even been looked at. Now the numbers are: amirbar[hydrazine]> ./capture-bug-counts loaded existing credentials getting project... ipython (IPython - Enhanced Interactive Python) By Status.................................................................................................................................................................................................................. 4 In Progress https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=In Progress 78 Fix Committed https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Fix Committed 14 Triaged https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Triaged 96 Confirmed https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Confirmed 18 Incomplete https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Incomplete Bugs with patches................ 16 HasPatch https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.has_patch=on Of those 16 with patches, 15 have already been committed, and the remaining one is 400600 that Brian and Vishal are helping with, so it will be in as well. We have now *zero* bugs marked 'new'. I was able to close a ton of small things, applied all available patches (I was trying to ensure no user contribution went ignored), and in general marked as 'confirmed' anything that looked remotely reasonable. So in this case, 'confirmed' doesn't always mean that I actually confirmed the bug, just that the report looked sensible enough to keep the bug alive on github. If you now look at our bug page: https://bugs.launchpad.net/ipython we appear to have 210 open ones, but in reality a good chunk of those have committed fixes, just awaiting a release of 0.10.1/0.11. If we exclude 'fix committed', we get: https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search for a total of 132 open ones. I can already download those 132 in Python, and I hope later this week to find the time to write the github upload part, so this time around we will not lose any bug history or data. I still feel bad that we abandoned some bugs reported in our old trac instance at scipy.org, and I really don't want to repeat that mistake. Importantly, once we close #400600, we won't have any bug with a patch left on LP (I can't migrate those easily). For the others, I'm pretty certain that I can migrate them back up to GH with all comment discussion and most relevant metadata (as labels). Upon upload, since all we have are labels, I'm going to use something similar to what Robert showed us Google code uses: label-value for key/value labels. For now GH doesn't provide any semantic support behind this syntax, but we can later ask them for it based on the Google model, and if they follow through, we'll be ready :) So little by little, we're making good progress towards being able to move 100% of our relevant code and bug history from bzr/Launchpad to git/github. Thanks for everyone's patience. I hope that this setup will give us a smoother workflow where contributions will be both easier to make and to integrate. Regards, f From gael.varoquaux at normalesup.org Mon Apr 26 02:58:23 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 26 Apr 2010 08:58:23 +0200 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: <20100426051052.GA14566@phare.normalesup.org> Message-ID: <20100426065822.GA9303@phare.normalesup.org> On Sun, Apr 25, 2010 at 10:51:31PM -0700, Fernando Perez wrote: > Well, you *do* have to configure git right off the bat before you use > it. So do you with bzr, by the way. Most people around me don't, with bzr. It may be a bad thing :) > We gave both the config file and the copy-paste at the command-line > commands, do you think the command-line version is friendlier? Matthew > had that first and I thought the file one would be easier. It depends who you target audience is. A lot a people around me are going to try and edit these files with word :), so maybe the command line is better. But if you target developers, it's fine the way it is. > Remember that with bzr you have the same thing, as the 'bazaar in five > minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc > says: That tutorial is pretty good, I find. Once again, it depends who your target audience is. Some words in the gitwash document may be confusing for non-developers: I have found that people can be confused by the word 'source' (notice how the bzr tutorial avoids the problem using 'file'). On the other hand, the bzr tutorial uses words like 'upstream', which might not be understood either. That said, I feel that anybody who is somewhat a developer should be able to understand and use the gitwash document. Extending to non-developers requires more lengthy phrasing, and more definition of terms (repository), but I am not sure this is what you are aiming for. Cheers, Ga?l From wackywendell at gmail.com Mon Apr 26 03:03:55 2010 From: wackywendell at gmail.com (Wendell Smith) Date: Mon, 26 Apr 2010 09:03:55 +0200 Subject: [IPython-dev] Curses Frontend Update In-Reply-To: <4BD26EE1.3030606@an.org> References: <4BCDA424.1080609@gmail.com> <4BD26EE1.3030606@an.org> Message-ID: <4BD53ADB.2090003@gmail.com> On 04/24/2010 06:09 AM, Toni Alatalo wrote: > Fernando Perez kirjoitti: > >>> they do fairly well. the urwid library is quite nice, and although >>> documentation is not perfect, it is good, and the whole thing provides >>> far more than curses - curses requires you to manually handle resizing, >>> for example. The code for the urwid part is therefore far simpler, and >>> >> Still, this is a tough one: I am genuinely worried about depending on >> a possibly undeveloped project. Have you contacted the urwid devs to >> find out a little bit about future plans/py3 development ideas? >> > One way to think about it is to compare the efforts of: > > a) reimplementing things that urwid does, like handling resizing > mentioned above etc., in the ipython curses frontend > > vs > > b) converting urwid to py3k yourself (shouldn't that be relatively easy > with 2to3 for a small pure py lib?) > > I do agree it's a tough one. There is the danger that the person doing > that ends up being the urwid maintainer in general if other devs are not > active. That has been happening with my and PythonQt (the qtscript like > thing for embedded py in qt apps) now, kind of, 'cause am so far the > only one who has made it to work on Qt 4.6 (with an ugly hack) and > haven't heard back from questions nor patches etc., that's not fun when > you have a lot of other things todo .. but another story alltogether. > > >> Using curses when urwid is around may feel painful, but at this point >> closing the door on py3k development possibilities sounds a little >> > There are few closed doors with open source :) > > I guess depends on how useful Urwid is in general, and whether there are > other uses and devs who fix etc. it otherwise and are eventually > switching over to py3k too. So what Fernando suggested about asking > around seems to be the thing to do indeed. > > 2cently yours, > ~Toni > Yes, I've thought about just trying to convert urwid myself... but I think that's a bit much for me. I have very little experience converting 2to3, and very little with Urwid... and it would be a big time sink. Its a nice library... but there's an awful lot of it that I'm not using, and trying to convert all of it myself would, I think, be a bigger undertaking than its worth. I did contact them earlier: the response from the main developer was something like "porting to python 3 is not currently in our plans, and will take a lot of time as there is a lot of str/unicode handling. However, someone rumored that there was a python 3 compatible version out there, but I haven't seen it." Which was a little weird. Maybe I'll ask again. Thanks for the feedback! -Wendell From fperez.net at gmail.com Mon Apr 26 03:13:43 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 00:13:43 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: <20100426065822.GA9303@phare.normalesup.org> References: <20100426051052.GA14566@phare.normalesup.org> <20100426065822.GA9303@phare.normalesup.org> Message-ID: Hi, On Sun, Apr 25, 2010 at 11:58 PM, Gael Varoquaux wrote: > > Most people around me don't, with bzr. It may be a bad thing :) Well, actually with git you can also avoid it altogether: I moved my git config files out of the way: amirbar[~]> mv .gitconfig .gitignore .gitk tmp/ and then made a toy repo: amirbar[~]> mkdir ff amirbar[~]> cd ff amirbar[ff]> git init Initialized empty Git repository in /home/fperez/ff/.git/ (master)amirbar[ff]> echo hi > readme (master)amirbar[ff]> git add . (master)amirbar[ff]> git commit -m"Initial commit" [master (root-commit) 317d06f] Initial commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 readme (master)amirbar[ff]> git log commit 317d06f03309b57a1978330c5f0520b84af57fe5 Author: Fernando Perez Date: Mon Apr 26 00:09:25 2010 -0700 Initial commit (master)amirbar[ff]> It works fine, git will try to get some identity from your username for the commits. So in that regard it's identical to bzr: you can use it with *zero* config, but you'll be happier with a minimal amount of it in the long run. >> We gave both the config file and the copy-paste at the command-line >> commands, do you think the command-line version is friendlier? ?Matthew >> had that first and I thought the file one would be easier. > > It depends who you target audience is. A lot a people around me are going > to try and edit these files with word :), so maybe the command line is > better. But if you target developers, it's fine the way it is. Well, our audience is anyone who can be expected to use nipy or ipython from source. And we hope that any such person will become at some point a contributor, so we want that transition to be as easy and painless as possible. >> Remember that with bzr you have the same thing, as the 'bazaar in five >> minutes' http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ doc >> says: > > That tutorial is pretty good, I find. > > Once again, it depends who your target audience is. Some words in the > gitwash document may be confusing for non-developers: I have found that > people can be confused by the word 'source' (notice how the bzr tutorial > avoids the problem using 'file'). On the other hand, the bzr tutorial > uses words like 'upstream', which might not be understood either. I actually agree, I hadn't really looked at that tutorial very much, but I now like it a lot. I think the gitwash doc could be restructured in a single page very much following the model of that bzr doc. > That said, I feel that anybody who is somewhat a developer should be able > to understand and use the gitwash document. Extending to non-developers > requires more lengthy phrasing, and more definition of terms > (repository), but I am not sure this is what you are aiming for. We'll iterate on it with this feedback, thanks a lot for providing it. Cheers, f From satra at mit.edu Mon Apr 26 07:46:28 2010 From: satra at mit.edu (Satrajit Ghosh) Date: Mon, 26 Apr 2010 07:46:28 -0400 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: Message-ID: hi fernando, matthew and brian, thanks for putting this together. i'm really looking forward to (ipython, nipy) being on github. # Get your fork: > git clone git at github.com:ellisonbg/ipython.git > > # Create a feature branch > git branch foo > git checkout foo > > # edit files, # for each file do: > git add [filename] > git commit > # rinse and repeate > > # To post branch to github > git push origin foo > talking of a cheat-sheet, there are a few other commands that i tend to use: # to pull collaborators updates from github git pull origin foo (if you are working with somebody on your branch) # deleting git branch -d foo (delete your local merged branch) git branch -D foo (delete your local unmerged branch) git push origin :foo (delete remote branch - this took me a search to figure out when i started) also for my needs this has been very helpful: http://github.com/guides/git-cheat-sheet users will always do all kinds of wacky things that you cannot foresee, so you should keep it simple, perhaps just reflect your basic workflow as brian suggests. ------------ # Get your copy git clone git at github.com:ellisonbg/ipython.git # update your copy (run this to sync up with the source) git pull ##### # if you are a user, that's all you need to know. if you # want to hack/develop, read on. ##### # ... the rest of brian's notes above, gitwash docs ------------ i'm about to give a talk about minimizing redundancy for data and code and i believe it applies to documentation as well! cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzgash.lists at gmail.com Mon Apr 26 08:11:41 2010 From: muzgash.lists at gmail.com (Gerardo Gutierrez) Date: Mon, 26 Apr 2010 07:11:41 -0500 Subject: [IPython-dev] IPythonQt GSoC update In-Reply-To: References: Message-ID: David Mashburn wrote: * Hello Gerardo, My name is David Mashburn and I am a graduate student in Physics at Vanderbilt University. I saw your GSoC proposal for IPythonQt, and though it looked very interesting! I just wanted to let you know about my project as you start work on yours. I have built a notebook interface atop wxPython's PyCrust and called it PySlices. It uses scintilla markers for "slice" (cell) separation, has multi-line support, and has a text-based "almost python" save format. I also added a little ipython-style magic, because I couldn't find an easy way to wrap ipython. Anyway, I just wanted to let you know about my project so we can collaborate. I guess in some ways we have competing software, but I want to make both projects better by sharing ideas. I would really like to collaborate on the save format so the two systems could be used interchangeably, I think that would be awesome! Anyway, I'm sure some of the ways I have done things are good and others are less than ideal, but I thought you might like to see how someone else did it! Here are the main links to PySlices: ------------------------------------------------------------------------- http://trac.wxwidgets.org/ticket/10959 -- Original Trac ticket at wxPython http://code.google.com/p/wxpysuite/ -- Google code page (main development) http://pypi.python.org/pypi/wx_py/0.9.8.3 -- PyPI page http://www.gossamer-threads.com/lists/python/announce/819207 -- Recent announcement BTW, I'm the only developer on this, so I haven't really set up an svn as of yet, but probably could if there is more interest. The best way to look at the code is to unzip the download from the Google code page. Looking forward to possibly working together and seeing how IPythonQt evolves! Thanks, -David Mashburn* Best regards. -- Gerardo Guti?rrez Guti?rrez Physics student Universidad de Antioquia Computational physics and astrophysics group (FACom ) Computational science and development branch(FACom-dev ) Usuario Linux #492295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Mon Apr 26 13:47:42 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 26 Apr 2010 10:47:42 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: I will look at this and try to develop a new patch. Brian On Sun, Apr 25, 2010 at 11:00 PM, Fernando Perez wrote: > On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger wrote: >> This patch can be applied. >> > > Mmmh, are you sure? The patch reads: > > === modified file 'IPython/kernel/core/interpreter.py' > --- IPython/kernel/core/interpreter.py ?2009-04-20 22:44:50 +0000 > +++ IPython/kernel/core/interpreter.py ?2009-07-17 09:46:18 +0000 > @@ -375,7 +375,7 @@ > ? ? ? ? ? ? exec code in self.user_ns > ? ? ? ? ? ? outflag = 0 > ? ? ? ? except SystemExit: > - ? ? ? ? ? ?self.resetbuffer() > + ? ? ? ? ? ?self.reset() > ? ? ? ? ? ? self.traceback_trap.args = sys.exc_info() > ? ? ? ? except: > ? ? ? ? ? ? self.traceback_trap.args = sys.exc_info() > > but the code at that location now reads: > > ? ? ? ?try: > ? ? ? ? ? ?exec code in self.user_ns > ? ? ? ? ? ?outflag = 0 > ? ? ? ?except SystemExit: > ? ? ? ? ? ?self.traceback_trap.args = sys.exc_info() > ? ? ? ?except: > ? ? ? ? ? ?self.traceback_trap.args = sys.exc_info() > > There is not even a self.resetbuffer() call anymore. ?So the patch > does not apply anymore. The question is, should I put in the > self.reset() the patch had added, or should I lseave the code like it > is now? > > Thanks for the help, it does look at least like this one is simple > enough that we'll be able to finish it off before the transition. > > Cheers, > > f > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From ellisonbg at gmail.com Mon Apr 26 14:04:02 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Mon, 26 Apr 2010 11:04:02 -0700 Subject: [IPython-dev] Bug blitz: a weekend report In-Reply-To: References: Message-ID: Fernando, Great job. I love it! > my little bug blitz has been fairly successful. ?I forgot to write the > numbers down yesterday morning when I started, but I think we had > around 100 new bugs, most of which hadn't even been looked at. ?Now > the numbers are: > > amirbar[hydrazine]> ./capture-bug-counts > loaded existing credentials > getting project... ipython (IPython - Enhanced Interactive Python) > By Status.................................................................................................................................................................................................................. > ? ? 4 In Progress > https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=In > Progress > ? ?78 Fix Committed > https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Fix > Committed > ? ?14 Triaged https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Triaged > ? ?96 Confirmed > https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Confirmed > ? ?18 Incomplete > https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Incomplete > > Bugs with patches................ > ? ?16 HasPatch > https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.has_patch=on > > Of those 16 with patches, 15 have already been committed, and the > remaining one is 400600 that Brian and Vishal are helping with, so it > will be in as well. I will look at this one soon. > We have now *zero* bugs marked 'new'. ?I was able to close a ton of > small things, applied all available patches (I was trying to ensure no > user contribution went ignored), and in general marked as 'confirmed' > anything that looked remotely reasonable. ?So in this case, > 'confirmed' doesn't always mean that I actually confirmed the bug, > just that the report looked sensible enough to keep the bug alive on > github. OK I think this makes sense. > If you now look at our bug page: > > https://bugs.launchpad.net/ipython > > we appear to have 210 open ones, but in reality a good chunk of those > have committed fixes, just awaiting a release of 0.10.1/0.11. ?If we > exclude 'fix committed', we get: > > https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search > > for a total of 132 open ones. > > I can already download those 132 in Python, and I hope later this week > to find the time to write the github upload part, so this time around > we will not lose any bug history or data. ?I still feel bad that we > abandoned some bugs reported in our old trac instance at scipy.org, > and I really don't want to repeat that mistake. It will be great to have all of these tickets migrated to github. At the same time, deleting all bug reports (like we did when we moved to LP) is not *that* bad. The real and important bugs always show up again - it is sort of a way of testing which are real and important. The only bummer is work that people have done in tracking the bugs down, fixing them etc. But it sounds like this time we won't loose any of that, which is great. > Importantly, once we close #400600, we won't have any bug with a patch > left on LP (I can't migrate those easily). For the others, I'm pretty > certain that I can migrate them back up to GH with all comment > discussion and most relevant metadata (as labels). > > Upon upload, since all we have are labels, I'm going to use something > similar to what Robert showed us Google code uses: label-value for > key/value labels. ?For now GH doesn't provide any semantic support > behind this syntax, but we can later ask them for it based on the > Google model, and if they follow through, we'll be ready :) Sounds great, but lets keep our labels and values simple. > So little by little, we're making good progress towards being able to > move 100% of our relevant code and bug history from bzr/Launchpad to > git/github. ?Thanks for everyone's patience. ?I hope that this setup > will give us a smoother workflow where contributions will be both > easier to make and to integrate. Thanks for working on this! Brian > Regards, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Mon Apr 26 14:29:31 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 11:29:31 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 10:47 AM, Brian Granger wrote: > I will look at this and try to develop a new patch. Great, thanks! f From fperez.net at gmail.com Mon Apr 26 15:42:49 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 12:42:49 -0700 Subject: [IPython-dev] Bug blitz: a weekend report In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 11:04 AM, Brian Granger wrote: > > Great job. ?I love it! Thanks! >> Of those 16 with patches, 15 have already been committed, and the >> remaining one is 400600 that Brian and Vishal are helping with, so it >> will be in as well. > > I will look at this one soon. Excellent. >> I can already download those 132 in Python, and I hope later this week >> to find the time to write the github upload part, so this time around >> we will not lose any bug history or data. ?I still feel bad that we >> abandoned some bugs reported in our old trac instance at scipy.org, >> and I really don't want to repeat that mistake. > > It will be great to have all of these tickets migrated to github. ?At > the same time, deleting all bug reports (like we did when we moved to > LP) is not *that* bad. ?The real and important bugs always show up > again - it is sort of a way of testing which are real and important. > The only bummer is work that people have done in tracking the bugs > down, fixing them etc. ?But it sounds like this time we won't loose > any of that, which is great. It's partly a matter of not losing information, but also of not losing community: people have spent their time reporting the bugs, I want to make it clear that as a project we value that enough to protect the result of their effort. If people feel that reporting bugs to IPython has a 50/50 chance of being completely ignored, we're less likely to get people contributing. And we never know when a bug reporter will become the next IPython contributor, so I don't want to alienate anyone. > Sounds great, but lets keep our labels and values simple. Very good point. Once I see that it works and I can make labels with a few test bugs and a toy project I made for that, I'll run the planned labels by all of you, so we can prune it out before the real upload. Cheers, f From andresete.chaos at gmail.com Mon Apr 26 18:47:56 2010 From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=) Date: Mon, 26 Apr 2010 17:47:56 -0500 Subject: [IPython-dev] About Ipython-zmq Message-ID: Hi all. More detailed ipython-zmq's desing is avalible now on scipy`s wiki. http://ipython.scipy.org/moin/GSoC2010/IPythonZmq In this desing we had two questions. 1) is tab completion a process into queue of ipython-zmq`s kernel or is it a simple thread? 2) is it good idea to write a daemon for crash recovery system to monitor the kernel`s pid in case it fails? regards!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Tue Apr 27 01:16:50 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:16:50 -0700 Subject: [IPython-dev] IPythonQt GSoC update In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 5:11 AM, Gerardo Gutierrez wrote: > David Mashburn wrote: > > Hello Gerardo, > > My name is David Mashburn and I am a graduate student in Physics at > Vanderbilt University. > > I saw your GSoC proposal for IPythonQt, and though it looked very > interesting! > > I just wanted to let you know about my project as you start work on yours. > ?I have built a notebook interface atop wxPython's PyCrust and called it > PySlices. ?It uses scintilla markers for "slice" (cell) separation, has > multi-line support, and has a text-based "almost python" save format. ?I > also added a little ipython-style magic, because I couldn't find an easy way > to wrap ipython. > Great, I hope you can collaborate with David and exchange as much information as possible. Please make sure to establish communication with David (you should invite him to join the list) as I'm sure that there will be many useful discussions to be had. Cheers, f From fperez.net at gmail.com Tue Apr 27 01:17:40 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:17:40 -0700 Subject: [IPython-dev] Gitwash: a git/github workflow document for review In-Reply-To: References: Message-ID: Hey Satra, On Mon, Apr 26, 2010 at 4:46 AM, Satrajit Ghosh wrote: > thanks for putting this together. i'm really looking forward to (ipython, > nipy) being on github. thanks for the feedback! We'll try to simplify the document quite a bit according to the comments you guys have given us. Best, f From fperez.net at gmail.com Tue Apr 27 01:23:11 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:23:11 -0700 Subject: [IPython-dev] IPython projects accepted to GSoC! Message-ID: Hi everyone, I heard today from both applicants that the two GSoC proposals from IPython got accepted. Congratulations to both of them! This is very good news, as there is a lot of good work to be done on the project. I hope to get the github transition out of the way as fast as possible, so that we can all work with more fluid tools, and for Omar and Gerardo not to have to learn too much about bzr/lp since it won't really be used in the long run (I wish I had finished this weekend, but it was just too much work). The full list of all 2010 gsoc projects is here: http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010 incidentally, I see another one that has an ipython bent to it: http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/advancedconceptsteam/t127230757723 Student Name: Dante Stroe Mentor Name: Francesco Biscani Title: Massively Parallel Islands via MPI, parallel IPython, and/or BOINC Needless to say, we'll do our best to help out as well if there are any questions from this student. Welcome to Gerardo and Omar to the project, and I hope we all have a very productive few months ahead! Cheers, f From fperez.net at gmail.com Tue Apr 27 01:32:16 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:32:16 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: References: Message-ID: Hi, 2010/4/25 Omar Andr?s Zapata Mesa : > > 1)? is tab completion a process into Queue of zmq kernels or is a simple > thread? There is a single zmq kernel operating, and there are no explicit python threads here (yet, there probably will be once guis enter the picture). The complicated question is how to deal with the fact that tab-completion events can come asynchronously at any point in time, and a number of bizarre situations can occur. For example, one client may tab complete on x which was a number, but in the meantime x can be reset to be a string by another client. Think about the various possibilities that can occur, and try to design sensible policies for what to do in these cases. We'll have to discuss them and implement something reasonable (if not perfect). > 2) is good idea make a daemon to crash recovery system? Brian and I thought a bit about this, and we think that it might be possible to run a 'heartbeat' socket directly in zmq. But I wouldn't worry about this too much yet. Cheers, f From fperez.net at gmail.com Tue Apr 27 01:36:47 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:36:47 -0700 Subject: [IPython-dev] Gsoc students: preliminary homework Message-ID: Hi folks, IPython is a fun project, but the internals of the code are complex to navigate. In order for you to succeed this summer, you'll need to get the basic ideas right, and those are fortunately very simple, and implemented in the Python standard library in a small and easy to read code. I recommend you start by understanding *extremely well* how this module operates: http://docs.python.org/library/code.html That is the code that IPython originated from. Even though today we don't even inherit from it anymore, the interaction model is very much the same, and it is vastly simpler to understand than IPython. The zmq kernel/frontend prototype that Brian and I wrote is based on it as well. So study and understand *every single part* of that code and the zmq kernel/frontend examples. IPython implements similar ideas but with a ton of extra complexity, and you'll get lost in the IPython code if you dive into it first. But if you understand the code.py module, you'll see that all IPython does is add bells and whistles to it, so you'll be much more capable of navigating IPython itself. Play with that, try to add a feature to it (like simple tab completion), see how our zmq prototype uses it in a two-process model, etc. Once the main objects in that code make sense to you, and how they operate, dive into the IPython source tree itself. Given the official timeline: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline You have one month of 'community bonding' to get up to speed on the project. That month starts now :) Cheers, f From fperez.net at gmail.com Tue Apr 27 01:43:25 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 26 Apr 2010 22:43:25 -0700 Subject: [IPython-dev] Engineering formatting In-Reply-To: References: <4BCF2537.9000500@enthought.com> Message-ID: 2010/4/24 St?fan van der Walt : > > Thanks for the code snippets! ?I've put them into a profile and added > array printing (attached). ?Maybe a useful profile to distribute? Hold that thought :) Have you tested it with trunk yet? We haven't documented too much how to change config stuff for trunk, but I don't want to put much more effort into 0.10 series machinery... If you can spelunk your way to make it work with trunk definitely send it our way, otherwise I'll give you a hand as soon as I catch a breather. Right now the git transition and gsoc stuff is taking up all my (non-existent) available time. cheers, f From stefan at sun.ac.za Tue Apr 27 06:29:24 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 27 Apr 2010 12:29:24 +0200 Subject: [IPython-dev] Engineering formatting In-Reply-To: References: <4BCF2537.9000500@enthought.com> Message-ID: On 27 April 2010 07:43, Fernando Perez wrote: > Hold that thought :) ?Have you tested it with trunk yet? We haven't > documented too much how to change config stuff for trunk, but I don't > want to put much more effort into 0.10 series machinery... > > If you can spelunk your way to make it work with trunk definitely send > it our way, otherwise I'll give you a hand as soon as I catch ?a > breather. ?Right now the git transition and gsoc stuff is taking up > all ?my (non-existent) available time. I couldn't get it to work with 0.10, so I'm currently running 0.11.alpha1.bzr.r1223. Not sure where "trunk" is exactly these days, but maybe that's close enough? Cheers St?fan From fperez.net at gmail.com Tue Apr 27 13:21:32 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 27 Apr 2010 10:21:32 -0700 Subject: [IPython-dev] Engineering formatting In-Reply-To: References: <4BCF2537.9000500@enthought.com> Message-ID: 2010/4/27 St?fan van der Walt : > > I couldn't get it to work with 0.10, so I'm currently running > 0.11.alpha1.bzr.r1223. ?Not sure where "trunk" is exactly these days, > but maybe that's close enough? Oh yes, trunk is the 0.11 series. I'll have a look then, thanks! Cheers, f From ellisonbg at gmail.com Tue Apr 27 17:13:13 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 27 Apr 2010 14:13:13 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: It looks like this one has already been fixed. We are good to go. Brian On Sun, Apr 25, 2010 at 8:56 PM, Brian Granger wrote: > This patch can be applied. > > Brian > > On Sun, Apr 25, 2010 at 4:04 PM, Fernando Perez wrote: >> Hey guys, >> >> I see you've been active on this one: >> >> https://bugs.launchpad.net/ipython/+bug/400600 >> >> It's the last remaining bug on LP that both has a patch and is still >> open, everything else with patches I've already committed. ?Since bugs >> with patches will be harder to auto-migrate to Gh, I'd like to close >> them for good while still on LP where the patch is tracked, to >> simplify life. >> >> If you guys have a chance to clarify the status of this one before we >> make the transition, it would be great. >> >> Cheers, >> >> f >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu > ellisonbg at gmail.com > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Tue Apr 27 17:14:40 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 27 Apr 2010 14:14:40 -0700 Subject: [IPython-dev] Brian and Vishal, help with #400600? In-Reply-To: References: Message-ID: On Tue, Apr 27, 2010 at 2:13 PM, Brian Granger wrote: > It looks like this one has already been fixed. ?We are good to go. Awesome, thanks! Cheers, f From hans_meine at gmx.net Thu Apr 29 03:50:48 2010 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 29 Apr 2010 09:50:48 +0200 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: References: Message-ID: <201004290950.50985.hans_meine@gmx.net> Am Dienstag 27 April 2010 07:32:16 schrieb Fernando Perez: > > 2) is good idea make a daemon to crash recovery system? > > Brian and I thought a bit about this, and we think that it might be > possible to run a 'heartbeat' socket directly in zmq. But I wouldn't > worry about this too much yet. In our own two-process, Qt-based python terminal, we simply connected to the signal the TCP socket class emits when the connection closed. AFAIK that's the standard approach for TCP/IP-based IPC with daemons (e.g. I recall KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays, I hope it offers the same failsafe detection of a lost/closed connection. HTH, Hans From ccordoba12 at gmail.com Thu Apr 29 11:41:52 2010 From: ccordoba12 at gmail.com (=?ISO-8859-1?Q?Carlos_C=F3rdoba?=) Date: Thu, 29 Apr 2010 10:41:52 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: Whatever the format for saving sessions is chosen, I think it would be a great idea if one could execute a whole notebook from the terminal with something like: ipython -nb foo.inb (inb = ipython notebook) or call it with the %run magic. This way you could write self-contained programs with IpythonQt and use ipython as an interpreter to run them. I'm very fond of literate programmingand I think it would be very useful to write programs as text (with sections, subsections, equations, figures, etc) but with the possibility to run them as easily as possible. Carlos 2010/4/25 Brian Granger > On Sat, Apr 17, 2010 at 6:08 PM, Robert Kern > wrote: > > On 2010-04-17 19:02 , Gerardo Gutierrez wrote: > >> Ok i'm going to paste a fragment of a document about this topic (that > >> I've not noticed until today) > >> > >> > >> /The frontend would store, for now, 5 types of data: > >> > >> #. Input: this is python/ipython code to be executed. > >> > >> #. Output (python): result of executing Inputs. > >> > >> #. Standard output: from subprocesses. > >> > >> #. Standard error: from subprocesses. > >> > >> #. Text: arbitrary text. For now, we'll just store plain text and will > defer > >> to the user on how to format it, though it should be valid reST if it is > >> later to be converted into html/pdf. > >> > >> The non-text cells would be stored on-disk as follows:: > >> > >> .. input-cell:: > >> :id: 1 > >> > >> 3+3 > >> > >> .. output-cell:: > >> :id: 1 > >> > >> 6 > >> > >> .. input-cell:: > >> :id: 2 > >> > >> ls > >> > >> .. stdout-cell:: > >> :id: 2 > >> > >> a.py b.py > >> > >> .. input-cell:: > >> :id: 3 > >> > >> !askdfj > >> > >> .. stderr-cell:: > >> :id: 3 > >> > >> sh: askdfj: command not found/ > >> > >> > >> This document clears some ideas, since the natural way for an IPython's > >> frontend (not only IPythonQt) to load data is rst in wich Python's and > >> IPython's documentation is written. > > > > I would not say that it is natural, no. reST is a fine text markup, but > not a > > very good datastore. The parser is difficult to work with, and there > aren't any > > tools for generating valid reST from a parsed description. > > I agree with Robert that reST is probably not the best option for this. > > > I highly recommend using xml.etree to parse and generate a simple XML > format. > > I am not quite as excited about XML as Robert, but my feeling is this: > it should be XML unless someone comes up with an option that beats > it. > > Cheers, > > Brian > > > -- > > Robert Kern > > > > "I have come to believe that the whole world is an enigma, a harmless > enigma > > that is made terrible by our own mad attempt to interpret it as though > it had > > an underlying truth." > > -- Umberto Eco > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu > ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu Apr 29 12:28:34 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 29 Apr 2010 09:28:34 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: <201004290950.50985.hans_meine@gmx.net> References: <201004290950.50985.hans_meine@gmx.net> Message-ID: Hans, 0MQ has very smart reconnection logic, and we take advantage of that in the huge way. For example, you can send messages to a process that is not currently running. Those message will be queued and when the process appears, 0MQ detects that and will send the messages. Also, 0MQ will disconnect/reconnect its raw sockets many times if needed. The bottom line is that you can't detect the types of failures you are talking about at the user API level. At first, this bothered me as I am used to handling the disconnect by hand. But, as time has gone on, I see the huge advantages this approach gives. In this new way of thinking a heartbeat is the only way to detect if a peer is truly alive. Cheers, Brian On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine wrote: > Am Dienstag 27 April 2010 07:32:16 schrieb Fernando Perez: >> > 2) is good idea make a daemon to crash recovery system? >> >> Brian and I thought a bit about this, and we think that it might be >> possible to run a 'heartbeat' socket directly in zmq. ?But I ?wouldn't >> worry about this too much yet. > > In our own two-process, Qt-based python terminal, we simply connected to the > signal the TCP socket class emits when the connection closed. ?AFAIK that's > the standard approach for TCP/IP-based IPC with daemons (e.g. I recall > KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays, > I hope it offers the same failsafe detection of a lost/closed connection. > > HTH, > ?Hans > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Thu Apr 29 19:30:05 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 29 Apr 2010 16:30:05 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: <201004290950.50985.hans_meine@gmx.net> References: <201004290950.50985.hans_meine@gmx.net> Message-ID: On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine wrote: > In our own two-process, Qt-based python terminal, we simply connected to the > signal the TCP socket class emits when the connection closed. ?AFAIK that's > the standard approach for TCP/IP-based IPC with daemons (e.g. I recall > KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays, > I hope it offers the same failsafe detection of a lost/closed connection. I don't think zmq sockets signal when they drop the connection, though. Brian, is that right? Hans, were you using pure python sockets? We're trying to avoid any python code in the sockets layer, so that message queuing can continue to happen even if the kernel is running blocking code (e.g. numpy). zmq does that by releasing the gil for most of its operations. Was that not an issue for you guys? Cheers, f From ellisonbg at gmail.com Thu Apr 29 22:43:16 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 29 Apr 2010 19:43:16 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: References: <201004290950.50985.hans_meine@gmx.net> Message-ID: On Thu, Apr 29, 2010 at 4:30 PM, Fernando Perez wrote: > On Thu, Apr 29, 2010 at 12:50 AM, Hans Meine wrote: >> In our own two-process, Qt-based python terminal, we simply connected to the >> signal the TCP socket class emits when the connection closed. ?AFAIK that's >> the standard approach for TCP/IP-based IPC with daemons (e.g. I recall >> KDE/DCOP etc. do that), and if 0mq really is the superior solution nowadays, >> I hope it offers the same failsafe detection of a lost/closed connection. > > I don't think zmq sockets signal when they drop the connection, > though. ?Brian, is that right? Correct. > Hans, were you using pure python sockets? ?We're trying to avoid any > python code in the sockets layer, so that message queuing can continue > to happen even if the kernel is running blocking code (e.g. numpy). > zmq does that by releasing the gil for most of its operations. ?Was > that not an issue for you guys? Probably not my guess. Brian > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From hans_meine at gmx.net Fri Apr 30 05:12:27 2010 From: hans_meine at gmx.net (Hans Meine) Date: Fri, 30 Apr 2010 11:12:27 +0200 Subject: [IPython-dev] Zmq branch on LP: re-created. Message-ID: <201004301112.27993.hans_meine@gmx.net> Am Donnerstag 29 April 2010 18:28:34 schrieben Sie: > The bottom line is that you can't detect the types of failures you are > talking about at the user API level. At first, this bothered me as I > am used to handling the disconnect by hand. But, as time has gone on, > I see the huge advantages this approach gives. I agree that all in all, this behaviour is very desirable. > In this new way of > thinking a heartbeat is the only way to detect if a peer is truly > alive. Hmm. But "heartbeat" sounds as if the peer needs to respond. Wouldn't it be even better to open a raw (non-0mq-)socket just to be able to watch it and get notified by the OS if the peer dies? Best, Hans From hans_meine at gmx.net Fri Apr 30 05:12:34 2010 From: hans_meine at gmx.net (Hans Meine) Date: Fri, 30 Apr 2010 11:12:34 +0200 Subject: [IPython-dev] Zmq branch on LP: re-created. Message-ID: <201004301112.40415.hans_meine@gmx.net> Am Freitag 30 April 2010 01:30:05 schrieben Sie: > Hans, were you using pure python sockets? I was about to say no, but actually we did: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) although we later used Qt's QSocketNotifier around it (by taking s.fileno()), so the select() would happen from within C++. > We're trying to avoid any > python code in the sockets layer, so that message queuing can continue > to happen even if the kernel is running blocking code (e.g. numpy). > zmq does that by releasing the gil for most of its operations. Was > that not an issue for you guys? I am not sure I understand the problem. Of course, the backend could (and would) block and not respond to the commands, so for example completion would not work during program execution. But I don't see a way around that. Messages would not be queued as in 0mq, but I guess the OS would maintain some buffer. Sorry if I could not really answer your question; I guess my memory is already too faint (this was 2003 according to the /CVS/ logs..). Anyhow, the 0mq approach is certainly better for the main communication, I was just wondering about the detection of a crashed backend. Best, Hans From edreamleo at gmail.com Fri Apr 30 09:58:20 2010 From: edreamleo at gmail.com (Edward K. Ream) Date: Fri, 30 Apr 2010 08:58:20 -0500 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. Message-ID: Hello all, I've been on vacation without a good way to respond to this thread. I have no idea whether any of the following will be of any use to the topic under discussion, but it might. I have a keen interest in this topic, for several reasons that you may or may not be familiar with. First, Leo could already be said to be a "front end" to IPython, and Leo's Qt gui works well with IPython. Leo's Qt outline widget is sophisticated and is highly optimized for large outlines. It's also solid, which is no mean feat, considering that it can be driven by Python scripts as well as by the user. Second, Mathematica is not the best notebook available, Leo is. Mathematica notebooks are trees, not dags, which has profound implications for data handling, as Leo proves. Mathematica's DOM and scripting are weak; Leo's (python) scripts have easy access to all outline data via a simple and easy-to-use api. Third, Leo outlines are xml files. .leo files have an "extension mechanism", uA's (user/unknown attributes), that allows any kind of data to be attached to any node in the outline. Thus, there is no urgent need to define one's own xml tags. The user (or Leo plugin) can embed any kind of data into a Leo outline without having to reach a consensus about the format of the data. To repeat, I have no idea whether any part of Leo will be of use in the project under discussion. But it might be worthwhile to take a look at Leo, its Qt interface, its xml file format and its in-core data structures. The features I have summarized here have been under development for 15+ years. Leo is pure Python and a single code base works with Python 2.6 and Python 3.1. Edward ------------------------------------------------------------------------------ Edward K. Ream email: edreamleo at gmail.com Leo: http://webpages.charter.net/edreamleo/front.html ------------------------------------------------------------------------------ From ellisonbg at gmail.com Fri Apr 30 11:16:04 2010 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 30 Apr 2010 08:16:04 -0700 Subject: [IPython-dev] Zmq branch on LP: re-created. In-Reply-To: <201004301112.40415.hans_meine@gmx.net> References: <201004301112.40415.hans_meine@gmx.net> Message-ID: On Fri, Apr 30, 2010 at 2:12 AM, Hans Meine wrote: > Am Freitag 30 April 2010 01:30:05 schrieben Sie: >> Hans, were you using pure python sockets? > > I was about to say no, but actually we did: > ?s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > although we later used Qt's QSocketNotifier around it (by taking s.fileno()), > so the select() would happen from within C++. > >> We're trying to avoid any >> python code in the sockets layer, so that message queuing can continue >> to happen even if the kernel is running blocking code (e.g. numpy). >> zmq does that by releasing the gil for most of its operations. ?Was >> that not an issue for you guys? > > I am not sure I understand the problem. ?Of course, the backend could (and > would) block and not respond to the commands, so for example completion would > not work during program execution. ?But I don't see a way around that. > Messages would not be queued as in 0mq, but I guess the OS would maintain some > buffer. With 0MQ, the heartbeat responder will be able to reply *while* the kernel executes code of any kind as the heartbeat responder will run in a native C++ that doesn't hold the GIL. > Sorry if I could not really answer your question; I guess my memory is already > too faint (this was 2003 according to the /CVS/ logs..). > > Anyhow, the 0mq approach is certainly better for the main communication, I was > just wondering about the detection of a crashed backend. > > Best, > ?Hans > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgranger at calpoly.edu ellisonbg at gmail.com From fperez.net at gmail.com Fri Apr 30 17:54:50 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 30 Apr 2010 14:54:50 -0700 Subject: [IPython-dev] notebook-like format for IPythonQt sessions. In-Reply-To: References: Message-ID: On Fri, Apr 30, 2010 at 6:58 AM, Edward K. Ream wrote: > > To repeat, I have no idea whether any part of Leo will be of use in > the project under discussion. ?But it might be worthwhile to take a > look at Leo, its Qt interface, its xml file format and its in-core > data structures. ?The features I have summarized here have been under > development for 15+ years. ?Leo is pure Python and a single code base > works with Python 2.6 and Python 3.1. Thanks for the pointers. Since leo is mit licensed it's compatible with ipython's license, so we can take ideas from there. Regards, f