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

Fernando Perez fperez.net at gmail.com
Tue Mar 18 19:26:00 EDT 2008


Hi Glenn,

On Tue, Mar 18, 2008 at 2:05 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 :-)

I take full responsibility for poor communications recently.  In my
defense, I've been traveling a lot and coding, and most of this work
will directly or indirectly benefit ipython:

- we had a sprint on sage/scipy at Enthought's headquarters in Austin
in early March where several ipython devs also worked a lot, with
great progress made by Brian and Min on a number of issues.   We were
also joined by Ondrej Certik (of sympy fame) and Stefan van der Walt
(from numpy/scipy).

- I returned to Berkeley where I've been working with Stefan on some
prototype algorithms for an NSF grant proposal which, if funded, would
benefit ipython.  It's on mathematics and neuroscience, but the core
implementation would all be in scipy/ipython.

- We are right now in Paris holding a development meeting related to
scipy and neuroimaging in Python; this is part of my 'real job' but it
also involves ipython work and resources (I ran a demo this morning of
ipython1 and some local labs are already testing things out for their
work).

- This weekend we'll hold a mini-sprint at Gael Varoquaux's house in
Paris (from Mayavi2), to push forward on a number of key
ipython1/ipython-trunk integration issues.

So in summary, I've just been so swamped with this work that I've done
a poor job of communicating it to the rest of the team, except for all
the face-to-face conversations we've had.

Perhaps this will  convince me to get a blog: for the first time in my
life I see the point of those things.  While I never thought anyone
would have a reason to be interested in my personal ramblings, it may
be a good way to occasionally post things that aren't exactly pure
mailing list announcements.  By aggregating the posts at a place like
http://planet.scipy.org, interested readers can follow the
appropriately tagged posts.

I'm afraid after this mini-update I'll disappear again; I need some
sleep and we have a long day ahead tomorrow.

I hope you'll forgive the incompleteness of this post, but I realize
that we need to do a better job of community building.  If you think
that a blog would be the right resource (I know Ville already has one)
to help on this front, let me know as I'd appreciate the feedback.


Cheers,

f

>
>
>  >
>  > >  More concerning is the state of Qt4.  There is a "critical" bug
>  entered
>  > >  in trac: http://projects.scipy.org/ipython/ipython/ticket/208
>  > >
>  > >  Clearly, a QCoreApplication (or QApplication) instance is
>  > >  auto-constructed due to the -q4thread switch... and since
>  calculate.py
>  > >  constructs one also, QT dumps core  (why QT decides to core-dump as
>  the
>  > >  error reporting strategy is beyond me... but thats whats going on).
>  > >
>  > >  Qt4 support is indeed broken... but unnecessarily so. I have Qt4
>  running
>  > >  with twisted in a naked ipython shell.  I simply construct my
>  qt4reactor
>  > >  and use embedded Qt4 code.  Can't pull in pylab because it renames
>  > >  packages which collide with PyQt4 (in particular, wrapping QObject
>  in a
>  > >  different module... don't get that yet).  and this is beyond the
>  issues
>  > >  associated with QSocketNotifier being invoked from a non-qt thread.
>  I'm
>  > >  sure this is straightforward but, again, I can't determine whether
>  time
>  > >  spent here is worthwhile.  Seems to me that IPython1's architecture
>  will
>  > >  make most of these problems "just go away" as its a far more
>  > >  comprehensive architecture.
>  >
>  > IPython1 does not have a magical solution for any of this, it's pretty
>  > universal stuff. The problem is still the same - gui mainloop has to
>  > be in one thread - but we have that already. Whatever you do in
>  > ipython0 regarding Qt4 will be applicable on IPython1 as well, and
>  > IPython0 isn't going away anytime soon.
>
>  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.
>
>  Of course, I believe this is part of the new / better / different
>  IPython1 design.
>
>  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
>  nail twisted to IPython0 which exploited the multithreaded IShell code.
>
>  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.
>
>  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.
>
>  and I'll say again, you're in the soup with wx.  It might work for a
>  while, but its broken and needs work.  I looked at it with the twisted
>  team but decided to just bag it and go Qt.  In that effort, it became
>  clear how to fix wx which is when I became aware of wx's previous issues
>  which may or may not still exist.  The use of threads to get around wx
>  blocking is, IMHO, a bad idea...  much better to fix wx... and if that
>  can't be done, it should be bagged or someone needs to take on that
>  project, certainly beyond my time availability.
>
>
>  >
>  > 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.
>
>  >
>  --
>
> Glenn H. Tarbox, PhD
>  glenn at tarbox.org
>
>
>
>
>
>
> _______________________________________________
>  IPython-dev mailing list
>  IPython-dev at scipy.org
>  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>



More information about the IPython-dev mailing list