[IPython-dev] the state if IPython development...

[Ville M. Vainio]

On Tue, Mar 18, 2008 at 10:50 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:

>  On Tue, 2008-03-18 at 22:15 +0200, Ville M. Vainio wrote:
>  > On Tue, Mar 18, 2008 at 8:35 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
>
>
> > That tarball only has svn, which has been pretty much discontinued (we
>  > will just dump a bzr snapshot there, for curiosity's sake, but you
>  > shouldn't count on the svn anymore).
>
>  we should probably indicate this somewhere.  There is very little
>  information being disseminated WRT where one should go for the bleeding
>  edge (which is the only place I feel comfortable :-)

Thea deal is that there are 2 bleeding edges - the bzr of stable-dev
and bzr of IPython1. IPython1 is not the bleeding edge of IPython0,
even if both projects have "IPython" in it ;-).


Think of this as baz and bzr, standard readline and pyreadline, glade
and gazpacho...


>  Actually, this is fairly straightforward with Qt and, I believe, the
>  other gui mainloops.  Since you're embracing twisted, I recommend adding
>  stdin and stdout to the event notification hooks and you're mostly done.
>  This is what I'm (kinda) doing... where things fall down a bit is when
>  IPython grabs the loop during scrolling (for example when reading the
>  docs which spew with a '??'.)  Other than that, it just kinda works.

Sound great. If you have something in place, please share the code! Do
new applications you %run reuse the reactor?

>  Of course, I believe this is part of the new / better / different
>  IPython1 design.

Yes, but we are not opposed to this in IPython0 either. The ground
rule is that as opposed to breaking stuff, we can add stuff.

>  Since IPython0 is gonna hang around we need to decide whether to work
>  deep inside to address this issue.  I previously posted a workaround to

Depends how deep inside you need to go. If it needs a lot of effort
(10+ hours), then the change itself may be too big for IPython0...

One factor is also how fast you want the thing to be in the hands of
the end users.

>  So, on this issue, we need a strategy.  I certainly appreciate continued
>  support for IPython0, but given the limited resources I wonder how much
>  effort should be put toward fixing the various GUI loops.

This is something I've been pondering as well, I've been thinking of a
simpler approach to handle these. One idea has been introducing a
magic command, say, %goqt4 that would register IPython with an already
existing Qt4 application - as opposed to the current approach of
constructing a QApplication of our own. Alternatively, we could
monkeypatch QApplication so that when it is created, we do our own
stuff for it and return (which is similar to how we handle mainloops
now). I haven't really looked deep into this since I tend not to use
these much.

>  As it stands, Qt4 is currently broken with IPython0 running pylab.  The
>  decision to expend effort needs to be based on the development plan /
>  schedule.  This is something I have no insight into as there is no
>  chatter I have access to.

You are talking about pylab_import_all option where it gets all the
names? This can be fixed easily. Just give the details.

>  > Have you considered putting up a bzr branch on launchpad for this
>  > stuff? Darren has been most active regarding Qt4, and we could  use
>  > more hands on this.
>
>  Love to... but this further emphasizes my point.  I have no idea whats
>  going on WRT development of the various flavors of IPython.  I have a
>  feeling I'm not the only one without the necessary visibility.

Just branch stable-dev branch and play around, if you need something
usable soon. IPython1 is still on "planning" stage regarding how to
run GUI mainloops in IPython core, as far as I understand.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'