From ellisonbg.net at gmail.com  Tue Apr  1 00:21:32 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 31 Mar 2008 22:21:32 -0600
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
Message-ID: <6ce0ac130803312121m55686e42u22f977685505e13@mail.gmail.com>

>  Just curious: what *benefits* do we obtain from using twisted 8.0?
>  It's nice that today, all of ipython1's depenedencies are satisfied
>  out of the box on current linux distros.  But even the
>  not-yet-released ubuntu has twisted 8, they are still on 2.5:
>
>  http://packages.ubuntu.com/hardy/python-twisted-core
>
>  I'm not fundamentally opposed to requiring 8.0 if we actually need it,
>  but otherwise I'd prefer to find a way (if possible, I haven't looked
>  at the code) to work with both 2.5 and 8.0. I hope the twisted devs
>  didn't make so many backwards incompatible changes as to make that
>  impossible...

Good question.  Here is my take on Twisted 8.0:

1. It is easy_installable so it will be _much_ easier for people to
get the deps for ipython1.

2. blockingCallFromThread (which we use all over the place) is in
Twisted 8,0.  Currently we include a copy of it in ipython1 :(

3.  twisted.web2.  This is the real kicker.  We include a copy of web2
in ipython1 (an svn copy as of last Jan.).  the problem is that we
can't update our web2 version as the latest web2 only works with
Twisted trunk or 8.0.  Because web2 is still changing often, I would
like to be able to follow more recent versions - which does require us
to use 8.0.

4.  8.0 had _lots_ of bug fixes.

There are other minor things, but these are the bigs ones that I think
are most relevant to us.

Brian


>  Cheers,
>
>  f
>


From barrywark at gmail.com  Tue Apr  1 19:11:52 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 1 Apr 2008 16:11:52 -0700
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
	<cd7634ce0803311818n21d9b738t873a39ca1dea497a@mail.gmail.com>
	<db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
Message-ID: <cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>

On Mon, Mar 31, 2008 at 6:48 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Mar 31, 2008 at 6:18 PM, Barry Wark <barrywark at gmail.com> wrote:
>  > Being installable via easy_install is a huge win (really a
>  >  requirement) on OS X 10.5.
>
>  Thanks for the info, easy_install support is certainly a benefit.
>  That doesn't outweigh the cost of losing out-of-the-box installability
>  on all linuxes, I'm afraid (it's not our fault that OSX is such a mess
>  to develop for when outside of the Apple garden), so we should find
>  out what's needed to make the code run with both 2.5 and 8.0. I'm now
>  praying that they didn't make it impossible...
>
>  Brian, you know that code far better than I do.  Any ideas on how hard
>  that would be?

Just to play devil's advocate, it's not our fault that linux distros
lag behind in their packaged version of Twisted ;) There's no reason
to loose out of the box installability on OS X either... Does anyone
know what the distribution of users' OS is for ipython?

On the more practical side, why not use Python's pacakge system (i.e.
setuptools) to install Twisted (I'd guess that all linux distros that
would include ipython would also have setuptools packages)? I know
ipython1 itself is going to be setuptools-free, but using a
setuptools-compatible Twisted might allow the ipython1 installer to
install (maybe even precompiled) Twisted eggs if Twisted isn't
present. Just a thought.

Hopefully we can use either Twisted 2.5 or 8 (perhaps mirroring
twisted.internet.threads.blockingCallFromThread if its present or
supplying the ipython1 version if using Twisted 2.5).

Barry

>
>  Cheers,
>
>  f
>


From gael.varoquaux at normalesup.org  Tue Apr  1 19:26:44 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 2 Apr 2008 01:26:44 +0200
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
	<cd7634ce0803311818n21d9b738t873a39ca1dea497a@mail.gmail.com>
	<db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
	<cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>
Message-ID: <20080401232644.GG26385@phare.normalesup.org>

On Tue, Apr 01, 2008 at 04:11:52PM -0700, Barry Wark wrote:
> Just to play devil's advocate, it's not our fault that linux distros
> lag behind in their packaged version of Twisted ;)

How old is the twisted 8.0 release? I have the feeling it is only a
couple of weeks old. In this case you can't call not packaging in a
stable release lagging behind, but simply normal procedure of validating
before shipping. Do you run mission-critical servers? Do you know what it
means to have a lab stopped from working if their is a flaw on the
packages you supported on one of your servers. I can tell you, it feels
very bad. So supporting leading edge is great when you are dealing with
your own box, and you are a devlopper happy to play around, but elsewhere
more conservative decisions can also make sense.

> On the more practical side, why not use Python's pacakge system (i.e.
> setuptools) to install Twisted (I'd guess that all linux distros that
> would include ipython would also have setuptools packages)?

Because it s not Python's package system. It is a hack to work around the
fact that Python has no package system. It induces a crazy amount of side
effect and misbehaviors. Don't get me wrong, I use setuptools a lot, and
appreciate the fonctionnality they add, but I can hardly see them as a
robust solution for packaging. It is funny you should mention them, AFAIK
until this (leading edge) release, twisted itself could not be installed
using setuptools.

I am not sure if you have followed, but currently setuptools are a
burning subject. IMHO Python packaging is a burning subject, and I am
tired of loosing a ridiculous amount of time to deal with different
version of libraries. I am afraid there is no good solution. Provide
several almost good solutions is a good idea, and setuptools do figure
amongst these, but I must admit I wouldn't force people to rely on
setuptools. I bites back.

> using a setuptools-compatible Twisted might allow the ipython1
> installer to install (maybe even precompiled) Twisted eggs if Twisted
> isn't present. Just a thought.

This kind of reasonning has brought setuptools to what it is currently:
something very problematic on secure and high-reliability servers. Indeed
you seem to be suggesting that the installer will be doing some magic to
download the requirements if they are not their. Think about it, this is
both a unacceptable security hole, and something that forbids any kind of
alternate packaging (for instance for automated deployement on a
cluster).

I am just trying to warn people that setuptools is a neat toy, but not a
solution for everybody. I use it a lot on my development boxes, but never
on my servers.

My 2 cents,

Ga?l


From glenn at tarbox.org  Tue Apr  1 22:11:04 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Tue, 01 Apr 2008 19:11:04 -0700
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <20080401232644.GG26385@phare.normalesup.org>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
	<cd7634ce0803311818n21d9b738t873a39ca1dea497a@mail.gmail.com>
	<db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
	<cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>
	<20080401232644.GG26385@phare.normalesup.org>
Message-ID: <1207102264.6425.141.camel@ghtmyth.hq.tarbox.org>

I don't fully understand all the issues with setuptools and the variants
other than there is a substantial debate.  I've seen threads and IRC
traffic on this on the twisted channels and elsewhere so I know there
are issues.

However, I've been running trunk Twisted for a while...  8.0 did bring a
number of fixes but the rather dramatic jump in numbering is almost
entirely about changing the version numbering scheme itself (the 8 is
for 2008), not a rearchitecture.

By the time code makes it to the trunk on Twisted, its pretty solid.
I've had no trouble and given the number of tests and buildbots (I host
4), I'd be surprised if we found significant issues.

On linux the installation is trivial and solid... can't speak to the
other platforms.

-glenn


On Wed, 2008-04-02 at 01:26 +0200, Gael Varoquaux wrote:
> On Tue, Apr 01, 2008 at 04:11:52PM -0700, Barry Wark wrote:
> > Just to play devil's advocate, it's not our fault that linux distros
> > lag behind in their packaged version of Twisted ;)
> 
> How old is the twisted 8.0 release? I have the feeling it is only a
> couple of weeks old. In this case you can't call not packaging in a
> stable release lagging behind, but simply normal procedure of validating
> before shipping. Do you run mission-critical servers? Do you know what it
> means to have a lab stopped from working if their is a flaw on the
> packages you supported on one of your servers. I can tell you, it feels
> very bad. So supporting leading edge is great when you are dealing with
> your own box, and you are a devlopper happy to play around, but elsewhere
> more conservative decisions can also make sense.
> 
> > On the more practical side, why not use Python's pacakge system (i.e.
> > setuptools) to install Twisted (I'd guess that all linux distros that
> > would include ipython would also have setuptools packages)?
> 
> Because it s not Python's package system. It is a hack to work around the
> fact that Python has no package system. It induces a crazy amount of side
> effect and misbehaviors. Don't get me wrong, I use setuptools a lot, and
> appreciate the fonctionnality they add, but I can hardly see them as a
> robust solution for packaging. It is funny you should mention them, AFAIK
> until this (leading edge) release, twisted itself could not be installed
> using setuptools.
> 
> I am not sure if you have followed, but currently setuptools are a
> burning subject. IMHO Python packaging is a burning subject, and I am
> tired of loosing a ridiculous amount of time to deal with different
> version of libraries. I am afraid there is no good solution. Provide
> several almost good solutions is a good idea, and setuptools do figure
> amongst these, but I must admit I wouldn't force people to rely on
> setuptools. I bites back.
> 
> > using a setuptools-compatible Twisted might allow the ipython1
> > installer to install (maybe even precompiled) Twisted eggs if Twisted
> > isn't present. Just a thought.
> 
> This kind of reasonning has brought setuptools to what it is currently:
> something very problematic on secure and high-reliability servers. Indeed
> you seem to be suggesting that the installer will be doing some magic to
> download the requirements if they are not their. Think about it, this is
> both a unacceptable security hole, and something that forbids any kind of
> alternate packaging (for instance for automated deployement on a
> cluster).
> 
> I am just trying to warn people that setuptools is a neat toy, but not a
> solution for everybody. I use it a lot on my development boxes, but never
> on my servers.
> 
> My 2 cents,
> 
> Ga?l
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
-- 
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




From barrywark at gmail.com  Tue Apr  1 22:55:07 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 1 Apr 2008 19:55:07 -0700
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <1207102264.6425.141.camel@ghtmyth.hq.tarbox.org>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
	<cd7634ce0803311818n21d9b738t873a39ca1dea497a@mail.gmail.com>
	<db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
	<cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>
	<20080401232644.GG26385@phare.normalesup.org>
	<1207102264.6425.141.camel@ghtmyth.hq.tarbox.org>
Message-ID: <cd7634ce0804011955h616c6ed0u7af8026d6f56905e@mail.gmail.com>

Same on OS X. Installation is easy (via setuptools or distutils). If I
find time in the next day or two, I'll make a twisted8 branch of
ipython1-dev and will try to get things working. Brian, shoot me a
note if you're going to do the same; I'm sure your efforts will be
more efficient than mine.

barry

On Tue, Apr 1, 2008 at 7:11 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> I don't fully understand all the issues with setuptools and the variants
>  other than there is a substantial debate.  I've seen threads and IRC
>  traffic on this on the twisted channels and elsewhere so I know there
>  are issues.
>
>  However, I've been running trunk Twisted for a while...  8.0 did bring a
>  number of fixes but the rather dramatic jump in numbering is almost
>  entirely about changing the version numbering scheme itself (the 8 is
>  for 2008), not a rearchitecture.
>
>  By the time code makes it to the trunk on Twisted, its pretty solid.
>  I've had no trouble and given the number of tests and buildbots (I host
>  4), I'd be surprised if we found significant issues.
>
>  On linux the installation is trivial and solid... can't speak to the
>  other platforms.
>
>  -glenn
>
>
>
>
>  On Wed, 2008-04-02 at 01:26 +0200, Gael Varoquaux wrote:
>  > On Tue, Apr 01, 2008 at 04:11:52PM -0700, Barry Wark wrote:
>  > > Just to play devil's advocate, it's not our fault that linux distros
>  > > lag behind in their packaged version of Twisted ;)
>  >
>  > How old is the twisted 8.0 release? I have the feeling it is only a
>  > couple of weeks old. In this case you can't call not packaging in a
>  > stable release lagging behind, but simply normal procedure of validating
>  > before shipping. Do you run mission-critical servers? Do you know what it
>  > means to have a lab stopped from working if their is a flaw on the
>  > packages you supported on one of your servers. I can tell you, it feels
>  > very bad. So supporting leading edge is great when you are dealing with
>  > your own box, and you are a devlopper happy to play around, but elsewhere
>  > more conservative decisions can also make sense.
>  >
>  > > On the more practical side, why not use Python's pacakge system (i.e.
>  > > setuptools) to install Twisted (I'd guess that all linux distros that
>  > > would include ipython would also have setuptools packages)?
>  >
>  > Because it s not Python's package system. It is a hack to work around the
>  > fact that Python has no package system. It induces a crazy amount of side
>  > effect and misbehaviors. Don't get me wrong, I use setuptools a lot, and
>  > appreciate the fonctionnality they add, but I can hardly see them as a
>  > robust solution for packaging. It is funny you should mention them, AFAIK
>  > until this (leading edge) release, twisted itself could not be installed
>  > using setuptools.
>  >
>  > I am not sure if you have followed, but currently setuptools are a
>  > burning subject. IMHO Python packaging is a burning subject, and I am
>  > tired of loosing a ridiculous amount of time to deal with different
>  > version of libraries. I am afraid there is no good solution. Provide
>  > several almost good solutions is a good idea, and setuptools do figure
>  > amongst these, but I must admit I wouldn't force people to rely on
>  > setuptools. I bites back.
>  >
>  > > using a setuptools-compatible Twisted might allow the ipython1
>  > > installer to install (maybe even precompiled) Twisted eggs if Twisted
>  > > isn't present. Just a thought.
>  >
>  > This kind of reasonning has brought setuptools to what it is currently:
>  > something very problematic on secure and high-reliability servers. Indeed
>  > you seem to be suggesting that the installer will be doing some magic to
>  > download the requirements if they are not their. Think about it, this is
>  > both a unacceptable security hole, and something that forbids any kind of
>  > alternate packaging (for instance for automated deployement on a
>  > cluster).
>  >
>  > I am just trying to warn people that setuptools is a neat toy, but not a
>  > solution for everybody. I use it a lot on my development boxes, but never
>  > on my servers.
>  >
>  > My 2 cents,
>  >
>  > Ga?l
>
> > _______________________________________________
>  > IPython-dev mailing list
>  > IPython-dev at scipy.org
>  > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>  --
>
> 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
>


From ellisonbg.net at gmail.com  Wed Apr  2 00:53:08 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 1 Apr 2008 22:53:08 -0600
Subject: [IPython-dev] Twisted 8...
In-Reply-To: <20080401232644.GG26385@phare.normalesup.org>
References: <1206732570.6425.9.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130803281300r65c305e8h40f70a95a3173539@mail.gmail.com>
	<db6b5ecc0803311715u3bb0593ch172222b9db25ca91@mail.gmail.com>
	<cd7634ce0803311818n21d9b738t873a39ca1dea497a@mail.gmail.com>
	<db6b5ecc0803311848o6c10ee02g96589d9a79b6a480@mail.gmail.com>
	<cd7634ce0804011611k40f2109er12dce94df028666e@mail.gmail.com>
	<20080401232644.GG26385@phare.normalesup.org>
Message-ID: <6ce0ac130804012153t17cdae35i6afa864ba65359ab@mail.gmail.com>

On Tue, Apr 1, 2008 at 5:26 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Apr 01, 2008 at 04:11:52PM -0700, Barry Wark wrote:
>  > Just to play devil's advocate, it's not our fault that linux distros
>  > lag behind in their packaged version of Twisted ;)
>
>  How old is the twisted 8.0 release? I have the feeling it is only a
>  couple of weeks old. In this case you can't call not packaging in a
>  stable release lagging behind, but simply normal procedure of validating
>  before shipping. Do you run mission-critical servers? Do you know what it
>  means to have a lab stopped from working if their is a flaw on the
>  packages you supported on one of your servers. I can tell you, it feels
>  very bad. So supporting leading edge is great when you are dealing with
>  your own box, and you are a devlopper happy to play around, but elsewhere
>  more conservative decisions can also make sense.

As Barry mentioned, the Twisted team is very conservative about making
changes to Twisted.  They are essentially completely test driven.
Because of this, Twisted 8.0 should make it into the the linux distros
soon enough.

>
>  > On the more practical side, why not use Python's pacakge system (i.e.
>  > setuptools) to install Twisted (I'd guess that all linux distros that
>  > would include ipython would also have setuptools packages)?
>
>  Because it s not Python's package system. It is a hack to work around the
>  fact that Python has no package system. It induces a crazy amount of side
>  effect and misbehaviors. Don't get me wrong, I use setuptools a lot, and
>  appreciate the fonctionnality they add, but I can hardly see them as a
>  robust solution for packaging. It is funny you should mention them, AFAIK
>  until this (leading edge) release, twisted itself could not be installed
>  using setuptools.

True, but the reason that Twisted 2.5.0 couldn't be installed with
setuptools is that it didn't even really use distutils :-).  That is
not a problem with setuptools, but rather some crazy decisions made
long ago by the Twisted team.  Also, it should be emphasized that
Twisted 8.0 does not _use_ setuptools for installation.  It is only
easy_installable as a tarball - just like ipython1.

>  I am not sure if you have followed, but currently setuptools are a
>  burning subject. IMHO Python packaging is a burning subject, and I am
>  tired of loosing a ridiculous amount of time to deal with different
>  version of libraries. I am afraid there is no good solution. Provide
>  several almost good solutions is a good idea, and setuptools do figure
>  amongst these, but I must admit I wouldn't force people to rely on
>  setuptools. I bites back.

I don't trust setuptools one bit myself.  It is not clear at all what
the future will bring for setuptools.  There are lots of discussions
about this going on on python-dev right now.  Time will tell.

>
>  > using a setuptools-compatible Twisted might allow the ipython1
>  > installer to install (maybe even precompiled) Twisted eggs if Twisted
>  > isn't present. Just a thought.
>
>  This kind of reasonning has brought setuptools to what it is currently:
>  something very problematic on secure and high-reliability servers. Indeed
>  you seem to be suggesting that the installer will be doing some magic to
>  download the requirements if they are not their. Think about it, this is
>  both a unacceptable security hole, and something that forbids any kind of
>  alternate packaging (for instance for automated deployement on a
>  cluster).


True, but this is perhaps getting a bit ahead of things:

1) Twisted 8.0 can be installed w/o setuptools, just like ipython1.
Linux distros will have no problem including Twisted 8.0 soon.

2) For beginning users who don't already have Twisted 8.0, being able
to easy_install Twisted 8.0 is a good thing.  Hell, that is probably
how I will install it!

Brian

>  My 2 cents,
>
>  Ga?l
>
>
> _______________________________________________
>  IPython-dev mailing list
>  IPython-dev at scipy.org
>  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Wed Apr  2 03:06:36 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 Apr 2008 10:06:36 +0300
Subject: [IPython-dev] IPython winpdb interface
In-Reply-To: <47F29277.9060003@winpdb.org>
References: <46cb515a0803231331k2330817cp4ef9cb22c3ebf5db@mail.gmail.com>
	<47E6E860.30702@winpdb.org>
	<46cb515a0803240214h61e857fdl35317b4204add12c@mail.gmail.com>
	<47e7da01.0407560a.53ef.0285@mx.google.com>
	<46cb515a0803250835g7bf64471p80bda793559c0cf8@mail.gmail.com>
	<47E939BA.4080104@winpdb.org>
	<46cb515a0803251242g44663a5ch35bdaaa3c9193799@mail.gmail.com>
	<47E9596F.7030304@winpdb.org>
	<46cb515a0803251306m5fcb412amfcf693584f893a46@mail.gmail.com>
	<47F29277.9060003@winpdb.org>
Message-ID: <46cb515a0804020006r4b40b853tde0afea1492b75bd@mail.gmail.com>

On Tue, Apr 1, 2008 at 10:52 PM, Nir <nir at winpdb.org> wrote:

> Hi Ville,
>
>  Your request is done.
>  Checkout latest SVN version of Winpdb with:
>  svn co https://winpdb.svn.sourceforge.net/svnroot/winpdb/trunk/winpdb winpdb
>
>  The %wpdb filename command should do something like:

Works like a charm, thank you :-).

It needs some trivial work on IPython side (password setting etc), but
the basic functionality is ok. I will check in a fully functional
version today.

The usage is:

import ipy_winpdb
%wpdb test.py

(does %run test.py with winpdb breakpoint)

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


From philipp.strack at gmail.com  Thu Apr  3 12:57:22 2008
From: philipp.strack at gmail.com (Philipp Strack)
Date: Thu, 3 Apr 2008 16:57:22 +0000 (UTC)
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK Interface for
	sympy
Message-ID: <loom.20080403T164616-823@post.gmane.org>

Hello,

I applied for the Google Summer of Code with the proposal to create a GTK based
GUI for the python based computer algebra system sympy. The GUI should be able
to graphically present formulas and graphs inside the document. This GUI could
be seen as a lightweight replacement for sage notebook. I want to create an
alternative to the sage webbased interface because I think GTK is a superior
technology for creating an interactive interface. A gtk interface will be much
easier to maintain and extend in the long run, because things like
autocompletion, syntaxchecking, etc can be easily implemented with a custom
gtk.TextBuffer and gtk.TextView. This GUI will follow the notebook system of
Mathematica/Maple/Mupad.

Because I want to avoid any duplication of work, I wanted to ask:

Whether someone is working on something similar? What are the points to take
care of to make it later work with ipython? 

I am thankful for every feedback on the proposal

Philipp 



From ldufrechou at marport.com  Thu Apr  3 13:18:53 2008
From: ldufrechou at marport.com (=?ISO-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Thu, 3 Apr 2008 19:18:53 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK Interface
	for sympy
In-Reply-To: <loom.20080403T164616-823@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>
Message-ID: <7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>

If you want to base your code on ipython1 check ipython1-cocoa branch from
barry wark.

bzr branch http://bazaar.launchpad.net/~ipython/ipython/ipython1-cocoa

If you want to base your code on ipython0 check stable bzr branch /gui/wx
that is an updated wx version based on the gtk example of
http://ipython.scipy.org/moin/Cookbook/EmbeddingInGTK.

bzr branch http://bazaar.launchpad.net/~ipython/ipython/stable-dev

Based on which branch you'll choose to work on I think one of us will be
willing to help you ;)

Laurent

2008/4/3, Philipp Strack <philipp.strack at gmail.com>:
>
> Hello,
>
> I applied for the Google Summer of Code with the proposal to create a GTK
> based
> GUI for the python based computer algebra system sympy. The GUI should be
> able
> to graphically present formulas and graphs inside the document. This GUI
> could
> be seen as a lightweight replacement for sage notebook. I want to create
> an
> alternative to the sage webbased interface because I think GTK is a
> superior
> technology for creating an interactive interface. A gtk interface will be
> much
> easier to maintain and extend in the long run, because things like
> autocompletion, syntaxchecking, etc can be easily implemented with a
> custom
> gtk.TextBuffer and gtk.TextView. This GUI will follow the notebook system
> of
> Mathematica/Maple/Mupad.
>
> Because I want to avoid any duplication of work, I wanted to ask:
>
> Whether someone is working on something similar? What are the points to
> take
> care of to make it later work with ipython?
>
> I am thankful for every feedback on the proposal
>
> Philipp
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Laurent Dufrechou
Hardware Engineering

Marport
16 Blv Abb? Louis LE CAM
56100 Lorient

T?l  : +33(0)635028304
Fax : +33(0)297884812
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080403/4569d803/attachment.html>

From laurent.dufrechou at gmail.com  Thu Apr  3 13:43:53 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Thu, 3 Apr 2008 19:43:53 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK Interface
	for	sympy
In-Reply-To: <loom.20080403T164616-823@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>
Message-ID: <47f5176b.0305560a.4eaa.5fba@mx.google.com>

Just in case you want to start on ipython 0.
I've replaced the gtk.textview control by scintilla one (on wx) thus to be
more multi-gui aware.
It exist a scintilla widget for gtk, so should be quite simple to have a GTK
ipython console running with low effort.

-----Message d'origine-----
De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De
la part de Philipp Strack
Envoy??: jeudi 3 avril 2008 18:57
??: ipython-dev at scipy.net
Objet?: [IPython-dev] Creating a Mathemtica notebook like GTK Interface for
sympy

Hello,

I applied for the Google Summer of Code with the proposal to create a GTK
based
GUI for the python based computer algebra system sympy. The GUI should be
able
to graphically present formulas and graphs inside the document. This GUI
could
be seen as a lightweight replacement for sage notebook. I want to create an
alternative to the sage webbased interface because I think GTK is a superior
technology for creating an interactive interface. A gtk interface will be
much
easier to maintain and extend in the long run, because things like
autocompletion, syntaxchecking, etc can be easily implemented with a custom
gtk.TextBuffer and gtk.TextView. This GUI will follow the notebook system of
Mathematica/Maple/Mupad.

Because I want to avoid any duplication of work, I wanted to ask:

Whether someone is working on something similar? What are the points to take
care of to make it later work with ipython? 

I am thankful for every feedback on the proposal

Philipp 

_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From philipp.strack at gmail.com  Thu Apr  3 13:47:48 2008
From: philipp.strack at gmail.com (Philipp Strack)
Date: Thu, 3 Apr 2008 17:47:48 +0000 (UTC)
Subject: [IPython-dev]
	=?utf-8?q?Creating_a_Mathemtica_notebook_like_GTK_I?=
	=?utf-8?q?nterface=09for_sympy?=
References: <loom.20080403T164616-823@post.gmane.org>
	<7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>
Message-ID: <loom.20080403T173747-488@post.gmane.org>

Hello Laurent,

thank you for your fast response. 

> If you want to base your code on ipython1 check ipython1-cocoa branch from
barry wark.bzr branch
http://bazaar.launchpad.net/~ipython/ipython/ipython1-cocoaIf you want to base
your code on ipython0 check stable bzr branch /gui/wx that is an updated wx
version based on the gtk example of
http://ipython.scipy.org/moin/Cookbook/EmbeddingInGTK.bzr branch
http://bazaar.launchpad.net/~ipython/ipython/stable-devBased on which branch
you'll choose to work on I think one of us will be willing to help you ;)Laurent
> 

I am probably going to be better of with the
ipython0 branch, especially because I want to use gtk/wx. Do you know whether
there is anywork done inside ipython to visualize python objects inside the
Textview (of e.g. the gtk example)? Does something like this make sense (as it
probably breakes compatibility between the terminals)? Would such a feature have
a place inside ipython?

Thank you very much for your help


Philipp

PS: some discussion around the proposal took place at

http://groups.google.com/group/sympy/browse_thread/thread/f4a28675d34e0ee6





From ondrej at certik.cz  Thu Apr  3 13:50:21 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 3 Apr 2008 19:50:21 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK Interface
	for sympy
In-Reply-To: <loom.20080403T164616-823@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>
Message-ID: <85b5c3130804031050j5fc017a8qf32f9d36c908fadf@mail.gmail.com>

On Thu, Apr 3, 2008 at 6:57 PM, Philipp Strack <philipp.strack at gmail.com> wrote:
> Hello,
>
>  I applied for the Google Summer of Code with the proposal to create a GTK based
>  GUI for the python based computer algebra system sympy. The GUI should be able
>  to graphically present formulas and graphs inside the document. This GUI could
>  be seen as a lightweight replacement for sage notebook. I want to create an
>  alternative to the sage webbased interface because I think GTK is a superior
>  technology for creating an interactive interface. A gtk interface will be much
>  easier to maintain and extend in the long run, because things like
>  autocompletion, syntaxchecking, etc can be easily implemented with a custom
>  gtk.TextBuffer and gtk.TextView. This GUI will follow the notebook system of
>  Mathematica/Maple/Mupad.
>
>  Because I want to avoid any duplication of work, I wanted to ask:
>
>  Whether someone is working on something similar? What are the points to take
>  care of to make it later work with ipython?
>
>  I am thankful for every feedback on the proposal

There is also quite detailed discussion about this proposal here:

http://groups.google.com/group/sympy/browse_thread/thread/f4a28675d34e0ee6

And of course I'll help with it too on the sympy side.

Ondrej


From olauzanne at gmail.com  Thu Apr  3 13:57:44 2008
From: olauzanne at gmail.com (Olivier Lauzanne)
Date: Thu, 3 Apr 2008 19:57:44 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK Interface
	for sympy
In-Reply-To: <loom.20080403T164616-823@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>
Message-ID: <d3c6a3710804031057tfc52670xe3b3e98d3c161b73@mail.gmail.com>

I'm working on a gtk python shell/editor.
The idea is that you are in an editor but what you type is evaluated and
displayed on the left.

That's probably not exactly what you want. And it doesn't integrate IPython
(so not sage either).
It's not finished yet (for example you can't open a file yet, that's a
problem for an editor) but if you are insterested I can send you the source.

Olivier

2008/4/3, Philipp Strack <philipp.strack at gmail.com>:
>
> Hello,
>
> I applied for the Google Summer of Code with the proposal to create a GTK
> based
> GUI for the python based computer algebra system sympy. The GUI should be
> able
> to graphically present formulas and graphs inside the document. This GUI
> could
> be seen as a lightweight replacement for sage notebook. I want to create
> an
> alternative to the sage webbased interface because I think GTK is a
> superior
> technology for creating an interactive interface. A gtk interface will be
> much
> easier to maintain and extend in the long run, because things like
> autocompletion, syntaxchecking, etc can be easily implemented with a
> custom
> gtk.TextBuffer and gtk.TextView. This GUI will follow the notebook system
> of
> Mathematica/Maple/Mupad.
>
> Because I want to avoid any duplication of work, I wanted to ask:
>
> Whether someone is working on something similar? What are the points to
> take
> care of to make it later work with ipython?
>
> I am thankful for every feedback on the proposal
>
> Philipp
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080403/0b742364/attachment.html>

From philipp.strack at gmail.com  Thu Apr  3 14:07:27 2008
From: philipp.strack at gmail.com (Philipp Strack)
Date: Thu, 3 Apr 2008 18:07:27 +0000 (UTC)
Subject: [IPython-dev]
	=?utf-8?q?Creating_a_Mathemtica_notebook_like_GTK_I?=
	=?utf-8?q?nterface=09for_sympy?=
References: <loom.20080403T164616-823@post.gmane.org>
	<d3c6a3710804031057tfc52670xe3b3e98d3c161b73@mail.gmail.com>
Message-ID: <loom.20080403T180653-326@post.gmane.org>

Olivier Lauzanne <olauzanne <at> gmail.com> writes:

> 
> 
> I'm working on a gtk python shell/editor.The idea is that you are in an editor
but what you type is evaluated and displayed on the left.That's probably not
exactly what you want. And it doesn't integrate IPython (so not sage either).
> It's not finished yet (for example you can't open a file yet, that's a problem
for an editor) but if you are insterested I can send you the source.Olivier

That would be really nice

Thank you very much

Philipp



From gael.varoquaux at normalesup.org  Thu Apr  3 14:08:48 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 3 Apr 2008 20:08:48 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like
	GTK	Interface?for sympy
In-Reply-To: <loom.20080403T173747-488@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>
	<7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>
	<loom.20080403T173747-488@post.gmane.org>
Message-ID: <20080403180848.GH21440@phare.normalesup.org>

On Thu, Apr 03, 2008 at 05:47:48PM +0000, Philipp Strack wrote:
> Do you know whether there is anywork done inside ipython to visualize
> python objects inside the Textview (of e.g. the gtk example)? Does
> something like this make sense (as it probably breakes compatibility
> between the terminals)? Would such a feature have a place inside
> ipython?

Not directly inside ipython, I think, but we discussed passing around
objects that could have a repr_wx method, that would be called by
the wx frontend to represent them. You could have a hierachy of methods
to represent an object, with the string method < unicode method < raster
picture method < vector picture method < gui/web front-end specific
method.

This is of course currently just vapor ware, and needs more thinking.

And this could only work with ipython1. There is a embryo of wx front end
in ipython1 that you can see on:
http://bazaar.launchpad.net/~ipython/ipython/ipython1-dev/files/gael.varoquaux%40normalesup.org-20080326023356-xm3yc935ky5q3zq8?file_id=wx-20080302203151-17poomviavsf2zjj-109
). All this is not terribly advanced though, and does not make use of
Min's notebook features. Maybe you should ping Min about them, I am not
sure he is following the discussion, and he is the one who thought about
this most.

Cheers,

Ga?l


From benjaminrk at gmail.com  Thu Apr  3 15:20:57 2008
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 3 Apr 2008 12:20:57 -0700
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK
	Interface?for sympy
In-Reply-To: <20080403180848.GH21440@phare.normalesup.org>
References: <loom.20080403T164616-823@post.gmane.org>
	<7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>
	<loom.20080403T173747-488@post.gmane.org>
	<20080403180848.GH21440@phare.normalesup.org>
Message-ID: <ea108cfa0804031220t46f3f267qc7521b1d85f927d8@mail.gmail.com>

Most of the notebook stuff we have focuses on metadata management,
persistence, and collaboration using the database system.  There is a
rudimentary ajax front end to this called ipnotebook.  The notebook does not
yet have any notion of images, the only data it stores is stdin/out/err,
along with some additional metadata.

At Sage Days 8 we discussed ideas for a show() method, which would be UI and
connection dependent for what it would actually do (much of our difficulty
comes from the fact that we need to use show() on a remote engine, and have
it appear on the client).  But we have not produced any code for this.

I would recommend using our notebook stuff as the basis of your data
structure/file format, but any visualization work you do would not be
redundant (and would be super cool).

-Min RK

On Thu, Apr 3, 2008 at 11:08 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Thu, Apr 03, 2008 at 05:47:48PM +0000, Philipp Strack wrote:
> > Do you know whether there is anywork done inside ipython to visualize
> > python objects inside the Textview (of e.g. the gtk example)? Does
> > something like this make sense (as it probably breakes compatibility
> > between the terminals)? Would such a feature have a place inside
> > ipython?
>
> Not directly inside ipython, I think, but we discussed passing around
> objects that could have a repr_wx method, that would be called by
> the wx frontend to represent them. You could have a hierachy of methods
> to represent an object, with the string method < unicode method < raster
> picture method < vector picture method < gui/web front-end specific
> method.
>
> This is of course currently just vapor ware, and needs more thinking.
>
> And this could only work with ipython1. There is a embryo of wx front end
> in ipython1 that you can see on:
>
> http://bazaar.launchpad.net/~ipython/ipython/ipython1-dev/files/gael.varoquaux%40normalesup.org-20080326023356-xm3yc935ky5q3zq8?file_id=wx-20080302203151-17poomviavsf2zjj-109<http://bazaar.launchpad.net/%7Eipython/ipython/ipython1-dev/files/gael.varoquaux%40normalesup.org-20080326023356-xm3yc935ky5q3zq8?file_id=wx-20080302203151-17poomviavsf2zjj-109>
> ). All this is not terribly advanced though, and does not make use of
> Min's notebook features. Maybe you should ping Min about them, I am not
> sure he is following the discussion, and he is the one who thought about
> this most.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080403/f4ec19d2/attachment.html>

From laurent.dufrechou at gmail.com  Thu Apr  3 17:26:49 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Thu, 3 Apr 2008 23:26:49 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK
	Interface	for sympy
In-Reply-To: <loom.20080403T173747-488@post.gmane.org>
References: <loom.20080403T164616-823@post.gmane.org>	<7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>
	<loom.20080403T173747-488@post.gmane.org>
Message-ID: <47f54bab.12975e0a.75f6.33a6@mx.google.com>

>I am probably going to be better of with the
>ipython0 branch, especially because I want to use gtk/wx. 

Well, the decision (Gael, barry correct me) must be better based on what you
want to do with your ipython:
-ipython0 is currently working as a much greater python shell replacement.
-ipython1 enhance this concept + one shell that can run commands on multiple
pc at the same time.
(for distributed computing).

Ipython0 is now, Ipython1 is the really near future.

If you just want an ipython shell that is working under WX and tune it to
match your needs than choose ipython0 wx shell one.
If you want to create a wx ipython shell that supports ipython1 concept base
your work on Barry cocoa branch + some code of /gui/wx of ipython0.

By the way reinteract is cool! 
I don't know how this guy has done to mix text and pics. I have to check
this!

Do you plan to do a notebook or a multi window dev env?? (a la PIDA/Editra)

If you want to do an ide, you can also do plugins for PIDA (gtk) or Editra
(wx).
If you want to do a notebook a la reinteract you can interface it with
ipython by just adding two classes of I python0 gui I think. Wx Gui is
written with separated GUI/ipython classes. So a port to GTK can be easy.


Cheers,
Laurent





From gael.varoquaux at normalesup.org  Thu Apr  3 17:50:48 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 3 Apr 2008 23:50:48 +0200
Subject: [IPython-dev] Creating a Mathemtica notebook like GTK	Interface
	for sympy
In-Reply-To: <47f54bab.12975e0a.75f6.33a6@mx.google.com>
References: <loom.20080403T164616-823@post.gmane.org>
	<7ced318f0804031018n6e3f9aj522ab3664e6d5818@mail.gmail.com>
	<loom.20080403T173747-488@post.gmane.org>
	<47f54bab.12975e0a.75f6.33a6@mx.google.com>
Message-ID: <20080403215048.GE22709@phare.normalesup.org>

On Thu, Apr 03, 2008 at 11:26:49PM +0200, Laurent Dufrechou wrote:
> Well, the decision (Gael, barry correct me) must be better based on what you
> want to do with your ipython:
> -ipython0 is currently working as a much greater python shell replacement.
> -ipython1 enhance this concept + one shell that can run commands on multiple
> pc at the same time.
> (for distributed computing).

Well, I can hardly see how it would be possible to display results with
other tools then text using ipython0 without horrible hacks. So I would
say ipython1 is your good option.

Ipython0 is a nice text-based interactive environement: you send it
strings, it returns strings.

Ipython1 is a nice abstract of the python execution engine. It will have
more, but currently it is mainly a network-transparent execution engine,
with some code lying around it being organized.

It seems to me you want more ipython1 than ipython0, because you want
more than text, and because anyhow you will be writing your own GUI code
on top of the execution engine.

Cheers,

Ga?l


From laurent.dufrechou at gmail.com  Thu Apr  3 17:55:32 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Thu, 3 Apr 2008 23:55:32 +0200
Subject: [IPython-dev] [IPython-user] merge ipython1-twisted8?
In-Reply-To: <cd7634ce0804031449m17784801m71f0a8a0a6362ea5@mail.gmail.com>
References: <cd7634ce0804030800n70e5a74aw6aaf5c3e863de15@mail.gmail.com>	<6ce0ac130804030925m512603f7k6d797fe1ab06eda6@mail.gmail.com>
	<cd7634ce0804031449m17784801m71f0a8a0a6362ea5@mail.gmail.com>
Message-ID: <47f55266.0af6660a.02b3.fffffdd7@mx.google.com>

https://bugs.launchpad.net/ipython/ ?

-----Message d'origine-----
De?: ipython-user-bounces at scipy.org [mailto:ipython-user-bounces at scipy.org]
De la part de Barry Wark
Envoy??: jeudi 3 avril 2008 23:50
??: Brian Granger; ipython user list
Objet?: Re: [IPython-user] merge ipython1-twisted8?

On Thu, Apr 3, 2008 at 9:25 AM, Brian Granger <ellisonbg.net at gmail.com>
wrote:
> Barry,
>
>  Yes, go ahead a merge back into ipython1-dev.  But could you also add
>  a ticket on launchpad that is attached to the ipython1-dev branch
>  simply stating that someone needs to update the version of
>  twisted.web2 that is in ipython1-dev to the current twisted.web2
>  trunk?  This is an optional dependency so I am not that worried about
>  it - I just don't want us to forget it.

This is stupid (of me) but I can't figure out how to add a bug ticket
on launchpad. I don't see anything at
https://bugs.launchpad.net/~ipython/ => Overview or Bugs that looks
like a way to submit a bug... can someone who's gotten more than 4
hours of sleep today help me?

Thanks,
Barry

>
>  Thanks for doing this!!
>
>  Brian
>
>
>
>  On Thu, Apr 3, 2008 at 9:00 AM, Barry Wark <barrywark at gmail.com> wrote:
>  > Does anyone object to merging ipython1-twisted8 back into
>  >  ipython1-dev? The only changes made are to alllow twisted 8 in
>  >  setupext and to delegate blockingCallFromThread to
>  >  twisted.internet.threads if ipython1 is running under twisted8 (it
>  >  still uses the current ipython1.kernel.twistedutils version if running
>  >  under twisted 2.5). I've moved to Twisted 8 on OS X (for the reasons
>  >  laid out in the previous thread on Twisted 8) and it would make
>  >  development a lot easier if we could merge these changes back into
>  >  ipython1-dev.
>  >
>  >  Of course, we should keep the ipython1-twisted8 branch around to deal
>  >  with the twisted.web2 issues that Brian pointed out.
>  >
>  >  barry
>  >  _______________________________________________
>  >  IPython-user mailing list
>  >  IPython-user at scipy.org
>  >  http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>  >
>
_______________________________________________
IPython-user mailing list
IPython-user at scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-user



From ellisonbg.net at gmail.com  Wed Apr  9 18:12:46 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 9 Apr 2008 16:12:46 -0600
Subject: [IPython-dev] State of twisted.web2 in ipython1
Message-ID: <6ce0ac130804091512y289e8be8m81d0b82c7851d63b@mail.gmail.com>

Hello all,

Up until now, we have been using twisted.web2 in ipython1 anytime we
needed to speak http.  Twisted.web2 was meant to be a replacement for
twisted.web.  But, that never happened, so the twisted team has
decided to phase out web2 and merge things back into web.  This means
two things for us:

1) Any new code in ipython1 that needs http support should use web (it
is in the latest twisted 8 release).

2) We will be removing the private version of web2 that we have been
shipping in ipython1.  This is because it no longer works with the
latest twisted release.

3) Code in ipython1 that uses web2 (mostly the notebook frontend) will
need to be ported to web eventually.  This code is not stable anyways
so I don't think this will be a big deal.

Here is the wiki page the twisted dev team has put up on the issue:

http://twistedmatrix.com/trac/wiki/TwistedWebPlan

Cheers,

Brian


From glenn at tarbox.org  Fri Apr 11 02:48:43 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Thu, 10 Apr 2008 23:48:43 -0700
Subject: [IPython-dev] Ipython1 architecture...
Message-ID: <1207896523.6343.47.camel@ghtmyth.hq.tarbox.org>

I'm starting to dig through the Ipython1 code... first thoughts are
there's been some serious thinking done here and I'm impressed.  I have
a lot of ideas driven by past-life experiences but tempered by
recent-life reality and am interested in beginning a dialog on very high
level architectural approaches.

In particular, as I'm sure is very clear to all, its very important that
we keep things as orthogonal as possible.  For example, I'm very
interested in the general needs of parallel computing but also require
elements of more conventional peer-to-peer and client-server
architecture.  From what I see, there shouldn't be any problems in that
regard.

I'm guessing that there are principles relating to non-generic resources
(e.g. live data sources or heterogeneous compute resources) which might
need to be addressed... this might be a simple matter of labeling
convention and a couplea data structures... but some discussion might be
fruitful.

But, the first thing I came across in digging through the code was
reference to threads on the client side.  My concern is basically that
virtually all the code I write avoids threads.  Threads are fine, of
course, but are often the single biggest source of difficulty in a
project for reasons I don't need to go into.

So, I'm interested in how and why threading is used in the client side
of Ipython1.  Is it simply to provide support for non-blocking gui
activity (like using -q4thread on the ipython command line) or is there
some other reason.

Given twisted, I'd posit that its not really necessary to use threads to
support non-blocking command line behavior or anything else on the
client.  The reactor (or select in general) can get around this... but
might require a rewrite of pyreadline which is planned but would take
time... which is why the threading is used...  

I'd probably go farther and say that threading might really only have a
proper place in the architecture for compute bound problems.  Given that
this is a parallel computing activity, that would make sense, but it
would really need to be thought through (and it looks like it might very
have been very carefully thought through).  Fortunately, twisted
provides very nice integration between the "main" thread and compute
threads, so I'm sure that all is well... but...

On the client side, it appears as though the reactor itself is spawned
in a thread.  Given that my gui code will be entirely reactor driven,
I'm probably fine... but how is the thread coordination planned?  From
previous posts its clear that the use of the new twisted blocking thread
stuff is heavily used (can't recall the proper names right now).  Again,
great... but it would be good to know what the intent is and, more
importantly, if I'm gonna get bit.

>From a more researchy / advanced / cool stuff perspective, I'd be
interested in any thinking thats been done WRT coroutines and the wild
stuff that can go on in that space.  Erlang (and I'm no Erlang expert)
has a very thorough architecture which provides all kinds of fanciness
including the persisting / migration of tasklets and levels of
architectural constructs answering questions I haven't yet asked (not
unlike twisted).  There's been some sniffing around by the stackless
folks to see what the right approach to nailing stackless and twisted
might be.  I see some of the concepts proposed for Ipython1 potentially
fitting nicely with things like tasklet migration.  Of course, there are
greenlets etc.

and its on the above that orthogonality need be maintained.

I could digress into domain specific nastiness... but will spare the
larger group... I guess that I hope for some increased radiation on the
Ipython1 front.

-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 



From ellisonbg.net at gmail.com  Fri Apr 11 13:23:46 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 11 Apr 2008 11:23:46 -0600
Subject: [IPython-dev] Ipython1 architecture...
In-Reply-To: <1207896523.6343.47.camel@ghtmyth.hq.tarbox.org>
References: <1207896523.6343.47.camel@ghtmyth.hq.tarbox.org>
Message-ID: <6ce0ac130804111023v51693f3dm4a39b33399ea400b@mail.gmail.com>

> I'm starting to dig through the Ipython1 code... first thoughts are
>  there's been some serious thinking done here and I'm impressed.  I have
>  a lot of ideas driven by past-life experiences but tempered by
>  recent-life reality and am interested in beginning a dialog on very high
>  level architectural approaches.

Great!

>  In particular, as I'm sure is very clear to all, its very important that
>  we keep things as orthogonal as possible.  For example, I'm very
>  interested in the general needs of parallel computing but also require
>  elements of more conventional peer-to-peer and client-server
>  architecture.  From what I see, there shouldn't be any problems in that
>  regard.

Do you mean that the parallel computing stuff is or should be
orthogonal to p2p/client/server stuff?

>  I'm guessing that there are principles relating to non-generic resources
>  (e.g. live data sources or heterogeneous compute resources) which might
>  need to be addressed... this might be a simple matter of labeling
>  convention and a couplea data structures... but some discussion might be
>  fruitful.
>
>  But, the first thing I came across in digging through the code was
>  reference to threads on the client side.  My concern is basically that
>  virtually all the code I write avoids threads.  Threads are fine, of
>  course, but are often the single biggest source of difficulty in a
>  project for reasons I don't need to go into.
>
>  So, I'm interested in how and why threading is used in the client side
>  of Ipython1.  Is it simply to provide support for non-blocking gui
>  activity (like using -q4thread on the ipython command line) or is there
>  some other reason.

Ah yes, glad you asked.  From my perspective, threads are used in two
broad ways:

1) As a model of parallelism/concurrency.  From this perspective,
threads are a way of handling concurrency in a shared memory context.
I personally think that threads are _not_ a good solution in this
arena.  They are simply too low level and difficult to get right.

2) As an implementation details for building other models of
parallelism/concurrency.  For example, Erlang uses an actor based,
shared nothing, message passing approach to concurreny.  But,
underneath the hood Erlang uses threads to implement their runtime
system.  I am all for this type of usage of threads.

In my mind, our usage of threads in the ipython1 falls into category
2).  We are not advocating that users know or care about threads.
But, we do need them in our implementation.  Here is why:

Long ago, when we first started ipython1, we did not use Twisted.  In
fact, we used plain old blocking sockets for our client.  The reason
is that we have always wanted an API that your average scientists
could understand.  And in our experience (we are scientists),
scientists do not think in terms of event loops or deferreds.  They
think in very blocking terms.  Thus, we have always felt like our
design goals require a blocking (possibly polling) user-facing
interface.

Eventually, we discovered Twisted and wanted to use Twisted for our
client networking code.  But, we have a particularly odd set of
constraints:

1) We need our client code to run on normal python/ipython sessions
that re not event driven.

2) We want to use Twisted.

3) We need to have a truly blocking interface.

So, we asked on the Twisted lists, "how can we block on a deferred?"
There was much laughter and blanket statements like "you don't want to
do that" and "you can't do that."  In spite of those statements we
knew that in fact we did want to do that.  So we spent time playing
around with various approaches.  The end of these explorations was
this conclusion:

If you only have one thread, it is true, "you can't block on a
deferred."  But also began to see that if there are multiple threads
around, you could do it.  Then came along blockingCallFromThread, that
does exactly that:  it allows blocking on a deferred in another
thread.  Another option is coroutines, and we haven't explored that
yet.  Coroutines are attractive, but only if they don't require a
custom python version (like stackless).

>  Given twisted, I'd posit that its not really necessary to use threads to
>  support non-blocking command line behavior or anything else on the
>  client.  The reactor (or select in general) can get around this... but
>  might require a rewrite of pyreadline which is planned but would take
>  time... which is why the threading is used...

Ironically, writing non-blocking interfaces is relatively easy using
threads or twisted.  The challenge is putting a blocking layer on top
of a non-blocking one.  I should mention that we do have two types of
clients:

1) asynclient:  these clients don't use threads.  Rather they use
twisted and return deferreds.  These are very new and most people
don't know about them.  I really like them.

2) client: these are a thin wrapper around the asynclient clients that
use blockingCallFromThread to block.

>  I'd probably go farther and say that threading might really only have a
>  proper place in the architecture for compute bound problems.  Given that
>  this is a parallel computing activity, that would make sense, but it
>  would really need to be thought through (and it looks like it might very
>  have been very carefully thought through).  Fortunately, twisted
>  provides very nice integration between the "main" thread and compute
>  threads, so I'm sure that all is well... but...

I still think threads are useful in implementing higher level
concurrency constructs - even though I agree with you that i don't
think they are a good solution many other things.

One thing that is really nice about twisted is that it does play well
with threads.  Our entire model is really message based (shared
nothing) and if python didn't have the GIL, we could do some very cool
single process things.

>  On the client side, it appears as though the reactor itself is spawned
>  in a thread.  Given that my gui code will be entirely reactor driven,
>  I'm probably fine... but how is the thread coordination planned?  From
>  previous posts its clear that the use of the new twisted blocking thread
>  stuff is heavily used (can't recall the proper names right now).  Again,
>  great... but it would be good to know what the intent is and, more
>  importantly, if I'm gonna get bit.

The interaction between the twisted reactors thread and GUI threads is
something we do need to think more about.  We would love help when we
get around to that.  We need to make sure that people don't get bit
because they choose to use our stuff.

>  >From a more researchy / advanced / cool stuff perspective, I'd be
>  interested in any thinking thats been done WRT coroutines and the wild
>  stuff that can go on in that space.  Erlang (and I'm no Erlang expert)
>  has a very thorough architecture which provides all kinds of fanciness
>  including the persisting / migration of tasklets and levels of
>  architectural constructs answering questions I haven't yet asked (not
>  unlike twisted).  There's been some sniffing around by the stackless
>  folks to see what the right approach to nailing stackless and twisted
>  might be.  I see some of the concepts proposed for Ipython1 potentially
>  fitting nicely with things like tasklet migration.  Of course, there are
>  greenlets etc.

Coroutines:  I would love to see a demonstration of using coroutines
and twisted, but using stackless or another custom python version is
not an option.  Another option is greenlet and corotwine:

http://codespeak.net/py/dist/greenlet.html
https://launchpad.net/corotwine/

These run with the standard Cpython.  I haven't played with them, but
would love it if someone wanted to scope this out and and report back.

Erlang:  I _really_ like Erlang.  I have been spending some of my free
time messing with Erlang and as far as I am concerned it is the best
language for concurrent/distributed programming.  What do I mean by
this.  It is what I would like Twisted to be.  Twisted is fantastic,
but I really need single process twisted apps to scale to multiple
cores.  An erlang app (at least in principle) can scale across both
threads and processes and that is really amazing.  I should also say
that I am amazed at how far Twisted goes in this direction.  It is
quite amazing!

But, I should say, I think Python is the best language for scientific,
mathematical and numerical computing.  Thus, I don't ever see a day
when I would recommend that a scientist use erlang to solve their
favorite diff-eq.

But, the combination of Erlang and Python is very interesting.  Here
is what I have been thinking.  There is a not a Twisted implementation
of the Erlang node protocol:

https://launchpad.net/twotp

I have played around with this and it is very encouraging.  More work
needs to be done, but there is a great foundation.  This lets
Python+Twisted processes talk seamlessly to Erlang nodes.  You can
imagine the possibilities.  My basic vision would be to have an
implementation of ipython1, where the controller is an erlang node,
and the engines/clients are python.  The advantages would be:

1) Better performance in terms of the networking stuff.

2) The controller is currently a huge bottleneck for us.  It simple
has to do to much.  If we used erlang, it would be much easier to
scale the controller itself to multiple cores or even multiple hosts.

3) The fault tolerance of the controller would be easier to address
(OTP,Mnesia, etc.)

Downside of using Erlang:

1) Users would have to install Erlang and Python

Bottom line:  there are lots of really interesting directions to go
in.  We just need good people with vision and ideas.

Cheers,

Brian

>  and its on the above that orthogonality need be maintained.
>
>  I could digress into domain specific nastiness... but will spare the
>  larger group... I guess that I hope for some increased radiation on the
>  Ipython1 front.
>
>  -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
>
>  _______________________________________________
>  IPython-dev mailing list
>  IPython-dev at scipy.org
>  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Fri Apr 11 18:06:09 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 11 Apr 2008 16:06:09 -0600
Subject: [IPython-dev] For transforming user input
Message-ID: <6ce0ac130804111506k6af69895pb006e3d3879c4bb9@mail.gmail.com>

Hi,

I thought this was nice:

http://pyside.blogspot.com/2008/03/ast-compilation-from-python.html

We might think about allowing prefilter to do such transformations in ipython1.

Cheers,

Brian


From glenn at tarbox.org  Fri Apr 11 18:09:25 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Fri, 11 Apr 2008 15:09:25 -0700
Subject: [IPython-dev] Ipython1 architecture...
In-Reply-To: <6ce0ac130804111023v51693f3dm4a39b33399ea400b@mail.gmail.com>
References: <1207896523.6343.47.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130804111023v51693f3dm4a39b33399ea400b@mail.gmail.com>
Message-ID: <1207951765.6343.169.camel@ghtmyth.hq.tarbox.org>

On Fri, 2008-04-11 at 11:23 -0600, Brian Granger wrote:

> >  In particular, as I'm sure is very clear to all, its very important that
> >  we keep things as orthogonal as possible.  For example, I'm very
> >  interested in the general needs of parallel computing but also require
> >  elements of more conventional peer-to-peer and client-server
> >  architecture.  From what I see, there shouldn't be any problems in that
> >  regard.
> 
> Do you mean that the parallel computing stuff is or should be
> orthogonal to p2p/client/server stuff?

I should clarify because I think my particular needs are likely
generalizable to the broader community.  In my case, I have feeds and
clients which will need to "do their thing" independent of IPython1.
However, in looking at the underlying constructs / capabilities of
IPython1, there are really nice synergies which are usable right off the
bat and provide a path to get where I want to be in the parallel
computing space

So, I see that I could suck in feeds, distribute them as I do now, but
also populate IPython1 constructs.  The next step is to invoke IPython1
computations and extend the client side capabilities incrementally...
this might mean that the cognoscenti can just go ahead and do IPython1
things as currently intended... with subsets of the capability exposed
through "pointy-clicky" gui presentation layers.

The reason I brought it up is I think this problem is probably
general... This doesn't require any major thinking at this point because
the core infrastructure is more important, but acknowledging this type
of use case and addressing it, perhaps just with examples, maybe more,
might be useful.

> >
> >  So, I'm interested in how and why threading is used in the client side
> >  of Ipython1.  Is it simply to provide support for non-blocking gui
> >  activity (like using -q4thread on the ipython command line) or is there
> >  some other reason.
> 
> Ah yes, glad you asked.  From my perspective, threads are used in two
> broad ways:
> 
> 1) As a model of parallelism/concurrency.  From this perspective,
> threads are a way of handling concurrency in a shared memory context.
> I personally think that threads are _not_ a good solution in this
> arena.  They are simply too low level and difficult to get right.

Agreed... and at multiple levels... difficult to get right by
infrastructure people... virtually impossible as a general capability
exposed to the masses.  I think threads are great in the kernel, for
example.  Fortunately, very few people are cleared for that kind of work

> 
> 2) As an implementation details for building other models of
> parallelism/concurrency.  For example, Erlang uses an actor based,
> shared nothing, message passing approach to concurreny.  But,
> underneath the hood Erlang uses threads to implement their runtime
> system.  I am all for this type of usage of threads.

Here we descend into the definition of threads...  At one level, the
abstraction is the same... but, really, all we're saying is that its
useful to maintain the stack frames... 

Most languages (Python included) provide threads which maintain state
but also "help" with scheduling, context switching etc... but without
much control.... which means synchronization of shared state and, um,
proper architecture... again, a place that most users shouldn't be
playing.

Erlang / stackless / greenlets provide more control of what a thread
does and how execution is controlled... and this is where we've gone way
way beyond what folks understand... which is unfortunate because this
could, with proper architecture, provide straightforward code writing
without too much concern about this kind of nastiness... note that I
haven't even gotten into the real nastiness which is typically exposed
inside libraries which aren't thread safe

> 
> In my mind, our usage of threads in the ipython1 falls into category
> 2).  We are not advocating that users know or care about threads.
> But, we do need them in our implementation.  Here is why:
> 
> Long ago, when we first started ipython1, we did not use Twisted.  In
> fact, we used plain old blocking sockets for our client.  The reason
> is that we have always wanted an API that your average scientists
> could understand.  And in our experience (we are scientists),
> scientists do not think in terms of event loops or deferreds.  They
> think in very blocking terms.  Thus, we have always felt like our
> design goals require a blocking (possibly polling) user-facing
> interface.

I've been using twisted for quite a while, and still get major brain
damage from time to time trying to figure out how to invert code to be
twisted compliant... so I'm very much in agreement...

> 
> Eventually, we discovered Twisted and wanted to use Twisted for our
> client networking code.  But, we have a particularly odd set of
> constraints:
> 
> 1) We need our client code to run on normal python/ipython sessions
> that re not event driven.
> 
> 2) We want to use Twisted.
> 
> 3) We need to have a truly blocking interface.

Wait... on 3)... Where is the blocking?  This is one of the things I
want to get a handle on... 

> 
> So, we asked on the Twisted lists, "how can we block on a deferred?"
> There was much laughter and blanket statements like "you don't want to
> do that" and "you can't do that."  

I love the twisted guys and think they're onto something really huge...
But, they are very very opinionated on stuff like this (more often then
not, they're also exactly right)...

However, Im looking at Kamaelia etc. and I think there's more to this
tasklet / coroutine / frame maintenance thing than they do.  I think we
can beat this one... not sure how just yet... but I think we can.

> In spite of those statements we
> knew that in fact we did want to do that.  So we spent time playing
> around with various approaches.  The end of these explorations was
> this conclusion:
> 
> If you only have one thread, it is true, "you can't block on a
> deferred."  But also began to see that if there are multiple threads
> around, you could do it.  Then came along blockingCallFromThread, that
> does exactly that:  it allows blocking on a deferred in another
> thread.  Another option is coroutines, and we haven't explored that
> yet.  Coroutines are attractive, but only if they don't require a
> custom python version (like stackless).

but, we're into dangerous territory here.  Coordinating with the "main"
thread is one thing... but then we have all the libraries that somebody
is gonna just go ahead and call.  and away we go...

> 
> >  Given twisted, I'd posit that its not really necessary to use threads to
> >  support non-blocking command line behavior or anything else on the
> >  client.  The reactor (or select in general) can get around this... but
> >  might require a rewrite of pyreadline which is planned but would take
> >  time... which is why the threading is used...
> 
> Ironically, writing non-blocking interfaces is relatively easy using
> threads or twisted.  The challenge is putting a blocking layer on top
> of a non-blocking one.  I should mention that we do have two types of
> clients:
> 
> 1) asynclient:  these clients don't use threads.  Rather they use
> twisted and return deferreds.  These are very new and most people
> don't know about them.  I really like them.
> 
> 2) client: these are a thin wrapper around the asynclient clients that
> use blockingCallFromThread to block.

ah, so I'm a bit behind on my code reading... but this is good to know.

But, I still haven't seen where the need for blocking comes in....

> 
> >  I'd probably go farther and say that threading might really only have a
> >  proper place in the architecture for compute bound problems.  Given that
> >  this is a parallel computing activity, that would make sense, but it
> >  would really need to be thought through (and it looks like it might very
> >  have been very carefully thought through).  Fortunately, twisted
> >  provides very nice integration between the "main" thread and compute
> >  threads, so I'm sure that all is well... but...
> 
> I still think threads are useful in implementing higher level
> concurrency constructs - even though I agree with you that i don't
> think they are a good solution many other things.

I also believe threads are useful... but the care required is very much
under appreciated...  There is no better way to introduce
non-reproducible, non-deterministic, non-debuggable, spurious errors
into infrastructure code than with threads (other than particle
emissions from deep space, something Sun can speak to)  

I'll make a completely unsupportable statement that in aggregate we'd
get more productivity without threads than with... of course, what a
waste that would be because done properly, threads make trivial work of
difficult problems... but too few people have enough of a clue or are
willing to spend the time to understand the issues.

> 
> One thing that is really nice about twisted is that it does play well
> with threads.  Our entire model is really message based (shared
> nothing) and if python didn't have the GIL, we could do some very cool
> single process things.

If we didn't have the GIL, Python would save 50% of mailing list traffic
and have something realistic to say WRT the multicore world we're
already in.  I have a feeling this one will get fixed... there are way
too many smart people involved and its too important not to get fixed.
Good thing we beat that cold virus too huh? :-)

> 
> >  On the client side, it appears as though the reactor itself is spawned
> >  in a thread.  Given that my gui code will be entirely reactor driven,
> >  I'm probably fine... but how is the thread coordination planned?  From
> >  previous posts its clear that the use of the new twisted blocking thread
> >  stuff is heavily used (can't recall the proper names right now).  Again,
> >  great... but it would be good to know what the intent is and, more
> >  importantly, if I'm gonna get bit.
> 
> The interaction between the twisted reactors thread and GUI threads is
> something we do need to think more about.  We would love help when we
> get around to that.  We need to make sure that people don't get bit
> because they choose to use our stuff.

So, why do we have multiple threads here?  The twisted gui reactors,
including the qtreactor I maintain, do everything in one thread.  So,
gtk and qt are single threaded already.  the wxreactor used a separate
thread because of wierd behavior with wx which may no longer be valid...
but if it is valid, we need to get wx fixed (it can't be that hard)...
but there is no reason that the gui needs to be in a different thread.

The difficulty I've run into is, most likely, with pyreadline which
blocks during scrolling... so the -q4thread (or other thread switches)
are provided... but this is probably easily fixed by adding stdin/stdout
to the reactor's main event loop and digging into pyreadline to replace
the blocking code with something asynchronous.  I don't know all the
issues here but I can't imagine this is all that hard either and avoids
all this nastiness

> Coroutines:  I would love to see a demonstration of using coroutines
> and twisted, but using stackless or another custom python version is
> not an option.  Another option is greenlet and corotwine:
> 
> http://codespeak.net/py/dist/greenlet.html
> https://launchpad.net/corotwine/
> 
> These run with the standard Cpython.  I haven't played with them, but
> would love it if someone wanted to scope this out and and report back.

Me too... and perhaps I'll do some of this... but we're into a different
client base here also.  While coroutines provide extremely useful
abstractions and "can" avoid typical threading difficulties (as well as
providing thousands vs. tens of concurrent frames) one is faced with
coroutine semantics.  

I guess the question which needs to be answered is when discussing
coroutines are we outside IPython1 and into IPythonCoroutine or
scipyCoroutine expecting that folks understand that they've crossed
over.

> 
> Erlang:  I _really_ like Erlang.  I have been spending some of my free
> time messing with Erlang and as far as I am concerned it is the best
> language for concurrent/distributed programming.  What do I mean by
> this.  It is what I would like Twisted to be.  Twisted is fantastic,
> but I really need single process twisted apps to scale to multiple
> cores.  An erlang app (at least in principle) can scale across both
> threads and processes and that is really amazing.  I should also say
> that I am amazed at how far Twisted goes in this direction.  It is
> quite amazing!

Hmmm... so, we're mixing models here and this is the kind of thing which
we need to get framed in order to make useful progress... 

coroutines are about maintaining execution state independent of
execution resources in order to provide the kind of control needed to
work properly at scale and to minimize the waste of resources not really
designed for all applications.  So, Erlang is about a lot of parallel
threads but not necessarily about compute bound processing...  Whats
nice is that state machine management is "implicitly" encoded in a
top-down manner (the stack frames are automatically managed by the
language).  Of course, Erlang also provids all the other stuff which
does lend itself to compute bound processing across cores etc...

but, what are we trying to do?  Is it MPI type work with python, or
coroutines... are we doing huge petri-nets or CFD?  There are many
similarities WRT infrastructure... but CFD cares a lot less about state
machines than massive petri-nets.

> 
> But, I should say, I think Python is the best language for scientific,
> mathematical and numerical computing.  Thus, I don't ever see a day
> when I would recommend that a scientist use erlang to solve their
> favorite diff-eq.

agreed.  Python also plays nice with lower level code so wrapping nasty
compute bound funcitonality is easy enough...  I think one of the best
examples is matplotlib (over scipy/numpy)... just in that you're most of
the way to what a lot of folks use matlab for with a much better
language

> 
> But, the combination of Erlang and Python is very interesting.  Here
> is what I have been thinking.  There is a not a Twisted implementation
> of the Erlang node protocol:
> 
> https://launchpad.net/twotp
> 
> I have played around with this and it is very encouraging.  More work
> needs to be done, but there is a great foundation.  This lets
> Python+Twisted processes talk seamlessly to Erlang nodes.  You can
> imagine the possibilities.  My basic vision would be to have an
> implementation of ipython1, where the controller is an erlang node,
> and the engines/clients are python.  The advantages would be:
> 
> 1) Better performance in terms of the networking stuff.

Hmmm... I'm with you on the first part of this... not sure that
performance is ever enhanced by python... python is about programmer
productivity and very rich semantic constructs... but i doubt you're
gonna see overall higher performance

> 
> 2) The controller is currently a huge bottleneck for us.  It simple
> has to do to much.  If we used erlang, it would be much easier to
> scale the controller itself to multiple cores or even multiple hosts.

not sure about this either.  First, I can't imagine the controller has a
huge amount to do but I say this without knowing much about it... seems
like a twisted process living on a multi-core cpu would work fine... the
other cores would provide all the support services (I/O etc) while a
single twisted process can handle coordination messaging...  If the
controller is doing a bunch of compute heavy work, I think I'd need to
know more... but I'd be surprised

> 
> 3) The fault tolerance of the controller would be easier to address
> (OTP,Mnesia, etc.)

this is true... but does it really matter... we need to determine our
domain... some of the best articles on this subject are on Google's
map-reduce infrastructure where they don't deal with this particular
issue... if a compute node goes down, no problem... the statistical
probability of the controller going down is low enough that its not
worth going through all this effort...

the above is not an option for the original intent of Erlang which is
telephone switch management... an entirely different problem.

> 
> Downside of using Erlang:
> 
> 1) Users would have to install Erlang and Python

yea, but if this is scipyCoroutines, they're already in... they either
have this kind of problem or not... if so, we're facilitators...

> 
> Bottom line:  there are lots of really interesting directions to go
> in.  We just need good people with vision and ideas.

The set intersection problem again... :-)

-glenn

> 
> Cheers,
> 
> Brian
> 
> >  and its on the above that orthogonality need be maintained.
> >
> >  I could digress into domain specific nastiness... but will spare the
> >  larger group... I guess that I hope for some increased radiation on the
> >  Ipython1 front.
> >
> >  -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
> >
> >  _______________________________________________
> >  IPython-dev mailing list
> >  IPython-dev at scipy.org
> >  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >
-- 
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




From fperez.net at gmail.com  Fri Apr 18 18:11:51 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 18 Apr 2008 15:11:51 -0700
Subject: [IPython-dev] Old 'broken terminal' bug finally fixed
Message-ID: <db6b5ecc0804181511q5b23c166o5d9f0d851986ffb1@mail.gmail.com>

Hi all,

there's a very old, *extremely* annoying bug that multiple people have
asked about (on list and in person) that is finally just fixed.  The
behavior was that at some point during a normal session, after a call
to 'foo?', your terminal would be totally messed up, with no displayed
input.  You could (blindly) type !reset to issue the system terminal
reset command, but that would only help until the next time foo? was
called, and the problem would then return.  Most of us would end up
just quitting ipython and restarting, often losing useful session
state.

The problem with this is that we never knew how to reliably reproduce
it...  Anyway, it's fixed now in current bzr:

http://bazaar.launchpad.net/~ipython/ipython/stable-dev/revision/79

I don't actually know how to trigger it, but it hit me during an
important session where I really couldn't afford to lose what I was
working on, and I managed to track it down to what I'm pretty sure is
a curses bug.  Basically curses.initscr() fails to correctly
initialize the terminal sometimes (I still don't have a clue why), and
after that it's all lost.  But it turns out that via termios one can
in fact reset the terminal state reliably , so now we unconditionally
do that.

Anyway, I figured this would be worth mentioning here, since I know
the problem is one that quite often bites people in the middle of work
sessions an it can be very, very annoying.

Cheers,

f

back to what I was busy doing, with my terminal now fully functional again... :)


From laurent.dufrechou at gmail.com  Sun Apr 20 17:52:13 2008
From: laurent.dufrechou at gmail.com (=?US-ASCII?Q?Laurent_Dufrechou?=)
Date: Sun, 20 Apr 2008 23:52:13 +0200
Subject: [IPython-dev] Pyreadline little issue.
Message-ID: <480bbb13.1438560a.6676.ffff9cf2@mx.google.com>

Hello there,

I've spent one hour or two tracking a stealthy bug.

Running a file .py that call wxipython works well under windows.

Running the same file but as .pyw (no console output) make the program
including wxipython crash.

 

I've traced the bug inside 10 files and finally I've found the bug. 

In pyreadline there is this line:

 

Pyreadline/unicode_helper.py:

 

try:

    pyreadline_codepage=sys.stdout.encoding

except AttributeError:        #This error occurs when pdb imports readline
and doctest has replaced 

                              #stdout with stdout collector

    pyreadline_codepage="ascii"   #assume ascii codepage

   

.

return text.decode(pyreadline_codepage, "replace")

 

The problem is that with myprog.py: sys.stdout.encoding = cpxxx (835 or
12??)

With myprog.pyw sys.stdout.encoding = None (!)

And the return crash.

 

Forcing 'ascii' solve the problem.

 

Must this be patched upstream in pyreadline? with:

try:

    pyreadline_codepage=sys.stdout.encoding

    if pyreadline_codepage is none:

                pyreadline_codepage="ascii"

except AttributeError:        #This error occurs when pdb imports readline
and doctest has replaced 

                              #stdout with stdout collector

    pyreadline_codepage="ascii"   #assume ascii codepage

 

or should I patch the behavior in my widget????

 

Cheers,

Laurent

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080420/d1724cb7/attachment.html>

From laurent.dufrechou at gmail.com  Sun Apr 20 18:21:14 2008
From: laurent.dufrechou at gmail.com (=?US-ASCII?Q?Laurent_Dufrechou?=)
Date: Mon, 21 Apr 2008 00:21:14 +0200
Subject: [IPython-dev] pyreadline little bug.
Message-ID: <480bc1e7.1c185e0a.1075.3c82@mx.google.com>

Whoops, seems to be corrected in latest pyreadline svn.

Sorry for the previous mail.

 

Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080421/33b4ae1f/attachment.html>

From glenn at tarbox.org  Sun Apr 20 21:35:43 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Sun, 20 Apr 2008 18:35:43 -0700
Subject: [IPython-dev] twisted process pool...
Message-ID: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>

This work might be relevant for IPython1

http://twistedmatrix.com/trac/browser/sandbox/dialtone/process_pool

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)

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




From vivainio at gmail.com  Mon Apr 21 09:14:26 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 21 Apr 2008 16:14:26 +0300
Subject: [IPython-dev] IPython0 developer blog
Message-ID: <46cb515a0804210614r5a048ffg1b50fe5b05c17178@mail.gmail.com>

Yo IPython0 core developers,

I created a now blog in wordpress for ipython0 development.
Apparently, there can be multiple people with post rights on a blog,
so please register a wordpress account and we can try it out.

I'm ok with going with another blog engine, but at least blogger
sucked when I tried it, and 360.yahoo.com is slated for deletion.

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


From vivainio at gmail.com  Mon Apr 21 09:16:37 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 21 Apr 2008 16:16:37 +0300
Subject: [IPython-dev] IPython0 developer blog
In-Reply-To: <46cb515a0804210614r5a048ffg1b50fe5b05c17178@mail.gmail.com>
References: <46cb515a0804210614r5a048ffg1b50fe5b05c17178@mail.gmail.com>
Message-ID: <46cb515a0804210616u72a1f2b7w1173994d4db0812d@mail.gmail.com>

On Mon, Apr 21, 2008 at 4:14 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Yo IPython0 core developers,
>
>  I created a now blog in wordpress for ipython0 development.
>  Apparently, there can be multiple people with post rights on a blog,
>  so please register a wordpress account and we can try it out.

Forgot to add: the address is http://ipython0.wordpress.com

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


From laurent.dufrechou at gmail.com  Mon Apr 21 11:36:40 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Mon, 21 Apr 2008 17:36:40 +0200
Subject: [IPython-dev] IPython0 developer blog
In-Reply-To: <46cb515a0804210614r5a048ffg1b50fe5b05c17178@mail.gmail.com>
References: <46cb515a0804210614r5a048ffg1b50fe5b05c17178@mail.gmail.com>
Message-ID: <480cb48f.0b38560a.4c50.44b0@mx.google.com>

Hi ville,

Good idea :)
I'm now registered as laurentdufrechou



-----Message d'origine-----
De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De
la part de Ville M. Vainio
Envoy??: lundi 21 avril 2008 15:14
??: ipython-dev Mailing list
Objet?: [IPython-dev] IPython0 developer blog

Yo IPython0 core developers,

I created a now blog in wordpress for ipython0 development.
Apparently, there can be multiple people with post rights on a blog,
so please register a wordpress account and we can try it out.

I'm ok with going with another blog engine, but at least blogger
sucked when I tried it, and 360.yahoo.com is slated for deletion.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From ias at alum.mit.edu  Wed Apr 23 22:17:36 2008
From: ias at alum.mit.edu (Igor Sylvester)
Date: Wed, 23 Apr 2008 21:17:36 -0500
Subject: [IPython-dev] Embedding IPython in wx
Message-ID: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>

Hi.
I asked in the enthought-dev mailing list about embedding an ipython shell
within a window.  This way I can break off from Windows' terrible console
and add toolbars and other widgets next to the shell.  I was told however
that this is not immediately possible because some functionality is
missing.  I'd like to implement this functionality so any first directions
and explanations of what's missing is greatly appreciated.

Thanks.

Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080423/e0d356d2/attachment.html>

From laurent.dufrechou at gmail.com  Thu Apr 24 02:52:58 2008
From: laurent.dufrechou at gmail.com (=?UTF-8?Q?Laurent_Dufr=C3=A9chou?=)
Date: Thu, 24 Apr 2008 08:52:58 +0200
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
Message-ID: <48102e4d.06e2660a.397d.50e7@mx.google.com>

Hi igor,

 

Depends on wich ipython you want a GUI:

 

-------------------------------------

If you?re looking after ipython0 check latest bzr stable branch in gui/wx, there is a demo app wxIpython, that is based on ipython_view.py

(install bazarr + ?bzr branch lp:ipython/stable?)

If you?re looking with a dev env with ipython0 console, editra : http://editra.org/ has now a plugin with ipython0 shell.(in beta currently)

 

http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin

 

There is some functionality missing:

-History reload on startup

-and check all %magic keys

-some doc J

 

But start to be quite usable.(any bug report welcomes)

 

If you want to help you?re welcome.

 

-------------------------------------

If it is Ipython1, then there is a lot of work for you too J. Barry is working on a cocoa backend, (can help to copy some parts) and there is a starting demo on wx too. Wx one need refresh. 

 

Laurent

 

De : ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De la part de Igor Sylvester
Envoy? : jeudi 24 avril 2008 04:18
? : ipython-dev at scipy.org
Objet : [IPython-dev] Embedding IPython in wx

 

Hi.
I asked in the enthought-dev mailing list about embedding an ipython shell within a window.  This way I can break off from Windows' terrible console and add toolbars and other widgets next to the shell.  I was told however that this is not immediately possible because some functionality is missing.  I'd like to implement this functionality so any first directions and explanations of what's missing is greatly appreciated.

Thanks.

Igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080424/6f1db4dd/attachment.html>

From vivainio at gmail.com  Thu Apr 24 03:07:33 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 Apr 2008 10:07:33 +0300
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
Message-ID: <46cb515a0804240007kd5ff031h8efb8bb7d9d115b5@mail.gmail.com>

On Thu, Apr 24, 2008 at 5:17 AM, Igor Sylvester <ias at alum.mit.edu> wrote:
> Hi.
> I asked in the enthought-dev mailing list about embedding an ipython shell
> within a window.  This way I can break off from Windows' terrible console
> and add toolbars and other widgets next to the shell.  I was told however

If you just want to get rid of the terrible console, try Console2.

http://sourceforge.net/projects/console/

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


From j.m.h.thomas at dl.ac.uk  Thu Apr 24 05:12:52 2008
From: j.m.h.thomas at dl.ac.uk (Jens Thomas)
Date: Thu, 24 Apr 2008 10:12:52 +0100
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <48102e4d.06e2660a.397d.50e7@mx.google.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
	<48102e4d.06e2660a.397d.50e7@mx.google.com>
Message-ID: <48104F14.6000101@dl.ac.uk>

Hello,

I don't know if this will be of any help, but I thought I'd mention it 
just so that people on this list are aware of it.

I work on a GUI for chemistry (http://sourceforge.net/projects/ccp1gui/) 
and have been experimenting with ipython as an interactive shell for our 
code. As we use Tkinter as our GUI toolkit, I took the very helpful code 
for GTK from http://ipython.scipy.org/moin/Cookbook/EmbeddingInGTK and 
translated it to Tk. You can find the code in the "ipython" directory if 
you check out the code from CVS on sourceforge.

You might find this useful as I think Tkinter is still the 'default' GUI 
for Python and so generally pretty easy to install on all platforms - 
even if it is getting rather long in the tooth... ;-)

Do get back to me if you have any questions.

Best wishes,

Jens


Laurent Dufr?chou wrote:
>
> Hi igor,
>
>  
>
> Depends on wich ipython you want a GUI:
>
>  
>
> -------------------------------------
>
> If you?re looking after ipython0 check latest bzr stable branch in 
> gui/wx, there is a demo app wxIpython, that is based on ipython_view.py
>
> (install bazarr + ?*bzr branch lp:ipython/stable?)*
>
> If you?re looking with a dev env with ipython0 console, editra : 
> http://editra.org/ has now a plugin with ipython0 shell.(in beta 
> currently)
>
>  
>
> http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin
>
>  
>
> There is some functionality missing:
>
> -History reload on startup
>
> -and check all %magic keys
>
> -some doc J
>
>  
>
> But start to be quite usable.(any bug report welcomes)
>
>  
>
> If you want to help you?re welcome.
>
>  
>
> -------------------------------------
>
> If it is Ipython1, then there is a lot of work for you too J. Barry is 
> working on a cocoa backend, (can help to copy some parts) and there is 
> a starting demo on wx too. Wx one need refresh.
>
>  
>
> Laurent
>
>  
>
> *De :* ipython-dev-bounces at scipy.org 
> [mailto:ipython-dev-bounces at scipy.org] *De la part de* Igor Sylvester
> *Envoy? :* jeudi 24 avril 2008 04:18
> *? :* ipython-dev at scipy.org
> *Objet :* [IPython-dev] Embedding IPython in wx
>
>  
>
> Hi.
> I asked in the enthought-dev mailing list about embedding an ipython 
> shell within a window.  This way I can break off from Windows' 
> terrible console and add toolbars and other widgets next to the 
> shell.  I was told however that this is not immediately possible 
> because some functionality is missing.  I'd like to implement this 
> functionality so any first directions and explanations of what's 
> missing is greatly appreciated.
>
> Thanks.
>
> Igor
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>   


-- 
===================================================================
Jens Thomas,                email:  j.m.h.thomas at dl.ac.uk
STFC Daresbury Lab,         tel:    +44-1925-603849
Warrington,                 fax:    +44-1925-603634
WA4 4AD,  UK.               http:   http://www.cse.scitech.ac.uk
===================================================================



From ias at alum.mit.edu  Thu Apr 24 09:45:41 2008
From: ias at alum.mit.edu (Igor Sylvester)
Date: Thu, 24 Apr 2008 08:45:41 -0500
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <48102318.1c365e0a.10d4.ffffc02b@mx.google.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>
	<48102318.1c365e0a.10d4.ffffc02b@mx.google.com>
Message-ID: <b3c85b560804240645t71dee070m75f14ae65ab84ac2@mail.gmail.com>

Hi Laurent.

Thank you for your help.

I actually want to embed an ipython shell inside a wx application.  I don't
need a dev env because I use emacs/command line for that :)    The
IPythonShellPlugin<http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin>for
editra looks really cool.  Would you happen to know if editra uses the
control available from the ipython stable ipython_view.py?

Thanks!

-Igor

On Thu, Apr 24, 2008 at 1:05 AM, Laurent Dufr?chou <
laurent.dufrechou at gmail.com> wrote:

>  Hi igor,
>
>
>
> Depends on wich ipython you want a GUI:
>
>
>
> -------------------------------------
>
> If you're looking after ipython0 check latest bzr stable branch in gui/wx,
> there is a demo app wxIpython, that is based on ipython_view.py
>
> (install bazarr + "*bzr branch lp:ipython/stable")*
>
> If you're looking with a dev env with ipython0 console, editra :
> http://editra.org/ has now a plugin with ipython0 shell.(in beta
> currently)
>
>
>
> http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin
>
>
>
> There is some functionality missing:
>
> -History reload on startup
>
> -and check all %magic keys
>
> -some doc J
>
>
>
> But start to be quite usable.(any bug report welcomes)
>
>
>
> If you want to help you're welcome.
>
>
>
> -------------------------------------
>
> If it is Ipython1, then there is a lot of work for you too J. Barry is
> working on a cocoa backend, (can help to copy some parts) and there is a
> starting demo on wx too. Wx one need refresh.
>
>
>
> Laurent
>
>
>
> *De :* ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org]
> *De la part de* Igor Sylvester
> *Envoy? :* jeudi 24 avril 2008 04:18
> *? :* ipython-dev at scipy.org
> *Objet :* [IPython-dev] Embedding IPython in wx
>
>
>
> Hi.
> I asked in the enthought-dev mailing list about embedding an ipython shell
> within a window.  This way I can break off from Windows' terrible console
> and add toolbars and other widgets next to the shell.  I was told however
> that this is not immediately possible because some functionality is
> missing.  I'd like to implement this functionality so any first directions
> and explanations of what's missing is greatly appreciated.
>
> Thanks.
>
> Igor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080424/e1c62066/attachment.html>

From laurent.dufrechou at gmail.com  Thu Apr 24 10:12:18 2008
From: laurent.dufrechou at gmail.com (=?UTF-8?Q?Laurent_Dufr=C3=A9chou?=)
Date: Thu, 24 Apr 2008 16:12:18 +0200
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <b3c85b560804240645t71dee070m75f14ae65ab84ac2@mail.gmail.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>	
	<48102318.1c365e0a.10d4.ffffc02b@mx.google.com>
	<b3c85b560804240645t71dee070m75f14ae65ab84ac2@mail.gmail.com>
Message-ID: <48109546.1d255e0a.03e6.5338@mx.google.com>

Yep sure J, it synced with ipython trunk.

To know how to use it check wxPython.py in /gui/wx that is the demo app.

If you turn into trouble fell free to ask. I need bug reports ;)

To make it works don?t forget you will need ipython AND pyreadline.

 

De : igorsyl at gmail.com [mailto:igorsyl at gmail.com] De la part de Igor Sylvester
Envoy? : jeudi 24 avril 2008 15:46
? : Laurent Dufr?chou; ipython-dev
Objet : Re: [IPython-dev] Embedding IPython in wx

 

Hi Laurent.

Thank you for your help.

I actually want to embed an ipython shell inside a wx application.  I don't need a dev env because I use emacs/command line for that :)    The IPythonShellPlugin <http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin>  for editra looks really cool.  Would you happen to know if editra uses the control available from the ipython stable ipython_view.py?

Thanks!

-Igor

On Thu, Apr 24, 2008 at 1:05 AM, Laurent Dufr?chou <laurent.dufrechou at gmail.com> wrote:

Hi igor,

 

Depends on wich ipython you want a GUI:

 

-------------------------------------

If you're looking after ipython0 check latest bzr stable branch in gui/wx, there is a demo app wxIpython, that is based on ipython_view.py

(install bazarr + "bzr branch lp:ipython/stable")

If you're looking with a dev env with ipython0 console, editra : http://editra.org/ has now a plugin with ipython0 shell.(in beta currently)

 

http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin

 

There is some functionality missing:

-History reload on startup

-and check all %magic keys

-some doc J

 

But start to be quite usable.(any bug report welcomes)

 

If you want to help you're welcome.

 

-------------------------------------

If it is Ipython1, then there is a lot of work for you too J. Barry is working on a cocoa backend, (can help to copy some parts) and there is a starting demo on wx too. Wx one need refresh. 

 

Laurent

 

De : ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De la part de Igor Sylvester
Envoy? : jeudi 24 avril 2008 04:18
? : ipython-dev at scipy.org
Objet : [IPython-dev] Embedding IPython in wx

 

Hi.
I asked in the enthought-dev mailing list about embedding an ipython shell within a window.  This way I can break off from Windows' terrible console and add toolbars and other widgets next to the shell.  I was told however that this is not immediately possible because some functionality is missing.  I'd like to implement this functionality so any first directions and explanations of what's missing is greatly appreciated.

Thanks.

Igor

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080424/15b16057/attachment.html>

From laurent.dufrechou at gmail.com  Thu Apr 24 10:39:08 2008
From: laurent.dufrechou at gmail.com (=?UTF-8?Q?Laurent_Dufr=C3=A9chou?=)
Date: Thu, 24 Apr 2008 16:39:08 +0200
Subject: [IPython-dev] Embedding IPython in wx
In-Reply-To: <b3c85b560804240718h7fccf860j9c227c15199cd9d0@mail.gmail.com>
References: <b3c85b560804231917n1c9c3f45xa321780834f92ed6@mail.gmail.com>	
	<48102318.1c365e0a.10d4.ffffc02b@mx.google.com>
	<b3c85b560804240718h7fccf860j9c227c15199cd9d0@mail.gmail.com>
Message-ID: <48109b91.08b6660a.30e8.5a53@mx.google.com>

Is any missing functionality only in the files within the demo directory?
What do you mean? If it is about missing functionalities here are the missing one:

 

Easy:

?History is not reloaded at startup? it is the next item in my todo list.

?%magic keys are not well tested.

If you find some that don?t works, make a report J

%cpaste as been deactivated ?cause it is a bit complicated to interface with it without doing ugly things, so I preferred to implement multiline copy/paste that what is doing cpaste (more or less)

I haven?t tried a lot other funcs.

? WxPython demo app save perspective, view widget option when they are closed ala wxdemo AUI example.

 

Medium:

?More option dialog:

-          One to choose colors for the color scheme

-          Other options I?m not aware of for the moment?

?Watch widget: A wx.panel that receive update on watched value via for example each time a command is executed:

A=1

print A

%watch A

 

Medium hard:

?Live Help widget: A wx.panel that receive the result of ??? command each time a key is pressed and display it in a fancy way (hoooot feature !)

 

Tricky:

?alt+C or ctrl+c to break while doing:

While(1):

                Print ?ok?

Can freeze the app (hard to solve) (multithreading lock issue with keyboard interrupt , not a good couple of things?)

 

Any other idea welcome.

 

De : igorsyl at gmail.com [mailto:igorsyl at gmail.com] De la part de Igor Sylvester
Envoy? : jeudi 24 avril 2008 16:19
? : Laurent Dufr?chou
Objet : Re: [IPython-dev] Embedding IPython in wx

 

I just tried the wxIPython demo and it is freaking awesome!!!  As I use it more, I can contribute patches.  Is any missing functionality only in the files within the demo directory?

Thanks!!!
-Igor

On Thu, Apr 24, 2008 at 1:05 AM, Laurent Dufr?chou <laurent.dufrechou at gmail.com> wrote:

Hi igor,

 

Depends on wich ipython you want a GUI:

 

-------------------------------------

If you're looking after ipython0 check latest bzr stable branch in gui/wx, there is a demo app wxIpython, that is based on ipython_view.py

(install bazarr + "bzr branch lp:ipython/stable")

If you're looking with a dev env with ipython0 console, editra : http://editra.org/ has now a plugin with ipython0 shell.(in beta currently)

 

http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin

 

There is some functionality missing:

-History reload on startup

-and check all %magic keys

-some doc J

 

But start to be quite usable.(any bug report welcomes)

 

If you want to help you're welcome.

 

-------------------------------------

If it is Ipython1, then there is a lot of work for you too J. Barry is working on a cocoa backend, (can help to copy some parts) and there is a starting demo on wx too. Wx one need refresh. 

 

Laurent

 

De : ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De la part de Igor Sylvester
Envoy? : jeudi 24 avril 2008 04:18
? : ipython-dev at scipy.org
Objet : [IPython-dev] Embedding IPython in wx

 

Hi.
I asked in the enthought-dev mailing list about embedding an ipython shell within a window.  This way I can break off from Windows' terrible console and add toolbars and other widgets next to the shell.  I was told however that this is not immediately possible because some functionality is missing.  I'd like to implement this functionality so any first directions and explanations of what's missing is greatly appreciated.

Thanks.

Igor

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080424/037f16c1/attachment.html>

From ias at alum.mit.edu  Fri Apr 25 01:31:45 2008
From: ias at alum.mit.edu (Igor Sylvester)
Date: Fri, 25 Apr 2008 00:31:45 -0500
Subject: [IPython-dev] wxIPython and wx
Message-ID: <b3c85b560804242231g4d3f1361t820fe546e1881d7@mail.gmail.com>

Hi Laurent,

I was playing with wxIPython today and I wasn't able to spawn new wx objects
within the shell.

I ran:

>>> import wxIPython
>>> wxIPython.MyApp().MainLoop()

Then, in the wxIPython shell, I typed:

>>> import wx
>>> wx.Frame(None).Show()

And the python process died with the following.

Warning! Hook 'show_in_pager' is not one of ['editor', 'fix_error_editor',
'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook',
'generate_prompt', 'generate_output_prompt']
Warning! Hook 'shell_hook' is not one of ['editor', 'fix_error_editor',
'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook',
'generate_prompt', 'generate_output_prompt']
^[[A^[[BXlib: unexpected async reply (sequence 0x31e8)!
Xlib: sequence lost (0x131e8 > 0x4bd8) in reply type 0x0!
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadImplementation (server does not implement operation)'.
  (Details: serial 12776 error_code 17 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I am about to look at the editra source to see how you embed an ipython
shell.  But, I'd appreciate if you have any insight into this.
Specifically, are you able to reproduce this error, or is it a bug in my X?

Thanks.

Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080425/6d598033/attachment.html>

From laurent.dufrechou at gmail.com  Fri Apr 25 03:47:47 2008
From: laurent.dufrechou at gmail.com (=?UTF-8?Q?Laurent_Dufr=C3=A9chou?=)
Date: Fri, 25 Apr 2008 09:47:47 +0200
Subject: [IPython-dev] wxIPython and wx
In-Reply-To: <b3c85b560804242231g4d3f1361t820fe546e1881d7@mail.gmail.com>
References: <b3c85b560804242231g4d3f1361t820fe546e1881d7@mail.gmail.com>
Message-ID: <48118ca7.1358560a.0983.5e96@mx.google.com>

Hi igor,

 

Ok I see you want to instanciate wx object from within the shell.

I haven?t tested GUI direct call within the widget.

As the widget is wx one, there should not have error and could be possible. I had a discussion with a guy previously on this mailing because he wanted to play with wx/qt/etc with ipython widget.

The main problem is that in that case he needed in fact that ipython shell run in it?s own process separated from wx one.

 

In your case, do you want to only interact with YOUR wx loop (that is the wx ipython widget loop)?

 

If yes, should be possible. I will take a look at your bug tonight (in ~12hours).

Sure it can work, and moreover should be really interesting to do that J!

I suspect that the ipython instance (not the widget) behind the scene has not the same globals/locals scope as your root app.

So it can directly interact with wx loop. (perhaps, I?m saying dumb things).

I think we have to pass globals/locals to the ipython shell.(there is parameters for this, but haven?t tried it this well)

Will try tonight.

 

By the way on which linux are you working? (version needed too, to reproduce the bug)

On windows, doing that just spawn a window, and kill it instantaneously?

 

Regards,

Laurent

 

De : igorsyl at gmail.com [mailto:igorsyl at gmail.com] De la part de Igor Sylvester
Envoy? : vendredi 25 avril 2008 07:32
? : Laurent Dufr?chou; ipython-dev
Objet : wxIPython and wx

 

Hi Laurent,

I was playing with wxIPython today and I wasn't able to spawn new wx objects within the shell.

I ran:

>>> import wxIPython
>>> wxIPython.MyApp().MainLoop()

Then, in the wxIPython shell, I typed:

>>> import wx
>>> wx.Frame(None).Show()

And the python process died with the following.

Warning! Hook 'show_in_pager' is not one of ['editor', 'fix_error_editor', 'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook', 'generate_prompt', 'generate_output_prompt']
Warning! Hook 'shell_hook' is not one of ['editor', 'fix_error_editor', 'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook', 'generate_prompt', 'generate_output_prompt']
^[[A^[[BXlib: unexpected async reply (sequence 0x31e8)!
Xlib: sequence lost (0x131e8 > 0x4bd8) in reply type 0x0!
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadImplementation (server does not implement operation)'.
  (Details: serial 12776 error_code 17 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I am about to look at the editra source to see how you embed an ipython shell.  But, I'd appreciate if you have any insight into this.  Specifically, are you able to reproduce this error, or is it a bug in my X?

Thanks.

Igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080425/94f0dd39/attachment.html>

From vivainio at gmail.com  Fri Apr 25 12:21:15 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 25 Apr 2008 19:21:15 +0300
Subject: [IPython-dev] ipython0 blog now visible in planet python!
Message-ID: <46cb515a0804250921r459da55k5b7cc5b7336956a0@mail.gmail.com>

Planet python is now publishing the ipython0 blog:

http://planet.python.org/

The posts appear there with some delay. This should give us a bit
wider distribution than the ipython user mailing list... :-)

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


From laurent.dufrechou at gmail.com  Sat Apr 26 11:09:58 2008
From: laurent.dufrechou at gmail.com (=?utf-8?Q?Laurent_Dufr=C3=A9chou?=)
Date: Sat, 26 Apr 2008 17:09:58 +0200
Subject: [IPython-dev] wxIPython and wx
In-Reply-To: <b3c85b560804242231g4d3f1361t820fe546e1881d7@mail.gmail.com>
References: <b3c85b560804242231g4d3f1361t820fe546e1881d7@mail.gmail.com>
Message-ID: <481345cd.0437560a.58bb.fffff7f5@mx.google.com>

Ok Igor I?ve checked a little what you were saying.

 

>>> import wxIPython
>>> wxIPython.MyApp().MainLoop()



Where is this done? In your script called by python myscript.py?


Then, in the wxIPython shell, I typed:

>>> import wx
>>> wx.Frame(None).Show()

And the python process died with the following.

Warning! Hook 'show_in_pager' is not one of ['editor', 'fix_error_editor', 'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook', 'generate_prompt', 'generate_output_prompt']
Warning! Hook 'shell_hook' is not one of ['editor', 'fix_error_editor', 'result_display', 'input_prefilter', 'shutdown_hook', 'late_startup_hook', 'generate_prompt', 'generate_output_prompt']



Hum strange don?t have this on my ubuntu?

Did you get the last bzr revision???

 

You will need bazaar revision of ipython directory. If I remember well 'show_in_pager? was added by while so wxIPython was able to hook the pager. I think you are running wxIPython with on ?old? (not bleeding edge) version of ipython.

 

Do: 

bzr branch http://bazaar.launchpad.net/~ipython/ipython/stable-dev

 

And tell me if it is ok.

By the way what do you want to do exactly?

Embed an ipython into your wx app, or just play with ipython with other thing than classical console?

 

Cheers,

Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080426/872b5898/attachment.html>

From laurent.dufrechou at gmail.com  Sun Apr 27 13:02:19 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sun, 27 Apr 2008 19:02:19 +0200
Subject: [IPython-dev] Problem with ipython in 'develop' mode
Message-ID: <4814b1a1.09b6660a.4aee.ffff937b@mx.google.com>

I there, i'm under windows.

I've used 'develop' mode (something like setup.py . develop?)

Now each time I run ipython I get this:

 

C:\Users\ldufrechou\Desktop\EditraPlugins\IPyShell\IPython\gui\wx>ipython

Traceback (most recent call last):

  File "C:\Python25\Scripts\ipython-script.py", line 5, in <module>

    from pkg_resources import load_entry_point

  File "c:\python25\lib\site-packages\pkg_resources.py", line 2561, in
<module>

    working_set.require(__requires__)

  File "c:\python25\lib\site-packages\pkg_resources.py", line 626, in
require

    needed = self.resolve(parse_requirements(requirements))

  File "c:\python25\lib\site-packages\pkg_resources.py", line 524, in
resolve

    raise DistributionNotFound(req)  # XXX put more info here

pkg_resources.DistributionNotFound: ipython==0.8.3.bzr.r57

 

Have you ever run in such problems? I think it is relative to using bazaar
branch, but I'm a bit lost..

 

Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080427/bd5b56c4/attachment.html>

From gael.varoquaux at normalesup.org  Sun Apr 27 13:03:05 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 27 Apr 2008 19:03:05 +0200
Subject: [IPython-dev] Problem with ipython in 'develop' mode
In-Reply-To: <4814b1a1.09b6660a.4aee.ffff937b@mx.google.com>
References: <4814b1a1.09b6660a.4aee.ffff937b@mx.google.com>
Message-ID: <20080427170305.GJ29247@phare.normalesup.org>

On Sun, Apr 27, 2008 at 07:02:19PM +0200, Laurent Dufrechou wrote:
>    pkg_resources.DistributionNotFound: ipython==0.8.3.bzr.r57



>    Have you ever run in such problems? I think it is relative to using
>    bazaar
>    branch, but I'm a bit lost....

This is setuptools magic. The script that you are trying to run is trying
to find a certain version of ipython, but is not finding it. Most often
the cause for this is that you are running an old script with a new
instal.

Ga?l



From laurent.dufrechou at gmail.com  Sun Apr 27 13:30:13 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Sun, 27 Apr 2008 19:30:13 +0200
Subject: [IPython-dev] Problem with ipython in 'develop' mode
In-Reply-To: <20080427170305.GJ29247@phare.normalesup.org>
References: <4814b1a1.09b6660a.4aee.ffff937b@mx.google.com>
	<20080427170305.GJ29247@phare.normalesup.org>
Message-ID: <4814b82b.05a0660a.2019.ffffa42e@mx.google.com>

Ok solved the problem with redoing:
Python eggsetup.py develop


-----Message d'origine-----
De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org] De
la part de Gael Varoquaux
Envoy??: dimanche 27 avril 2008 19:03
??: 'ipython-dev Mailing list'
Objet?: Re: [IPython-dev] Problem with ipython in 'develop' mode

On Sun, Apr 27, 2008 at 07:02:19PM +0200, Laurent Dufrechou wrote:
>    pkg_resources.DistributionNotFound: ipython==0.8.3.bzr.r57



>    Have you ever run in such problems? I think it is relative to using
>    bazaar
>    branch, but I'm a bit lost....

This is setuptools magic. The script that you are trying to run is trying
to find a certain version of ipython, but is not finding it. Most often
the cause for this is that you are running an old script with a new
instal.

Ga?l

_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From glenn at tarbox.org  Wed Apr 30 17:14:29 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Wed, 30 Apr 2008 14:14:29 -0700
Subject: [IPython-dev] Ipython0, Ipython1, Qt, and threading...
Message-ID: <1209590069.6270.72.camel@ghtmyth.hq.tarbox.org>

I didn't think I'd run into this right out of the box... But it looks
like I'm getting bit by threading issues in ipython when using Qt4...

I'm using twisted inside ipython.  Its been straightforward till now...
but am having problems when using deferreds.

Basically, I make queries to remote servers which return values later.
I'm using the twisted Qt reactor I maintain
(http://code.tarbox.org/qtreactor) and it all worked pretty well until
recently...

In the current case, the deferred gets its return information across the
network.  The callback simply populates an object in the background...
so there's no IO or anything which should be occuring visably in
ipython.  

?However, there appear to be threads running around which get unhappy.
PyQt has the unfortunate feature of just spewing error messages without
any traceback information (one of the truly bizarre and unfortunate
characteristics of PyQt and I haven't found a way to get useful
information from PyQt) so at this point I really don't know where in the
code this occurs and I get this kind of message output in the ipython
session:

QObject::killTimer: timers cannot be stopped from another thread
QObject::startTimer: timers cannot be started from another thread

what problems this is causing I'm unaware... everything seems to keep
working but this can't be good...

Since I'm running ipython with the Qt4Agg backend, I'm guessing a bunch
of Qt things get spawned by default... and I'm guessing that something
must be looking at IO... or there wouldn't be anything outside my code
which would otherwise see any events causing the above errors to be
generated

So, I'm kinda wondering whats happening.

Knowing that Ipython1 is using twisted, I figured I would try some of
that code to initiate whatever default reactor is used...
Unfortunately, same issue with other much nastier side effects... 

In particular, some of my other code generates a plot in a callback.
Using my Qt reactor, no problem... but using the Ipython1 reactor, the
application crashes because its very unhappy when gui activity occurs in
a non-gui thread... which appears to be the case with the default
reactor.

-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