[IPython-dev] twisted process pool...

[Barry Wark]

On Thu, May 8, 2008 at 9:51 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> This work might be relevant for IPython1
>>
>>  http://twistedmatrix.com/trac/browser/sandbox/dialtone/process_pool
>
> 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
>
> https://launchpad.net/ampoule/
>
>>  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.
>
> Brian
>
>
>>  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
>>
>>  --
>>  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
>>  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer
>>
>>
>>  _______________________________________________
>>  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
>