From vishal.vatsa at gmail.com Mon Dec 1 05:23:13 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Mon, 01 Dec 2008 10:23:13 +0000 Subject: [IPython-dev] ipcluster with clusterfile References: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com> <6ce0ac130811050851t13b5ff0ag1bcf84af3552c90e@mail.gmail.com> <6ce0ac130811050919s1eae7fc8l9e8020ff4420c8db@mail.gmail.com> <6ce0ac130811161446y52aa965fx3394b0a40677a67c@mail.gmail.com> <6ce0ac130811191133q72bb2dc2wf03367d8c63879b@mail.gmail.com> <6ce0ac130811251729o995bbfas3f42473c7e12a191@mail.gmail.com> Message-ID: Brian, There is a merge request available at: https://code.launchpad.net/~vvatsa/ipython/ipcluster-dev/+merge/1965 Can you take a look and let me know. Thanks, -vishal. Brian Granger wrote: > Vishal, > > Cool! > > Can you create a launchpad proposal to merge (into my branch) for your > branch. That way others can review your work as well and we can keep > all the comments together. Once you do that I will begin looking at > this. > > Cheers, > > Brian > > On Mon, Nov 24, 2008 at 6:56 AM, Vishal Vatsa > wrote: >> >> Brian Granger wrote: >> >>>>> If you start hacking on the ssh cluster, keep in touch so we can >>>>> coordinate. >> Hi Brian, >> >> I have done my 1st drop of a working ssh cluster (sort of manager), >> >> http://bazaar.launchpad.net/%7Evvatsa/ipython/ipcluster-dev/revision/1165?start_revid=1165 >> >> Works in a similar way as to 0.8.x ipcluster, the main caveat is that >> this is very *nix, don't think this will work in windows, I have tested >> this on GNU/Linux systems, no reason it should not work on OS X. >> >> Have a look and if you have any pointers, let me know. >> I wanted to be happy with the cluster semantics 1st and then I would be >> happy to fix any implementation issues. >> >> Regards, >> -vishal >> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> From vishal.vatsa at gmail.com Mon Dec 1 10:57:44 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Mon, 01 Dec 2008 15:57:44 +0000 Subject: [IPython-dev] gathering statics/infomation from running TaskController Message-ID: Hi Guys, I have wondering about, whats the best way to get data from the TaskController about things like which job is cooking on which engine. It alway nice to have some visualization of what the cluster is up to. Any one have any thoughts on this? Regards, -vishal From benjaminrk at gmail.com Mon Dec 1 12:30:49 2008 From: benjaminrk at gmail.com (MinRK) Date: Mon, 1 Dec 2008 09:30:49 -0800 Subject: [IPython-dev] gathering statics/infomation from running TaskController In-Reply-To: References: Message-ID: TaskClient.queue_status(True) returns a dict of taskID lists for completed, failed, pending, queued The pending list currently ignores which engine is doing which task, but we could easily change that, so it would look more like: {completed: [0,1], queued: [], pending: {1:3,2:4,3:None}, failed: [2] } Now, if we want something more thorough, including pending runtime etc., then perhaps another method would be called for. -MinRK On Mon, Dec 1, 2008 at 7:57 AM, Vishal Vatsa wrote: > Hi Guys, > > I have wondering about, whats the best way to get data from the > TaskController about things like which job is cooking on which engine. > > It alway nice to have some visualization of what the cluster is up to. > > Any one have any thoughts on this? > > Regards, > -vishal > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg.net at gmail.com Mon Dec 1 17:04:51 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 1 Dec 2008 14:04:51 -0800 Subject: [IPython-dev] ipcluster with clusterfile In-Reply-To: References: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com> <6ce0ac130811050919s1eae7fc8l9e8020ff4420c8db@mail.gmail.com> <6ce0ac130811161446y52aa965fx3394b0a40677a67c@mail.gmail.com> <6ce0ac130811191133q72bb2dc2wf03367d8c63879b@mail.gmail.com> <6ce0ac130811251729o995bbfas3f42473c7e12a191@mail.gmail.com> Message-ID: <6ce0ac130812011404h5e40a1oc99bbd8906d996a4@mail.gmail.com> Vishal, I saw this and will get to it soon. Thanks. Brian On Mon, Dec 1, 2008 at 2:23 AM, Vishal Vatsa wrote: > Brian, > > There is a merge request available at: > https://code.launchpad.net/~vvatsa/ipython/ipcluster-dev/+merge/1965 > > Can you take a look and let me know. > > Thanks, > -vishal. > > Brian Granger wrote: > >> Vishal, >> >> Cool! >> >> Can you create a launchpad proposal to merge (into my branch) for your >> branch. That way others can review your work as well and we can keep >> all the comments together. Once you do that I will begin looking at >> this. >> >> Cheers, >> >> Brian >> >> On Mon, Nov 24, 2008 at 6:56 AM, Vishal Vatsa >> wrote: >>> >>> Brian Granger wrote: >>> >>>>>> If you start hacking on the ssh cluster, keep in touch so we can >>>>>> coordinate. >>> Hi Brian, >>> >>> I have done my 1st drop of a working ssh cluster (sort of manager), >>> >>> http://bazaar.launchpad.net/%7Evvatsa/ipython/ipcluster-dev/revision/1165?start_revid=1165 >>> >>> Works in a similar way as to 0.8.x ipcluster, the main caveat is that >>> this is very *nix, don't think this will work in windows, I have tested >>> this on GNU/Linux systems, no reason it should not work on OS X. >>> >>> Have a look and if you have any pointers, let me know. >>> I wanted to be happy with the cluster semantics 1st and then I would be >>> happy to fix any implementation issues. >>> >>> Regards, >>> -vishal >>> >>> >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From vishal.vatsa at gmail.com Mon Dec 1 17:12:38 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Mon, 01 Dec 2008 22:12:38 +0000 Subject: [IPython-dev] gathering statics/infomation from running TaskController References: Message-ID: Cheers for the response MinRK wrote: > TaskClient.queue_status(True) > returns a dict of taskID lists for completed, failed, pending, queued > The pending list currently ignores which engine is doing which task, but > we could easily change that, so it would look more like: > {completed: [0,1], > queued: [], > pending: {1:3,2:4,3:None}, > failed: [2] > } Thanks, ya, if queue_status can give information on which engine is doing which task, it would be great. > Now, if we want something more thorough, including pending runtime etc., > then perhaps another method would be called for. > > -MinRK > > On Mon, Dec 1, 2008 at 7:57 AM, Vishal Vatsa > wrote: > >> Hi Guys, >> >> I have wondering about, whats the best way to get data from the >> TaskController about things like which job is cooking on which engine. >> >> It alway nice to have some visualization of what the cluster is up to. >> >> Any one have any thoughts on this? >> >> Regards, >> -vishal >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> From ellisonbg.net at gmail.com Mon Dec 1 17:16:21 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 1 Dec 2008 14:16:21 -0800 Subject: [IPython-dev] gathering statics/infomation from running TaskController In-Reply-To: References: Message-ID: <6ce0ac130812011416t1b2d97b1l26c7acc245e85713@mail.gmail.com> > if queue_status can give information on which engine is doing which task, it would be great. What is the usage case for this. My only hesitation to add this is that there is no promise that the engine that is currently working on a task will be the engine that actually completes the task. Brian From vishal.vatsa at gmail.com Mon Dec 1 19:55:59 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Tue, 2 Dec 2008 00:55:59 +0000 Subject: [IPython-dev] gathering statics/infomation from running TaskController In-Reply-To: <6ce0ac130812011416t1b2d97b1l26c7acc245e85713@mail.gmail.com> References: <6ce0ac130812011416t1b2d97b1l26c7acc245e85713@mail.gmail.com> Message-ID: <7ea8f2ed0812011655l1b23c385k50a1019e211c10e4@mail.gmail.com> 2008/12/1 Brian Granger : >> if queue_status can give information on which engine is doing which task, it would be great. > > What is the usage case for this. My only hesitation to add this is > that there is no promise that the engine that is currently working on > a task will be the engine that actually completes the task. > My use case is mostly cosmetic to begin with, it would be a nice visualization for how the cluster is being used. -vishal From sophacles at gmail.com Tue Dec 2 11:36:53 2008 From: sophacles at gmail.com (Erich Heine) Date: Tue, 2 Dec 2008 10:36:53 -0600 Subject: [IPython-dev] New Twisted based server that works with IPython TextMate bundle In-Reply-To: <6ce0ac130811281555w64ea82bk26db3b410ee42f1a@mail.gmail.com> References: <6ce0ac130811281555w64ea82bk26db3b410ee42f1a@mail.gmail.com> Message-ID: <35966ad50812020836l51eab4f6kdb45c6ddda0a8005@mail.gmail.com> Hi Brian and list, As the original author of the ipy_vimserver stuff, I read the textmate bundle announcement with a bit of concern, because that code was just not up to date with modern Ipythons. So I'm really glad Brian did this, because I had been looking to do something like this for quite a while, but hadn't had the opportunity to learn the Ipython internals with the twisted integration. Its a load off my mind, particularly since this is well done. Note: This should just work with the vimscripts I wrote to go with the ipy_vimserver stuff originally. I can see this being useful with an emacs plugin as well (I mean really, who doesn't like to control the interpreter from the editor :) Perhaps this module could be called ipy_commandserver or similar, and ipy_vimserver could just go away. Another thing I had been thinking, even more genericizing this, is: Does Ipython allow for multiple frontends on the same interpreter? It seems like it may with the notification framework stuff, but like I said, I haven't had a chance to really keep up with the internals. Regards, Erich On Fri, Nov 28, 2008 at 5:55 PM, Brian Granger wrote: > Hi, > > I just finished the first draft of a new Twisted based > ipy_textmateserver.py extension that allows IPython to work with Matt > Foster's IPython TextMate bundle. This replaces the stuff in > ipy_vimserver.py and is much more powerful and flexible. > > To use it do: > > In [1]: import ipy_textmateserver > > In [2]: s = ipy_textmateserver.TextMateServer() > > In [3]: s.start() > > Then the bundle will find this session. > > Barry and other Mac+TextMate users, could you have a look at this to > see what you think? > > Cheers, > > Brian > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.p.foster at gmail.com Tue Dec 2 11:54:31 2008 From: matt.p.foster at gmail.com (Matt Foster) Date: Tue, 2 Dec 2008 16:54:31 +0000 Subject: [IPython-dev] New Twisted based server that works with IPython TextMate bundle In-Reply-To: <35966ad50812020836l51eab4f6kdb45c6ddda0a8005@mail.gmail.com> References: <6ce0ac130811281555w64ea82bk26db3b410ee42f1a@mail.gmail.com> <35966ad50812020836l51eab4f6kdb45c6ddda0a8005@mail.gmail.com> Message-ID: <1dcb3f200812020854n118225fbu99684239207f92f3@mail.gmail.com> On Tue, Dec 2, 2008 at 4:36 PM, Erich Heine wrote: > Note: This should just work with the vimscripts I wrote to go with the > ipy_vimserver stuff originally. It should do: the TextMate side of things is based your vim client's code. Thinking about it, is there any reason the main client-side code couldn't be abstracted out into ipython itself? That way only editor specific stuff would need re-implemeting, and it wouldn't matter that people like me know very little of ipython's internals :) Cheers, Matt -- Matt Foster | http://hackerific.net From vivainio at gmail.com Tue Dec 2 13:16:34 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Tue, 2 Dec 2008 20:16:34 +0200 Subject: [IPython-dev] [IPython-user] Qt gui now usable (sort of) :-) In-Reply-To: References: <46cb515a0811301128r56cadb1dgf945e2adb8555551@mail.gmail.com> <4932f406.25e2660a.5dc6.ffffe84c@mx.google.com> <46cb515a0811301249u6e6cd927m2685c0021f65dd63@mail.gmail.com> Message-ID: <46cb515a0812021016x2bb7604dk3dc75cf33f6a07b1@mail.gmail.com> On Tue, Dec 2, 2008 at 6:29 PM, Edward K. Ream wrote: > I'm intrigued by PyOs_InputHook. It doesn't seem to be documented > PyOs_InputHook is apparently the magic that makes ILeo possible. My > present hypothesis is that you learned about PyOS_InputHook during > your work on IPython. Do you know of any reference docs? I don't think it's that much a documented feature, as opposed to a hack that is provided for convenience. Google code search is the best place to explore the thing: http://google.com/codesearch?hl=en&start=10&sa=N&q=+PyOS_InputHook Essentially, it's a readline feature. -- Ville M. Vainio http://tinyurl.com/vainio From laurent.dufrechou at gmail.com Tue Dec 2 18:17:01 2008 From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=) Date: Wed, 3 Dec 2008 00:17:01 +0100 Subject: [IPython-dev] [IPython-user] Qt gui now usable (sort of) :-) In-Reply-To: <46cb515a0812021016x2bb7604dk3dc75cf33f6a07b1@mail.gmail.com> References: <46cb515a0811301128r56cadb1dgf945e2adb8555551@mail.gmail.com> <4932f406.25e2660a.5dc6.ffffe84c@mx.google.com> <46cb515a0811301249u6e6cd927m2685c0021f65dd63@mail.gmail.com> <46cb515a0812021016x2bb7604dk3dc75cf33f6a07b1@mail.gmail.com> Message-ID: <4935c1f1.02225e0a.349c.0b8a@mx.google.com> Hi ville, I'm a definitive supported of your html view! Good job ;) I really like the multiline editing. It offers a lot more flexibity, no more editor is necessary, that's really cool feature. Autocompletion is a little bit sluggish, I've tried import wx. Wx. Tooks ages to render in html :p, and after the gui was really slow, I thinks it try to render the whole hmtl page or something like this. (using vista) Waiting your next releases! Laurent From vivainio at gmail.com Wed Dec 3 11:54:45 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 3 Dec 2008 18:54:45 +0200 Subject: [IPython-dev] [IPython-user] Qt gui now usable (sort of) :-) In-Reply-To: <4935c1f1.02225e0a.349c.0b8a@mx.google.com> References: <46cb515a0811301128r56cadb1dgf945e2adb8555551@mail.gmail.com> <4932f406.25e2660a.5dc6.ffffe84c@mx.google.com> <46cb515a0811301249u6e6cd927m2685c0021f65dd63@mail.gmail.com> <46cb515a0812021016x2bb7604dk3dc75cf33f6a07b1@mail.gmail.com> <4935c1f1.02225e0a.349c.0b8a@mx.google.com> Message-ID: <46cb515a0812030854h1903468dia07f64fab4f576f3@mail.gmail.com> On Wed, Dec 3, 2008 at 1:17 AM, Laurent Dufrechou wrote: > Hi ville, I'm a definitive supported of your html view! Good thing, since you can be of assistance due to your hard-earned wx gui experience, if you want of course :-). The code is now available at lp:~ipython-dev/ipython/ipython-extensions which means it can be committed to by others (if you feel like fiddling with it). > Autocompletion is a little bit sluggish, I've tried import wx. > Wx. > Tooks ages to render in html :p, and after the gui was really slow, I thinks > it try to render the whole hmtl page or something like this. Yeah, it seems having a very long
    list in the qtextedit slows it down severely. I probably want to change it to a fancier autocompleter anyway (something like scintilla's native one). -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Dec 3 13:27:39 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 3 Dec 2008 20:27:39 +0200 Subject: [IPython-dev] [IPython-user] Qt gui now usable (sort of) :-) In-Reply-To: <46cb515a0812030854h1903468dia07f64fab4f576f3@mail.gmail.com> References: <46cb515a0811301128r56cadb1dgf945e2adb8555551@mail.gmail.com> <4932f406.25e2660a.5dc6.ffffe84c@mx.google.com> <46cb515a0811301249u6e6cd927m2685c0021f65dd63@mail.gmail.com> <46cb515a0812021016x2bb7604dk3dc75cf33f6a07b1@mail.gmail.com> <4935c1f1.02225e0a.349c.0b8a@mx.google.com> <46cb515a0812030854h1903468dia07f64fab4f576f3@mail.gmail.com> Message-ID: <46cb515a0812031027h776d005dp18222f74b6b11cb4@mail.gmail.com> On Wed, Dec 3, 2008 at 6:54 PM, Ville M. Vainio wrote: >> Autocompletion is a little bit sluggish, I've tried import wx. >> Wx. >> Tooks ages to render in html :p, and after the gui was really slow, I thinks >> it try to render the whole hmtl page or something like this. > > Yeah, it seems having a very long
      list in the qtextedit slows it > down severely. I probably want to change it to a fancier autocompleter > anyway (something like scintilla's native one). Done! http://img356.imageshack.us/img356/55/qtautocompleteou3.png -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Dec 3 13:44:05 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 3 Dec 2008 20:44:05 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos Message-ID: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> To enhance autocompleter operation, I thought I should add a few hooks: 'get_line_idx' => int return the position of "cursor" on current line. Alternative names: get_caret_pos, get_line_buf_idx. 'get_current_line_buffer' => string return the current line. This is for the benefit of custom completers in gui's (and emacs). Currently, these are directly provided by readline, and you can monkeypatch your way around this requirement, but that's obviously not something to like... See test/test_completer.py for monkeypatching alternative. -- Ville M. Vainio http://tinyurl.com/vainio From vivainio at gmail.com Wed Dec 3 13:47:38 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 3 Dec 2008 20:47:38 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> Message-ID: <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> On Wed, Dec 3, 2008 at 8:44 PM, Ville M. Vainio wrote: > Currently, these are directly provided by readline, and you can > monkeypatch your way around this requirement, but that's obviously not > something to like... Addendun: we can factor out the need for readline as far as completion goes by making default hooks that use readline in a separate extension. Frankly, I'd look to hook away the whole readline requirement, it should be pretty simple in practice. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Thu Dec 4 23:05:54 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Thu, 4 Dec 2008 20:05:54 -0800 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> Message-ID: <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> Ville, I don't really know the readline and completion related parts of IPython very well. But, I am all for abstracting the readline stuff out. I also think that initially hooks are probably the best way of going about that. But, while we are on this topic, what do you think about the eventual unification of the existing IPython core and IPython.kernel.core? I would love to get rid of IPython.kernel.core, and just use IPython, but I don't think it is ready yet. You probably know the existing core as well as anyone, so I wanted to get your opinion. More questions: * What do you think the main challenges are? (I have my own list, but I am curious what you have in mind). * What do you think the best approach is to move forward on all of this stuff? Back to the question of hooking readline out. For now, I think hooks will be fine. Eventually, I think we need to re-visit the hooks system to see if it is really what we need movig forward. Cheers, Brian On Wed, Dec 3, 2008 at 10:47 AM, Ville M. Vainio wrote: > On Wed, Dec 3, 2008 at 8:44 PM, Ville M. Vainio wrote: > >> Currently, these are directly provided by readline, and you can >> monkeypatch your way around this requirement, but that's obviously not >> something to like... > > Addendun: we can factor out the need for readline as far as completion > goes by making default hooks that use readline in a separate > extension. > > Frankly, I'd look to hook away the whole readline requirement, it > should be pretty simple in practice. > > -- > Ville M. Vainio > http://tinyurl.com/vainio > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From jorgen.stenarson at bostream.nu Fri Dec 5 15:26:57 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Fri, 05 Dec 2008 21:26:57 +0100 Subject: [IPython-dev] Fixes for Bug #274067 Message-ID: <49398E91.60501@bostream.nu> Hi, I have attached a branch with a fix to bug #274607. The branch also adds some tests for a few other functions in the same module. Should I add the branch for review? /J?rgen From ellisonbg.net at gmail.com Fri Dec 5 17:32:19 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Fri, 5 Dec 2008 14:32:19 -0800 Subject: [IPython-dev] Fixes for Bug #274067 In-Reply-To: <49398E91.60501@bostream.nu> References: <49398E91.60501@bostream.nu> Message-ID: <6ce0ac130812051432t34c9aa44je9541d224d8fbb1e@mail.gmail.com> Yes, please post the branch on launchpad (if you haven't already) and then create a proposal to merge it. Also, when you do that, create a short description of what the branch contains. Then we will all jump in and review it. Cheers, Brian On Fri, Dec 5, 2008 at 12:26 PM, J?rgen Stenarson wrote: > Hi, > > I have attached a branch with a fix to bug #274607. > The branch also adds some tests for a few other functions in the same > module. > > Should I add the branch for review? > > /J?rgen > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From vivainio at gmail.com Sat Dec 6 17:22:49 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 7 Dec 2008 00:22:49 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> Message-ID: <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> On Fri, Dec 5, 2008 at 6:05 AM, Brian Granger wrote: > But, while we are on this topic, what do you think about the eventual > unification of the existing IPython core and IPython.kernel.core? I > would love to get rid of IPython.kernel.core, and just use IPython, > but I don't think it is ready yet. You probably know the existing > core as well as anyone, so I wanted to get your opinion. So what's missing from the IPython core that you would like to use? Perhaps there is something we should add to ipapi? IPython core should be pretty easy to extend in the fashion that allows it to do whatever it is you need to integrate your other stuff with it. > * What do you think the main challenges are? (I have my own list, but > I am curious what you have in mind). I don't really see the challenges, but that depends on your set of requirements. I would "just do it" and see what breaks. > * What do you think the best approach is to move forward on all of this stuff? Again, it depends on what you mean by "all this stuff". Personally, I would just use normal IPython as the engine, with necessary output trapping as needed. If you list the problems you are concerned about, I can give you more specific answers. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Sat Dec 6 20:06:22 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sat, 6 Dec 2008 17:06:22 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) Message-ID: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> Hi, (yes, I put TextMate first in that list ;-) ) I am in the process of designing a simple IPC mechanism that will allow various editors to talk to IPython. This has been done before, but I was to clean all this up and provide a single solution that all editors can use. So, here is the idea: * Create a UNIX socket at the location: ~/.ipython/IPY-SERVER-{time} Where {time} will be some simple time stamp. * Create a server that listens on this socket using Twisted. The protocol on this socket will be the following: BLOCKBEGIN import math a = 2.0*math.pi BLOCKEND That is, it will be line based, and the client will have to send BLOCKBEGIN/BLOCKEND to mark the beginning and end of a block of code. When the client sends BLOCKEND, IPython will execute the code. One question, what should we use to mark the end of lines (what does IPython use) \n or \r\n? * We should have a command line switch that activates this server upon starting IPython (--server) * All editors should then use this to talk to IPython. All other approaches will be phased out. * The new design will make it very easy to add new capabilities to the server. Cheers, Brian From gael.varoquaux at normalesup.org Sun Dec 7 05:21:16 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 7 Dec 2008 11:21:16 +0100 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> Message-ID: <20081207102116.GA11204@phare.normalesup.org> On Sat, Dec 06, 2008 at 05:06:22PM -0800, Brian Granger wrote: > I am in the process of designing a simple IPC mechanism that will > allow various editors to talk to IPython. This has been done before, > but I was to clean all this up and provide a single solution that all > editors can use. So, here is the idea: Brian, This is fantastic. I look very much forward to this. Will your architecture work under Wdinows? Ga?l From ellisonbg.net at gmail.com Sun Dec 7 11:08:46 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 08:08:46 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <20081207102116.GA11204@phare.normalesup.org> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> Message-ID: <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> > This is fantastic. I look very much forward to this. > > Will your architecture work under Wdinows? I don't think it will work with a Unix socket, but is there a Windows equivalent. If there is, it should be trivial to get it to work. Brian > > Ga?l > From gael.varoquaux at normalesup.org Sun Dec 7 11:14:37 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 7 Dec 2008 17:14:37 +0100 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> Message-ID: <20081207161437.GB6025@phare.normalesup.org> On Sun, Dec 07, 2008 at 08:08:46AM -0800, Brian Granger wrote: > > This is fantastic. I look very much forward to this. > > Will your architecture work under Wdinows? > I don't think it will work with a Unix socket, but is there a Windows > equivalent. If there is, it should be trivial to get it to work. I think there is. It is just a socket, although it is not "Unix". For instance IDLE, which is based on IPC between the frontend and the execution engine, works under windows, although it can be blocked by firewalls. Ga?l From ellisonbg.net at gmail.com Sun Dec 7 12:27:04 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 09:27:04 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <20081207161437.GB6025@phare.normalesup.org> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> <20081207161437.GB6025@phare.normalesup.org> Message-ID: <6ce0ac130812070927x68d768a6q36e491c158021aae@mail.gmail.com> > I think there is. It is just a socket, although it is not "Unix". For > instance IDLE, which is based on IPC between the frontend and the > execution engine, works under windows, although it can be blocked by > firewalls. Is it an actual TCP/IP socket, or something more like a Unix socket? I will try to look into this later when I go back to this stuff. Brian > Ga?l > From barrywark at gmail.com Sun Dec 7 12:33:13 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 7 Dec 2008 09:33:13 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> Message-ID: On Sun, Dec 7, 2008 at 8:08 AM, Brian Granger wrote: >> This is fantastic. I look very much forward to this. >> >> Will your architecture work under Wdinows? > > I don't think it will work with a Unix socket, but is there a Windows > equivalent. If there is, it should be trivial to get it to work. I haven't had a chance to play with the new server yet, so this is just idle chat... Please forgive my Twisted newbie-ness, but why not use an IProcessProtocol? I realize that running a service on a socket lets multiple editors connect, but is that really a likely use case? If you're really planning on having multiple clients, don't you have to end up replicating (or using) all of IPython.kernel to deal with the semantics of multiple clients connecting to an IPython instance? barry > > Brian > >> >> Ga?l >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg.net at gmail.com Sun Dec 7 12:49:06 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 09:49:06 -0800 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> Message-ID: <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> > So what's missing from the IPython core that you would like to use? > Perhaps there is something we should add to ipapi? IPython core should > be pretty easy to extend in the fashion that allows it to do whatever > it is you need to integrate your other stuff with it. Good questions. 1. The IPython parser+prefilter needs to be block based and the line based logic need to be separated out into a separate Frontend class. Currently, both the prefilter and parser operate in a line based fashion. Thus, even for your nice block based Qt frontend, it is not *really* block based. Most importantly, you have to have multiple newlines to end a block of code. That is not valid Python though. This logic in currently in runsource, runcode, push, raw_input and friends. We have a true block based parser in the execute_python method here: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/1152?file_id=interpreter.py-20080606193734-psuinzq9276j4ah1-42 We also have the basics of a frontend here: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/files/1152?file_id=frontend-20080611225339-bjp8mnnd2tnxj9n5-1 The default prefilter should still be lines based though (once the parsing has happened, but it should be possible to have a completely block based prefilter. 2. Everything must be refactored in a way that the frontend can run in a different process. This means that the frontend must be a separate class that talks to the core through a clean well defined API that *can't* be hacked like the current ipapi.IP hack that goes on. 3. We need a way of capturing stdout/stderr/stdin that allows things to be done over a network connection. See IPython.kernel.core for how we do this now, but this is not even sufficient as 1) it doesn't handle stdin and 2) it only returns stdout/stderr when a block is done executing. Thus, the following won't do what you expect: for i in range(10): time.sleep(1) print i (it prints is all at the end rather than asynchronously). 4. The core needs to be threadsafe and allow Twisted to be run in a thread. This is needed because currently (for example in the new TextMate bundle) we are calling the core (ipapi.runlines) in a very thread-unsafe manner. This will require rethinking from the ground up how we handle the threaded shells and GUI integration. 5. The output of certain things like tracebacks and other colored text, needs to be represented in a way (i.e., without ASCI coloring) that is independent of the terminal. The best choices are something like XML or Python dicts. Otherwise, non terminal based frontends will have a though time coloring such things. 6. Because the frontend and the core can be run in different processes, we need to rethink the usage of hooks and how IPython is configured/customized on the fly. While the hook system is better than nothing, my feeling is that it exists to simply cover up the nasty, monolithic design of iplib. kernel.core.interpreter has the beginnings of a cleaner design that is much more modular an loosely coupled. 7. The core needs to have a super clean API that is based only on methods, not attributes. Otherwise it is difficult to propagate things over a network connection. We have a sketch of such an API in kernel.core.interpreter. 8. As you mention, readline needs to be factored out, but when this is done, we need to create the frontend that is a completely separate class. My challenge is that I don't know the code base of the existing core very well. Plus there are some really subtle things going on - especially with threads. It will take me a long time to get up to speed on these things so I an make the needed changes. But, I may end up doing this. I would love to get your feedback on these things. Cheers, Brian >> * What do you think the main challenges are? (I have my own list, but >> I am curious what you have in mind). > > I don't really see the challenges, but that depends on your set of > requirements. I would "just do it" and see what breaks. > >> * What do you think the best approach is to move forward on all of this stuff? > > Again, it depends on what you mean by "all this stuff". Personally, I > would just use normal IPython as the engine, with necessary output > trapping as needed. If you list the problems you are concerned about, > I can give you more specific answers. > > -- > Ville M. Vainio > http://tinyurl.com/vainio > From ellisonbg.net at gmail.com Sun Dec 7 12:52:49 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 09:52:49 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> Message-ID: <6ce0ac130812070952h4934bfb5n1215665aeb65f464@mail.gmail.com> > Please forgive my Twisted newbie-ness, but why not use an > IProcessProtocol? I realize that running a service on a socket lets > multiple editors connect, but is that really a likely use case? I think potentially yes. But remember, you can't connect/reconnect a process protocol. Also, I don't think you can attach a process protocol to a process that someone else started. Using a Unix socket makes all of these things trivial. > If > you're really planning on having multiple clients, don't you have to > end up replicating (or using) all of IPython.kernel to deal with the > semantics of multiple clients connecting to an IPython instance? No, not really, because the only capability we are exposing is execute, and we don't even return stdout (it is printed in IPython itself). But, yes, eventually, all of this should be based on the engine itself. But for now, this is an easy thing to maintain. Have a look at the code and you will see what I mean. Good question though. Cheers, Brian > barry > >> >> Brian >> >>> >>> Ga?l >>> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> > From vivainio at gmail.com Sun Dec 7 14:14:05 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 7 Dec 2008 21:14:05 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> Message-ID: <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> On Sun, Dec 7, 2008 at 7:49 PM, Brian Granger wrote: > 1. The IPython parser+prefilter needs to be block based and the line > based logic need to be separated out into a separate Frontend class. We can make it block-based by handling it block-at-the time, instead of line-at-a-time, by just splitting the lines and running the lines through prefilter function. I am not a big fan of moving prefiltering to frontend classes, so can't comment on that. > 2. Everything must be refactored in a way that the frontend can run > in a different process. > > This means that the frontend must be a separate class that talks to > the core through a clean well defined API that *can't* be hacked like > the current ipapi.IP hack that goes on. The ipapi.IP hacks are mostly there because of the unwillingness to add to the api (especially regarding something unimportant). Frontends shouldn't really need it. There is nothing hugely important that mandates its use anyway, so I won't expect you to hit any problems. > 3. We need a way of capturing stdout/stderr/stdin that allows things > to be done over a network connection. See IPython.kernel.core for how > we do this now, but this is not even sufficient as 1) it doesn't > handle stdin and 2) it only returns stdout/stderr when a block is done > executing. Thus, the following won't do what you expect: > > for i in range(10): > time.sleep(1) > print i > > (it prints is all at the end rather than asynchronously). The stdin is the bigger problem, but normal stdout capturing should take care of the partial stdout problem rather easily. Can't you just send the data over the network connection? > 4. The core needs to be threadsafe and allow Twisted to be run in a > thread. This is needed because currently (for example in the new > TextMate bundle) we are calling the core (ipapi.runlines) in a very > thread-unsafe manner. This will require rethinking from the ground up > how we handle the threaded shells and GUI integration. Threaded GUI shells can probably be ignored in the future, since it's questionable whether they are even required. > > 5. The output of certain things like tracebacks and other colored > text, needs to be represented in a way (i.e., without ASCI coloring) > that is independent of the terminal. The best choices are something > like XML or Python dicts. Otherwise, non terminal based frontends > will have a though time coloring such things. It's actually quite easy to color that stuff, as it's already done in various gui frontends. If I were you, I wouldn't give this particular issue much thought. > configured/customized on the fly. While the hook system is better > than nothing, my feeling is that it exists to simply cover up the > nasty, monolithic design of iplib. kernel.core.interpreter has the > beginnings of a cleaner design that is much more modular an loosely > coupled. But some kind of hook system will still be needed, so let's not remove it before replacement is ready. -- Ville M. Vainio http://tinyurl.com/vainio From ellisonbg.net at gmail.com Sun Dec 7 14:40:06 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 11:40:06 -0800 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> Message-ID: <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> >> 1. The IPython parser+prefilter needs to be block based and the line >> based logic need to be separated out into a separate Frontend class. > > We can make it block-based by handling it block-at-the time, instead > of line-at-a-time, by just splitting the lines and running the lines > through prefilter function. I am not a big fan of moving prefiltering > to frontend classes, so can't comment on that. Yes, the prefilter is easy to make block based. But, the parser stuff is quite a bit more involved and that is the more important part. I agree with you that the prefilter (like the parser) should be in the core, not the frontend. What *does* need to be in the frontend (once the core is block based) is all the extra logic (for line based interfaces) that handles line based input - prompts, when is a block complete, etc. >> 2. Everything must be refactored in a way that the frontend can run >> in a different process. >> >> This means that the frontend must be a separate class that talks to >> the core through a clean well defined API that *can't* be hacked like >> the current ipapi.IP hack that goes on. > > The ipapi.IP hacks are mostly there because of the unwillingness to > add to the api (especially regarding something unimportant). Frontends > shouldn't really need it. There is nothing hugely important that > mandates its use anyway, so I won't expect you to hit any problems. This one is definitely easier. But, I think we should expand the ipapi interface if this is the reason we haven't. >> 3. We need a way of capturing stdout/stderr/stdin that allows things >> to be done over a network connection. See IPython.kernel.core for how >> we do this now, but this is not even sufficient as 1) it doesn't >> handle stdin and 2) it only returns stdout/stderr when a block is done >> executing. Thus, the following won't do what you expect: >> >> for i in range(10): >> time.sleep(1) >> print i >> >> (it prints is all at the end rather than asynchronously). > > The stdin is the bigger problem, but normal stdout capturing should > take care of the partial stdout problem rather easily. Can't you just > send the data over the network connection? For stdout we can, but making is really asynchronous is not trivial, but it is doable. Stdin will be a pain in the @$$. >> 4. The core needs to be threadsafe and allow Twisted to be run in a >> thread. This is needed because currently (for example in the new >> TextMate bundle) we are calling the core (ipapi.runlines) in a very >> thread-unsafe manner. This will require rethinking from the ground up >> how we handle the threaded shells and GUI integration. > > Threaded GUI shells can probably be ignored in the future, since it's > questionable whether they are even required. In what sense? Obviously, people will continue to want to use GUIs in conjunction with IPython, correct? >> >> 5. The output of certain things like tracebacks and other colored >> text, needs to be represented in a way (i.e., without ASCI coloring) >> that is independent of the terminal. The best choices are something >> like XML or Python dicts. Otherwise, non terminal based frontends >> will have a though time coloring such things. > > It's actually quite easy to color that stuff, as it's already done in > various gui frontends. If I were you, I wouldn't give this particular > issue much thought. Nice, what do you think the best way of handling this is? Just convert the ASCI colors to whatever the frontend needs? What about web based frontends? >> configured/customized on the fly. While the hook system is better >> than nothing, my feeling is that it exists to simply cover up the >> nasty, monolithic design of iplib. kernel.core.interpreter has the >> beginnings of a cleaner design that is much more modular an loosely >> coupled. > > But some kind of hook system will still be needed, so let's not remove > it before replacement is ready. Absolutely!!! This is one of the big benefits of having only one code base now - every merge into trunk that we do must keep everything in a completely working and tested state. That is why we it is so important for *everything* to have tests. Obviously, we will have to break the API at times, but that will be a deliberate decision to improve IPython. Brian From vivainio at gmail.com Sun Dec 7 15:24:12 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 7 Dec 2008 22:24:12 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> Message-ID: <46cb515a0812071224r738bb8a0r37350491115f2e3c@mail.gmail.com> On Sun, Dec 7, 2008 at 9:40 PM, Brian Granger wrote: > core, not the frontend. What *does* need to be in the frontend (once > the core is block based) is all the extra logic (for line based > interfaces) that handles line based input - prompts, when is a block > complete, etc. Ah, I thought you were to allow block-based operation aside the existing line-based stuff, as opposed to doing a wholesale replacement. I'm not sure whether the moveover is worth the effort & regression risk (as opposed to having parallel systems that both work), but you have to try it out and see. >> The ipapi.IP hacks are mostly there because of the unwillingness to >> add to the api (especially regarding something unimportant). Frontends >> shouldn't really need it. There is nothing hugely important that >> mandates its use anyway, so I won't expect you to hit any problems. > > This one is definitely easier. But, I think we should expand the > ipapi interface if this is the reason we haven't. Agreed, >> Threaded GUI shells can probably be ignored in the future, since it's >> questionable whether they are even required. > > In what sense? Obviously, people will continue to want to use GUIs in > conjunction with IPython, correct? Yeah, but the current threaded shells are probably not needed. Most UI tookits can be made to work with PyOS_InputHook, so we don't need a different thread for ui mainloop and the raw_input. > Nice, what do you think the best way of handling this is? Just > convert the ASCI colors to whatever the frontend needs? What about Yes (they are typically called ANSI colors btw) > web based frontends? They can be converted to html. That's what I do in the qt ui. -- Ville M. Vainio http://tinyurl.com/vainio From gael.varoquaux at normalesup.org Sun Dec 7 15:30:44 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 7 Dec 2008 21:30:44 +0100 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812070927x68d768a6q36e491c158021aae@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> <20081207161437.GB6025@phare.normalesup.org> <6ce0ac130812070927x68d768a6q36e491c158021aae@mail.gmail.com> Message-ID: <20081207203044.GA17526@phare.normalesup.org> On Sun, Dec 07, 2008 at 09:27:04AM -0800, Brian Granger wrote: > Is it an actual TCP/IP socket, or something more like a Unix socket? AFAIK the difference is not huge. I mean that a TCP/IP socket can be used as a replacement for a Unix socket, when Unix sockets are not available. But then, I don't know much about this... Ga?l From ellisonbg.net at gmail.com Sun Dec 7 15:32:45 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Sun, 7 Dec 2008 12:32:45 -0800 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <46cb515a0812071224r738bb8a0r37350491115f2e3c@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> <46cb515a0812071224r738bb8a0r37350491115f2e3c@mail.gmail.com> Message-ID: <6ce0ac130812071232i2ba5f2d5o67ca2c7bf67ab4f9@mail.gmail.com> >> In what sense? Obviously, people will continue to want to use GUIs in >> conjunction with IPython, correct? > > Yeah, but the current threaded shells are probably not needed. Most UI > tookits can be made to work with PyOS_InputHook, so we don't need a > different thread for ui mainloop and the raw_input. Hmmm. I am not familiar with PyOS_InputHook, what does it do? It would be great to get rid of all the threading tricks for sure! Do we have a prototype of using PyOS_InputHook? By the name of this method, I am not sure it will handle all the cases we need. Also, we need to make sure that IPython can run Twisted in a thread and all that integrates with what is done with the GUIs. But, what does PyOS_InputHook do? >> Nice, what do you think the best way of handling this is? Just >> convert the ASCI colors to whatever the frontend needs? What about > > Yes (they are typically called ANSI colors btw) doh. >> web based frontends? > > They can be converted to html. That's what I do in the qt ui. OK, I won't worry about this then. Cheers, Brian > -- > Ville M. Vainio > http://tinyurl.com/vainio > From gael.varoquaux at normalesup.org Sun Dec 7 15:36:25 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 7 Dec 2008 21:36:25 +0100 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> Message-ID: <20081207203625.GB17526@phare.normalesup.org> On Sun, Dec 07, 2008 at 11:40:06AM -0800, Brian Granger wrote: > For stdout we can, but making is really asynchronous is not trivial, > but it is doable. Stdin will be a pain in the @$$. I have been following this discussion only very lightly, but I think I have dealt with stdin in my frontend (look at the machinerie in wx_frontend, especially the system_call method). With the Wx frontend it works. I think it could be abstracted out to work with most of the GUI toolkit out there. Ga?l From vivainio at gmail.com Sun Dec 7 15:57:06 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Sun, 7 Dec 2008 22:57:06 +0200 Subject: [IPython-dev] New hooks suggestion: line buf, cursor pos In-Reply-To: <6ce0ac130812071232i2ba5f2d5o67ca2c7bf67ab4f9@mail.gmail.com> References: <46cb515a0812031044r343a26adl597401a522d48a5d@mail.gmail.com> <46cb515a0812031047o71855c9dw7d786214f926289b@mail.gmail.com> <6ce0ac130812042005o7073af00ndccbb210aa1028e1@mail.gmail.com> <46cb515a0812061422r46b79388ua984aa0fa362e4a1@mail.gmail.com> <6ce0ac130812070949k682b4608lc56515bc4b537bc2@mail.gmail.com> <46cb515a0812071114m3ccfefc8s3627b7178e82618f@mail.gmail.com> <6ce0ac130812071140t3962c74bjdab1966860e99d30@mail.gmail.com> <46cb515a0812071224r738bb8a0r37350491115f2e3c@mail.gmail.com> <6ce0ac130812071232i2ba5f2d5o67ca2c7bf67ab4f9@mail.gmail.com> Message-ID: <46cb515a0812071257r247b929bxca35ca45a4ab521a@mail.gmail.com> On Sun, Dec 7, 2008 at 10:32 PM, Brian Granger wrote: > Hmmm. I am not familiar with PyOS_InputHook, what does it do? It runs the gui event loop when readline is reading input (i.e. python is sitting at raw_input()). This has classically worked with Tk (one of the reasons tk shell is single threaded). The same works with Qt and new Gtk. > It would be great to get rid of all the threading tricks for sure! Do > we have a prototype of using PyOS_InputHook? By the name of this > method, I am not sure it will handle all the cases we need. - Tk ipython shell is already one example - https://bugs.launchpad.net/ipython/+bug/270856 > Also, we need to make sure that IPython can run Twisted in a thread > and all that integrates with what is done with the GUIs. But, what > does PyOS_InputHook do? I think someone (Glenn Tarbox) used qt4reactor with ipython without needing threads. -- Ville M. Vainio http://tinyurl.com/vainio From barrywark at gmail.com Sun Dec 7 16:56:35 2008 From: barrywark at gmail.com (Barry Wark) Date: Sun, 7 Dec 2008 13:56:35 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812070952h4934bfb5n1215665aeb65f464@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <20081207102116.GA11204@phare.normalesup.org> <6ce0ac130812070808w1f2c2f92ocbefa38690d3a8e8@mail.gmail.com> <6ce0ac130812070952h4934bfb5n1215665aeb65f464@mail.gmail.com> Message-ID: On Sun, Dec 7, 2008 at 9:52 AM, Brian Granger wrote: >> Please forgive my Twisted newbie-ness, but why not use an >> IProcessProtocol? I realize that running a service on a socket lets >> multiple editors connect, but is that really a likely use case? > > I think potentially yes. But remember, you can't connect/reconnect a > process protocol. Also, I don't think you can attach a process > protocol to a process that someone else started. Using a Unix socket > makes all of these things trivial. I see. Not being able to reconnect is obviously a deal breaker. Thanks for the explanation. > >> If >> you're really planning on having multiple clients, don't you have to >> end up replicating (or using) all of IPython.kernel to deal with the >> semantics of multiple clients connecting to an IPython instance? > > No, not really, because the only capability we are exposing is > execute, and we don't even return stdout (it is printed in IPython > itself). But, yes, eventually, all of this should be based on the > engine itself. But for now, this is an easy thing to maintain. Have > a look at the code and you will see what I mean. I see what you mean. It is very clear code, so it's definitely worth going with this approach. Thanks for bearing with my nagging. > > Good question though. > > Cheers, > > Brian > > >> barry >> >>> >>> Brian >>> >>>> >>>> Ga?l >>>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>> >> > From vishal.vatsa at gmail.com Mon Dec 8 05:43:23 2008 From: vishal.vatsa at gmail.com (Vishal Vatsa) Date: Mon, 08 Dec 2008 10:43:23 +0000 Subject: [IPython-dev] ipcluster with clusterfile References: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com> <6ce0ac130811050919s1eae7fc8l9e8020ff4420c8db@mail.gmail.com> <6ce0ac130811161446y52aa965fx3394b0a40677a67c@mail.gmail.com> <6ce0ac130811191133q72bb2dc2wf03367d8c63879b@mail.gmail.com> <6ce0ac130811251729o995bbfas3f42473c7e12a191@mail.gmail.com> <6ce0ac130812011404h5e40a1oc99bbd8906d996a4@mail.gmail.com> Message-ID: Hi Brian, Did a new push on friday, I think I have addressed your points. Please let me know what you think. Regards, -vishal Brian Granger wrote: > Vishal, > > I saw this and will get to it soon. Thanks. > > Brian > > On Mon, Dec 1, 2008 at 2:23 AM, Vishal Vatsa > wrote: >> Brian, >> >> There is a merge request available at: >> https://code.launchpad.net/~vvatsa/ipython/ipcluster-dev/+merge/1965 >> >> Can you take a look and let me know. >> >> Thanks, >> -vishal. >> >> Brian Granger wrote: >> >>> Vishal, >>> >>> Cool! >>> >>> Can you create a launchpad proposal to merge (into my branch) for your >>> branch. That way others can review your work as well and we can keep >>> all the comments together. Once you do that I will begin looking at >>> this. >>> >>> Cheers, >>> >>> Brian >>> >>> On Mon, Nov 24, 2008 at 6:56 AM, Vishal Vatsa >>> wrote: >>>> >>>> Brian Granger wrote: >>>> >>>>>>> If you start hacking on the ssh cluster, keep in touch so we can >>>>>>> coordinate. >>>> Hi Brian, >>>> >>>> I have done my 1st drop of a working ssh cluster (sort of manager), >>>> >>>> http://bazaar.launchpad.net/%7Evvatsa/ipython/ipcluster-dev/revision/1165?start_revid=1165 >>>> >>>> Works in a similar way as to 0.8.x ipcluster, the main caveat is that >>>> this is very *nix, don't think this will work in windows, I have tested >>>> this on GNU/Linux systems, no reason it should not work on OS X. >>>> >>>> Have a look and if you have any pointers, let me know. >>>> I wanted to be happy with the cluster semantics 1st and then I would be >>>> happy to fix any implementation issues. >>>> >>>> Regards, >>>> -vishal >>>> >>>> >>>> >>>> _______________________________________________ >>>> IPython-dev mailing list >>>> IPython-dev at scipy.org >>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >>>> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev >> From ellisonbg.net at gmail.com Mon Dec 8 18:53:08 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Mon, 8 Dec 2008 15:53:08 -0800 Subject: [IPython-dev] Be sure to merge from trunk often Message-ID: <6ce0ac130812081553x1dd5a126of9027751ffb97f30@mail.gmail.com> Hello all, It seems that we are getting a lot of activity with all the contributions and code reviews going on. One reminder, as branches get merged into trunk, please make sure you merge trunk *often*B into your branches that are being reviewed. With many of us editing the docs (especially changes.txt), you will probably have to resolve some merge conflicts as well. Thanks everyone for the hard work! Cheers, Brian From matt.p.foster at gmail.com Tue Dec 9 06:25:14 2008 From: matt.p.foster at gmail.com (Matt Foster) Date: Tue, 9 Dec 2008 11:25:14 +0000 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> Message-ID: <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> On Sun, Dec 7, 2008 at 1:06 AM, Brian Granger wrote: > Hi, > > (yes, I put TextMate first in that list ;-) ) > > I am in the process of designing a simple IPC mechanism that will > allow various editors to talk to IPython. This has been done before, > but I was to clean all this up and provide a single solution that all > editors can use. So, here is the idea: > > * Create a UNIX socket at the location: > > ~/.ipython/IPY-SERVER-{time} > > Where {time} will be some simple time stamp. > > * Create a server that listens on this socket using Twisted. The > protocol on this socket will be the following: > > BLOCKBEGIN > import math > a = 2.0*math.pi > BLOCKEND > > That is, it will be line based, and the client will have to send > BLOCKBEGIN/BLOCKEND to mark the beginning and end of a block of code. > When the client sends BLOCKEND, IPython will execute the code. > > One question, what should we use to mark the end of lines (what does > IPython use) \n or \r\n? > > * We should have a command line switch that activates this server upon > starting IPython (--server) > > * All editors should then use this to talk to IPython. All other > approaches will be phased out. > > * The new design will make it very easy to add new capabilities to the server. Brian, This sounds really good. Do you think a twisted-based client library would be a good idea too? Also, as something of an aside, will it be possible to add executed lines/files to IPython's history? I've got a feeling this would involve modifying ipapi.runlines but I've no idea where to start. Cheers, Matt -- Matt Foster | http://hackerific.net From ellisonbg.net at gmail.com Tue Dec 9 20:29:45 2008 From: ellisonbg.net at gmail.com (Brian Granger) Date: Tue, 9 Dec 2008 17:29:45 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> Message-ID: <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> > This sounds really good. Do you think a twisted-based client library > would be a good idea too? Not sure? Are you writing the client in Python too? What event loop is present? > Also, as something of an aside, will it be possible to add executed > lines/files to IPython's history? Can you ask this as a separate question on IPython-dev to Ville sees this? > I've got a feeling this would involve modifying ipapi.runlines but > I've no idea where to start. Ville would know how to do this. Unfortunately I probably won't get back to this until the week after next. Brian > Cheers, > > Matt > > -- > Matt Foster | http://hackerific.net > From vivainio at gmail.com Wed Dec 10 01:13:07 2008 From: vivainio at gmail.com (Ville M. Vainio) Date: Wed, 10 Dec 2008 08:13:07 +0200 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> Message-ID: <46cb515a0812092213u2e75d669i72bc947724ab3e86@mail.gmail.com> On Wed, Dec 10, 2008 at 3:29 AM, Brian Granger wrote: >> Also, as something of an aside, will it be possible to add executed >> lines/files to IPython's history? > > Can you ask this as a separate question on IPython-dev to Ville sees this? I can see this here. Unfortunately, I'm swamped. >> I've got a feeling this would involve modifying ipapi.runlines but >> I've no idea where to start. I suggest we create a whole new ipapi commands: ipapi.translate_block (pushes every line of block through prefilters and returns the new block) ipapi.runblock (pushes the whole block as single history entry) -- Ville M. Vainio http://tinyurl.com/vainio From basti.wiesner at gmx.net Wed Dec 10 13:54:44 2008 From: basti.wiesner at gmx.net (Sebastian Wiesner) Date: Wed, 10 Dec 2008 19:54:44 +0100 Subject: [IPython-dev] Unicode literals in IPython Message-ID: <200812101954.51401.basti.wiesner@gmx.net> Hi, on my system ipython fails to correctly decode unicode literals: [2]--> u'?' Out[2]: u'\xc3\xa4' The standard python interpreter handles this correctly and gives u'\xe4' as expected. This issue was observed on a Gentoo System with Python 2.6 and IPython 0.9.1. The locale setting is "de_DE.utf8", and "sys.stdin.encoding" gives "UTF-8" in IPython. -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From barrywark at gmail.com Wed Dec 10 14:15:02 2008 From: barrywark at gmail.com (Barry Wark) Date: Wed, 10 Dec 2008 11:15:02 -0800 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <46cb515a0812092213u2e75d669i72bc947724ab3e86@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> <46cb515a0812092213u2e75d669i72bc947724ab3e86@mail.gmail.com> Message-ID: On Tue, Dec 9, 2008 at 10:13 PM, Ville M. Vainio wrote: > On Wed, Dec 10, 2008 at 3:29 AM, Brian Granger wrote: > >>> Also, as something of an aside, will it be possible to add executed >>> lines/files to IPython's history? >> >> Can you ask this as a separate question on IPython-dev to Ville sees this? > > I can see this here. Unfortunately, I'm swamped. > >>> I've got a feeling this would involve modifying ipapi.runlines but >>> I've no idea where to start. > > I suggest we create a whole new ipapi commands: > > ipapi.translate_block (pushes every line of block through prefilters > and returns the new block) > > ipapi.runblock (pushes the whole block as single history entry) +1 > > -- > Ville M. Vainio > http://tinyurl.com/vainio > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev > From matt.p.foster at gmail.com Sat Dec 13 11:46:03 2008 From: matt.p.foster at gmail.com (Matt Foster) Date: Sat, 13 Dec 2008 16:46:03 +0000 Subject: [IPython-dev] Generic design for an IPython servers that talks to editors (TextMate, vi, emacs) In-Reply-To: <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> References: <6ce0ac130812061706v7e555ab1tf9cac10a9b04937c@mail.gmail.com> <1dcb3f200812090325h6398b0c2g21ec1021f296c529@mail.gmail.com> <6ce0ac130812091729s50f4907awa25df8209b576cc2@mail.gmail.com> Message-ID: <1dcb3f200812130846k7582e453ua6be9315ece95831@mail.gmail.com> On Wed, Dec 10, 2008 at 1:29 AM, Brian Granger wrote: >> This sounds really good. Do you think a twisted-based client library >> would be a good idea too? > > Not sure? Are you writing the client in Python too? What event loop > is present? I was planning on using python, yes. I've never used twisted before, so currently I have a hacked version of the echoclient [1] example, which uses a reactor. I've no idea if this is the best loop, but I have it working with your textmate server. > Ville would know how to do this. Unfortunately I probably won't get > back to this until the week after next. Excellent. I'm going to be (mostly) out of email contact until the second week in Jan, too. Cheers, Matt [1]: http://github.com/mattfoster/ipython-tmbundle/tree/master/Support/lib/twisted_editor_client.py -- Matt Foster | http://hackerific.net From dsdale24 at gmail.com Sun Dec 14 18:07:35 2008 From: dsdale24 at gmail.com (Darren Dale) Date: Sun, 14 Dec 2008 18:07:35 -0500 Subject: [IPython-dev] requesting guidance with a custom completer for a dictionary-like object Message-ID: Hello, I am working on a custom completer for h5py, which provides a nice interface to hdf5 files with a dictionary-style interface. I would like to enable tab completion for these h5py objects (which share a common ancestor called _DictCompat), but I am testing with regular dictionaries. If I have: d={'a':{'b':1},'b':2} I can currently do: d[' and get a b if I do: d['a I would like to get: d['a'] but I get d['a' and then if I do d['a' I get d['a'a Also, it is common to have deeply nested hierarchies with h5py, so I would like to be able to do: d['a']. or d['a'][' I think I remember hearing that IPython used to do tab completion of dict-like objects, but the feature was removed because it was causing problems with user code. I was hoping someone might remember how this could be done, and could provide some guidance. Thanks, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipy_h5py_completer.py Type: text/x-python Size: 1615 bytes Desc: not available URL: From erik.tollerud at gmail.com Mon Dec 15 19:51:31 2008 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Mon, 15 Dec 2008 16:51:31 -0800 Subject: [IPython-dev] vim hook for ipy_editors.py Message-ID: Attached is a diff against the launchpad ipython that adds an entry for the vim text editor to the ipy_editors.py extension file. Seems to work find on my Ubuntu Intrepid install with the regular vim package... -------------- next part -------------- A non-text attachment was scrubbed... Name: ipy_editors.py Type: text/x-python Size: 2512 bytes Desc: not available URL: From davels at telus.net Wed Dec 17 00:10:30 2008 From: davels at telus.net (David Shilvock) Date: Tue, 16 Dec 2008 21:10:30 -0800 Subject: [IPython-dev] pyreadline [PATCH] AnsiWriter incorrectly applies background color Message-ID: I've been out of touch with IPython development for a while. The website for pyreadline says the svn repo is current but it doesn't look like there have been any updates for a while so I hope this is still relevant. Index: pyreadline/console/ansi.py =================================================================== --- pyreadline/console/ansi.py (revision 3108) +++ pyreadline/console/ansi.py (working copy) @@ -98,7 +98,7 @@ elif len(part) == 2 and "30" <= part <= "37": # set foreground color attr.color = trtable[int(part)-30] elif len(part) == 2 and "40" <= part <= "47": # set background color - attr.color = trtable[int(part)-40] + attr.background = trtable[int(part)-40] continue n += len(chunk) if True: -- DS From jorgen.stenarson at bostream.nu Wed Dec 17 14:02:18 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 17 Dec 2008 20:02:18 +0100 Subject: [IPython-dev] pyreadline [PATCH] AnsiWriter incorrectly applies background color In-Reply-To: References: Message-ID: <49494CBA.1080501@bostream.nu> David Shilvock skrev: > I've been out of touch with IPython development for a while. The website > for pyreadline says the svn repo is current but it doesn't look like there > have been any updates for a while so I hope this is still relevant. > David, thanks for your patch. I think one of the reasons you do not see any activity is because we moved the code over to launchpad (https://code.launchpad.net/pyreadline). I should go over the old wiki pages and update them with correct references. If you feel like helping out the docs really need attention. If there are any other questions or requests feel free to ask them on list. There are currently two branches trunk which have seens a few bugfixes since we moved it over. And the refactor branch on which a lot of cleaning up and simplifying of the code base has been done. However the activity has been intermittent. My goal is to fold back the refactoring into trunk and then start to work on getting pyreadline to python 3.0. /J?rgen From jorgen.stenarson at bostream.nu Wed Dec 17 14:14:42 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 17 Dec 2008 20:14:42 +0100 Subject: [IPython-dev] ipython wiki Message-ID: <49494FA2.306@bostream.nu> I have tried to create an account on the ipython wiki but I get some errormessage that I think is caused by localization to swedish in moinmoin and I have not figured out how to switch the wiki to english. Could someone please create an account for me using JorgenStenarson as username and email me the password. /J?rgen From davels at telus.net Thu Dec 18 00:06:48 2008 From: davels at telus.net (David Shilvock) Date: Wed, 17 Dec 2008 21:06:48 -0800 Subject: [IPython-dev] pyreadline [PATCH] AnsiWriter incorrectly applies background color In-Reply-To: <49494CBA.1080501@bostream.nu> (=?iso-8859-1?Q?=22J=F6rgen?= Stenarson"'s message of "Wed\, 17 Dec 2008 20\:02\:18 +0100") References: <49494CBA.1080501@bostream.nu> Message-ID: On Wed, 17 Dec 2008 20:02:18 +0100 J?rgen Stenarson wrote: > David Shilvock skrev: >> I've been out of touch with IPython development for a while. The website >> for pyreadline says the svn repo is current but it doesn't look like there >> have been any updates for a while so I hope this is still relevant. >> > David, > > thanks for your patch. I think one of the reasons you do not see any > activity is because we moved the code over to launchpad > (https://code.launchpad.net/pyreadline). Cool. I grabbed a copy of trunk to play with. Noticed that you already updated the wiki with a link to the bzr repo. You probably meant "lp:pyreadline" instead of "lp:ipython". > I should go over the old wiki pages and update them with correct > references. If you feel like helping out the docs really need > attention. If there are any other questions or requests feel free to ask > them on list. > > There are currently two branches trunk which have seens a few bugfixes > since we moved it over. And the refactor branch on which a lot of > cleaning up and simplifying of the code base has been done. However > the activity has been intermittent. My goal is to fold back the > refactoring into trunk and then start to work on getting pyreadline to > python 3.0. > > /J?rgen BTW it looks like you made a little Copy/Paste error when you incorporated my patch. Here's the fix. === modified file 'pyreadline/console/ansi.py' --- pyreadline/console/ansi.py 2008-12-17 18:27:56 +0000 +++ pyreadline/console/ansi.py 2008-12-18 04:26:31 +0000 @@ -98,7 +98,7 @@ elif len(part) == 2 and "30" <= part <= "37": # set foreground color attr.color = trtable[int(part)-30] elif len(part) == 2 and "40" <= part <= "47": # set background color - attr.backgroundcolor = trtable[int(part)-40] + attr.background = trtable[int(part)-40] continue n += len(chunk) if True: -- DS From jorgen.stenarson at bostream.nu Thu Dec 18 15:07:44 2008 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Thu, 18 Dec 2008 21:07:44 +0100 Subject: [IPython-dev] pyreadline [PATCH] AnsiWriter incorrectly applies background color In-Reply-To: References: <49494CBA.1080501@bostream.nu> Message-ID: <494AAD90.1060107@bostream.nu> David Shilvock skrev: > On Wed, 17 Dec 2008 20:02:18 +0100 J?rgen Stenarson wrote: >> David Shilvock skrev: >>> I've been out of touch with IPython development for a while. The website >>> for pyreadline says the svn repo is current but it doesn't look like there >>> have been any updates for a while so I hope this is still relevant. >>> >> David, >> >> thanks for your patch. I think one of the reasons you do not see any >> activity is because we moved the code over to launchpad >> (https://code.launchpad.net/pyreadline). > > Cool. I grabbed a copy of trunk to play with. Noticed that you already > updated the wiki with a link to the bzr repo. You probably meant > "lp:pyreadline" instead of "lp:ipython". > Typical, copy/paste is bad for you:) /J?rgen