[IPython-dev] New hooks suggestion: line buf, cursor pos

[Ville M. Vainio]

On Sun, Dec 7, 2008 at 7:49 PM, Brian Granger <ellisonbg.net at gmail.com> 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