[IPython-dev] twisted process pool...
Thu May 8 17:24:20 CDT 2008
On Thu, May 8, 2008 at 9:51 AM, Brian Granger <firstname.lastname@example.org> wrote:
>> This work might be relevant for IPython1
> Thanks, I hadn't seen this. I really like the AMP protocol, but I
> don't think it is well suited to what we are doing with IPython1. For
> reference the project has moved to
>> Also, any further thinking been done on the integration of the twisted
>> event loop with pyreadline? More generally stated, I guess the question
>> really is, how hard is it to make pyreadline asynchronous (give it
>> cycles based on select or its new/better/different implementation epoll)
> I am not the one to comment on this, but I do think people have begun
> to think about this. It would probably be in ipython1/frontend. But
> I don't think people have gotten very far yet. Also, pyreadline is
> Windows only, so I think you are referring to a pyreadline that
> doesn't yet exist?
> That said, here is my take on this. Our model in ipython1 is that the
> core/kernel of ipython1 will provide the methods that something like
> readline (or the GUI equivalent) will need to call when certain things
> are triggered. The core/kernel will provide both blocking versions of
> these methods and fully asynchronous versions (that return deferreds).
> It will be up to the people who are writting frontends (IPython GUIs
> or terminals) to plug into whatever mechanism that exist (readline for
> the terminal, events for GUIs) for their context. Of course, much of
> the logic will be the same for all of these things, which is where (I
> think) we will need something like a new pyreadline. And yes, it
> would need to be able to handle both asynchronous and blocking
> situations. I think Barry Wark has possibly begun to work on some of
> this in the ipython1-cocoa branch - something like frontendbase.py?
Correct. The intention is that the ipython1.frontend.frontendbase
contains the common logic for frontends. It's currently async-based,
but will eventually have to encompass both async and sync models, much
like core/kernel vs. engineservice. Unfortunately, ipython1-cocoa is
in a pretty broken state as I'm working on it... I will let folks know
as soon as there's something worth looking at--but feel free to take a
look and comment in the mean time.
> Hope this helps, but I will say that we are not focused on this side
> of things right now. But we do have the design pieces in our heads.
>> Lately this has become a broader issue (for me at least) because similar
>> issues exist with Rpy... so I might be digging into this anyway...
>> Glenn H. Tarbox, PhD | Don't worry about people stealing your ideas. If your ideas
>> 206-494-0819 | are any good, you'll have to ram them down people's throats
>> email@example.com (gtalk) + ghtdak on aim/freenode | ^ Howard Aiken, IBM engineer
>> IPython-dev mailing list
> IPython-dev mailing list
More information about the IPython-dev