From fperez.net at gmail.com  Mon Sep  1 20:28:02 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 1 Sep 2008 17:28:02 -0700
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <388792597149196992@unknownmsgid>
References: <388792597149196992@unknownmsgid>
Message-ID: <db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>

Hey,

On Mon, Sep 1, 2008 at 9:51 AM,  <noreply at launchpad.net> wrote:
> ------------------------------------------------------------
> revno: 1129
> committer: Ville M. Vainio <vivainio at gmail.com>
> branch nick: ipython
> timestamp: Mon 2008-09-01 19:49:39 +0300
> message:
>  added ipy_gmail extension
> added:
>  IPython/Extensions/ipy_gmail.py
>
> === added file 'IPython/Extensions/ipy_gmail.py'
> --- a/IPython/Extensions/ipy_gmail.py   1970-01-01 00:00:00 +0000
> +++ b/IPython/Extensions/ipy_gmail.py   2008-09-01 16:49:39 +0000
> @@ -0,0 +1,133 @@
> +""" Gmail interface for IPython
> +
> +This extension requires libgmail (http://libgmail.sourceforge.net/,
> +apt-gettable on ubuntu), and is mostly provided for entertainment purposes .

I'm  not necessarily opposed to this, but I think you should consider
that now we're all trying to work together with code review, tests,
etc.  This code is GPL, for 'entertainment purposes', was committed
ritght before we wrap up a release cycle and doesn't have a single
test in it.

Don't you think it's worth at least running the code by everyone else
to see if it's a good idea to have it in?  We ultimately all have to
maintain the codebase together, so we all  have a stake in this.

Cheers,

f


From vivainio at gmail.com  Tue Sep  2 02:33:50 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 09:33:50 +0300
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
Message-ID: <46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>

On Tue, Sep 2, 2008 at 3:28 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> Don't you think it's worth at least running the code by everyone else
> to see if it's a good idea to have it in?  We ultimately all have to
> maintain the codebase together, so we all  have a stake in this.


Again, note that this is in extension code which implicitly holds no promise
of actually being useful. Notably, extension code can change how it behaves
quite randomly, and can fall out of maintenance as easily. This is why we
can take whole extensions as external contributions in quite a relaxed
fashion (and this is a good thing).

Thin of the "Extensions" directory as 'contrib' directory.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080902/df16107e/attachment.html>

From stefan at sun.ac.za  Tue Sep  2 02:53:23 2008
From: stefan at sun.ac.za (Stefan Van der Walt)
Date: Tue, 2 Sep 2008 08:53:23 +0200
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
Message-ID: <87669CF1-CA08-41B8-BF15-13F6E7060695@sun.ac.za>

On 02 Sep 2008, at 08:33 , Ville M. Vainio wrote:
> Again, note that this is in extension code which implicitly holds no  
> promise of actually being useful. Notably, extension code can change  
> how it behaves quite randomly, and can fall out of maintenance as  
> easily. This is why we can take whole extensions as external  
> contributions in quite a relaxed fashion (and this is a good thing).
>
> Thin of the "Extensions" directory as 'contrib' directory.

It's so annoying when projects ship files in "contrib" that are  
incompatible with the latest release -- kind of makes you wonder  
whether these people are serious about delivering good quality  
software.  By investing a tiny amount of time in unit testing and peer  
reviewing code, the problem can mostly be eradicated.  Seems worth it  
to me, a thousand times over.

Cheers
St?fan



From vivainio at gmail.com  Tue Sep  2 03:23:10 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 10:23:10 +0300
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <87669CF1-CA08-41B8-BF15-13F6E7060695@sun.ac.za>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
	<87669CF1-CA08-41B8-BF15-13F6E7060695@sun.ac.za>
Message-ID: <46cb515a0809020023s615ddd92i1fd5bb5b97e5b5a0@mail.gmail.com>

On Tue, Sep 2, 2008 at 9:53 AM, Stefan Van der Walt <stefan at sun.ac.za>wrote:

>
> It's so annoying when projects ship files in "contrib" that are
> incompatible with the latest release -- kind of makes you wonder
> whether these people are serious about delivering good quality
> software.  By investing a tiny amount of time in unit testing and peer
> reviewing code, the problem can mostly be eradicated.  Seems worth it
> to me, a thousand times over.


Actually, the mechanics here is that 'contrib' stuff should just use the
public api's of ipython. Sometimes, some extension may go through _ip.IP
(which slates them for breakage), but it makes sense to provide a
low-overhead way to contribute additional features.

One alternative would be to move all these extensions to separate package -
kind of like package archive of emacs. Post-0.9, I think we should seriously
consider adding a magic function that downloads and installs the latest
version of ipython extensions package - this would also decouple the
extension release cycle from ipython release cycle. Of course the problem is
mostly psychological - code in 'contrib' will mostly be invisible to
everybody that doesn't go out to 1) find it and 2) enable it.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080902/01d1f88a/attachment.html>

From fperez.net at gmail.com  Tue Sep  2 03:26:53 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 2 Sep 2008 00:26:53 -0700
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
Message-ID: <db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>

On Mon, Sep 1, 2008 at 11:33 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Tue, Sep 2, 2008 at 3:28 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>> Don't you think it's worth at least running the code by everyone else
>> to see if it's a good idea to have it in?  We ultimately all have to
>> maintain the codebase together, so we all  have a stake in this.
>
> Again, note that this is in extension code which implicitly holds no promise
> of actually being useful. Notably, extension code can change how it behaves
> quite randomly, and can fall out of maintenance as easily. This is why we
> can take whole extensions as external contributions in quite a relaxed
> fashion (and this is a good thing).

No.

Recently, Vivian's extensions were reviewed, she added docs for them,
etc.  Once  that code goes in, we ultimately all have to answer for
it, or clean up the breakage later.

It is simply not acceptable for the project to start carrying in its
core code that's randomly broken at any given time.  If you have test
snippets of that sort, that's what the cookbook is for: a publicly
contributed area where neat ideas can go, but which haven't been
vetted.

My (long-term) goal is  for ipython to reach 100% test coverage. We're
nowhere near that,  but the only way we'll ever get there is by
ensuring that new code is always tested.

Please either add tests and docs for this or revert the commit and put
it in the cookbook.

All of us are developing in the open, keeping our branches ready for
public review and accepting feedback from others.  I hope you'll be
willing to play by the same rules as everyone else.

Cheers,

f


From vivainio at gmail.com  Tue Sep  2 05:44:05 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 12:44:05 +0300
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
	<db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>
Message-ID: <46cb515a0809020244w75125339wf1a85c1cf02cdc0@mail.gmail.com>

On Tue, Sep 2, 2008 at 10:26 AM, Fernando Perez <fperez.net at gmail.com>wrote:

>
> Recently, Vivian's extensions were reviewed, she added docs for them,
> etc.  Once  that code goes in, we ultimately all have to answer for
> it, or clean up the breakage later.


I would split the maintenance responsibility to 2 parts

- The parts that actually are in the core
- The parts that are in ipy_* files, under Extensions.


>
>
> It is simply not acceptable for the project to start carrying in its
> core code that's randomly broken at any given time.  If you have test
> snippets of that sort, that's what the cookbook is for: a publicly
> contributed area where neat ideas can go, but which haven't been
> vetted.


I still believe it's a matter af agreement what is in the core - the
original idea is that the stuff in ipy_* is *not* in the core, but clearly
it's not obvious enough so the physical location should be changed.

I don't mind removing the recently added extensions (ipy_miscapps and
ipy_gmail) from the Extensions folder though - their idea is not to be in
the core in any way. They will be available post-0.9, after running an
"%get_extensions" magic command or somesuch (exact implementation to be
decided). Maybe it'll just be "easy_install ipython_extensions", which would
kinda make sense.


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080902/8d909f22/attachment.html>

From vivainio at gmail.com  Tue Sep  2 05:45:35 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 12:45:35 +0300
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <46cb515a0809020244w75125339wf1a85c1cf02cdc0@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
	<db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>
	<46cb515a0809020244w75125339wf1a85c1cf02cdc0@mail.gmail.com>
Message-ID: <46cb515a0809020245g42c3498fn8619b2cfc24e0f49@mail.gmail.com>

On Tue, Sep 2, 2008 at 12:44 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> I still believe it's a matter af agreement what is in the core - the
> original idea is that the stuff in ipy_* is *not* in the core, but clearly
> it's not obvious enough so the physical location should be changed.
>

One additional note - it can also make the licensing a bit clearer. If
extensions are shipped separately, we can guarantee that everyhing in
ipython core distribution is bsd-clear.


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080902/a11e44e9/attachment.html>

From edreamleo at gmail.com  Tue Sep  2 10:28:50 2008
From: edreamleo at gmail.com (Edward K. Ream)
Date: Tue, 2 Sep 2008 09:28:50 -0500
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <46cb515a0809020245g42c3498fn8619b2cfc24e0f49@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
	<db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>
	<46cb515a0809020244w75125339wf1a85c1cf02cdc0@mail.gmail.com>
	<46cb515a0809020245g42c3498fn8619b2cfc24e0f49@mail.gmail.com>
Message-ID: <ffb592890809020728t2030ffbby3002a4bc303f4232@mail.gmail.com>

On Tue, Sep 2, 2008 at 4:45 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

>> I still believe it's a matter of agreement what is in the core - the
>> original idea is that the stuff in ipy_* is *not* in the core, but clearly
>> it's not obvious enough so the physical location should be changed.

Similar issues arise in Leo.  Imo, it was a mistake not to require
unit tests for all "official" Leo plugins.  In practice, it seems the
time to require unit tests is when the plugin/extension is first
offered.  People never seem to add unit tests later. Alas, the cost of
not having unit tests just keeps going up...

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------


From vivainio at gmail.com  Tue Sep  2 11:21:57 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 18:21:57 +0300
Subject: [IPython-dev] [Branch ~ipython-dev/ipython/trunk] Rev 1129:
	added ipy_gmail extension
In-Reply-To: <ffb592890809020728t2030ffbby3002a4bc303f4232@mail.gmail.com>
References: <388792597149196992@unknownmsgid>
	<db6b5ecc0809011728r59559bf1sde25d900df9b33a8@mail.gmail.com>
	<46cb515a0809012333q409917b0iece4fcd404ba4e3e@mail.gmail.com>
	<db6b5ecc0809020026vad3026fl75dc748048f8bd84@mail.gmail.com>
	<46cb515a0809020244w75125339wf1a85c1cf02cdc0@mail.gmail.com>
	<46cb515a0809020245g42c3498fn8619b2cfc24e0f49@mail.gmail.com>
	<ffb592890809020728t2030ffbby3002a4bc303f4232@mail.gmail.com>
Message-ID: <46cb515a0809020821k6ae8fa41l5f857d4faee4406f@mail.gmail.com>

On Tue, Sep 2, 2008 at 5:28 PM, Edward K. Ream <edreamleo at gmail.com> wrote:

> On Tue, Sep 2, 2008 at 4:45 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>>> I still believe it's a matter of agreement what is in the core - the
>>> original idea is that the stuff in ipy_* is *not* in the core, but clearly
>>> it's not obvious enough so the physical location should be changed.
>
> Similar issues arise in Leo.  Imo, it was a mistake not to require
> unit tests for all "official" Leo plugins.  In practice, it seems the
> time to require unit tests is when the plugin/extension is first
> offered.  People never seem to add unit tests later. Alas, the cost of
> not having unit tests just keeps going up...

I think unit tests alone don't cut it in a system like IPython or leo.

Consider the situation where code is refactored so that interfaces
between components change, for example. Unit tests may or may not
break, but the usability does change significantly.

For large pieces of software, automatic functional tests are the
solution. With IPython, these can be implemented easily with
_ip.runlines. It may not give a perfect reflection of the behaviour in
interactive use (readline problems, for example), but still provide
better feedback on breakage than low-level unit tests.

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


From vivainio at gmail.com  Tue Sep  2 11:30:36 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 18:30:36 +0300
Subject: [IPython-dev] Handy launchpad trick
Message-ID: <46cb515a0809020830g611d68bbocf365dacda3f977e@mail.gmail.com>

Here's how to deal with those launchpad push url's that were broken a
while back:

Typically, the push url on launchpad page will look like this::

 bzr push lp:~villemvainio/ipython/ipython-extensions

Obviously, you can't execute that command (at least not with the bzr
version I'm using). What you wants looks like this::

 bzr push bzr+ssh://villemvainio at bazaar.launchpad.net/~villemvainio/ipython/ipython-extensions

So, here's how to do it with minimum pain:

LP = "bzr+ssh://villemvainio at bazaar.launchpad.net/"
%store LP

(adjust according to your launchpad username)

After that, you will (manually) change all the suggested push url's like this::

 bzr push lp:~villemvainio/ipython/ipython-extensions    (OLD)
 bzr push $LP~villemvainio/ipython/ipython-extensions  (NEW)

(and maybe add --remember for good measure)

Of course there may be another way to fix it, I was hoping launchpad
would have got it fixed by now.

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


From vivainio at gmail.com  Tue Sep  2 12:22:19 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 19:22:19 +0300
Subject: [IPython-dev] ipython-extensions
Message-ID: <46cb515a0809020922q23848d54t8cfd1eb4b23e85da@mail.gmail.com>

I have now created "ipython-extensions" branch on bzr, as well as the
cheeseshop package
(http://pypi.python.org/pypi/ipython-extensions/0.1). I think this
will make more sense in the long run than always bundling all the
extensions with ipython core, thus requiring users to check out full
IPython just to play with an extension. Additionally, it will decouple
the maintenance of core ipython and that of ipython extensions.

So far, there is only ipy_gmail.py and ipy_miscapps.py, but moving
forward, it should probably be the place where user-contributed
extensions (especially platform specific ones, or ones with
dependencies to nonstandard libraries, or ones with non-BSD licenses)
are added.

It can be installed by running easy_install ipython-extensions
(provided that you have setuptools).

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


From vivainio at gmail.com  Tue Sep  2 12:35:26 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 19:35:26 +0300
Subject: [IPython-dev] ipython-extensions
In-Reply-To: <46cb515a0809020922q23848d54t8cfd1eb4b23e85da@mail.gmail.com>
References: <46cb515a0809020922q23848d54t8cfd1eb4b23e85da@mail.gmail.com>
Message-ID: <46cb515a0809020935v3a41ce28x8d3f1992d63e0e10@mail.gmail.com>

On Tue, Sep 2, 2008 at 7:22 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> So far, there is only ipy_gmail.py and ipy_miscapps.py, but moving
> forward, it should probably be the place where user-contributed
> extensions (especially platform specific ones, or ones with
> dependencies to nonstandard libraries, or ones with non-BSD licenses)
> are added.

And here's a list of what I think should be in this module, as opposed
to being ipython core (for one or more of the reasons specified
above):

ipy_bzr
ipy_editors
ipy_gnuglobal
ipy_jot
ipy_leo
ipy_lookfor
ipy_p4
ipy_server
ipy_synchronize_with
ipy_vimserver
ipy_winpdb
ipy_workdir
ledit
scitedirector

Obviously, this is very late in the 0.9 cycle to do such a
reorganization, so we can consider it after 0.9.

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


From vivainio at gmail.com  Tue Sep  2 13:44:11 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 2 Sep 2008 20:44:11 +0300
Subject: [IPython-dev] Handy launchpad trick
In-Reply-To: <46cb515a0809020830g611d68bbocf365dacda3f977e@mail.gmail.com>
References: <46cb515a0809020830g611d68bbocf365dacda3f977e@mail.gmail.com>
Message-ID: <46cb515a0809021044v3bae084cha726313f5ed3fa94@mail.gmail.com>

On Tue, Sep 2, 2008 at 6:30 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

>  bzr push lp:~villemvainio/ipython/ipython-extensions
>
> Obviously, you can't execute that command (at least not with the bzr
> version I'm using). What you wants looks like this::
>
>  bzr push bzr+ssh://villemvainio at bazaar.launchpad.net/~villemvainio/ipython/ipython-extensions

Ok, this was news for me: you can use

bzr launchpad-login villemvainio

(or equivalent) beforehand, and pushing will work.

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


From gael.varoquaux at normalesup.org  Tue Sep  2 18:48:32 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Sep 2008 00:48:32 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
Message-ID: <20080902224832.GA12777@phare.normalesup.org>

On Sun, Aug 31, 2008 at 02:07:09AM +0200, Laurent Dufrechou wrote:
> So here is a bug report for you (just to keep a trace) ;) :

> In [2]: !ls

> The GUI freeze and I need to push enter to get this message: (under vista)

Darn. I can't reproduce this at all under my windows XP virtual box. Can
you check that you can reproduce the problem with the latest version of
my branch?

Cheers,

Ga?l


From laurent.dufrechou at gmail.com  Tue Sep  2 19:15:49 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Wed, 3 Sep 2008 01:15:49 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080902224832.GA12777@phare.normalesup.org>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
Message-ID: <7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>

... even worse !
Now got an exception but nothing is displayed :/
I'm under vista business.
Will try tomorrow to a fresh chekout of your branch on a friend computer.
Got a XP computer too here, so can try.
Will try tomorrow (depending on my planning :/ )


From gael.varoquaux at normalesup.org  Tue Sep  2 20:34:32 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Sep 2008 02:34:32 +0200
Subject: [IPython-dev] Frontend-sync branch updated, and test failures
Message-ID: <20080903003432.GC12777@phare.normalesup.org>

I have done a few tweaks in the frontend branch (mainly to be able to pass
in a namespace and not have it duplicated, but kept as a reference). It
would be nice if it where merged before the release. The changes are
minor.

On the other hand, I get a score of test failures with latest bzr. A
bunch of them are due to the fact that I don't have foolscap install. I
thing they should simply be skipped when foolscap is not there. Another
bunch of them look like:

======================================================================
ERROR: Doctest: IPython.strdispatch.StrDispatch
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
line 356, in runTest
    clear_globs=False)
  File
"/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
line 643, in run
    compileflags,out,clear_globs)
  File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/genutils.py", line
874, in f
    out = func(*a,**k)
  File "/usr/lib/python2.5/doctest.py", line 1361, in run
    return self.__run(test, compileflags, out)
  File "/usr/lib/python2.5/doctest.py", line 1244, in __run
    if check(example.want, got, self.optionflags):
  File
"/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
line 285, in check_output
    optionflags)
TypeError: unbound method check_output() must be called with
OutputChecker instance as first argument (got IPDoctestOutputChecker
instance instead)

I am having a hard time distinguish signal from noise in my test result.

Ga?l


From fperez.net at gmail.com  Tue Sep  2 20:41:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 2 Sep 2008 17:41:00 -0700
Subject: [IPython-dev] Frontend-sync branch updated, and test failures
In-Reply-To: <20080903003432.GC12777@phare.normalesup.org>
References: <20080903003432.GC12777@phare.normalesup.org>
Message-ID: <db6b5ecc0809021741u28b6e315u3861480a649dd194@mail.gmail.com>

On Tue, Sep 2, 2008 at 5:34 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> I have done a few tweaks in the frontend branch (mainly to be able to pass
> in a namespace and not have it duplicated, but kept as a reference). It
> would be nice if it where merged before the release. The changes are
> minor.
>
> On the other hand, I get a score of test failures with latest bzr. A
> bunch of them are due to the fact that I don't have foolscap install. I
> thing they should simply be skipped when foolscap is not there. Another
> bunch of them look like:
>
> ======================================================================
> ERROR: Doctest: IPython.strdispatch.StrDispatch
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
> line 356, in runTest
>    clear_globs=False)
>  File
> "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
> line 643, in run
>    compileflags,out,clear_globs)
>  File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/genutils.py", line
> 874, in f
>    out = func(*a,**k)
>  File "/usr/lib/python2.5/doctest.py", line 1361, in run
>    return self.__run(test, compileflags, out)
>  File "/usr/lib/python2.5/doctest.py", line 1244, in __run
>    if check(example.want, got, self.optionflags):
>  File
> "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",

Are you running the test suite via

iptest

(perhaps with -vvvs if you want lots of output)? The installed plugin
shouldn't be picked up at all, iptest loads it for you.  Just symlink
iptest from the scripts/ directory to something in your $PATH and let
us know how that goes.

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Sep  2 20:45:05 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Sep 2008 02:45:05 +0200
Subject: [IPython-dev] Frontend-sync branch updated, and test failures
In-Reply-To: <db6b5ecc0809021741u28b6e315u3861480a649dd194@mail.gmail.com>
References: <20080903003432.GC12777@phare.normalesup.org>
	<db6b5ecc0809021741u28b6e315u3861480a649dd194@mail.gmail.com>
Message-ID: <20080903004505.GD12777@phare.normalesup.org>

On Tue, Sep 02, 2008 at 05:41:00PM -0700, Fernando Perez wrote:
> Are you running the test suite via

> iptest

I wasn't (I must have managed to sleep through the discussion mentioning
this beast).

I know have:

    Ran 301 tests in 7.016s

    OK (SKIP=8)

That's better.

Ga?l


From fperez.net at gmail.com  Tue Sep  2 20:50:25 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 2 Sep 2008 17:50:25 -0700
Subject: [IPython-dev] Frontend-sync branch updated, and test failures
In-Reply-To: <20080903004505.GD12777@phare.normalesup.org>
References: <20080903003432.GC12777@phare.normalesup.org>
	<db6b5ecc0809021741u28b6e315u3861480a649dd194@mail.gmail.com>
	<20080903004505.GD12777@phare.normalesup.org>
Message-ID: <db6b5ecc0809021750o6c21bd52y647ae85012c970ec@mail.gmail.com>

On Tue, Sep 2, 2008 at 5:45 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Sep 02, 2008 at 05:41:00PM -0700, Fernando Perez wrote:
>> Are you running the test suite via
>
>> iptest
>
> I wasn't (I must have managed to sleep through the discussion mentioning
> this beast).

You must have been sleeping pretty deep, because it happened while you
were about 30cm away from me :)

> I know have:
>
>    Ran 301 tests in 7.016s
>
>    OK (SKIP=8)
>
> That's better.

Good.

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Sep  2 20:52:16 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 3 Sep 2008 02:52:16 +0200
Subject: [IPython-dev] Frontend-sync branch updated, and test failures
In-Reply-To: <db6b5ecc0809021750o6c21bd52y647ae85012c970ec@mail.gmail.com>
References: <20080903003432.GC12777@phare.normalesup.org>
	<db6b5ecc0809021741u28b6e315u3861480a649dd194@mail.gmail.com>
	<20080903004505.GD12777@phare.normalesup.org>
	<db6b5ecc0809021750o6c21bd52y647ae85012c970ec@mail.gmail.com>
Message-ID: <20080903005216.GA16442@phare.normalesup.org>

On Tue, Sep 02, 2008 at 05:50:25PM -0700, Fernando Perez wrote:
> > I wasn't (I must have managed to sleep through the discussion mentioning
> > this beast).

> You must have been sleeping pretty deep, because it happened while you
> were about 30cm away from me :)

You know me. My brain is often on power saving mode. This is my
contribution to fighting global warming.

Ga?l


From ellisonbg.net at gmail.com  Wed Sep  3 16:34:42 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 13:34:42 -0700
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
Message-ID: <6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>

> I have couple more questions to the workflow:
>
> So you publish let's say 30 little commits in your branch. Stefan
> reviews it, let's say he says the commits 15, 20 and 21 are crap and
> you should rework it. :) So will you add commits 31, 32 and 33 fixing
> the crap, or will you actually edit the commits 15, 20, 21 directly?
> Does bzr allow you to easily delete the public branch and repost your
> reworked 30 little commits?

Currently we only use an all or nothing approach to reviewing and
merging branches into trunk.  This does have the disadvantage that if
you have a branch with many different commits, merging all of them
could be held up by one or two that nee to be cleaned up.

This is a reason to make more and smaller branches, rather than fewer
larger ones (with more commits).

I guess I usually work in a way such that in a given branch all the
commits are related to each other in such a way that it wouldn't make
sense to only merge some of the them.

But, I think it is possible to do a merge of only certain commits.

Does this answer your questions?

> Because you said you merge those 30 little commits into one or a few
> commits, so people who pulled your branch will have mess in their
> repos, right?
>
> I like the direct editing workflow, i.e. I also like to commit 30
> little commits and then merge it in a few well polished patches, send
> them for a review (e.g. push them into some branch), then fix things
> couple times depending on the review and finally the commits go in the
> main trunk. And I realized that mercurial is getting in my way in this
> workflow, and we switched to git with Kirill (another sympy developer)
> and it allows me to work in the way I described very easily and also
> to push the reworked patches to the same public branch (removing the
> old stuff).

At this point, we are not working with directly with patches.  When a
branch is ready to go - public or not, it is merged in.  I am not sure
I am understanding your question now.

Brian

> Ondrej
> _______________________________________________
> 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 Sep  3 16:43:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 13:43:15 -0700
Subject: [IPython-dev] ipcontroller & ipengine
In-Reply-To: <48B2813B.80203@sarvision.nl>
References: <48B2813B.80203@sarvision.nl>
Message-ID: <6ce0ac130809031343h4a9afeebl7034c42266829ea1@mail.gmail.com>

> I'm trying ipython's parallel capabilities once again, but things have
> changed... a lot apparently, since I last tried...

Yep, that is very true.  Are you using a 0.9 beta or release candidate?

> I used to start 'ipcontroller --engine-ip 10.0.0.211' on localhost, and
> then 'ipengine -n8' on 10.0.0.211 (an 8-core machine). I could then
> connect from localhost to the controller, which connected to the
> engines at 10.0.0.211. Or I started ipcluster -n8 on 10.0.0.211, and then
> started a client connection from ipython specifying 10.0.0.211 as the
> controller-host to connect to.
> Neither works anymore.

Yep, now you have to fiddle with furl files.  While this may seem like
a pain, it is actually a huge improvement in usability.

> I know I can fiddle with furl files, but it is not convenient for me to
> have to copy a furl file each time I (re)start a cluster. I don't want
> to mess with ssh-agent either, if possible.

Furl files are persistent.  You only need to move them once and then
future controllers and engines will use those.  Let us know if this
doesn't work - it would be a bug.

> What would be the simplest way to achieve a situation where 1) the
> engines run on remotehost, 2) I can connect from kernel.client to those
> engines? Controller might run anywhere it is convenient...

1.  Start the controller somewhere.

2.  Copy ~/.ipython/ipcontroller-engine.furl to the machines where the
engine will run and ipcontroller-mec.furl and ipcontroller-tc.furl to
where the client will run.

3.  Start the engines using

ipengine --furl-file=FURL_FILE_LOCATION

Or if you just put ipcontroller-engine.furl in ~/.ipython on the
engine's host, you can leave --furl-file out.

4.  Start the client, passing to it, the furl file location.

The important point is that once you do (2), it never has to be done again!

Does that make sense?


> Btw this is the error when I try to start a controller on localhost,
> ready to listen for engines on 10.0.0.211:
>
> $  ipcontroller --engine-ip 10.0.0.211

--engine-ip is not a valid option anymore.

Let us know if this helps or if you have other questions.

Cheers,

Brian
> 2008-08-22 15:49:19+0200 [-] Log opened.
> 2008-08-22 15:49:19+0200 [-] foolscap.pb.Listener starting on 45401
> 2008-08-22 15:49:19+0200 [-] Traceback (most recent call last):
> 2008-08-22 15:49:19+0200 [-]   File "/usr/bin/ipcontroller", line 19, in
> <module>
> 2008-08-22 15:49:19+0200 [-]     ipcontroller.main()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/IPython/kernel/scripts/ipcontroller.py",
> line 363, in main
> 2008-08-22 15:49:19+0200 [-]     start_controller()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/IPython/kernel/scripts/ipcontroller.py",
> line 217, in start_controller
> 2008-08-22 15:49:19+0200 [-]     main_service.startService()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/application/service.py", line
> 260, in startService
> 2008-08-22 15:49:19+0200 [-]     service.startService()
> 2008-08-22 15:49:19+0200 [-]   File
> "build/bdist.linux-x86_64/egg/foolscap/pb.py", line 591, in startService
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/application/service.py", line
> 260, in startService
> 2008-08-22 15:49:19+0200 [-]     service.startService()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/application/internet.py", line
> 91, in startService
> 2008-08-22 15:49:19+0200 [-]     self._port = self._getPort()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/application/internet.py", line
> 116, in _getPort
> 2008-08-22 15:49:19+0200 [-]     *self.args, **self.kwargs)
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/internet/posixbase.py", line
> 328, in listenTCP
> 2008-08-22 15:49:19+0200 [-]     p.startListening()
> 2008-08-22 15:49:19+0200 [-]   File
> "/usr/lib/python2.5/site-packages/twisted/internet/tcp.py", line 739, in
> startListening
> 2008-08-22 15:49:19+0200 [-]     raise CannotListenError,
> (self.interface, self.port, le)
> 2008-08-22 15:49:19+0200 [-] twisted.internet.error.CannotListenError:
> Couldn't listen on 10.0.0.211:0: (99, 'Cannot assign requested address').
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ondrej at certik.cz  Wed Sep  3 16:59:47 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 3 Sep 2008 22:59:47 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
Message-ID: <85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>

On Wed, Sep 3, 2008 at 10:34 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I have couple more questions to the workflow:
>>
>> So you publish let's say 30 little commits in your branch. Stefan
>> reviews it, let's say he says the commits 15, 20 and 21 are crap and
>> you should rework it. :) So will you add commits 31, 32 and 33 fixing
>> the crap, or will you actually edit the commits 15, 20, 21 directly?
>> Does bzr allow you to easily delete the public branch and repost your
>> reworked 30 little commits?
>
> Currently we only use an all or nothing approach to reviewing and
> merging branches into trunk.  This does have the disadvantage that if
> you have a branch with many different commits, merging all of them
> could be held up by one or two that nee to be cleaned up.
>
> This is a reason to make more and smaller branches, rather than fewer
> larger ones (with more commits).
>
> I guess I usually work in a way such that in a given branch all the
> commits are related to each other in such a way that it wouldn't make
> sense to only merge some of the them.
>
> But, I think it is possible to do a merge of only certain commits.
>
> Does this answer your questions?

It answers a question, but not the one I asked. :) Sorry that I made
my question unclear, I'll try to ask it differently below.

>
>> Because you said you merge those 30 little commits into one or a few
>> commits, so people who pulled your branch will have mess in their
>> repos, right?
>>
>> I like the direct editing workflow, i.e. I also like to commit 30
>> little commits and then merge it in a few well polished patches, send
>> them for a review (e.g. push them into some branch), then fix things
>> couple times depending on the review and finally the commits go in the
>> main trunk. And I realized that mercurial is getting in my way in this
>> workflow, and we switched to git with Kirill (another sympy developer)
>> and it allows me to work in the way I described very easily and also
>> to push the reworked patches to the same public branch (removing the
>> old stuff).
>
> At this point, we are not working with directly with patches.  When a
> branch is ready to go - public or not, it is merged in.  I am not sure
> I am understanding your question now.

We both agree that one branch should only contain things, that are
related and it should go in as all or nothing.

Let's say you have 30 commits in the branch and let's say that it
doesn't pass the review, because it needs improving. My question is,
what will you do? Will you commit the improvement over your 30 commits
(e.g. just adding more commits to the branch, until all the code is ok
to go in), or will you try to fix some of the commits in the branch,
so that actually all of the commits individually are ok? (I know you
cannot just push there "individual commits", because they are related
with the rest.)

I don't know if I made it clear now. My question is if you try to make
each change (=each commit) ok to go in, or if you just try for each
new bunch of commits (=branch) to be ok to go in (i.e. some commits
can be crap, if they are fixed by later commits in the same branch).

Ondrej


From ellisonbg.net at gmail.com  Wed Sep  3 16:59:51 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 13:59:51 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
Message-ID: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>

Hi,

Do we have a get_ipython_dir function somehere.  I see a get_home_dir
in genutils, but not one for finding the .ipython dir on all
platforms.

Also, if this function doesn' exist, where is the equivalent logic?

Cheers,

Brian


From fperez.net at gmail.com  Wed Sep  3 17:08:07 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 14:08:07 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
Message-ID: <db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>

On Wed, Sep 3, 2008 at 1:59 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> Do we have a get_ipython_dir function somehere.  I see a get_home_dir
> in genutils, but not one for finding the .ipython dir on all
> platforms.
>
> Also, if this function doesn' exist, where is the equivalent logic?

The logic is unfortunately not encapsulated in a function, it's inline
in the old, messy ipmaker.py.  The *value* however, is available as
IP.ipythondir, where IP is the main ipython object.

This should obviously be refactored later...

Cheers,

f


From ellisonbg.net at gmail.com  Wed Sep  3 17:08:48 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 14:08:48 -0700
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
Message-ID: <6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>

> Let's say you have 30 commits in the branch and let's say that it
> doesn't pass the review, because it needs improving. My question is,
> what will you do? Will you commit the improvement over your 30 commits
> (e.g. just adding more commits to the branch, until all the code is ok
> to go in), or will you try to fix some of the commits in the branch,
> so that actually all of the commits individually are ok? (I know you
> cannot just push there "individual commits", because they are related
> with the rest.)

Ahh, now I understand.  Our approach is that you create new commits
that fix the problems in the old commits.  There are a couple of
reasons for this:

1.  Commits serve as a full record of all the code that gets written -
good and bad.  If you are always completely covering up bad code, it
an hurt you.  Let's say there is a really subtle bug in a commit and
you spend a long time tracking it down.  You put in a test case and
all seems OK.  But if you erase the original commit, there is less of
a record about the bug that may help you or others in the future.  I
think it is much better to 1) have a commit that has the bug and 2)
have another commit that fixes the bug with a full description of the
bug.

2.  Sometimes code review requires making changes to code that spans
multiple initial commits.  At this point, I think it just gets
difficult to have a development model where each individual commit is
OK by itself.  Our development style to just too non-linear and
convoluted for this to be practical.  I suppose your style might fit
this model better - don't know though.

> I don't know if I made it clear now. My question is if you try to make
> each change (=each commit) ok to go in, or if you just try for each
> new bunch of commits (=branch) to be ok to go in (i.e. some commits
> can be crap, if they are fixed by later commits in the same branch).

We have a development model that allows for the following:

crap + crap + crap + fix_crap + tests = beautiful code merged into trunk

This seems more realistic than:

beautiful_code + beautiful_code + beautiful_code + tests = beautiful_code

Maybe once I become perfect, the second would work though ;-)

Brian


> Ondrej
>


From ellisonbg.net at gmail.com  Wed Sep  3 17:13:11 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 14:13:11 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
Message-ID: <6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>

The reason that I ask is that we have get_home_dir repeated twice:

genutils.py
IPython/config/cutils.py

I want to get rid of one of these.  IPython/config/cutils.py also has
an get_ipython_dir.py, but I don't think this is the right place for
this.

Also pulling the value from IP won't work in my case because I need it
for the controller and engines, which (for now) don't have a full IP
instance.

Is this the right logic from ipmaker.py:

    # Platform-dependent suffix and directory names.  We use _ipython instead
    # of .ipython under win32 b/c there's software that breaks with .named
    # directories on that platform.
    if os.name == 'posix':
        rc_suffix = ''
        ipdir_def = '.ipython'
    else:
        rc_suffix = '.ini'
        ipdir_def = '_ipython'

    # default directory for configuration
    ipythondir_def = os.path.abspath(os.environ.get('IPYTHONDIR',
                                 os.path.join(IP.home_dir,ipdir_def)))

If so, I will make a get_ipython_dir function in genutils and remove
the cruft from config/cutils.py

Cheers,

Brian

On Wed, Sep 3, 2008 at 2:08 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Sep 3, 2008 at 1:59 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hi,
>>
>> Do we have a get_ipython_dir function somehere.  I see a get_home_dir
>> in genutils, but not one for finding the .ipython dir on all
>> platforms.
>>
>> Also, if this function doesn' exist, where is the equivalent logic?
>
> The logic is unfortunately not encapsulated in a function, it's inline
> in the old, messy ipmaker.py.  The *value* however, is available as
> IP.ipythondir, where IP is the main ipython object.
>
> This should obviously be refactored later...
>
> Cheers,
>
> f
>


From ellisonbg.net at gmail.com  Wed Sep  3 17:19:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 14:19:15 -0700
Subject: [IPython-dev] ipcluster with clusterfile
Message-ID: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com>

Hi,

Our old ipcluster script has a remote mode that can be used for
starting a cluster over ssh.  This is currently broken and I want to
either:

1.  Fix it for the 0.9 release.

2.  Remove it for the 0..9 release.

The big problem with fixing it is the management of the furl files.
Previously we didn't have security, so this wasn't an issue, but now
the controller's furl file needs to be moved to where the engines are.
 This would require additional logic in ipcluster.py.

The main issue is that the ipcluster is about to get an entirely new
implementation when Min's daemon stuff is merged in.

Thoughts?  Do we try to get this working for the 0.9 release (with a
hack, not Min's stuff), or do we remove the capability?

Cheers,

Brian


From fperez.net at gmail.com  Wed Sep  3 18:01:08 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 15:01:08 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
Message-ID: <db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>

On Wed, Sep 3, 2008 at 2:13 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> The reason that I ask is that we have get_home_dir repeated twice:
>
> genutils.py
> IPython/config/cutils.py
>
> I want to get rid of one of these.  IPython/config/cutils.py also has
> an get_ipython_dir.py, but I don't think this is the right place for
> this.
>
> Also pulling the value from IP won't work in my case because I need it
> for the controller and engines, which (for now) don't have a full IP
> instance.
>
> Is this the right logic from ipmaker.py:
>
>    # Platform-dependent suffix and directory names.  We use _ipython instead
>    # of .ipython under win32 b/c there's software that breaks with .named
>    # directories on that platform.
>    if os.name == 'posix':
>        rc_suffix = ''
>        ipdir_def = '.ipython'
>    else:
>        rc_suffix = '.ini'
>        ipdir_def = '_ipython'
>
>    # default directory for configuration
>    ipythondir_def = os.path.abspath(os.environ.get('IPYTHONDIR',
>                                 os.path.join(IP.home_dir,ipdir_def)))
>
> If so, I will make a get_ipython_dir function in genutils and remove
> the cruft from config/cutils.py

Yes.  Even if it's not ideal, having it in a function will let us clean it up.

Cheers,

f


From fperez.net at gmail.com  Wed Sep  3 18:05:02 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 15:05:02 -0700
Subject: [IPython-dev] ipcluster with clusterfile
In-Reply-To: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com>
References: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com>
Message-ID: <db6b5ecc0809031505w3f6f259buca9c5acab35e41b7@mail.gmail.com>

Howdy,

On Wed, Sep 3, 2008 at 2:19 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> Our old ipcluster script has a remote mode that can be used for
> starting a cluster over ssh.  This is currently broken and I want to
> either:
>
> 1.  Fix it for the 0.9 release.
>
> 2.  Remove it for the 0..9 release.
>
> The big problem with fixing it is the management of the furl files.
> Previously we didn't have security, so this wasn't an issue, but now
> the controller's furl file needs to be moved to where the engines are.
>  This would require additional logic in ipcluster.py.
>
> The main issue is that the ipcluster is about to get an entirely new
> implementation when Min's daemon stuff is merged in.
>
> Thoughts?  Do we try to get this working for the 0.9 release (with a
> hack, not Min's stuff), or do we remove the capability?

We're at the RC1 level now, so I'd like to hold off on anything but
really focused changes.  If you think this requires major work, I'd
say let's disable it altogether and document it, so we can cut the
release quickly.

Once the release is out, we can open again a 'merge window' for more
invasive changes.

Cheers,

f


From ellisonbg.net at gmail.com  Wed Sep  3 18:12:45 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 15:12:45 -0700
Subject: [IPython-dev] ipcluster with clusterfile
In-Reply-To: <db6b5ecc0809031505w3f6f259buca9c5acab35e41b7@mail.gmail.com>
References: <6ce0ac130809031419g3bd07c7cxa1657c3f4f88b779@mail.gmail.com>
	<db6b5ecc0809031505w3f6f259buca9c5acab35e41b7@mail.gmail.com>
Message-ID: <6ce0ac130809031512k48c1cd7cn6632f8a26bb757e@mail.gmail.com>

> We're at the RC1 level now, so I'd like to hold off on anything but
> really focused changes.  If you think this requires major work, I'd
> say let's disable it altogether and document it, so we can cut the
> release quickly.

This was my leaning as well.  For this release, I am going to disable
the clusterfile and simply print a message to the user that it has
been disabled.

> Once the release is out, we can open again a 'merge window' for more
> invasive changes.
>
> Cheers,
>
> f
>


From ellisonbg.net at gmail.com  Wed Sep  3 18:15:31 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 15:15:31 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
Message-ID: <6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>

I will create a get_ipython_dir function in genutils.

I do want this to go into the 0.9 release as it will enable me to fix
something that we want to get right before we release...

I would like to create a ~/.ipython/security directory to put the furl
files and ssl certificates into.  Are people OK with me putting this
in the 0.9 release?  I consider this a bug that should be fixed ASAP.

Cheers,

Brian

On Wed, Sep 3, 2008 at 3:01 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Sep 3, 2008 at 2:13 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> The reason that I ask is that we have get_home_dir repeated twice:
>>
>> genutils.py
>> IPython/config/cutils.py
>>
>> I want to get rid of one of these.  IPython/config/cutils.py also has
>> an get_ipython_dir.py, but I don't think this is the right place for
>> this.
>>
>> Also pulling the value from IP won't work in my case because I need it
>> for the controller and engines, which (for now) don't have a full IP
>> instance.
>>
>> Is this the right logic from ipmaker.py:
>>
>>    # Platform-dependent suffix and directory names.  We use _ipython instead
>>    # of .ipython under win32 b/c there's software that breaks with .named
>>    # directories on that platform.
>>    if os.name == 'posix':
>>        rc_suffix = ''
>>        ipdir_def = '.ipython'
>>    else:
>>        rc_suffix = '.ini'
>>        ipdir_def = '_ipython'
>>
>>    # default directory for configuration
>>    ipythondir_def = os.path.abspath(os.environ.get('IPYTHONDIR',
>>                                 os.path.join(IP.home_dir,ipdir_def)))
>>
>> If so, I will make a get_ipython_dir function in genutils and remove
>> the cruft from config/cutils.py
>
> Yes.  Even if it's not ideal, having it in a function will let us clean it up.
>
> Cheers,
>
> f
>


From ondrej at certik.cz  Wed Sep  3 18:23:19 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 4 Sep 2008 00:23:19 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
Message-ID: <85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>

On Wed, Sep 3, 2008 at 11:08 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Let's say you have 30 commits in the branch and let's say that it
>> doesn't pass the review, because it needs improving. My question is,
>> what will you do? Will you commit the improvement over your 30 commits
>> (e.g. just adding more commits to the branch, until all the code is ok
>> to go in), or will you try to fix some of the commits in the branch,
>> so that actually all of the commits individually are ok? (I know you
>> cannot just push there "individual commits", because they are related
>> with the rest.)
>
> Ahh, now I understand.  Our approach is that you create new commits
> that fix the problems in the old commits.  There are a couple of
> reasons for this:
>
> 1.  Commits serve as a full record of all the code that gets written -
> good and bad.  If you are always completely covering up bad code, it
> an hurt you.  Let's say there is a really subtle bug in a commit and
> you spend a long time tracking it down.  You put in a test case and
> all seems OK.  But if you erase the original commit, there is less of
> a record about the bug that may help you or others in the future.  I
> think it is much better to 1) have a commit that has the bug and 2)
> have another commit that fixes the bug with a full description of the
> bug.
>
> 2.  Sometimes code review requires making changes to code that spans
> multiple initial commits.  At this point, I think it just gets
> difficult to have a development model where each individual commit is
> OK by itself.  Our development style to just too non-linear and
> convoluted for this to be practical.  I suppose your style might fit
> this model better - don't know though.
>
>> I don't know if I made it clear now. My question is if you try to make
>> each change (=each commit) ok to go in, or if you just try for each
>> new bunch of commits (=branch) to be ok to go in (i.e. some commits
>> can be crap, if they are fixed by later commits in the same branch).
>
> We have a development model that allows for the following:
>
> crap + crap + crap + fix_crap + tests = beautiful code merged into trunk
>
> This seems more realistic than:
>
> beautiful_code + beautiful_code + beautiful_code + tests = beautiful_code
>
> Maybe once I become perfect, the second would work though ;-)

I see, thanks for the explanation, that's what I was interested in,
everything is now much clearer to me. Still couple points though:

I don't understand why you need to be perfect to fix crap ->
beautiful_code. In my experience, I always write:

crap+crap+crap+tests

and in the process of review, it becomes:

beautiful_code + beautiful_code + beautiful_code + tests

while in your case, it becomes:

crap+crap+crap+tests+fix_crap

E.g. the only difference is that in my case I distribute the
"fix_crap" commit into the commits that are crap.
I guess it depends on the "fix_crap". If it's just a simple fix, it's ok.

I am still trying to find the best workflow, but so far I like this: I
commit very often and prepare something in my local branch. Then I
rebase it in a couple of well documented nice commits, put it in some
public branch (so that people can pull it) and ask for a review. Then,
if I did a good job and the "fix_crap" commit (there is almost always
some) is simple, I completely agree with you it should be committed
after it. But if I did a bad job and the whole branch needs to be
revised, or just more deep changes are needed, it's imho better to
rework it. E.g. what happens in your case, if the branch is "not ok to
go in", but the fix is not just some easy "fix_crap", but some
fundamental problem -- you just start another branch and use the good
ideas (patches) from the broken one?

Ondrej


From fperez.net at gmail.com  Wed Sep  3 20:05:58 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 17:05:58 -0700
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
	<85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
Message-ID: <db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>

Hey Ondrej,

On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <ondrej at certik.cz> wrote:

> I am still trying to find the best workflow, but so far I like this: I
> commit very often and prepare something in my local branch. Then I
> rebase it in a couple of well documented nice commits, put it in some
> public branch (so that people can pull it) and ask for a review. Then,
> if I did a good job and the "fix_crap" commit (there is almost always
> some) is simple, I completely agree with you it should be committed
> after it. But if I did a bad job and the whole branch needs to be
> revised, or just more deep changes are needed, it's imho better to
> rework it. E.g. what happens in your case, if the branch is "not ok to
> go in", but the fix is not just some easy "fix_crap", but some
> fundamental problem -- you just start another branch and use the good
> ideas (patches) from the broken one?

I actually do like the approach you describe, but as far as I've seen,
bzr isn't the friendliest to this type of workflow with frequent
'history rewriting'.  It's my understanding that git is far, far
better suited to this approach.

For now I feel like we've found somewhat of a sweet spot with bzr,
where things aren't perfect but they work OK, we do benefit from the
tools in launchpad and the distributed nature of bzr, and we can
actually spend more time working on ipython than thinking about
version control :)

But your comments regarding history cleanup do linger in the back of
my mind and I've thought about it.  It's just that right now, I want
to focus for a while on using the tools productively (even if they are
imperfect) rather than fidgeting forever with them.

I'm always eager to learn further about this though, especially about
approaches that work better in the context of bzr/launchpad, since I'm
not about to consider another change, at least for a while.

cheers,

f


From fperez.net at gmail.com  Wed Sep  3 20:30:52 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 17:30:52 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
Message-ID: <db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>

On Wed, Sep 3, 2008 at 3:15 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I will create a get_ipython_dir function in genutils.
>
> I do want this to go into the 0.9 release as it will enable me to fix
> something that we want to get right before we release...
>
> I would like to create a ~/.ipython/security directory to put the furl
> files and ssl certificates into.  Are people OK with me putting this
> in the 0.9 release?  I consider this a bug that should be fixed ASAP.

Yes, please do so.  The directory must be made read-only for the
owner, and a warning should be emitted if its permissions are more
open than that (like ssh does with ~/.ssh/).

Let's target 1 week from now for the final 0.9 release, is that OK
with everyone  (next Wednesday)?

Cheers,

f


From fperez.net at gmail.com  Wed Sep  3 20:35:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 17:35:19 -0700
Subject: [IPython-dev] ipython0 and sys.displayhook
In-Reply-To: <48b27b30.09c5660a.0ff6.ffffd07a@mx.google.com>
References: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com>
	<46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com>
	<48b27b30.09c5660a.0ff6.ffffd07a@mx.google.com>
Message-ID: <db6b5ecc0809031735r4ecf4556w686d4e33328b7cad@mail.gmail.com>

On Mon, Aug 25, 2008 at 2:28 AM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:

> (in comment it  is said it used by 'exec' but so far I haven't seen side
> effect, perhaps that's because I'm using a recent python interpreter...)

I believe sys.displayhook is directly called by the internals of the
python vm when 'exec' is run, but I could be wrong.  My memory is
pretty fuzzy on this and I haven't done any recent, careful
experimentation to verify this statement.

Cheers,

f


From gael.varoquaux at normalesup.org  Wed Sep  3 21:05:13 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 4 Sep 2008 03:05:13 +0200
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
Message-ID: <20080904010513.GA23307@phare.normalesup.org>

On Wed, Sep 03, 2008 at 05:30:52PM -0700, Fernando Perez wrote:
> Let's target 1 week from now for the final 0.9 release, is that OK
> with everyone  (next Wednesday)?


OK from my side. I am using the frontend rather heavily right now, so
hopefully I findany bugs lying around.

Ga?l


From fperez.net at gmail.com  Wed Sep  3 21:19:06 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 18:19:06 -0700
Subject: [IPython-dev] Release plans for 0.9
Message-ID: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>

Howdy,

we've had several betas already and an rc in the usual location.
Brian seems to have a few small fixes in the pipeline, but otherwise
I'd rather not delay things too far.

Unless anyone objects, we'll try to cut the release next Wednesday or
so (give or take a day).  I'll be somewhat offline (travel) between
tomorrow and next Tuesday, but I'll try to keep an eye on things.

Please:

- keep your development branch publicly visible so others can review
your code, give feedback, etc.  At

https://code.launchpad.net/ipython

you can see the branches that are already publicly visible.   I'd
encourage everyone else in the team to follow suit (we'll revisit this
post-0.9 as we firm up our dev process).

- request some feedback as appropriate before making significant changes.


Cheers,

f


From fperez.net at gmail.com  Wed Sep  3 21:23:05 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 18:23:05 -0700
Subject: [IPython-dev] [IPython-user] sys.stderr
In-Reply-To: <48BF3660.8050106@bughunter.ca>
References: <48BEBC6B.8000905@bughunter.ca>
	<db6b5ecc0809031733u69dd6715l321193bb832e647c@mail.gmail.com>
	<48BF3660.8050106@bughunter.ca>
Message-ID: <db6b5ecc0809031823k39fce407td037baa4b5a96f02@mail.gmail.com>

[ replying on list so it stays archived.  I'll also be rather offline
starting basically now...]

On Wed, Sep 3, 2008 at 6:14 PM, JM Seitz <jms at bughunter.ca> wrote:
> Yeah I will see how much information I can post, worst case scenario I
> will off-list to you, but I warn you I had to do some nasty hacks to
> make it all work.
>
> Quick question: InteractiveShell.Completer....how do I set this properly
> so the completer behaves like the standard IPython completer? I have
> been through the docs/tutorials, but I can't seem to get a valid
> completer working.

have a look at iplib.py, around line 1330, the init_readline method is
where the self.Completer attribute is created.

HTH,

f


From ellisonbg.net at gmail.com  Thu Sep  4 00:18:58 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 21:18:58 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
Message-ID: <6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>

On Wed, Sep 3, 2008 at 5:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Sep 3, 2008 at 3:15 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I will create a get_ipython_dir function in genutils.
>>
>> I do want this to go into the 0.9 release as it will enable me to fix
>> something that we want to get right before we release...
>>
>> I would like to create a ~/.ipython/security directory to put the furl
>> files and ssl certificates into.  Are people OK with me putting this
>> in the 0.9 release?  I consider this a bug that should be fixed ASAP.
>
> Yes, please do so.  The directory must be made read-only for the
> owner, and a warning should be emitted if its permissions are more
> open than that (like ssh does with ~/.ssh/).

I have implemented this in my private branch and am testing.  I am
setting the permissions to 0700.

> Let's target 1 week from now for the final 0.9 release, is that OK
> with everyone  (next Wednesday)?

Sounds good for me!  I am almost done finishing up a few bug fixes and
then it is just docs.

Brian

> Cheers,
>
> f
>


From ellisonbg.net at gmail.com  Thu Sep  4 00:20:56 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 21:20:56 -0700
Subject: [IPython-dev] Release plans for 0.9
In-Reply-To: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>
References: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>
Message-ID: <6ce0ac130809032120x7c311af2rcce5edaac09a7f1c@mail.gmail.com>

> we've had several betas already and an rc in the usual location.
> Brian seems to have a few small fixes in the pipeline, but otherwise
> I'd rather not delay things too far

My fixes are almost done.

> Unless anyone objects, we'll try to cut the release next Wednesday or
> so (give or take a day).  I'll be somewhat offline (travel) between
> tomorrow and next Tuesday, but I'll try to keep an eye on things.
>
> Please:
>
> - keep your development branch publicly visible so others can review
> your code, give feedback, etc.  At
>
> https://code.launchpad.net/ipython
>
> you can see the branches that are already publicly visible.   I'd
> encourage everyone else in the team to follow suit (we'll revisit this
> post-0.9 as we firm up our dev process).
>
> - request some feedback as appropriate before making significant changes.

Yep, I have some changes that I will want reviewed before merging.  I
will post my branch soon.

Cheers,

Brian

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


From fperez.net at gmail.com  Thu Sep  4 00:23:58 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 21:23:58 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
	<6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>
Message-ID: <db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>

On Wed, Sep 3, 2008 at 9:18 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> I have implemented this in my private branch and am testing.  I am
> setting the permissions to 0700.

Great (just keep win32 in mind, where the above probably just needs to
be skipped, or at least I don't know what the right solution should
be).

Could you publish your working branch as well for review?  We've been using

lp:~devname/ipython/trunk-dev

for each person's working copy of trunk (in addition to any others
they may have around) as a convention so it's easy to know what those
mean when we see the list of associated branches.  That obviously
doesn't preclude anyone from keeping regular feature branches, like we
have some right now.

Thanks!

f


From fperez.net at gmail.com  Thu Sep  4 00:24:35 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 21:24:35 -0700
Subject: [IPython-dev] Release plans for 0.9
In-Reply-To: <6ce0ac130809032120x7c311af2rcce5edaac09a7f1c@mail.gmail.com>
References: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>
	<6ce0ac130809032120x7c311af2rcce5edaac09a7f1c@mail.gmail.com>
Message-ID: <db6b5ecc0809032124s307858b9ga36f9e52e650647c@mail.gmail.com>

On Wed, Sep 3, 2008 at 9:20 PM, Brian Granger

> Yep, I have some changes that I will want reviewed before merging.  I
> will post my branch soon.

Oops.  Ignore my previous message then :)

Cheers,

f


From ellisonbg.net at gmail.com  Thu Sep  4 00:28:38 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 21:28:38 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
Message-ID: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>

Hi,

I am trying to test IPython 0.9 on Win32 in preparation for the
release.  Here is how I am building the installer:

python setup.py bdist_wininst --install-script=ipython_win_post_install.py

I need to build my own installer because I am working off a private
branch that has some bug fixes.  Then I just double click to install.

Everything installs fine.....but, there are no .exe files created
(ipython.exe, ipcontroller.exe, etc.).

When I install using an egg and easy_install, the .exe files get
created just fine.

Is the Win32 installer still broken or am I doing something really
stupid?  I don't @#$* about Windows and I would consider this to be a
show stopper for the 0.9 release (unless someone can point out what
stupid thing I am doing).

Can someone with Win32 karma point the way here?

Thanks,

Brian


From ellisonbg.net at gmail.com  Thu Sep  4 00:30:19 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 21:30:19 -0700
Subject: [IPython-dev] Release plans for 0.9
In-Reply-To: <db6b5ecc0809032124s307858b9ga36f9e52e650647c@mail.gmail.com>
References: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>
	<6ce0ac130809032120x7c311af2rcce5edaac09a7f1c@mail.gmail.com>
	<db6b5ecc0809032124s307858b9ga36f9e52e650647c@mail.gmail.com>
Message-ID: <6ce0ac130809032130o1f6e0464o3ee6908c101a1eef@mail.gmail.com>

Fernando,

Also, do we want to tag a 0.9 branch at this point?  That would let
trunk move forward without any worries of messing up the 0.9 release.
Minimally, we need to do a code freeze for all but critical bug fixes
into trunk (or a 0.9 branch if we create one).

Thoughts?

Brian

On Wed, Sep 3, 2008 at 9:24 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Sep 3, 2008 at 9:20 PM, Brian Granger
>
>> Yep, I have some changes that I will want reviewed before merging.  I
>> will post my branch soon.
>
> Oops.  Ignore my previous message then :)
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Thu Sep  4 00:33:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 21:33:23 -0700
Subject: [IPython-dev] Release plans for 0.9
In-Reply-To: <6ce0ac130809032130o1f6e0464o3ee6908c101a1eef@mail.gmail.com>
References: <db6b5ecc0809031819u2cdf04dby1b3ed13dbf87a318@mail.gmail.com>
	<6ce0ac130809032120x7c311af2rcce5edaac09a7f1c@mail.gmail.com>
	<db6b5ecc0809032124s307858b9ga36f9e52e650647c@mail.gmail.com>
	<6ce0ac130809032130o1f6e0464o3ee6908c101a1eef@mail.gmail.com>
Message-ID: <db6b5ecc0809032133h33bc7b0ei8fe0247a4ef2d3ff@mail.gmail.com>

On Wed, Sep 3, 2008 at 9:30 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Fernando,
>
> Also, do we want to tag a 0.9 branch at this point?  That would let
> trunk move forward without any worries of messing up the 0.9 release.
> Minimally, we need to do a code freeze for all but critical bug fixes
> into trunk (or a 0.9 branch if we create one).

Sure, though I won't be able to do it: I have to go pack and I'm
leaving for a trip tomorrow.  Since  I don't know the details of how
tagging works in bzr, I'd need to look it up a bit.  If you can have a
go at it (or anyone else),  great.  It seems to me on quick inspection
that tagging just marks a specific revision, so we'd need to make the
tag branch as well in order to support the 0.9 specific work.

Go for it.

Cheers,

f


From fperez.net at gmail.com  Thu Sep  4 00:46:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 21:46:47 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
Message-ID: <db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>

Hey,

On Wed, Sep 3, 2008 at 9:28 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> I am trying to test IPython 0.9 on Win32 in preparation for the
> release.  Here is how I am building the installer:
>
> python setup.py bdist_wininst --install-script=ipython_win_post_install.py
>
> I need to build my own installer because I am working off a private
> branch that has some bug fixes.  Then I just double click to install.
>
> Everything installs fine.....but, there are no .exe files created
> (ipython.exe, ipcontroller.exe, etc.).

I don't think it's supposed to create .exes at all.  What it does is
make Start Menu links to the appropriate "python ... ipython .. flags"
call.  So you should see in your start menu an "IPython" entry with
sub-entries for 'scipy', 'pylab', 'pysh', and the docs (as well as the
default main ipython entry).

Cheers,

f


From ellisonbg.net at gmail.com  Thu Sep  4 00:52:18 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 21:52:18 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
Message-ID: <6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>

> I don't think it's supposed to create .exes at all.  What it does is
> make Start Menu links to the appropriate "python ... ipython .. flags"
> call.  So you should see in your start menu an "IPython" entry with
> sub-entries for 'scipy', 'pylab', 'pysh', and the docs (as well as the
> default main ipython entry).

It does make the Start Menu links.  But, it only does this for a few
things.  Namely it does do ipcontroller, ipengine, iptest, etc.  Thus,
there is no way of calling these other programs.  Also, does this mean
that you can't start ipython from the Win32 command line by typing
"ipython"?

I very much like how the egg creates .exe files for _all_ the scripts,
so you can just type the command name at the command line.

Brian

> Cheers,
>
> f
>


From gael.varoquaux at normalesup.org  Thu Sep  4 00:55:37 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 4 Sep 2008 06:55:37 +0200
Subject: [IPython-dev] 0.9 Windows installer still not working for	me!?!?
In-Reply-To: <6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
	<6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
Message-ID: <20080904045537.GD27182@phare.normalesup.org>

On Wed, Sep 03, 2008 at 09:52:18PM -0700, Brian Granger wrote:
> I very much like how the egg creates .exe files for _all_ the scripts,
> so you can just type the command name at the command line.

Yes, this is one of the nice features of setuptools. Setuptools has a
bunch of nice features. It is too bad they are bundled with a few others
that one might prefer not to use.

Ga?l


From fperez.net at gmail.com  Thu Sep  4 00:58:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 21:58:47 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
	<6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
Message-ID: <db6b5ecc0809032158u2409bbe4vd92266826c75da18@mail.gmail.com>

On Wed, Sep 3, 2008 at 9:52 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I don't think it's supposed to create .exes at all.  What it does is
>> make Start Menu links to the appropriate "python ... ipython .. flags"
>> call.  So you should see in your start menu an "IPython" entry with
>> sub-entries for 'scipy', 'pylab', 'pysh', and the docs (as well as the
>> default main ipython entry).
>
> It does make the Start Menu links.  But, it only does this for a few
> things.  Namely it does do ipcontroller, ipengine, iptest, etc.  Thus,
> there is no way of calling these other programs.  Also, does this mean
> that you can't start ipython from the Win32 command line by typing
> "ipython"?
>
> I very much like how the egg creates .exe files for _all_ the scripts,
> so you can just type the command name at the command line.

Yes, that stuff is *very old*, from back when we only had the main
ipython terminal, with at most one or two profiles.  It hasn't really
been updated for the new codebase where we want proper terminal-based
script support even under windows, I'm afraid.

Sorry not to have a better solution to offer right now.  Perhaps for
win32 we should just recommend the egg?  When I wrote that installer,
setuptools didn't even exist, so it wasn't an option, but maybe now we
can go that route for win32, I don't know...

I certainly lack the knowledge for how to create all the .exe entry
points in windows myself...

Cheers,

f


From ellisonbg.net at gmail.com  Thu Sep  4 01:00:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 22:00:15 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
	<6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>
	<db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>
Message-ID: <6ce0ac130809032200r7d7c513cxcd1e612d597d9696@mail.gmail.com>

> Could you publish your working branch as well for review?  We've been using
>
> lp:~devname/ipython/trunk-dev

Done!

I also posted this branch for review.  There are three commits that
need review before I merge them into trunk for the 0.9 release.  They
are minor, but I especially like review this close to a release!

> for each person's working copy of trunk (in addition to any others
> they may have around) as a convention so it's easy to know what those
> mean when we see the list of associated branches.  That obviously
> doesn't preclude anyone from keeping regular feature branches, like we
> have some right now.

Yep, this is a great idea that all of us should follow!!!!

Brian

> Thanks!
>
> f
>


From ellisonbg.net at gmail.com  Thu Sep  4 01:01:42 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 22:01:42 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
	<6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>
	<db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>
Message-ID: <6ce0ac130809032201t6351d9b7oc84f5986bef5d633@mail.gmail.com>

Fernando,

I also noticed that your lp:~fdo.perez/ipython/trunk-dev branch has
commits that need to be merged into trunk.  Do these need review?  Are
they ready to go?  It would be great to get these in before you leave
tomorrow?  (your not trying to pack are you?)


Cheers,

Brian

On Wed, Sep 3, 2008 at 9:23 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Sep 3, 2008 at 9:18 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>
>> I have implemented this in my private branch and am testing.  I am
>> setting the permissions to 0700.
>
> Great (just keep win32 in mind, where the above probably just needs to
> be skipped, or at least I don't know what the right solution should
> be).
>
> Could you publish your working branch as well for review?  We've been using
>
> lp:~devname/ipython/trunk-dev
>
> for each person's working copy of trunk (in addition to any others
> they may have around) as a convention so it's easy to know what those
> mean when we see the list of associated branches.  That obviously
> doesn't preclude anyone from keeping regular feature branches, like we
> have some right now.
>
> Thanks!
>
> f
>


From ellisonbg.net at gmail.com  Thu Sep  4 01:10:10 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 3 Sep 2008 22:10:10 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <db6b5ecc0809032158u2409bbe4vd92266826c75da18@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
	<6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
	<db6b5ecc0809032158u2409bbe4vd92266826c75da18@mail.gmail.com>
Message-ID: <6ce0ac130809032210i70f158e2p57accf3395b3b8de@mail.gmail.com>

> Yes, that stuff is *very old*, from back when we only had the main
> ipython terminal, with at most one or two profiles.  It hasn't really
> been updated for the new codebase where we want proper terminal-based
> script support even under windows, I'm afraid.

OK.  That makes sense then.  I guess Win32 users have always just
started ipython from the start Menu?  Ouch.

> Sorry not to have a better solution to offer right now.  Perhaps for
> win32 we should just recommend the egg?  When I wrote that installer,
> setuptools didn't even exist, so it wasn't an option, but maybe now we
> can go that route for win32, I don't know...

Not your fault that distutils sucks.

> I certainly lack the knowledge for how to create all the .exe entry
> points in windows myself...

Me too.  The only thing I know how to do would be to copy what another
project does (like Twisted) and see if that works.

Here are the options as I see it:

1.  We simply get rid of this bad code and stop shipping Win32 .exe
installers.  Instead people can easy_install the egg or just python
setup.py install it.  If we go this route, we should really get rid of
the post install scripts as they will simply confuse people.

2.  Someone who cares about an .exe installer and who knows how to
handle the post install stuff properly steps in and fixes all of this
before the release.

Note:  it is not an option to simply leave the post install script as
it is for the release.  It leaves much of IPython completely unsuable
from Win32.

Opinions on this?  We don't have much time left on this...

Cheers,

Brian

> Cheers,
>
> f
>


From fperez.net at gmail.com  Thu Sep  4 01:41:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 3 Sep 2008 22:41:33 -0700
Subject: [IPython-dev] Do we have an get_ipython_dir
In-Reply-To: <6ce0ac130809032201t6351d9b7oc84f5986bef5d633@mail.gmail.com>
References: <6ce0ac130809031359k3579a4a9h3208fa8cd0df94ca@mail.gmail.com>
	<db6b5ecc0809031408i434e6ceg5a40d29419e76f1e@mail.gmail.com>
	<6ce0ac130809031413r66723d51qf4fc6d3713e1874f@mail.gmail.com>
	<db6b5ecc0809031501o3820eae6oc88b5cf47ae8c952@mail.gmail.com>
	<6ce0ac130809031515l5e9c9afcg26a8d32be16a2692@mail.gmail.com>
	<db6b5ecc0809031730i1fc8c732se437a0ca016cc844@mail.gmail.com>
	<6ce0ac130809032118r5420d7deg33a6e2a6596ab25e@mail.gmail.com>
	<db6b5ecc0809032123p44a12698p4c9d21e319141dfe@mail.gmail.com>
	<6ce0ac130809032201t6351d9b7oc84f5986bef5d633@mail.gmail.com>
Message-ID: <db6b5ecc0809032241v7e2b5217s50099982fac3ed59@mail.gmail.com>

On Wed, Sep 3, 2008 at 10:01 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Fernando,
>
> I also noticed that your lp:~fdo.perez/ipython/trunk-dev branch has
> commits that need to be merged into trunk.  Do these need review?  Are
> they ready to go?  It would be great to get these in before you leave
> tomorrow?  (your not trying to pack are you?)

No, those have all been merged when doing the rc1.  They were
basically last-minute fixes in the rc build, and merging stuff from
others.  Go to the review page and you'll see no pending merges:

https://code.launchpad.net/~fdo.perez/ipython/trunk-dev/+merge/760

I did a quick review of your merges, mostly just to get the ball
rolling and to start using the lp review tool to get used to it.
We'll see how we adapt to using more and more review, which is better
than scanning code post-commit for problems...

I gotta go pack now :)

Cheers,

f


From stefan at sun.ac.za  Thu Sep  4 02:27:27 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 4 Sep 2008 08:27:27 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
	<85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
	<db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>
Message-ID: <9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>

2008/9/4 Fernando Perez <fperez.net at gmail.com>:
> On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>
>> I am still trying to find the best workflow, but so far I like this: I
>> commit very often and prepare something in my local branch. Then I
>> rebase it in a couple of well documented nice commits, put it in some
>> public branch (so that people can pull it) and ask for a review. Then,
>> if I did a good job and the "fix_crap" commit (there is almost always
>> some) is simple, I completely agree with you it should be committed
>> after it. But if I did a bad job and the whole branch needs to be
>> revised, or just more deep changes are needed, it's imho better to
>> rework it. E.g. what happens in your case, if the branch is "not ok to
>> go in", but the fix is not just some easy "fix_crap", but some
>> fundamental problem -- you just start another branch and use the good
>> ideas (patches) from the broken one?
>
> I actually do like the approach you describe, but as far as I've seen,
> bzr isn't the friendliest to this type of workflow with frequent
> 'history rewriting'.  It's my understanding that git is far, far
> better suited to this approach.

In bzr, it seems everything is just a plugin away:

http://bazaar-vcs.org/Rebase

Cheers
St?fan


From cournapeau at cslab.kecl.ntt.co.jp  Thu Sep  4 02:32:33 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 04 Sep 2008 15:32:33 +0900
Subject: [IPython-dev] rebase vs loom (was branch management getting better)
Message-ID: <1220509953.4665.16.camel@bbc8>

Hi,

	For a discussion about how bzr do things when you would use rebase with
git

http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism

and

http://lwn.net/Articles/269120/

Which is interesting since Linus explains why he thinks rebase should
avoided in some cases, which are quite important when you think about
it. Rebase is nice to use (I use it all the time now for numpy/scipy,
since I only develop through git-svn for sometime), but I think it
becomes impractical. Making it hard to share with people is not the only
reason: it makes it hard to understand what happened during that
developement when you need to go back in history; IOW, rebase is almost
always the bad solution. It also makes bisecting much harder. I like how
Andrew makes the difference between commit history and change
presentation; I think the difference really makes sense.

cheers,

David



From cournapeau at cslab.kecl.ntt.co.jp  Thu Sep  4 02:37:00 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 04 Sep 2008 15:37:00 +0900
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
	<85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
	<db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>
	<9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>
Message-ID: <1220510220.4665.21.camel@bbc8>

On Thu, 2008-09-04 at 08:27 +0200, St?fan van der Walt wrote:
> 
> In bzr, it seems everything is just a plugin away:

Yes, but bzr does not work well with rebase from a UI POV. You should
not use it for the above user-cases, specially since bzr is specifically
designed with a very different mindset when it comes to sharing work
with others. bzr developers never use rebase.

Rewriting history is just not such a great feature once anyone else
started to look at it: integrating it into the official code will not
reflect what happened, and if you need to go back at it one year later,
there will be no chance to understand what happened.

cheers,

David



From ondrej at certik.cz  Thu Sep  4 02:49:09 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 4 Sep 2008 08:49:09 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
	<85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
	<db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>
	<9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>
Message-ID: <85b5c3130809032349nc3c9accq20eb78cf159e759c@mail.gmail.com>

On Thu, Sep 4, 2008 at 8:27 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/9/4 Fernando Perez <fperez.net at gmail.com>:
>> On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>>
>>> I am still trying to find the best workflow, but so far I like this: I
>>> commit very often and prepare something in my local branch. Then I
>>> rebase it in a couple of well documented nice commits, put it in some
>>> public branch (so that people can pull it) and ask for a review. Then,
>>> if I did a good job and the "fix_crap" commit (there is almost always
>>> some) is simple, I completely agree with you it should be committed
>>> after it. But if I did a bad job and the whole branch needs to be
>>> revised, or just more deep changes are needed, it's imho better to
>>> rework it. E.g. what happens in your case, if the branch is "not ok to
>>> go in", but the fix is not just some easy "fix_crap", but some
>>> fundamental problem -- you just start another branch and use the good
>>> ideas (patches) from the broken one?
>>
>> I actually do like the approach you describe, but as far as I've seen,
>> bzr isn't the friendliest to this type of workflow with frequent
>> 'history rewriting'.  It's my understanding that git is far, far
>> better suited to this approach.
>
> In bzr, it seems everything is just a plugin away:
>
> http://bazaar-vcs.org/Rebase

This is cool. Mercurial implemented rebase only recently, so it is in
the hg repo of hg, but not in any release.

Thanks Fernando for the comments, that's all I wanted to know. Btw,
this email by Linus is interesting with regards to rebasing:

http://kerneltrap.org/mailarchive/linux-kernel/2008/5/17/1852794

And see the emails around it. So as you can see it's still quite a hot
topic about the ideal workflow. Generally I'll try to learn from the
kernel developers, because they don't have just 5 or 6 active
developers, but hundreds of them.

Ondrej

From ondrej at certik.cz  Thu Sep  4 02:50:08 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 4 Sep 2008 08:50:08 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <1220510220.4665.21.camel@bbc8>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
	<85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>
	<6ce0ac130809031334n594f4f60hb7bbc4a9b68a352a@mail.gmail.com>
	<85b5c3130809031359y1594cd17m9b46973939268d19@mail.gmail.com>
	<6ce0ac130809031408t25689f8elcf83b6cd7e43d06b@mail.gmail.com>
	<85b5c3130809031523x3242e82dvc1dfdb1a7c310ffc@mail.gmail.com>
	<db6b5ecc0809031705x6a7f4fc1w4a19e2f64eee68cb@mail.gmail.com>
	<9457e7c80809032327v840dfa8v12bb8568ab534ff2@mail.gmail.com>
	<1220510220.4665.21.camel@bbc8>
Message-ID: <85b5c3130809032350k9e4a24dg908e9bad1329ef41@mail.gmail.com>

On Thu, Sep 4, 2008 at 8:37 AM, David Cournapeau
<cournapeau at cslab.kecl.ntt.co.jp> wrote:
> On Thu, 2008-09-04 at 08:27 +0200, St?fan van der Walt wrote:
>>
>> In bzr, it seems everything is just a plugin away:
>
> Yes, but bzr does not work well with rebase from a UI POV. You should
> not use it for the above user-cases, specially since bzr is specifically
> designed with a very different mindset when it comes to sharing work
> with others. bzr developers never use rebase.
>
> Rewriting history is just not such a great feature once anyone else
> started to look at it: integrating it into the official code will not
> reflect what happened, and if you need to go back at it one year later,
> there will be no chance to understand what happened.

This is addressed in the linus email I linked in my previous email.

Ondrej

From jorgen.stenarson at bostream.nu  Thu Sep  4 13:04:21 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 04 Sep 2008 19:04:21 +0200
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
Message-ID: <48C01515.30804@bostream.nu>

Brian Granger skrev:
> Hi,
> 
> I am trying to test IPython 0.9 on Win32 in preparation for the
> release.  Here is how I am building the installer:
> 
> python setup.py bdist_wininst --install-script=ipython_win_post_install.py
> 
> I need to build my own installer because I am working off a private
> branch that has some bug fixes.  Then I just double click to install.
> 
> Everything installs fine.....but, there are no .exe files created
> (ipython.exe, ipcontroller.exe, etc.).
> 
> When I install using an egg and easy_install, the .exe files get
> created just fine.
> 
> Is the Win32 installer still broken or am I doing something really
> stupid?  I don't @#$* about Windows and I would consider this to be a
> show stopper for the 0.9 release (unless someone can point out what
> stupid thing I am doing).
> 
> Can someone with Win32 karma point the way here?
>

I usually add .py and .pyw to PATHEXT and %PYTHON_INSTALL_DIR%/scripts 
to PATH to ensure I can just type ipython at the commandprompt. With 
these environment variables set, I can run ipython just fine at the 
cmd-prompt after running a windows installer from latest trunk.

It looks like the ipython shell script in %PYTHON%/Scripts is copied to 
ipython.py on line 76 in ipython_win_post_install.py perhaps the other 
scripts should be given the same treatment.

The last time I looked at using ipython from an egg in windows there was 
some weirdness. Caused by the ipython.exe file launching another process
to run python and when you did ctrl-c only one of the processes where 
killed causing really strange behaviour. But this was several years ago.

/J?rgen




From ellisonbg.net at gmail.com  Thu Sep  4 13:33:59 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 10:33:59 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <6ce0ac130809032210i70f158e2p57accf3395b3b8de@mail.gmail.com>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<db6b5ecc0809032146i32893341t66b4a5637e9184bf@mail.gmail.com>
	<6ce0ac130809032152l56f2a0ct8e709f43db68195a@mail.gmail.com>
	<db6b5ecc0809032158u2409bbe4vd92266826c75da18@mail.gmail.com>
	<6ce0ac130809032210i70f158e2p57accf3395b3b8de@mail.gmail.com>
Message-ID: <6ce0ac130809041033j1eb22ef0y49fe3e61b9f8f23d@mail.gmail.com>

> 1.  We simply get rid of this bad code and stop shipping Win32 .exe
> installers.  Instead people can easy_install the egg or just python
> setup.py install it.  If we go this route, we should really get rid of
> the post install scripts as they will simply confuse people.
>
> 2.  Someone who cares about an .exe installer and who knows how to
> handle the post install stuff properly steps in and fixes all of this
> before the release.

I got a good night sleep and am going to attempt to fix all of this
today.  I will let people know how his goes.

Brian


From ellisonbg.net at gmail.com  Thu Sep  4 13:34:43 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 10:34:43 -0700
Subject: [IPython-dev] 0.9 Windows installer still not working for me!?!?
In-Reply-To: <48C01515.30804@bostream.nu>
References: <6ce0ac130809032128y76dbbd49wfb408653932b4fe1@mail.gmail.com>
	<48C01515.30804@bostream.nu>
Message-ID: <6ce0ac130809041034s7b5aadc1jbdf7a0bb14944d56@mail.gmail.com>

Thanks for the tip, I didn't know about this.  I will probably do what
you suggest, as well as creating .bat files as well.

Cheers,

Brian

On Thu, Sep 4, 2008 at 10:04 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Brian Granger skrev:
>>
>> Hi,
>>
>> I am trying to test IPython 0.9 on Win32 in preparation for the
>> release.  Here is how I am building the installer:
>>
>> python setup.py bdist_wininst --install-script=ipython_win_post_install.py
>>
>> I need to build my own installer because I am working off a private
>> branch that has some bug fixes.  Then I just double click to install.
>>
>> Everything installs fine.....but, there are no .exe files created
>> (ipython.exe, ipcontroller.exe, etc.).
>>
>> When I install using an egg and easy_install, the .exe files get
>> created just fine.
>>
>> Is the Win32 installer still broken or am I doing something really
>> stupid?  I don't @#$* about Windows and I would consider this to be a
>> show stopper for the 0.9 release (unless someone can point out what
>> stupid thing I am doing).
>>
>> Can someone with Win32 karma point the way here?
>>
>
> I usually add .py and .pyw to PATHEXT and %PYTHON_INSTALL_DIR%/scripts to
> PATH to ensure I can just type ipython at the commandprompt. With these
> environment variables set, I can run ipython just fine at the cmd-prompt
> after running a windows installer from latest trunk.
>
> It looks like the ipython shell script in %PYTHON%/Scripts is copied to
> ipython.py on line 76 in ipython_win_post_install.py perhaps the other
> scripts should be given the same treatment.
>
> The last time I looked at using ipython from an egg in windows there was
> some weirdness. Caused by the ipython.exe file launching another process
> to run python and when you did ctrl-c only one of the processes where killed
> causing really strange behaviour. But this was several years ago.
>
> /J?rgen
>
>
>


From Alexander_Brown at uml.edu  Thu Sep  4 14:01:19 2008
From: Alexander_Brown at uml.edu (Alex Brown)
Date: Thu, 04 Sep 2008 14:01:19 -0400
Subject: [IPython-dev] ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe??
 [was: Re: Win32 IPython1?]
In-Reply-To: <db6b5ecc0808171443m79d47feei293ca67a55622d19@mail.gmail.com>
References: <48457029.8020401@uml.edu>	
	<db6b5ecc0806262219w424ae80eh39c54321c789a91c@mail.gmail.com>	
	<48659443.4050109@uml.edu>	
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>	
	<4865AB18.4040000@uml.edu>	
	<db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>	
	<cd7634ce0806281153h5ac76143ie825a0bfa2a41eca@mail.gmail.com>	
	<486EA0A3.9020307@uml.edu>	
	<db6b5ecc0808170351q54910b0fh72171d5ba6de7451@mail.gmail.com>	
	<48A89AF3.7090703@uml.edu>
	<db6b5ecc0808171443m79d47feei293ca67a55622d19@mail.gmail.com>
Message-ID: <48C0226F.4040900@uml.edu>

Hi - I've installed 
http://ipython.scipy.org/dist/testing/ipython-0.9.rc1.win32-setup.exe 
with the Enthought Python 2.5 Distribution (EPD,  
http://enthought.com/products/epd.php), DeinoMPI (http://mpi.deino.net), 
mpi4py (http://pypi.python.org/pypi/mpi4py) and VS03 as I described.  
VS03's compiler and libraries are required to build and install mpi4py 
for EPD, apparently because that's the original EPD build environment.   
Have not had a chance to run thorough tests but everything seems to 
build and operate correctly.

Thanks again -

Alex Brown <Alexander_Brown at uml.edu>
http://gis.uml.edu/abrown2




Fernando Perez wrote:
> On Sun, Aug 17, 2008 at 2:41 PM, Alex Brown <Alexander_Brown at uml.edu> wrote:
>   
>> Thanks!   I did get IPython working after your merge, with Python 2.5
>> (EPD).  There were several steps in the installation.  I am now going into
>> an IT rework phase to prepare my instructional/computational cluster for the
>> next semester (reloading disks with 50GB of software and data, including
>> IPython and MPI) and this should speed things up a great deal.  However,
>> with my MPI choice for this Win32 cluster (DeinoMPI) the mpi4py installation
>> requires specifically the 2003 version of the MS Visual Studio C++ compiler
>> to be present, so it's still going to be a pain in the neck.  But it will
>> work.  I will try this win32 installer and see if it speeds things up, or
>> shows any problems.
>>
>> Thanks again -
>>     
>
> No worries. And please do report back on the list.  The merge of
> ipython0/1 was a huge amount of work, but it should put us in a much
> better position to move the project forward.  So we'll be glad to hear
> your feedback.
>
> Regards,
>
> f
>
>   

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

From gael.varoquaux at normalesup.org  Thu Sep  4 15:18:20 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 4 Sep 2008 21:18:20 +0200
Subject: [IPython-dev]
	ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe??	[was: Re:
	Win32 IPython1?]
In-Reply-To: <48C0226F.4040900@uml.edu>
References: <48659443.4050109@uml.edu>
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>
	<4865AB18.4040000@uml.edu>
	<db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>
	<cd7634ce0806281153h5ac76143ie825a0bfa2a41eca@mail.gmail.com>
	<486EA0A3.9020307@uml.edu>
	<db6b5ecc0808170351q54910b0fh72171d5ba6de7451@mail.gmail.com>
	<48A89AF3.7090703@uml.edu>
	<db6b5ecc0808171443m79d47feei293ca67a55622d19@mail.gmail.com>
	<48C0226F.4040900@uml.edu>
Message-ID: <20080904191820.GD20691@phare.normalesup.org>

Hi Alex,

If there are things we can do on the EPD side to make your life easier,
don't hesitate mentioning them. There will be an EPD release real soon,
and we'd like it to make people's life easier.

Ga?l

On Thu, Sep 04, 2008 at 02:01:19PM -0400, Alex Brown wrote:
>    Hi - I've installed
>    [1]http://ipython.scipy.org/dist/testing/ipython-0.9.rc1.win32-setup.exe
>    with the Enthought Python 2.5 Distribution (EPD,
>    [2]http://enthought.com/products/epd.php), DeinoMPI
>    ([3]http://mpi.deino.net), mpi4py ([4]http://pypi.python.org/pypi/mpi4py)
>    and VS03 as I described.  VS03's compiler and libraries are required to
>    build and install mpi4py for EPD, apparently because that's the original
>    EPD build environment.   Have not had a chance to run thorough tests but
>    everything seems to build and operate correctly.

>    Thanks again -

>    Alex Brown [5]<Alexander_Brown at uml.edu>
>    [6]http://gis.uml.edu/abrown2

>    Fernando Perez wrote:

>  On Sun, Aug 17, 2008 at 2:41 PM, Alex Brown [7]<Alexander_Brown at uml.edu> wrote:


>  Thanks!   I did get IPython working after your merge, with Python 2.5
>  (EPD).  There were several steps in the installation.  I am now going into
>  an IT rework phase to prepare my instructional/computational cluster for the
>  next semester (reloading disks with 50GB of software and data, including
>  IPython and MPI) and this should speed things up a great deal.  However,
>  with my MPI choice for this Win32 cluster (DeinoMPI) the mpi4py installation
>  requires specifically the 2003 version of the MS Visual Studio C++ compiler
>  to be present, so it's still going to be a pain in the neck.  But it will
>  work.  I will try this win32 installer and see if it speeds things up, or
>  shows any problems.

>  Thanks again -


>  No worries. And please do report back on the list.  The merge of
>  ipython0/1 was a huge amount of work, but it should put us in a much
>  better position to move the project forward.  So we'll be glad to hear
>  your feedback.

>  Regards,

>  f



> References

>    Visible links
>    1. http://ipython.scipy.org/dist/testing/ipython-0.9.rc1.win32-setup.exe
>    2. http://enthought.com/products/epd.php
>    3. http://mpi.deino.net/
>    4. http://pypi.python.org/pypi/mpi4py
>    5. mailto:Alexander_Brown at uml.edu
>    6. http://gis.uml.edu/abrown2
>    7. mailto:Alexander_Brown at uml.edu

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



From Alexander_Brown at uml.edu  Thu Sep  4 17:37:55 2008
From: Alexander_Brown at uml.edu (Alex Brown)
Date: Thu, 04 Sep 2008 17:37:55 -0400
Subject: [IPython-dev] ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe??
 [was: Re: Win32 IPython1?]
In-Reply-To: <48C03CBE.4070301@enthought.com>
References: <48659443.4050109@uml.edu>
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>
	<4865AB18.4040000@uml.edu>
	<db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>
	<cd7634ce0806281153h5ac76143ie825a0bfa2a41eca@mail.gmail.com>
	<486EA0A3.9020307@uml.edu>
	<db6b5ecc0808170351q54910b0fh72171d5ba6de7451@mail.gmail.com>
	<48A89AF3.7090703@uml.edu>
	<db6b5ecc0808171443m79d47feei293ca67a55622d19@mail.gmail.com>
	<48C0226F.4040900@uml.edu>
	<20080904191820.GD20691@phare.normalesup.org>
	<48C03CBE.4070301@enthought.com>
Message-ID: <48C05533.9050901@uml.edu>

Dave Peterson wrote:
> I was under the impression that Windows users could use the MinGW 
> compiler to build things compatible with the MSVC we used to build 
> EPD.   That's one of the reasons we ship it.
>
You are almost certainly correct - I did not have time to deal with this 
in detail and found that VS03 worked well enough.  MinGW would be better.
> I don't know anything about DeinoMPI, but it seems to be the MPI libs 
> that mpi4py will link against, right?  If so, you should be able to 
> build mpi4py against a MSVC version of these by making sure to set 
> your distutils.cfg or pydistutils.cfg to define the compiler to use to 
> be mingw.   There are numerous threads on doing this on various 
> mailing lists, plus it is covered in the distutils docs.
Hm - you are probably right - DeinoMPI is the culprit, not EPD.  The 
build error was from mpi4py of course.  I will look into the cfgs.
> BTW, in the future, an EPD install will contain an appropriately setup 
> distutils.cfg to default the compiler to the mingw we ship in EPD.   
> IIRC, it is already in the current beta -- EPD with Py2.5 v4.0.30001 
> Beta 1.
>
>
> -- Dave
>
Great - thanks again.  I'm not inexperienced with software make/build 
tools in other contexts but Python internals and distribution tools are 
still somewhat new to me;  I appreciate everyone's interest.

- Alex

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

From ellisonbg.net at gmail.com  Thu Sep  4 22:37:48 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 19:37:48 -0700
Subject: [IPython-dev] Fully working Win32 installer
Message-ID: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>

Hi,

Today I spent the day fixing and updating the post install script that
gets run by the Win32 installer.  Now we have:

* All ipython related script have .bat and .py versions, so they can
be run from the command line
* The main one (including iptest, ipcontroler and ipengine) have Start
Menu shortcuts

This commit has not been merged into trunk yet as I would like it
reviewed.  Could someone have a look at that in my trunk-dev branch?
Thanks!  Also, I still need to test all of this on Vista (that is
next!).

But, the manual post install script win32_manual_post_install.py is
probably completely broken.  I know Fernando has been considering
getting rid of this and I now agree, as no Windows gurus have stepped
up to the plate on this.

So, let's put it up for a vote:  shall we delete win32_manual_post_install.py?

+1

Cheers,

Brian


From ellisonbg.net at gmail.com  Thu Sep  4 23:51:27 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 20:51:27 -0700
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <48C0A73D.5020905@aero.iitb.ac.in>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
	<48C0A73D.5020905@aero.iitb.ac.in>
Message-ID: <6ce0ac130809042051k43c9d86fo8ab5be544306fbc9@mail.gmail.com>

> When you ask collaborators to review, do you mean they go over all the
> revisions listed here manually?
>
> https://code.launchpad.net/~ellisonbg/ipython/trunk-dev

In launchpad, when you propose a branch for merging and request
review, a new page gets created for that code review:

https://code.launchpad.net/~ellisonbg/ipython/trunk-dev/+merge/933

This page only lists the commits that have not been reviewed _and_
merged.  This page is a click or two away from the page you asked
about.

> Or is there something I'm missing.  I'm trying to get an idea of the patch,
> review, merge workflow you guys are using.  Do you use Guido's code review
> tool?  Can you?

I don't think you can use Guido's tools yet with bzr+launchpad.  But,
Launchpad's new code review system seems to do a lot of what we need -
and with 0 setup.

The workflow that are are playing around with is this:

1.  All devs do their work in branches*
2.  When they have a set of commits ready for review, they propose
that the branch be merged.
3.  People use Launchpad to review
4.  When all is OK, the merge happens.

*Sometimes the branches are short lived feature branches that go away
after the merge.  Other branches (like my trunk-dev branch above) is
long lived.  It is where I do much of my ipython development.  These
branches have a continual merge proposal.  The merge page shows the
latest commits that are ready to go and people can review just the
un-merged ones.

We have lots of fine tuning to figure out, but overall I am liking it.
 Compared to cvs/svn, this is lightyears ahead.

Brian
>
> cheers,
> prabhu
>
>


From prabhu at aero.iitb.ac.in  Thu Sep  4 23:27:57 2008
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Fri, 05 Sep 2008 08:57:57 +0530
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
Message-ID: <48C0A73D.5020905@aero.iitb.ac.in>

Hi Brian,

Just a quick off-topic question.

Brian Granger wrote:
> This commit has not been merged into trunk yet as I would like it
> reviewed.  Could someone have a look at that in my trunk-dev branch?
> Thanks!  Also, I still need to test all of this on Vista (that is
> next!).

When you ask collaborators to review, do you mean they go over all the 
revisions listed here manually?

https://code.launchpad.net/~ellisonbg/ipython/trunk-dev

Or is there something I'm missing.  I'm trying to get an idea of the 
patch, review, merge workflow you guys are using.  Do you use Guido's 
code review tool?  Can you?

cheers,
prabhu



From prabhu at aero.iitb.ac.in  Fri Sep  5 00:09:35 2008
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Fri, 05 Sep 2008 09:39:35 +0530
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <6ce0ac130809042051k43c9d86fo8ab5be544306fbc9@mail.gmail.com>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>	
	<48C0A73D.5020905@aero.iitb.ac.in>
	<6ce0ac130809042051k43c9d86fo8ab5be544306fbc9@mail.gmail.com>
Message-ID: <48C0B0FF.3040603@aero.iitb.ac.in>

Brian Granger wrote:
> In launchpad, when you propose a branch for merging and request
> review, a new page gets created for that code review:
> 
> https://code.launchpad.net/~ellisonbg/ipython/trunk-dev/+merge/933
> 
> This page only lists the commits that have not been reviewed _and_
> merged.  This page is a click or two away from the page you asked
> about.

Yes, I saw that link too.

>> Or is there something I'm missing.  I'm trying to get an idea of the patch,
>> review, merge workflow you guys are using.  Do you use Guido's code review
>> tool?  Can you?
> 
> I don't think you can use Guido's tools yet with bzr+launchpad.  But,
> Launchpad's new code review system seems to do a lot of what we need -
> and with 0 setup.
> 
> The workflow that are are playing around with is this:
> 
> 1.  All devs do their work in branches*
> 2.  When they have a set of commits ready for review, they propose
> that the branch be merged.
> 3.  People use Launchpad to review
> 4.  When all is OK, the merge happens.

Thanks for the clarifications.

If someone rejected 1128 you'd make 1129 and they'd review that, and 
once that is OK a merge will be done by the person in charge of the 
mainline.  Nice.

> *Sometimes the branches are short lived feature branches that go away
> after the merge.  Other branches (like my trunk-dev branch above) is
> long lived.  It is where I do much of my ipython development.  These
> branches have a continual merge proposal.  The merge page shows the
> latest commits that are ready to go and people can review just the
> un-merged ones.
> 
> We have lots of fine tuning to figure out, but overall I am liking it.
>  Compared to cvs/svn, this is lightyears ahead.

Yes, it seems really nice.  Thanks.

cheers,
prabhu



From ellisonbg.net at gmail.com  Fri Sep  5 00:46:07 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 21:46:07 -0700
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <48C0B0FF.3040603@aero.iitb.ac.in>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
	<48C0A73D.5020905@aero.iitb.ac.in>
	<6ce0ac130809042051k43c9d86fo8ab5be544306fbc9@mail.gmail.com>
	<48C0B0FF.3040603@aero.iitb.ac.in>
Message-ID: <6ce0ac130809042146k5762e9d6x4545c4c7e37fe091@mail.gmail.com>

>>> Or is there something I'm missing.  I'm trying to get an idea of the
>>> patch,
>>> review, merge workflow you guys are using.  Do you use Guido's code
>>> review
>>> tool?  Can you?
>>
>> I don't think you can use Guido's tools yet with bzr+launchpad.  But,
>> Launchpad's new code review system seems to do a lot of what we need -
>> and with 0 setup.
>>
>> The workflow that are are playing around with is this:
>>
>> 1.  All devs do their work in branches*
>> 2.  When they have a set of commits ready for review, they propose
>> that the branch be merged.
>> 3.  People use Launchpad to review
>> 4.  When all is OK, the merge happens.
>
> Thanks for the clarifications.
>
> If someone rejected 1128 you'd make 1129 and they'd review that, and once
> that is OK a merge will be done by the person in charge of the mainline.
>  Nice.

Yep, that is the idea.  But, for now, anyone can actually do the final
merge.  We haven't gotten formal enough with our workflow yet that we
have a gatekeeper that does the final merges.  We are probably too
small to make that worth it.

Cheers,

Brian


From ellisonbg.net at gmail.com  Fri Sep  5 01:05:36 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 4 Sep 2008 22:05:36 -0700
Subject: [IPython-dev] Important: notes on testing
Message-ID: <6ce0ac130809042205jb927f51gc74397c01ed5cb3c@mail.gmail.com>

Hi,

Recently we have been having some really weird test problems.  Things
like random failures, and things like "unhandled error in Deferred"
things.

In getting ready for the 0.9 release I tracked some of these down.
Most of the problems are coming from the test module:

IPython.frontend.test_frontendbase

I found a couple of major problems with this:

1.  The method test_error_callback_added_to_execute raises an
exception in a Deferred but then doesn't register an errback to catch
the error.  This is a super nasty thing to do.  When this is done,
unittest says that the test passes.  There are no exceptions raised
(just an unhandled error in a deferred) and all asserts are satisfied.
 For now I have just put a @skip decorator on this method so that it
gets skipped, but this needs to be fixed.

2.  Any test class that uses Twisted things (like Deferreds, etc.)
need to be a subclass of trial.unittest.TestCase.  This is super
important and the tests in IPython.frontend.test_frontendbase don't
have this.  This class is needed so that Twisted and nose can handle
all the subtleties of the Twisted reactor in the tests.  So, if your
tests use Deferreds in any way, use trial.unittest.TestCase!!!

3.  Any test that has one or more Deferreds in it _MUST_ properly
chain those Deferreds together and return the last one!!!  Here is an
example:

def test_foo(self):
  d = do_something_deferred()
  d.addCallback(lambda _: do_something_else())
  d.addCallback(lambda r: self.assertEquals(r,10))
  return d

If you don't return d, disaster will result, and debugging the problem
is typically impossible.  Why is this needed you ask?  When you get a
Deferred, you don't yet have a result, and thus can't actually do the
assert.  Twisted gets the Deferred that you return and watches it
until it fires and the tests are actually run - then it knows the test
is done and the test suite can move on.  If you don't return the
Deferred, Twisted thinks the test is done before the Deferred fires.
The cleanup method then fires, possibly killing the stuff that is
doing the work of the test.  It basically ties everything up in a big
knot.

So.....

Barry and Gael, can you clean up IPython.frontend.test_frontendbase so
that it adheres to these things?  Also, can you look over other code
you have commited over the last few months to see if we have any more
of these types of problems?

Also, anyone writing Twisted/Deferred using tests, please make sure
you understand these things.  Feel free to ask Min or I questions
about this and also, check out the many tests in IPython.kernel.tests
that do these things.

The good news is that all our tests are passing!

Cheers,

Brian


From ariciputi at pito.com  Fri Sep  5 03:07:29 2008
From: ariciputi at pito.com (Andrea Riciputi)
Date: Fri, 5 Sep 2008 09:07:29 +0200
Subject: [IPython-dev] IPython+libedit
Message-ID: <B2CC5501-AFD4-47F9-9700-4EB88C58B424@pito.com>

Hi all,
I've been working for a couple of days on the issues regarding IPython  
and the libedit shipped with OSX Leopard, and I've got a little more  
insight in it. I'd like to share this stuff with you in order to get a  
better understanding of these issues and to make IPython working  
better under OSX.

Although I can understand that installing the readline egg build by  
Ludwig Schwardt makes everything work smoothly, I think making IPython  
behaves correctly also using libedit could be a plus not only to all  
OSX users, but to any other user using that library as well.

So let me start listing the issues I've found so far:

1) Multi-line commands in history get scrambled when recalled at the  
prompt
2) Autoindentation doesn't work
3) Key binding initialization it's not correct

Regarding multi-line commands, the problem is due to the way libedit  
write out its history file. Despite readline, libedit encodes all the  
white spaces, newline and tabs before writing the history (look at  
libedit source code and to man strvis under OSX). As a consequence a  
muli-line command in the libedit history looked like this:

for\040i\040in\040[1,2,3]:\012\040\040print\040i

appearing as a single line command (it's a single entry in the  
history). However, a simple patch to iplib.py fixes this:

% diff -u IPython/iplib.py.orig IPython/iplib.py
--- IPython/iplib.py.orig       2008-09-03 12:12:11.000000000 +0200
+++ IPython/iplib.py    2008-09-04 10:12:05.000000000 +0200
@@ -2170,7 +2174,7 @@
        if line.strip():
            if continue_prompt:
                self.input_hist_raw[-1] += '%s\n' % line
-                if self.has_readline: # and some config option is set?
+                if self.has_readline and not  
self.readline.uses_libedit: # and some config option is set?
                    try:
                        histlen =  
self.readline.get_current_history_length()
                        if histlen > 1:

Regarding the autoindentation problem seems more rooted in libedit/ 
readline compatibility, and haven't been able to fix it yet. Infact it  
turns out that using libedit the _ip.IP.readline_startup_hook function  
(i.e. pre_readline()) is never called. I can't understand why, but if  
someone could give me so hints on how to test the readline module,  
I'll try to investagete it a little further.

Finally, I need your help again regarding the readline/libedit key- 
binging. It seems that (when libedit are present) readline key-binding  
are set despite the if-clause in init_readline() (in ipylib.py):

          if not readline.uses_libedit:
               for rlcommand in self.rc.readline_parse_and_bind:
                   readline.parse_and_bind(rlcommand)

Which file is actually read between ipythonrc and ipy_user_conf.py to  
configure IPython? And where in the code the rc Struct is initialized?

I'm sorry for this long email, but I hope someone could help me to  
make IPython a little better.

TIA,
Andrea


From vivian at vdesmedt.com  Fri Sep  5 13:00:26 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Fri, 05 Sep 2008 19:00:26 +0200
Subject: [IPython-dev] Documenting the recent editor sync extension
In-Reply-To: <db6b5ecc0808271153y13efd7bch4a84cd6db6238a15@mail.gmail.com>
References: <db6b5ecc0808261228p2b9e0f45ncfb21b109b5c6803@mail.gmail.com>	
	<48B56C89.2060409@vdesmedt.com>
	<db6b5ecc0808271153y13efd7bch4a84cd6db6238a15@mail.gmail.com>
Message-ID: <48C165AA.2000304@vdesmedt.com>

Hi Fernando,

I have add some end user documentation in the ipy_syncrhonize_with 
module and to the docs\source\interactive\extension_api.txt doc.

I also merge the latest modification of the trunk into they 
synchronize_with branch.

It should be now ready for review ;-)

Regards,
Vivian.



From ellisonbg.net at gmail.com  Fri Sep  5 18:02:07 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 15:02:07 -0700
Subject: [IPython-dev] Failing tests in test_process.py
Message-ID: <6ce0ac130809051502u6a50c084g7acf57ed608df3aa@mail.gmail.com>

Gael,

I am going through and running the test suite on various platforms.
Overall everything looks good.

But I am seeing a set of errors in frontend/tests/test_process.py

When run using iptest on Vista, but only when iptest is called through
its link in the Start Menu (you will have to build a .exe installer
and install IPython that way), test_kill and test_capture_out both
give an error related to permissions.  The odd thing is that these
tests pass when iptest is called from the command line.  PITA.

For now, I have simply put @skip decorators on these tests.  I will
file a bug report on these as well.  Can you look into this at some
point?

Cheers,

Brian


From ellisonbg.net at gmail.com  Fri Sep  5 18:28:34 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 15:28:34 -0700
Subject: [IPython-dev] Ville's branch to be merged before the 0.9 release?
Message-ID: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>

Hi,

I saw Ville's branch was recently marked as "ready for review."  I am
more than willing to do a review, but I just wanted to see these
changes need to go into trunk before the 0.9 release.  Unless they are
bug fixes to already existing features, I would prefer to have these
wait until after 0.9 is released.  I am just finishing up a huge round
of testing on various platforms+OS combinations and I don't want to
have to repeat all this for this release.

Cheers,

Brian


From vivainio at gmail.com  Fri Sep  5 18:49:43 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 6 Sep 2008 01:49:43 +0300
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
Message-ID: <46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>

On Sat, Sep 6, 2008 at 1:28 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> I saw Ville's branch was recently marked as "ready for review."  I am
> more than willing to do a review, but I just wanted to see these
> changes need to go into trunk before the 0.9 release.  Unless they are
> bug fixes to already existing features, I would prefer to have these
> wait until after 0.9 is released.  I am just finishing up a huge round
> of testing on various platforms+OS combinations and I don't want to
> have to repeat all this for this release.

There is only one bugfix, and it's for a rarely used feature (%cpaste
& pasted_block variable), so there's no need to put it in before 0.9.

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


From ellisonbg.net at gmail.com  Fri Sep  5 18:52:09 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 15:52:09 -0700
Subject: [IPython-dev] Merging my branch
Message-ID: <6ce0ac130809051552w338174d7t3a7489224b9dfbc7@mail.gmail.com>

Hi,

I just finished fixing a bunch of bugs (working in my trunk-dev)
branch.  In terms of code + features + test suite, I think things are
looking good for the 0.9 release.  I have tested everything on OS X,
XP and Vista.  Have not done any Linux tests though.

I am going to switch gears and begin working on updating docs.

I would like to merge all the commits in my branch and am willing to
wait for code review....but I do want to do the merge sooner rather
than later, so people can try out trunk, or maybe we can even put out
an rc2 on Monday before the release on Wed.

Here is my plan:  I am going to merge my branch sometime after 9 pm
PDT on Sat (tomorrow).  If anyone wants to review things before that,
that would be great.

PS - thanks to _everyone_ in all the work that has gone into this
release.  It is really cool to be able to run our test suite using
iptest and see over 400 passing tests on all the major platforms!!!
Weeeee!

Cheers,

Brian


From ellisonbg.net at gmail.com  Fri Sep  5 19:41:37 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 16:41:37 -0700
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
Message-ID: <6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>

Is there anything major other than this bug fix?  I am all for bug
fixes going in.

Brian

On Fri, Sep 5, 2008 at 3:49 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sat, Sep 6, 2008 at 1:28 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>
>> I saw Ville's branch was recently marked as "ready for review."  I am
>> more than willing to do a review, but I just wanted to see these
>> changes need to go into trunk before the 0.9 release.  Unless they are
>> bug fixes to already existing features, I would prefer to have these
>> wait until after 0.9 is released.  I am just finishing up a huge round
>> of testing on various platforms+OS combinations and I don't want to
>> have to repeat all this for this release.
>
> There is only one bugfix, and it's for a rarely used feature (%cpaste
> & pasted_block variable), so there's no need to put it in before 0.9.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>


From vivainio at gmail.com  Fri Sep  5 19:58:32 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 6 Sep 2008 02:58:32 +0300
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
Message-ID: <46cb515a0809051658u2d7ca4adv5a3945a86a272044@mail.gmail.com>

On Sat, Sep 6, 2008 at 2:41 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Is there anything major other than this bug fix?  I am all for bug
> fixes going in.

Nothing really major, just "-r" (repeat) arg for %cpaste and some
ipy_leo stuff. Just let it wait 'till after 0.9.

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


From ellisonbg.net at gmail.com  Fri Sep  5 19:59:05 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 16:59:05 -0700
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <46cb515a0809051658u2d7ca4adv5a3945a86a272044@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
	<46cb515a0809051658u2d7ca4adv5a3945a86a272044@mail.gmail.com>
Message-ID: <6ce0ac130809051659s3a0f0570g782c43be67f49fd@mail.gmail.com>

OK, sounds good.

Brian

On Fri, Sep 5, 2008 at 4:58 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sat, Sep 6, 2008 at 2:41 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Is there anything major other than this bug fix?  I am all for bug
>> fixes going in.
>
> Nothing really major, just "-r" (repeat) arg for %cpaste and some
> ipy_leo stuff. Just let it wait 'till after 0.9.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>


From gael.varoquaux at normalesup.org  Fri Sep  5 21:42:26 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 6 Sep 2008 03:42:26 +0200
Subject: [IPython-dev] setupegg.py
Message-ID: <20080906014226.GI22673@phare.normalesup.org>

Setupegg is failing under windows because it is trying
os.environ['HOME']. I wonder if the lines monkey-patching sys.path to add
~/usr/local should be in this file anyhow. It seems to me they only cover
a personnal use ;).

Ga?l


From ellisonbg.net at gmail.com  Sat Sep  6 00:46:13 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 21:46:13 -0700
Subject: [IPython-dev] setupegg.py
In-Reply-To: <20080906014226.GI22673@phare.normalesup.org>
References: <20080906014226.GI22673@phare.normalesup.org>
Message-ID: <6ce0ac130809052146sa7816e0ye57eeba157b3ec2b@mail.gmail.com>

> Setupegg is failing under windows because it is trying
> os.environ['HOME']. I wonder if the lines monkey-patching sys.path to add
> ~/usr/local should be in this file anyhow. It seems to me they only cover
> a personnal use ;).

Both of these things sound like bugs.  Can you remove them and test on
Windows+Linux?  Good catch!

Cheers,

Brian

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


From gael.varoquaux at normalesup.org  Sat Sep  6 00:52:20 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 6 Sep 2008 06:52:20 +0200
Subject: [IPython-dev] setupegg.py
In-Reply-To: <6ce0ac130809052146sa7816e0ye57eeba157b3ec2b@mail.gmail.com>
References: <20080906014226.GI22673@phare.normalesup.org>
	<6ce0ac130809052146sa7816e0ye57eeba157b3ec2b@mail.gmail.com>
Message-ID: <20080906045220.GJ22673@phare.normalesup.org>

On Fri, Sep 05, 2008 at 09:46:13PM -0700, Brian Granger wrote:
> > Setupegg is failing under windows because it is trying
> > os.environ['HOME']. I wonder if the lines monkey-patching sys.path to add
> > ~/usr/local should be in this file anyhow. It seems to me they only cover
> > a personnal use ;).

> Both of these things sound like bugs.  Can you remove them and test on
> Windows+Linux? 

Done on my branch.

> Good catch!

Testing ++. Especially in situations that you are not familiar with,
that's where you find the bugs.

I am not sure I will be able to get the testing done under Vista. I have
been fighting both with XP and Vista for a good chunk of the afternoon
and the evening to try and get ipython installed and the tests running.

I can't get the tests running under XP. The error is incomprehensible (
importing IPython fails, but only in the tests), this might be due to a
screwed up box). I would be interested in testing your branch, but I
can't get bzr working under XP.

Still trying for Vista, but I gave up for XP.

Ga?l


From ellisonbg.net at gmail.com  Sat Sep  6 01:00:44 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 5 Sep 2008 22:00:44 -0700
Subject: [IPython-dev] setupegg.py
In-Reply-To: <20080906045220.GJ22673@phare.normalesup.org>
References: <20080906014226.GI22673@phare.normalesup.org>
	<6ce0ac130809052146sa7816e0ye57eeba157b3ec2b@mail.gmail.com>
	<20080906045220.GJ22673@phare.normalesup.org>
Message-ID: <6ce0ac130809052200x14e25ac2o2377ab182fd4eb55@mail.gmail.com>

I have fixed lots of bugs on Windows in my branch - these are not yet
merged into trunk.  You probably won't have success on Windows without
my fixes.  What do you think we should do?  Should I mege my stuff
into trunk and then you can merge those things into your branch and
continue testing?  I am a little afraid to merge my fixes directly
into your branch (instead of trunk) as they also need to go into
trunk.

Brian

On Fri, Sep 5, 2008 at 9:52 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Fri, Sep 05, 2008 at 09:46:13PM -0700, Brian Granger wrote:
>> > Setupegg is failing under windows because it is trying
>> > os.environ['HOME']. I wonder if the lines monkey-patching sys.path to add
>> > ~/usr/local should be in this file anyhow. It seems to me they only cover
>> > a personnal use ;).
>
>> Both of these things sound like bugs.  Can you remove them and test on
>> Windows+Linux?
>
> Done on my branch.
>
>> Good catch!
>
> Testing ++. Especially in situations that you are not familiar with,
> that's where you find the bugs.
>
> I am not sure I will be able to get the testing done under Vista. I have
> been fighting both with XP and Vista for a good chunk of the afternoon
> and the evening to try and get ipython installed and the tests running.
>
> I can't get the tests running under XP. The error is incomprehensible (
> importing IPython fails, but only in the tests), this might be due to a
> screwed up box). I would be interested in testing your branch, but I
> can't get bzr working under XP.
>
> Still trying for Vista, but I gave up for XP.
>
> Ga?l
>


From gael.varoquaux at normalesup.org  Sat Sep  6 01:02:53 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 6 Sep 2008 07:02:53 +0200
Subject: [IPython-dev] setupegg.py
In-Reply-To: <6ce0ac130809052200x14e25ac2o2377ab182fd4eb55@mail.gmail.com>
References: <20080906014226.GI22673@phare.normalesup.org>
	<6ce0ac130809052146sa7816e0ye57eeba157b3ec2b@mail.gmail.com>
	<20080906045220.GJ22673@phare.normalesup.org>
	<6ce0ac130809052200x14e25ac2o2377ab182fd4eb55@mail.gmail.com>
Message-ID: <20080906050253.GK22673@phare.normalesup.org>

On Fri, Sep 05, 2008 at 10:00:44PM -0700, Brian Granger wrote:
> I have fixed lots of bugs on Windows in my branch - these are not yet
> merged into trunk.  You probably won't have success on Windows without
> my fixes.  What do you think we should do?  Should I mege my stuff
> into trunk and then you can merge those things into your branch and
> continue testing?  I am a little afraid to merge my fixes directly
> into your branch (instead of trunk) as they also need to go into
> trunk.

Yeah, I had the same line of thought. I think you should merge. I'll try
to test. Worst case I'll try to test Monday (I can't test this week end,
as I don't have a windows VM on my laptop).

Ga?l


From fperez.net at gmail.com  Sat Sep  6 02:15:31 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 5 Sep 2008 23:15:31 -0700
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <6ce0ac130809051659s3a0f0570g782c43be67f49fd@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
	<46cb515a0809051658u2d7ca4adv5a3945a86a272044@mail.gmail.com>
	<6ce0ac130809051659s3a0f0570g782c43be67f49fd@mail.gmail.com>
Message-ID: <db6b5ecc0809052315j67c75155n5f6dbbdefebf1a33@mail.gmail.com>

On Fri, Sep 5, 2008 at 4:59 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> OK, sounds good.

Thanks a lot for all the flurry of work from all; I  do have a bit of
net access right now but I'm going to crash, and will likely only have
very limited net touches until Tuesday.

Please CC me explicitly if something needs a quick answer from me
between now and then. Otherwise I'll do my best to scan the list when
I have a chance, but will otherwise lay low.

Cheers,

f


From ellisonbg.net at gmail.com  Sat Sep  6 03:32:28 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sat, 6 Sep 2008 00:32:28 -0700
Subject: [IPython-dev] My branch is merged
Message-ID: <6ce0ac130809060032p75297692hc89906458406f05e@mail.gmail.com>

Hi,

Gael reviewed by branch this afternoon and not having my commits in
trunk (mainly the bug fixes on Win32) was causing him grief.

Thus, I have merged my branch into trunk.

After chatting with Gael today,  I think it is important to get his
branch merged before 0.9 as is contains quite a number of bug fixes
for the new wx frontend...so, here is the plan:

* Gael is finishing testing and squashing bugs in his branch related
to the new wx frontend

* When this is done, we will do a quick code review of Gael's branch

* We will merge Gael's branch into trunk and then we should be ready
to go for the 0.9 release.

* We will need to do some testing of everything once all this is done (on M/T).

Cheers,

Brian


From gael.varoquaux at normalesup.org  Sat Sep  6 12:55:36 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 6 Sep 2008 18:55:36 +0200
Subject: [IPython-dev] My branch is merged
In-Reply-To: <6ce0ac130809060032p75297692hc89906458406f05e@mail.gmail.com>
References: <6ce0ac130809060032p75297692hc89906458406f05e@mail.gmail.com>
Message-ID: <20080906165536.GA12886@phare.normalesup.org>

On Sat, Sep 06, 2008 at 12:32:28AM -0700, Brian Granger wrote:
> After chatting with Gael today,  I think it is important to get his
> branch merged before 0.9 as is contains quite a number of bug fixes
> for the new wx frontend...so, here is the plan:

> * Gael is finishing testing and squashing bugs in his branch related
> to the new wx frontend

I can't test it under vista until Monday, I'd really like to test it
under vista. I have done smoke testing on XP, but I couldn't run
the test suite properly. I'll try to do this on Monday too.

> * When this is done, we will do a quick code review of Gael's branch

> * We will merge Gael's branch into trunk and then we should be ready
> to go for the 0.9 release.

> * We will need to do some testing of everything once all this is done (on M/T).
Right, I am tracking trunk in my branch, so I should capture any changes,
but I'd still like people to test. In particular, if you feel like
playing with "ipythonx", which brings up a very simple terminal-like app
using the wx frontend. This can expose bugs both in the frontend, and in
the IPython1 interpreter, as this is using the interpreter under the
hood.

Cheers,

Ga?l


From vivainio at gmail.com  Mon Sep  8 09:21:22 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 8 Sep 2008 16:21:22 +0300
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
Message-ID: <46cb515a0809080621r475cf035m17d812903984134f@mail.gmail.com>

On Fri, Sep 5, 2008 at 5:37 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> So, let's put it up for a vote:  shall we delete win32_manual_post_install.py?
>
> +1

+1


From gael.varoquaux at normalesup.org  Mon Sep  8 15:56:35 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 8 Sep 2008 21:56:35 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
Message-ID: <20080908195635.GB15536@phare.normalesup.org>

Hey Laurent,

You had a bug under Vista with the wx frontend. Hopefuly thisis fixed
now. Can you pull my branch and give it a test?

Vista changed the semantics of a GUI event loop Yeild (it seems a Yield
is now a SafeYield, ie no user interaction is possible in a Yield).
That's nasty, and I had to do a nasty hack to go around it.

On a side note, I am lucky-enough to be currently working at Enthought,
where we have VMs of multiple operating systems, and I can develop and
test under multiple operating systems. In a couple of weeks this will no
longer be the case. I am a bit worried about this, given how the fine
details of wx vary from an OS to another.

Ga?l


From laurent.dufrechou at gmail.com  Mon Sep  8 16:42:12 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Mon, 8 Sep 2008 22:42:12 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080908195635.GB15536@phare.normalesup.org>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
Message-ID: <48c58e35.0407560a.6882.4bbb@mx.google.com>

Hi gael,

It is not working at all :(
To be sure:
I've created a new directory.
Then:
bzr branch lp:~gael-varoquaux/ipython/ipython-sync-frontend
then launched ipythonx

Is it tagged 0.9beta3 ? If yes then...there still an issue.
Moreover, the exception don't display anything... Is it working on your
side?
I've also tried with administrator privileges just in case...
I'm doinf this:
!ls (tried with !dir too)
Do I need to do eggsetup develop?????


I've worked a little on your widget:

What I want is something that looks like to my widget (white on black) + one
line next to other + prompt2:

1/I've seen that there is global value in underling classes that are used to
change color of input/output and error.
I couldn't manage to change them in the top level class. I'm not used to
vars like
Class toto:
	MYVAR = ...
MYVAR is global to the class but is constant?
If yes can you change them to make me change the aspect of the widget?

2/Next I don't want a '\n' between each prompt (in and out too).
I've tried different things
#self.write('\n', refresh=False)
self.write('', refresh=False)

But it seems that the '\n' are used by the underlying classes to handle the
line state, or something like this, so don't where to change this witout
breaking your widget. Any idea?

3/ I've seen a little threading? Problem while pushing a lot of time
a+enter...

In [98]: 
a
In [99]: 

In [100]: a

Out[100]: 1

Oups, look at line 99.(Had the same problem before too with my widget)

4/? -> display long text, is there a way to overload help display to add
input from user?
I've done this in my widget, I display 10lines then used have to push 'space
to display 10 next lines or 'q' to quit.

5/ You widget seems to react strangely (well not at all in fact ) but
somewhat frustrating:

IN: while(1):
	&
	print "coucou"
and your widget don't execute the lines like ioython0 because he detects an
error! It is REALLY frustrating because sometimes you don't see the error
and would like to execute the line to make ipython shell show you the bug :)

Can we change this behavior?

6/ import htt+'tab' don't work at all, in fact completion on import don't
works.

Sorry it's a lot of questions, that shows you I'm trying to use it ;)

Cheers,
Laurent





From gael.varoquaux at normalesup.org  Mon Sep  8 17:13:20 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 8 Sep 2008 23:13:20 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48c58e35.0407560a.6882.4bbb@mx.google.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
Message-ID: <20080908211320.GD15536@phare.normalesup.org>

On Mon, Sep 08, 2008 at 10:42:12PM +0200, Laurent Dufrechou wrote:
> It is not working at all :(
> To be sure:
> I've created a new directory.
> Then:
> bzr branch lp:~gael-varoquaux/ipython/ipython-sync-frontend
> then launched ipythonx

> Is it tagged 0.9beta3 ? If yes then...there still an issue.

I don't think you are picking up the new code. You need to install it.
Just copying (or branching) the files and starting the ipythonx program
won't be enough.

> Moreover, the exception don't display anything... Is it working on your
> side?

If there is an exception in the display code, then indeed it won't
display. It is a pain, but that's the price to pay for having the display
code running in the same event loop as the code raising the eceptions.

> Do I need to do eggsetup develop?????

That's should get you going.

> I've worked a little on your widget:

> What I want is something that looks like to my widget (white on black) + one
> line next to other + prompt2:

> 1/I've seen that there is global value in underling classes that are used to
> change color of input/output and error.
> I couldn't manage to change them in the top level class. I'm not used to
> vars like
> Class toto:
> 	MYVAR = ...
> MYVAR is global to the class but is constant?

MYVAR is just a class variable. You can change it either by subclassing
the class and changing it in the subclass, or simply be assiging a value
to it:

t = toto()
t.MYVAR = "A different value"

> If yes can you change them to make me change the aspect of the widget?

I haven't focussed yet on this aspect. The code currently will not make
it easy for you to do that. This is low priority for me: I first want to
get the main frontend API right, and the event handling right. I need to
understand these problems well to get the right overall architecture
first.

> 2/Next I don't want a '\n' between each prompt (in and out too).
> I've tried different things
> #self.write('\n', refresh=False)
> self.write('', refresh=False)

> But it seems that the '\n' are used by the underlying classes to handle the
> line state, or something like this, so don't where to change this witout
> breaking your widget. Any idea?

The '\n' is necessary for the separation between input and output, indeed
at the frontend level. There sometimes is too much vertical space, but I
have not found a way to have less without breaking formatting on one
platform or the other. The stems from the horrible mix of the different
values for carriage return under the different platforms ('\n', '\r',
'\n\r') and with or without an UNicode build of Wx. I spent a while on
this, and then decided I would live with the extra vertical space.
Anybody is welcome to have a go at trying to fix this. Plan for having
many VMs.

> 3/ I've seen a little threading? Problem while pushing a lot of time
> a+enter...

> In [98]: 
> a
> In [99]: 

> In [100]: a

> Out[100]: 1

> Oups, look at line 99.(Had the same problem before too with my widget)

Well, that's not really a threading problem, that's just a buffering of
the input problem. I could indeed maybe be smarter with input buffering,
but that would make things more fragile. Right now the rule is that if
you enter keys outside of a prompt, the behavior is undefined.

> 4/? -> display long text, is there a way to overload help display to add
> input from user?
> I've done this in my widget, I display 10lines then used have to push 'space
> to display 10 next lines or 'q' to quit.

I don't plan on adding such a feature right now. Even in the long run, I
am not too sure it is a good idea. User interaction with the mainloop
while the user is executing code should be restricted as much as
possible. This is fragile, and will always be. You can use page up and
page down to navigate this output.

> 5/ You widget seems to react strangely (well not at all in fact ) but
> somewhat frustrating:

> IN: while(1):
> 	&
> 	print "coucou"
> and your widget don't execute the lines like ioython0 because he detects an
> error! It is REALLY frustrating because sometimes you don't see the error
> and would like to execute the line to make ipython shell show you the bug :)

> Can we change this behavior?

That should be fixed. Make sure you have the latest version.

> 6/ import htt+'tab' don't work at all, in fact completion on import don't
> works.

Indeed. That's interesting. Ipython0's complete method does not complete
imports:

In [1]: __IP.complete('import htt')
Out[1]: []

Anybody has a clue why, and what could be done to fix that?

Cheers,

Ga?l





From laurent.dufrechou at gmail.com  Mon Sep  8 17:47:52 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Mon, 8 Sep 2008 23:47:52 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080908211150.GC15536@phare.normalesup.org>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
Message-ID: <48c59d9a.09c5660a.40df.24d0@mx.google.com>

> > 6/ import htt+'tab' don't work at all, in fact completion on import
> don't
> > works.
> 
> Indeed. That's interesting. Ipython0's complete method does not
> complete
> imports:
> 
> In [1]: __IP.complete('import htt')
> Out[1]: []
> 
> Anybody has a clue why, and what could be done to fix that?
> 

Hum really strange, must be a regression, quite sure it was working before
on my widget an now it is no more working too ...

Done eggsetup.py develop, now got ipython rc1.
Still got the same behavior... Got python 2.5.1 here and wxpython 2.8.8.1.
U sure it works on your vista?



From gael.varoquaux at normalesup.org  Mon Sep  8 18:11:28 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 9 Sep 2008 00:11:28 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48c59d9a.09c5660a.40df.24d0@mx.google.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
Message-ID: <20080908221128.GE15536@phare.normalesup.org>

On Mon, Sep 08, 2008 at 11:47:52PM +0200, Laurent Dufrechou wrote:
> Done eggsetup.py develop, now got ipython rc1.
> Still got the same behavior... Got python 2.5.1 here and wxpython 2.8.8.1.
> U sure it works on your vista?

Everything I have tested works on vista here. Can you give me steps to
reproduce the problem, please. I may be missing something.

Ga?l


From gael.varoquaux at normalesup.org  Mon Sep  8 18:49:18 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 9 Sep 2008 00:49:18 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48c5a84d.02a1660a.60b5.6c89@mx.google.com>
References: <20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
Message-ID: <20080908224918.GF15536@phare.normalesup.org>

On Tue, Sep 09, 2008 at 12:33:18AM +0200, Laurent Dufr?chou wrote:
> Here is a session taht is failling,
> I launch your script inside wx directory, push !dir or !ls then 'enter'
> Then the gui seems freezed, next when I push another time 'enter' got the
> exception you can see.
> It does not react like this on your system?

Hum. No. I have the same wx version as you do.

Are you sure you have installed the latest version of my branch? This
sounds so much like a bug I fixed this morning.

Can do

import IPython
print IPython.__file__

and in the directory of that module, 

bzr log -r -3..

And send me the output.

Cheers,

Ga?l


From laurent.dufrechou at gmail.com  Mon Sep  8 18:54:09 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Tue, 9 Sep 2008 00:54:09 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080908224918.GF15536@phare.normalesup.org>
References: <20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
	<20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
	<20080908224918.GF15536@phare.normalesup.org>
Message-ID: <48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>

In [1]: import IPython

In [2]: print IP
IPython     ipythonx.py

In [2]: print IPython.__file__
c:\users\ldufrechou\desktop\ipython-dev\gael\ipython-sync-frontend\IPython\_
_init__.pyc

In [4]: wx.__version__
Out[4]: '2.8.8.1'

C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-frontend\IPython\f
rontend\wx>bzr log -r -3
------------------------------------------------------------
revno: 1134
committer: gvaroquaux <gvaroquaux at gvaroquaux-desktop>
branch nick: ipython-frontend
timestamp: Mon 2008-09-08 14:38:39 -0500
message:
  Apply the same hack used for raw_input to system calls.

...
Perhaps we could do some print >>sys.__stdout__,"" ????


> -----Message d'origine-----
> De?: Gael Varoquaux [mailto:gael.varoquaux at normalesup.org]
> Envoy??: mardi 9 septembre 2008 00:49
> ??: Laurent Dufr?chou
> Cc?: 'IPython Development list'
> Objet?: Re: shell command for ipython1 frontend
> 
> On Tue, Sep 09, 2008 at 12:33:18AM +0200, Laurent Dufr?chou wrote:
> > Here is a session taht is failling,
> > I launch your script inside wx directory, push !dir or !ls then
> 'enter'
> > Then the gui seems freezed, next when I push another time 'enter' got
> the
> > exception you can see.
> > It does not react like this on your system?
> 
> Hum. No. I have the same wx version as you do.
> 
> Are you sure you have installed the latest version of my branch? This
> sounds so much like a bug I fixed this morning.
> 
> Can do
> 
> import IPython
> print IPython.__file__
> 
> and in the directory of that module,
> 
> bzr log -r -3..
> 
> And send me the output.
> 
> Cheers,
> 
> Ga?l



From gael.varoquaux at normalesup.org  Mon Sep  8 18:59:33 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 9 Sep 2008 00:59:33 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>
References: <20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
	<20080908224918.GF15536@phare.normalesup.org>
	<48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>
Message-ID: <20080908225933.GA20348@phare.normalesup.org>

On Tue, Sep 09, 2008 at 12:54:09AM +0200, Laurent Dufr?chou wrote:
> C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-frontend\IPython\f
> rontend\wx>bzr log -r -3
> ------------------------------------------------------------
> revno: 1134
> committer: gvaroquaux <gvaroquaux at gvaroquaux-desktop>
> branch nick: ipython-frontend
> timestamp: Mon 2008-09-08 14:38:39 -0500
> message:
>   Apply the same hack used for raw_input to system calls.

Darn!!! I don't get it. I don't understand why I can't repoduce your bug.

> ...
> Perhaps we could do some print >>sys.__stdout__,"" ????


Maybe, but that's going to be tedious. Especially since all the output
gets captured during command execution. So you actually tend not to have
any debug output.

Could you pull again from my brnach (no need to redo a develop) and try
running something with a raw_input, eg "raw_input()".

Cheers,

Ga?l


From laurent.dufrechou at gmail.com  Mon Sep  8 19:01:44 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Tue, 9 Sep 2008 01:01:44 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080908225933.GA20348@phare.normalesup.org>
References: <20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
	<20080908224918.GF15536@phare.normalesup.org>
	<48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>
	<20080908225933.GA20348@phare.normalesup.org>
Message-ID: <48c5aeea.25e2660a.5cb7.2e68@mx.google.com>

Hey!

In [1]: raw_input()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-frontend\IPython\f
rontend\wx\<string> in <module>()

TypeError: raw_input() takes exactly 2 arguments (1 given)

Do you want to skype? (should be faster)

> -----Message d'origine-----
> De?: Gael Varoquaux [mailto:gael.varoquaux at normalesup.org]
> Envoy??: mardi 9 septembre 2008 01:00
> ??: Laurent Dufr?chou
> Cc?: 'IPython Development list'
> Objet?: Re: shell command for ipython1 frontend
> 
> On Tue, Sep 09, 2008 at 12:54:09AM +0200, Laurent Dufr?chou wrote:
> > C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-
> frontend\IPython\f
> > rontend\wx>bzr log -r -3
> > ------------------------------------------------------------
> > revno: 1134
> > committer: gvaroquaux <gvaroquaux at gvaroquaux-desktop>
> > branch nick: ipython-frontend
> > timestamp: Mon 2008-09-08 14:38:39 -0500
> > message:
> >   Apply the same hack used for raw_input to system calls.
> 
> Darn!!! I don't get it. I don't understand why I can't repoduce your
> bug.
> 
> > ...
> > Perhaps we could do some print >>sys.__stdout__,"" ????
> 
> 
> Maybe, but that's going to be tedious. Especially since all the output
> gets captured during command execution. So you actually tend not to
> have
> any debug output.
> 
> Could you pull again from my brnach (no need to redo a develop) and try
> running something with a raw_input, eg "raw_input()".
> 
> Cheers,
> 
> Ga?l



From laurent.dufrechou at gmail.com  Mon Sep  8 19:02:54 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Tue, 9 Sep 2008 01:02:54 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080908225933.GA20348@phare.normalesup.org>
References: <20080902224832.GA12777@phare.normalesup.org>
	<7ced318f0809021615i1f5c5461m38d27a0c09c25247@mail.gmail.com>
	<20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
	<20080908224918.GF15536@phare.normalesup.org>
	<48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>
	<20080908225933.GA20348@phare.normalesup.org>
Message-ID: <48c5af2f.0ab6660a.3512.7fea@mx.google.com>

In [2]: raw_input("toto")
toto
Out[2]: u''

In [3]:

> -----Message d'origine-----
> De?: Gael Varoquaux [mailto:gael.varoquaux at normalesup.org]
> Envoy??: mardi 9 septembre 2008 01:00
> ??: Laurent Dufr?chou
> Cc?: 'IPython Development list'
> Objet?: Re: shell command for ipython1 frontend
> 
> On Tue, Sep 09, 2008 at 12:54:09AM +0200, Laurent Dufr?chou wrote:
> > C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-
> frontend\IPython\f
> > rontend\wx>bzr log -r -3
> > ------------------------------------------------------------
> > revno: 1134
> > committer: gvaroquaux <gvaroquaux at gvaroquaux-desktop>
> > branch nick: ipython-frontend
> > timestamp: Mon 2008-09-08 14:38:39 -0500
> > message:
> >   Apply the same hack used for raw_input to system calls.
> 
> Darn!!! I don't get it. I don't understand why I can't repoduce your
> bug.
> 
> > ...
> > Perhaps we could do some print >>sys.__stdout__,"" ????
> 
> 
> Maybe, but that's going to be tedious. Especially since all the output
> gets captured during command execution. So you actually tend not to
> have
> any debug output.
> 
> Could you pull again from my brnach (no need to redo a develop) and try
> running something with a raw_input, eg "raw_input()".
> 
> Cheers,
> 
> Ga?l



From gael.varoquaux at normalesup.org  Mon Sep  8 19:03:15 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 9 Sep 2008 01:03:15 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48c5aeea.25e2660a.5cb7.2e68@mx.google.com>
References: <20080908195635.GB15536@phare.normalesup.org>
	<48c58e35.0407560a.6882.4bbb@mx.google.com>
	<20080908211150.GC15536@phare.normalesup.org>
	<48c59d9a.09c5660a.40df.24d0@mx.google.com>
	<20080908221128.GE15536@phare.normalesup.org>
	<48c5a84d.02a1660a.60b5.6c89@mx.google.com>
	<20080908224918.GF15536@phare.normalesup.org>
	<48c5ad23.0c07560a.0ca7.ffffb09a@mx.google.com>
	<20080908225933.GA20348@phare.normalesup.org>
	<48c5aeea.25e2660a.5cb7.2e68@mx.google.com>
Message-ID: <20080908230315.GG15536@phare.normalesup.org>

On Tue, Sep 09, 2008 at 01:01:44AM +0200, Laurent Dufr?chou wrote:
> In [1]: raw_input()
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)

> C:\Users\ldufrechou\Desktop\Ipython-dev\gael\ipython-sync-frontend\IPython\f
> rontend\wx\<string> in <module>()

> TypeError: raw_input() takes exactly 2 arguments (1 given)

> Do you want to skype? (should be faster)

Yup, good idea.

Ga?l


From fperez.net at gmail.com  Wed Sep 10 18:08:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 10 Sep 2008 15:08:40 -0700
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
Message-ID: <db6b5ecc0809101508l4fa029b3l5f1f38ee82422668@mail.gmail.com>

On Thu, Sep 4, 2008 at 7:37 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:


> But, the manual post install script win32_manual_post_install.py is
> probably completely broken.  I know Fernando has been considering
> getting rid of this and I now agree, as no Windows gurus have stepped
> up to the plate on this.
>
> So, let's put it up for a vote:  shall we delete win32_manual_post_install.py?
>
> +1

+1, since I won't be fixing it :)

Cheers,

f


From ellisonbg.net at gmail.com  Wed Sep 10 19:12:02 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 10 Sep 2008 16:12:02 -0700
Subject: [IPython-dev] Fully working Win32 installer
In-Reply-To: <db6b5ecc0809101508l4fa029b3l5f1f38ee82422668@mail.gmail.com>
References: <6ce0ac130809041937qdcb3486k403f77d167dace43@mail.gmail.com>
	<db6b5ecc0809101508l4fa029b3l5f1f38ee82422668@mail.gmail.com>
Message-ID: <6ce0ac130809101612x75260ae1xcfe42fad693242a@mail.gmail.com>

Just removed it.

Brian

On Wed, Sep 10, 2008 at 3:08 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Sep 4, 2008 at 7:37 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>
>
>> But, the manual post install script win32_manual_post_install.py is
>> probably completely broken.  I know Fernando has been considering
>> getting rid of this and I now agree, as no Windows gurus have stepped
>> up to the plate on this.
>>
>> So, let's put it up for a vote:  shall we delete win32_manual_post_install.py?
>>
>> +1
>
> +1, since I won't be fixing it :)
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Wed Sep 10 19:16:17 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 10 Sep 2008 16:16:17 -0700
Subject: [IPython-dev] doc structure fixes
Message-ID: <db6b5ecc0809101616j7888ff2fu8e1ad857840a2a95@mail.gmail.com>

Hi all,

I've just pushed a trivial change to my branch that changes how the
docs are generated.  I'd like review/comments on it before merging,
but to save you the time of building the docs with this in place, I've
put the result up here:

https://cirl.berkeley.edu/fperez/tmp/ipython-docs/

If there are no objections, I'd like to merge this soon so Brian can
move ahead with doc updates for installation, which seems to be the
last remaining big item before we push 0.9 out.

Cheers,

f


From fperez.net at gmail.com  Wed Sep 10 19:24:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 10 Sep 2008 16:24:00 -0700
Subject: [IPython-dev] 0.9 - last call
Message-ID: <db6b5ecc0809101624g5da3a805wb3c91cf457263ed4@mail.gmail.com>

Hi all,

it seems we're almost done with work for 0.9.  As Brian just said
earlier, many thanks to all who've worked so hard to make this
possible!  It's great also to see we now really have a true team,
where different people pitch in with different skills to assemble
what's growing into a really fun and exciting project in many more
directions than any one of us could do alone.

So, this is the last call for changes before we push 0.9 out.  It
appears we're done with changes that are reasonable to include right
now code-wise, and Brian is about to start an update of a few docs
that really need fixing before the actual release files are cut.
Unless someone complains, we should only finish touching docs for the
next day or two, and target Friday for the actual release (give or
take a day as usual :).

Any objections?

Cheers,

f


From fperez.net at gmail.com  Thu Sep 11 13:25:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 11 Sep 2008 10:25:55 -0700
Subject: [IPython-dev] doc structure fixes
In-Reply-To: <6ce0ac130809102048g4b63a5b2le8aec7684ca8f801@mail.gmail.com>
References: <db6b5ecc0809101616j7888ff2fu8e1ad857840a2a95@mail.gmail.com>
	<6ce0ac130809102048g4b63a5b2le8aec7684ca8f801@mail.gmail.com>
Message-ID: <db6b5ecc0809111025l4c97fd62g858f8e5adb259b7a@mail.gmail.com>

On Wed, Sep 10, 2008 at 8:48 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Looks great.  I say go ahead and merge when are ready.  I will start
> working on the docs tomorrow morning early.

Thanks for the review, I've pushed it.  Pound away at the docs!

Cheers,

f


From fperez.net at gmail.com  Thu Sep 11 17:55:43 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 11 Sep 2008 14:55:43 -0700
Subject: [IPython-dev] Fwd: IPython documentation
In-Reply-To: <1220814816.14155.6.camel@localhost.localdomain>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
	<9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com>
	<1213295536.10989.27.camel@localhost.localdomain>
	<db6b5ecc0806171717k510310b9obc47491314f8c4c4@mail.gmail.com>
	<1220814816.14155.6.camel@localhost.localdomain>
Message-ID: <db6b5ecc0809111455i341f8bfaqae133d04ac9839dd@mail.gmail.com>

Hey Pauli,

I'm replying with your full message below so it goes to the list,
since I think this is both interesting and exciting for others as
well.

I don't have right now the bandwidth to test it, but I'm very happy to
see pydocweb moving in this direction.  Ultimately I think this is
moving exactly in the direction I'd like to see tools for managing
*all* docs for an open source project.  I hope after we settle down a
bit with the giant code/architecture merges we're tackling right now,
we can look into this for ipython.

Alternatively, if anyone likes this kind of work and would like to
play with getting it up and running for the ipython docs and codebase,
it would make a great contribution to the project :)

Cheers,

f

On Sun, Sep 7, 2008 at 12:13 PM, Pauli Virtanen <pav at iki.fi> wrote:
> Hi Fernando,
>
> On ti, 2008-06-17 at 17:17 -0700, Fernando Perez wrote:
> [clip: Re: Sphinx documents in the scipy doc editor web app]
>> But if you do want to contribute on any of this (which sooner or later
>> ipython, numpy, scipy, matplotlib, proably sympy, etc will want), I
>> think that a solution that integrates with the version control backend
>> naturally would be the easiest.  I don't know how you guys implemented
>> it, but I'd think that simply:
>>
>> - producing one wiki page per .rst/.txt in a given directory
>> - generating one local commit into a special branch per user-visible
>> change
>>
>> should be enough, no?  Then, the editors can merge/reject those
>> individual commits into the trunk.
>
> Part of this is now implemented:
>
> - Pydocweb can now extract Sphinx documentation pages, and generate
>  patches against them.
>
> toctree:: is handled, but most other Sphinx cross-references do not work
> properly yet. Also, the CSS probably needs some tweaking, as the
> rendered document pages look quite fugly :)
>
> If you want to check it out, here's the branch
>
>        https://code.launchpad.net/~pauli-virtanen/scipy/pydocweb
>
> There's a sample configuration for IPython in there, and steps in taking
> it into use are explained in README.txt.
>
>        Pauli
>
>
>


From fperez.net at gmail.com  Thu Sep 11 18:55:24 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 11 Sep 2008 15:55:24 -0700
Subject: [IPython-dev] Docs: authorship listing
Message-ID: <db6b5ecc0809111555p2a11ef3l59212bd0196dc142@mail.gmail.com>

Howdy,

we were considering to just list the authorship of the docs similarly
to the rest of the project as "ipython dev team".  This will give us a
simple policy as more and more people add contributions, since that
can be easily listed in the history/credits section of the docs, while
having 20 authors and 50 contributors on the title page gets a bit
silly (particle physics papers with 1000 authors not withstanding :)

Hopefully this highlights further how this has become a truly collective effort.

If nobody opposes, we'll just do that for the final 0.9, for which now
only doc fixes are going in.

Cheers,

f


From fperez.net at gmail.com  Sun Sep 14 05:08:04 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 02:08:04 -0700
Subject: [IPython-dev] IPython 0.9 is out!
Message-ID: <db6b5ecc0809140208y7667c8f8t4417a6f63f106c64@mail.gmail.com>

Hi all,

the IPython development team is very happy to announce the release of
version 0.9 of IPython.  You can download it from the usual location:

http://ipython.scipy.org/dist/

What's in here? Glad you asked...

*A project renewed*

This release is a special one, because it marks the unification of all
the work done on what used to be known as the 'IPython1' series, and
it brings together the contributions of a much larger team.  Over the
course of the last few years, we had kept two separate lines of
IPython development: one (the 0.8.x series) had all the command-line
functionality many of you use, and the other (known as 'IPython1') had
facilities for distributed and parallel computing, as well as a
cleaner design we hoped would eventually replace the previous series.
Over time it became clear that we'd all be better served by merging
the two codebases, and gradually blending all the excellent ideas of
the ipython1 work into the main trunk, so all users of IPython could
benefit from the new facilities while keeping everything they already
like about IPython and use regularly.

So this release marks the first step of this unification.  There is no
more IPython1 separate project: if you install IPython 0.9, you get
everything that used to be called 'ipython1', with only very minor API
changes.  The manual details most changes in this release:

http://ipython.scipy.org/doc/rel-0.9/html/changes.html#release-0-9

There are still important changes in the pipeline that will help make
the new facilities easier to use, as well as growing them in terms of
features and functionality.  But we wanted to put this version out as
soon as possible, in trying to keep a cycle with more frequent
releases now that our team has grown and that we all share a unified
front where we can all focus our development effort.

It is important to note that this means that IPython is now a larger
codebase, but for the basic terminal-only functionality, its
dependencies remain the same as always: the standard Python library
(and pyreadline under windows).  You only need extra dependencies
(mainly Twisted & friends) if you intend to use its distributed
computing facilities, much like before you'd only need Wx or Qt if you
wanted to use its GUI integration.  The core of IPython will remain as
a python-only, standard-library-based project as long as we can manage
to do it, and we don't see any changes on this front happening any
time soon.


*Highlights*

Please see the changes linked above for the full details; in brief:

- Full merge of the distributed/parallel code known as 'ipython1' into
the project.
- New integrated docs, using Sphinx and the utilities developed by
Matplotlib for their docs.
- New testing system that uses nose and tests not only pure python
code but also IPython's unique extensions.  As of this release we have
about 415 tests, and now *all* new code is required to have proper
tests before being accepted. A new script, 'iptest', runs the whole
test suite (use it as 'iptest -vv' for more detailed output).
- New focus on the GUI shells.  A new WX frontend has been developed
(ipythonx) that can serve as a full "ipython widget" for plugging into
WX apps.  The existing iptyhon-wx app will be updated to use this
machinery.  A native Cocoa (OSX) widget has also been developed.
- Improvements to synchronization with Windows editors.
- Cleaner interfaces for high-level distributed work (task, map, etc.)
- Proper security model for distributed work, using Twisted's foolscap
(http://foolscap.lothar.com/trac).  We welcome reviews, criticism and
improvements on the security front, where none of us is a real expert.


*A larger, stronger team*

Many people have contributed to this release, and we apologize in
advance if we've missed any of you either in this notice or in the
credits section of the manual.  Please *do* notify us of such
omissions, which we'll correct immediately.  In addition to the many
useful comments, bug reports, ideas, patches that many people
contributed, we'd like to highlight the work of some newcomers to the
IPython team who have either become regulars or who helped us with key
pieces of infrastructure for this release:

- Barry Wark: new work on all the frontend architecture and Cocoa shell.
- Gael Varoquaux: new work on all the frontend architecture and WX shell.
- Ondrej Certik: got all of our docs on the new Sphinx system.
- Stefan van der Walt: help with new config code.

This is in addition to the work of the regulars who've been
contributing to IPython for a while and who have also new code in this
release: Brian Granger, Min Ragan-Kelley, Ville Vainio, Laurent
Dufrechou, Vivian de Smedt, Robert Kern, Fernando Perez.  The full bzr
log for the project will show you the gory details of all the work
done by many.


*What next?*

We'll be merging new code soon, targeting the next (0.10) release in a
few months (2-3, time permitting).  We are now (after some growing
pains) firmly enjoying the benefits of a distributed version control
and hosting system (bzr & launchpad), with a strong emphasis on code
review, proper documentation and testing, to ensure that as the
project grows we can keep a robust and reliable base that is easy to
use by all.  Please let us know of any problems you may encounter.

Enjoy,

Fernando, on behalf of the IPython development team.


From fperez.net at gmail.com  Sun Sep 14 06:06:12 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 03:06:12 -0700
Subject: [IPython-dev] The road to 0.10
Message-ID: <db6b5ecc0809140306o1ceaf420ud7c01dd90b8bcc54@mail.gmail.com>

Hi all,

now that 0.9 is out, it woudl be great to start putting things in
place for a really good 0.10.  I suspect it will take us a release or
two to shake out all the things that just went in once we go into
wider use.

Some things that I think are high on the pipeline:

- Min's branch on the ipython daemon.  I think this is critical
functionality to have in early so we can beat on it.

- Our doc machinery.  Now that we have the great sphinx docs, we need
to set up proper API docs as well as auto-generate the magic docs, the
manpages, etc.  We have a bit too much manually duplicated info.

- Revisiting the discussion we put a bit on hold on
notifications/events.  A skype/phone chat would be great to have while
Gael is still on US timezones, even if only between Gael and Barry for
starters.  This is a tricky problem but I'm sure we can find a good
solution to it so all the various frontends can make as much code
reuse as possible.

- Better integration of Laurent's and Gael's WX codes.  This one may
be easier to think about once Gael is back in the same timezone as
Laurent :)


I think the first two can be done very early in the 0.10 cycle.  The
GUI work is also high-importance, but it will depend on how much we
all can work on that (it needs more people).

Obviously, we have a ton of open bugs on lp, so there's plenty to do :)

Cheers,

f


From nwagner at iam.uni-stuttgart.de  Sun Sep 14 10:26:51 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 14 Sep 2008 16:26:51 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
Message-ID: <web-111238254@uni-stuttgart.de>

Hi all,

I just installed ipython from source.
I found an incompatibility wrt python2.4

byte-compiling 
/usr/lib/python2.4/site-packages/IPython/config/config.py 
to config.pyc
   File 
"/usr/lib/python2.4/site-packages/IPython/config/config.py", 
line 49
     with raw(self):
            ^
SyntaxError: invalid syntax
byte-compiling 
/usr/lib/python2.4/site-packages/IPython/kernel/tests/test_contexts.py 
to test_contexts.pyc
   File 
"/usr/lib/python2.4/site-packages/IPython/kernel/tests/test_contexts.py", 
line 28
     with parallel as pr:
                 ^
SyntaxError: invalid syntax
byte-compiling 
/usr/lib/python2.4/site-packages/IPython/kernel/contexts.py 
to contexts.pyc
SyntaxError: ('future feature with_statement is not 
defined',)
byte-compiling 
/usr/lib/python2.4/site-packages/IPython/frontend/prefilterfrontend.py 
to prefilterfrontend.pyc
   File 
"/usr/lib/python2.4/site-packages/IPython/frontend/prefilterfrontend.py", 
line 207
     finally:
           ^
SyntaxError: invalid syntax
byte-compiling 
/usr/lib/python2.4/site-packages/IPython/frontend/linefrontendbase.py 
to linefrontendbase.pyc
   File 
"/usr/lib/python2.4/site-packages/IPython/frontend/linefrontendbase.py", 
line 192
     finally:
           ^
SyntaxError: invalid syntax
  
Nils


From ellisonbg.net at gmail.com  Sun Sep 14 11:52:06 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 08:52:06 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <web-111238254@uni-stuttgart.de>
References: <web-111238254@uni-stuttgart.de>
Message-ID: <6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>

Nils,

Sorry about this.  We will put out a bug fix release ASAP to address this.

Cheers,

Brian

On Sun, Sep 14, 2008 at 7:26 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> I just installed ipython from source.
> I found an incompatibility wrt python2.4
>
> byte-compiling
> /usr/lib/python2.4/site-packages/IPython/config/config.py
> to config.pyc
>   File
> "/usr/lib/python2.4/site-packages/IPython/config/config.py",
> line 49
>     with raw(self):
>            ^
> SyntaxError: invalid syntax
> byte-compiling
> /usr/lib/python2.4/site-packages/IPython/kernel/tests/test_contexts.py
> to test_contexts.pyc
>   File
> "/usr/lib/python2.4/site-packages/IPython/kernel/tests/test_contexts.py",
> line 28
>     with parallel as pr:
>                 ^
> SyntaxError: invalid syntax
> byte-compiling
> /usr/lib/python2.4/site-packages/IPython/kernel/contexts.py
> to contexts.pyc
> SyntaxError: ('future feature with_statement is not
> defined',)
> byte-compiling
> /usr/lib/python2.4/site-packages/IPython/frontend/prefilterfrontend.py
> to prefilterfrontend.pyc
>   File
> "/usr/lib/python2.4/site-packages/IPython/frontend/prefilterfrontend.py",
> line 207
>     finally:
>           ^
> SyntaxError: invalid syntax
> byte-compiling
> /usr/lib/python2.4/site-packages/IPython/frontend/linefrontendbase.py
> to linefrontendbase.pyc
>   File
> "/usr/lib/python2.4/site-packages/IPython/frontend/linefrontendbase.py",
> line 192
>     finally:
>           ^
> SyntaxError: invalid syntax
>
> Nils
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Sun Sep 14 12:58:33 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 14 Sep 2008 19:58:33 +0300
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
Message-ID: <46cb515a0809140958v3efe7e92x89ef36ce3d86c27b@mail.gmail.com>

On Sat, Sep 6, 2008 at 2:41 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Is there anything major other than this bug fix?  I am all for bug
> fixes going in.

Ok, Brian, care to take a look at the code in my trunk-dev now? I'll
add the entries for changes.txt once the stuff goes in.

You can ignore reviewing the stuff in ipy_leo.py, it's code that isn't
widely used yet.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From fperez.net at gmail.com  Sun Sep 14 15:41:18 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 12:41:18 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
Message-ID: <db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>

Hi Nils,

On Sun, Sep 14, 2008 at 8:52 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Nils,
>
> Sorry about this.  We will put out a bug fix release ASAP to address this.

Thanks for catching this, I'm sorry we missed it.  For all the testing
we did (we did, really :), we dropped the ball on 2.4 compatibility.

I'm working on the fix release right now.

BTW, it greatly annoys me that setuptools will happily build a broken egg:

byte-compiling build/bdist.linux-i686/egg/IPython/kernel/tests/test_contexts.py
to test_contexts.pyc
  File "build/bdist.linux-i686/egg/IPython/kernel/tests/test_contexts.py",
line 28
    with parallel as pr:
                ^
SyntaxError: invalid syntax

and it chugs along, so it's very easy to miss the above message in a
long flash of output.

At least the bdist_rpm commands have the decency of failing in this case:

RPM build errors:
    File not found:
/var/tmp/ipython-0.9-py24-buildroot/usr/lib/python2.4/site-packages/IPython/config/config.pyc
    File not found:
/var/tmp/ipython-0.9-py24-buildroot/usr/lib/python2.4/site-packages/IPython/frontend/linefrontendbase.pyc
    File not found:
/var/tmp/ipython-0.9-py24-buildroot/usr/lib/python2.4/site-packages/IPython/frontend/prefilterfrontend.pyc
    File not found:
/var/tmp/ipython-0.9-py24-buildroot/usr/lib/python2.4/site-packages/IPython/kernel/contexts.pyc
    File not found:
/var/tmp/ipython-0.9-py24-buildroot/usr/lib/python2.4/site-packages/IPython/kernel/tests/test_contexts.pyc
error: command 'rpmbuild' failed with exit status 1

(though the build still proceeds farther than it should).

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 14 15:42:45 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 21:42:45 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
	<db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
Message-ID: <20080914194245.GF12842@phare.normalesup.org>

On Sun, Sep 14, 2008 at 12:41:18PM -0700, Fernando Perez wrote:
> BTW, it greatly annoys me that setuptools will [...]

:).

Ga?l


From fperez.net at gmail.com  Sun Sep 14 15:48:06 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 12:48:06 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080914194245.GF12842@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
	<db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
	<20080914194245.GF12842@phare.normalesup.org>
Message-ID: <db6b5ecc0809141248l3ff37f7ey2d3c6b299365ab4e@mail.gmail.com>

On Sun, Sep 14, 2008 at 12:42 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 12:41:18PM -0700, Fernando Perez wrote:
>> BTW, it greatly annoys me that setuptools will [...]
>
> :).

Truth be told, this one is probably a distutils problem.  I think the
byte compilation step is performed by distutils and not by setuptools,
though I could be wrong.

The joys of python package distribution...

Cheers,

f


From jesus at aguillon.com  Sun Sep 14 16:09:25 2008
From: jesus at aguillon.com (Jesus Aguillon)
Date: Sun, 14 Sep 2008 13:09:25 -0700
Subject: [IPython-dev] IPython 0.9 is out!
Message-ID: <a52480020809141309l22ca114dqfa699e57284116c@mail.gmail.com>

Does this version include everything that is in 0.8.4?Thanks,
  <Jesus Aguillon>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080914/9230288f/attachment.html>

From fperez.net at gmail.com  Sun Sep 14 16:17:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 13:17:19 -0700
Subject: [IPython-dev] IPython 0.9 is out!
In-Reply-To: <a52480020809141309l22ca114dqfa699e57284116c@mail.gmail.com>
References: <a52480020809141309l22ca114dqfa699e57284116c@mail.gmail.com>
Message-ID: <db6b5ecc0809141317x3ae39e9fue1766c3b0ae98fd5@mail.gmail.com>

On Sun, Sep 14, 2008 at 1:09 PM, Jesus Aguillon <jesus at aguillon.com> wrote:
> Does this version include everything that is in 0.8.4?

Yes, it does.

But please hold off for 0.9.1 if you need to use it with python 2.4,
we let some 2.5-isms slip in by accident.

Cheers,

f


From ellisonbg.net at gmail.com  Sun Sep 14 17:07:55 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:07:55 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141248l3ff37f7ey2d3c6b299365ab4e@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
	<db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
	<20080914194245.GF12842@phare.normalesup.org>
	<db6b5ecc0809141248l3ff37f7ey2d3c6b299365ab4e@mail.gmail.com>
Message-ID: <6ce0ac130809141407s6eb903e7kab9c0989cd2c87f9@mail.gmail.com>

Fernando and others,

Do we want to make a new branch:

ipython-0.9

that we can use for bug fixes and releasing things in the 0.9.x series?

Obviously fixes going into these releases would also be rolled into
trunk, but, as people start doing 0.10 related things in trunk, I
don't want us to loose the ability to release bug fix releases in the
0.9.x series.

I can do this if people want - Just want to coordinate with Fernando

Brian


On Sun, Sep 14, 2008 at 12:48 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Sep 14, 2008 at 12:42 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Sun, Sep 14, 2008 at 12:41:18PM -0700, Fernando Perez wrote:
>>> BTW, it greatly annoys me that setuptools will [...]
>>
>> :).
>
> Truth be told, this one is probably a distutils problem.  I think the
> byte compilation step is performed by distutils and not by setuptools,
> though I could be wrong.
>
> The joys of python package distribution...
>
> Cheers,
>
> f
>


From gael.varoquaux at normalesup.org  Sun Sep 14 17:08:51 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 23:08:51 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141407s6eb903e7kab9c0989cd2c87f9@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
	<db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
	<20080914194245.GF12842@phare.normalesup.org>
	<db6b5ecc0809141248l3ff37f7ey2d3c6b299365ab4e@mail.gmail.com>
	<6ce0ac130809141407s6eb903e7kab9c0989cd2c87f9@mail.gmail.com>
Message-ID: <20080914210851.GJ12842@phare.normalesup.org>

On Sun, Sep 14, 2008 at 02:07:55PM -0700, Brian Granger wrote:
> ipython-0.9

> that we can use for bug fixes and releasing things in the 0.9.x series?

> Obviously fixes going into these releases would also be rolled into
> trunk, but, as people start doing 0.10 related things in trunk, I
> don't want us to loose the ability to release bug fix releases in the
> 0.9.x series.

It sounds to me as the right thing to do.

Ga?l


From fperez.net at gmail.com  Sun Sep 14 17:11:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:11:40 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080914210851.GJ12842@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809140852g4c95c919mc85c3ad5892e6529@mail.gmail.com>
	<db6b5ecc0809141241q5fc52332ydc39b287488f22b@mail.gmail.com>
	<20080914194245.GF12842@phare.normalesup.org>
	<db6b5ecc0809141248l3ff37f7ey2d3c6b299365ab4e@mail.gmail.com>
	<6ce0ac130809141407s6eb903e7kab9c0989cd2c87f9@mail.gmail.com>
	<20080914210851.GJ12842@phare.normalesup.org>
Message-ID: <db6b5ecc0809141411i19061f5fwc5d7e28e07ccde62@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:08 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 02:07:55PM -0700, Brian Granger wrote:
>> ipython-0.9
>
>> that we can use for bug fixes and releasing things in the 0.9.x series?
>
>> Obviously fixes going into these releases would also be rolled into
>> trunk, but, as people start doing 0.10 related things in trunk, I
>> don't want us to loose the ability to release bug fix releases in the
>> 0.9.x series.
>
> It sounds to me as the right thing to do.

It is, but I'm already in the middle of cleaning up the mess on my
trunk-dev branch.  I did tag the trunk with a 0.9 tag, so that could
be used for branching.  I'm going to push the changes up to the trunk
as soon as I can get this sorted out, I'd appreciate the help with
making the branch work.  These fixes need to go into trunk regardless,
so I'll make them there.

f


From fperez.net at gmail.com  Sun Sep 14 17:11:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:11:48 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <web-111238254@uni-stuttgart.de>
References: <web-111238254@uni-stuttgart.de>
Message-ID: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>

On Sun, Sep 14, 2008 at 7:26 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> I just installed ipython from source.
> I found an incompatibility wrt python2.4

This is turning into a minor nightmare.  There were LOTS more 2.5
things in there:

import _ast
import uuid

in the frontend code...

Please, from now on: let's always run the test suite with 2.4 and 2.5
always.  This is not fun.

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 14 17:17:51 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 23:17:51 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
Message-ID: <20080914211751.GA7927@phare.normalesup.org>

On Sun, Sep 14, 2008 at 02:11:48PM -0700, Fernando Perez wrote:
> This is turning into a minor nightmare.  There were LOTS more 2.5
> things in there:

> import _ast
> import uuid

> in the frontend code...

Well, let us just say that the frontend code is 2.5 only. Now how do we
enforce this on the packaging level? I don't know.

> Please, from now on: let's always run the test suite with 2.4 and 2.5
> always.  This is not fun.

Good point. We need to keep this in mind indeed.

Ga?l


From ellisonbg.net at gmail.com  Sun Sep 14 17:21:10 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:21:10 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
Message-ID: <6ce0ac130809141421u629ab8cfs7050e9f820f692c8@mail.gmail.com>

> This is turning into a minor nightmare.  There were LOTS more 2.5
> things in there:
>
> import _ast
> import uuid

We also have the guid module in IPython.externals.  I think it does
the same thing as uuid.  You could use that as an alternative to uuid.

Don't think there is an _ast substitute though.

Brian

> in the frontend code...
>
> Please, from now on: let's always run the test suite with 2.4 and 2.5
> always.  This is not fun.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Sun Sep 14 17:21:13 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:21:13 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080914211751.GA7927@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<20080914211751.GA7927@phare.normalesup.org>
Message-ID: <db6b5ecc0809141421w2786f1dfxe4ed95d0d16b1f12@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:17 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 02:11:48PM -0700, Fernando Perez wrote:
>> This is turning into a minor nightmare.  There were LOTS more 2.5
>> things in there:
>
>> import _ast
>> import uuid
>
>> in the frontend code...
>
> Well, let us just say that the frontend code is 2.5 only. Now how do we
> enforce this on the packaging level? I don't know.

I'd much rather keep 2.4 compatibility everywhere.  Making a project
with pieces that are version dependent is a recipe for disaster: the
packaging gets very brittle and the maintenance burden gets much, much
worse.

Until we find a compelling reason why we MUST use 2.5, we should make
our code work with 2.4.  There's still a lot of 2.4-only installations
out there, I assure you.  This week Brian, Min and I need to validate
all of ipython 0.9 on one such set of beasts, for example.  It's going
to be great...

Cheers,

f


From ellisonbg.net at gmail.com  Sun Sep 14 17:22:16 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:22:16 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141421w2786f1dfxe4ed95d0d16b1f12@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<20080914211751.GA7927@phare.normalesup.org>
	<db6b5ecc0809141421w2786f1dfxe4ed95d0d16b1f12@mail.gmail.com>
Message-ID: <6ce0ac130809141422s5495a0b6o4df462fe89958f33@mail.gmail.com>

>> Well, let us just say that the frontend code is 2.5 only. Now how do we
>> enforce this on the packaging level? I don't know.
>
> I'd much rather keep 2.4 compatibility everywhere.  Making a project
> with pieces that are version dependent is a recipe for disaster: the
> packaging gets very brittle and the maintenance burden gets much, much
> worse.

+1


From ellisonbg.net at gmail.com  Sun Sep 14 17:23:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:23:15 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
Message-ID: <6ce0ac130809141423t7be0e149uc7fbdcb35faed1ae@mail.gmail.com>

> Please, from now on: let's always run the test suite with 2.4 and 2.5
> always.  This is not fun.

That is for sure.  This is sort of my fault as I was informally
responsible for testing this release *everywhere* I could think of.
Unfortunately, the last time I did the 2.4 test was quite a while ago
and it escaped me this time around.

Brian

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


From fperez.net at gmail.com  Sun Sep 14 17:23:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:23:54 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141423t7be0e149uc7fbdcb35faed1ae@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<6ce0ac130809141423t7be0e149uc7fbdcb35faed1ae@mail.gmail.com>
Message-ID: <db6b5ecc0809141423k4b991359yd49474fb64d1c906@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:23 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Please, from now on: let's always run the test suite with 2.4 and 2.5
>> always.  This is not fun.
>
> That is for sure.  This is sort of my fault as I was informally
> responsible for testing this release *everywhere* I could think of.
> Unfortunately, the last time I did the 2.4 test was quite a while ago
> and it escaped me this time around.

No worries, I wasn't pointing fingers.  We all dropped the ball, we
all pick it up :)

Cheers,

f


From fperez.net at gmail.com  Sun Sep 14 17:25:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:25:33 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
Message-ID: <db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:11 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Sep 14, 2008 at 7:26 AM, Nils Wagner
> <nwagner at iam.uni-stuttgart.de> wrote:
>> Hi all,
>>
>> I just installed ipython from source.
>> I found an incompatibility wrt python2.4
>
> This is turning into a minor nightmare.  There were LOTS more 2.5
> things in there:

OK, I give up for now.  I'm going to take a break and see where I can
get later, but I may not be able to spend more time on this today.
The problem is that I deactivated the config stuff altogether to avoid
the with statement, thinking it wasn't yet used everywhere.  Well, it
is:

======================================================================
ERROR: Failure: exceptions.ImportError(No module named config.api)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/python-support/python2.4/nose/loader.py", line 360,
in loadTestsFromName
    module = self.importer.importFromPath(
  File "/var/lib/python-support/python2.4/nose/importer.py", line 39,
in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/var/lib/python-support/python2.4/nose/importer.py", line 84,
in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/home/fpa/usr/local/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/kernel/config/__init__.py",
line 21, in ?
    from IPython.config.api import ConfigObjManager
ImportError: No module named config.api


We can't run the kernel code on 2.4 at all in this manner...

I'm thinking of just pushing my current trunk-dev up to lp and see if
someone can pitch in quickly in case I can't continue.  I've fixed a
lot of the failures, but now it seems that deactivating the config
stuff isn't viable: we need to make it 2.4-compliant, like it or not.
Which means rewriting some of its with-using code to not use 'with' at
all.

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 14 17:26:28 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 23:26:28 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141421u629ab8cfs7050e9f820f692c8@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<6ce0ac130809141421u629ab8cfs7050e9f820f692c8@mail.gmail.com>
Message-ID: <20080914212628.GL12842@phare.normalesup.org>

On Sun, Sep 14, 2008 at 02:21:10PM -0700, Brian Granger wrote:
> > This is turning into a minor nightmare.  There were LOTS more 2.5
> > things in there:

> > import _ast
> > import uuid

> We also have the guid module in IPython.externals.  I think it does
> the same thing as uuid.  You could use that as an alternative to uuid.

> Don't think there is an _ast substitute though.

codeop, probably, for what we do with it. I'll give it a look quickly.

Ga?l


From gael.varoquaux at normalesup.org  Sun Sep 14 17:27:53 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 23:27:53 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
Message-ID: <20080914212753.GM12842@phare.normalesup.org>

On Sun, Sep 14, 2008 at 02:25:33PM -0700, Fernando Perez wrote:
> I'm thinking of just pushing my current trunk-dev up to lp and see if
> someone can pitch in quickly in case I can't continue.  I've fixed a
> lot of the failures, but now it seems that deactivating the config
> stuff isn't viable: we need to make it 2.4-compliant, like it or not.
> Which means rewriting some of its with-using code to not use 'with' at
> all.

I have only an hour to spend on this today, but I'll look at the frontend
part.

Ga?l


From ellisonbg.net at gmail.com  Sun Sep 14 17:29:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:29:12 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
Message-ID: <6ce0ac130809141429w3d48a279l77936e9756cadc5b@mail.gmail.com>

I have time to work on this now.  Push your trunk-dev and I will take
over.  I will keep the list posted on my progress.

Brian

On Sun, Sep 14, 2008 at 2:25 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Sep 14, 2008 at 2:11 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Sun, Sep 14, 2008 at 7:26 AM, Nils Wagner
>> <nwagner at iam.uni-stuttgart.de> wrote:
>>> Hi all,
>>>
>>> I just installed ipython from source.
>>> I found an incompatibility wrt python2.4
>>
>> This is turning into a minor nightmare.  There were LOTS more 2.5
>> things in there:
>
> OK, I give up for now.  I'm going to take a break and see where I can
> get later, but I may not be able to spend more time on this today.
> The problem is that I deactivated the config stuff altogether to avoid
> the with statement, thinking it wasn't yet used everywhere.  Well, it
> is:
>
> ======================================================================
> ERROR: Failure: exceptions.ImportError(No module named config.api)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/var/lib/python-support/python2.4/nose/loader.py", line 360,
> in loadTestsFromName
>    module = self.importer.importFromPath(
>  File "/var/lib/python-support/python2.4/nose/importer.py", line 39,
> in importFromPath
>    return self.importFromDir(dir_path, fqname)
>  File "/var/lib/python-support/python2.4/nose/importer.py", line 84,
> in importFromDir
>    mod = load_module(part_fqname, fh, filename, desc)
>  File "/home/fpa/usr/local/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/kernel/config/__init__.py",
> line 21, in ?
>    from IPython.config.api import ConfigObjManager
> ImportError: No module named config.api
>
>
> We can't run the kernel code on 2.4 at all in this manner...
>
> I'm thinking of just pushing my current trunk-dev up to lp and see if
> someone can pitch in quickly in case I can't continue.  I've fixed a
> lot of the failures, but now it seems that deactivating the config
> stuff isn't viable: we need to make it 2.4-compliant, like it or not.
> Which means rewriting some of its with-using code to not use 'with' at
> all.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Sun Sep 14 17:29:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:29:57 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080914212753.GM12842@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
Message-ID: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:27 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 02:25:33PM -0700, Fernando Perez wrote:
>> I'm thinking of just pushing my current trunk-dev up to lp and see if
>> someone can pitch in quickly in case I can't continue.  I've fixed a
>> lot of the failures, but now it seems that deactivating the config
>> stuff isn't viable: we need to make it 2.4-compliant, like it or not.
>> Which means rewriting some of its with-using code to not use 'with' at
>> all.
>
> I have only an hour to spend on this today, but I'll look at the frontend
> part.

I've just pushed my branch with the current fixes.  They're ugly but
they mostly work.  The frontend stuff at least doesn't explode on
testing.

The config code needs work, but I need to stop now.  I'll be back in a
bit, I hope.

Cheers,

f


From fperez.net at gmail.com  Sun Sep 14 17:30:16 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 14:30:16 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141429w3d48a279l77936e9756cadc5b@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<6ce0ac130809141429w3d48a279l77936e9756cadc5b@mail.gmail.com>
Message-ID: <db6b5ecc0809141430if67dd94k4465c38d268710c2@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:29 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I have time to work on this now.  Push your trunk-dev and I will take
> over.  I will keep the list posted on my progress.

It's up now.  Thanks..

f


From ellisonbg.net at gmail.com  Sun Sep 14 17:31:36 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 14:31:36 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
Message-ID: <6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>

> I've just pushed my branch with the current fixes.  They're ugly but
> they mostly work.  The frontend stuff at least doesn't explode on
> testing.
>
> The config code needs work, but I need to stop now.  I'll be back in a
> bit, I hope.

OK, thanks for getting this started.  I will be in touch.  Gael, I
will have my gmail open for chat if you want to reach me.

Brian

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


From gael.varoquaux at normalesup.org  Sun Sep 14 17:39:25 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 14 Sep 2008 23:39:25 +0200
Subject: [IPython-dev] Frontendbase and compile_ast.
Message-ID: <20080914213925.GO12842@phare.normalesup.org>

The frontend base class has a compile ast method. This introduces a
Python2.5 dependency, which we cannot have.

Currently no code in the frontends uses this method. I used it for a
while, but it turned out that the codeop module was more suited for
testing if the code was complete than compiling it to ast. I am strongly
thinking about removing this method for know.

Barry, you are the original author of this piece of code. I'd like your
input on this.

Cheers,

Ga?l


From gael.varoquaux at normalesup.org  Sun Sep 14 18:11:55 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 00:11:55 +0200
Subject: [IPython-dev] Frontendbase and compile_ast.
In-Reply-To: <20080914213925.GO12842@phare.normalesup.org>
References: <20080914213925.GO12842@phare.normalesup.org>
Message-ID: <20080914221155.GP12842@phare.normalesup.org>

On Sun, Sep 14, 2008 at 11:39:25PM +0200, Gael Varoquaux wrote:
> Currently no code in the frontends uses this method. I used it for a
> while, but it turned out that the codeop module was more suited for
> testing if the code was complete than compiling it to ast. I am strongly
> thinking about removing this method for know.

OK, I went ahead and replaced the is_complete method to avoid using the
compile_ast one. I stuck with the original behavior of not raise an
exception when the code was not valid, but I think it would be a better
behavior, as it allows to give feedback to the user on incorrect code.
This is what I do in the linefrontendbase is_complete's method.

Barry, what are your thoughts on that? You can take a peek at the new
version of is_complete in my branch.

Ga?l


From fperez.net at gmail.com  Sun Sep 14 19:34:39 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 16:34:39 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
Message-ID: <db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>

On Sun, Sep 14, 2008 at 2:31 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I've just pushed my branch with the current fixes.  They're ugly but
>> they mostly work.  The frontend stuff at least doesn't explode on
>> testing.
>>
>> The config code needs work, but I need to stop now.  I'll be back in a
>> bit, I hope.
>
> OK, thanks for getting this started.  I will be in touch.  Gael, I
> will have my gmail open for chat if you want to reach me.

What's the status?  I could spend an hour or so trying to clean up the
config code for 2.4.  This week is going to be mad for me, so it would
be good to fix this quickly, and let the cleaner solutions trickle in
later...

Cheers,

f


From ellisonbg.net at gmail.com  Sun Sep 14 19:43:42 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 16:43:42 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
Message-ID: <6ce0ac130809141643k533c70fclfc592176d830bda6@mail.gmail.com>

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1004.1.6?file_id=config-20080606193721-phlcq9ug5m39wm0m-1



On Sun, Sep 14, 2008 at 4:34 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Sep 14, 2008 at 2:31 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> I've just pushed my branch with the current fixes.  They're ugly but
>>> they mostly work.  The frontend stuff at least doesn't explode on
>>> testing.
>>>
>>> The config code needs work, but I need to stop now.  I'll be back in a
>>> bit, I hope.
>>
>> OK, thanks for getting this started.  I will be in touch.  Gael, I
>> will have my gmail open for chat if you want to reach me.
>
> What's the status?  I could spend an hour or so trying to clean up the
> config code for 2.4.  This week is going to be mad for me, so it would
> be good to fix this quickly, and let the cleaner solutions trickle in
> later...
>
> Cheers,
>
> f
>


From gael.varoquaux at normalesup.org  Sun Sep 14 21:31:12 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 03:31:12 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
Message-ID: <20080915013112.GA21560@phare.normalesup.org>

On Sun, Sep 14, 2008 at 04:34:39PM -0700, Fernando Perez wrote:
> What's the status?  I could spend an hour or so trying to clean up the
> config code for 2.4.  This week is going to be mad for me, so it would
> be good to fix this quickly, and let the cleaner solutions trickle in
> later...

Frontend code is cleaned up. This has been check in my branch. Brian was
centralizing the fixes in his branch. I am not too sure what the status
is there.

Ga?l


From fperez.net at gmail.com  Sun Sep 14 22:15:05 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 19:15:05 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080915013112.GA21560@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
Message-ID: <db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>

On Sun, Sep 14, 2008 at 6:31 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 04:34:39PM -0700, Fernando Perez wrote:
>> What's the status?  I could spend an hour or so trying to clean up the
>> config code for 2.4.  This week is going to be mad for me, so it would
>> be good to fix this quickly, and let the cleaner solutions trickle in
>> later...
>
> Frontend code is cleaned up. This has been check in my branch. Brian was
> centralizing the fixes in his branch. I am not too sure what the status
> is there.

I just merged his code, where he'd merged from you.  I've added some
decorators to implement the win32 fixes more cleanly.

Please do review the changes as they stand now:

https://code.launchpad.net/~fdo.perez/ipython/trunk-dev

Only the last revision really matters, the others have already been
looked at by you and Brian and merged into yours.

Once I get some feedback I'll cut the release.  Brian was going to run
the tests under win32 and I'm testing linux/2.4.  Any further testing
would be welcome!

Cheers,

f


From fperez.net at gmail.com  Sun Sep 14 22:22:24 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 19:22:24 -0700
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <46cb515a0809140958v3efe7e92x89ef36ce3d86c27b@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
	<46cb515a0809140958v3efe7e92x89ef36ce3d86c27b@mail.gmail.com>
Message-ID: <db6b5ecc0809141922o5be43263rdf1139647eb2bcde@mail.gmail.com>

On Sun, Sep 14, 2008 at 9:58 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sat, Sep 6, 2008 at 2:41 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Is there anything major other than this bug fix?  I am all for bug
>> fixes going in.
>
> Ok, Brian, care to take a look at the code in my trunk-dev now? I'll
> add the entries for changes.txt once the stuff goes in.

Great, I'm glad we're all using review more and more...

> You can ignore reviewing the stuff in ipy_leo.py, it's code that isn't
> widely used yet.

Nope.  Basically if it's code we ship, it's code we hold to the same
standard of review, documentation and testing.  Even in this scramble
to fix quickly the 2.4 issue we're using review, we're adding new
tests, functions have docstrings, etc.

All code going into the project will be held to the same standard of
quality, period.  If it's code that's not ready for review, that's
what private branches and personal homepages are for.

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 14 22:26:39 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 04:26:39 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
Message-ID: <20080915022639.GB21560@phare.normalesup.org>

On Sun, Sep 14, 2008 at 07:15:05PM -0700, Fernando Perez wrote:
> > Frontend code is cleaned up. This has been check in my branch. Brian was
> > centralizing the fixes in his branch. I am not too sure what the status
> > is there.

> I just merged his code, where he'd merged from you.  I've added some
> decorators to implement the win32 fixes more cleanly.

Looks good.

Brian and I where toying with the idea of adding a method to the wx
frontend. This method is for execution of a command in the interpreter,
while displaying it also on the screen.

The changelog can be seen on 
http://bazaar.launchpad.net/~gael-varoquaux/ipython/ipython-sync-frontend/revision/1149
and you can pull from my branch if you want.

I had to add this in my work at Enthought, and it was really an oversight
from my side not to put this in the API of the line frontends. The reason
being that this is actually not trivial to get right (finding out what
event to call, and even more important, how to interact with the GUI
event loop in a way that is robust under Vista), so I think it should be
part of the API. I had kinda decided that we would have to wait for 0.10,
as I missed the 0.9 release, but now that we are doing a 0.9.1, I am
pushing for it to go in. It's been used fairly heavily in the work I have
been doing at Enthought, so it's been tested in this regards. I can't add
a unit test, however, as it relies on the GUI event loop.

Ga?l



From fperez.net at gmail.com  Sun Sep 14 22:42:45 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 19:42:45 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080915022639.GB21560@phare.normalesup.org>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<20080915022639.GB21560@phare.normalesup.org>
Message-ID: <db6b5ecc0809141942y3a2a54c4wbc780c5be912532c@mail.gmail.com>

On Sun, Sep 14, 2008 at 7:26 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 07:15:05PM -0700, Fernando Perez wrote:
>> > Frontend code is cleaned up. This has been check in my branch. Brian was
>> > centralizing the fixes in his branch. I am not too sure what the status
>> > is there.
>
>> I just merged his code, where he'd merged from you.  I've added some
>> decorators to implement the win32 fixes more cleanly.
>
> Looks good.

Thanks.  I'll wait for Brian's report on win32 tests and will then push.

> Brian and I where toying with the idea of adding a method to the wx
> frontend. This method is for execution of a command in the interpreter,
> while displaying it also on the screen.
>
> The changelog can be seen on
> http://bazaar.launchpad.net/~gael-varoquaux/ipython/ipython-sync-frontend/revision/1149
> and you can pull from my branch if you want.
>
> I had to add this in my work at Enthought, and it was really an oversight
> from my side not to put this in the API of the line frontends. The reason
> being that this is actually not trivial to get right (finding out what
> event to call, and even more important, how to interact with the GUI
> event loop in a way that is robust under Vista), so I think it should be
> part of the API. I had kinda decided that we would have to wait for 0.10,
> as I missed the 0.9 release, but now that we are doing a 0.9.1, I am
> pushing for it to go in. It's been used fairly heavily in the work I have
> been doing at Enthought, so it's been tested in this regards. I can't add
> a unit test, however, as it relies on the GUI event loop.

I'd really prefer to keep this release as the emergency, fix-2.4
release.  This code is small, but it's not properly documented
(docstrings without args, no first line summary, no examples even if
they aren't doctests,...).

I believe you that it's been used, but the reality is that you could
easily have made a silly mistake (we all do), etc.  We're rushing a
release on a Sunday night to fix a brown-paper bug, this is not the
time to put in *any* new code outside the scope of the fixes we needed
(the test decorators were part of fixing broken tests).

Sorry, but I'm going to be very conservative here.  Let's just not
have another problem tomorrow, when none of us will have time to fix
it.  Brian and I were on the phone on this and he also seems to agree
with me, so I hope you'll understand.  I'll be super happy to pull it
in for 0.10 once you finish documenting it (for example, one version
of the execute method ignores the hidden argument, that should be
explained since it still takes it).

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 14 22:46:27 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 04:46:27 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141942y3a2a54c4wbc780c5be912532c@mail.gmail.com>
References: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<20080915022639.GB21560@phare.normalesup.org>
	<db6b5ecc0809141942y3a2a54c4wbc780c5be912532c@mail.gmail.com>
Message-ID: <20080915024627.GC21560@phare.normalesup.org>

On Sun, Sep 14, 2008 at 07:42:45PM -0700, Fernando Perez wrote:
> I'd really prefer to keep this release as the emergency, fix-2.4
> release.  This code is small, but it's not properly documented
> (docstrings without args, no first line summary, no examples even if
> they aren't doctests,...).

OK, that makes sens. I agree that the code is not to highest standards.
It was made as a stopgap solution in the Enthought codebase. I just
thought I might as well share it.

The best solution would be to have a new release in something like 3
months, to address all these small problems, before we undertake big
refactorings.

Ga?l


From ellisonbg.net at gmail.com  Sun Sep 14 22:50:25 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 19:50:25 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
Message-ID: <6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>

> Please do review the changes as they stand now:
>
> https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
>
> Only the last revision really matters, the others have already been
> looked at by you and Brian and merged into yours.

Just got from dinner.  Sitting down to work..

I will review and then do the merge into trunk.  After that I will do
some quick tests and ping the list saying we are ready for takeoff.

Brian

> Once I get some feedback I'll cut the release.  Brian was going to run
> the tests under win32 and I'm testing linux/2.4.  Any further testing
> would be welcome!
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Sun Sep 14 22:55:09 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 19:55:09 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
Message-ID: <db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>

On Sun, Sep 14, 2008 at 7:50 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Please do review the changes as they stand now:
>>
>> https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
>>
>> Only the last revision really matters, the others have already been
>> looked at by you and Brian and merged into yours.
>
> Just got from dinner.  Sitting down to work..
>
> I will review and then do the merge into trunk.  After that I will do
> some quick tests and ping the list saying we are ready for takeoff.

Great, thanks.  Just do the pull into your trunk-dev for review and
testing, I'll do the push from here with the last commit, there's
always a little something to tweak at push time :)  Does that work?

Cheers,

f


From fperez.net at gmail.com  Sun Sep 14 22:58:03 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 19:58:03 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080915024627.GC21560@phare.normalesup.org>
References: <db6b5ecc0809141411q1de03901q6b22645962c8a7d3@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<20080915022639.GB21560@phare.normalesup.org>
	<db6b5ecc0809141942y3a2a54c4wbc780c5be912532c@mail.gmail.com>
	<20080915024627.GC21560@phare.normalesup.org>
Message-ID: <db6b5ecc0809141958i4e34c585xde75ee6b423b827f@mail.gmail.com>

On Sun, Sep 14, 2008 at 7:46 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 07:42:45PM -0700, Fernando Perez wrote:
>> I'd really prefer to keep this release as the emergency, fix-2.4
>> release.  This code is small, but it's not properly documented
>> (docstrings without args, no first line summary, no examples even if
>> they aren't doctests,...).
>
> OK, that makes sens. I agree that the code is not to highest standards.
> It was made as a stopgap solution in the Enthought codebase. I just
> thought I might as well share it.
>
> The best solution would be to have a new release in something like 3
> months, to address all these small problems, before we undertake big
> refactorings.

Yup, that's what I'd like to see with 0.10: finishing merging key
components and stabilizing all we have in place.  We can then look a
bit deeper...

Thanks for being understanding :)

Cheers,

f


From ellisonbg.net at gmail.com  Mon Sep 15 00:05:13 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 21:05:13 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141425s56f561fciadf688142e4f1e46@mail.gmail.com>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
Message-ID: <6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>

>> I will review and then do the merge into trunk.  After that I will do
>> some quick tests and ping the list saying we are ready for takeoff.
>
> Great, thanks.  Just do the pull into your trunk-dev for review and
> testing, I'll do the push from here with the last commit, there's
> always a little something to tweak at push time :)  Does that work?

I didn't see this - also, I like to do my final testing from the final
merged trunk....so this is what I have been doing.  I have found a few
more things that I am now working on in my branch:

* A few extra things were listed in MANIFEST.in
* I added setupegg.py to the MANIFEST.in
* Fixed a another small bug in ipcontroller that would annoy the hell
out of people on Win32 (basically a confusing exception message).

One more question.  I see that the sdist includes the top-level test
directory.  Do we even use these?  Should they be shipped with the
source?

I need to finish my testing and make sure that I have everything, and
I will let you know.

Brian

> Cheers,
>
> f
>


From fperez.net at gmail.com  Mon Sep 15 00:13:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 21:13:57 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<20080914212753.GM12842@phare.normalesup.org>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
Message-ID: <db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>

On Sun, Sep 14, 2008 at 9:05 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> I will review and then do the merge into trunk.  After that I will do
>>> some quick tests and ping the list saying we are ready for takeoff.

Ouch. I understood the above as 'go' :)  I already pushed the release
script (meaning registered with pypi, etc...), when I saw you'd merged
and given the green light, I just went ahead with the final.  I have a
few things I need to do before going to bed.

I'm going to have to call it a day for now.  Let's let the little
fixes work their way in for a  few days and I'm sure we'll want to
have a 0.9.2 out after all the OSC tests this week.  With a release
that merged this much code, it's to be expected that we'll need to add
 a bit of polish for a while.  At least we now have the 2.4 problem
that was pure brown-paper-bag material out of the way :)

Sorry for the slight haste, but I honestly understood the above as a
green light, and I've been working on this release stuff for most of
this weekend, so I think I'm a bit tired...

Cheers,

f


From ellisonbg.net at gmail.com  Mon Sep 15 00:23:06 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 21:23:06 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
Message-ID: <6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>

> Ouch. I understood the above as 'go' :)  I already pushed the release
> script (meaning registered with pypi, etc...), when I saw you'd merged
> and given the green light, I just went ahead with the final.  I have a
> few things I need to do before going to bed.

Ha ha.  I think we are all getting tired :)  No problem.  I tested on
OS X and Win32 and all looks fine.  I pushed all of my fixes to my
branch.  They only related to extremely minor things.  But, they
should go in a 0.9.2 release in a bit....let's sit on it and how what
bubbles up in the next week or so.

But, before I quit I am going to:

* Make a ipython-0.9 branch out of trunk.
* Test to make sure that easy_install IPython "just works" through PyPI.
* Post an email about the ipython-0.9 branch to the list.


> I'm going to have to call it a day for now.  Let's let the little
> fixes work their way in for a  few days and I'm sure we'll want to
> have a 0.9.2 out after all the OSC tests this week.  With a release
> that merged this much code, it's to be expected that we'll need to add
>  a bit of polish for a while.  At least we now have the 2.4 problem
> that was pure brown-paper-bag material out of the way :)

Yep, Gael and I chatted about this earlier.  All things considered, I
think we have done pretty well.  This is a huge release for us!

> Sorry for the slight haste, but I honestly understood the above as a
> green light, and I've been working on this release stuff for most of
> this weekend, so I think I'm a bit tired...

No problem.

Cheers,

Brian

> Cheers,
>
> f
>


From gael.varoquaux at normalesup.org  Mon Sep 15 00:28:04 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 06:28:04 +0200
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
References: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
	<6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
Message-ID: <20080915042804.GD21560@phare.normalesup.org>

On Sun, Sep 14, 2008 at 09:23:06PM -0700, Brian Granger wrote:
> But, they should go in a 0.9.2 release in a bit....let's sit on it and
> how what bubbles up in the next week or so.

Let's define what we want to put in this 0.9.2 release. Next week I can
take half a day to put this aditional method in the frontends in order
and push it for inclusion, if this is an option. Unfortunately, I'll
still need to use my subclass in the enthought branch, as I don't think
we'll ship 0.9.2 with EPD, and I can only rely on what is shipped with
EPD.

Ga?l


From fperez.net at gmail.com  Mon Sep 15 00:33:13 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 21:33:13 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
References: <web-111238254@uni-stuttgart.de>
	<6ce0ac130809141431l5c439563l1fcd3de6356789c7@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
	<6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
Message-ID: <db6b5ecc0809142133u65a4ddd1xda68b1756f697497@mail.gmail.com>

On Sun, Sep 14, 2008 at 9:23 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Ouch. I understood the above as 'go' :)  I already pushed the release
>> script (meaning registered with pypi, etc...), when I saw you'd merged
>> and given the green light, I just went ahead with the final.  I have a
>> few things I need to do before going to bed.
>
> Ha ha.  I think we are all getting tired :)  No problem.  I tested on
> OS X and Win32 and all looks fine.  I pushed all of my fixes to my
> branch.  They only related to extremely minor things.  But, they
> should go in a 0.9.2 release in a bit....let's sit on it and how what
> bubbles up in the next week or so.
>
> But, before I quit I am going to:
>
> * Make a ipython-0.9 branch out of trunk.

Yup, thanks.  I did tag the releases using bzr tag, which I haven't
used before.  It just seems to give a human alias to a given revision
and litlte else.

> * Test to make sure that easy_install IPython "just works" through PyPI.
> * Post an email about the ipython-0.9 branch to the list.

Thanks!

f


From fperez.net at gmail.com  Mon Sep 15 00:36:24 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 14 Sep 2008 21:36:24 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080915042804.GD21560@phare.normalesup.org>
References: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
	<6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
	<20080915042804.GD21560@phare.normalesup.org>
Message-ID: <db6b5ecc0809142136t2ac7a91eh844be81d65d41180@mail.gmail.com>

On Sun, Sep 14, 2008 at 9:28 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 09:23:06PM -0700, Brian Granger wrote:
>> But, they should go in a 0.9.2 release in a bit....let's sit on it and
>> how what bubbles up in the next week or so.
>
> Let's define what we want to put in this 0.9.2 release. Next week I can
> take half a day to put this aditional method in the frontends in order
> and push it for inclusion, if this is an option. Unfortunately, I'll
> still need to use my subclass in the enthought branch, as I don't think
> we'll ship 0.9.2 with EPD, and I can only rely on what is shipped with
> EPD.

I'd say we should have it be a 'let the dust settle' for a few days
only.  We don't have the resources to keep multiple series in
parallel, so I'd rather:

- just wait for a few days for a 0.9.2 that accumulates any more
bloopers we spot, plus *small*, well-contained features.  Yours
qualifies as such, certainly.

- Cut the release next week or so, with all changes properly reviewed.

- Move into the 0.10 mode as soon as feasible.

I don't have the bandwidth to worry about 0.9.x and 0.10 in parallel,
but I have no objections to anyone who's willing to spend time on
both.  That's why I suggest staggering them so we focus on one at a
time (we're a pretty small team in any case).

Cheers,

f


From ellisonbg.net at gmail.com  Mon Sep 15 01:04:23 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 22:04:23 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <20080915042804.GD21560@phare.normalesup.org>
References: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<db6b5ecc0809141634m4815aab9ma42203dc65d1b17d@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
	<6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
	<20080915042804.GD21560@phare.normalesup.org>
Message-ID: <6ce0ac130809142204v7a1b9977xfc716f999688ef82@mail.gmail.com>

> Let's define what we want to put in this 0.9.2 release. Next week I can
> take half a day to put this aditional method in the frontends in order
> and push it for inclusion, if this is an option. Unfortunately, I'll
> still need to use my subclass in the enthought branch, as I don't think
> we'll ship 0.9.2 with EPD, and I can only rely on what is shipped with
> EPD.

I think 0.9.2 should have only super small bug fixes that aboslutely
need to get out before 0.10.  I put your code more in the category of
"almost a new feature that requires much more testing and review."

Also, because having this code in 0.9.2 won't make a difference for
Enthought, let's just schedule this code for 0.10 and merge it into
trunk after has been reviewed.

Cheers,

Brian

> Ga?l
>


From ellisonbg.net at gmail.com  Mon Sep 15 01:06:21 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 22:06:21 -0700
Subject: [IPython-dev] ipython0.9 and python2.4
In-Reply-To: <db6b5ecc0809142136t2ac7a91eh844be81d65d41180@mail.gmail.com>
References: <db6b5ecc0809141429j26117eaw858fc73dcf76b61c@mail.gmail.com>
	<20080915013112.GA21560@phare.normalesup.org>
	<db6b5ecc0809141915l7da5e505nab4830fde9c7ac55@mail.gmail.com>
	<6ce0ac130809141950n2fb8442eqef0e3c4ec9e78846@mail.gmail.com>
	<db6b5ecc0809141955s3dfbb519r837216e0685e816@mail.gmail.com>
	<6ce0ac130809142105r67d9294fr79cf4d56cc70f622@mail.gmail.com>
	<db6b5ecc0809142113v62c65abbh7530139dd0ffff16@mail.gmail.com>
	<6ce0ac130809142123h6b593dc6m5df33f5c3bb838a0@mail.gmail.com>
	<20080915042804.GD21560@phare.normalesup.org>
	<db6b5ecc0809142136t2ac7a91eh844be81d65d41180@mail.gmail.com>
Message-ID: <6ce0ac130809142206k7154a82avb8b7cde584599d8@mail.gmail.com>

> I'd say we should have it be a 'let the dust settle' for a few days
> only.  We don't have the resources to keep multiple series in
> parallel, so I'd rather:
>
> - just wait for a few days for a 0.9.2 that accumulates any more
> bloopers we spot, plus *small*, well-contained features.  Yours
> qualifies as such, certainly.

Sounds good.  I very much agree that only the 0.9.x should be only
small bug fixes.

> - Cut the release next week or so, with all changes properly reviewed.

+1

> - Move into the 0.10 mode as soon as feasible.

+1

> I don't have the bandwidth to worry about 0.9.x and 0.10 in parallel,
> but I have no objections to anyone who's willing to spend time on
> both.  That's why I suggest staggering them so we focus on one at a
> time (we're a pretty small team in any case).

Me neither.  I start teaching next week so all my free time will
evaporate quickly.

I am going to send out a small email to the list about the ipython-0.9
branch and our plans for the 0.9.2 release.

Cheers,

Brian

> Cheers,
>
> f
>


From ellisonbg.net at gmail.com  Mon Sep 15 01:12:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 14 Sep 2008 22:12:15 -0700
Subject: [IPython-dev] Update: ipython-0.9.1 is out,
	ipython-0.9 branch created
Message-ID: <6ce0ac130809142212y148d4c52j9cf8364c3ff2963@mail.gmail.com>

Hi,

So, after a day of fixing bug related to Python 2.4, we have released
IPython 0.9.1.  Thanks to everyone who helped on this last minute
effort.

Here is our short term development plan:

* I have created a ipython-0.9 branch that will be used for *bug
fixes* in the 0.9.x series only.  These bug fixes need to be small,
self-contained and fully reviewed and tested.

* We are going to let the dust settle for about a week with the 0.9.1
release and then push out 0.9.2 with any fixes that are in the
ipython-0.9 branch.  That will hopefully be the last release in the
0.9.2 series as we quickly want to move onto focusing on the 0.10
release.

* So, if you have a change that should go into the ipython-0.9 branch,
make sure you mark it as such when you are requesting code review.

* Trunk is now open for 0.10 development.  The timeline and feature
set for 0.10 is a whole different story that will probably require
some discussion.

Thanks everyone, this is a huge release for us!

Cheers,

Brian


From barrywark at gmail.com  Mon Sep 15 01:50:02 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 14 Sep 2008 22:50:02 -0700
Subject: [IPython-dev] Frontendbase and compile_ast.
In-Reply-To: <20080914221155.GP12842@phare.normalesup.org>
References: <20080914213925.GO12842@phare.normalesup.org>
	<20080914221155.GP12842@phare.normalesup.org>
Message-ID: <cd7634ce0809142250y55094ec6pec8bab6f873fffda@mail.gmail.com>

Gael,

I will take a look at your branch as soon as I can this week. Just to
give you the reasoning behind compile_ast, at the time, Brian had
brought up the idea of passing around ASTs rather than strings to
represent code blocks in the IPython core and frontends. The advantage
would be that code transformations and modifications by the frontend
or by the controller before sending to the agents would be easier. I
thought that sounded swell and even started an aborted attempt to
change the core and frontends to using ASTs. Obviously, that
conversion from string -> AST hasn't happened and I didn't realize
that it introduced an incompatibility with 2.4. It's fine with me if
we remove it for now. I know you've worked very hard on the block
completion testing for your frontend, so I suggest we go with your
code for now.

-Barry

On Sun, Sep 14, 2008 at 3:11 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Sep 14, 2008 at 11:39:25PM +0200, Gael Varoquaux wrote:
>> Currently no code in the frontends uses this method. I used it for a
>> while, but it turned out that the codeop module was more suited for
>> testing if the code was complete than compiling it to ast. I am strongly
>> thinking about removing this method for know.
>
> OK, I went ahead and replaced the is_complete method to avoid using the
> compile_ast one. I stuck with the original behavior of not raise an
> exception when the code was not valid, but I think it would be a better
> behavior, as it allows to give feedback to the user on incorrect code.
> This is what I do in the linefrontendbase is_complete's method.
>
> Barry, what are your thoughts on that? You can take a peek at the new
> version of is_complete in my branch.
>
> Ga?l
>


From gael.varoquaux at normalesup.org  Mon Sep 15 01:58:14 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 15 Sep 2008 07:58:14 +0200
Subject: [IPython-dev] Frontendbase and compile_ast.
In-Reply-To: <cd7634ce0809142250y55094ec6pec8bab6f873fffda@mail.gmail.com>
References: <20080914213925.GO12842@phare.normalesup.org>
	<20080914221155.GP12842@phare.normalesup.org>
	<cd7634ce0809142250y55094ec6pec8bab6f873fffda@mail.gmail.com>
Message-ID: <20080915055814.GE21560@phare.normalesup.org>

On Sun, Sep 14, 2008 at 10:50:02PM -0700, Barry Wark wrote:
> I will take a look at your branch as soon as I can this week. Just to
> give you the reasoning behind compile_ast, at the time, Brian had
> brought up the idea of passing around ASTs rather than strings to
> represent code blocks in the IPython core and frontends. The advantage
> would be that code transformations and modifications by the frontend
> or by the controller before sending to the agents would be easier. I
> thought that sounded swell and even started an aborted attempt to
> change the core and frontends to using ASTs. Obviously, that
> conversion from string -> AST hasn't happened and I didn't realize
> that it introduced an incompatibility with 2.4. It's fine with me if
> we remove it for now. I know you've worked very hard on the block
> completion testing for your frontend, so I suggest we go with your
> code for now.

OK, I thought that there might be something more than simply testing for
completion with ast :).

This idea is fairly neat, though I don't know how it would fare with
presenting useful exceptions to the user. In addition, it forbid any kind
of magic evalution happening on the interpreter side. Not that I mind,
but if we are going to go down this road, we need to be aware of this, as
I am not too sure yet where magic evaluation should happen.

One thing with block completion testing: in your code, you didn't raise
errors when the code had a syntax error, but simply considered it as
uncomplete. I first did the same, and when testing with users, it created
some confusions: users might not see what was wrong with their syntax,
and they would press return on and on. This is why I raise an exception
if the code is invalid, and the frontend captures this exception, to
display feedback to the user about what might be wrong with his input.

I have kept your behavior in the frontendbase code, but I tend to favour
the other one, I must admit. What's your take on this?

Ga?l


From vivainio at gmail.com  Mon Sep 15 04:05:54 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 15 Sep 2008 11:05:54 +0300
Subject: [IPython-dev] [IPython-user] Twisted support?
In-Reply-To: <bcc23fcc0809150003v34462cfek4520f6a6cad57fac@mail.gmail.com>
References: <bcc23fcc0809100502te1c45edh5fbe8531221ff7c1@mail.gmail.com>
	<bcc23fcc0809101019x1f6dc05dla3c2637a3d4afaa1@mail.gmail.com>
	<6ce0ac130809101454w8571d6fr92faa0550e70d90a@mail.gmail.com>
	<bcc23fcc0809101520q745b8fbbg4b3d386ba5cf8bd3@mail.gmail.com>
	<46cb515a0809140949w4e602553n2b172095d772c86b@mail.gmail.com>
	<bcc23fcc0809150003v34462cfek4520f6a6cad57fac@mail.gmail.com>
Message-ID: <46cb515a0809150105v2b953d67xcba57ca6656198ed@mail.gmail.com>

On Mon, Sep 15, 2008 at 10:03 AM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:

> So thats mean only window builds are working..
> Is there going to be support for twisted reactor in upcoming release?

If someone wants to work on it, yes. I don't think it's a big deal to
fix, it just needs someone that cares enough about the functionality
to do the necessary testing and fixing.

Also, you may want to look into qt4reactor project (search the
archives). It should work correctly with ipython.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From vivainio at gmail.com  Mon Sep 15 04:09:41 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 15 Sep 2008 11:09:41 +0300
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <db6b5ecc0809141922o5be43263rdf1139647eb2bcde@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
	<46cb515a0809140958v3efe7e92x89ef36ce3d86c27b@mail.gmail.com>
	<db6b5ecc0809141922o5be43263rdf1139647eb2bcde@mail.gmail.com>
Message-ID: <46cb515a0809150109h92a8a3cw93674c1709d969c0@mail.gmail.com>

On Mon, Sep 15, 2008 at 5:22 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> All code going into the project will be held to the same standard of
> quality, period.  If it's code that's not ready for review, that's
> what private branches and personal homepages are for.

Yep, that's probably a good idea. I will move ipy_leo.py to
ipython-extensions distribution before 0.9.1, so it doesn't need to be
merged (and thus reviewed). The rest of the branch should be reviewed,
of course.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From ondrej at certik.cz  Mon Sep 15 04:50:46 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 15 Sep 2008 10:50:46 +0200
Subject: [IPython-dev] Docs: authorship listing
In-Reply-To: <db6b5ecc0809111555p2a11ef3l59212bd0196dc142@mail.gmail.com>
References: <db6b5ecc0809111555p2a11ef3l59212bd0196dc142@mail.gmail.com>
Message-ID: <85b5c3130809150150r3d77ca8flc34bf39d74bc5c30@mail.gmail.com>

On Fri, Sep 12, 2008 at 12:55 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> we were considering to just list the authorship of the docs similarly
> to the rest of the project as "ipython dev team".  This will give us a
> simple policy as more and more people add contributions, since that
> can be easily listed in the history/credits section of the docs, while
> having 20 authors and 50 contributors on the title page gets a bit
> silly (particle physics papers with 1000 authors not withstanding :)
>
> Hopefully this highlights further how this has become a truly collective effort.

We do that same for sympy and have this page with credits:

http://docs.sympy.org/aboutus.html#sympy-development-team

Ondrej


From vivainio at gmail.com  Mon Sep 15 11:38:22 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 15 Sep 2008 18:38:22 +0300
Subject: [IPython-dev] Ville's branch to be merged before the 0.9
	release?
In-Reply-To: <46cb515a0809150109h92a8a3cw93674c1709d969c0@mail.gmail.com>
References: <6ce0ac130809051528q20d8f1acue2b37513f159bf26@mail.gmail.com>
	<46cb515a0809051549x216fd23au67f28d79a558d95f@mail.gmail.com>
	<6ce0ac130809051641y194284cblc7e0532dadb8b668@mail.gmail.com>
	<46cb515a0809140958v3efe7e92x89ef36ce3d86c27b@mail.gmail.com>
	<db6b5ecc0809141922o5be43263rdf1139647eb2bcde@mail.gmail.com>
	<46cb515a0809150109h92a8a3cw93674c1709d969c0@mail.gmail.com>
Message-ID: <46cb515a0809150838vc5bec27kf647ab280ddc67b9@mail.gmail.com>

On Mon, Sep 15, 2008 at 11:09 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

> Yep, that's probably a good idea. I will move ipy_leo.py to
> ipython-extensions distribution before 0.9.1, so it doesn't need to be
> merged (and thus reviewed). The rest of the branch should be reviewed,
> of course.

I've now removed ipy_leo.py from my trunk-dev (and added it to
ipython-extensions) - so it'll be removed from trunk when you
integrate my branch. Too bad this didn't go in before 0.9.1, but that
probably won't be a big problem anyhow.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From ellisonbg.net at gmail.com  Mon Sep 15 12:12:30 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 15 Sep 2008 09:12:30 -0700
Subject: [IPython-dev] [IPython-user] Twisted support?
In-Reply-To: <46cb515a0809150105v2b953d67xcba57ca6656198ed@mail.gmail.com>
References: <bcc23fcc0809100502te1c45edh5fbe8531221ff7c1@mail.gmail.com>
	<bcc23fcc0809101019x1f6dc05dla3c2637a3d4afaa1@mail.gmail.com>
	<6ce0ac130809101454w8571d6fr92faa0550e70d90a@mail.gmail.com>
	<bcc23fcc0809101520q745b8fbbg4b3d386ba5cf8bd3@mail.gmail.com>
	<46cb515a0809140949w4e602553n2b172095d772c86b@mail.gmail.com>
	<bcc23fcc0809150003v34462cfek4520f6a6cad57fac@mail.gmail.com>
	<46cb515a0809150105v2b953d67xcba57ca6656198ed@mail.gmail.com>
Message-ID: <6ce0ac130809150912x79d6b126h23294b0dc7bb8aa3@mail.gmail.com>

>> So thats mean only window builds are working..
>> Is there going to be support for twisted reactor in upcoming release?
>
> If someone wants to work on it, yes. I don't think it's a big deal to
> fix, it just needs someone that cares enough about the functionality
> to do the necessary testing and fixing.

There are some subtleties about this lurking.  The main issue is that
we are already in some cases running the Twisted reactor in IPython
using a very careful and particular model.  If someone tries to run
the reactor in a different manner, everything will blow up.

My suggestion is this:  if someone wants to run the reactor in IPython
there are two likely scenarios:

1.  (please don't take offense at this, I have been this person for
most of my Twisted using life) The user thinks they want to run the
reactor in IPython, but really it would not behave how they want it
too (most people in this scenario want to block on the result of a
deferred, which is broadly speaking not possible)

2.  The user is a Twisted ninja and they understand the issues
involved.  These users should ask us: "how does IPython run the
Twisted event loop and how can I use this."

(yes I understand that this sounds like some sort of secret knowledge
cult thing going on.  Twisted can be like that at times).

If someone does want to make it easier to pursue (2), the main thing
we need is someone to try things out and write some good documentation
about how it all works.  That would be fantastic and we are more than
willing to help.

Cheers,

Brian


From vivainio at gmail.com  Mon Sep 15 15:08:11 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 15 Sep 2008 22:08:11 +0300
Subject: [IPython-dev] Fwd: IPython Crash Report
In-Reply-To: <091520081903.17279.48CEB1790006B0650000437F2205889116089B07039C0B030D040D@comcast.net>
References: <091520081903.17279.48CEB1790006B0650000437F2205889116089B07039C0B030D040D@comcast.net>
Message-ID: <46cb515a0809151208y7b1087fr36ee00042014faf3@mail.gmail.com>

Check this out - this is probably a new development.


---------- Forwarded message ----------
From:  <blbmdsmith at comcast.net>
Date: Mon, Sep 15, 2008 at 10:03 PM
Subject: IPython Crash Report
To: vivainio at gmail.com




I am running IPython for the first time.  It is highly likely that I
don't have all of IPython installed correctly or I am missing some
library.

Thanks for any help,
Bill

***************************************************************************

IPython post-mortem report

IPython version: 0.9.1

SVN revision   : 1145

Platform info  : os.name -> posix, sys.platform -> linux2

***************************************************************************

Current user configuration structure:

{'Version': 0,
 '__allownew': True,
 'alias': [],
 'args': [],
 'autocall': 1,
 'autoedit_syntax': 0,
 'autoexec': [],
 'autoindent': 1,
 'automagic': 1,
 'banner': 1,
 'c': '',
 'cache_size': 1000,
 'classic': 0,
 'color_info': 1,
 'colors': 'Linux',
 'confirm_exit': 1,
 'debug': 0,
 'deep_reload': 0,
 'editor': 'vi',
 'embedded': False,
 'execfile': [],
 'execute': [''],
 'gthread': 0,
 'help': 0,
 'import_all': [],
 'import_mod': [],
 'import_some': [[]],
 'include': [],
 'interact': 0,
 'ipythondir': '/root/.ipython',
 'log': 0,
 'logfile': '',
 'logplay': '',
 'magic_docstrings': 0,
 'messages': 1,
 'multi_line_specials': 1,
 'nosep': 0,
 'object_info_string_level': 0,
 'opts': Struct({'__allownew': True}),
 'pdb': 0,
 'pprint': 1,
 'profile': '',
 'prompt_in1': 'In [\\#]: ',
 'prompt_in2': '   .\\D.: ',
 'prompt_out': 'Out[\\#]: ',
 'prompts_pad_left': 1,
 'pydb': 0,
 'pylab': 0,
 'pylab_import_all': 1,
 'q4thread': 0,
 'qthread': 0,
 'quick': 0,
 'quiet': 0,
 'rcfile': 'ipythonrc',
 'readline': 1,
 'readline_merge_completions': 1,
 'readline_omit__names': 0,
 'readline_parse_and_bind': ['tab: complete',
                            '"\\C-l": possible-completions',
                            'set show-all-if-ambiguous on',
                            '"\\C-o": tab-insert',
                            '"\\M-i": "    "',
                            '"\\M-o": "\\d\\d\\d\\d"',
                            '"\\M-I": "\\d\\d\\d\\d"',
                            '"\\C-r": reverse-search-history',
                            '"\\C-s": forward-search-history',
                            '"\\C-p": history-search-backward',
                            '"\\C-n": history-search-forward',
                            '"\\e[A": history-search-backward',
                            '"\\e[B": history-search-forward',
                            '"\\C-k": kill-line',
                            '"\\C-u": unix-line-discard'],
 'readline_remove_delims': '-/~',
 'screen_length': -2,
 'separate_in': '\n',
 'separate_out': '',
 'separate_out2': '',
 'system_header': 'IPython system call: ',
 'system_verbose': 0,
 'term_title': 1,
 'tk': 0,
 'upgrade': 0,
 'wildcards_case_sensitive': 1,
 'wthread': 0,
 'wxversion': '0',
 'xmode': 'Context'}

***************************************************************************

Crash traceback:

---------------------------------------------------------------------------
TypeError                                     Python 2.4.3: /usr/bin/python
                                                  Mon Sep 15 14:56:04 2008
A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

/usr/bin/ipython
     1
     2
     3
     4
     5
     6
----> 7
       sys.exit = <built-in function exit>
       load_entry_point = <function load_entry_point at 0xb7eddd4c>
     8
     9
    10 #!/usr/bin/python
    11 # EASY-INSTALL-ENTRY-SCRIPT: 'ipython==0.9.1','console_scripts','ipython'
    12 __requires__ = 'ipython==0.9.1'
    13 import sys
    14 from pkg_resources import load_entry_point
    15
    16 sys.exit(
    17    load_entry_point('ipython==0.9.1', 'console_scripts', 'ipython')()
    18 )
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31

/usr/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/ipapi.pyc
in launch_new_instance(user_ns=None, shellclass=None)
   544     def check_hotname(self,name):
   545         if name in self.hotnames:
   546             self.debug_stack( "HotName '%s' caught" % name)
   547
   548
   549 def launch_new_instance(user_ns = None,shellclass = None):
   550     """ Make and start a new ipython instance.
   551
   552     This can be called even without having an already initialized
   553     ipython session running.
   554
   555     This is also used as the egg entry point for the 'ipython' script.
   556
   557     """
   558     ses = make_session(user_ns,shellclass)
--> 559     ses.mainloop()
   560
   561
   562 def make_user_ns(user_ns = None):
   563     """Return a valid user interactive namespace.
   564
   565     This builds a dict with the minimal information needed to
operate as a
   566     valid IPython user namespace, which you can pass to the
various embedding
   567     classes in ipython.
   568
   569     This API is currently deprecated. Use
ipapi.make_user_namespaces() instead
   570     to make both the local and global namespace objects simultaneously.
   571
   572     :Parameters:
   573         user_ns : dict-like, optional
   574             The current user namespace. The items in this
namespace should be

/usr/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/Shell.pyc
in mainloop(self=<IPython.Shell.IPShell instance>, sys_exit=0,
banner=None)
    66 #-----------------------------------------------------------------------------
    67 # This class is trivial now, but I want to have it in to publish a clean
    68 # interface. Later when the internals are reorganized, code
that uses this
    69 # shouldn't have to change.
    70
    71 class IPShell:
    72     """Create an IPython instance."""
    73
    74     def __init__(self,argv=None,user_ns=None,user_global_ns=None,
    75                  debug=1,shell_class=InteractiveShell):
    76         self.IP = make_IPython(argv,user_ns=user_ns,
    77                                user_global_ns=user_global_ns,
    78                                debug=debug,shell_class=shell_class)
    79
    80     def mainloop(self,sys_exit=0,banner=None):
---> 81         self.IP.mainloop(banner)
       global When = undefined
       global the = undefined
       global IPython = <module 'IPython' from
'/usr/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/__init__.pyc'>
       global shell = undefined
       global exited = undefined
       global with = undefined
       global Ctrl = undefined
       global D = undefined
       global normal = undefined
       global program = undefined
       global execution = undefined
    82         if sys_exit:
    83             sys.exit()
    84
    85 #-----------------------------------------------------------------------------
    86 def kill_embedded(self,parameter_s=''):
    87     """%kill_embedded : deactivate for good the current embedded IPython.
    88
    89     This function (after asking for confirmation) sets an
internal flag so that
    90     an embedded IPython will never activate again.  This is useful to
    91     permanently disable a shell that is being called inside a
loop: once you've
    92     figured out what you needed from it, you may then kill it
and the program
    93     will then continue to run without the interactive shell
interfering again.
    94     """
    95
    96     kill = ask_yes_no("Are you sure you want to kill this
embedded instance "

/usr/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/iplib.pyc
in mainloop(self=<IPython.iplib.InteractiveShell object>,
banner='Python 2.4.3 (#1, Jan 14 2008, 18:32:40) \nType "...ut
\'object\'. ?object also works, ?? prints more.\n')
  1562         internally created default banner."""
  1563
  1564         if self.rc.c:  # Emulate Python's -c option
  1565             self.exec_init_cmd()
  1566         if banner is None:
  1567             if not self.rc.banner:
  1568                 banner = ''
  1569             # banner is string? Use it directly!
  1570             elif isinstance(self.rc.banner,basestring):
  1571                 banner = self.rc.banner
  1572             else:
  1573                 banner = self.BANNER+self.banner2
  1574
  1575         while 1:
  1576             try:
-> 1577                 self.interact(banner)
  1578                 #self.interact_with_readline()
  1579                 # XXX for testing of a readline-decoupled repl
loop, call interact_with_readline above
  1580
  1581                 break
  1582             except KeyboardInterrupt:
  1583                 # this should not be necessary, but KeyboardInterrupt
  1584                 # handling seems rather unpredictable...
  1585                 self.write("\nKeyboardInterrupt in interact()\n")
  1586
  1587     def exec_init_cmd(self):
  1588         """Execute a command given at the command line.
  1589
  1590         This emulates Python's -c option."""
  1591
  1592         #sys.argv = ['-c']

/usr/lib/python2.4/site-packages/ipython-0.9.1-py2.4.egg/IPython/iplib.pyc
in interact(self=<IPython.iplib.InteractiveShell object>,
banner='Python 2.4.3 (#1, Jan 14 2008, 18:32:40) \nType "...ut
\'object\'. ?object also works, ?? prints more.\n')
  1799                     self.rl_do_indent = False
  1800                     self.readline_startup_hook(None)
  1801                 self.write('\n')
  1802                 self.exit()
  1803             except bdb.BdbQuit:
  1804                 warn('The Python debugger has exited with a
BdbQuit exception.\n'
  1805                      'Because of how pdb handles the stack, it
is impossible\n'
  1806                      'for IPython to properly format this
particular exception.\n'
  1807                      'IPython will resume normal operation.')
  1808             except:
  1809                 # exceptions here are VERY RARE, but they can
be triggered
  1810                 # asynchronously by signal handlers, for example.
  1811                 self.showtraceback()
  1812             else:
  1813                 more = self.push(line)
-> 1814                 if (self.SyntaxTB.last_syntax_error and
  1815                     self.rc.autoedit_syntax):
  1816                     self.edit_syntax_error()
  1817
  1818         # We are off again...
  1819         __builtin__.__dict__['__IPYTHON__active'] -= 1
  1820
  1821     def excepthook(self, etype, value, tb):
  1822       """One more defense for GUI apps that call sys.excepthook.
  1823
  1824       GUI frameworks like wxPython trap exceptions and call
  1825       sys.excepthook themselves.  I guess this is a feature that
  1826       enables them to keep running after exceptions that would
  1827       otherwise kill their mainloop. This is a bother for IPython
  1828       which excepts to catch all of the program exceptions with a try:
  1829       except: statement.

TypeError: expected string or Unicode object, NoneType found

***************************************************************************

History of session input:
import netsnmp
oid = netsnmp.Varbind('sysDescr')
result = netsnmp.snmpwalk(oid,Version
=2,DestHost="192.168.8.103,Community="public"")
result = netsnmp.snmpwalk(oid,Version
=2,DestHost="192.168.8.103",Community="public"")
result = netsnmp.snmpwalk(oid,Version
=2,DestHost="192.168.8.103",Community="public")

*** Last line of input (may not be in above history):
result = netsnmp.snmpwalk(oid,Version
=2,DestHost="192.168.8.103",Community="public")




-- 
Ville M. Vainio
http://tinyurl.com/vainio
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: IPython_crash_report.txt
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080915/1f7ab1df/attachment.txt>

From ellisonbg.net at gmail.com  Tue Sep 16 19:19:07 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 16 Sep 2008 16:19:07 -0700
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
	IPython
Message-ID: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>

Hi,

A while back Barry Wark developed a nice prototype of a notification
center for IPython.  There was lots of discussions about that versus
other models and then things died off with the 0.9 release.

Gael, Fernando and I picked up this topic in person at SciPy and I
wanted to summarize our conclusions for the list (especially Barry).

We feel all feel that there are two types of "notification" models
that we want to support:

* Something like Barry's notification center, where observers register
that they want to recieve certain types of notification events.

* Objects with interfaces based model.  In this model, the "observer"
provides an object that obeys a certain interface (like a dict, for
example) and then someone just uses that object.  The notifiations
happen because the observer has put its own custom hooks in the object
that handle the notifications.

An example will hopefully clarify this.  The user namespace is a
perfect example of this second type of pattern.  Let's say someone
wants to receive notifications of when a new variable appears in the
namespace.  If that someone give the interpreter a dict-like object to
use as the namespace, that object can have custom logic that notifies
the someone when the events occur.

Our conclusion (I guess it is not that profound) is that we want to
support *both* of these models as much as possible.  Thus any time
notifications are wanted, we should work *very hard* to try to
implement both ways.  Some further points:

* In some cases one type of notification will be implemented on top of
the other.
* The object based model tends to be useful for highly coupled
situations, where the notifications are very static (always
on/wanted).
* The notification center works in a very transient context, when
notifications are very dynamic (observers come and go).
* The notification center approach is very much needed to allow
notifications to be propagated over network connections.
* The object based model is very nice for developing frontends based
on technologies like enthought.traits, which already have
notifications buildin.
* Handling notifications both ways will force us to get the abstractions right.
* The notification center type design should be preferred over designs
that rely on heavy subclassing to implement notifications (this type
of design is common in GUI programming, but we need to be really
careful to avoid this when possible as it leads to coupling that is
too strong for us).

Gael and Fernando, does this accurately reflect our conclusions?  Comments.

I think the only conclusion is that there are places in the current
frontend, where a more formal notification setup could be used =
notificationcenter+objects.

Cheers,

Brian


From gael.varoquaux at normalesup.org  Tue Sep 16 21:09:26 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 17 Sep 2008 03:09:26 +0200
Subject: [IPython-dev] Notes on SciPy discussion about Notifications
	in	IPython
In-Reply-To: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
Message-ID: <20080917010926.GA13862@phare.normalesup.org>

On Tue, Sep 16, 2008 at 04:19:07PM -0700, Brian Granger wrote:
> Gael and Fernando, does this accurately reflect our conclusions?  Comments.

I think it does, thank you for spending time on that. 

One thing that might be useful to add, is that we felt that for
notification accross the network, explicitely registering the
notifications was probably a best option, as it would give finer control
on the different events fired.

I look forward to seeing how this can be put in practice,

Ga?l


From vivainio at gmail.com  Wed Sep 17 03:29:07 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 17 Sep 2008 10:29:07 +0300
Subject: [IPython-dev] Next PyGtk is going to rock the pylab
Message-ID: <46cb515a0809170029x35b10577i4cfe41d5d06085bb@mail.gmail.com>

Once the "bleeding edge" of pygtk is released, we will have a pylab
gtk backend that is as stable and simple as the Tk backend. I.e. no
more threading woes.

I'd like to draw everyone's attention to the discussion in this bug report:

https://bugs.launchpad.net/ipython/+bug/270856

All that is needed to create the single threaded gtk matplotlibshell
is this (note that it does not use "gui specific" shell, just the
launcher code is gui specific - it uses the plain vanilla
IPython.Shell.IPShellMatplotlib()):

#!/usr/bin/env python
# -*- coding: utf-8 -*-
""" Launch matplotlibshell using gtk """

import gtk,gobject
import IPython.Shell
live = False

def run_ipython():
    global live
    if live:
        return False

    live = True
    shell = IPython.Shell.IPShellMatplotlib()
    IPython.Shell.hijack_gtk()
    shell.mainloop()

gobject.idle_add(run_ipython)
# the following line does not work on current pygtk
#gtk.set_interactive(True)
gtk.main()


-- 
Ville M. Vainio
http://tinyurl.com/vainio


From gael.varoquaux at normalesup.org  Wed Sep 17 10:25:44 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 17 Sep 2008 16:25:44 +0200
Subject: [IPython-dev] ipython1 and synchronous printing of stdout
In-Reply-To: <200808181151.47065.meine@informatik.uni-hamburg.de>
References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com>
	<200808082218.50243.hans_meine@gmx.net>
	<20080808202439.GB8104@phare.normalesup.org>
	<200808181151.47065.meine@informatik.uni-hamburg.de>
Message-ID: <20080917142544.GJ752@phare.normalesup.org>

On Mon, Aug 18, 2008 at 11:51:46AM +0200, Hans Meine wrote:
> Hi Ga?l,

Sorry, this e-mail dropped out of my radar :).

> on Friday 08 August 2008 22:24:39 Gael Varoquaux wrote:
> > OK, I use this, but this by itself is not sufficient, because you want to
> > have trap to shell back out in the GUI mainloop to refresh the screen and
> > process events like "Ctrl-C" every once in a while

> If I understand you right, you process GUI events when something is output?  
> What about a long-running loop without any output?

If there is no output, only the use code is run. I run my own code on
print, but I cannot do more than that because the program is 
single-threaded.

> > (once again,
> > multi-threading is unacceptable, because the GUI toolkits that we have
> > are not thread-safe (none is), and it would lead to crashers when the
> > users would input code that interacted with the GUI toolkit.

> I don't remember if I have mentioned it in this thread or whether you
> have read an older thread about it, but we solved this by having two
> processes, one for the frontend and one for the backend, communicating
> over a socket.  In the backend, we would load a trivial "interrupt"
> extension module which would listen to a command sent by the frontend
> and call PyErr_SetInterrupt();

Yes, this would be a very good option. I am starting to consider this
option for an IDE more and more (and actually, this is how IDLE works).

> The main disadvantage is that if the backend wants to integrate into the 
> frontend GUI, an extra API for that becomes necessary.  Otherwise, it's 
> similar to a "real" terminal, which also runs in a separate process.

Yes, this is exactly the limitation. I am however wondering if the gain
here is not high-enough to justify the cost. If we go down this way, we
should ask ourselves why we are building this in a Wx (or QT, or GTK)
application. What does it give us that a terminal does not give us? More
control on the layout, for instance. But then we start seeing the limits
of the canvas API exposed by these toolkits. What about using a web
interface, then? The canvas is excellent, but the handling of events is
less so.

Anyhow, the reason Enthought is interested in this frontend, is to put it
inside GUIs, so this reflection is off-topic for what I am doing now. It
is still interesting to keep it in mind.

Thanks for sharing your thoughts,

Ga?l


From vivainio at gmail.com  Wed Sep 17 13:01:47 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 17 Sep 2008 20:01:47 +0300
Subject: [IPython-dev] Unit testing
Message-ID: <46cb515a0809171001p4d251ee6y28868234e7931f6a@mail.gmail.com>

Since it appears we will be using nose to run the unit test, and since
IPython "classic" has zero tests that are run by the current test
suite (from what I gathered from running ./iptest), where can I get
started on writing such tests?

I tried adding this to ipy_profile_sh.py:

def test():
    assert False

And, it wasn't run by nose. So, where should we get started? Create
'test' directories?

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From ellisonbg.net at gmail.com  Wed Sep 17 14:21:29 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 17 Sep 2008 11:21:29 -0700
Subject: [IPython-dev] Unit testing
In-Reply-To: <46cb515a0809171001p4d251ee6y28868234e7931f6a@mail.gmail.com>
References: <46cb515a0809171001p4d251ee6y28868234e7931f6a@mail.gmail.com>
Message-ID: <6ce0ac130809171121x74dbb739xe226c16375568357@mail.gmail.com>

Ville,

Fernando knows much better about how nose finds tests, but I think in
this case I know what the issue is.  Nose only looks for tests in
modules names *test*.py.  We are putting such files in locations like

IPython.tests
IPython.kernel.tests
IPython.frontend.tests
etc.

Broadly speaking, any package should have a tests sub-directory that
has test modules for each module in the package:

foo.py
bar.py
tests
    test_foo.py
    test_bar.py

If you then go put your unittests or nose tests in test_foo.py or
test_bar.py nose should pick them up automatically.

The tests for the ipy_profile_sh.py module would probably go into

IPython.tests.test_profile_sh.py

Does that help?  Fernando, any other wisdom as to how nose finds tests?

We need to update our Sphinx developer docs about this.

Cheers,

Brian



On Wed, Sep 17, 2008 at 10:01 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Since it appears we will be using nose to run the unit test, and since
> IPython "classic" has zero tests that are run by the current test
> suite (from what I gathered from running ./iptest), where can I get
> started on writing such tests?
>
> I tried adding this to ipy_profile_sh.py:
>
> def test():
>    assert False
>
> And, it wasn't run by nose. So, where should we get started? Create
> 'test' directories?
>
> --
> Ville M. Vainio
> http://tinyurl.com/vainio
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Wed Sep 17 14:52:00 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 17 Sep 2008 21:52:00 +0300
Subject: [IPython-dev] Unit testing
In-Reply-To: <6ce0ac130809171121x74dbb739xe226c16375568357@mail.gmail.com>
References: <46cb515a0809171001p4d251ee6y28868234e7931f6a@mail.gmail.com>
	<6ce0ac130809171121x74dbb739xe226c16375568357@mail.gmail.com>
Message-ID: <46cb515a0809171152s7df07b05l2c57d29b89a41ded@mail.gmail.com>

On Wed, Sep 17, 2008 at 9:21 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> If you then go put your unittests or nose tests in test_foo.py or
> test_bar.py nose should pick them up automatically.

Actually, it seems ipython/IPython/tests is the best place.

Something that's cool: a test like this will work:

def test_rehashx():
    _ip.IP.alias_table.clear()
    _ip.magic('rehashx')
    assert len(_ip.IP.alias_table) > 10

That is, I don't need to set up _ip myself because the stuff gets
evaluated in an existing ipython session.

Is there a way I can make nose skip all the tests I don't care about
(i.e. the ones I'm NOT developing at the moment)? Waiting for 9 secs
every time I try it feels unnecessary. I could create a proper
setup/teardown fixture, but my guess is that it isn't really needed...

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From barrywark at gmail.com  Wed Sep 17 15:51:56 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 17 Sep 2008 12:51:56 -0700
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
	IPython
In-Reply-To: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
Message-ID: <cd7634ce0809171251i4b2c8e85rff73151ccfd3db61@mail.gmail.com>

Brian,

Thank you for summarizing the discussion; I'm sorry I missed it! I
like the way you lay things out and I agree with your conclusions. I
came out hard on the side of the notification-center style so that
in-process and networked interactions could be as similar as possible,
but I'm happy we've reached a common middle ground and am looking
forward to trying to make both styles work for developers and users.

As soon as I can 1) clean up the bugs in the frontendbase test code
and 2) get the Cocoa frontend into a more useable state, I would like
to have a crack at the network-aware notification problem... unless
someone goes ahead and implements it first ;)

barry

On Tue, Sep 16, 2008 at 4:19 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> A while back Barry Wark developed a nice prototype of a notification
> center for IPython.  There was lots of discussions about that versus
> other models and then things died off with the 0.9 release.
>
> Gael, Fernando and I picked up this topic in person at SciPy and I
> wanted to summarize our conclusions for the list (especially Barry).
>
> We feel all feel that there are two types of "notification" models
> that we want to support:
>
> * Something like Barry's notification center, where observers register
> that they want to recieve certain types of notification events.
>
> * Objects with interfaces based model.  In this model, the "observer"
> provides an object that obeys a certain interface (like a dict, for
> example) and then someone just uses that object.  The notifiations
> happen because the observer has put its own custom hooks in the object
> that handle the notifications.
>
> An example will hopefully clarify this.  The user namespace is a
> perfect example of this second type of pattern.  Let's say someone
> wants to receive notifications of when a new variable appears in the
> namespace.  If that someone give the interpreter a dict-like object to
> use as the namespace, that object can have custom logic that notifies
> the someone when the events occur.
>
> Our conclusion (I guess it is not that profound) is that we want to
> support *both* of these models as much as possible.  Thus any time
> notifications are wanted, we should work *very hard* to try to
> implement both ways.  Some further points:
>
> * In some cases one type of notification will be implemented on top of
> the other.
> * The object based model tends to be useful for highly coupled
> situations, where the notifications are very static (always
> on/wanted).
> * The notification center works in a very transient context, when
> notifications are very dynamic (observers come and go).
> * The notification center approach is very much needed to allow
> notifications to be propagated over network connections.
> * The object based model is very nice for developing frontends based
> on technologies like enthought.traits, which already have
> notifications buildin.
> * Handling notifications both ways will force us to get the abstractions right.
> * The notification center type design should be preferred over designs
> that rely on heavy subclassing to implement notifications (this type
> of design is common in GUI programming, but we need to be really
> careful to avoid this when possible as it leads to coupling that is
> too strong for us).
>
> Gael and Fernando, does this accurately reflect our conclusions?  Comments.
>
> I think the only conclusion is that there are places in the current
> frontend, where a more formal notification setup could be used =
> notificationcenter+objects.
>
> Cheers,
>
> Brian
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From barrywark at gmail.com  Wed Sep 17 15:55:29 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 17 Sep 2008 12:55:29 -0700
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
	IPython
In-Reply-To: <20080917010926.GA13862@phare.normalesup.org>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
	<20080917010926.GA13862@phare.normalesup.org>
Message-ID: <cd7634ce0809171255n3a9276e1ue27e1d2a9dc7e09@mail.gmail.com>

On Tue, Sep 16, 2008 at 6:09 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Sep 16, 2008 at 04:19:07PM -0700, Brian Granger wrote:
>> Gael and Fernando, does this accurately reflect our conclusions?  Comments.
>
> I think it does, thank you for spending time on that.
>
> One thing that might be useful to add, is that we felt that for
> notification accross the network, explicitely registering the
> notifications was probably a best option, as it would give finer control
> on the different events fired.

Someone please correct me where I go astray... I think that
implementing something like the interface style notification across a
foolscap connection would require explicitlly defining remote_*
methods to receive those callbacks. Thus, there may not be a *huge*
difference in the level of control between interface and
notification-center style but there may still be stylistic reasons why
one feels better. Hopefully the design decisions that lead us towards
one style or the other for in-process notifications will transfer to
the networked or out-of-process cases.

>
> I look forward to seeing how this can be put in practice,
>
> 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 Sep 17 16:23:31 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 17 Sep 2008 23:23:31 +0300
Subject: [IPython-dev] Why trunk-dev (i.e. long-lived branches) may be a bad
	idea
Message-ID: <46cb515a0809171323s6f2427cbo4ab8dd388d079f9f@mail.gmail.com>

Some thoughts about long lived branches (i.e. a branch that goes on
indefinitely) & optimizing our workflow:

- Clicking on "branch merged" on launchpad does not make any sense for
the long-lived-branch scheme (which in part suggests that this is not
the way bzr is meant to be used)

- All branches should be as close to the trunk as possible (i.e. it
should be clear when it was branched, and when it was merged). If you
merge back-and-forth between trunk-dev and trunk, you lose sight of
what has really been happening - and it's impossible to tell by just
looking at revision graph and branch names.

- The point where you had "clean slate" is not visible in history.

Of course this is only a problem if you do lots of back-and-forth
merging. If you push trunk over your trunk-dev after merge (or rather,
just before starting to develop something), the history stays easily
understandable.

Perhaps this could be a scheme that is as "relaxed" as using trunk-dev
*appears to be*, in that it doesn't require you to think of branch
name before you have actually done someting:

1. When you start developing, push trunk over trunk-dev

2. Commit to trunk-dev normally

2. When you have set of changes about "something" ready, push
trunk-dev to launchpad under different name (ipy-done-something). Mark
that branch as "request review & merge". When that is done, merge and
mark the branch "merged"

3. Go to #1.

The idea here, among other things, is to retain review comments etc.
neatly associated with the branch where they occured.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From vivainio at gmail.com  Wed Sep 17 17:30:37 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 18 Sep 2008 00:30:37 +0300
Subject: [IPython-dev] Proposal to get unit test coverage as soon as possible
Message-ID: <46cb515a0809171430q4ca67661p7c85148c90aeab7@mail.gmail.com>

I suppose we should try to cover as much of the classic ipython code
as possible. Even if we can't easily ensure that something behaves
correctly without lot of stubbing work (as opposed to something
obvious such as crashing), we should at least *excercise* as much of
the code as possible. If thinking about perfect test case prevents you
from writing anything, stop thinking and start writing ;-).

Additionally, I don't think unit tests need to go through code review
process. They won't break anything, and when they themselves break it
is quite obvious why ;-)

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From ondrej at certik.cz  Wed Sep 17 18:03:05 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 18 Sep 2008 00:03:05 +0200
Subject: [IPython-dev] Next PyGtk is going to rock the pylab
In-Reply-To: <46cb515a0809170029x35b10577i4cfe41d5d06085bb@mail.gmail.com>
References: <46cb515a0809170029x35b10577i4cfe41d5d06085bb@mail.gmail.com>
Message-ID: <85b5c3130809171503l12c12570rc9071e80944452e7@mail.gmail.com>

On Wed, Sep 17, 2008 at 9:29 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Once the "bleeding edge" of pygtk is released, we will have a pylab
> gtk backend that is as stable and simple as the Tk backend. I.e. no
> more threading woes.
>
> I'd like to draw everyone's attention to the discussion in this bug report:
>
> https://bugs.launchpad.net/ipython/+bug/270856

This is what I got:

Sorry

Launchpad is offline for scheduled maintenance. We should be back soon.

For more about Launchpad's maintenance schedule, check Launchpad News.

Thanks for your patience.


>
> All that is needed to create the single threaded gtk matplotlibshell
> is this (note that it does not use "gui specific" shell, just the
> launcher code is gui specific - it uses the plain vanilla
> IPython.Shell.IPShellMatplotlib()):
>
> #!/usr/bin/env python
> # -*- coding: utf-8 -*-
> """ Launch matplotlibshell using gtk """
>
> import gtk,gobject
> import IPython.Shell
> live = False
>
> def run_ipython():
>    global live
>    if live:
>        return False
>
>    live = True
>    shell = IPython.Shell.IPShellMatplotlib()
>    IPython.Shell.hijack_gtk()
>    shell.mainloop()
>
> gobject.idle_add(run_ipython)
> # the following line does not work on current pygtk
> #gtk.set_interactive(True)
> gtk.main()

This is exciting. So where was the problem previously and how was it
fixed? (if it's in the bug that I failed to access, just one or two
senteces are enough:).

Thanks,
Ondrej


From ellisonbg.net at gmail.com  Wed Sep 17 18:37:46 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 17 Sep 2008 15:37:46 -0700
Subject: [IPython-dev] Proposal to get unit test coverage as soon as
	possible
In-Reply-To: <46cb515a0809171430q4ca67661p7c85148c90aeab7@mail.gmail.com>
References: <46cb515a0809171430q4ca67661p7c85148c90aeab7@mail.gmail.com>
Message-ID: <6ce0ac130809171537g65f716bna35c970961b3a5e1@mail.gmail.com>

> I suppose we should try to cover as much of the classic ipython code
> as possible. Even if we can't easily ensure that something behaves
> correctly without lot of stubbing work (as opposed to something
> obvious such as crashing), we should at least *excercise* as much of
> the code as possible.

Yes, definitely.  For example, I just added a get_ipython_dir function
to genutils.py and the best way of testing it is too simply all it.
Of course, with nose and all the new testing capabilities that
Fernando has added, in many cases we can do more details testing.
Fernando, do you have plans on writing up some Sphinx docs in the
developer section about testing?  I know that your testing stuff does
*way* more than we are taking advantage of.

> If thinking about perfect test case prevents you
> from writing anything, stop thinking and start writing ;-).

Amen!

> Additionally, I don't think unit tests need to go through code review
> process. They won't break anything, and when they themselves break it
> is quite obvious why ;-)

I disagree with this and here it why:

* I just spent at least 3-5 full days fixing test code that was broken
in subtle ways for the 0.9 release.  The underlying code was just
fine, the tests were broken in some subtle manner.

* Getting test code right is often more difficult than getting the
underlying code right.  There are subtleties with Twisted, platform
dependencies, tests that take a very long time to run, etc., etc.

* Tests need to be documented just like regular code.

* More and more, our tests need to follow certain conventions.  For
example, we now have decorators that can be applied to test that
should be skipped on particular platforms, like @skip_win32, etc.

* IPython is getting big enough that no single person can keep track
of all of everything.  This is particularly difficult when different
parts of our code are coupled in seemingly unrelated ways.  For
example the usage of thread in pylab and in the parallel computing
stuff in IPython.kernel.

I do think that all of these things apply to testing the "older" parts
of IPython as well.

Also, I like applying code review uniformly to our code as it
encourages a very open and honest development process where we all
learn to give and take productive criticism.  One of the biggest
reasons I want universal code review, is that I want *my* code
reviwed.  Not that I write bad code, but I do at times get lazy and/or
miss things.

So, I vote for no exceptions to code review for tests

PS - because I do want everyone to start writing lots of tests, I
think it is important that all of us really make an effort to do code
reviews for this stuff promptly.

Cheers,

Brian

> --
> Ville M. Vainio
> http://tinyurl.com/vainio
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Wed Sep 17 19:54:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 17 Sep 2008 16:54:28 -0700
Subject: [IPython-dev] Proposal to get unit test coverage as soon as
	possible
In-Reply-To: <6ce0ac130809171537g65f716bna35c970961b3a5e1@mail.gmail.com>
References: <46cb515a0809171430q4ca67661p7c85148c90aeab7@mail.gmail.com>
	<6ce0ac130809171537g65f716bna35c970961b3a5e1@mail.gmail.com>
Message-ID: <db6b5ecc0809171654m56739be1g9313c079ada9031@mail.gmail.com>

Howdy,

On Wed, Sep 17, 2008 at 3:37 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I suppose we should try to cover as much of the classic ipython code
>> as possible. Even if we can't easily ensure that something behaves
>> correctly without lot of stubbing work (as opposed to something
>> obvious such as crashing), we should at least *excercise* as much of
>> the code as possible.
>
> Yes, definitely.  For example, I just added a get_ipython_dir function
> to genutils.py and the best way of testing it is too simply all it.
> Of course, with nose and all the new testing capabilities that
> Fernando has added, in many cases we can do more details testing.
> Fernando, do you have plans on writing up some Sphinx docs in the
> developer section about testing?  I know that your testing stuff does
> *way* more than we are taking advantage of.

Yes, I'm sorry that in the madness of 0.9 I just wrote all that code
and didn't explain well enough how to use it.  I'll definitely add to
the developer manual a section on testing so this is easier for
everyone to do.

> So, I vote for no exceptions to code review for tests

+1 to no exceptions, thanks for the well-reasoned discussion.


> PS - because I do want everyone to start writing lots of tests, I
> think it is important that all of us really make an effort to do code
> reviews for this stuff promptly.

Yup.  I'll try to catch up on reviews on Friday, I'm a little swamped right now.

f


From steve at shrogers.com  Thu Sep 18 09:15:44 2008
From: steve at shrogers.com (Steven H. Rogers)
Date: Thu, 18 Sep 2008 07:15:44 -0600
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
 IPython
In-Reply-To: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
Message-ID: <48D25480.4050507@shrogers.com>

If you haven't seen it, you might want to look at Philip Eby's Trellis.  
It provides nice abstractions for this sort of thing.

http://peak.telecommunity.com/DevCenter/Trellis

# Steve



From barrywark at gmail.com  Thu Sep 18 13:20:16 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 18 Sep 2008 10:20:16 -0700
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
	IPython
In-Reply-To: <48D25480.4050507@shrogers.com>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>
	<48D25480.4050507@shrogers.com>
Message-ID: <cd7634ce0809181020i286aab12p32e0e8a90a4a29cf@mail.gmail.com>

Steve,

Thanks for the pointer. From first looks, Trellis appears very similar
to Enthought's Traits package. Are you familiar with Traits? Is the
comparison valid? Understanding how these two packages relate will
help me place Trellis in the ecosystem.

Thanks,
Barry

On Thu, Sep 18, 2008 at 6:15 AM, Steven H. Rogers <steve at shrogers.com> wrote:
> If you haven't seen it, you might want to look at Philip Eby's Trellis.
> It provides nice abstractions for this sort of thing.
>
> http://peak.telecommunity.com/DevCenter/Trellis
>
> # Steve
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From barrywark at gmail.com  Thu Sep 18 13:46:15 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 18 Sep 2008 10:46:15 -0700
Subject: [IPython-dev] Proposal to get unit test coverage as soon as
	possible
In-Reply-To: <db6b5ecc0809171654m56739be1g9313c079ada9031@mail.gmail.com>
References: <46cb515a0809171430q4ca67661p7c85148c90aeab7@mail.gmail.com>
	<6ce0ac130809171537g65f716bna35c970961b3a5e1@mail.gmail.com>
	<db6b5ecc0809171654m56739be1g9313c079ada9031@mail.gmail.com>
Message-ID: <cd7634ce0809181046o26dfc1adwf26cff948136d35a@mail.gmail.com>

Has anyone investigated the nose.twistedtools API
(http://somethingaboutorange.com/mrl/projects/nose/doc/module_nose.twistedtools.html)?
Given that we've standardized on using nose for tests, it may also be
worth standardizing on using nose.twistedtools when possible so that
folks don't have to keep nose vs. trial differences in their heads (as
I've already demonstrated, I'm clearly incapable of keeping it all
straight).

-Barry

On Wed, Sep 17, 2008 at 4:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> On Wed, Sep 17, 2008 at 3:37 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> I suppose we should try to cover as much of the classic ipython code
>>> as possible. Even if we can't easily ensure that something behaves
>>> correctly without lot of stubbing work (as opposed to something
>>> obvious such as crashing), we should at least *excercise* as much of
>>> the code as possible.
>>
>> Yes, definitely.  For example, I just added a get_ipython_dir function
>> to genutils.py and the best way of testing it is too simply all it.
>> Of course, with nose and all the new testing capabilities that
>> Fernando has added, in many cases we can do more details testing.
>> Fernando, do you have plans on writing up some Sphinx docs in the
>> developer section about testing?  I know that your testing stuff does
>> *way* more than we are taking advantage of.
>
> Yes, I'm sorry that in the madness of 0.9 I just wrote all that code
> and didn't explain well enough how to use it.  I'll definitely add to
> the developer manual a section on testing so this is easier for
> everyone to do.
>
>> So, I vote for no exceptions to code review for tests
>
> +1 to no exceptions, thanks for the well-reasoned discussion.
>
>
>> PS - because I do want everyone to start writing lots of tests, I
>> think it is important that all of us really make an effort to do code
>> reviews for this stuff promptly.
>
> Yup.  I'll try to catch up on reviews on Friday, I'm a little swamped right now.
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From steve at shrogers.com  Thu Sep 18 21:52:09 2008
From: steve at shrogers.com (Steven H. Rogers)
Date: Thu, 18 Sep 2008 19:52:09 -0600
Subject: [IPython-dev] Notes on SciPy discussion about Notifications in
 IPython
In-Reply-To: <cd7634ce0809181020i286aab12p32e0e8a90a4a29cf@mail.gmail.com>
References: <6ce0ac130809161619l2d0174d1p57aba17b932a4946@mail.gmail.com>	
	<48D25480.4050507@shrogers.com>
	<cd7634ce0809181020i286aab12p32e0e8a90a4a29cf@mail.gmail.com>
Message-ID: <48D305C9.50306@shrogers.com>

Barry Wark wrote:
> Steve,
>
> Thanks for the pointer. From first looks, Trellis appears very similar
> to Enthought's Traits package. Are you familiar with Traits? Is the
> comparison valid? Understanding how these two packages relate will
> help me place Trellis in the ecosystem.
>
> Thanks,
> Barry
>   
Barry:

I've played with Trellis a bit, but not Traits.  I believe that traits 
requires a Python extension in C where Trellis is pure Python.  Traits 
appears to be GUI centric while Trellis tries to be more general.  I 
need to implement a small project in both to get a better idea of their 
relative strengths.

Regards,
Steve



From lukpank at o2.pl  Fri Sep 19 08:05:25 2008
From: lukpank at o2.pl (=?utf-8?Q?=C5=81ukasz?= Pankowski)
Date: Fri, 19 Sep 2008 14:05:25 +0200
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
Message-ID: <87od2kxrwa.fsf@ash.lupan-home>

Hello

This is a week since I'm using IPython (for now as a shell under
Emacs) and I really like it.  I attach three patches (for revno: 1147)
to the problems I have found, demo---stop---.diff is an obvious one
line fix that should go to 0.9 branch, the rest depend on your taste.


demo---stop---.diff:
allow multiple dashes in `# <demo> --- stop ---' (as used in example-demo.py)

(Just s/-?/-*/ in a regexp to make docs/examples/core/example-demo.py working)


slashslash-tildeslash-prefilter.diff:
now not only ./foo but also ~/foo and /bin/foo run foo as system command

(as ~/foo and /bin/foo are not valid python even with automatic
parenthesis)


TryNext-if-editor-fail.diff:
raise TryNext if editor fails and does not execute code if all editors fail

When os.system returns non zero code the editor failed, and IMHO it
should not be left silent (for me it means emacsclient could not
connect to the server) than:
1. The next editor is tried (raising TryNext)
2. If all editors failed the code is not executed by %edit or -autoedit_syntax.


Thanks for IPython!
?ukasz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo---stop---.diff
Type: text/x-diff
Size: 453 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080919/f9f32fd6/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slashslash-tildeslash-prefilter.diff
Type: text/x-diff
Size: 1349 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080919/f9f32fd6/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TryNext-if-editor-fail.diff
Type: text/x-diff
Size: 2913 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080919/f9f32fd6/attachment-0002.diff>

From vivainio at gmail.com  Fri Sep 19 08:51:26 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 19 Sep 2008 15:51:26 +0300
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
In-Reply-To: <87od2kxrwa.fsf@ash.lupan-home>
References: <87od2kxrwa.fsf@ash.lupan-home>
Message-ID: <46cb515a0809190551t5acb9bf9y971ce94ca6361dc2@mail.gmail.com>

On Fri, Sep 19, 2008 at 3:05 PM, ?ukasz Pankowski <lukpank at o2.pl> wrote:

> This is a week since I'm using IPython (for now as a shell under
> Emacs) and I really like it.  I attach three patches (for revno: 1147)
> to the problems I have found, demo---stop---.diff is an obvious one
> line fix that should go to 0.9 branch, the rest depend on your taste.

I like these patches, they will all go in.

However, regarding the editor hook patch - could you make it raise
UsageError instead of warn, try it out a bit and send a new patch?

-- 
Ville M. Vainio
http://tinyurl.com/vainio

From lukpank at o2.pl  Fri Sep 19 18:21:38 2008
From: lukpank at o2.pl (=?utf-8?Q?=C5=81ukasz?= Pankowski)
Date: Sat, 20 Sep 2008 00:21:38 +0200
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
In-Reply-To: <46cb515a0809190551t5acb9bf9y971ce94ca6361dc2@mail.gmail.com>
	(Ville M. Vainio's message of "Fri\,
	19 Sep 2008 15\:51\:26 +0300")
References: <87od2kxrwa.fsf@ash.lupan-home>
	<46cb515a0809190551t5acb9bf9y971ce94ca6361dc2@mail.gmail.com>
Message-ID: <877i97wzd9.fsf@ash.lupan-home>

"Ville M. Vainio" <vivainio at gmail.com> writes:

> On Fri, Sep 19, 2008 at 3:05 PM, ?ukasz Pankowski <lukpank at o2.pl> wrote:
>
>> This is a week since I'm using IPython (for now as a shell under
>> Emacs) and I really like it.  I attach three patches (for revno: 1147)
>> to the problems I have found, demo---stop---.diff is an obvious one
>> line fix that should go to 0.9 branch, the rest depend on your taste.
>
> I like these patches, they will all go in.
>
> However, regarding the editor hook patch - could you make it raise
> UsageError instead of warn, try it out a bit and send a new patch?

Ok, done.  It required catching UsageError in all three calls to
InteractiveShell.edit_syntax_error().  Otherwise UsageError would go
out of InteractiveShell.interact and show crash report or (in case of
wxIPython) out of NonBlockingIPShell._execute with traceback in the
console and unusable wxIPython shell.

NOTE: This time I left in the patch a hunk fixing no newline in
ipy_editors.py as GNU Emacs tends to require final newline in Python
mode by default and I do not want to fight with Emacs here.

>
> -- 
> Ville M. Vainio
> http://tinyurl.com/vainio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TryNext-UsageError-if-editor-fail.diff
Type: text/x-diff
Size: 4726 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080920/d1a95012/attachment.diff>

From vivainio at gmail.com  Sat Sep 20 05:26:58 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 20 Sep 2008 12:26:58 +0300
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
In-Reply-To: <877i97wzd9.fsf@ash.lupan-home>
References: <87od2kxrwa.fsf@ash.lupan-home>
	<46cb515a0809190551t5acb9bf9y971ce94ca6361dc2@mail.gmail.com>
	<877i97wzd9.fsf@ash.lupan-home>
Message-ID: <46cb515a0809200226i598a51aw258870dff41ccaf7@mail.gmail.com>

On Sat, Sep 20, 2008 at 1:21 AM, ?ukasz Pankowski <lukpank at o2.pl> wrote:

> Ok, done.  It required catching UsageError in all three calls to
> InteractiveShell.edit_syntax_error().  Otherwise UsageError would go

Ok, that won't do then. I'll commit the original patchset.

-- 
Ville M. Vainio
http://tinyurl.com/vainio

From robert.kern at gmail.com  Mon Sep 22 17:23:35 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 22 Sep 2008 16:23:35 -0500
Subject: [IPython-dev] An idea: unique synthetic filenames
Message-ID: <gb92cp$qes$1@ger.gmane.org>

Currently, for each In[], we compile the input to a code object with a fake 
filename like "<string>" or "<ipython console>". If we were to generate a unique 
fake filename for each input, say "<ipython console 10>" to correspond with 
In[10], we could then stuff the text into linecache. This will be used in 
tracebacks and other similar tools (like my line_profiler).

Worth a shot?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From gael.varoquaux at normalesup.org  Tue Sep 23 14:57:16 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 23 Sep 2008 20:57:16 +0200
Subject: [IPython-dev] An idea: unique synthetic filenames
In-Reply-To: <gb92cp$qes$1@ger.gmane.org>
References: <gb92cp$qes$1@ger.gmane.org>
Message-ID: <20080923185716.GE20503@phare.normalesup.org>

On Mon, Sep 22, 2008 at 04:23:35PM -0500, Robert Kern wrote:
> Currently, for each In[], we compile the input to a code object with a fake 
> filename like "<string>" or "<ipython console>". If we were to generate a unique 
> fake filename for each input, say "<ipython console 10>" to correspond with 
> In[10], we could then stuff the text into linecache. This will be used in 
> tracebacks and other similar tools (like my line_profiler).

> Worth a shot?

Seems like a good idea to me.

Ga?l


From hans_meine at gmx.net  Wed Sep 24 08:11:11 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 24 Sep 2008 14:11:11 +0200
Subject: [IPython-dev] Pylab support: How about dynamic backend selection?
Message-ID: <200809241411.12898.hans_meine@gmx.net>

Hi,

right now, IPython has special thread support for different GUI backends, and 
special support for MPL/pylab.  AFAIK, when I specify -pylab on the cmdline, 
ipython will choose the "right" GUI toolkit depending on my matplotlibrc 
backend setting.  However, I sometimes need Qt4 and sometimes WX support, 
which are both supported by MPL, but the -pylab overwrites the threading 
switch.

My suggestion is to let the -pylab switch gracefully handle -foothread 
switches by internally calling matplotlib.use(...) to let MPL use the same 
GUI toolkit that has been specified on the cmdline.

What do you think?

Greetings,
  Hans


From hans_meine at gmx.net  Wed Sep 24 08:22:28 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 24 Sep 2008 14:22:28 +0200
Subject: [IPython-dev] An idea: unique synthetic filenames
In-Reply-To: <gb92cp$qes$1@ger.gmane.org>
References: <gb92cp$qes$1@ger.gmane.org>
Message-ID: <200809241422.30090.hans_meine@gmx.net>

Am Montag, 22. September 2008 23:23:35 schrieb Robert Kern:
> Currently, for each In[], we compile the input to a code object with a fake
> filename like "<string>" or "<ipython console>". If we were to generate a
> unique fake filename for each input, say "<ipython console 10>" to
> correspond with In[10], we could then stuff the text into linecache. This
> will be used in tracebacks and other similar tools (like my line_profiler).

Nice idea!  Even without the linecache, I'd like the more verbose source 
indication.

Greetings,
  Hans


From gael.varoquaux at normalesup.org  Wed Sep 24 08:23:39 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 24 Sep 2008 14:23:39 +0200
Subject: [IPython-dev] Pylab support: How about dynamic
	backend	selection?
In-Reply-To: <200809241411.12898.hans_meine@gmx.net>
References: <200809241411.12898.hans_meine@gmx.net>
Message-ID: <20080924122339.GL1535@phare.normalesup.org>

On Wed, Sep 24, 2008 at 02:11:11PM +0200, Hans Meine wrote:
> right now, IPython has special thread support for different GUI
> backends, and
> special support for MPL/pylab.  AFAIK, when I specify -pylab on the
> cmdline,
> ipython will choose the "right" GUI toolkit depending on my
> matplotlibrc
> backend setting.  However, I sometimes need Qt4 and sometimes WX
> support,
> which are both supported by MPL, but the -pylab overwrites the
> threading
> switch.

> My suggestion is to let the -pylab switch gracefully handle -foothread
> switches by internally calling matplotlib.use(...) to let MPL use the
> same
> GUI toolkit that has been specified on the cmdline.

In the latest ipython, this behavior should be possible:

ipython "-pylab -wthread" should be running matplotlib with the Wx
support.


Ga?l


From hans_meine at gmx.net  Wed Sep 24 14:29:15 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 24 Sep 2008 20:29:15 +0200
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
In-Reply-To: <46cb515a0809200226i598a51aw258870dff41ccaf7@mail.gmail.com>
References: <87od2kxrwa.fsf@ash.lupan-home> <877i97wzd9.fsf@ash.lupan-home>
	<46cb515a0809200226i598a51aw258870dff41ccaf7@mail.gmail.com>
Message-ID: <200809242029.16047.hans_meine@gmx.net>

On Samstag 20 September 2008, Ville M. Vainio wrote:
> On Sat, Sep 20, 2008 at 1:21 AM, ?ukasz Pankowski <lukpank at o2.pl> wrote:
> > Ok, done.  It required catching UsageError in all three calls to
> > InteractiveShell.edit_syntax_error().  Otherwise UsageError would go
>
> Ok, that won't do then. I'll commit the original patchset.

What about tests?  Aren't there tests nowadays for the prefilters?
/me ducks..

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080924/c4b82455/attachment.sig>

From vivainio at gmail.com  Wed Sep 24 15:27:31 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 24 Sep 2008 22:27:31 +0300
Subject: [IPython-dev] three patches: dashes in demo; /bin/foo, ~/foo;
	checking returned code from the editor
In-Reply-To: <200809242029.16047.hans_meine@gmx.net>
References: <87od2kxrwa.fsf@ash.lupan-home> <877i97wzd9.fsf@ash.lupan-home>
	<46cb515a0809200226i598a51aw258870dff41ccaf7@mail.gmail.com>
	<200809242029.16047.hans_meine@gmx.net>
Message-ID: <46cb515a0809241227k8944e89o65e7192c62fce860@mail.gmail.com>

2008/9/24 Hans Meine <hans_meine at gmx.net>:

>> Ok, that won't do then. I'll commit the original patchset.
>
> What about tests?  Aren't there tests nowadays for the prefilters?
> /me ducks..

There are, but not integrated with current nose tests just yet.
Unfortunately, for stuff in profiles to be testable (==importable
without running), we would have to change the way profiles are loaded,
or extract the stuff to external module and use ipy_profile_FOO files
merely as loaders.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From f.wenzel at gmx.net  Thu Sep 25 06:55:40 2008
From: f.wenzel at gmx.net (Fabian Wenzel)
Date: Thu, 25 Sep 2008 12:55:40 +0200
Subject: [IPython-dev] Embed wxIPython/WxController in own app: How to
	access variables?
Message-ID: <1011746816@web.de>

Hi list,

today, I played a little bit with embedding the wxIPython and WxController shell into an own wxPySimpleApp as a widget in order to add some interaction/scripting techniques. In both shells I do not have access to the variables of my app, so I cannot control/script it. Using the shell that comes with wx.py.shell.Shell (the old PyCrust-shell) does not provide all the nice features IPython brings along, but variable access is possible.

Does anybody have some information on how to accomplish this?

Thanks,

      Fabian


_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114



From gael.varoquaux at normalesup.org  Thu Sep 25 07:33:48 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 25 Sep 2008 13:33:48 +0200
Subject: [IPython-dev] Embed wxIPython/WxController in own app: How
	to	access variables?
In-Reply-To: <1011746816@web.de>
References: <1011746816@web.de>
Message-ID: <20080925113348.GD28008@phare.normalesup.org>

On Thu, Sep 25, 2008 at 12:55:40PM +0200, Fabian Wenzel wrote:
> today, I played a little bit with embedding the wxIPython and WxController shell into an own wxPySimpleApp as a widget in order to add some interaction/scripting techniques. In both shells I do not have access to the variables of my app, so I cannot control/script it. Using the shell that comes with wx.py.shell.Shell (the old PyCrust-shell) does not provide all the nice features IPython brings along, but variable access is possible.

> Does anybody have some information on how to accomplish this?

Yes. Well, I am not too sure what you are trying to accomplish. If you
simply want to access the namespace, it is the
wx_controller.shell.user_ns attribute: a dictionary object with the local
namespace.

Now if you want to pass in your own namespace (say it is a reference to a
shared dictionnary that you are using some place else in your
application), the WxController accepts an interpreter as a keyword
argument in its constructor. The interpreter also accepts a keyword
argument to the namespace, so you can have something like this:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
namespace = dict()

from IPython.frontend.wx.wx_frontend import WxController
from IPython.kernel.core.interpreter import Interpreter

interp = Interpreter(user_ns=namespace)

# Here you can play with your interpreter, eg evaluate commands in it,
# without an UI. This is your model, in the MVC pattern

# ...

my_widget = WxController(parent, size, ..., shell=interp)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Does this answer your question?

One remark: the Wx frontend code is pretty much a first cut
implementation. It has some rough edges, and I am very unhappy about some
design decisions. Hopefully I'll find time to improve it. I might break
some downstream code when fixing this code (specifically, I am not happy
at all with the poor MVC separation of the code, and the fact that the
representation model is not well-defined outside the view). Please do
consider this as a technology preview: it can be useful, but it is still
code in movement.

HTH,

Ga?l


From f.wenzel at gmx.net  Thu Sep 25 09:39:44 2008
From: f.wenzel at gmx.net (Fabian Wenzel)
Date: Thu, 25 Sep 2008 15:39:44 +0200
Subject: [IPython-dev]
 =?iso-8859-15?q?Embed_wxIPython/WxController_in_own?=
 =?iso-8859-15?q?_app=3A_How_to_access_variables=3F?=
Message-ID: <1012212172@web.de>

Hi,

thanks for your fast reply - I tried the code you posted in your answer but still could not get access to variables. So I believe I did not understand all details of your answer, and that may very well be because you were not sure what I was trying to accomplish. So here is some "dummy" example code:

++++++++++++++++++++++++

# Some class here...
class Testclass():
   def __init__(self):
      self.member = "SOMETHING"

# Some function here...
def Testfunc(instance):
   instance.member = "SOMETHINGELSE"

# Main program
if __name__ == "__main__":
   import wx
   from IPython.frontend.wx.wx_frontend import WxController
   from IPython.kernel.core.interpreter import Interpreter

   # These variable should be accessible from the shell below
   testinstance = Testclass()

   # Generate frame
   app = wx.PySimpleApp()
   frame = wx.Frame(None,wx.ID_ANY)

   # Generate shell child
   shell = WxController(frame,wx.ID_ANY)

   frame.Show()
   app.MainLoop()

+++++++++++++++++++++++++++++++++++++++++++

I did not check the code for errors, also some things are definitely missing
(sizers etc., I just typed it into this e-mail), but the idea is that
in the shell that I create above, I would like to type something like

Testfunc(testinstance)

as both, the function and the instance of Testclass() have been defined before. In PyCrust, this is possible.

Maybe I just did not get the meaning of the namespace and dictionary?


Regards,

           Fabian


> Yes. Well, I am not too sure what you are trying to accomplish. If you
> simply want to access the namespace, it is the
> wx_controller.shell.user_ns attribute: a dictionary object with the local
> namespace.
> 
> Now if you want to pass in your own namespace (say it is a reference to a
> shared dictionnary that you are using some place else in your
> application), the WxController accepts an interpreter as a keyword
> argument in its constructor. The interpreter also accepts a keyword
> argument to the namespace, so you can have something like this:
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> namespace = dict()
> 
> from IPython.frontend.wx.wx_frontend import WxController
> from IPython.kernel.core.interpreter import Interpreter
> 
> interp = Interpreter(user_ns=namespace)
> 
> # Here you can play with your interpreter, eg evaluate commands in it,
> # without an UI. This is your model, in the MVC pattern
> 
> # ...
> 
> my_widget = WxController(parent, size, ..., shell=interp)
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Does this answer your question?
> 
> One remark: the Wx frontend code is pretty much a first cut
> implementation. It has some rough edges, and I am very unhappy about some
> design decisions. Hopefully I'll find time to improve it. I might break
> some downstream code when fixing this code (specifically, I am not happy
> at all with the poor MVC separation of the code, and the fact that the
> representation model is not well-defined outside the view). Please do
> consider this as a technology preview: it can be useful, but it is still
> code in movement.
> 
> HTH,
> 
> Ga?l
> 
> 


____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger geh?rt? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123



From fperez.net at gmail.com  Fri Sep 26 16:07:04 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 26 Sep 2008 13:07:04 -0700
Subject: [IPython-dev] An idea: unique synthetic filenames
In-Reply-To: <gb92cp$qes$1@ger.gmane.org>
References: <gb92cp$qes$1@ger.gmane.org>
Message-ID: <db6b5ecc0809261307r6d9d3cc0mf0d80d32b577b378@mail.gmail.com>

On Mon, Sep 22, 2008 at 2:23 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Currently, for each In[], we compile the input to a code object with a fake
> filename like "<string>" or "<ipython console>". If we were to generate a unique
> fake filename for each input, say "<ipython console 10>" to correspond with
> In[10], we could then stuff the text into linecache. This will be used in
> tracebacks and other similar tools (like my line_profiler).
>
> Worth a shot?

Definitely!  I like it a lot: simple to implement and with good payoff.

Cheers,

f


From fperez.net at gmail.com  Fri Sep 26 16:08:30 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 26 Sep 2008 13:08:30 -0700
Subject: [IPython-dev] Pylab support: How about dynamic backend
	selection?
In-Reply-To: <20080924122339.GL1535@phare.normalesup.org>
References: <200809241411.12898.hans_meine@gmx.net>
	<20080924122339.GL1535@phare.normalesup.org>
Message-ID: <db6b5ecc0809261308n6993d583m829973f3e7d7fd15@mail.gmail.com>

On Wed, Sep 24, 2008 at 5:23 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Wed, Sep 24, 2008 at 02:11:11PM +0200, Hans Meine wrote:
>> right now, IPython has special thread support for different GUI
>> backends, and
>> special support for MPL/pylab.  AFAIK, when I specify -pylab on the
>> cmdline,
>> ipython will choose the "right" GUI toolkit depending on my
>> matplotlibrc
>> backend setting.  However, I sometimes need Qt4 and sometimes WX
>> support,
>> which are both supported by MPL, but the -pylab overwrites the
>> threading
>> switch.
>
>> My suggestion is to let the -pylab switch gracefully handle -foothread
>> switches by internally calling matplotlib.use(...) to let MPL use the
>> same
>> GUI toolkit that has been specified on the cmdline.
>
> In the latest ipython, this behavior should be possible:
>
> ipython "-pylab -wthread" should be running matplotlib with the Wx
> support.

Yup, this was added a while ago already, and I use it all the time.
So Hans, you should be in business if you're running a recent ipython.

It's always nice when the time machine works :)

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Sep 28 17:27:59 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 28 Sep 2008 23:27:59 +0200
Subject: [IPython-dev] Embed wxIPython/WxController in own app: How
	to	access variables?
In-Reply-To: <1012212172@web.de>
References: <1012212172@web.de>
Message-ID: <20080928212759.GC25435@phare.normalesup.org>

Hi, 

Sorry for being slow to reply, I was travelling this week end.

On Thu, Sep 25, 2008 at 03:39:44PM +0200, Fabian Wenzel wrote:
> thanks for your fast reply - I tried the code you posted in your answer
> but still could not get access to variables. So I believe I did not
> understand all details of your answer, and that may very well be
> because you were not sure what I was trying to accomplish. So here is
> some "dummy" example code:

> ++++++++++++++++++++++++

> # Some class here...
> class Testclass():
>    def __init__(self):
>       self.member = "SOMETHING"

> # Some function here...
> def Testfunc(instance):
>    instance.member = "SOMETHINGELSE"

> # Main program
> if __name__ == "__main__":
>    import wx
>    from IPython.frontend.wx.wx_frontend import WxController
>    from IPython.kernel.core.interpreter import Interpreter

>    # These variable should be accessible from the shell below
>    testinstance = Testclass()

>    # Generate frame
>    app = wx.PySimpleApp()
>    frame = wx.Frame(None,wx.ID_ANY)

>    # Generate shell child
>    shell = WxController(frame,wx.ID_ANY)

>    frame.Show()
>    app.MainLoop()

> +++++++++++++++++++++++++++++++++++++++++++

> I did not check the code for errors, also some things are definitely missing
> (sizers etc., I just typed it into this e-mail), but the idea is that
> in the shell that I create above, I would like to type something like

> Testfunc(testinstance)

> as both, the function and the instance of Testclass() have been defined before. In PyCrust, this is possible.

> Maybe I just did not get the meaning of the namespace and dictionary?

:). I think you should try to learn a bit what a dictionnary is in
Python, and understand the concept of namespace to do these things, but
anyhow, I'll try to help you right away. I don't have the code installed
on this computer, so I'll just try and modify your code. I can't garanty
that the resulting code will actually run :).

++++++++++++++++++++++++

# Some class here...
class Testclass():
   def __init__(self):
      self.member = "SOMETHING"

# Some function here...
def Testfunc(instance):
   instance.member = "SOMETHINGELSE"

# Main program
if __name__ == "__main__":

   import wx
   from IPython.frontend.wx.wx_frontend import WxController
   from IPython.kernel.core.interpreter import Interpreter

   # This variable should be accessible from the shell below
   testinstance = Testclass()

   # Here is a dictionnary which will be the namespace in which our shell
   # runs. We bind the variables we are interested in accessing in it.
   namespace = dict()
   namespace['testinstance'] = testinstance
   namespace['Testfunc'] = Testfunc
   interp = Interpreter(user_ns=namespace)

   # Generate frame
   app = wx.PySimpleApp()
   frame = wx.Frame(None, wx.ID_ANY)

   # Generate shell child
   shell = WxController(frame, wx.ID_ANY, shell=interp)

   frame.Show()
   app.MainLoop()

+++++++++++++++++++++++++++++++++++++++++++

HTH,

Ga?l


From vivainio at gmail.com  Tue Sep 30 17:05:09 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 1 Oct 2008 00:05:09 +0300
Subject: [IPython-dev] Fwd: IPython Crash Report
In-Reply-To: <C240AB86555DA948A19AC0CBAB4D428402A39122@NAMAIL.sapient.com>
References: <C240AB86555DA948A19AC0CBAB4D428402A39122@NAMAIL.sapient.com>
Message-ID: <46cb515a0809301405n5b393e33vd4e895acd82982df@mail.gmail.com>

---------- Forwarded message ----------
From: Kevin Northover <knorthover at sapient.com>
Date: Wed, Oct 1, 2008 at 12:02 AM
Subject: IPython Crash Report
To: "vivainio at gmail.com" <vivainio at gmail.com>


***************************************************************************

IPython post-mortem report

IPython version: 0.9.1

SVN revision   : 1145

Platform info  : os.name -> nt, sys.platform -> win32

***************************************************************************

Current user configuration structure:

{'Version': 0,
'__allownew': False,
'alias': [],
'args': [],
'autocall': 2,
'autoedit_syntax': 0,
'autoexec': [],
'autoindent': 1,
'automagic': 1,
'banner': 'IPython 0.9.1   [on Py 2.5.2]\n',
'c': '',
'cache_size': 1000,
'classic': 0,
'color_info': 1,
'colors': 'Linux',
'confirm_exit': 1,
'debug': 0,
'deep_reload': 0,
'editor': 'D:\\Apps\\IDM Computer Solutions\\UltraEdit-32\\uedit32.exe',
'embedded': False,
'execfile': [],
'execute': [''],
'gthread': 0,
'help': 0,
'import_all': [],
'import_mod': [],
'import_some': [[]],
'include': [],
'interact': 0,
'ipythondir': 'C:\\Documents and Settings\\knorth\\_ipython',
'log': 0,
'logfile': '',
'logplay': '',
'magic_docstrings': 0,
'messages': 1,
'multi_line_specials': 1,
'nosep': 0,
'object_info_string_level': 0,
'opts': Struct({'__allownew': True, 'logfile': 'critical_log.txt', 'pylab': 1}),
'pdb': 0,
'pprint': 1,
'profile': '',
'prompt_in1': '\\C_LightBlue[\\C_LightCyan\\Y2\\C_LightBlue]\\C_Green|\\#> ',
'prompt_in2': '\\C_Green|\\C_LightGreen\\D\\C_Green> ',
'prompt_out': '<\\#> ',
'prompts_pad_left': '1',
'pydb': 0,
'pylab': 1,
'pylab_import_all': 1,
'q4thread': 0,
'qthread': 0,
'quick': 0,
'quiet': 0,
'rcfile': 'ipythonrc.ini',
'readline': 1,
'readline_merge_completions': 1,
'readline_omit__names': 0,
'readline_parse_and_bind': ['tab: complete',
                             '"\\C-l": possible-completions',
                             'set show-all-if-ambiguous on',
                             '"\\C-o": tab-insert',
                             '"\\M-i": "    "',
                             '"\\M-o": "\\d\\d\\d\\d"',
                             '"\\M-I": "\\d\\d\\d\\d"',
                             '"\\C-r": reverse-search-history',
                             '"\\C-s": forward-search-history',
                             '"\\C-p": history-search-backward',
                             '"\\C-n": history-search-forward',
                             '"\\e[A": history-search-backward',
                             '"\\e[B": history-search-forward',
                             '"\\C-k": kill-line',
                             '"\\C-u": unix-line-discard'],
'readline_remove_delims': '-/~',
'screen_length': -1,
'separate_in': '',
'separate_out': '',
'separate_out2': '',
'system_header': 'IPython system call: ',
'system_verbose': 0,
'term_title': 1,
'tk': 0,
'upgrade': 0,
'wildcards_case_sensitive': 1,
'wthread': 0,
'wxversion': '0',
'xmode': 'Context'}

***************************************************************************

Crash traceback:

---------------------------------------------------------------------------
TypeError                         Python 2.5.2: D:\Apps\python25\python.exe
                                                   Tue Sep 30 16:58:29 2008
A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

D:\Apps\python25\scripts\ipython.py in <module>()
     13
     14 [or simply IPython.Shell.IPShell().mainloop(1) ]
     15
     16 and IPython will be your working environment when you start
python. The final
     17 sys.exit() call will make python exit transparently when
IPython finishes, so
     18 you don't have an extra prompt to get out of.
     19
     20 This is probably useful to developers who manage multiple
Python versions and
     21 don't want to have correspondingly multiple IPython versions.
Note that in
     22 this mode, there is no way to pass IPython any command-line
options, as those
     23 are trapped first by Python itself.
     24 """
     25
     26 import IPython.Shell
     27
---> 28 IPython.Shell.start().mainloop()
        global IPython.Shell.start.mainloop = undefined
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43

D:\Apps\python25\lib\site-packages\IPython\Shell.pyc in
mainloop(self=<IPython.Shell.IPShellMatplotlib instance at
0x013416E8>, sys_exit=0, banner=None)
     66 #-----------------------------------------------------------------------------
     67 # This class is trivial now, but I want to have it in to publish a clean
     68 # interface. Later when the internals are reorganized, code
that uses this
     69 # shouldn't have to change.
     70
     71 class IPShell:
     72     """Create an IPython instance."""
     73
     74     def __init__(self,argv=None,user_ns=None,user_global_ns=None,
     75                  debug=1,shell_class=InteractiveShell):
     76         self.IP = make_IPython(argv,user_ns=user_ns,
     77                                user_global_ns=user_global_ns,
     78                                debug=debug,shell_class=shell_class)
     79
     80     def mainloop(self,sys_exit=0,banner=None):
---> 81         self.IP.mainloop(banner)
        global resumes. = undefined
     82         if sys_exit:
     83             sys.exit()
     84
     85 #-----------------------------------------------------------------------------
     86 def kill_embedded(self,parameter_s=''):
     87     """%kill_embedded : deactivate for good the current
embedded IPython.
     88
     89     This function (after asking for confirmation) sets an
internal flag so that
     90     an embedded IPython will never activate again.  This is useful to
     91     permanently disable a shell that is being called inside a
loop: once you've
     92     figured out what you needed from it, you may then kill it
and the program
     93     will then continue to run without the interactive shell
interfering again.
     94     """
     95
     96     kill = ask_yes_no("Are you sure you want to kill this
embedded instance "

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
mainloop(self=<IPython.Shell.MatplotlibShell object at 0x00BF0E30>,
banner='IPython 0.9.1   [on Py 2.5.2]\n')
   1562         internally created default banner."""
   1563
   1564         if self.rc.c:  # Emulate Python's -c option
   1565             self.exec_init_cmd()
   1566         if banner is None:
   1567             if not self.rc.banner:
   1568                 banner = ''
   1569             # banner is string? Use it directly!
   1570             elif isinstance(self.rc.banner,basestring):
   1571                 banner = self.rc.banner
   1572             else:
   1573                 banner = self.BANNER+self.banner2
   1574
   1575         while 1:
   1576             try:
-> 1577                 self.interact(banner)
   1578                 #self.interact_with_readline()
   1579                 # XXX for testing of a readline-decoupled repl
loop, call interact_with_readline above
   1580
   1581                 break
   1582             except KeyboardInterrupt:
   1583                 # this should not be necessary, but KeyboardInterrupt
   1584                 # handling seems rather unpredictable...
   1585                 self.write("\nKeyboardInterrupt in interact()\n")
   1586
   1587     def exec_init_cmd(self):
   1588         """Execute a command given at the command line.
   1589
   1590         This emulates Python's -c option."""
   1591
   1592         #sys.argv = ['-c']

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
interact(self=<IPython.Shell.MatplotlibShell object at 0x00BF0E30>,
banner='IPython 0.9.1   [on Py 2.5.2]\n')
   1798                 if self.autoindent:
   1799                     self.rl_do_indent = False
   1800                     self.readline_startup_hook(None)
   1801                 self.write('\n')
   1802                 self.exit()
   1803             except bdb.BdbQuit:
   1804                 warn('The Python debugger has exited with a
BdbQuit exception.\n'
   1805                      'Because of how pdb handles the stack, it
is impossible\n'
   1806                      'for IPython to properly format this
particular exception.\n'
   1807                      'IPython will resume normal operation.')
   1808             except:
   1809                 # exceptions here are VERY RARE, but they can
be triggered
   1810                 # asynchronously by signal handlers, for example.
   1811                 self.showtraceback()
   1812             else:
-> 1813                 more = self.push(line)
   1814                 if (self.SyntaxTB.last_syntax_error and
   1815                     self.rc.autoedit_syntax):
   1816                     self.edit_syntax_error()
   1817
   1818         # We are off again...
   1819         __builtin__.__dict__['__IPYTHON__active'] -= 1
   1820
   1821     def excepthook(self, etype, value, tb):
   1822       """One more defense for GUI apps that call sys.excepthook.
   1823
   1824       GUI frameworks like wxPython trap exceptions and call
   1825       sys.excepthook themselves.  I guess this is a feature that
   1826       enables them to keep running after exceptions that would
   1827       otherwise kill their mainloop. This is a bother for IPython
   1828       which excepts to catch all of the program exceptions with a try:

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
push(self=<IPython.Shell.MatplotlibShell object at 0x00BF0E30>,
line=u'C.grid_layout(G)')
   2103         is reset; otherwise, the command is incomplete, and the buffer
   2104         is left as it was after the line was appended.  The return
   2105         value is 1 if more input is required, 0 if the line was dealt
   2106         with in some way (this is the same as runsource()).
   2107         """
   2108
   2109         # autoindent management should be done here, and not in the
   2110         # interactive loop, since that one is only seen by
keyboard input.  We
   2111         # need this done correctly even for code run via
runlines (which uses
   2112         # push).
   2113
   2114         #print 'push line: <%s>' % line  # dbg
   2115         for subline in line.splitlines():
   2116             self.autoindent_update(subline)
   2117         self.buffer.append(line)
-> 2118         more = self.runsource('\n'.join(self.buffer), self.filename)
   2119         if not more:
   2120             self.resetbuffer()
   2121         return more
   2122
   2123     def split_user_input(self, line):
   2124         # This is really a hold-over to support ipapi and some
extensions
   2125         return prefilter.splitUserInput(line)
   2126
   2127     def resetbuffer(self):
   2128         """Reset the input buffer."""
   2129         self.buffer[:] = []
   2130
   2131     def raw_input(self,prompt='',continue_prompt=False):
   2132         """Write a prompt and read a line.
   2133

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
runsource(self=<IPython.Shell.MatplotlibShell object at 0x00BF0E30>,
source='C.grid_layout(G)', filename='<ipython console>',
symbol='single')
   2029             # Case 1
   2030             self.showsyntaxerror(filename)
   2031             return None
   2032
   2033         if code is None:
   2034             # Case 2
   2035             return True
   2036
   2037         # Case 3
   2038         # We store the code object so that threaded shells and
   2039         # custom exception handlers can access all this info if needed.
   2040         # The source corresponding to this can be obtained from the
   2041         # buffer attribute as '\n'.join(self.buffer).
   2042         self.code_to_run = code
   2043         # now actually execute the code object
-> 2044         if self.runcode(code) == 0:
   2045             return False
   2046         else:
   2047             return None
   2048
   2049     def runcode(self,code_obj):
   2050         """Execute a code object.
   2051
   2052         When an exception occurs, self.showtraceback() is
called to display a
   2053         traceback.
   2054
   2055         Return value: a flag indicating whether the code to be
run completed
   2056         successfully:
   2057
   2058           - 0: successful execution.
   2059           - 1: an error occurred.

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
runcode(self=<IPython.Shell.MatplotlibShell object at 0x00BF0E30>,
code_obj=<code object <module> at 00BE3800, file "<ipython console>",
line 1>)
   2071             try:
   2072                 self.hooks.pre_runcode_hook()
   2073                 exec code_obj in self.user_global_ns, self.user_ns
   2074             finally:
   2075                 # Reset our crash handler in place
   2076                 sys.excepthook = old_excepthook
   2077         except SystemExit:
   2078             self.resetbuffer()
   2079             self.showtraceback()
   2080             warn("Type %exit or %quit to exit IPython "
   2081                  "(%Exit or %Quit do so unconditionally).",level=1)
   2082         except self.custom_exceptions:
   2083             etype,value,tb = sys.exc_info()
   2084             self.CustomTB(etype,value,tb)
   2085         except:
-> 2086             self.showtraceback()
   2087         else:
   2088             outflag = 0
   2089             if softspace(sys.stdout, 0):
   2090                 print
   2091         # Flush out code object which has been run (and source)
   2092         self.code_to_run = None
   2093         return outflag
   2094
   2095     def push(self, line):
   2096         """Push a line to the interpreter.
   2097
   2098         The line should not have a trailing newline; it may have
   2099         internal newlines.  The line is appended to a buffer and the
   2100         interpreter's runsource() method is called with the
   2101         concatenated contents of the buffer as source.  If this

D:\Apps\python25\lib\site-packages\IPython\iplib.pyc in
showtraceback(self=<IPython.Shell.MatplotlibShell object at
0x00BF0E30>, exc_tuple=None, filename=None, tb_offset=None)
   1534                 self.showsyntaxerror(filename)
   1535             elif etype is IPython.ipapi.UsageError:
   1536                 print "UsageError:", value
   1537             else:
   1538                 # WARNING: these variables are somewhat
deprecated and not
   1539                 # necessarily safe to use in a threaded
environment, but tools
   1540                 # like pdb depend on their existence, so let's
set them.  If we
   1541                 # find problems in the field, we'll need to
revisit their use.
   1542                 sys.last_type = etype
   1543                 sys.last_value = value
   1544                 sys.last_traceback = tb
   1545
   1546                 if etype in self.custom_exceptions:
   1547                     self.CustomTB(etype,value,tb)
   1548                 else:
-> 1549
self.InteractiveTB(etype,value,tb,tb_offset=tb_offset)
   1550                     if self.InteractiveTB.call_pdb and
self.has_readline:
   1551                         # pdb mucks up readline, fix it back
   1552                         self.set_completer()
   1553         except KeyboardInterrupt:
   1554             self.write("\nKeyboardInterrupt\n")
   1555
   1556
   1557
   1558     def mainloop(self,banner=None):
   1559         """Creates the local namespace and starts the mainloop.
   1560
   1561         If an optional banner argument is given, it will override the
   1562         internally created default banner."""
   1563
   1564         if self.rc.c:  # Emulate Python's -c option

D:\Apps\python25\lib\site-packages\IPython\ultraTB.pyc in
__call__(self=<IPython.ultraTB.AutoFormattedTB instance at
0x00DC63A0>, etype=<type 'exceptions.IndexError'>,
evalue=IndexError('list index out of range',), etb=<traceback object
at 0x00CDDE90>, out=<IPython.genutils.IOStream instance at
0x0133EB98>, tb_offset=None)
    990           - tb_offset: the number of frames to skip over in
the stack, on a
    991           per-call basis (this overrides temporarily the
instance's tb_offset
    992           given at initialization time.  """
    993
    994         if out is None:
    995             out = Term.cerr
    996         Term.cout.flush()
    997         if tb_offset is not None:
    998             tb_offset, self.tb_offset = self.tb_offset, tb_offset
    999             print >> out, self.text(etype, evalue, etb)
   1000             self.tb_offset = tb_offset
   1001         else:
   1002             print >> out, self.text(etype, evalue, etb)
   1003         out.flush()
   1004         try:
-> 1005             self.debugger()
   1006         except KeyboardInterrupt:
   1007             print "\nKeyboardInterrupt"
   1008
   1009     def text(self,etype=None,value=None,tb=None,context=5,mode=None):
   1010         if etype is None:
   1011             etype,value,tb = sys.exc_info()
   1012         self.tb = tb
   1013         return FormattedTB.text(self,etype,value,tb,context=5,mode=mode)
   1014
   1015 #---------------------------------------------------------------------------
   1016 # A simple class to preserve Nathan's original functionality.
   1017 class ColorTB(FormattedTB):
   1018     """Shorthand to initialize a FormattedTB in Linux colors mode."""
   1019     def __init__(self,color_scheme='Linux',call_pdb=0):
   1020         FormattedTB.__init__(self,color_scheme=color_scheme,

D:\Apps\python25\lib\site-packages\IPython\ultraTB.pyc in
debugger(self=<IPython.ultraTB.AutoFormattedTB instance at
0x00DC63A0>, force=False)
    832           The 'force' option forces the debugger to activate
even if the flag
    833           is false.
    834
    835         If the call_pdb flag is set, the pdb interactive debugger is
    836         invoked. In all cases, the self.tb reference to the
current traceback
    837         is deleted to prevent lingering references which hamper memory
    838         management.
    839
    840         Note that each call to pdb() does an 'import
readline', so if your app
    841         requires a special setup for the readline completers,
you'll have to
    842         fix that by hand after invoking the exception handler."""
    843
    844         if force or self.call_pdb:
    845             if self.pdb is None:
    846                 self.pdb = Debugger.Pdb(
--> 847                     self.color_scheme_table.active_scheme_name)
    848             # the system displayhook may have changed, restore
the original
    849             # for pdb
    850             dhook = sys.displayhook
    851             sys.displayhook = sys.__displayhook__
    852             self.pdb.reset()
    853             # Find the right frame so we don't pop up inside
ipython itself
    854             if hasattr(self,'tb'):
    855                 etb = self.tb
    856             else:
    857                 etb = self.tb = sys.last_traceback
    858             while self.tb.tb_next is not None:
    859                 self.tb = self.tb.tb_next
    860             try:
    861                 if etb and etb.tb_next:
    862                     etb = etb.tb_next

D:\Apps\python25\lib\site-packages\IPython\Debugger.pyc in
__init__(self=<IPython.Debugger.Pdb instance at 0x02DE95A8>,
color_scheme='Linux', completekey=None, stdin=None, stdout=None)
    167         out = outfile.readlines()
    168         outfile.close()
    169         return out
    170
    171 class Pdb(OldPdb):
    172     """Modified Pdb class, does not load readline."""
    173
    174     if sys.version[:3] >= '2.5' or has_pydb:
    175         def __init__(self,color_scheme='NoColor',completekey=None,
    176                      stdin=None, stdout=None):
    177
    178             # Parent constructor:
    179             if has_pydb and completekey is None:
    180                 OldPdb.__init__(self,stdin=stdin,stdout=Term.cout)
    181             else:
--> 182                 OldPdb.__init__(self,completekey,stdin,stdout)
        global _ = undefined
        global q = undefined
        global Wt = undefined
        global i = undefined
        global d = undefined
        global IJWn = undefined
        global t = undefined
        global j = undefined
    183
    184             self.prompt = prompt # The default prompt is '(Pdb)'
    185
    186             # IPython changes...
    187             self.is_pydb = has_pydb
    188
    189             if self.is_pydb:
    190
    191                 # iplib.py's ipalias seems to want pdb's checkline
    192                 # which located in pydb.fn
    193                 import pydb.fns
    194                 self.checkline = lambda filename, lineno: \
    195                                  pydb.fns.checkline(self,
filename, lineno)
    196
    197                 self.curframe = None

D:\Apps\python25\lib\pdb.pyc in __init__(self=<IPython.Debugger.Pdb
instance at 0x02DE95A8>, completekey=None, stdin=None, stdout=None)
     41         lineno = lineno + 1
     42     fp.close()
     43     return answer
     44
     45
     46 # Interaction prompt line will separate file and call info from code
     47 # text using value of line_prefix string.  A newline and arrow may
     48 # be to your liking.  You can set it once pdb is imported using the
     49 # command "pdb.line_prefix = '\n% '".
     50 # line_prefix = ': '    # Use this to get the old situation back
     51 line_prefix = '\n-> '   # Probably a better default
     52
     53 class Pdb(bdb.Bdb, cmd.Cmd):
     54
     55     def __init__(self, completekey='tab', stdin=None, stdout=None):
---> 56         bdb.Bdb.__init__(self)
        global __exception__R = undefined
     57         cmd.Cmd.__init__(self, completekey, stdin, stdout)
     58         if stdout:
     59             self.use_rawinput = 0
     60         self.prompt = '(Pdb) '
     61         self.aliases = {}
     62         self.mainpyfile = ''
     63         self._wait_for_mainpyfile = 0
     64         # Try to load readline if it exists
     65         try:
     66             import readline
     67         except ImportError:
     68             pass
     69
     70         # Read $HOME/.pdbrc and ./.pdbrc
     71         self.rcLines = []

TypeError: unbound method __init__() must be called with Bdb instance
as first argument (got Pdb instance instead)

***************************************************************************

History of session input:
import networkx as NX
G = NX.dodecahedral_graph()
G.nodes()
NX.draw(G)
edges = [ (4, 1), (4, 7), (1, 2), (7, 3), (2, 13),  (2, 17), (13, 24),
(17, 24), (3, 24) ]
G = NX.DiGraph()
G.add_edges_from(edges)
G.nodes()
G.edges()
NX.draw(G)
NX.write_edgelist(G, edges.txt)
NX.write_edgelist(G, 'edges.txt')
G = NX.Graph
G.add_edges_from(edges)
G = NX.Graph()
G.add_edges_from(edges)
NX.draw(G)
NX.draw(G)
G = NX.XDiGraph()
_I7
In[7]
G.nodes()
?%exec
#?exec
exec _i14
G.nodes()
NX.draw(G)
NX.draw(G)
help(draw)
NX.draw(G)
help(NX.draw)
help(scatter)
help(draw)
help(savefig)
NX.draw_graphviz(G)
NX.draw_shell(G)
NX.draw_spectral(G)
NX.draw(G)
G.degree()
help(G.degree)
G.degree(labels=True)
G.degree(with_labels=True)
G.in_degree(with_labels=True)
G.out_degree(with_labels=True)
G.diameter
diameter(G)
NX.diameter(G)
NX.topological_sort(G)
help(G)
help(G.successors_iter)
for s in G.successors_iter():
    print s
for n in G.nodes():
    for s in G.successors_iter(n):
        print n, " - ", s
help(G.has_predecessor)
len(G.predecessors(24))
def longest_path_length_to sink(G, sink):
def longest_path_length_to_sink(G, sink):
    pred = G.predecessors(sink)
    if pred:
        d = [longest_path(G, p) for p in pred]
        return max(d) + 1
    else:
        return 0
longest_path_length_to_sink(G, 24)
def longest_path_length_to_sink(G, sink):
    pred = G.predecessors(sink)
    if pred:
        d = [longest_path_length_to_sink(G, p) for p in pred]
        return max(d) + 1
    else"
def longest_path_length_to_sink(G, sink):
    pred = G.predecessors(sink)
    if pred:
        d = [longest_path_length_to_sink(G, p) for p in pred]
        return max(d) + 1
    else:
        return 0
longest_path_length_to_sink(G, 24)
edges
g2 = NX.grid_2d_graph(4,4)
NX.draw(g2)
_ip.magic(r"cd D:\MyDocuments\Projects\network")
_ip.system("dir /on ")
import critical as C
C.longest_path_to_sink(G, 24)
_ip.magic("dreload C")
_ip.magic("reload C")
dreload(C)
C.longest_path_to_sink(G, 24)
a = [1, 2, 3]
b = a + 1
b = a + [4]
b
dreload(C)
C.longest_path_to_sink(G, 24)
dreload(C)
C.longest_path_to_sink(G, 24)
C.longest_path_length_to_sink(G, 24)
_ip.magic("doctest_mode ")
_ip.magic("logstart critical_log.txt")
edges = [ (4, 1), (4, 7), (1, 2), (7, 3), (2, 13),  (2, 17), (13, 24),
(17, 24), (3, 24) ]
G = NX.XDiGraph()
G.add_edges_from(edges)
C.longest_path_length_to_sink(G, 24)
C.longest_path_to_sink(G, 24)
_ip.magic("logoff ")
_ip.magic("logon ")
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
lp = C.all_longest_paths(G, 24)
dreload(C)
C.all_longest_paths(G, 24)
_ip.magic("logoff ")
_ip.magic("doctest_mode ")
help(draw)
help(NX.draw)
lp
l = max([ len(v) - 1 for v in lp.values])
l = max([ len(v) - 1 for v in lp.values()])
l
n = {}
for v in lp.values():
    x = len(v) - 1
    n[x] = 1 + n.get(x, 0)
n
max(n.values())
xincr = 1.0 / l
yincr = 1.0 / n
yincr = 1.0 / max(n.values())
xvals = [ (xincr/2) + xincr * i for i in range(l)]
xvals
yvals = [yincr/2 + yincr * i for i in range(n)]
yvals = [yincr/2 + yincr * i for i in range(max(n.values()))]
yvals
_ip.magic("hist -n")
dreload(C)
C.grid_coordinates(lp)
_ip.magic("doctest_mode ")
C.grid_coordinates(lp)
_ip.magic("doctest_mode ")
help(NX.draw)
x = 2
(2 * (x / 2))
x = 3
(2 * (x / 2))
dreload(C)
dreload(C)
vpos = C.grid_layout(G)
help(NX.successors)
help(NX)
help(G.successors)
dr
dreload(C)
dreload(C)
C.grid_coordinates(lp)
C.grid_layout(lp)
help(NX.is_directed)
dreload(C)
C.grid_layout(lp)
type(G)
G.is_directed()
C.grid_layout(G)
dreload(C)
_ip.magic("pdb ")
C.grid_layout(G)

*** Last line of input (may not be in above history):
C.grid_layout(G)

Kevin Northover
Director, Technology | ? Sapient
One Penn Plaza, 24th Floor, Suite 2400
New York, NY  10119 USA
desk: +1.212.560.5733
fax: +1.212.560.5701
e-mail: knorthover at sapient.com





-- 
Ville M. Vainio
http://tinyurl.com/vainio