From fperez.net at gmail.com  Sun Jun  1 00:04:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 21:04:47 -0700
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
Message-ID: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>

Hi all,

A couple of months ago we started the launchpad/bzr experiment, and
that has been very successful.  I don't think there's any doubt that
we'll stick with bzr for the time being, nobody feels like going back
to SVN.

To get things started,  Ville created a clean bzr branch without any
SVN history, partly because the scipy server at the time kept timing
out and the svn import into launchpad wasn't working.  Now that import
does function, and one can check out the bzr version of SVN trunk via

bzr branch lp:~vcs-imports/ipython/main/ ipython-svn

The main ipython dev branch (our new 'trunk') can be obtained with

bzr branch lp:ipython

The problem I'm having is how to merge the latter into the former
while preserving the full  history.  Because the bzr trunk was
initialized without any SVN history, every attempt I've made so far
has failed.  I've tried bzr merge and rebase with various flags,
without any success.  I'm not even sure it's possible to do this
cleanly, I'm afraid.

The SVN trunk has several years of history that I'm not willing to
lose (I already made the mistake of losing all  project history in the
CVS->SVN transition, I won't repeat that).  I'd love to hear from
anyone who might know how to make this merge, if it is possible.  If
it can't be made with bzr merge tools, I guess we can try to produce a
set of bundles and apply them one by one or as a lump change with one
gigantic commit message that preserves the other log...

We're probably going to lose history no matter what, because of the
'branch folding' problem I mentioned earlier.  The current bzr 'trunk'
has a really funky log that shows these, and hopefully we won't make
these mistakes with bzr in the future.  But I'd like to minimize the
losses, so I'd love if a bzr guru amongst us knows the magic trick.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 00:14:07 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 21:14:07 -0700
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
In-Reply-To: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
Message-ID: <db6b5ecc0805312114of8bf4bo9742ec305d55d98b@mail.gmail.com>

On Sat, May 31, 2008 at 9:04 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> The problem I'm having is how to merge the latter into the former
> while preserving the full  history.  Because the bzr trunk was
> initialized without any SVN history, every attempt I've made so far
> has failed.  I've tried bzr merge and rebase with various flags,
> without any success.  I'm not even sure it's possible to do this
> cleanly, I'm afraid.

I forgot to add that I tried to make a bundle containing the history
of the entire new bzr trunk and apply that to the svn branch, but it
produced 141 conflicts!  Cleaning merge conflicts by hand is a huge
PITA, cleaning 141 is way more than I think any of us is either
interested in doing, or likely to do without making mistakes.

I'll keep on trying, but any ideas would be very welcome at this point.

Cheers,

f


From ellisonbg.net at gmail.com  Sun Jun  1 01:08:52 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sat, 31 May 2008 23:08:52 -0600
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
Message-ID: <6ce0ac130805312208w6ce8d648pf54d05f7e8bad490@mail.gmail.com>

One thing you might try is posting a question on the launchpad
"answers" section.  They were pretty good about answering a question
when I asked.  They might even be able to help or give good direction
- we can't be the first to have faced this.

Brian

On Sat, May 31, 2008 at 10:04 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> A couple of months ago we started the launchpad/bzr experiment, and
> that has been very successful.  I don't think there's any doubt that
> we'll stick with bzr for the time being, nobody feels like going back
> to SVN.
>
> To get things started,  Ville created a clean bzr branch without any
> SVN history, partly because the scipy server at the time kept timing
> out and the svn import into launchpad wasn't working.  Now that import
> does function, and one can check out the bzr version of SVN trunk via
>
> bzr branch lp:~vcs-imports/ipython/main/ ipython-svn
>
> The main ipython dev branch (our new 'trunk') can be obtained with
>
> bzr branch lp:ipython
>
> The problem I'm having is how to merge the latter into the former
> while preserving the full  history.  Because the bzr trunk was
> initialized without any SVN history, every attempt I've made so far
> has failed.  I've tried bzr merge and rebase with various flags,
> without any success.  I'm not even sure it's possible to do this
> cleanly, I'm afraid.
>
> The SVN trunk has several years of history that I'm not willing to
> lose (I already made the mistake of losing all  project history in the
> CVS->SVN transition, I won't repeat that).  I'd love to hear from
> anyone who might know how to make this merge, if it is possible.  If
> it can't be made with bzr merge tools, I guess we can try to produce a
> set of bundles and apply them one by one or as a lump change with one
> gigantic commit message that preserves the other log...
>
> We're probably going to lose history no matter what, because of the
> 'branch folding' problem I mentioned earlier.  The current bzr 'trunk'
> has a really funky log that shows these, and hopefully we won't make
> these mistakes with bzr in the future.  But I'd like to minimize the
> losses, so I'd love if a bzr guru amongst us knows the magic trick.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-user mailing list
> IPython-user at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>


From vivainio at gmail.com  Sun Jun  1 01:35:04 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 1 Jun 2008 08:35:04 +0300
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
In-Reply-To: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
Message-ID: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>

On 6/1/08, Fernando Perez <fperez.net at gmail.com> wrote:

> The SVN trunk has several years of history that I'm not willing to
> lose (I already made the mistake of losing all  project history in the

We didn't actually lose the history - it's still there on launchpad,
albeit on separate branch. We just don't NEED it on our work branch,
since no branching/merging/revert is needed for that code.

The problem with bzr is that it slows down with long history, so not
having it around in our work copies is a net win. As a fun excercise,
we might create an ipython repo with full history at some point - but
it certainly doesn't yield tangible benefits right now.

> We're probably going to lose history no matter what, because of the
> 'branch folding' problem I mentioned earlier.  The current bzr 'trunk'

This doesn't lose history, even if it appears to be so from log
messages. Still, it's annoying that bzr doesn't even WARN about
pushing a branch over a branch with a completely different view of
revisions...

We might ask the bzr mailing list for a pre-push hook that does this -
OTOH, I think the people with commit access now know to be wary of
this little quirk.

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


From prabhu at aero.iitb.ac.in  Sun Jun  1 02:06:49 2008
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Sun, 01 Jun 2008 11:36:49 +0530
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
Message-ID: <48423C79.7050901@aero.iitb.ac.in>

Hi,

Fernando Perez wrote:
> This would bring us a number of benefits:
[...]
>  * It would be much easier to explain to people that state of ipython.
>  "IPython is just IPython and now it has parallel computing"  The
> ambitious plans for refactoring, notebooks, frontends are underway,
> but IPython is still just IPython.
> 
>  * The parallel computing stuff would instantly make it into all the
> Linux distros.
[...]
>  * Our entire combined effort (limited as it may be, we have some
> great people on board) can be focused on a single problem, and we can
> all trust that we're working together for the same goal.

I agree with the majority of these benefits.  I really would like to see 
the IPython1 features but am too addicted to IPython0 myself.

However, I think there are two things that are being mixed up here.  One 
is getting ip1 features in ip0 and the other is the headache of two 
separate development fronts. I think the idea of "backporting" ip1 
features to ip0 is a great idea but I still see benefit in an 
experimental tree where you experiment on ideas.  Too often, the need 
for stability bogs down interesting work and new developments.  If you 
mix the two you get the benefit of one but loose out on the other.

In my experience with mayavi2, I had the following problem, which is 
somewhat similar.  For mayavi, the trunk is where the other great 
projects that it depended on were being developed and the branches was 
for stable work (branches are released as part of EPD, and in Debian 
etc.).  This made doing any API breaking improvements a *huge* pain and 
a constant deterrent.  This was incredibly frustrating for me as a 
developer -- I see warts that I know I can fix but can't!  For a while 
everything was trundling along on the branch, it took a ton of work to 
first port everything from branches to trunk. Once the trunk worked, it 
was amazingly liberating.  Immediately, I was able to resolve a few 
issues that plagued the codebase.  Once those were done, I was able to 
cherry pick nice improvements that would not trigger an API break and 
backport them to the branch.  This included a huge amount of 
functionality and tests.  I agree that this can't always be done but the 
cost of my developer-interest is high and if I loose out interest in 
programming for the project, I might as well kill the project.

What I'm saying is that there is a great advantage to having an official 
unstable branch.  While that may or may not be ip1, I do think it is 
important to not blindly merge the two into one just for the sake of the 
benefits.

My 50 paise.

cheers,
prabhu


From prabhu at aero.iitb.ac.in  Sun Jun  1 02:10:15 2008
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Sun, 01 Jun 2008 11:40:15 +0530
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
In-Reply-To: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
Message-ID: <48423D47.4030707@aero.iitb.ac.in>

Fernando Perez wrote:
> The problem I'm having is how to merge the latter into the former
> while preserving the full  history.  Because the bzr trunk was
> initialized without any SVN history, every attempt I've made so far
> has failed.  I've tried bzr merge and rebase with various flags,
> without any success.  I'm not even sure it's possible to do this
> cleanly, I'm afraid.

Not sure if this will work or if you've tried it, but can't you do the 
reverse?  I.e. create a freshly imported bzr tree with the SVN history 
of the older code in SVN then merge *that* with the zero-history branch?

cheers,
prabhu


From fperez.net at gmail.com  Sun Jun  1 02:40:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 23:40:36 -0700
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
In-Reply-To: <48423D47.4030707@aero.iitb.ac.in>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<48423D47.4030707@aero.iitb.ac.in>
Message-ID: <db6b5ecc0805312340v10964acckb6a6df8e35597785@mail.gmail.com>

On Sat, May 31, 2008 at 11:10 PM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> Fernando Perez wrote:
>>
>> The problem I'm having is how to merge the latter into the former
>> while preserving the full  history.  Because the bzr trunk was
>> initialized without any SVN history, every attempt I've made so far
>> has failed.  I've tried bzr merge and rebase with various flags,
>> without any success.  I'm not even sure it's possible to do this
>> cleanly, I'm afraid.
>
> Not sure if this will work or if you've tried it, but can't you do the
> reverse?  I.e. create a freshly imported bzr tree with the SVN history of
> the older code in SVN then merge *that* with the zero-history branch?

I've tried that, but bzr merge refuses to apply the merge because it
doesn't see the two as having a common ancestor.  This seems to do
exactly what I'm after:

http://spacepants.org/src/bzrgraft/

Unfortunately the warnings about it being badly outdated are a bit
worrying.  I'm going to give it a try nonetheless, we'll see how it
goes.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 02:44:43 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 23:44:43 -0700
Subject: [IPython-dev] Porting SVN history to Launchpad - help needed.
In-Reply-To: <46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
Message-ID: <db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>

On Sat, May 31, 2008 at 10:35 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 6/1/08, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> The SVN trunk has several years of history that I'm not willing to
>> lose (I already made the mistake of losing all  project history in the
>
> We didn't actually lose the history - it's still there on launchpad,
> albeit on separate branch. We just don't NEED it on our work branch,
> since no branching/merging/revert is needed for that code.

The point is that (as per the other message), this branch is now *the*
project.  Making an arbitrary cut in history at any point in time (Feb
2008 in this case) makes no sense.

> The problem with bzr is that it slows down with long history, so not
> having it around in our work copies is a net win. As a fun excercise,
> we might create an ipython repo with full history at some point - but
> it certainly doesn't yield tangible benefits right now.

I simply don't like idea of dumping away the whole line of development
with the project's early history.  If we're going to leave some
history aside, I'd rather drop Feb-May 2008 than the previous years.
If we can't make this work, I'll apply the recent changes as a single,
gigantic change with a huge commit message (the whole log), and refer
to the other branch for details.

If I have to choose between 3 months and 3 years of history, I lose
the three months, not the three years. Period.

bzr graft would do the job, we'll see if I can make it run.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 02:46:59 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 23:46:59 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <88e473830805312024o76df6d8byda0138cd6940f791@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<88e473830805312024o76df6d8byda0138cd6940f791@mail.gmail.com>
Message-ID: <db6b5ecc0805312346q58ed14caid29dd3e9d5ce43e8@mail.gmail.com>

On Sat, May 31, 2008 at 8:24 PM, John Hunter <jdh2358 at gmail.com> wrote:
> On Sat, May 31, 2008 at 9:55 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> So, any comments?  We'd like to move forward *quickly* with this idea.
>> We'd try to make a series of much more frequent releases, one for each
>> key component we add in, so that little by little the baby can
>> actually grow.   There will be an initial period where I would prepare
>> the ground in ip0 for the ip1 components to land in while Brian
>> finishes a couple of things he has in his local branch, but we're
>> talking a couple of weeks, not years.

[..]

> So I think your proposal is the right one.
>

Thanks for the feedback.  MPL is a project I thought a lot about,
because we've talked many times about your refactoring experiences
there.  So your perspective is actually very welcome on this front,
thanks.  Michael D. has done a superhuman job on MPL, but it's also
true that working off something that works is always more rewarding
and easier psychologically.  I think I vastly underestimated the
importance of that.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 02:52:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 23:52:00 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <48423C79.7050901@aero.iitb.ac.in>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<48423C79.7050901@aero.iitb.ac.in>
Message-ID: <db6b5ecc0805312352m5ae7eee1r8ce45c95dc0ac0f3@mail.gmail.com>

On Sat, May 31, 2008 at 11:06 PM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> However, I think there are two things that are being mixed up here.  One is
> getting ip1 features in ip0 and the other is the headache of two separate
> development fronts. I think the idea of "backporting" ip1 features to ip0 is
> a great idea but I still see benefit in an experimental tree where you
> experiment on ideas.  Too often, the need for stability bogs down
> interesting work and new developments.  If you mix the two you get the
> benefit of one but loose out on the other.
>
> In my experience with mayavi2, I had the following problem, which is
> somewhat similar.  For mayavi, the trunk is where the other great projects
> that it depended on were being developed and the branches was for stable
> work (branches are released as part of EPD, and in Debian etc.).  This made
> doing any API breaking improvements a *huge* pain and a constant deterrent.
>  This was incredibly frustrating for me as a developer -- I see warts that I
> know I can fix but can't!  For a while everything was trundling along on the
> branch, it took a ton of work to first port everything from branches to
> trunk. Once the trunk worked, it was amazingly liberating.  Immediately, I
> was able to resolve a few issues that plagued the codebase.  Once those were
> done, I was able to cherry pick nice improvements that would not trigger an
> API break and backport them to the branch.  This included a huge amount of
> functionality and tests.  I agree that this can't always be done but the
> cost of my developer-interest is high and if I loose out interest in
> programming for the project, I might as well kill the project.
>
> What I'm saying is that there is a great advantage to having an official
> unstable branch.  While that may or may not be ip1, I do think it is
> important to not blindly merge the two into one just for the sake of the
> benefits.

Thanks for this take on it: I think we should be OK on that front
though.  ip1 and ip0 were unfortunately not really experimental/stable
versions, they were effectively two projects meant to merge at some
point in the future, but with no viable path (with the available time
and resources) for that to happen in one gigantic shot.  What we want
to do now is basically start putting on the trunk of plain ipython the
parts and features of ip1 that work well already, and  gradually morph
ip1 into the architecturally cleaner project (and well tested) that
we've always wanted.

For experimental development, we *will* have proper branches.  Keep in
mind that now we're on bzr, we have the technical support for easy and
comfortable true branch work.  So once this new merged ipython is up
and running (a few weeks), we can call it 'trunk' and then have
branches *off that* where experimental features can be developed.
With this setup, said branches can still merge from trunk as needed
while their neat ideas mature.  That wasn't really viable with the
ip0/ip1 split, since there was no true common ground for merging.

So I do appreciate your concern and don't dismiss it offhand, but I
think we're OK on that front.  But thanks still for the feedback,
these are all things I'd like to keep in mind.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 03:10:01 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 00:10:01 -0700
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <48424570.4010808@ar.media.kyoto-u.ac.jp>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
Message-ID: <db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>

On Sat, May 31, 2008 at 11:45 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Fernando Perez wrote:
>>>
>>> The problem with bzr is that it slows down with long history, so not
>>> having it around in our work copies is a net win. As a fun excercise,
>>> we might create an ipython repo with full history at some point - but
>>> it certainly doesn't yield tangible benefits right now.
>
> (sorry for the doublon, I always forget reply to all...)
>
> Every DVCS slows down with long history, but really, if bzr is too slow,
> then don't use it: using a DVCS will mean more history than with subversion.
> Limiting yourself to less history because of bzr slowness sounds really
> wrong to me: you lose the whole point.

Yup, I forgot to say exactly that.

> Now, I really cannot see how this would be the case for ipython: bzr is
> slower than hg, and much slower than git, but ipython is a small project
> (not that I want to diminish anybody's work, of course). Hopefully, bzr (or
> our computer) will scale better when ipython will be as big as the linux
> kernel :)

No offense, I think pretty much the same: if bzr can't deal with a
project of this size, it's useless.  And I know that MUCH larger
projects use it, so I'm sure this won't be the problem.

> More seriously, I will take a look at this myself. Fernando, are you only
> interested in the trunk history ?

Yup.   As I said above, you can do:

bzr branch lp:~vcs-imports/ipython/main/ launchpad-svn-1
bzr branch lp:ipython  ipython-main-2

Now the problem is how to produce a valid bzr branch that basically
concatenates in time -1 and -2, in that order.  bzr graft
(http://spacepants.org/src/bzrgraft/) was meant exactly for that
purpose, but it indeed doesn't work at all with today's bzr as the
developer warned (I already tried).

If you can find some combination of bzr merge/bundle/rebase that would
do the trick, let me know.  I've already written a little python
script that can generate the individual changes and log messages as
bundles/logfile pairs, but they still don't apply because the target
is missing the required base revision.

It kind of annoys me that one apparently can't force a bundle to apply
(it's just a diff, after all!). There must be a way to do this...

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 03:28:18 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 00:28:18 -0700
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <48424B1A.1060307@ar.media.kyoto-u.ac.jp>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
Message-ID: <db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>

On Sun, Jun 1, 2008 at 12:09 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Fernando Perez wrote:
>>
>> If you can find some combination of bzr merge/bundle/rebase that would
>> do the trick, let me know.
>
> I was thinking about using a bigger hammer (git + bzr export).
>
>> It kind of annoys me that one apparently can't force a bundle to apply
>> (it's just a diff, after all!). There must be a way to do this...
>>
>
> bundle is not just a diff: it records information about file move and the
> likes (which is useless in this case, since svn does not know about rename,
> it just delete/copy). AFAIK, that's one fundamental difference between git
> and bzr. I would not be able to explain the differences, but I know some
> people chose git for this exact reasons (and that's why I think using git
> for the import will be less hassle here).

By all means, if git/bzr does the job, go for it!

And yes, I was sloppy above, I know bundles contain extra info beyond
the diff.  But what I meant was that it should be possible to tell bzr
simply to apply a bundle off a given point, much like you can with
diff/patch.  In fact that's precisely what bzr graft does, but I don't
feel like learning the bzr API right now just to update 'bzr graft'
for a one-off operation we want to perform.

Thanks a lot for being willing to help here!


Cheers,

f


From laurent.dufrechou at gmail.com  Sun Jun  1 08:01:14 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Sun, 1 Jun 2008 14:01:14 +0200
Subject: [IPython-dev] Going mad with bzr push
Message-ID: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com>

Hi guys,
Since this morning, i've tryied to push from my recent linux install...
without success.
I've done:
ssh-keygen -t dsa
ssh-add id_dsa
uploaded the public key to my launchpad account that is laurent.dufrechou
and:

 bzr push bzr+ssh://
laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/

and got:
No such Launchpad account: laurent.dufrechou
No such Launchpad account: laurent.dufrechou
Permission denied (publickey).
bzr: ERROR: Connection closed: please check connectivity and permissions
(and try -Dhpss if further diagnosis is required)

Any idea? (Sure this is the bzr line that is bad)

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080601/53137dfd/attachment.html>

From vivainio at gmail.com  Sun Jun  1 08:40:18 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 1 Jun 2008 15:40:18 +0300
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
Message-ID: <46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com>

On 6/1/08, Fernando Perez <fperez.net at gmail.com> wrote:

> So our current rethinking is: forge ahead with what we've been calling
> IPython0, and begin integrating the various key (and functional)
> components of IPython1 into it one by one.  The IPython0/1 split will
> end, and we will use all the good pieces of IPython1 to add
> functionality to ip0 without losing its current features.  At each 0.X

This is definitely a good plan; even if porting of ipython0 code to
ipython1 happened some day, the result would not be much "cleaner"
than today's ipython0.

Cleaning up ipython0's interfaces to allow inclusion of ipython1 is a
better scheme overall; there are many places where obvious cleanups
are possible (separation of input / output code etc), but have not
been feasible because of "maintenance" status and small team - not to
mention the questionable future. Essentially, creating an experimental
branch of ipython0 where cleanups and ipython1 feature integration
happens frees ipython0 from paralyzing conservativeness, and the
development effort of everybody actually ends up in the hands of the
end users.

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


From fperez.net at gmail.com  Sun Jun  1 15:23:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 12:23:36 -0700
Subject: [IPython-dev] Going mad with bzr push
In-Reply-To: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com>
References: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com>
Message-ID: <db6b5ecc0806011223l4c7903b9v6beec62a94cc575d@mail.gmail.com>

On Sun, Jun 1, 2008 at 5:01 AM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Hi guys,
> Since this morning, i've tryied to push from my recent linux install...
> without success.
> I've done:
> ssh-keygen -t dsa
> ssh-add id_dsa
> uploaded the public key to my launchpad account that is laurent.dufrechou
> and:
>
>  bzr push
> bzr+ssh://laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/
>
> and got:
> No such Launchpad account: laurent.dufrechou
> No such Launchpad account: laurent.dufrechou
> Permission denied (publickey).
> bzr: ERROR: Connection closed: please check connectivity and permissions
> (and try -Dhpss if further diagnosis is required)
>

I see your account as:

https://launchpad.net/~laurent-dufrechou

There's a '-', not a '.' between your first/last names.  That could be
the problem.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 15:27:31 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 12:27:31 -0700
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <484267EF.5070500@ar.media.kyoto-u.ac.jp>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>
	<484267EF.5070500@ar.media.kyoto-u.ac.jp>
Message-ID: <db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>

On Sun, Jun 1, 2008 at 2:12 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Fernando Perez wrote:
>>
>> By all means, if git/bzr does the job, go for it!
>>
>
> Ok, I tried different things without success, but I think I know why you
> cannot merge successfully the new branch into the old one: many files are in
> DOS format in the new trunk !
>
> file IPython/* on the first bzr revision gives me:
>
> IPython/background_jobs.py:    ASCII English text, with CRLF line
> terminators
> IPython/ColorANSI.py:          ASCII English text, with CRLF line
> terminators
> IPython/completer.py:          a python script text executable
> IPython/ConfigLoader.py:       ASCII English text, with CRLF line
> terminators
> IPython/CrashHandler.py:       ASCII English text, with CRLF line
> terminators
> IPython/Debugger.py:           ASCII English text, with CRLF line
> terminators
> IPython/deep_reload.py:        ASCII Java program text, with CRLF line
> terminators
> IPython/demo.py:               a python script text executable
> IPython/DPyGetOpt.py:          ASCII English text, with CRLF line
> terminators
> IPython/dtutils.py:            a python script text executable
> IPython/excolors.py:           ASCII English text
> IPython/Extensions:            directory
> IPython/external:              directory
> IPython/FakeModule.py:         ASCII English text, with CRLF line
> terminators
> IPython/generics.py:           ASCII Java program text
> IPython/genutils.py:           ASCII English text, with CRLF line
> terminators
> IPython/Gnuplot2.py:           ASCII English text, with CRLF line
> terminators
> IPython/GnuplotInteractive.py: ASCII English text, with CRLF line
> terminators
> IPython/GnuplotRuntime.py:     ASCII Java program text, with CRLF line
> terminators
> IPython/gui:                   directory
> IPython/history.py:            ASCII Java program text
> IPython/hooks.py:              a python script text executable
> IPython/__init__.py:           ASCII English text, with CRLF line
> terminators
> IPython/ipapi.py:              troff or preprocessor input text
> IPython/iplib.py:              ASCII English text, with CRLF line
> terminators
> IPython/ipmaker.py:            ASCII English text, with CRLF line
> terminators
> IPython/ipstruct.py:           ASCII English text, with CRLF line
> terminators
> IPython/irunner.py:            a python script text executable
> IPython/Itpl.py:               ASCII English text, with CRLF line
> terminators
> IPython/Logger.py:             ASCII C++ program text, with CRLF line
> terminators
> IPython/macro.py:              a python script text executable
> IPython/Magic.py:              ASCII English text, with CRLF line
> terminators
> IPython/numutils.py:           ASCII English text, with CRLF line
> terminators
> IPython/OInspect.py:           ASCII English text, with CRLF line
> terminators
> IPython/OutputTrap.py:         ASCII English text, with CRLF line
> terminators
> IPython/platutils_dummy.py:    ASCII English text
> IPython/platutils_posix.py:    ASCII Java program text
> IPython/platutils.py:          ASCII English text
> IPython/platutils_win32.py:    ASCII Java program text
> IPython/prefilter.py:          ASCII English text
> IPython/Prompts.py:            ASCII English text, with CRLF line
> terminators
> IPython/PyColorize.py:         ASCII Pascal program text, with CRLF line
> terminators
> IPython/Release.py:            ASCII English text, with CRLF line
> terminators
> IPython/rlineimpl.py:          ASCII English text
> IPython/shadowns.py:           a python script text executable
> IPython/Shell.py:              ASCII English text, with CRLF line
> terminators
> IPython/strdispatch.py:        ASCII Java program text
> IPython/ultraTB.py:            ASCII English text, with CRLF line
> terminators
> IPython/upgrade_dir.py:        a python script text executable
> IPython/usage.py:              ASCII English text, with CRLF line
> terminators
> IPython/UserConfig:            directory
> IPython/wildcard.py:           UTF-8 Unicode English text
> IPython/winconsole.py:         a python script text executable
>
> I am afraid it will be a nightmare to merge. I am trying to get the first
> version without any CRLF line terminator, and diffing from there,


Argh!!! I have no idea how that happened, I only work under Linux.
But we've had cases before of devs who work under Win32 committing
accidentally DOS-formatted files.  I used to notice right away because
old XEmacs showed the ^M characters at the end  of the lines.  But
these days, Emacs fixes that silently and hides them out (it does show
a little 'DOS' marker on the bottom left).

But which branch do you see this on? If I look for example at Magic.py
on either the launchpad-svn branch (the one from vcs-imports) or on
the  main stable-dev one, I don't get the DOS marker. I suppose it's
possible that there are *mixed* EOL markers in those files, that Emacs
is failing to detect.  It probably only scans the first few lines to
make a decision, so chances  are what we have is a mess of files with
mixed line endings.

I'm leaning towards simply ditching our history for the last three
months.  I spent a fair amount of time yesterday on it without success
(I tried lots of things) and so have you with git.  I've just gone on
IRC to ask on the bzr channel, I might get a bit of help there. But I
have a bunch of 'life' related things to do today, so unless an easy
solution materializes, I think we'll just have to move forward.

But thanks for trying, and if you do come up with a solution, by all
means let us know!

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 15:31:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 12:31:36 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<46cb515a0806010540y6b954c65kf047b35d760668b0@mail.gmail.com>
Message-ID: <db6b5ecc0806011231u24440585l9d6144441b9980d4@mail.gmail.com>

On Sun, Jun 1, 2008 at 5:40 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 6/1/08, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> So our current rethinking is: forge ahead with what we've been calling
>> IPython0, and begin integrating the various key (and functional)
>> components of IPython1 into it one by one.  The IPython0/1 split will
>> end, and we will use all the good pieces of IPython1 to add
>> functionality to ip0 without losing its current features.  At each 0.X
>
> This is definitely a good plan; even if porting of ipython0 code to
> ipython1 happened some day, the result would not be much "cleaner"
> than today's ipython0.
>
> Cleaning up ipython0's interfaces to allow inclusion of ipython1 is a
> better scheme overall; there are many places where obvious cleanups
> are possible (separation of input / output code etc), but have not
> been feasible because of "maintenance" status and small team - not to
> mention the questionable future. Essentially, creating an experimental
> branch of ipython0 where cleanups and ipython1 feature integration
> happens frees ipython0 from paralyzing conservativeness, and the
> development effort of everybody actually ends up in the hands of the
> end users.

I'm super happy to see everyone is so positive about the plan, and
thanks to all for the feedback. This response is an indicator (and a
lesson, at least to me) that the change was overdue :)

This new setup will  let us all work with better integration towards a
common goal.  I have urgent, immediate need of the ip1  features being
usable in production for research work at Berkeley, and I also want
things to be in good shape by the end of the summer: in the fall new
grad students arrive, and there are a number of interesting research
ideas that Brian and I want to push forward with that will require a
workable codebase for others to participate with.

Having the support of bzr will hopefully allow us to be flexible about
trying out small experimental side branches for new features with
regular merges, instead of the 'forever split' situation we were
trapped in.

So let's move on!

Cheers,

f


From vivainio at gmail.com  Sun Jun  1 15:42:38 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 1 Jun 2008 22:42:38 +0300
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>
	<484267EF.5070500@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
Message-ID: <46cb515a0806011242u245a348cu9cda24c53d4e160e@mail.gmail.com>

On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:

>> file IPython/* on the first bzr revision gives me:

Yes, the first revision in bzr indeed har CRLF newlines. This happened
because on windows, svn checks files out in "native" line feed format
(which sucks), and the bzr repo was created directly from that tree.
Few revisions later, the linefeeds were corrected.

I'm not sure why this should break the repo combination, though -
linefeed change is like any other change, though one that sadly
affects every line.

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


From vivainio at gmail.com  Sun Jun  1 15:45:55 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 1 Jun 2008 22:45:55 +0300
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>
	<484267EF.5070500@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
Message-ID: <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com>

On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> I'm leaning towards simply ditching our history for the last three
> months.  I spent a fair amount of time yesterday on it without success
> (I tried lots of things) and so have you with git.  I've just gone on
> IRC to ask on the bzr channel, I might get a bit of help there. But I
> have a bunch of 'life' related things to do today, so unless an easy
> solution materializes, I think we'll just have to move forward.

This is a reasonable solution if everything else fails. We just leave
the contents of stable-dev dangling around, and mark it as "abandoned"
- it's still available for browsing if need be.

The commit message should contain full contents of "bzr log" for
reference, though, as well as the url for the branch.

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


From fperez.net at gmail.com  Sun Jun  1 15:53:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 12:53:36 -0700
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<46cb515a0805312235k6656664fp4b0aff001814e94b@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>
	<484267EF.5070500@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
	<46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com>
Message-ID: <db6b5ecc0806011253o54f3eb6dy9f4d579b0f490b0@mail.gmail.com>

On Sun, Jun 1, 2008 at 12:45 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sun, Jun 1, 2008 at 10:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> I'm leaning towards simply ditching our history for the last three
>> months.  I spent a fair amount of time yesterday on it without success
>> (I tried lots of things) and so have you with git.  I've just gone on
>> IRC to ask on the bzr channel, I might get a bit of help there. But I
>> have a bunch of 'life' related things to do today, so unless an easy
>> solution materializes, I think we'll just have to move forward.
>
> This is a reasonable solution if everything else fails. We just leave
> the contents of stable-dev dangling around, and mark it as "abandoned"
> - it's still available for browsing if need be.
>
> The commit message should contain full contents of "bzr log" for
> reference, though, as well as the url for the branch.

Yes, both points were exactly what I had in mind doing.  It will still
take some manual labor, but the alternatives aren't looking feasible.
On the IRC channel all I got was 'try rebase' (which doesn't work),
and 'try the list'.  I'm running out of patience for this one though,
so I think I'll move on.

If someone figures out how to do this, or has the energy to resurrect
bzr-graft, great.  As far as I'm concerned, the above plan is
reasonable (if not  ideal),  and the faster we do it, the less history
we end up trapping in this side, frozen branch.

Cheers,

f


From fperez.net at gmail.com  Sun Jun  1 16:50:15 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 13:50:15 -0700
Subject: [IPython-dev] [IPython-user] Porting SVN history to Launchpad -
	help needed.
In-Reply-To: <db6b5ecc0806011253o54f3eb6dy9f4d579b0f490b0@mail.gmail.com>
References: <db6b5ecc0805312104j51d507a4qe6a537968f7b643@mail.gmail.com>
	<db6b5ecc0805312344n164fcb0epf881692a876e98d@mail.gmail.com>
	<48424570.4010808@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010010k73da5457t2e1c2da0638d86fc@mail.gmail.com>
	<48424B1A.1060307@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806010028gb853e8bsef1327ed271a74c6@mail.gmail.com>
	<484267EF.5070500@ar.media.kyoto-u.ac.jp>
	<db6b5ecc0806011227r69c72470j37df53d77769dce0@mail.gmail.com>
	<46cb515a0806011245y358ef9e1v12f3262adfe95561@mail.gmail.com>
	<db6b5ecc0806011253o54f3eb6dy9f4d579b0f490b0@mail.gmail.com>
Message-ID: <db6b5ecc0806011350m692eedb6i3ae3ad1cb638906a@mail.gmail.com>

On Sun, Jun 1, 2008 at 12:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Yes, both points were exactly what I had in mind doing.  It will still
> take some manual labor, but the alternatives aren't looking feasible.
> On the IRC channel all I got was 'try rebase' (which doesn't work),
> and 'try the list'.  I'm running out of patience for this one though,
> so I think I'll move on.

I've made one last try by mailing the bzr list.  If a magical, 'type
this and it works' recipe comes back I'll use it, else I'll go with
our sub-optimal-but-acceptable plan B.

Cheers,

f


From stefan at sun.ac.za  Sun Jun  1 17:07:27 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 1 Jun 2008 23:07:27 +0200
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <db6b5ecc0805311933p611b229dx96c2c29008ab6ab1@mail.gmail.com>
References: <g0ak8r$qch$1@ger.gmane.org>
	<6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>
	<3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com>
	<6ce0ac130805121918t470fbd46icb709523440a9978@mail.gmail.com>
	<3d375d730805121929r16a72402q1cc83b64beba7867@mail.gmail.com>
	<db6b5ecc0805311933p611b229dx96c2c29008ab6ab1@mail.gmail.com>
Message-ID: <9457e7c80806011407r5d4040b5icf82d21c65130dab@mail.gmail.com>

2008/6/1 Fernando Perez <fperez.net at gmail.com>:
> On Mon, May 12, 2008 at 7:29 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Mon, May 12, 2008 at 9:18 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> How about docutils.  I am not at my dev computer, but I think I was
>>> running 0.4 (not svn) of docutils.  Hint is listed in docutils
>>> documentation as being a supported directive, so that is odd.  I try
>>> this out again when I get back to my other computer.
>>
>> Ah, there we go. I'll have to double-check my SVN checkout. Maybe
>> development moved elsewhere.
>
> If I recall correctly, at the Enthought sprint Ondrej and I ran into
> quite a bit of trouble with docutils from SVN when using Sphinx, and
> had to back off to the official 0.4 release.

It's a problem, since the SVN version has bugs but also fixes some
that occurred in 0.4  My solution is to use the Debian patched SVN
version.

Regards
St?fan


From fperez.net at gmail.com  Sun Jun  1 17:10:58 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 14:10:58 -0700
Subject: [IPython-dev] RFC: Launchpad, Trac and bugs
Message-ID: <db6b5ecc0806011410v6cf8f40bka7c586a9f71497fe@mail.gmail.com>

Hi folks,

we'll see what we end up doing with the recent bzr history, but the
fact that we're moving to bzr/launchpad for all code work is now a
done deal.  What I'd like to do is to solicit a bit of feedback on
what to do with bug tracking, because there I'm a bit less decided.
We have informally discussed this already in bits and pieces, but now
I'd like to make a final decision.

The options seem to be:

1. Keep using Trac for all bugs.  Launchpad even explicitly supports
linking all bug reports for a project to an external tracker (we'd
have to register the IPython Trac somehow, but that should be easy).

2. Move to the Launchpad bug system for all new bugs.  We could keep
existing open tickets on Trac and gradually close them, but mark the
main page indicating that no new bugs should be filed there.


#2 has the advantage of integrating with the rest of  Launchpad a
little better, and this ties us in with other projects, the Ubuntu
package database, etc.  But I have to  admit that so far, I like Trac
much more than Launchpad for project management/bug tracking.  For all
of SVN's flaws, trac is actually really nice and usable, while the
Launchpad site's web interface is very, very clunky.  Simple things
take a lot of clicking around to do, their documentation is hideous,
etc.  I love the hosting that launchpad provides, but the system feels
very, very immature in terms of everyday usability.

On the flip side, launchpad has lots of use, hence one hopes lots of
development, while I worry that Trac seems to be slowing down (0.11
isn't even out yet, and it has been in that state for a looong time).

So I'd like to hear opinions on the most sensible approach forward.
One way or another we'll keep all filed tickets we have on both
systems, so it's just a matter of deciding, and appropriately
informing our users, what the *official* system will be in the future.

cheers,

f


From barrywark at gmail.com  Sun Jun  1 17:26:49 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 1 Jun 2008 14:26:49 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
Message-ID: <cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>

Sorry to jump in late on the discussion. As the token frontend guy, I
think this sounds like a good idea too. My understanding is that
following the reintegration, ipython0 will instantly be the
terminal-based front-end for the ipython1 features. That's great. We
can continue efforts to make Twisted-based GUI frontends for ipython1.
But, how are we planning to make ipython0 features (such as macros
etc.) available via the engineservice interfaces? My (weak)
understanding of the ipython0 codebase is that much of the ipython0
Interpreter is tied to the terminal/readline interface. Integrating
that with Twisted is (as we've just seen) difficult. So, is there a
plan yet for using ipython0's features in non-terminal-based use
cases?

Barry


On Sat, May 31, 2008 at 7:55 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> after much thought and hand-wringing, Brian and I would like to bring
> up an idea for a change of plans in the development process that will
> hopefully make us all happier, more efficient, and will lead to more
> usable code sooner, which is after all what we want.  Please pitch in
> with any comments you may have, ideas, dissent, etc.
>
> The current ipython development process is, we think, far less
> efficient than it could be.  Coupled with the fact that we have a
> rather small core team, this is leading to sometimes near paralysis.
> It is particularly unfair to Ville, who is tasked with maintaining an
> actively (and very widely) used project on a codebase with no clear
> future, and yet we have in ipython1 a codebase with split-personality
> disorder: lovely parallel computing interfaces but a bunch of "we'll
> get there soon" components that are all half-finished.
>
> In all this, Brian and Min try to push ip1 forward, Barry Wark works
> on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but
> that work is half-repeated in ip0 and ip1, etc.  And in the meantime,
> I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on
> growing wider, with the so far unfulfilled promised of building a
> bridge across it, and no realistic plan for such a bridge to really be
> built any time soon.  I still come back to issues with ip0 on
> occasion, and I try to work on ip1, but the split is too much for my
> limited time.  This has left me personally disenchanted with the
> project, feeling that I'm not really doing anything of quality on any
> front.
>
> So our current rethinking is: forge ahead with what we've been calling
> IPython0, and begin integrating the various key (and functional)
> components of IPython1 into it one by one.  The IPython0/1 split will
> end, and we will use all the good pieces of IPython1 to add
> functionality to ip0 without losing its current features.  At each 0.X
> release we'll clearly document any api breakage that might happen.
>
> This would bring us a number of benefits:
>
>  * We would be forced to only commit _finished_ stuff to ipython0
> because otherwise there will be lots of pissed off IPython0 users.
>
>  * We go from a situation where few people are trying our new code, to
> one where thousands of people are trying it.
>
>  * If we moved stuff in IPython.* -> IPython.core.*, we could then
> move things in ipython1.kernel.* -> IPython.kernel.*.  It one simple
> step, _every_ IPython user has parallel computing at their finger
> tips.  With our current approach, the parallel computing stuff will
> always be "over there" for your average IPython user and won't be used
> until ipython1 is a full replacement for ipython0.
>
>  * It would be sooo much simpler to manage one code base and documentation set.
>
>  * It would be much easier to explain to people that state of ipython.
>  "IPython is just IPython and now it has parallel computing"  The
> ambitious plans for refactoring, notebooks, frontends are underway,
> but IPython is still just IPython.
>
>  * The parallel computing stuff would instantly make it into all the
> Linux distros.
>
>  * Design problems will emerge much faster as we will always have a
> completely working terminal based IPython to test everything on.
> Things like -pylab can't be broken, not even for a second.  Whereas in
> ipython1, we are a long way off from even thinking about such things.
>
>  * We don't have to handle the questions like "I want to implement
> such and such in IPython, should I use ipython0 or ipython1"
>
>  * Our entire combined effort (limited as it may be, we have some
> great people on board) can be focused on a single problem, and we can
> all trust that we're working together for the same goal.
>
>
> In retrospect, I take full blame for any mistakes that I pushed for.
> While having a clean slate for thinking IPython1 ideas was probably
> beneficial, and none of that work is going to be lost (we'll just fold
> it piece by piece into the trunk), some of my ideas led to this
> paralysis.  Live and learn.
>
> So, any comments?  We'd like to move forward *quickly* with this idea.
> We'd try to make a series of much more frequent releases, one for each
> key component we add in, so that little by little the baby can
> actually grow.   There will be an initial period where I would prepare
> the ground in ip0 for the ip1 components to land in while Brian
> finishes a couple of things he has in his local branch, but we're
> talking a couple of weeks, not years.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From laurent.dufrechou at gmail.com  Sun Jun  1 19:07:00 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Mon, 2 Jun 2008 01:07:00 +0200
Subject: [IPython-dev] Going mad with bzr push
In-Reply-To: <db6b5ecc0806011223l4c7903b9v6beec62a94cc575d@mail.gmail.com>
References: <7ced318f0806010501l2bf16e59t298e4a411ce5385f@mail.gmail.com>
	<db6b5ecc0806011223l4c7903b9v6beec62a94cc575d@mail.gmail.com>
Message-ID: <7ced318f0806011607v437f29b1q654cda713051e160@mail.gmail.com>

Yep thx!

2008/6/1 Fernando Perez <fperez.net at gmail.com>:

> On Sun, Jun 1, 2008 at 5:01 AM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
> > Hi guys,
> > Since this morning, i've tryied to push from my recent linux install...
> > without success.
> > I've done:
> > ssh-keygen -t dsa
> > ssh-add id_dsa
> > uploaded the public key to my launchpad account that is laurent.dufrechou
> > and:
> >
> >  bzr push
> > bzr+ssh://
> laurent.dufrechou at bazaar.launchpad.net/ipython/~ipython/stable-dev/<http://laurent.dufrechou at bazaar.launchpad.net/ipython/%7Eipython/stable-dev/>
> >
> > and got:
> > No such Launchpad account: laurent.dufrechou
> > No such Launchpad account: laurent.dufrechou
> > Permission denied (publickey).
> > bzr: ERROR: Connection closed: please check connectivity and permissions
> > (and try -Dhpss if further diagnosis is required)
> >
>
> I see your account as:
>
> https://launchpad.net/~laurent-dufrechou<https://launchpad.net/%7Elaurent-dufrechou>
>
> There's a '-', not a '.' between your first/last names.  That could be
> the problem.
>
> Cheers,
>
> f
>



-- 
Laurent Dufrechou
Hardware Engineering

Marport
16 Blv Abb? Louis LE CAM
56100 Lorient

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

From fperez.net at gmail.com  Sun Jun  1 19:48:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 16:48:36 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>
Message-ID: <db6b5ecc0806011648r231094f0o97c4adbad9f61626@mail.gmail.com>

Hey Barry,

On Sun, Jun 1, 2008 at 2:26 PM, Barry Wark <barrywark at gmail.com> wrote:
> Sorry to jump in late on the discussion. As the token frontend guy, I
> think this sounds like a good idea too. My understanding is that
> following the reintegration, ipython0 will instantly be the
> terminal-based front-end for the ipython1 features. That's great. We
> can continue efforts to make Twisted-based GUI frontends for ipython1.
> But, how are we planning to make ipython0 features (such as macros
> etc.) available via the engineservice interfaces? My (weak)
> understanding of the ipython0 codebase is that much of the ipython0
> Interpreter is tied to the terminal/readline interface. Integrating
> that with Twisted is (as we've just seen) difficult. So, is there a
> plan yet for using ipython0's features in non-terminal-based use
> cases?

Glad  you pitched in.  Yes, the plan will  be simply to gradually
morph the current ip0 code so it supports the abstractions needed for
things like what you're working on.  The code is fairly tied to the
terminal, but that doesn't mean we can't untie it :)  In fact, various
people have hacked it into submission (Laurent for WX, there's a GTK
example, I've seen an OpenGL console somewhere...).

So what we'll do is simply try to do a series of targeted small
releases where we can make these changes in a somewhat controlled
manner, but admitting (and advertising) that there WILL be some
inevitable API breakages.

I took the attitude of keeping the IP0 100% frozen in time and
expecting ip1 to eventually become ipython 1.0 with a potentially new
API.  From a development process perspective, we've seen that turned
out to have problems [1].  So now we'll just move on top of what we
have, add all the (good) code that had been written for ip1 and morph
interfaces as needed.  We'll  make an honest effort to keep the most
user-facing APIs  unchanged, but I won't make any promises.  If we
have to break an API, we'll do it.  Some WILL break, period.  We'll
just need to be diligent with our api_changes.txt document so it's
always an honest reference of what has changed and when.

Cheers,

f

[1] I should say that I don't think it was all a mistake: thinking on
a clean slate for ip1 let Brian, Min and I have lots of wild-eyed
discussions (and boy did we) on a number of topics, that would
probably have been much more constrained if we felt we were working
within the confines of the must-be-respected-at-all-costs iptyhon0
codebase (and supported by the very rigid workflow of SVN).  But
still, it is now clear that we made process mistakes.  Live and
learn...  Thanks again for the well thought out feedback from
everyone!


From fperez.net at gmail.com  Sun Jun  1 21:27:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 18:27:57 -0700
Subject: [IPython-dev] Please do NOT push to launchpad for a bit.
Message-ID: <db6b5ecc0806011827u36241b83l43b767c3cfb7a4e7@mail.gmail.com>

Hi all,

I got some help on the bzr list that seems like it's going to help.
The history may end up a bit mangled but it will likely not be lost.
So please hold off any pushes until a bit later so I don't have to
remerge again.

thanks

f


From ellisonbg.net at gmail.com  Sun Jun  1 23:02:30 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 1 Jun 2008 21:02:30 -0600
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>
Message-ID: <6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com>

> Sorry to jump in late on the discussion. As the token frontend guy, I
> think this sounds like a good idea too. My understanding is that
> following the reintegration, ipython0 will instantly be the
> terminal-based front-end for the ipython1 features. That's great. We
> can continue efforts to make Twisted-based GUI frontends for ipython1.
> But, how are we planning to make ipython0 features (such as macros
> etc.) available via the engineservice interfaces? My (weak)
> understanding of the ipython0 codebase is that much of the ipython0
> Interpreter is tied to the terminal/readline interface. Integrating
> that with Twisted is (as we've just seen) difficult. So, is there a
> plan yet for using ipython0's features in non-terminal-based use
> cases?

Another thing that we should mention, that is relevant to your work on
the Cocoa frontend it that all of the stuff in ipython1 that you are
depending on for your Cocoa frontend will be moved into ipython0 very
soon (mainly ipython1.kernel and ipython1.core).  As Fernando
mentioned, this doesn't mean that it will magically and immediately
grow all the extra ipython0 capabilities.  But your Cocoa stuff should
work fine with a few import changes.  We will keep you posted.

Brian

> Barry
>
>
> On Sat, May 31, 2008 at 7:55 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> Hi all,
>>
>> after much thought and hand-wringing, Brian and I would like to bring
>> up an idea for a change of plans in the development process that will
>> hopefully make us all happier, more efficient, and will lead to more
>> usable code sooner, which is after all what we want.  Please pitch in
>> with any comments you may have, ideas, dissent, etc.
>>
>> The current ipython development process is, we think, far less
>> efficient than it could be.  Coupled with the fact that we have a
>> rather small core team, this is leading to sometimes near paralysis.
>> It is particularly unfair to Ville, who is tasked with maintaining an
>> actively (and very widely) used project on a codebase with no clear
>> future, and yet we have in ipython1 a codebase with split-personality
>> disorder: lovely parallel computing interfaces but a bunch of "we'll
>> get there soon" components that are all half-finished.
>>
>> In all this, Brian and Min try to push ip1 forward, Barry Wark works
>> on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but
>> that work is half-repeated in ip0 and ip1, etc.  And in the meantime,
>> I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on
>> growing wider, with the so far unfulfilled promised of building a
>> bridge across it, and no realistic plan for such a bridge to really be
>> built any time soon.  I still come back to issues with ip0 on
>> occasion, and I try to work on ip1, but the split is too much for my
>> limited time.  This has left me personally disenchanted with the
>> project, feeling that I'm not really doing anything of quality on any
>> front.
>>
>> So our current rethinking is: forge ahead with what we've been calling
>> IPython0, and begin integrating the various key (and functional)
>> components of IPython1 into it one by one.  The IPython0/1 split will
>> end, and we will use all the good pieces of IPython1 to add
>> functionality to ip0 without losing its current features.  At each 0.X
>> release we'll clearly document any api breakage that might happen.
>>
>> This would bring us a number of benefits:
>>
>>  * We would be forced to only commit _finished_ stuff to ipython0
>> because otherwise there will be lots of pissed off IPython0 users.
>>
>>  * We go from a situation where few people are trying our new code, to
>> one where thousands of people are trying it.
>>
>>  * If we moved stuff in IPython.* -> IPython.core.*, we could then
>> move things in ipython1.kernel.* -> IPython.kernel.*.  It one simple
>> step, _every_ IPython user has parallel computing at their finger
>> tips.  With our current approach, the parallel computing stuff will
>> always be "over there" for your average IPython user and won't be used
>> until ipython1 is a full replacement for ipython0.
>>
>>  * It would be sooo much simpler to manage one code base and documentation set.
>>
>>  * It would be much easier to explain to people that state of ipython.
>>  "IPython is just IPython and now it has parallel computing"  The
>> ambitious plans for refactoring, notebooks, frontends are underway,
>> but IPython is still just IPython.
>>
>>  * The parallel computing stuff would instantly make it into all the
>> Linux distros.
>>
>>  * Design problems will emerge much faster as we will always have a
>> completely working terminal based IPython to test everything on.
>> Things like -pylab can't be broken, not even for a second.  Whereas in
>> ipython1, we are a long way off from even thinking about such things.
>>
>>  * We don't have to handle the questions like "I want to implement
>> such and such in IPython, should I use ipython0 or ipython1"
>>
>>  * Our entire combined effort (limited as it may be, we have some
>> great people on board) can be focused on a single problem, and we can
>> all trust that we're working together for the same goal.
>>
>>
>> In retrospect, I take full blame for any mistakes that I pushed for.
>> While having a clean slate for thinking IPython1 ideas was probably
>> beneficial, and none of that work is going to be lost (we'll just fold
>> it piece by piece into the trunk), some of my ideas led to this
>> paralysis.  Live and learn.
>>
>> So, any comments?  We'd like to move forward *quickly* with this idea.
>> We'd try to make a series of much more frequent releases, one for each
>> key component we add in, so that little by little the baby can
>> actually grow.   There will be an initial period where I would prepare
>> the ground in ip0 for the ip1 components to land in while Brian
>> finishes a couple of things he has in his local branch, but we're
>> talking a couple of weeks, not years.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> 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 Jun  1 23:30:27 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 20:30:27 -0700
Subject: [IPython-dev] Can others push to lp right now?
Message-ID: <db6b5ecc0806012030j629ed572rf90ea15edfac9c5f@mail.gmail.com>

Hi folks,

I've got the branch merge ready to go, and now for some reason I can't
connect.  I'm getting this message:

maqroll[lp-svn]> bzr push
bzr+ssh://fdo.perez at bazaar.launchpad.net/~ipython/ipython/main
ssh: connect to host bazaar.launchpad.net port 22: Connection refused
bzr: ERROR: Connection closed: please check connectivity and
permissions (and try -Dhpss if further diagnosis is required)

(that -Dhpss option doesn't do anything else).  I tried to commit a
trivial change to one of the ip1 branches and I still can't commit
either right now, and I also tried from my office without success.

Is it something on my end, or is LP down just now?  Can another dev
please try some trivial commit?

thanks

f


From fperez.net at gmail.com  Sun Jun  1 23:35:03 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 20:35:03 -0700
Subject: [IPython-dev] Can others push to lp right now?
In-Reply-To: <db6b5ecc0806012030j629ed572rf90ea15edfac9c5f@mail.gmail.com>
References: <db6b5ecc0806012030j629ed572rf90ea15edfac9c5f@mail.gmail.com>
Message-ID: <db6b5ecc0806012035w73cb5663t76c214ce351fa14f@mail.gmail.com>

On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> I've got the branch merge ready to go, and now for some reason I can't
> connect.  I'm getting this message:

Never mind.  I went on IRC and got this:

Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance


Great timing...

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 01:11:53 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 22:11:53 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
	<cd7634ce0806011426m4514cbf2k26b21a78e563ea52@mail.gmail.com>
	<6ce0ac130806012002k56053058yf8cc6d7f9659407d@mail.gmail.com>
Message-ID: <db6b5ecc0806012211t28b02fc2u454fb937c78adc2c@mail.gmail.com>

On Sun, Jun 1, 2008 at 8:02 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> Another thing that we should mention, that is relevant to your work on
> the Cocoa frontend it that all of the stuff in ipython1 that you are
> depending on for your Cocoa frontend will be moved into ipython0 very
> soon (mainly ipython1.kernel and ipython1.core).  As Fernando
> mentioned, this doesn't mean that it will magically and immediately
> grow all the extra ipython0 capabilities.  But your Cocoa stuff should
> work fine with a few import changes.  We will keep you posted.

As soon as we settle down in terms of the infrastructure changes to
allow this to move forward (a few days, I hope), we'll all need to
look into how exactly to best do all of this.  The point  is that we
want *all* the work that was done on ip1 and that led to useful
features (even if incomplete) to come into a single project.  We'll
work on making that happen.

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 01:25:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 22:25:00 -0700
Subject: [IPython-dev] IMPORTANT: Branches merged on launchpad,
	updates required.
Message-ID: <db6b5ecc0806012225p6258f86dn2f18c3cf6aa983b@mail.gmail.com>

Hi everyone,

I was able to do a merge of the old SVN history along with the work
done from February until today on the stable-dev branch.  Now the main
branch you download from Launchpad contains the entire project history
since the first SVN commit, at least for the trunk (the first 3+ years
of history were on CVS and I was dumb enough to lose them in the
transition to SVN.  Oh well.).

But please note: you need to re-download IPython from launchpad,
whether you use bzr just to track the tunk or to develop.  Please run
again

bzr branch lp:ipython

to get the trunk out.  This is the web page for the trunk:

https://code.launchpad.net/~ipython/ipython/trunk

Note that while the 990 commit swallowed the entire history of the
stable-dev branch,  that is only the case when viewing it via the
launchpad web interface.  If you get the branch and view it locally
(with bzr viz, for example), you'll see the whole history with
individual commits.

To developers: please remember the worfklow guidelines from

http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines

and please update/improve that page if my instructions were in any way
incorrect (I'm just now really getting the hang of a good bzr
workflow).

I have marked the stable-dev branch as "merged", so it doesn't appear
by default anymore in most displays at launchpad, but it was NOT
deleted (and it won't), it's still here for reference:

https://code.launchpad.net/~ipython/ipython/stable-dev

So it seems we're fully off SVN!  Welcome to the great bright world of
DVCS everyone :)

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 02:11:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 23:11:55 -0700
Subject: [IPython-dev] For transforming user input
In-Reply-To: <6ce0ac130804111506k6af69895pb006e3d3879c4bb9@mail.gmail.com>
References: <6ce0ac130804111506k6af69895pb006e3d3879c4bb9@mail.gmail.com>
Message-ID: <db6b5ecc0806012311w52bc8e11r2ac2bb6b2087dd6d@mail.gmail.com>

On Fri, Apr 11, 2008 at 3:06 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> I thought this was nice:
>
> http://pyside.blogspot.com/2008/03/ast-compilation-from-python.html
>
> We might think about allowing prefilter to do such transformations in ipython1.

Nice :)  And the context managers could also use this type of
transformation... Let's keep this in mind now moving on.

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 02:19:53 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 1 Jun 2008 23:19:53 -0700
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
References: <AciRRoCFBNcQ4KqYTC+2M8PmvDU8jgAOIUig>
	<47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
Message-ID: <db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>

Hey Laurent,

sorry I'm only now digging from under the world :)

2008/3/29 Laurent Dufrechou <laurent.dufrechou at gmail.com>:
> Hi guys,
>
> I've submitted a pre-plugin for editra as an alternative to pyshell ;)
>
> All is working except some quirk with ctrl+c (editra interact with it) and
> enter under mac osx?.
>
> (I had never tried under mac osx.)
>
> So here are my two help request:
>
> -Can somebody tell if it exist a macosx emulator??? Or is there someone
> willing to help me debug this remotely? (else trying to correct the code by
> itself with my help or perhaps via a vnc connection?)

I think people have hacked OSX into running under virtualization
environments, but it's not officially supported as best I know.

> Here is what cody saw:
>
> 2) The plugin loads and shows on Mac OSX but there must be some problem with
> the key handling because hitting 'Enter' only inserts a new line in the
> control and doesn't execute the command. This problem doesn't exist when
> running under wxGTK.
>
>
>
> -Cody is asking if it is possible to embed Ipython in the plugin:
>
> It might also be interesting to try and embed IPython itself into the plugin
> so nobody has to worry about dependencies. If IPython is pure python (not a
> C extension) this should be as easy as copying the IPython directory into
> your plugins __init__.py path and then including it the setup.py's data
> files.
>
>
>
> Does Ipython as C dependency I'm not aware of???

No, IPython is pure python.  So yes, embedding it should be pretty
straightforward.  See this:

http://ipython.scipy.org/doc/manual/ipython.html#embedding-ipython

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 03:27:13 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 00:27:13 -0700
Subject: [IPython-dev] Development on Launchpad, odds and ends
Message-ID: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>

Hi everyone,

I think we're now in decent shape regarding the transition to
Launchpad (I updated the Trac site and the Moin wiki to reflect this).
 I still find the Launchpad site a PITA to navigate and find
information about, but let's hope it will improve as more people use
it.

We have two official "series" for IPython (these were there before,
what  I did was change branch structure, not the series):

https://launchpad.net/ipython/trunk
https://launchpad.net/ipython/stable

They are for now basically copies of each other, since 'stable' is
also tied to the trunk bzr branch.  I suppose from a a project
management perspective, we'll just want to make a separate branch for
stable maintenance if we ever get into backport mode.  We can make
series for major releases later if really needed.

Right now I think the only key topic to clean things up is the
proliferation of ipython1 branches:

https://code.launchpad.net/ipython

Brian is actively working on -fc, Barry on -cocoa, Min is out of town,
and we should keep the ipython1-dev one around until the dust settles.
 But I'd suggest cleaning up a bit what we can if possible.  It will
give us a better focus for the integration process.  Let's sort out
what the best process for that merge will be over the next few days...

So let's see how this whole thing moves forward.  I'm going to work on
preparing the trunk to 'receive' ipython1 code over the next few days,
I'll  likely do that in a publicly visible branch and periodically
merge that into trunk.  I'll announce it here as soon as it's up.

One last word: please be careful from now on with trunk.  We don't
have ipython0/1 anymore, but that means the trunk is that much more
important.  We'll port over the documentation and tests from ip1 and I
will add testing support for all the code, so that we can refactor
cleanly.  We'll  also uniformize the code for calling conventions as
we go, for documentation quality, docstrings, etc.

I've subscribed by email to the trunk to keep an eye out on all
commits.  Please from now on, let's all try to write clean, documented
and well organized code.  This is the line of the project that we
expect will live for a long time, so we all want it to be as clean and
manageable as possible.  No files without top-level docstrings, no
functions without proper reST docstrings, etc.  I'll be backing off
improper commits if need be, but hopefully we won't have to get into
that.  We may eventually consider instituting a formal code review
system for all patches, but I'm a bit worried that right now we just
don't have the resources for that, especially when we're faced with a
period of rapid code merge/churn by only a few people.

But let's all try our best to work for the highest standards of code
quality.  We'll all benefit.

IPython0/1 are dead.  Long live IPython! ;)

Cheers,

f


From laurent.dufrechou at gmail.com  Mon Jun  2 04:12:53 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Mon, 2 Jun 2008 10:12:53 +0200
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>
References: <AciRRoCFBNcQ4KqYTC+2M8PmvDU8jgAOIUig>	
	<47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>
Message-ID: <4843ab8f.1358560a.46cd.ffffde15@mx.google.com>

Ho you saw this :)
It is solved now!
Here is the page for the plugin if anyone has some interest:

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

There still some problems with path interaction etc... that I try to solve
with editra developer cody precod.
The good point is that he is a macosx dev so he has solved some problem of
my code under macosx!

All is packed in a an egg thanks to the fact that ipython is only pure
python!

Chers,
Laurent

-----Message d'origine-----
De?: Fernando Perez [mailto:fperez.net at gmail.com] 
Envoy??: lundi 2 juin 2008 08:20
??: Laurent Dufrechou
Cc?: ipython-dev Mailing list
Objet?: Re: [IPython-dev] Help! TR: TR: Ipython plugin

Hey Laurent,

sorry I'm only now digging from under the world :)

2008/3/29 Laurent Dufrechou <laurent.dufrechou at gmail.com>:
> Hi guys,
>
> I've submitted a pre-plugin for editra as an alternative to pyshell ;)
>
> All is working except some quirk with ctrl+c (editra interact with it) and
> enter under mac osx
.
>
> (I had never tried under mac osx.)
>
> So here are my two help request:
>
> -Can somebody tell if it exist a macosx emulator??? Or is there someone
> willing to help me debug this remotely? (else trying to correct the code
by
> itself with my help or perhaps via a vnc connection?)

I think people have hacked OSX into running under virtualization
environments, but it's not officially supported as best I know.

> Here is what cody saw:
>
> 2) The plugin loads and shows on Mac OSX but there must be some problem
with
> the key handling because hitting 'Enter' only inserts a new line in the
> control and doesn't execute the command. This problem doesn't exist when
> running under wxGTK.
>
>
>
> -Cody is asking if it is possible to embed Ipython in the plugin:
>
> It might also be interesting to try and embed IPython itself into the
plugin
> so nobody has to worry about dependencies. If IPython is pure python (not
a
> C extension) this should be as easy as copying the IPython directory into
> your plugins __init__.py path and then including it the setup.py's data
> files.
>
>
>
> Does Ipython as C dependency I'm not aware of???

No, IPython is pure python.  So yes, embedding it should be pretty
straightforward.  See this:

http://ipython.scipy.org/doc/manual/ipython.html#embedding-ipython

Cheers,

f



From fperez.net at gmail.com  Mon Jun  2 04:17:14 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 01:17:14 -0700
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <4843ab8f.1358560a.46cd.ffffde15@mx.google.com>
References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>
	<4843ab8f.1358560a.46cd.ffffde15@mx.google.com>
Message-ID: <db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>

On Mon, Jun 2, 2008 at 1:12 AM, Laurent Dufr?chou
<laurent.dufrechou at gmail.com> wrote:
> Ho you saw this :)
> It is solved now!
> Here is the page for the plugin if anyone has some interest:
>
> http://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin

OK, great!  Keep the needs of all this in mind as we begin the
reorganization/merge, so we can get a set of APIs that make this kind
of usage cleaner/easier.

Cheers,

f


From stefan at sun.ac.za  Mon Jun  2 04:46:35 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 10:46:35 +0200
Subject: [IPython-dev] Can others push to lp right now?
In-Reply-To: <db6b5ecc0806012035w73cb5663t76c214ce351fa14f@mail.gmail.com>
References: <db6b5ecc0806012030j629ed572rf90ea15edfac9c5f@mail.gmail.com>
	<db6b5ecc0806012035w73cb5663t76c214ce351fa14f@mail.gmail.com>
Message-ID: <9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com>

2008/6/2 Fernando Perez <fperez.net at gmail.com>:
> On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> Hi folks,
>>
>> I've got the branch merge ready to go, and now for some reason I can't
>> connect.  I'm getting this message:
>
> Never mind.  I went on IRC and got this:
>
> Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance

They upgraded Launchpad.  The latest version implements branch
commenting, which looks like a crude sub-set of a code review tool:

Vote and comment on proposed branch mergers
--------------------------------------------

Launchpad's merge proposals are a great way for project contributors
to get their code considered for inclusion in the main line.

Now, branch owners - and anyone else who's interested - can vote and
comment on merge proposals.

"""
Aaron Bentley, who's been working on the feature, says:

 These changes make it easy to discuss and tweak proposed changes to a
 branch. You can browse the branch which contains the changes then
 comment and vote directly on what you've seen.

Comments build into a threaded conversation about the branch. You can
also vote either on the branch as whole, or use custom tags to apply
your vote to a specific aspect of the work.

Take a look at one of the first branch merger comments here:

https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296/

This is just the start for this feature. Keep an eye on future
Launchpad releases!
"""


Cheers
St?fan


From cohen at slac.stanford.edu  Mon Jun  2 05:04:00 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 02 Jun 2008 11:04:00 +0200
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
References: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
Message-ID: <4843B780.3010806@slac.stanford.edu>

hi there,
I am even more a spectator than John, but I fully concur with the 
conclusions that incrementing ipy0 is the right approach. I have been 
downloading both versions of ipython in order to check where were the 
features I needed or wanted to explore, and the parallelism is certainly 
not available to any ipython user as it stands now. I somewhat 
sheepishly asked in this list a few weeks ago why there were no ipython1 
executable  to try out the corresponding features!
You might even gain in developer's base by proceeding this way ;)

So, +1 big time on reconsidering developing ipy1 within ipy0!
best,
Johann

Fernando Perez wrote:
> [ Folks: this message was sent to ipython-dev, where  the bulk of the
> discussion  is likely to take place.  But I want to make sure all
> users see it, and everyone's comments are welcome]
>
> Hi all,
>
> after much thought and hand-wringing, Brian and I would like to bring
> up an idea for a change of plans in the development process that will
> hopefully make us all happier, more efficient, and will lead to more
> usable code sooner, which is after all what we want.  Please pitch in
> with any comments you may have, ideas, dissent, etc.
>
> The current ipython development process is, we think, far less
> efficient than it could be.  Coupled with the fact that we have a
> rather small core team, this is leading to sometimes near paralysis.
> It is particularly unfair to Ville, who is tasked with maintaining an
> actively (and very widely) used project on a codebase with no clear
> future, and yet we have in ipython1 a codebase with split-personality
> disorder: lovely parallel computing interfaces but a bunch of "we'll
> get there soon" components that are all half-finished.
>
> In all this, Brian and Min try to push ip1 forward, Barry Wark works
> on Cocoa, Laurent works on the WX sell, Ondrej helps us with docs but
> that work is half-repeated in ip0 and ip1, etc.  And in the meantime,
> I'm feeling like I'm straddling a chasm (ip0-ip1) that keeps on
> growing wider, with the so far unfulfilled promised of building a
> bridge across it, and no realistic plan for such a bridge to really be
> built any time soon.  I still come back to issues with ip0 on
> occasion, and I try to work on ip1, but the split is too much for my
> limited time.  This has left me personally disenchanted with the
> project, feeling that I'm not really doing anything of quality on any
> front.
>
> So our current rethinking is: forge ahead with what we've been calling
> IPython0, and begin integrating the various key (and functional)
> components of IPython1 into it one by one.  The IPython0/1 split will
> end, and we will use all the good pieces of IPython1 to add
> functionality to ip0 without losing its current features.  At each 0.X
> release we'll clearly document any api breakage that might happen.
>
> This would bring us a number of benefits:
>
>  * We would be forced to only commit _finished_ stuff to ipython0
> because otherwise there will be lots of pissed off IPython0 users.
>
>  * We go from a situation where few people are trying our new code, to
> one where thousands of people are trying it.
>
>  * If we moved stuff in IPython.* -> IPython.core.*, we could then
> move things in ipython1.kernel.* -> IPython.kernel.*.  It one simple
> step, _every_ IPython user has parallel computing at their finger
> tips.  With our current approach, the parallel computing stuff will
> always be "over there" for your average IPython user and won't be used
> until ipython1 is a full replacement for ipython0.
>
>  * It would be sooo much simpler to manage one code base and documentation set.
>
>  * It would be much easier to explain to people that state of ipython.
>  "IPython is just IPython and now it has parallel computing"  The
> ambitious plans for refactoring, notebooks, frontends are underway,
> but IPython is still just IPython.
>
>  * The parallel computing stuff would instantly make it into all the
> Linux distros.
>
>  * Design problems will emerge much faster as we will always have a
> completely working terminal based IPython to test everything on.
> Things like -pylab can't be broken, not even for a second.  Whereas in
> ipython1, we are a long way off from even thinking about such things.
>
>  * We don't have to handle the questions like "I want to implement
> such and such in IPython, should I use ipython0 or ipython1"
>
>  * Our entire combined effort (limited as it may be, we have some
> great people on board) can be focused on a single problem, and we can
> all trust that we're working together for the same goal.
>
>
> In retrospect, I take full blame for any mistakes that I pushed for.
> While having a clean slate for thinking IPython1 ideas was probably
> beneficial, and none of that work is going to be lost (we'll just fold
> it piece by piece into the trunk), some of my ideas led to this
> paralysis.  Live and learn.
>
> So, any comments?  We'd like to move forward *quickly* with this idea.
> We'd try to make a series of much more frequent releases, one for each
> key component we add in, so that little by little the baby can
> actually grow.   There will be an initial period where I would prepare
> the ground in ip0 for the ip1 components to land in while Brian
> finishes a couple of things he has in his local branch, but we're
> talking a couple of weeks, not years.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-user mailing list
> IPython-user at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>   


From ellisonbg.net at gmail.com  Mon Jun  2 10:20:46 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 2 Jun 2008 08:20:46 -0600
Subject: [IPython-dev] Can others push to lp right now?
In-Reply-To: <9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com>
References: <db6b5ecc0806012030j629ed572rf90ea15edfac9c5f@mail.gmail.com>
	<db6b5ecc0806012035w73cb5663t76c214ce351fa14f@mail.gmail.com>
	<9457e7c80806020146n22024be0i9748c522ae587ab8@mail.gmail.com>
Message-ID: <6ce0ac130806020720n6000f5aenb6035200342b80f0@mail.gmail.com>

This looks like it could be really useful.  Especially as it seems
pretty lightweight, which is important for a small team like IPython's

Brian

On Mon, Jun 2, 2008 at 2:46 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/6/2 Fernando Perez <fperez.net at gmail.com>:
>> On Sun, Jun 1, 2008 at 8:30 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>>> Hi folks,
>>>
>>> I've got the branch merge ready to go, and now for some reason I can't
>>> connect.  I'm getting this message:
>>
>> Never mind.  I went on IRC and got this:
>>
>> Topic for #launchpad is: bazaar.launchpad.net shutdown for urgent maintenance
>
> They upgraded Launchpad.  The latest version implements branch
> commenting, which looks like a crude sub-set of a code review tool:
>
> Vote and comment on proposed branch mergers
> --------------------------------------------
>
> Launchpad's merge proposals are a great way for project contributors
> to get their code considered for inclusion in the main line.
>
> Now, branch owners - and anyone else who's interested - can vote and
> comment on merge proposals.
>
> """
> Aaron Bentley, who's been working on the feature, says:
>
>  These changes make it easy to discuss and tweak proposed changes to a
>  branch. You can browse the branch which contains the changes then
>  comment and vote directly on what you've seen.
>
> Comments build into a threaded conversation about the branch. You can
> also vote either on the branch as whole, or use custom tags to apply
> your vote to a specific aspect of the work.
>
> Take a look at one of the first branch merger comments here:
>
> https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296/
>
> This is just the start for this feature. Keep an eye on future
> Launchpad releases!
> """
>
>
> Cheers
> St?fan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Mon Jun  2 12:23:43 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 2 Jun 2008 10:23:43 -0600
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
Message-ID: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>

> I think we're now in decent shape regarding the transition to
> Launchpad (I updated the Trac site and the Moin wiki to reflect this).
>  I still find the Launchpad site a PITA to navigate and find
> information about, but let's hope it will improve as more people use
> it.
>
> We have two official "series" for IPython (these were there before,
> what  I did was change branch structure, not the series):
>
> https://launchpad.net/ipython/trunk
> https://launchpad.net/ipython/stable
>
> They are for now basically copies of each other, since 'stable' is
> also tied to the trunk bzr branch.  I suppose from a a project
> management perspective, we'll just want to make a separate branch for
> stable maintenance if we ever get into backport mode.  We can make
> series for major releases later if really needed.

Thanks for tackling all this Fernando, it needed to be done but it
sounds like it was a bit painful.

> Right now I think the only key topic to clean things up is the
> proliferation of ipython1 branches:
>
> https://code.launchpad.net/ipython
>
> Brian is actively working on -fc, Barry on -cocoa, Min is out of town,
> and we should keep the ipython1-dev one around until the dust settles.
>  But I'd suggest cleaning up a bit what we can if possible.  It will
> give us a better focus for the integration process.  Let's sort out
> what the best process for that merge will be over the next few days...

I will be merging ipython1-fc into ipython1-dev very soon.  The
ipython1-dev branch will probably remain for quite a long time as it
will have all the ipython1 code that is being brought over into
IPython and that will take a while, for some of the more unstable
portions (like the notebook).  There are also some other ipython1
branches that I will 1) either merge into ipython1-dev eventually or
2) delete.

> So let's see how this whole thing moves forward.  I'm going to work on
> preparing the trunk to 'receive' ipython1 code over the next few days,
> I'll  likely do that in a publicly visible branch and periodically
> merge that into trunk.  I'll announce it here as soon as it's up.

This sounds great.  After I merge ipython1-fc into ipython1-dev, I
will begin to pull ipython1-dev things into IPython (in a branch).
Because both of us will be doing pretty heavy things to IPython, lets
make sure we do lots of pushes back to IPython.  We can coordinate
this further when I start to do this.

My initial merging of ipython1 -> IPython will look like this:

ipython1.config -> IPython.config
ipython1.kernel -> IPython.kernel
ipython1.core -> IPython.kernel.core
ipython1.external -> IPython.external (we will need to coordinate this
as some of the externals are already in IPython.

There will be lots of little things to merge in (docs, setup.py) as well.

The code in these parts of ipython1 are very well tested and are
fairly stable.  The other parts of ipython1 (notebook, daemon,
frontend) are less stable and will need to be transitions over to
appropriate branches IPython trunk development.

> One last word: please be careful from now on with trunk.  We don't
> have ipython0/1 anymore, but that means the trunk is that much more
> important.  We'll port over the documentation and tests from ip1 and I
> will add testing support for all the code, so that we can refactor
> cleanly.  We'll  also uniformize the code for calling conventions as
> we go, for documentation quality, docstrings, etc.

I have a good start on a rst based developer guidelines in ipython1
that we an bring into IPython and merge with the info on the moin
page.

> I've subscribed by email to the trunk to keep an eye out on all
> commits.  Please from now on, let's all try to write clean, documented
> and well organized code.  This is the line of the project that we
> expect will live for a long time, so we all want it to be as clean and
> manageable as possible.  No files without top-level docstrings, no
> functions without proper reST docstrings, etc.  I'll be backing off
> improper commits if need be, but hopefully we won't have to get into
> that.  We may eventually consider instituting a formal code review
> system for all patches, but I'm a bit worried that right now we just
> don't have the resources for that, especially when we're faced with a
> period of rapid code merge/churn by only a few people.

I agree that we probably don't have the manpower to do code review,
but subscribing to trunk at least keeps people in the loop.

> But let's all try our best to work for the highest standards of code
> quality.  We'll all benefit.
>
> IPython0/1 are dead.  Long live IPython! ;)

Yes!

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  Mon Jun  2 12:24:15 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 09:24:15 -0700
Subject: [IPython-dev] Please update the man page always.
Message-ID: <db6b5ecc0806020924t1134b371qece6e482abcc8866@mail.gmail.com>

Hi all,

I was writing a response about the new pydb control flag and went to
check how it works for the user, only to find out that it's not
actually documented in the man page.

Please: if you add new flags to the system, it is NOT appropriate to
leave them undocumented.  Every single flag that is recognized by
ipython at the command line should have an entry in the manpage and
the manual, period.  Having undocumented flags that were simply
mentioned in a changelog or release notes is completely unacceptable.

Cheers,

f


From ellisonbg.net at gmail.com  Mon Jun  2 13:05:02 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 2 Jun 2008 11:05:02 -0600
Subject: [IPython-dev] RFC: Launchpad, Trac and bugs
In-Reply-To: <db6b5ecc0806011410v6cf8f40bka7c586a9f71497fe@mail.gmail.com>
References: <db6b5ecc0806011410v6cf8f40bka7c586a9f71497fe@mail.gmail.com>
Message-ID: <6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com>

> we'll see what we end up doing with the recent bzr history, but the
> fact that we're moving to bzr/launchpad for all code work is now a
> done deal.  What I'd like to do is to solicit a bit of feedback on
> what to do with bug tracking, because there I'm a bit less decided.
> We have informally discussed this already in bits and pieces, but now
> I'd like to make a final decision.
>
> The options seem to be:
>
> 1. Keep using Trac for all bugs.  Launchpad even explicitly supports
> linking all bug reports for a project to an external tracker (we'd
> have to register the IPython Trac somehow, but that should be easy).

-1

> 2. Move to the Launchpad bug system for all new bugs.  We could keep
> existing open tickets on Trac and gradually close them, but mark the
> main page indicating that no new bugs should be filed there.

+1

> #2 has the advantage of integrating with the rest of  Launchpad a
> little better, and this ties us in with other projects, the Ubuntu
> package database, etc.  But I have to  admit that so far, I like Trac
> much more than Launchpad for project management/bug tracking.  For all
> of SVN's flaws, trac is actually really nice and usable, while the
> Launchpad site's web interface is very, very clunky.  Simple things
> take a lot of clicking around to do, their documentation is hideous,
> etc.  I love the hosting that launchpad provides, but the system feels
> very, very immature in terms of everyday usability.

I agree with your assesment of Trac vs launchpad in this respect - but
launchpad development seems to be moving fast and we can always give
them feedback about the interface.  Given the fact that we are moving
to a development model that has many branches, I think it is really
important to be able to associate tickets with branches and have
everything integrated.  So many of the things that make Trac nice for
tickets (timeline, code browser, etc) will go away with our code on
launchpad.  Plus, I don't like the idea of people going to our Trac
site - one of the main ways I assess an open source project is to look
at their Trac timeline.  Our timeline will be empty, giving the
misleading impression that IPython is dead.  Also, keeping Trac around
means that we are loosing one of the biggest benefits of launchpad -
that we don't have to do any admin.

Cheers,

Brian

> On the flip side, launchpad has lots of use, hence one hopes lots of
> development, while I worry that Trac seems to be slowing down (0.11
> isn't even out yet, and it has been in that state for a looong time).
>
> So I'd like to hear opinions on the most sensible approach forward.
> One way or another we'll keep all filed tickets we have on both
> systems, so it's just a matter of deciding, and appropriately
> informing our users, what the *official* system will be in the future.
>
> cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From jorgen.stenarson at bostream.nu  Mon Jun  2 13:40:12 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 02 Jun 2008 19:40:12 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
Message-ID: <4844307C.80308@bostream.nu>

Hi,

I just registered pyreadline at launchpad. Considering all the traffic 
on bzr problems. I just thought I should ask here what is the best way 
to move svn over to launchpad? How do I handle the branches and tags?

By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to 
go but this year I'm not going to do a presentation.

/J?rgen



From barrywark at gmail.com  Mon Jun  2 14:05:08 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 2 Jun 2008 11:05:08 -0700
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
	<6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
Message-ID: <cd7634ce0806021105i577c1b56yf6ec8fafd25fc206@mail.gmail.com>

On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I think we're now in decent shape regarding the transition to
>> Launchpad (I updated the Trac site and the Moin wiki to reflect this).
>>  I still find the Launchpad site a PITA to navigate and find
>> information about, but let's hope it will improve as more people use
>> it.
>>
>> We have two official "series" for IPython (these were there before,
>> what  I did was change branch structure, not the series):
>>
>> https://launchpad.net/ipython/trunk
>> https://launchpad.net/ipython/stable
>>
>> They are for now basically copies of each other, since 'stable' is
>> also tied to the trunk bzr branch.  I suppose from a a project
>> management perspective, we'll just want to make a separate branch for
>> stable maintenance if we ever get into backport mode.  We can make
>> series for major releases later if really needed.
>
> Thanks for tackling all this Fernando, it needed to be done but it
> sounds like it was a bit painful.
>
>> Right now I think the only key topic to clean things up is the
>> proliferation of ipython1 branches:
>>
>> https://code.launchpad.net/ipython
>>
>> Brian is actively working on -fc, Barry on -cocoa, Min is out of town,
>> and we should keep the ipython1-dev one around until the dust settles.
>>  But I'd suggest cleaning up a bit what we can if possible.  It will
>> give us a better focus for the integration process.  Let's sort out
>> what the best process for that merge will be over the next few days...
>
> I will be merging ipython1-fc into ipython1-dev very soon.  The
> ipython1-dev branch will probably remain for quite a long time as it
> will have all the ipython1 code that is being brought over into
> IPython and that will take a while, for some of the more unstable
> portions (like the notebook).  There are also some other ipython1
> branches that I will 1) either merge into ipython1-dev eventually or
> 2) delete.

Feel free to (or I can) merge ipython1-cocoa into ipython1-dev or
whatever ipython0 becomes. The only changes in the branch are in
frontends, and all tests for other packages pass so it should be safe
to merge it in.

>
>> So let's see how this whole thing moves forward.  I'm going to work on
>> preparing the trunk to 'receive' ipython1 code over the next few days,
>> I'll  likely do that in a publicly visible branch and periodically
>> merge that into trunk.  I'll announce it here as soon as it's up.
>
> This sounds great.  After I merge ipython1-fc into ipython1-dev, I
> will begin to pull ipython1-dev things into IPython (in a branch).
> Because both of us will be doing pretty heavy things to IPython, lets
> make sure we do lots of pushes back to IPython.  We can coordinate
> this further when I start to do this.
>
> My initial merging of ipython1 -> IPython will look like this:
>
> ipython1.config -> IPython.config
> ipython1.kernel -> IPython.kernel
> ipython1.core -> IPython.kernel.core
> ipython1.external -> IPython.external (we will need to coordinate this
> as some of the externals are already in IPython.

So there will still be a (for now) fundamental difference between
ipython1.kernel.core and IPython.iplib.InteractiveShell?
>
> There will be lots of little things to merge in (docs, setup.py) as well.
>
> The code in these parts of ipython1 are very well tested and are
> fairly stable.  The other parts of ipython1 (notebook, daemon,
> frontend) are less stable and will need to be transitions over to
> appropriate branches IPython trunk development.
>
>> One last word: please be careful from now on with trunk.  We don't
>> have ipython0/1 anymore, but that means the trunk is that much more
>> important.  We'll port over the documentation and tests from ip1 and I
>> will add testing support for all the code, so that we can refactor
>> cleanly.  We'll  also uniformize the code for calling conventions as
>> we go, for documentation quality, docstrings, etc.
>
> I have a good start on a rst based developer guidelines in ipython1
> that we an bring into IPython and merge with the info on the moin
> page.
>
>> I've subscribed by email to the trunk to keep an eye out on all
>> commits.  Please from now on, let's all try to write clean, documented
>> and well organized code.  This is the line of the project that we
>> expect will live for a long time, so we all want it to be as clean and
>> manageable as possible.  No files without top-level docstrings, no
>> functions without proper reST docstrings, etc.  I'll be backing off
>> improper commits if need be, but hopefully we won't have to get into
>> that.  We may eventually consider instituting a formal code review
>> system for all patches, but I'm a bit worried that right now we just
>> don't have the resources for that, especially when we're faced with a
>> period of rapid code merge/churn by only a few people.
>
> I agree that we probably don't have the manpower to do code review,
> but subscribing to trunk at least keeps people in the loop.
>
>> But let's all try our best to work for the highest standards of code
>> quality.  We'll all benefit.
>>
>> IPython0/1 are dead.  Long live IPython! ;)
>
> Yes!
>
> Brian
>
>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Mon Jun  2 14:35:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 11:35:23 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <4844307C.80308@bostream.nu>
References: <4844307C.80308@bostream.nu>
Message-ID: <db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>

Hey,

On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Hi,
>
> I just registered pyreadline at launchpad. Considering all the traffic
> on bzr problems. I just thought I should ask here what is the best way
> to move svn over to launchpad? How do I handle the branches and tags?

Great!  I just approved you for the ip team as well.

I'm not an expert, but you can follow one of several routes:

- use the bzr svn plugin.  This will let you do imports of the svn
history with a fair bit of control.

- Register a branch for their vcs-imports team, typically the trunk.
Here's the ipython one:

https://code.launchpad.net/~vcs-imports/ipython/main

Yesterday what I did was to use that one for the ipython svn->bzr
final move, and basically ditch all the svn tags.  Our svn repo is not
going away, so we can always refer to that for historical purposes.
And if there's ever a move to destroy the svn repo on scipy.org, we
can also convert the whole thing to bzr.

- Do an import from the raw svn repo.  I can run an svn dump of the
whole repo and put it up for you to download if you want to play with
things there (I can probably dump just the pyreadline part so it's
smaller).


In my case, I just went for easy: launchpad did the original svn
import of trunk for us, so it was the least amount of effort to start
from there.  Unless you really want to keep all branches and tags also
in bzr, that will get you off the ground quickly and with full history
(as I said, you can keep on referring to SVN for the foreseeable
future, and if anything ever changes there I'll let you know).

> By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to
> go but this year I'm not going to do a presentation.

I think John Hunter was considering swinging by, but I'm not sure what
his final plans are, check with him.  I know some of the Enthought
guys will go, and perhaps Ondrej could make it, since he's not too
far.  I have too much other stuff going on, and no travel budget for
that kind of trip right now.

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 14:37:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 11:37:33 -0700
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <cd7634ce0806021105i577c1b56yf6ec8fafd25fc206@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
	<6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
	<cd7634ce0806021105i577c1b56yf6ec8fafd25fc206@mail.gmail.com>
Message-ID: <db6b5ecc0806021137v3165eac7n1c6fbc60ac655c89@mail.gmail.com>

On Mon, Jun 2, 2008 at 11:05 AM, Barry Wark <barrywark at gmail.com> wrote:

> Feel free to (or I can) merge ipython1-cocoa into ipython1-dev or
> whatever ipython0 becomes. The only changes in the branch are in
> frontends, and all tests for other packages pass so it should be safe
> to merge it in.

Good to hear that one is fairly focalized.


> So there will still be a (for now) fundamental difference between
> ipython1.kernel.core and IPython.iplib.InteractiveShell?

Initially yes, but my hope is that we'll be able to push that merge
quickly.  That will be the job for the next few weeks: to morph the
current monolithic shells into something with a tad more abstraction
of i/o so they fit the network/gui/twisted models better.

roll up your sleeves :)

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 14:46:17 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 11:46:17 -0700
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
	<6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
Message-ID: <db6b5ecc0806021146t4fa2b88fwd430c655cf8b42a7@mail.gmail.com>

On Mon, Jun 2, 2008 at 9:23 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> Thanks for tackling all this Fernando, it needed to be done but it
> sounds like it was a bit painful.

Thanks for the kind words.  It wasn't too much fun, and part of it is
that the lp web interface is really not very helpful in certain spots.
 But my ignorance of certain aspects of the tools obviously was the
main problem.

In the end it worked pretty well I think, and we didn't end up losing
any history, which is the key point.  The web view is fundamentally
not very good since it doesn't know how to show true branches, but at
least the full history *is* there (bzr log/viz show it all).  This is
much better than the alternative of just dumping in a big commit
message with the old log but no real merge step-by-step history.

> I will be merging ipython1-fc into ipython1-dev very soon.  The
> ipython1-dev branch will probably remain for quite a long time as it
> will have all the ipython1 code that is being brought over into
> IPython and that will take a while, for some of the more unstable
> portions (like the notebook).  There are also some other ipython1
> branches that I will 1) either merge into ipython1-dev eventually or
> 2) delete.

Sounds like a perfect plan, thanks.
> This sounds great.  After I merge ipython1-fc into ipython1-dev, I
> will begin to pull ipython1-dev things into IPython (in a branch).
> Because both of us will be doing pretty heavy things to IPython, lets
> make sure we do lots of pushes back to IPython.  We can coordinate
> this further when I start to do this.

Yup.

> My initial merging of ipython1 -> IPython will look like this:
>
> ipython1.config -> IPython.config
> ipython1.kernel -> IPython.kernel
> ipython1.core -> IPython.kernel.core
> ipython1.external -> IPython.external (we will need to coordinate this
> as some of the externals are already in IPython.
>
> There will be lots of little things to merge in (docs, setup.py) as well.

Yup.

> The code in these parts of ipython1 are very well tested and are
> fairly stable.  The other parts of ipython1 (notebook, daemon,
> frontend) are less stable and will need to be transitions over to
> appropriate branches IPython trunk development.

I'm thinking first and foremost about how to do better testing on
trunk, so we can painlessly absorb all existing ip1 tests, AND improve
our testing practices for the old code as well.  That will be my
immediate focus for the time I can devote to ipython in the coming
days.


> I have a good start on a rst based developer guidelines in ipython1
> that we an bring into IPython and merge with the info on the moin
> page.

Great.  Soon we should also think about a way to reduce the wiki/docs
duplication.  The new work on the numpy docs wiki site could be a
start.  But let's go with what we have for now: that might be a topic
for a sprint at scipy, to generalize that machinery for other projects
to use.

>> IPython0/1 are dead.  Long live IPython! ;)
>
> Yes!

I should close this by giving a huge thanks to everyone not only for
recent feedback, but especially for keeping the project alive and
moving despite the difficult split created by my short-sightedness.
In particular, if it weren't for Ville's steady pushing of the trunk,
I'm afraid we wouldn't have a live project to merge again back into,
and if it weren't for Brian and Min's patience on endless discussions
with me for ip1, we would have nothing to bring :)  So really, thanks
to all for helping this stay alive and interesting, now we'll move
forward.

Regards,

f


From stefan at sun.ac.za  Mon Jun  2 14:51:44 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 20:51:44 +0200
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
	<6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
Message-ID: <9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com>

Hey Brian

2008/6/2 Brian Granger <ellisonbg.net at gmail.com>:
> My initial merging of ipython1 -> IPython will look like this:
>
> ipython1.config -> IPython.config
> ipython1.kernel -> IPython.kernel
> ipython1.core -> IPython.kernel.core
> ipython1.external -> IPython.external (we will need to coordinate this
> as some of the externals are already in IPython.

Has the sconfig branch been merged into ipython1?  It is fairly close
to complete (you'll find the details in the email I sent last time,
but as far as I recall, the only missing functionality is a complete
roundtrip based on configobj, which should take a further 20 minutes
to implement).

Regards
St?fan


From fperez.net at gmail.com  Mon Jun  2 14:59:59 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 11:59:59 -0700
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
	<6ce0ac130806020923m5d5f0164m2c0a8ea8e0400b46@mail.gmail.com>
	<9457e7c80806021151m2d11a881he13abcea1bc15f2b@mail.gmail.com>
Message-ID: <db6b5ecc0806021159jbcc82bam25aa4d18e8df0017@mail.gmail.com>

On Mon, Jun 2, 2008 at 11:51 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Hey Brian
>
> 2008/6/2 Brian Granger <ellisonbg.net at gmail.com>:
>> My initial merging of ipython1 -> IPython will look like this:
>>
>> ipython1.config -> IPython.config
>> ipython1.kernel -> IPython.kernel
>> ipython1.core -> IPython.kernel.core
>> ipython1.external -> IPython.external (we will need to coordinate this
>> as some of the externals are already in IPython.
>
> Has the sconfig branch been merged into ipython1?  It is fairly close
> to complete (you'll find the details in the email I sent last time,
> but as far as I recall, the only missing functionality is a complete
> roundtrip based on configobj, which should take a further 20 minutes
> to implement).

No, I don't think it's been merged yet, but it obviously will.  If you
have a chance to finish that little piece, great!

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 15:45:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 12:45:33 -0700
Subject: [IPython-dev] RFC: Launchpad, Trac and bugs
In-Reply-To: <6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com>
References: <db6b5ecc0806011410v6cf8f40bka7c586a9f71497fe@mail.gmail.com>
	<6ce0ac130806021005k211d14c3wf11dc7c7ab2bb267@mail.gmail.com>
Message-ID: <db6b5ecc0806021245r63a81d1al2c00efd340778605@mail.gmail.com>

On Mon, Jun 2, 2008 at 10:05 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:

>> The options seem to be:
>>
>> 1. Keep using Trac for all bugs.  Launchpad even explicitly supports
>> linking all bug reports for a project to an external tracker (we'd
>> have to register the IPython Trac somehow, but that should be easy).
>
> -1
>
>> 2. Move to the Launchpad bug system for all new bugs.  We could keep
>> existing open tickets on Trac and gradually close them, but mark the
>> main page indicating that no new bugs should be filed there.
>
> +1
>
>> #2 has the advantage of integrating with the rest of  Launchpad a
>> little better, and this ties us in with other projects, the Ubuntu
>> package database, etc.  But I have to  admit that so far, I like Trac
>> much more than Launchpad for project management/bug tracking.  For all
>> of SVN's flaws, trac is actually really nice and usable, while the
>> Launchpad site's web interface is very, very clunky.  Simple things
>> take a lot of clicking around to do, their documentation is hideous,
>> etc.  I love the hosting that launchpad provides, but the system feels
>> very, very immature in terms of everyday usability.
>
> I agree with your assesment of Trac vs launchpad in this respect - but
> launchpad development seems to be moving fast and we can always give
> them feedback about the interface.  Given the fact that we are moving
> to a development model that has many branches, I think it is really
> important to be able to associate tickets with branches and have
> everything integrated.  So many of the things that make Trac nice for
> tickets (timeline, code browser, etc) will go away with our code on
> launchpad.  Plus, I don't like the idea of people going to our Trac
> site - one of the main ways I assess an open source project is to look
> at their Trac timeline.  Our timeline will be empty, giving the
> misleading impression that IPython is dead.  Also, keeping Trac around
> means that we are loosing one of the biggest benefits of launchpad -
> that we don't have to do any admin.


Unless anyone else objects, we'll do #2 then.  That was also the
opinion of Gael and Stefan while at the Paris sprint, and hanging our
hat on a possibly-dying project doesn't sound like a very good idea.
As you correctly point out, we can always give lp feedback on the more
glaring problems, and I'm sure with all the use it's getting, it will
improve over time.

I'll update the Trac wiki a bit later to reflect this then, yell if
you disagree.

Cheers,

f


From laurent.dufrechou at gmail.com  Mon Jun  2 16:39:32 2008
From: laurent.dufrechou at gmail.com (=?US-ASCII?Q?Laurent_Dufrechou?=)
Date: Mon, 2 Jun 2008 22:39:32 +0200
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>
References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>	
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>	
	<4843ab8f.1358560a.46cd.ffffde15@mx.google.com>
	<db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>
Message-ID: <48445a88.02a1660a.6b17.776d@mx.google.com>

Hi Fernando,

[Warning very long mail that do a sum-up(?) of all problem I encoutered to
make an ipython0 gui interaction]

About specific API for GUI devs,
Here is my feeling about what was missing in ipython0 and that could be
refactored/improved while switching to ipython1:

- stdin/stdout/stderr hook (the MOST important):
All ipython0 is tightly glued with pyreadline that is not tailored for
'graphical' gui (from my point of view ^_^):
We should think about an API where we could send data we get from user:
Something like:
	(ip_output,ip_error) = IP.IO.process_input(user_input)

I mean we can stay with pyreadline for console based terminal but I think we
need something simpler for "graphical" gui.
Pyreadline is thought to handle all user key and process input/output for
the console.
In a GUI the designer is using a specific widget he has choosed and handle
its user input the way he want.
So pyreadline is something too much complex for what I needed.(I only use
the ASCII coloration output of pyreadline)
(Another time, this is my point of view, some other devs will say that this
is the job of a readline object: I'm not ok with that because I want to be
free and I need something flexible. "Keep it simple" philosophy)
By the way it could be interesting to have something like what pyreadline is
doing but improved:
IP.IO.setOutFilter("html") or IP.IO.setOutFilter("ANSI") that output the
result as a 'html' or 'xml' or 'ascii_colored' or user_defined filter hook.

My main problems were:

	#we replace the ipython default pager by our pager
	self._IP.set_hook('show_in_pager',self._pager)
        
	#we replace the ipython default shell command caller by our shell
handler
	self._IP.set_hook('shell_hook',self._shell)
        
	#we replace the ipython default input command caller by our method
	IPython.iplib.raw_input_original = self._raw_input
	#we replace the ipython default exit command by our method
	self._IP.exit = ask_exit_handler
	#we replace the help command
	self._IP.user_ns['help'] = _Helper(self._pager_help)

Most of these lines where mostly ugly hack that could have been avoid if I
had the IP.process_input and IP.get_output command.

IP.IO.process_input(user_input) <-- this is really important! See 'def
_execute(self):' in ipshell_nonblocking to see how I handle that.
We can't ask people that want to integrate a new GUI toolkit to write this
sort of code. They will run away ;). Hopefully I've totally copied it from
GTK port :), that's why I didn't ran away ^_^
	

- history management API simpler(my current problem):
Currently ipython history is completely handled by pyreadline. I feel
ipython0 is missing an history API simpler.
Something like;
IP.History.getHistoryLength()
IP.History.loadHistoryFromFile(file)
IP.History.getHistory[number]
In fact this is something I can get from pyreadline, but it is really
complex. I need to access the readline object and then call some function of
function of readline API.
Can be simpler for ipython0 external user. So perhaps this is just some
wrapper around pyreadline to hide the complexity to external and non
specialized user.
It was so complex for me (based on my poor knowledge of ipython0 and
pyreadline) that it was simpler to make my history API.
(And this was also the case with gtk port from which I based my work).

- Completer API.
Sometihng like:
IP.Completer.getCompletion(user_input_to_complete) -> return a list of
completion :
list([completion1,'function'],[completion2,'int'],[completion3,'private']
etc...
Check complete function of ipshell_nonblocking to see how I(hum perhaps
previous guy in fact :) ) did a simpler thing.

That all for the moment ;)

Laurent



From jorgen.stenarson at bostream.nu  Mon Jun  2 17:23:56 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 02 Jun 2008 23:23:56 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
Message-ID: <484464EC.8030502@bostream.nu>

Fernando Perez skrev:
> Hey,
> 
> On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> Hi,
>>
>> I just registered pyreadline at launchpad. Considering all the traffic
>> on bzr problems. I just thought I should ask here what is the best way
>> to move svn over to launchpad? How do I handle the branches and tags?
> 
> Great!  I just approved you for the ip team as well.
> 
> I'm not an expert, but you can follow one of several routes:
> 
I'll look into this tomorrow. Thanks for your input.

/J?rgen



From vivainio at gmail.com  Mon Jun  2 17:39:54 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 00:39:54 +0300
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <48445a88.02a1660a.6b17.776d@mx.google.com>
References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>
	<4843ab8f.1358560a.46cd.ffffde15@mx.google.com>
	<db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>
	<48445a88.02a1660a.6b17.776d@mx.google.com>
Message-ID: <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com>

On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:

> I mean we can stay with pyreadline for console based terminal but I think we
> need something simpler for "graphical" gui.

I agree. However, this can be done as it is now in iplib.py
"interact_with_readline" method (which, admittedly, is not excercised
in current code but mostly server as proof that ipython can be easily
decoupled from raw_input.

> (Another time, this is my point of view, some other devs will say that this
> is the job of a readline object: I'm not ok with that because I want to be
> free and I need something flexible. "Keep it simple" philosophy)

I agree with you here. All the direct references to readline should
factored out of the logic-running classes.

> - Completer API.
> Sometihng like:
> IP.Completer.getCompletion(user_input_to_complete) -> return a list of
> completion :
> list([completion1,'function'],[completion2,'int'],[completion3,'private']
> etc...

This should be easy. test_completer.py introduces how to "hack" your
way aroud the lack of API (so far).

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


From vivainio at gmail.com  Mon Jun  2 18:26:19 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 01:26:19 +0300
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
Message-ID: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>

On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:

> About specific API for GUI devs,
> Here is my feeling about what was missing in ipython0 and that could be
> refactored/improved while switching to ipython1:

Since I have some professional interest to boost my qt skills, I
thought that providing qscintilla (and pyqt4) version of ipython might
be a good way to really find out what needs to be generalized in
IPython. Of course you have already done a good job with wxipython,
but it would really help overall ipython architecture if we made the
code in GUI's as natural as possible (i.e. without needing the hacks
you had to do for wxipython). At least eric4 could then embed ipython
instead of vanilla python.

As assumedly Fernando now re-assumes the coordinator role for the
stable branch, plus the influx of other dev's to ipython0 code base,
it should be much easier for me personally to allocate the "ipython
time" into playing with a largish feature like this.

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


From laurent.dufrechou at gmail.com  Mon Jun  2 18:47:56 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Tue, 3 Jun 2008 00:47:56 +0200
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
Message-ID: <7ced318f0806021547m1abfe11cx8c06c8b5d9dd1b20@mail.gmail.com>

2008/6/3 Ville M. Vainio <vivainio at gmail.com>:

> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
>
> > About specific API for GUI devs,
> > Here is my feeling about what was missing in ipython0 and that could be
> > refactored/improved while switching to ipython1:
>
> Since I have some professional interest to boost my qt skills, I
> thought that providing qscintilla (and pyqt4) version of ipython might
> be a good way to really find out what needs to be generalized in
> IPython. Of course you have already done a good job with wxipython,
> but it would really help overall ipython architecture if we made the
> code in GUI's as natural as possible (i.e. without needing the hacks
> you had to do for wxipython). At least eric4 could then embed ipython
> instead of vanilla python.
>
> As assumedly Fernando now re-assumes the coordinator role for the
> stable branch, plus the influx of other dev's to ipython0 code base,
> it should be much easier for me personally to allocate the "ipython
> time" into playing with a largish feature like this.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>

Hey ville, that seems quite interesting. If ultimately we could merge a lot
of thing I will be more than happy :)
So if you find ways to avoid hack drop me emails.
QT and WX must not be so different ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080603/0dbaea72/attachment.html>

From fperez.net at gmail.com  Mon Jun  2 19:56:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 16:56:28 -0700
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
Message-ID: <db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>

On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
>
>> About specific API for GUI devs,
>> Here is my feeling about what was missing in ipython0 and that could be
>> refactored/improved while switching to ipython1:
>
> Since I have some professional interest to boost my qt skills, I
> thought that providing qscintilla (and pyqt4) version of ipython might
> be a good way to really find out what needs to be generalized in
> IPython. Of course you have already done a good job with wxipython,
> but it would really help overall ipython architecture if we made the
> code in GUI's as natural as possible (i.e. without needing the hacks
> you had to do for wxipython). At least eric4 could then embed ipython
> instead of vanilla python.
>
> As assumedly Fernando now re-assumes the coordinator role for the
> stable branch, plus the influx of other dev's to ipython0 code base,
> it should be much easier for me personally to allocate the "ipython
> time" into playing with a largish feature like this.

That is an excellent plan.  Let's make sure that as we work on this,
we keep in mind:

- the work that Barry has been doing on Cocoa

- correct integration with twisted's event loop.  There's a lot of
interest in the -twisted option working right, and twisted has GUI
integration mechanisms (as discussed here earlier); we just want the
whole thing to play nice with the networking layer used for
distributed use.  Note that the distributed use is not just for
parallel computing: you may also want a Qt/Wx gui working on a remote
ipython instance...

- the needs for the same abstractions to work over the network from
frontends like a web browser that uses JavaScript.

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 20:12:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 17:12:20 -0700
Subject: [IPython-dev] google shell
Message-ID: <db6b5ecc0806021712h6525b5easa05800b692080603@mail.gmail.com>

Something neat I just saw:

http://goosh.org/

IPython would fit right in there...

Cheers,

f


From fperez.net at gmail.com  Mon Jun  2 20:31:42 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 17:31:42 -0700
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
Message-ID: <db6b5ecc0806021731gd83a70xce1dd76bfbbb9565@mail.gmail.com>

On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> Since I have some professional interest to boost my qt skills, I
> thought that providing qscintilla (and pyqt4) version of ipython might
> be a good way to really find out what needs to be generalized in
> IPython. Of course you have already done a good job with wxipython,
> but it would really help overall ipython architecture if we made the
> code in GUI's as natural as possible (i.e. without needing the hacks
> you had to do for wxipython). At least eric4 could then embed ipython
> instead of vanilla python.

I forgot to add that I'm super happy to see you push a Qt gui forward.
 Having wx, qt and cocoa shells out of the box would be really killer.
 We'll work on ensuring they all operate on the same api that a
terminal-based one would.

Cheers,

f


From barrywark at gmail.com  Mon Jun  2 23:10:03 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 2 Jun 2008 20:10:03 -0700
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
	<db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
Message-ID: <cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>

On Mon, Jun 2, 2008 at 4:56 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
>> <laurent.dufrechou at gmail.com> wrote:
>>
>>> About specific API for GUI devs,
>>> Here is my feeling about what was missing in ipython0 and that could be
>>> refactored/improved while switching to ipython1:
>>
>> Since I have some professional interest to boost my qt skills, I
>> thought that providing qscintilla (and pyqt4) version of ipython might
>> be a good way to really find out what needs to be generalized in
>> IPython. Of course you have already done a good job with wxipython,
>> but it would really help overall ipython architecture if we made the
>> code in GUI's as natural as possible (i.e. without needing the hacks
>> you had to do for wxipython). At least eric4 could then embed ipython
>> instead of vanilla python.
>>
>> As assumedly Fernando now re-assumes the coordinator role for the
>> stable branch, plus the influx of other dev's to ipython0 code base,
>> it should be much easier for me personally to allocate the "ipython
>> time" into playing with a largish feature like this.
>
> That is an excellent plan.  Let's make sure that as we work on this,
> we keep in mind:
>
> - the work that Barry has been doing on Cocoa

I would encourage you guys to take a look at the
ipython1.frontends.frontendbase class. My intention is to develop this
into a base class for all GUI frontends. The underlying assumption is
that GUI frontends will interact with the ipython interpreter via the
ipython1.kernel.engineservice (Twisted) API. The benefits, as I see
them for this approach is to avoid rewriting the Wheel of GUI
Integration (the Twisted guys have already done this), and to make it
_very_ easy to provide remote/parallel capabilities from within the
GUI frontend.

Of course, code speaks louder than words and I invite you to hack on
the frontends package (currently in ipython1-cocoa branch, but I
assume soon to be merged inwards towards ipython1-dev or trunk). The
frontendbase is currently a work in progress, but I've attempted to
make it clear where subclasses (e.g. GUI frontend implementations
should subclass particular methods to gain the desired functionality).
The intention is that frontends are an aggregate of a frontendbase
subclass and a GUI widget or a GUI widget (such as a text widget) that
subclasses both the GUI toolkit's widget and the frontendbase.

barry

>
> - correct integration with twisted's event loop.  There's a lot of
> interest in the -twisted option working right, and twisted has GUI
> integration mechanisms (as discussed here earlier); we just want the
> whole thing to play nice with the networking layer used for
> distributed use.  Note that the distributed use is not just for
> parallel computing: you may also want a Qt/Wx gui working on a remote
> ipython instance...

If we stick with developing GUI interfaces through the engineservice
interface, we get all this for free. In addition, I think such an
approach will help drive the ipython1->ipython0 integration because it
will highlight the most pressing areas where we the ipython1's core
(exposed via engineservice) is not up-to-par wrt the ipython0
InteractiveShell.

>
> - the needs for the same abstractions to work over the network from
> frontends like a web browser that uses JavaScript.
>
> 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  Tue Jun  3 02:00:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 2 Jun 2008 23:00:28 -0700
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <4843B780.3010806@slac.stanford.edu>
References: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
	<4843B780.3010806@slac.stanford.edu>
Message-ID: <db6b5ecc0806022300j65bc3b59w207e9a9c5a27bae4@mail.gmail.com>

On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> hi there,
> I am even more a spectator than John, but I fully concur with the
> conclusions that incrementing ipy0 is the right approach. I have been
> downloading both versions of ipython in order to check where were the
> features I needed or wanted to explore, and the parallelism is certainly
> not available to any ipython user as it stands now. I somewhat
> sheepishly asked in this list a few weeks ago why there were no ipython1
> executable  to try out the corresponding features!
> You might even gain in developer's base by proceeding this way ;)

That's precisely the plan :)  As long as we're careful not to piss
people off by breaking too many things at the same time, what users
will experience will be the gradual growth of the parallel features
inside a tool they already use for everyday work.  This is something I
was blind enough to overlook for a long time.  Yes, I'm kicking
myself, you don't need to :)

> So, +1 big time on reconsidering developing ipy1 within ipy0!

Thanks for the feedback, much appreciated.

Cheers,

f


From fperez.net at gmail.com  Tue Jun  3 03:43:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 00:43:28 -0700
Subject: [IPython-dev] message from a launchpad developer
In-Reply-To: <481B3596.5020709@astraw.com>
References: <481972E7.7070006@astraw.com>
	<46cb515a0805020156j7a492475i5bd63c685aa7717@mail.gmail.com>
	<481B3596.5020709@astraw.com>
Message-ID: <db6b5ecc0806030043q445438ecw85d05b667bc9c76@mail.gmail.com>

On Fri, May 2, 2008 at 8:39 AM, Andrew Straw <strawman at astraw.com> wrote:
> Ville M. Vainio wrote:
>> On Thu, May 1, 2008 at 10:36 AM, Andrew Straw <strawman at astraw.com> wrote:
>>
>>
>>> I thought you guys might be interested in this blog post i came across
>>>  -- a launchpad dev is praising the new doctest_mode and suggesting a PPA
>>>  ("Personal Package Archive" -- .deb repository hosted at launchpad) with
>>>  the latest IPython: http://elliotmurphy.com/2008/04/23/ipython-and-doctests/
>>>
>>
>> Anyone know what benefits PPA brings over just uploading the releases
>> to launchpad download folder? It would seem easier to just download
>> and install the release than it is to edit your apt sources list...
>>
> The main benefits I can think of:
>
>  * PPAs integrate with the Ubuntu Update Manager -- a new release will
> be just like any other update from the user's perspective. According to
> their preferences, it will be a single click to install or will be
> automatically installed.
>
>  * The .debs will be built by their buildbots for all the architectures
> they support, which also ensures that your debian package at least
> builds from source.
>
> Of course, .debs should only be installed for the specific version of
> debian (derivative) they were compiled for. Thus, it's not a replacement
> for a source tarball (although a debian source package, by definition,
> comes with an unmodified source tarball), but something in addition to that.

With the new development plans, I think we should do this a bit later
in the summer.   It will provide users on the various ubuntu
derivatives a clean way of getting the new parallel goodies with
little pain.  Thanks for the idea!

Cheers,

f


From ondrej at certik.cz  Tue Jun  3 04:49:20 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 3 Jun 2008 10:49:20 +0200
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0806022300j65bc3b59w207e9a9c5a27bae4@mail.gmail.com>
References: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
	<4843B780.3010806@slac.stanford.edu>
	<db6b5ecc0806022300j65bc3b59w207e9a9c5a27bae4@mail.gmail.com>
Message-ID: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com>

On Tue, Jun 3, 2008 at 8:00 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>> hi there,
>> I am even more a spectator than John, but I fully concur with the
>> conclusions that incrementing ipy0 is the right approach. I have been
>> downloading both versions of ipython in order to check where were the
>> features I needed or wanted to explore, and the parallelism is certainly
>> not available to any ipython user as it stands now. I somewhat
>> sheepishly asked in this list a few weeks ago why there were no ipython1
>> executable  to try out the corresponding features!
>> You might even gain in developer's base by proceeding this way ;)
>
> That's precisely the plan :)  As long as we're careful not to piss
> people off by breaking too many things at the same time, what users
> will experience will be the gradual growth of the parallel features
> inside a tool they already use for everyday work.  This is something I
> was blind enough to overlook for a long time.  Yes, I'm kicking
> myself, you don't need to :)
>
>> So, +1 big time on reconsidering developing ipy1 within ipy0!
>
> Thanks for the feedback, much appreciated.
>

Hi Fernando and other ipython developers,

I never fully understood why you started ipython1 as a separate
project instead of improving ipython that everyone knows
and is in all distributions. So all I can say is a big +1.

Another mistake would have been to release something usable in a year.
That's too late. However releasing things that are ready in small
improvements now is the way to go.

Ondrej


From stefan at sun.ac.za  Tue Jun  3 06:38:50 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Jun 2008 12:38:50 +0200
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com>
References: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
	<4843B780.3010806@slac.stanford.edu>
	<db6b5ecc0806022300j65bc3b59w207e9a9c5a27bae4@mail.gmail.com>
	<85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com>
Message-ID: <9457e7c80806030338t79e61747vef067af9d6d41d20@mail.gmail.com>

2008/6/3 Ondrej Certik <ondrej at certik.cz>:
> Hi Fernando and other ipython developers,
>
> I never fully understood why you started ipython1 as a separate
> project instead of improving ipython that everyone knows
> and is in all distributions. So all I can say is a big +1.

I thought it made sense at the time.  It wasn't immediately apparent
(to me, at least) what the overlap between the new and the old project
would be (or whether there would be any).  Also, without a
proof-of-concept, adding a twistd dependency onto a very lightweight
IPython would have been unpopular (I suppose this could have been an
"optional dependency").

I am glad that the two development streams have merged.  A project
without innovation simply waits to die.  That said, I think it is easy
to overlook the advantages gained by the initial split (that is,
giving Brian, Fernando and Min a blank slate to produce innovative
ideas, as well as providing a test-bed for implementations).

But, hey, all's well that ends well!

Happy hacking,
St?fan


From vds at aisystems.be  Tue Jun  3 09:40:00 2008
From: vds at aisystems.be (Vivian De Smedt)
Date: Tue, 03 Jun 2008 15:40:00 +0200
Subject: [IPython-dev] Editor Syncrhronization
Message-ID: <484549B0.5050301@aisystems.be>

Dear All,

Few month ago I wrote a small patch for IPython that synchronize IPython 
and an external text editor or your choice.

When this patch is active IPython call a hook whenever it put highlight 
on a line of code.
Typically when:
 - Some script throw an uncatched exception
 - We go up and down in the stack in debug mode

I find this useful because it let me
 - Use my editor of choice to view and edit large chunk of code and
 - Use IPython to debug and analyze the variables.

With the new 0.8.3 release I just patch reapply my patch to 0.8.3 to 
have the functionality and it works well for me.

If someone is interested  by this functionality I'll be glad to submit a 
patch.

The modifications are:
 - the definition of a new hook (in hook.py)
 - some call to these hook in Debugger.py and in ultraTB.py
 - and two exemple of hook in Extentions\ip_synchronize_with_ue.py and 
in Extensions\ip_synchronize_with_nppp.py to synchronize with UltraEdit 
and with Notepad++ respectively.

Note: the Notepad++ hook have a flaw it don't synchronize IPython and 
the text file on the right line if the text file is already opened  in 
the editor (which mean in practice that it synchronize at the correct 
line only the first time). This is a Notepad++ flaw that I'll try to 
solve with the Notepad++ peoples.

To test it simply import ip_synchronize_with_xxx in you ipy_user_conf 
IPyhon configuration.

I'll be glad to have some feedback about this proposition of extension.
If needed I could provide some other implementation of the hook for 
other text processor.

Please tell me what you think about this extension, if you could 
consider it for inclusion in IPython and if so what should I do for that.

Vivian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPython.zip
Type: application/octet-stream
Size: 23117 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080603/8cf24837/attachment.obj>

From vivian at vdesmedt.com  Tue Jun  3 10:22:41 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 03 Jun 2008 16:22:41 +0200
Subject: [IPython-dev] Synchronization with gvim
Message-ID: <484553B1.9020405@vdesmedt.com>

Dear All,

Here is a version of the hook that should work for gvim (it suppose that 
gvim is in the path).

Vivian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip_synchronize_with_gvim.zip
Type: application/octet-stream
Size: 501 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080603/45f73545/attachment.obj>

From vivian at vdesmedt.com  Tue Jun  3 10:24:29 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 03 Jun 2008 16:24:29 +0200
Subject: [IPython-dev] Editor Syncrhronization
Message-ID: <4845541D.9040909@vdesmedt.com>

Dear All,

Few month ago I wrote a small patch for IPython that synchronize IPython 
and an external text editor or your choice.

When this patch is active IPython call a hook whenever it put highlight 
on a line of code.
Typically when:
- Some script throw an uncatched exception
- We go up and down in the stack in debug mode

I find this useful because it let me
- Use my editor of choice to view and edit large chunk of code and
- Use IPython to debug and analyze the variables.

With the new 0.8.3 release I just patch reapply my patch to 0.8.3 to 
have the functionality and it works well for me.

If someone is interested  by this functionality I'll be glad to submit a 
patch.

The modifications are:
- the definition of a new hook (in hook.py)
- some call to these hook in Debugger.py and in ultraTB.py
- and two exemple of hook in Extentions\ip_synchronize_with_ue.py and in 
Extensions\ip_synchronize_with_nppp.py to synchronize with UltraEdit and 
with Notepad++ respectively.

Note: the Notepad++ hook have a flaw it don't synchronize IPython and 
the text file on the right line if the text file is already opened  in 
the editor (which mean in practice that it synchronize at the correct 
line only the first time). This is a Notepad++ flaw that I'll try to 
solve with the Notepad++ peoples.

To test it simply import ip_synchronize_with_xxx in you ipy_user_conf 
IPyhon configuration.

I'll be glad to have some feedback about this proposition of extension.
If needed I could provide some other implementation of the hook for 
other text processor.

Please tell me what you think about this extension, if you could 
consider it for inclusion in IPython and if so what should I do for that.

Vivian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPython.zip
Type: application/octet-stream
Size: 23598 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080603/68c2d0f9/attachment.obj>

From vivainio at gmail.com  Tue Jun  3 10:37:24 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 17:37:24 +0300
Subject: [IPython-dev] Editor Syncrhronization
In-Reply-To: <4845541D.9040909@vdesmedt.com>
References: <4845541D.9040909@vdesmedt.com>
Message-ID: <46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com>

On Tue, Jun 3, 2008 at 5:24 PM, Vivian De Smedt <vivian at vdesmedt.com> wrote:

> Few month ago I wrote a small patch for IPython that synchronize IPython and
> an external text editor or your choice.

Can you please send a diff for review instead?

It seems that your implementation is not "risky" (in the sense of
breaking anything), and most of it is in extension there should be no
blocks for getting it in. Can you create a launchpad account and
submit this in a branch?

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


From cohen at slac.stanford.edu  Tue Jun  3 10:44:38 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 03 Jun 2008 16:44:38 +0200
Subject: [IPython-dev] NameError: global name 'error' is not defined
Message-ID: <484558D6.8090700@slac.stanford.edu>

[cohen at jarrett GRBOD]$ ipython
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: %store -d
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/cohen/data1/WORK/GRBOD/<ipython console> in <module>()

/usr/lib/python2.5/site-packages/IPython/iplib.pyc in ipmagic(self, arg_s)
    958         else:
    959             magic_args = self.var_expand(magic_args,1)
--> 960             return fn(magic_args)
    961
    962     def ipalias(self,arg_s):

/usr/lib/python2.5/site-packages/IPython/Extensions/pspersistence.pyc in 
magic_store(self, parameter_s)
     97             todel = args[0]
     98         except IndexError:
---> 99             error('You must provide the variable to forget')
    100         else:
    101             try:

NameError: global name 'error' is not defined


I know I forgot the argument (I should have seen the message 'You must 
provide the variable to forget' right ;) ? ), but still.....
best,
Johann


From ellisonbg.net at gmail.com  Tue Jun  3 12:07:50 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 3 Jun 2008 10:07:50 -0600
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com>
References: <db6b5ecc0805311956p286a421fxe4c5ceab9ea9a66e@mail.gmail.com>
	<4843B780.3010806@slac.stanford.edu>
	<db6b5ecc0806022300j65bc3b59w207e9a9c5a27bae4@mail.gmail.com>
	<85b5c3130806030149h5c9e67e4p339520934c0dfef4@mail.gmail.com>
Message-ID: <6ce0ac130806030907u1ef5b40am77c1d031c4dc86fd@mail.gmail.com>

Thanks everyone for the feedback.  It definitely seems like this is a
very good choice for us and that it will energize the development
process.  I will begin to merge ipython1 things into IPython soon
(hopefully this week).

Cheers,

Brian

On Tue, Jun 3, 2008 at 2:49 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Tue, Jun 3, 2008 at 8:00 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Mon, Jun 2, 2008 at 2:04 AM, Johann Cohen-Tanugi
>> <cohen at slac.stanford.edu> wrote:
>>> hi there,
>>> I am even more a spectator than John, but I fully concur with the
>>> conclusions that incrementing ipy0 is the right approach. I have been
>>> downloading both versions of ipython in order to check where were the
>>> features I needed or wanted to explore, and the parallelism is certainly
>>> not available to any ipython user as it stands now. I somewhat
>>> sheepishly asked in this list a few weeks ago why there were no ipython1
>>> executable  to try out the corresponding features!
>>> You might even gain in developer's base by proceeding this way ;)
>>
>> That's precisely the plan :)  As long as we're careful not to piss
>> people off by breaking too many things at the same time, what users
>> will experience will be the gradual growth of the parallel features
>> inside a tool they already use for everyday work.  This is something I
>> was blind enough to overlook for a long time.  Yes, I'm kicking
>> myself, you don't need to :)
>>
>>> So, +1 big time on reconsidering developing ipy1 within ipy0!
>>
>> Thanks for the feedback, much appreciated.
>>
>
> Hi Fernando and other ipython developers,
>
> I never fully understood why you started ipython1 as a separate
> project instead of improving ipython that everyone knows
> and is in all distributions. So all I can say is a big +1.
>
> Another mistake would have been to release something usable in a year.
> That's too late. However releasing things that are ready in small
> improvements now is the way to go.
>
> Ondrej
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From Alexander_Brown at uml.edu  Tue Jun  3 12:24:09 2008
From: Alexander_Brown at uml.edu (Alex Brown)
Date: Tue, 03 Jun 2008 12:24:09 -0400
Subject: [IPython-dev] Win32 IPython1?
Message-ID: <48457029.8020401@uml.edu>

Hello - this may be the wrong list for this question;  if so my 
apologies.  My next Python excursion involves a simple "parallel 
programming" problem - I am trying to put together Python controller and 
server modules for very coarse-grain parallel processing of GIS and 
remote sensing data using existing Win32 GIS and remote sensing software 
tools running in WinXP on a classroom cluster.  The Win32 COM Python 
tools are fine for local control of these interactive applications and 
I'm trying to find an existing "parallel" network controller toolkit 
that will work in the Win32 world, either native or through Cygwin.  
(The controller environment can be Linux of course.)  I've tried some of 
the "grid" style tools for cluster management that claim to run in 
Cygwin, and found them to be clumsy (batch-oriented) and unreliable.  I 
am now looking into IPython1, and I'd like to know if there is any 
experience with it in a Win32 environment.

Any suggestions would be welcome.

Thanks again -

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


From vivian at vdesmedt.com  Tue Jun  3 12:50:16 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 03 Jun 2008 18:50:16 +0200
Subject: [IPython-dev] Editor Syncrhronization
In-Reply-To: <46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com>
References: <4845541D.9040909@vdesmedt.com>
	<46cb515a0806030737o2211fc35u7d1d9c9139c205e@mail.gmail.com>
Message-ID: <48457648.8050703@vdesmedt.com>

Thank you for you quick answer.

It seems that I can't access launchpad from here probably for security 
reasons.

I'll try to do what you ask from home this week end.

Regards,
Vivian.

PS: I just finalize a synchronization hook for scite.



From vivainio at gmail.com  Tue Jun  3 14:01:08 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 21:01:08 +0300
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
Message-ID: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>

Here is a short guide to launchpad I wrote for Leo editor. It's
applicable to ipython as well, when you substitute "ipython" for
"leo-editor"

--------

Many users will want to track the development version of Leo, in order to stay
on top of the latest features and bugfixes. Running the development version is
quite safe and easy, and it's also a requirement if you want to contribute to
Leo.

1. First, you need to get Bazaar (bzr) from http://bazaar-vcs.org. For windows
 users we recommend the standalone installer - the python installer may have
 problems pushing to Launchpad. Plain bzr installer only contains the command
 line version, so you might want to augment that with a friendly GUI - qbzr is
 recommended as it's the easiest one to install. It provides command like
 ``bzr qlog``, ``bzr qannotate`` etc.

2. Get Leo from launchpad by doing::

   bzr branch lp:leo-editor

And that's it! You can run leo/src/leo.py directly. When you want to refresh the
code with latest modifications from Launchpad, run ``bzr pull``.

If you make modifications to Leo (with the interest in sharing them with the Leo
community), you can check them in to your local branch by doing ``bzr checkin``.
Now, to actually request your changes to be merged to Leo trunk, you need a
Launchpad account with RSA keys in place. There is showmedo video about how to
accomplish this on Windows using puttygen and pageant at
``http://showmedo.com/videos/video?name=1510070&fromSeriesID=151``.

After your Launchpad account is set up, go to
``https://launchpad.net/leo-editor``, choose Code tab -> Register Branch, select
Branch type "Hosted" and fill in descriptive details about the branch. After
that, go to the branch home page from Code tab again, and copy-paste the push
command line to terminal. For example, for branch::

  https://code.launchpad.net/~leo-editor-team/leo-editor/mod_rclick

The push command is::

  bzr push bzr+ssh://my_name at bazaar.launchpad.net/~leo-editor-team/leo-editor/mod_rclick

You may wish to add --remember command line option to bzr push, to direct all
future pushes to that location. Then, you only need to execute ``bzr push``.

After your branch is pushed, you can email the Leo mailing list and request it
to be reviewed and merged to trunk.

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


From fperez.net at gmail.com  Tue Jun  3 14:31:58 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 11:31:58 -0700
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
Message-ID: <db6b5ecc0806031131xd71f77etdfc9c2b3f67b562d@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Here is a short guide to launchpad I wrote for Leo editor. It's
> applicable to ipython as well, when you substitute "ipython" for
> "leo-editor"

Great, could you please update this in the wiki page we have ?

http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines

It's important that this is in a permanent location besides the list
archives so newcomers find it right away.

Cheers,


f

> --------
>
> Many users will want to track the development version of Leo, in order to stay
> on top of the latest features and bugfixes. Running the development version is
> quite safe and easy, and it's also a requirement if you want to contribute to
> Leo.
>
> 1. First, you need to get Bazaar (bzr) from http://bazaar-vcs.org. For windows
>  users we recommend the standalone installer - the python installer may have
>  problems pushing to Launchpad. Plain bzr installer only contains the command
>  line version, so you might want to augment that with a friendly GUI - qbzr is
>  recommended as it's the easiest one to install. It provides command like
>  ``bzr qlog``, ``bzr qannotate`` etc.
>
> 2. Get Leo from launchpad by doing::
>
>   bzr branch lp:leo-editor
>
> And that's it! You can run leo/src/leo.py directly. When you want to refresh the
> code with latest modifications from Launchpad, run ``bzr pull``.
>
> If you make modifications to Leo (with the interest in sharing them with the Leo
> community), you can check them in to your local branch by doing ``bzr checkin``.
> Now, to actually request your changes to be merged to Leo trunk, you need a
> Launchpad account with RSA keys in place. There is showmedo video about how to
> accomplish this on Windows using puttygen and pageant at
> ``http://showmedo.com/videos/video?name=1510070&fromSeriesID=151``.
>
> After your Launchpad account is set up, go to
> ``https://launchpad.net/leo-editor``, choose Code tab -> Register Branch, select
> Branch type "Hosted" and fill in descriptive details about the branch. After
> that, go to the branch home page from Code tab again, and copy-paste the push
> command line to terminal. For example, for branch::
>
>  https://code.launchpad.net/~leo-editor-team/leo-editor/mod_rclick
>
> The push command is::
>
>  bzr push bzr+ssh://my_name at bazaar.launchpad.net/~leo-editor-team/leo-editor/mod_rclick
>
> You may wish to add --remember command line option to bzr push, to direct all
> future pushes to that location. Then, you only need to execute ``bzr push``.
>
> After your branch is pushed, you can email the Leo mailing list and request it
> to be reviewed and merged to trunk.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Jun  3 14:37:05 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 11:37:05 -0700
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
Message-ID: <db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Here is a short guide to launchpad I wrote for Leo editor. It's
> applicable to ipython as well, when you substitute "ipython" for
> "leo-editor"

One more thing: in here, the workflow you describe will lead to the
'history folding' problem we were having, no?  You don't indicate
keeping the dual-branch approach we'd discussed before and that I put
in the version of the guide I uploaded over the weekend.

The more I think about it, the more I think that no matter what we do,
the web history view will never be 100% correct: lp made the decision
to have a flat history view, and for a system that's fundamentally
based on branching, there will alyways be cases where the linear view
will fail to properly show the branch evolution and remerging.

But I do want to clarify (simply because *I* am not 100% sure what the
right solution is) if the dual-branch approach advocated earlier is
correct, necessary, useful, etc.

Cheers,

f


From ellisonbg.net at gmail.com  Tue Jun  3 14:45:02 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 3 Jun 2008 12:45:02 -0600
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
Message-ID: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>

Also, I have started a rst/Sphinx based developer's guidelines in
ipython1.  I based it on the wiki initially, but has more info on
certain fronts - especially on the stuff that is relevant to ipython1
merging with IPython.  When I do the merge of ipython1->IPython, I
will also merge the developer related things.

This brings up a bigger issue.  I would like _all_ of our docs to be
Sphinx based.  And in my mind, the developer guidelines fall under
this.  I don't like having to maintain multiple documentation sets
(wiki + Sphinx) and I think the Sphinx docs are a better place for all
of these things, including the developer related things.  We should
save the wiki for things like the cookbook and the basic web presence
for IPython.  How does this sound?

Brian



On Tue, Jun 3, 2008 at 12:37 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 3, 2008 at 11:01 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>> Here is a short guide to launchpad I wrote for Leo editor. It's
>> applicable to ipython as well, when you substitute "ipython" for
>> "leo-editor"
>
> One more thing: in here, the workflow you describe will lead to the
> 'history folding' problem we were having, no?  You don't indicate
> keeping the dual-branch approach we'd discussed before and that I put
> in the version of the guide I uploaded over the weekend.
>
> The more I think about it, the more I think that no matter what we do,
> the web history view will never be 100% correct: lp made the decision
> to have a flat history view, and for a system that's fundamentally
> based on branching, there will alyways be cases where the linear view
> will fail to properly show the branch evolution and remerging.
>
> But I do want to clarify (simply because *I* am not 100% sure what the
> right solution is) if the dual-branch approach advocated earlier is
> correct, necessary, useful, etc.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Tue Jun  3 14:50:42 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 3 Jun 2008 12:50:42 -0600
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
	<db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
	<cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
Message-ID: <6ce0ac130806031150o31b91c82hfa2911c4f91bf444@mail.gmail.com>

> I would encourage you guys to take a look at the
> ipython1.frontends.frontendbase class. My intention is to develop this
> into a base class for all GUI frontends. The underlying assumption is
> that GUI frontends will interact with the ipython interpreter via the
> ipython1.kernel.engineservice (Twisted) API. The benefits, as I see
> them for this approach is to avoid rewriting the Wheel of GUI
> Integration (the Twisted guys have already done this), and to make it
> _very_ easy to provide remote/parallel capabilities from within the
> GUI frontend.

+1

> Of course, code speaks louder than words and I invite you to hack on
> the frontends package (currently in ipython1-cocoa branch, but I
> assume soon to be merged inwards towards ipython1-dev or trunk). The
> frontendbase is currently a work in progress, but I've attempted to
> make it clear where subclasses (e.g. GUI frontend implementations
> should subclass particular methods to gain the desired functionality).
> The intention is that frontends are an aggregate of a frontendbase
> subclass and a GUI widget or a GUI widget (such as a text widget) that
> subclasses both the GUI toolkit's widget and the frontendbase.
>
> barry
>
>>
>> - correct integration with twisted's event loop.  There's a lot of
>> interest in the -twisted option working right, and twisted has GUI
>> integration mechanisms (as discussed here earlier); we just want the
>> whole thing to play nice with the networking layer used for
>> distributed use.  Note that the distributed use is not just for
>> parallel computing: you may also want a Qt/Wx gui working on a remote
>> ipython instance...
>
> If we stick with developing GUI interfaces through the engineservice
> interface, we get all this for free. In addition, I think such an
> approach will help drive the ipython1->ipython0 integration because it
> will highlight the most pressing areas where we the ipython1's core
> (exposed via engineservice) is not up-to-par wrt the ipython0
> InteractiveShell.
>
>>
>> - the needs for the same abstractions to work over the network from
>> frontends like a web browser that uses JavaScript.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Tue Jun  3 14:57:03 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 3 Jun 2008 12:57:03 -0600
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com>
References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>
	<4843ab8f.1358560a.46cd.ffffde15@mx.google.com>
	<db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>
	<48445a88.02a1660a.6b17.776d@mx.google.com>
	<46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com>
Message-ID: <6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com>

Another thing that we will have to move away from is having a Shell
that talks to the GUI/frontend through callbacks that the frontend
registers.  The reason is that the frontend could possibly be in a
completely different process, or even a web browser.  In that type of
setting, it is simply impossible for the Shell to call methods in the
frontend.  Furthermore, it is too tight of a coupling to have in a
distributed system - what happens if the frontend goes away but the
Shell persists.

Instead, all the methods of the Shell will have to return Python
objects (dicts, etcs) that contain the information that the frontend
can use for its own purposes.

Brian


On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
>
>> I mean we can stay with pyreadline for console based terminal but I think we
>> need something simpler for "graphical" gui.
>
> I agree. However, this can be done as it is now in iplib.py
> "interact_with_readline" method (which, admittedly, is not excercised
> in current code but mostly server as proof that ipython can be easily
> decoupled from raw_input.
>
>> (Another time, this is my point of view, some other devs will say that this
>> is the job of a readline object: I'm not ok with that because I want to be
>> free and I need something flexible. "Keep it simple" philosophy)
>
> I agree with you here. All the direct references to readline should
> factored out of the logic-running classes.
>
>> - Completer API.
>> Sometihng like:
>> IP.Completer.getCompletion(user_input_to_complete) -> return a list of
>> completion :
>> list([completion1,'function'],[completion2,'int'],[completion3,'private']
>> etc...
>
> This should be easy. test_completer.py introduces how to "hack" your
> way aroud the lack of API (so far).
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Tue Jun  3 15:16:49 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 22:16:49 +0300
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
Message-ID: <46cb515a0806031216i48797067uf0c6f53dc3bd75e6@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:37 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> One more thing: in here, the workflow you describe will lead to the
> 'history folding' problem we were having, no?  You don't indicate
> keeping the dual-branch approach we'd discussed before and that I put
> in the version of the guide I uploaded over the weekend.

That is correct. This is guide for people who do not have push access
to the trunk, but rather will create a small branch to be integrated
to the trunk. People pushing to the trunk have different
responsibilities. This is rather a guide to get started with
launchpad, not ipython workflow as such.

> But I do want to clarify (simply because *I* am not 100% sure what the
> right solution is) if the dual-branch approach advocated earlier is
> correct, necessary, useful, etc.

Yes, it is necessary and useful; though with a slight clarification:
the main idea in keeping safe is to prefer pull instead of merge.
Basically, you should not do merges to "remain up to date", pull is
for that. merge should be used to move your own changes to the trunk,
not to get other people's stuff as with "svn up" (unless you are sure
your change actually needs other people's modifications as well).

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


From vivainio at gmail.com  Tue Jun  3 15:17:36 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 22:17:36 +0300
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
	<6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
Message-ID: <46cb515a0806031217t6ddaf3c4y312be4dbe6311f76@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:45 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> Sphinx based.  And in my mind, the developer guidelines fall under
> this.  I don't like having to maintain multiple documentation sets
> (wiki + Sphinx) and I think the Sphinx docs are a better place for all
> of these things, including the developer related things.  We should
> save the wiki for things like the cookbook and the basic web presence
> for IPython.  How does this sound?

+1

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


From fperez.net at gmail.com  Tue Jun  3 15:21:07 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 12:21:07 -0700
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
	<6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
Message-ID: <db6b5ecc0806031221v47962f27w22d99043aab6eaad@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:45 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Also, I have started a rst/Sphinx based developer's guidelines in
> ipython1.  I based it on the wiki initially, but has more info on
> certain fronts - especially on the stuff that is relevant to ipython1
> merging with IPython.  When I do the merge of ipython1->IPython, I
> will also merge the developer related things.
>
> This brings up a bigger issue.  I would like _all_ of our docs to be
> Sphinx based.  And in my mind, the developer guidelines fall under
> this.  I don't like having to maintain multiple documentation sets
> (wiki + Sphinx) and I think the Sphinx docs are a better place for all
> of these things, including the developer related things.  We should
> save the wiki for things like the cookbook and the basic web presence
> for IPython.  How does this sound?

This has been very much in my mind, I just don't have the bandwidth to
deal with all of it simultaneously.  But I'm growing increasingly
annoyed at having docs in the wiki and in rst that are separate.  At
the same time, the wiki has the advantage of lowering the barrier to
external contributions in a way that rst docs don't quite achieve
(they still require source editing and a patch).

Ultimately the solution to this problem would be to have something
like what is being now used for the numpy docstrings:

http://sd-2116.dedibox.fr/pydocweb/wiki/Front Page/

but applied to ALL documentation.  This is the ideal solution in the
long run: everything in one place, casual users can contribute with a
zero-overhead web interface, and the system automatically generates
the changesets so that developers can apply them with minimal effort.

But integrating all that is more than we should tackle *right now*, I
think.  So I'm all for the following as a compromise solution:

1. Put our dev guidelines in rst
2. I write a cron job to update nightly docs from the bzr mainline.
3. We make certain key wiki pages simply link to the relevant point in
these auto-generated docs.

I think it would make a neat topic for a sprint at scipy'08 to work on
the full doc integration system...

Cheers,

f


From fperez.net at gmail.com  Tue Jun  3 15:22:10 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 12:22:10 -0700
Subject: [IPython-dev] Win32 IPython1?
In-Reply-To: <48457029.8020401@uml.edu>
References: <48457029.8020401@uml.edu>
Message-ID: <db6b5ecc0806031222x672c6524m64043723da45afa5@mail.gmail.com>

Hi Alex,

On Tue, Jun 3, 2008 at 9:24 AM, Alex Brown <Alexander_Brown at uml.edu> wrote:
> Hello - this may be the wrong list for this question;  if so my
> apologies.  My next Python excursion involves a simple "parallel
> programming" problem - I am trying to put together Python controller and
> server modules for very coarse-grain parallel processing of GIS and
> remote sensing data using existing Win32 GIS and remote sensing software
> tools running in WinXP on a classroom cluster.  The Win32 COM Python
> tools are fine for local control of these interactive applications and
> I'm trying to find an existing "parallel" network controller toolkit
> that will work in the Win32 world, either native or through Cygwin.
> (The controller environment can be Linux of course.)  I've tried some of
> the "grid" style tools for cluster management that claim to run in
> Cygwin, and found them to be clumsy (batch-oriented) and unreliable.  I
> am now looking into IPython1, and I'd like to know if there is any
> experience with it in a Win32 environment.
>
> Any suggestions would be welcome.
>

Yes, some people have used it in a win32 environment, though I haven't
myself.  We are very interested in feedback.

We should caution you that we are starting the process of merging all
the ip1 capabilities into 'regular' ipython.  So while for now the
ipython1 code will continue to exist, we hope that soon (in a few
weeks) the key components for distributed computing will be part of
the main trunk.  In the long run this will make it easier for you: you
simply upgrade ipython with each release (or follow the development
tree with bzr) and you're done.

This is just so you're aware that the location for some things is
changing, but we're convinced the change is for the best.

Regards,

f


From fperez.net at gmail.com  Tue Jun  3 15:59:09 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 12:59:09 -0700
Subject: [IPython-dev] Synchronization with gvim
In-Reply-To: <484553B1.9020405@vdesmedt.com>
References: <484553B1.9020405@vdesmedt.com>
Message-ID: <db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>

Hi Vivian,

On Tue, Jun 3, 2008 at 7:22 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:
> Dear All,
>
> Here is a version of the hook that should work for gvim (it suppose that
> gvim is in the path).

I imagine from your other post that you'll resend this as a patch
against current trunk, correct?  You mentioned you'd need to do it
from home to access launchpad, so I assume we'll wait for all the
editor-related patches to come from you.

Just checking so this doesn't get lost...

Thanks!

f


From jorgen.stenarson at bostream.nu  Tue Jun  3 16:04:47 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 03 Jun 2008 22:04:47 +0200
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
Message-ID: <4845A3DF.60504@bostream.nu>

Ville M. Vainio skrev:
> Here is a short guide to launchpad I wrote for Leo editor. It's
> applicable to ipython as well, when you substitute "ipython" for
> "leo-editor"

Hi,

nice intro. But do you know of any comprehensive guide to get 
bzr+launchpad working on windows. With instructions for authentication,
creating a project on launchpad and pushing the first content.

/J?rgen


From ellisonbg.net at gmail.com  Tue Jun  3 16:06:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 3 Jun 2008 14:06:12 -0600
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <db6b5ecc0806031221v47962f27w22d99043aab6eaad@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
	<6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
	<db6b5ecc0806031221v47962f27w22d99043aab6eaad@mail.gmail.com>
Message-ID: <6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:21 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 3, 2008 at 11:45 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Also, I have started a rst/Sphinx based developer's guidelines in
>> ipython1.  I based it on the wiki initially, but has more info on
>> certain fronts - especially on the stuff that is relevant to ipython1
>> merging with IPython.  When I do the merge of ipython1->IPython, I
>> will also merge the developer related things.
>>
>> This brings up a bigger issue.  I would like _all_ of our docs to be
>> Sphinx based.  And in my mind, the developer guidelines fall under
>> this.  I don't like having to maintain multiple documentation sets
>> (wiki + Sphinx) and I think the Sphinx docs are a better place for all
>> of these things, including the developer related things.  We should
>> save the wiki for things like the cookbook and the basic web presence
>> for IPython.  How does this sound?
>
> This has been very much in my mind, I just don't have the bandwidth to
> deal with all of it simultaneously.  But I'm growing increasingly
> annoyed at having docs in the wiki and in rst that are separate.  At
> the same time, the wiki has the advantage of lowering the barrier to
> external contributions in a way that rst docs don't quite achieve
> (they still require source editing and a patch).
>
> Ultimately the solution to this problem would be to have something
> like what is being now used for the numpy docstrings:
>
> http://sd-2116.dedibox.fr/pydocweb/wiki/Front Page/
>
> but applied to ALL documentation.  This is the ideal solution in the
> long run: everything in one place, casual users can contribute with a
> zero-overhead web interface, and the system automatically generates
> the changesets so that developers can apply them with minimal effort.

Except, I am not sure that having casual users contribute to the docs
without any review is a good idea.  In fact, with no review, there is
the possibility that wiki spam could make it into our docs in a major
release.  Also, even when you know rst+Sphinx it is easy to mess up
links, etc.  I would like to move gradually towards code review (but
not a formal process, I am thinking of people simply reviewing each
others branches before a merge) and a direct wiki->trunk connection is
a move in the opposite direction.  Here is what I have been thinking
of:

1) We (the ipython dev team) use the rst/Sphinx for any/all docs that
we are maintaining.

1) We encourage the usage of the wiki for unofficial, user contributed
docs, the cookbook, etc.

2) We encourage users to contribute official rst/Sphinx docs by
branching trunk, writing the docs and then requesting a review/merge.

> But integrating all that is more than we should tackle *right now*, I
> think.  So I'm all for the following as a compromise solution:
>
> 1. Put our dev guidelines in rst
> 2. I write a cron job to update nightly docs from the bzr mainline.
> 3. We make certain key wiki pages simply link to the relevant point in
> these auto-generated docs.

I think this sounds great.  I volunteer to get the docs
(IPython+ipython1) in shape if you can setup the cron job afterwards.

> I think it would make a neat topic for a sprint at scipy'08 to work on
> the full doc integration system...
>
> Cheers,
>
> f
>


From vivainio at gmail.com  Tue Jun  3 16:08:28 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 23:08:28 +0300
Subject: [IPython-dev] NameError: global name 'error' is not defined
In-Reply-To: <484558D6.8090700@slac.stanford.edu>
References: <484558D6.8090700@slac.stanford.edu>
Message-ID: <46cb515a0806031308q56a60bf7q2d350b4bfae7ba3a@mail.gmail.com>

On Tue, Jun 3, 2008 at 5:44 PM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:

> NameError: global name 'error' is not defined

Thanks for the report, fix committed!

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


From vivainio at gmail.com  Tue Jun  3 16:11:54 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 23:11:54 +0300
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <4845A3DF.60504@bostream.nu>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<4845A3DF.60504@bostream.nu>
Message-ID: <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:04 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:

> nice intro. But do you know of any comprehensive guide to get bzr+launchpad
> working on windows. With instructions for authentication,
> creating a project on launchpad and pushing the first content.

See that video linked to in my intro, it has just the stuff you are looking for.

I'll try to get pyreadline imported to launchpad, stay tuned.

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


From fperez.net at gmail.com  Tue Jun  3 16:17:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 13:17:40 -0700
Subject: [IPython-dev] Win32 IPython1?
In-Reply-To: <48459D9F.9020900@uml.edu>
References: <48457029.8020401@uml.edu>
	<db6b5ecc0806031222x672c6524m64043723da45afa5@mail.gmail.com>
	<48459D9F.9020900@uml.edu>
Message-ID: <db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>

On Tue, Jun 3, 2008 at 12:38 PM, Alex Brown <Alexander_Brown at uml.edu> wrote:
> Should I wait until your merge is complete?  I need to at least decide on an
> approach in the next week or two.

If you can tolerate *minor* code breakage, I'd suggest that you start
using ipython1 right away, as if the merge wasn't going to happen.
It's perfectly usable today, and all we're doing is moving its
functionality into the trunk.  So what you'll need to do when we
finish the move and *you* are ready (ip1 will remain available for you
to install/deploy) will be to change a few imports from

from ipython1.blah...

to

from IPython.blahh....

Your application code will remain the same otherwise.

HTH,

f


From fperez.net at gmail.com  Tue Jun  3 16:22:21 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 13:22:21 -0700
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<db6b5ecc0806031137h6c1ef070k9c48709cf9542c53@mail.gmail.com>
	<6ce0ac130806031145q70ad2e71m18eb6f543116b52e@mail.gmail.com>
	<db6b5ecc0806031221v47962f27w22d99043aab6eaad@mail.gmail.com>
	<6ce0ac130806031306y683c53cfs3470dfb0b6b77998@mail.gmail.com>
Message-ID: <db6b5ecc0806031322n1bcf6836q8ef0e03c1bb209a6@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:06 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> Except, I am not sure that having casual users contribute to the docs
> without any review is a good idea.  In fact, with no review, there is
> the possibility that wiki spam could make it into our docs in a major
> release.  Also, even when you know rst+Sphinx it is easy to mess up
> links, etc.  I would like to move gradually towards code review (but
> not a formal process, I am thinking of people simply reviewing each
> others branches before a merge) and a direct wiki->trunk connection is
> a move in the opposite direction.  Here is what I have been thinking
> of:

Ah, but that's the killer feature of the above system: the user
contributions do NOT go into the core without prior review.  The
Turbogears backend behind that site generates a patch per contribution
that goes into a private branch of numpy.  Periodically (I think
Stefan is doing it once or twice a week) those patches get applied or
discarded and the site re-synced.  There are tools on the site for
other editors to review, comment, etc.

So I honestly think that system gives us the best of both worlds:
trivial for users to contribute, impossible for junk to contaminate
the core.  The only problem is that the system isn't currently set up
to do the rst docs, only docstrings, and I'm too busy to talk to
Stefan, Pauli and Emanuelle about generalizing it a bit.  I think we
should focus on our code merge right now.  But a bit later in the
summer I think this is really worth looking into.

> I think this sounds great.  I volunteer to get the docs
> (IPython+ipython1) in shape if you can setup the cron job afterwards.

Will do.  Thanks for kicking in!

Cheers,

f


From Alexander_Brown at uml.edu  Tue Jun  3 16:19:58 2008
From: Alexander_Brown at uml.edu (Alex Brown)
Date: Tue, 03 Jun 2008 16:19:58 -0400
Subject: [IPython-dev] Win32 IPython1?
In-Reply-To: <db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>
References: <48457029.8020401@uml.edu>	
	<db6b5ecc0806031222x672c6524m64043723da45afa5@mail.gmail.com>	
	<48459D9F.9020900@uml.edu>
	<db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>
Message-ID: <4845A76E.4060307@uml.edu>

Sounds good - thanks.

Fernando Perez wrote:
> On Tue, Jun 3, 2008 at 12:38 PM, Alex Brown <Alexander_Brown at uml.edu> wrote:
>   
>> Should I wait until your merge is complete?  I need to at least decide on an
>> approach in the next week or two.
>>     
>
> If you can tolerate *minor* code breakage, I'd suggest that you start
> using ipython1 right away, as if the merge wasn't going to happen.
> It's perfectly usable today, and all we're doing is moving its
> functionality into the trunk.  So what you'll need to do when we
> finish the move and *you* are ready (ip1 will remain available for you
> to install/deploy) will be to change a few imports from
>
> from ipython1.blah...
>
> to
>
> from IPython.blahh....
>
> Your application code will remain the same otherwise.
>
> HTH,
>
> f
>
>   

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

From vivainio at gmail.com  Tue Jun  3 16:39:20 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 23:39:20 +0300
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
	<db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
	<cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
Message-ID: <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com>

On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark <barrywark at gmail.com> wrote:

> I would encourage you guys to take a look at the
> ipython1.frontends.frontendbase class. My intention is to develop this
> into a base class for all GUI frontends. The underlying assumption is

It doesn't seem to be too hard to shoehorn the frontendbase between
the gui and ipython; most of the work is really in implementation of
the actual gui drawing.

Though, at the moment frontendbase can't be directly imported in core
ipython due to twisted dependency. I suppose the only real twisted
dependency in that class could be removed by creating
"result_ready(r)" method and implementing execute_with_callback in
engine that does normal callback instead of returning a deferred...
obviously the engine can use deferred for actual implementation, for
the twisted version.

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


From vivainio at gmail.com  Tue Jun  3 16:53:10 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 3 Jun 2008 23:53:10 +0300
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<4845A3DF.60504@bostream.nu>
	<46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com>
Message-ID: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> I'll try to get pyreadline imported to launchpad, stay tuned.

Of course we are having the same problem as with ipython. See my import request:

https://answers.launchpad.net/launchpad-bazaar/+question/24416

I assume they can sort this out shortly.

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


From fperez.net at gmail.com  Tue Jun  3 17:00:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 14:00:28 -0700
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>
	<4845A3DF.60504@bostream.nu>
	<46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com>
	<46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com>
Message-ID: <db6b5ecc0806031400y5342a031l537bce113a69f7c1@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:53 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> I'll try to get pyreadline imported to launchpad, stay tuned.
>
> Of course we are having the same problem as with ipython. See my import request:
>
> https://answers.launchpad.net/launchpad-bazaar/+question/24416
>
> I assume they can sort this out shortly.

The scipy server was recently upgraded and now it's a lot more
responsive.  Even if it times out a little now, it should work
shortly.  Let me know if it doesn't and we can try to manually fetch a
repo dump.

f


From fperez.net at gmail.com  Tue Jun  3 18:57:56 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 15:57:56 -0700
Subject: [IPython-dev] automatic cpaste
In-Reply-To: <479FA443.8010406@csail.mit.edu>
References: <479FA443.8010406@csail.mit.edu>
Message-ID: <db6b5ecc0806031557w40daeab5had752621a39df129@mail.gmail.com>

Hi Ken,

2008/1/29 Ken Schutte <kschutte at csail.mit.edu>:
> Hello,
>
> I've been trying to figure out a way to make cpaste more "automatic".
>
> The closest I've come is the attached cpaste modification.  Using "cpaste
> -a" automatically executes the contents of the clipboard; however, it
> requires the 'xclip' command, which is run with os.popen3(). (btw, xclip is
> a nice command-line utility - I've found it's in most distro's repositories,
> but usually not installed by default).
>
> I'm not sure if you'd want to add this patch because of this dependency, but
> it should be backward compatible as is. (or is there a better way to get the
> clipbard contents?)
>
> This is maybe a slight improvement for me, but I'd love something where I
> can truly do a simple paste with the mouse and everything is done
> automatically.  I guess this is basically not possible within ipython?
>
> I usually use ipython within a Konsole window, so the only other thing I can
> think of is to figure out if you can easily do something there to make this
> happen, e.g. intercept a mouse paste, and instead paste in the text
> "cpaste\n"+$clipboard+"\n--\n".
>
> If anyone has any suggestions, please let me know.

Sorry for the long delay.  As you can see, we're now trying to
re-energize work around here :)

The problem with your patch is that it adds an X11 dependency onto
ipython's core, and that's just not OK.  We do have platform-specific
extensions and features, but not in the very core features, which
*must* remain portable.

However, if you can figure out a way to abstract out what's basically
a get_clipboard() functionality into something for which os-specific
backends can be written, this could certainly be done.  There may even
be already in the freedesktop.org an API for clipboard access that
works on reasonably modern linuxes, and I'm sure both OSX and Win32
have APIs for the same thing.

In the meantime, you can keep this as a local magic function in your
own environment, so you can freely upgrade ipython versions without
losing your changes.

regards,

f


From barrywark at gmail.com  Tue Jun  3 19:28:44 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 3 Jun 2008 16:28:44 -0700
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
	<db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
	<cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
	<46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com>
Message-ID: <cd7634ce0806031628t9fadb64l6f2e52d1363e4be@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:39 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark <barrywark at gmail.com> wrote:
>
>> I would encourage you guys to take a look at the
>> ipython1.frontends.frontendbase class. My intention is to develop this
>> into a base class for all GUI frontends. The underlying assumption is
>
> It doesn't seem to be too hard to shoehorn the frontendbase between
> the gui and ipython; most of the work is really in implementation of
> the actual gui drawing.

Correct.  This is the only way to make sure that a terminal frontend,
a graphical frontend like Mathematica's or a web-based frontend can
all fit into the same framework. This leads to the somewhat simplified
M(VC) picture where the FrontendBase acts as the model for an ipython
engine, and the front end implementation acts as a combined view and
controller in the MVC architecture.

>
> Though, at the moment frontendbase can't be directly imported in core
> ipython due to twisted dependency. I suppose the only real twisted
> dependency in that class could be removed by creating
> "result_ready(r)" method and implementing execute_with_callback in
> engine that does normal callback instead of returning a deferred...
> obviously the engine can use deferred for actual implementation, for
> the twisted version.

Because FrontendBase.__init__ takes an engine parameter, the terminal
frontend could use core instead of engineservice for its engine. The
only requirement then is to have a small amount of code (I think this
already exists somewhere in ipython1.core) for chaining callbacks to
the execution result (i.e. creating a pseudo-Deferred).


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


From barrywark at gmail.com  Tue Jun  3 19:43:16 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 3 Jun 2008 16:43:16 -0700
Subject: [IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR:
	Ipython plugin
In-Reply-To: <cd7634ce0806031628t9fadb64l6f2e52d1363e4be@mail.gmail.com>
References: <46cb515a0806021526t13c1db21m1897cbcaa2cbbdb4@mail.gmail.com>
	<db6b5ecc0806021656k27429541me855eb4e2529b532@mail.gmail.com>
	<cd7634ce0806022010m6790ffaes46a299988485e5a9@mail.gmail.com>
	<46cb515a0806031339s7508ddc9md8083a6f7b721a5f@mail.gmail.com>
	<cd7634ce0806031628t9fadb64l6f2e52d1363e4be@mail.gmail.com>
Message-ID: <cd7634ce0806031643h48221b56s9ad2878060c150f0@mail.gmail.com>

It's also worth mentioning by way of introduction what I'm working on
in ipython1.frontend.rendering. The idea is that things like
matplotlib/chaco plots, images, or other non-string results may want
to be displayed inline by a graphical frontend (like Mathematica's
notebook interface). Obviously, this rendering is going to be GUI
framework dependent, so I'm trying to make it easier for frontends to
create renderers for images, plots etc. and figure what renderer to
use for what result. So the rendering module provides a registry,
keyed by object type of renderers so a frontend can find the most
specific renderer for a result object. I'm not sure this is ultimately
worth it... we'll have to see how much utility it provides to
frontends.

Barry

On Tue, Jun 3, 2008 at 4:28 PM, Barry Wark <barrywark at gmail.com> wrote:
> On Tue, Jun 3, 2008 at 1:39 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>> On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark <barrywark at gmail.com> wrote:
>>
>>> I would encourage you guys to take a look at the
>>> ipython1.frontends.frontendbase class. My intention is to develop this
>>> into a base class for all GUI frontends. The underlying assumption is
>>
>> It doesn't seem to be too hard to shoehorn the frontendbase between
>> the gui and ipython; most of the work is really in implementation of
>> the actual gui drawing.
>
> Correct.  This is the only way to make sure that a terminal frontend,
> a graphical frontend like Mathematica's or a web-based frontend can
> all fit into the same framework. This leads to the somewhat simplified
> M(VC) picture where the FrontendBase acts as the model for an ipython
> engine, and the front end implementation acts as a combined view and
> controller in the MVC architecture.
>
>>
>> Though, at the moment frontendbase can't be directly imported in core
>> ipython due to twisted dependency. I suppose the only real twisted
>> dependency in that class could be removed by creating
>> "result_ready(r)" method and implementing execute_with_callback in
>> engine that does normal callback instead of returning a deferred...
>> obviously the engine can use deferred for actual implementation, for
>> the twisted version.
>
> Because FrontendBase.__init__ takes an engine parameter, the terminal
> frontend could use core instead of engineservice for its engine. The
> only requirement then is to have a small amount of code (I think this
> already exists somewhere in ipython1.core) for chaining callbacks to
> the execution result (i.e. creating a pseudo-Deferred).
>
>
>>
>> --
>> Ville M. Vainio - vivainio.googlepages.com
>> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
>>
>


From fperez.net at gmail.com  Tue Jun  3 19:47:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 16:47:28 -0700
Subject: [IPython-dev] Bzr merge idiosyncracies...
Message-ID: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>

Hi folks,

since I remain concerned about the issue of how bzr handles history
with multiple merges, and how launchpad displays it, I went looking
around in the bazaar mailing list.  From there I ran into this, that
happened to be written today:

http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html

(btw, that blog seems like it will be a handy reference on DVCS systems).

At least I wasn't totally crazy in feeling uncomfortable with the bzr
model.  I think we can live with it for now, and the benefits of all
the launchpad hosting infrastructure are too big for us to ignore, so
we'll just have to tweak our development practices to coexist somewhat
with bzr's personality quirks.

As we all find the pieces of what a good workflow should be, I hope
we'll all contribute it back.  Now that I'm trying to use the
two-branch approach to avoid messy history, I'm getting extremely
irritated.  I feel like I'm babysitting my VCS instead of it being a
tool at my service (way too many steps for normal operation, too many
things that need to be done in *just the right order* to avoid a mess,
etc).  I hope these are just growing pains and that we'll soon settle
into something reasonable, otherwise I might revert to basically
ignoring the launchpad history tool and having local trees be the only
way that we consider the history to be logged.

A bit grumpy...

f


From fperez.net at gmail.com  Tue Jun  3 21:03:46 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 18:03:46 -0700
Subject: [IPython-dev] Clearing exception info stored for %debug?
In-Reply-To: <200801181746.26728.hans_meine@gmx.net>
References: <200801181746.26728.hans_meine@gmx.net>
Message-ID: <db6b5ecc0806031803x95f3616w332ccb506368a937@mail.gmail.com>

Hi Hans,

2008/1/18 Hans Meine <hans_meine at gmx.net>:
> Hi!
>
> I just suffered from a complicated situation; I had a file being clobbered on
> IPython quit by a __del__ method from one of the objects in the stack within
> an exception that occurred earlier.  After the exception, I only ran one
> corrected command which stored the right file after a long computation, but
> when I quit IPython the data was overwritten by the partial results from the
> earlier, broken run.
>
> This situation is probably a rare one, but I thought that one might want to
> introduce "%clear exception" or sth. along that lines.

Could you be more specific on how such clearing would be implemented?
As far as I know, Python doesn't provide an official API for exception
clearing, but I could well be wrong.  sys holds certain special
objects:

In [2]: sys.last
sys.last_traceback  sys.last_type       sys.last_value

that only appear after an exception has occurred.  One could
concievably delete those straight from the sys module dict, but that
feels a bit harsh.  And in addition, references could be held
elsewhere, there's no easy way in python for finding all references
held to an object (or is there?).  So I'm not opposed in principle to
your idea, I'm just not quite sure how to go about it...

Regards,

f


From stefan at sun.ac.za  Tue Jun  3 21:29:35 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Jun 2008 03:29:35 +0200
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
Message-ID: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>

Hi Fernando

2008/6/4 Fernando Perez <fperez.net at gmail.com>:
> since I remain concerned about the issue of how bzr handles history
> with multiple merges, and how launchpad displays it, I went looking
> around in the bazaar mailing list.  From there I ran into this, that
> happened to be written today:
>
> http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html

Interesting post.  As far as I recall, "bzr merge --pull" also does
fast-forwarding.  I wonder if a person can set this to be the default
behaviour.

Ah, here's the article:

http://jameswestby.net/weblog/bzr/01-revision-numbers.html

Regards
St?fan


From fperez.net at gmail.com  Tue Jun  3 22:01:45 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 19:01:45 -0700
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
Message-ID: <db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>

On Tue, Jun 3, 2008 at 6:29 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Hi Fernando
>
> 2008/6/4 Fernando Perez <fperez.net at gmail.com>:
>> since I remain concerned about the issue of how bzr handles history
>> with multiple merges, and how launchpad displays it, I went looking
>> around in the bazaar mailing list.  From there I ran into this, that
>> happened to be written today:
>>
>> http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html
>
> Interesting post.  As far as I recall, "bzr merge --pull" also does
> fast-forwarding.  I wonder if a person can set this to be the default
> behaviour.
>
> Ah, here's the article:
>
> http://jameswestby.net/weblog/bzr/01-revision-numbers.html

Wow.  And here's the problem (next to last paragraph):

The indentation of the merged commits (and the fact they disappear
with "--short" and "--line") means that mentally they become of lesser
importance. You see "merged performance work from Emma's branch",
rather than all of the commits that you got from her. They are still
there to look at if you want, but they can be ignored at most times.
/quote

I can't believe that this is actually something that bazaar considers
a 'feature' and they promote as a valid design point.  The fact that
you've merged someone else's work into your branch because you happen
to be a maintainer, for example, doesn't make their work in any way
'second class'.  I agree 100% percent with Linus here (post linked to
in the vcscompare post):

http://www.gelato.unsw.edu.au/archives/git/0611/31361.html


Oh well.  For me, what really matters right now is that we get the
hosting infrastructure of launchpad.  I'm less and less enamored with
bzr, but that's irrelevant.  We have much bigger fish to fry than
getting into a bzr-vs-git/hg decision.  We stick with bzr, warts and
all.

All I want to do is to find a workflow that we can use with minimal
pain.  If that means accomodating bzr's design flaws, so be it.  My
problem is that I haven't found that workflow yet, and I'm finding
myself fighting the tool.

I await enlightenment...

f


From vivainio at gmail.com  Wed Jun  4 02:05:12 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 09:05:12 +0300
Subject: [IPython-dev] automatic cpaste
In-Reply-To: <479FA443.8010406@csail.mit.edu>
References: <479FA443.8010406@csail.mit.edu>
Message-ID: <46cb515a0806032305u67b6c5dfl23edbfca3e0945a8@mail.gmail.com>

2008/1/30 Ken Schutte <kschutte at csail.mit.edu>:

> I'm not sure if you'd want to add this patch because of this dependency, but
> it should be backward compatible as is. (or is there a better way to get the
> clipbard contents?)

This is not ok "directly", but will be with a bit of tweaking:

- Add "get_clipboard" to platutils.py and platutils_posix.py (it
should be easy), and an empty stub for windows.

- I will add the windows implementation later on.

> This is maybe a slight improvement for me, but I'd love something where I
> can truly do a simple paste with the mouse and everything is done
> automatically.  I guess this is basically not possible within ipython?

It's possible, but does a different thing.

cpaste executes standard python code that is pasted - pasting to
ipython prompt does ipython input translation, and may have problems
with empty lines.

> I usually use ipython within a Konsole window, so the only other thing I can
> think of is to figure out if you can easily do something there to make this
> happen, e.g. intercept a mouse paste, and instead paste in the text
> "cpaste\n"+$clipboard+"\n--\n".

This does sound like functionality that will have to reside in the GUI
frontends.

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


From vivainio at gmail.com  Wed Jun  4 02:55:56 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 09:55:56 +0300
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
	<db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
Message-ID: <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com>

On Wed, Jun 4, 2008 at 5:01 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> I can't believe that this is actually something that bazaar considers
> a 'feature' and they promote as a valid design point.  The fact that
> you've merged someone else's work into your branch because you happen
> to be a maintainer, for example, doesn't make their work in any way
> 'second class'.  I agree 100% percent with Linus here (post linked to
> in the vcscompare post):

This is something that works very well in practice, provided that the
branch work is of reasonable size - one feature, bugfix, etc. The idea
is that the log message is detailed enough to describe what was
merged. It should not be "merged stuff".

This liberates the commit policy in the branch, you can experiment and
play around a bit more when the end result will appear as single
well-contained commit.

In my last project the policy was "single commit per bugfix", using an
official commit template. It worked just fine, and you could easily
find what bugfix caused a problem, who did it, etc. You are not
interested it 10+ micro-commits that the original fixer did.

We should pick up a policy where we add the branch owners name as the
first thing in the log message, for people who don't have trunk
access.

As far as linux goes - the development hierarchy is multilayered,
which is not the case with us. There are no people who consolidate
small branches to big branches that are merged to trunk, but rather
the small branches are integrated directly to trunk.

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


From fperez.net at gmail.com  Wed Jun  4 03:02:56 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 00:02:56 -0700
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
	<db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
	<46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com>
Message-ID: <db6b5ecc0806040002s1c1a6d66j863696c2ac4e0744@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:55 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 5:01 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> I can't believe that this is actually something that bazaar considers
>> a 'feature' and they promote as a valid design point.  The fact that
>> you've merged someone else's work into your branch because you happen
>> to be a maintainer, for example, doesn't make their work in any way
>> 'second class'.  I agree 100% percent with Linus here (post linked to
>> in the vcscompare post):
>
> This is something that works very well in practice, provided that the
> branch work is of reasonable size - one feature, bugfix, etc. The idea
> is that the log message is detailed enough to describe what was
> merged. It should not be "merged stuff".
>
> This liberates the commit policy in the branch, you can experiment and
> play around a bit more when the end result will appear as single
> well-contained commit.
>
> In my last project the policy was "single commit per bugfix", using an
> official commit template. It worked just fine, and you could easily
> find what bugfix caused a problem, who did it, etc. You are not
> interested it 10+ micro-commits that the original fixer did.
>
> We should pick up a policy where we add the branch owners name as the
> first thing in the log message, for people who don't have trunk
> access.
>
> As far as linux goes - the development hierarchy is multilayered,
> which is not the case with us. There are no people who consolidate
> small branches to big branches that are merged to trunk, but rather
> the small branches are integrated directly to trunk.

It would be really good if you put some of these 'bzr good workflow
practices' in the wiki dev guidelines page.  Feel free to make it all
rst right away: that way when Brian integrates the docs, he can just
grab it from there.  Moin renders rest just fine, with a directive:

{{{
#rst
...
}}}

You have a *much* better sense for how to work with, rather than
against, bzr.  We'd all benefit from that insight before we mangle the
ipython tree into a crazy mess...

The single commit per bugfix is probably also a good policy because
I'm starting to get the feel that there's ONE file that is going to
give us grief: the linear ChangeLog.  That's the one file where
conflicts are likely to appear if we all edit it, so we might be
better off probably NOT using it anymore, and relying on the commit
logs instead.  But for that to be viable, the commit logs must be a
suitable replacement of the current Changelog, so they need to have an
entry per actual change, and must be more than one-liners.  Otherwise
there will be no easily human-readable log later anywhere.  Does that
sound right?

Cheers,


f


From fperez.net at gmail.com  Wed Jun  4 03:16:58 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 00:16:58 -0700
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <db6b5ecc0806040002s1c1a6d66j863696c2ac4e0744@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
	<db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
	<46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com>
	<db6b5ecc0806040002s1c1a6d66j863696c2ac4e0744@mail.gmail.com>
Message-ID: <db6b5ecc0806040016m31ece9dbl738961cdb4423fe8@mail.gmail.com>

On Wed, Jun 4, 2008 at 12:02 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> {{{
> #rst

Typo

{{{
#!rst



Cheers,

f


From fperez.net at gmail.com  Wed Jun  4 04:21:12 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 01:21:12 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
Message-ID: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>

Howdy,

I am now using the two-branch system we discussed earlier, but still
when I pull in the changes from trunk and push again, the problem of
'history folding' happens:

On Wed, Jun 4, 2008 at 1:11 AM,  <noreply at launchpad.net> wrote:
> ------------------------------------------------------------
> revno: 994
> committer: Fernando Perez <Fernando.Perez at berkeley.edu>
> branch nick: trunk-dev
> timestamp: Tue 2008-06-03 14:09:11 -0700
> message:
>  merge remote
> modified:
>  IPython/Extensions/pspersistence.py
>  IPython/gui/wx/ipshell_nonblocking.py
>  IPython/gui/wx/ipython_view.py
>  doc/ChangeLog
>  doc/ipython.1
>  doc/source/ipython.rst
>    ------------------------------------------------------------
>    revno: 991.1.4
>    committer: Ville M. Vainio <vivainio at gmail.com>
>    branch nick: ipython
>    timestamp: Tue 2008-06-03 23:05:35 +0300
>    message:
>      changelog: report UsageError on %store -w w/o arg,and other usage pattern errors. Bug report by Johann Cohen-Tanugi.
>    modified:
>      doc/ChangeLog
>    ------------------------------------------------------------
>    revno: 991.1.3
>    committer: Ville M. Vainio <vivainio at gmail.com>
>    branch nick: ipython
>    timestamp: Tue 2008-06-03 23:03:02 +0300
>    message:
>      pspersistence report UsageError's instead of crashing on 'error'
>    modified:
>      IPython/Extensions/pspersistence.py

etc..

In this case a sequence of commits from Ville got swallowed in by my
merge (I did use --pull which is supposed to 'fast forward') but no
luck.  Obviously next time anyone else commits it will be my changes
that get folded in, etc.  It seems the notion of  a 'shared mainline'
with multiple push persons is just not how bzr likes to work, or I'm
doing something very, very wrong with it...

Cheers,

f


From fperez.net at gmail.com  Wed Jun  4 04:22:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 01:22:33 -0700
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Main line of
	IPython development (stable)
In-Reply-To: <8612293437090592870@unknownmsgid>
References: <8612293437090592870@unknownmsgid>
Message-ID: <db6b5ecc0806040122g1ba9902eq44176047363b8b90@mail.gmail.com>

Aha!

On Wed, Jun 4, 2008 at 1:11 AM,  <noreply at launchpad.net> wrote:
> 4 revisions were removed from the branch.
>
>
> --
> Main line of IPython development (stable)
> https://code.launchpad.net/~ipython/ipython/trunk

This is what lp thinks: that we've 'removed' revisions, simply because
they were merged in my local copy.  But I *have* to merge them,
because I need to pull in the remote changes made from other
committers.

Confused...

f


From laurent.dufrechou at gmail.com  Wed Jun  4 04:28:06 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Wed, 4 Jun 2008 10:28:06 +0200
Subject: [IPython-dev] Help! TR: TR: Ipython plugin
In-Reply-To: <6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com>
References: <47ee21fb.05a0660a.4a91.3ff1@mx.google.com>	
	<db6b5ecc0806012319gdba5072ydcb206b12ab9a62f@mail.gmail.com>	
	<4843ab8f.1358560a.46cd.ffffde15@mx.google.com>	
	<db6b5ecc0806020117n1269023cle77f3054115e97bd@mail.gmail.com>	
	<48445a88.02a1660a.6b17.776d@mx.google.com>	
	<46cb515a0806021439h770661f7m5216f458b05773ac@mail.gmail.com>
	<6ce0ac130806031157t777c28c0wbb6ca0c981644e92@mail.gmail.com>
Message-ID: <48465218.0ab6660a.4758.7a00@mx.google.com>

For the callback, I see it difficult to avoid (but not impossible)

When i wrote wxIpython i fall in such a situation, whether to chose callback
approach or state machine approach.
Has you said, It should be better not to use callback.
This is what I did at first place.
The only problem was responsiveness because you will do some polling...
So the only methods I use currently for call back are:
	
    def _askExit(self):
        wx.CallAfter(self.ask_exit_callback, ())

    def _afterExecute(self):
        wx.CallAfter(self.parent.evtStateExecuteDone, ())

_askExit(self) is called when user type : "Exit()" <-- this callback can be
avoid
_afterExecute(self) is called for performance reason, to avoid polling of
the GUI.

So please keep in mind the _afterExecute problem :)

Another problem (THE hardest!)
If user do:

while (1):
	print "hello"

--> problems: display "hello" for each loop
--> support ctrl+c

I had to use a callback with multithread synchronization (ugghhh) to display
all the hello in my gui and be able to do a ctrl+c to break the loop.
This was the worst thing for me that condense all the problem with GUI.
If you can solve this with your approach without a big hack I'll be more
than happy!

The inter multithread 'synchro' could be avoid but would have implied
ipython core modification, that was not my objective...
(the multithread alone can't be avoid if you want to support ctrl+c)

I AM VERY VERY VERY interested in a ipython core + twisted with xml rpc +
GUI loop:
This will permit me to launch an ipython core + wx or qt or ??? in a
different process and be able to create graphical apps while the display gui
as its own GUI loop!
We must find a way to do this ;=) !!!!!!!!!!!!!!

Laurent




> -----Message d'origine-----
> De?: Brian Granger [mailto:ellisonbg.net at gmail.com]
> Envoy??: mardi 3 juin 2008 20:57
> ??: Ville M. Vainio
> Cc?: Laurent Dufrechou; Fernando Perez; ipython-dev Mailing list
> Objet?: Re: [IPython-dev] Help! TR: TR: Ipython plugin
> 
> Another thing that we will have to move away from is having a Shell
> that talks to the GUI/frontend through callbacks that the frontend
> registers.  The reason is that the frontend could possibly be in a
> completely different process, or even a web browser.  In that type of
> setting, it is simply impossible for the Shell to call methods in the
> frontend.  Furthermore, it is too tight of a coupling to have in a
> distributed system - what happens if the frontend goes away but the
> Shell persists.
> 
> Instead, all the methods of the Shell will have to return Python
> objects (dicts, etcs) that contain the information that the frontend
> can use for its own purposes.
> 
> Brian
> 
> 
> On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio <vivainio at gmail.com>
> wrote:
> > On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> > <laurent.dufrechou at gmail.com> wrote:
> >
> >> I mean we can stay with pyreadline for console based terminal but I
> think we
> >> need something simpler for "graphical" gui.
> >
> > I agree. However, this can be done as it is now in iplib.py
> > "interact_with_readline" method (which, admittedly, is not excercised
> > in current code but mostly server as proof that ipython can be easily
> > decoupled from raw_input.
> >
> >> (Another time, this is my point of view, some other devs will say
> that this
> >> is the job of a readline object: I'm not ok with that because I want
> to be
> >> free and I need something flexible. "Keep it simple" philosophy)
> >
> > I agree with you here. All the direct references to readline should
> > factored out of the logic-running classes.
> >
> >> - Completer API.
> >> Sometihng like:
> >> IP.Completer.getCompletion(user_input_to_complete) -> return a list
> of
> >> completion :
> >>
> list([completion1,'function'],[completion2,'int'],[completion3,'private
> ']
> >> etc...
> >
> > This should be easy. test_completer.py introduces how to "hack" your
> > way aroud the lack of API (so far).
> >
> > --
> > Ville M. Vainio - vivainio.googlepages.com
> > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >



From vivian at vdesmedt.com  Wed Jun  4 04:34:51 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Wed, 04 Jun 2008 10:34:51 +0200
Subject: [IPython-dev] Synchronization with gvim
In-Reply-To: <db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
References: <484553B1.9020405@vdesmedt.com>
	<db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
Message-ID: <484653AB.7060909@vdesmedt.com>

Hi Fernando,
> I imagine from your other post that you'll resend this as a patch 
> against current trunk, correct?
Yes, I'll try to create an account, create a branch and "checkin" my
change for revision.
Since I'm new with bzr it could take me some days before I'll finish
with that but I'll try to complete the task before the end of next week.

Thanks to Ville and its nice hint I guess it will be easy :-)

Regards,
Vivian.




From vivainio at gmail.com  Wed Jun  4 07:36:28 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 14:36:28 +0300
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
Message-ID: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>

On Wed, Jun 4, 2008 at 11:21 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> I am now using the two-branch system we discussed earlier, but still
> when I pull in the changes from trunk and push again, the problem of
> 'history folding' happens:

You are doing something wrong.

What you need to do is (iptrunk is your local trunk, ipfix is your
change branch):

cd /iptrunk
bzr pull
bzr merge ../ipfix
bzr ci
bzr push

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


From vivainio at gmail.com  Wed Jun  4 07:39:34 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 14:39:34 +0300
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Main line of
	IPython development (stable)
In-Reply-To: <db6b5ecc0806040122g1ba9902eq44176047363b8b90@mail.gmail.com>
References: <8612293437090592870@unknownmsgid>
	<db6b5ecc0806040122g1ba9902eq44176047363b8b90@mail.gmail.com>
Message-ID: <46cb515a0806040439i28e4e415rfc68f8e37ba7686f@mail.gmail.com>

On Wed, Jun 4, 2008 at 11:22 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> This is what lp thinks: that we've 'removed' revisions, simply because
> they were merged in my local copy.  But I *have* to merge them,
> because I need to pull in the remote changes made from other
> committers.

Actually, you don't need to merge changes from other developers in
your fix branch. "merge" is not "svn up". You should *pull* changes
from other developers (in your local trunk), *then* merge your changes
from your personal branch to the trunk.

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


From vivainio at gmail.com  Wed Jun  4 07:43:31 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 14:43:31 +0300
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <db6b5ecc0806040002s1c1a6d66j863696c2ac4e0744@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
	<db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
	<46cb515a0806032355i27c0d933hfa26b0e82bbdd9fc@mail.gmail.com>
	<db6b5ecc0806040002s1c1a6d66j863696c2ac4e0744@mail.gmail.com>
Message-ID: <46cb515a0806040443i438cd561p13b500740c93d3ae@mail.gmail.com>

On Wed, Jun 4, 2008 at 10:02 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> It would be really good if you put some of these 'bzr good workflow
> practices' in the wiki dev guidelines page.  Feel free to make it all

I'll try to do that soon, but I'm rather bogged ATM.

> The single commit per bugfix is probably also a good policy because
> I'm starting to get the feel that there's ONE file that is going to
> give us grief: the linear ChangeLog.  That's the one file where
> conflicts are likely to appear if we all edit it, so we might be
> better off probably NOT using it anymore, and relying on the commit
> logs instead.  But for that to be viable, the commit logs must be a
> suitable replacement of the current Changelog, so they need to have an
> entry per actual change, and must be more than one-liners.  Otherwise
> there will be no easily human-readable log later anywhere.  Does that
> sound right?

It worked well for us (we used perforce which had similar branch/merge
philosophy), let's try to follow it.

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


From darren.dale at cornell.edu  Wed Jun  4 09:12:17 2008
From: darren.dale at cornell.edu (Darren Dale)
Date: Wed, 4 Jun 2008 09:12:17 -0400
Subject: [IPython-dev] broken link on download page
Message-ID: <200806040912.17653.darren.dale@cornell.edu>

 The "this section" link in the windows section of the download page is 
broken, and the page is immutable so I can't fix it myself.

Darren

-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

darren.dale at cornell.edu
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu


From fperez.net at gmail.com  Wed Jun  4 10:53:14 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 07:53:14 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
Message-ID: <db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>

On Wed, Jun 4, 2008 at 4:36 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 11:21 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> I am now using the two-branch system we discussed earlier, but still
>> when I pull in the changes from trunk and push again, the problem of
>> 'history folding' happens:
>
> You are doing something wrong.
>
> What you need to do is (iptrunk is your local trunk, ipfix is your
> change branch):
>
> cd /iptrunk
> bzr pull
> bzr merge ../ipfix
> bzr ci
> bzr push

Ah, OK.  I got confused by the post that said that 'merge --pull' was
the way to 'fast forward' the history, and was using that.

What is the correct mechanism for getting the trunk changes that come
from other developer into ipfix?  Because at some point you still need
to make sure you get those as well, so that you stay in sync with
them.  Should you do the same as above but iptrunk<->ipfix?  Or can
you push from iptrunk like this?

cd /iptrunk
bzr pull # from lp/upstream
bzr push ../iptrunk

Is this correct?  That would be nice, in that it would cleanly (for my
mind) split the roles into:

1. cd /iptrunk: all things that involve communicating with launchpad,
including sending local changes from ipfix, retrieving upstream
changes and pushing them to ipfix

2. cd /ipfix: all things that involve committing local work but do not
touch the 'outside world'.

Thanks

f


From fperez.net at gmail.com  Wed Jun  4 11:03:37 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 08:03:37 -0700
Subject: [IPython-dev] broken link on download page
In-Reply-To: <200806040912.17653.darren.dale@cornell.edu>
References: <200806040912.17653.darren.dale@cornell.edu>
Message-ID: <db6b5ecc0806040803n9cf4c11t4f826bbce10d4871@mail.gmail.com>

On Wed, Jun 4, 2008 at 6:12 AM, Darren Dale <darren.dale at cornell.edu> wrote:
>  The "this section" link in the windows section of the download page is
> broken, and the page is immutable so I can't fix it myself.

Now you can, I added you to the editors group :)

Cheers,

f


From vivainio at gmail.com  Wed Jun  4 11:09:13 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 18:09:13 +0300
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
Message-ID: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>

On Wed, Jun 4, 2008 at 5:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> What is the correct mechanism for getting the trunk changes that come
> from other developer into ipfix?  Because at some point you still need
> to make sure you get those as well, so that you stay in sync with
> them.  Should you do the same as above but iptrunk<->ipfix?  Or can
> you push from iptrunk like this?
>
> cd /iptrunk
> bzr pull # from lp/upstream
> bzr push ../iptrunk

No, there is no point in doing both push and pull because both
operations make the repositories equal.

After pulling, you can just delete your ipfix branch and create a new
branch when you intend to do a change.

Let's assume that you start up by NOT having an ipfix branch. You
commit the changes directly to iptrunk branch, and attempt to push
them:

cd /iptrunk
hack hack hack
bzr ci
bzr push

BRANCHES HAVE DIVERGED error

Now, you need to get the changes from others, so you create the ipfix
branch and get a pristine, most recent version of trunk:

cd /
mv iptrunk ipfix
bzr branch lp:ipython iptrunk
cd iptrunk
bzr merge ../ipfix
bzr ci
bzr push   <== now, this will succeed.

The important thing is to minimize the amount of merging, and
generally not merge stuff from others - just merge stuff to trunk, not
the other way around. Of course you *can* merge stuff from others if
you need to, but don't make it a habit "just to be sure".

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


From fperez.net at gmail.com  Wed Jun  4 11:13:14 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 08:13:14 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
Message-ID: <db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>

On Wed, Jun 4, 2008 at 8:09 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 5:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> What is the correct mechanism for getting the trunk changes that come
>> from other developer into ipfix?  Because at some point you still need
>> to make sure you get those as well, so that you stay in sync with
>> them.  Should you do the same as above but iptrunk<->ipfix?  Or can
>> you push from iptrunk like this?
>>
>> cd /iptrunk
>> bzr pull # from lp/upstream
>> bzr push ../iptrunk
>
> No, there is no point in doing both push and pull because both
> operations make the repositories equal.
>
> After pulling, you can just delete your ipfix branch and create a new
> branch when you intend to do a change.

Mmh, what if you have stuff in your local copy that you're playing
with still but not quite ready to commit?  I'm not sure I like the
idea that the local branch must be immediately gone after each commit.
 It seems to me that the iptrunk branch should be pretty 'pure' from
local work, but I do want a more long-lived area for local work.  Or
is this just 'going against the grain' of bzr workflow?


Cheers,

f


From ellisonbg.net at gmail.com  Wed Jun  4 11:22:56 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 4 Jun 2008 09:22:56 -0600
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
Message-ID: <6ce0ac130806040822h381cc4berf86c6fbd75de2831@mail.gmail.com>

> Mmh, what if you have stuff in your local copy that you're playing
> with still but not quite ready to commit?  I'm not sure I like the
> idea that the local branch must be immediately gone after each commit.
>  It seems to me that the iptrunk branch should be pretty 'pure' from
> local work, but I do want a more long-lived area for local work.  Or
> is this just 'going against the grain' of bzr workflow?

I hope not because that is (in my mind) one of the main reasons to use
a distributed vcs.

Brian

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


From vivainio at gmail.com  Wed Jun  4 11:25:00 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 18:25:00 +0300
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
Message-ID: <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>

On Wed, Jun 4, 2008 at 6:13 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Mmh, what if you have stuff in your local copy that you're playing
> with still but not quite ready to commit?  I'm not sure I like the
> idea that the local branch must be immediately gone after each commit.
>  It seems to me that the iptrunk branch should be pretty 'pure' from
> local work, but I do want a more long-lived area for local work.  Or
> is this just 'going against the grain' of bzr workflow?

For long-lived work you should have a separate "feature branch", e.g.
"twisted-exp". Not "fernandos-stuff" where you routinely do all the
local stuff and keep merging to it all the time.

It's quite ok to merge stuff to your feature branches if it's a
long-term undertaking, but for short lived fixes it's an unnecessary
complication and should not be done "just to see if your stuff works
with the new stuff". To test your branch against the latest codes, run
the tests in trunk after "bzr merge ../ipfix", before commit.

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


From fperez.net at gmail.com  Wed Jun  4 11:38:08 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 08:38:08 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
Message-ID: <db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>

On Wed, Jun 4, 2008 at 8:25 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 6:13 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> Mmh, what if you have stuff in your local copy that you're playing
>> with still but not quite ready to commit?  I'm not sure I like the
>> idea that the local branch must be immediately gone after each commit.
>>  It seems to me that the iptrunk branch should be pretty 'pure' from
>> local work, but I do want a more long-lived area for local work.  Or
>> is this just 'going against the grain' of bzr workflow?
>
> For long-lived work you should have a separate "feature branch", e.g.
> "twisted-exp". Not "fernandos-stuff" where you routinely do all the
> local stuff and keep merging to it all the time.
>
> It's quite ok to merge stuff to your feature branches if it's a
> long-term undertaking, but for short lived fixes it's an unnecessary
> complication and should not be done "just to see if your stuff works
> with the new stuff". To test your branch against the latest codes, run
> the tests in trunk after "bzr merge ../ipfix", before commit.

But then how are those 'long lived' feature branches different?  If we
do merge into them, we're back to the history folding problem, no?  If
we don't merge into them, they diverge...

Basically (as Brian said) a basic feature of DVCS seems to be
precisely the ability to keep long (or short)-lived lines of work that
track the trunk and where experimental work happens, merging
nilly-willy the pieces that make sense and without having to worry
about the history.  Having to make a distinction between long and
short lived branches in terms of workflow for this point sounds weird.

I'm not saying there's no use for one-off branches, they're fine on
their own.  But I don't want to be constrained to that being the only
way to merge into trunk, that does feel unduly limiting...

cheers,

f


From vivainio at gmail.com  Wed Jun  4 11:44:04 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 18:44:04 +0300
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
Message-ID: <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>

On Wed, Jun 4, 2008 at 6:38 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> But then how are those 'long lived' feature branches different?  If we
> do merge into them, we're back to the history folding problem, no?  If
> we don't merge into them, they diverge...

There is no history folding problem if you merge to trunk, then push
trunk (as opposed to merging to your feature branch and then pushing
it over the trunk).

> about the history.  Having to make a distinction between long and
> short lived branches in terms of workflow for this point sounds weird.

The point is that you should not merge "by habit", as in "I must
always merge to myself before I publish changes". It only complicates
the history, without helping anybody... and is just a habit acquired
by having to do "svn up" before checkin.

> their own.  But I don't want to be constrained to that being the only
> way to merge into trunk, that does feel unduly limiting...

Yes, of course if you think you want/need to do it, by all means do
it. It's just good to know you don't have to do it because "it's a
good process" or anything like that.

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


From vivainio at gmail.com  Wed Jun  4 11:55:00 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 4 Jun 2008 18:55:00 +0300
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
Message-ID: <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>

On Wed, Jun 4, 2008 at 6:44 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> There is no history folding problem if you merge to trunk, then push
> trunk (as opposed to merging to your feature branch and then pushing
> it over the trunk).

Just to emphasize this: you might use the golden rule that unless you
pulled a non-private branch less than one hour ago, do not push that
branch. This avoids nuking valuable history entries with "merged from
trunk" entries.

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


From fperez.net at gmail.com  Wed Jun  4 12:46:15 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 09:46:15 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
	<46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
Message-ID: <db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>

On Wed, Jun 4, 2008 at 8:55 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 6:44 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> There is no history folding problem if you merge to trunk, then push
>> trunk (as opposed to merging to your feature branch and then pushing
>> it over the trunk).
>
> Just to emphasize this: you might use the golden rule that unless you
> pulled a non-private branch less than one hour ago, do not push that
> branch. This avoids nuking valuable history entries with "merged from
> trunk" entries.

OK, thanks for all the feedback on bzr.  I'll try to make a little
cheat sheet from this discussion and see how it goes.  Ultimately we
might send that info back to the bzr team for their docs.  I feel
their 'Workflows' pages and sections of the guide are woefully
insufficient in critical details (like a number of things you've
clarified here).

Cheers,

f


From stefan at sun.ac.za  Wed Jun  4 15:44:37 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Jun 2008 21:44:37 +0200
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
	<46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
	<db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>
Message-ID: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>

2008/6/4 Fernando Perez <fperez.net at gmail.com>:
> OK, thanks for all the feedback on bzr.  I'll try to make a little
> cheat sheet from this discussion and see how it goes.  Ultimately we
> might send that info back to the bzr team for their docs.  I feel
> their 'Workflows' pages and sections of the guide are woefully
> insufficient in critical details (like a number of things you've
> clarified here).

I like bzr a lot, but it scares me that we need a cheat sheet to
achieve something so simple.  Please do provide this feedback to the
bzr list or #bzr on freenode.net; I would very much like to know what
they have to say.

Cheers
St?fan


From ellisonbg.net at gmail.com  Wed Jun  4 16:04:31 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 4 Jun 2008 14:04:31 -0600
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
	<46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
	<db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>
	<9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>
Message-ID: <6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com>

So....

I have a branch of ipython1-dev (ipython1-fc) that I want to merge
back into ipython1-dev.  Previously, I had been doing a simple push
from my local ipython1-fc to ipython1-dev.  But, what is the best way
(after all this discussion) of doing the merge that will get the
history right?

Brian

On Wed, Jun 4, 2008 at 1:44 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/6/4 Fernando Perez <fperez.net at gmail.com>:
>> OK, thanks for all the feedback on bzr.  I'll try to make a little
>> cheat sheet from this discussion and see how it goes.  Ultimately we
>> might send that info back to the bzr team for their docs.  I feel
>> their 'Workflows' pages and sections of the guide are woefully
>> insufficient in critical details (like a number of things you've
>> clarified here).
>
> I like bzr a lot, but it scares me that we need a cheat sheet to
> achieve something so simple.  Please do provide this feedback to the
> bzr list or #bzr on freenode.net; I would very much like to know what
> they have to say.
>
> Cheers
> St?fan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From barrywark at gmail.com  Wed Jun  4 16:43:22 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 4 Jun 2008 13:43:22 -0700
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <db6b5ecc0805311917y4f908bdnd515900e30f1ae84@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
	<6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
	<cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
	<6ce0ac130805280754m51475f8ai39dec8e145fd385c@mail.gmail.com>
	<db6b5ecc0805311917y4f908bdnd515900e30f1ae84@mail.gmail.com>
Message-ID: <cd7634ce0806041343o34cd3d6cl6687b4876e75bdd6@mail.gmail.com>

On Sat, May 31, 2008 at 7:17 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, May 28, 2008 at 7:54 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>
>> I don't think there is anyway of monitoring the user's namespace for
>> changes.  But, I can think of a couple different approaches that might
>> work:
>
>
> Actually there is, to some extent.  The execution user_ns can be a
> dict-like object whose methods fire notifications onto listeners.  One
> can't detect *all* changes (such as in-place modifications of deeply
> nested mutable objects), but at least one can detect all variable
> reads (__getitem__), new variables (__setitem__) and deletions
> (__del__).

That's exactly what I was thinking. I know it's not perfect, but as a
hint to the frontend, would be very useful.

>
> Just a side note...
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Wed Jun  4 16:53:49 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 4 Jun 2008 13:53:49 -0700
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
	<46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
	<db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>
	<9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>
Message-ID: <db6b5ecc0806041353i24e10d09uef0d11505625edcc@mail.gmail.com>

On Wed, Jun 4, 2008 at 12:44 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/6/4 Fernando Perez <fperez.net at gmail.com>:
>> OK, thanks for all the feedback on bzr.  I'll try to make a little
>> cheat sheet from this discussion and see how it goes.  Ultimately we
>> might send that info back to the bzr team for their docs.  I feel
>> their 'Workflows' pages and sections of the guide are woefully
>> insufficient in critical details (like a number of things you've
>> clarified here).
>
> I like bzr a lot, but it scares me that we need a cheat sheet to
> achieve something so simple.  Please do provide this feedback to the
> bzr list or #bzr on freenode.net; I would very much like to know what
> they have to say.

I've now gone under in swamp mode, but it does worry me too.  Thanks
for your offer to look into this further!

Cheers,

f


From cournapeau at cslab.kecl.ntt.co.jp  Wed Jun  4 22:45:33 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 05 Jun 2008 11:45:33 +0900
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<46cb515a0806040436l4a2f1143va2b7e0867c0d6a2c@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
Message-ID: <1212633933.13915.32.camel@bbc8>

On Wed, 2008-06-04 at 07:53 -0700, Fernando Perez wrote:

> 
> Ah, OK.  I got confused by the post that said that 'merge --pull' was
> the way to 'fast forward' the history, and was using that.

You should avoid using this with bzr. I think using it comes from people
used to git, and it does not work well with bzr (it leads to those
problems you are having with history "folding"). You may like the git's
way better, but forcing bzr in git mode is bad. It is like using vim
mode in emacs. Possible, but weird.

About pull vs merge:

https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html

This is important to understand well to avoid the problem you got, I
think. I find the article you posted typical of someone used to git and
do not understand why bzr is different. FWIW, you can get git's log with
the --short/--line option (as mentioned above, bzr --short --forward is
nice, it is the default on my computer too).

About bzr vs other tools, I think it is easy to see problems when using
one program, and not seeing the ones brought by another, not used yet,
one. Using git effectively wrt history is not trivial either, there
would have been the same kind of discussion I believe (on different
points, obviously: but rebase is not so easy to understand either). I
really believe bzr has its advantages here (as well as its problems too,
obviously).

Hope the above helps,

David



From cournapeau at cslab.kecl.ntt.co.jp  Wed Jun  4 22:59:38 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 05 Jun 2008 11:59:38 +0900
Subject: [IPython-dev] bzr - what am I doing wrong?
In-Reply-To: <6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com>
References: <db6b5ecc0806040121p1d1fb657w2279b732e97aa705@mail.gmail.com>
	<db6b5ecc0806040753h4fc683a8pf8ec62f8a953c504@mail.gmail.com>
	<46cb515a0806040809q2862bdd1mb6464b82be6a7d7@mail.gmail.com>
	<db6b5ecc0806040813lee94db3x84c4643259529d70@mail.gmail.com>
	<46cb515a0806040825u2477886x6f663004c218a310@mail.gmail.com>
	<db6b5ecc0806040838x24c639b2w80c83989ab56a1aa@mail.gmail.com>
	<46cb515a0806040844j7461a7bbi4b594687cabab71f@mail.gmail.com>
	<46cb515a0806040855x4e2742adr41225db7ce684bb6@mail.gmail.com>
	<db6b5ecc0806040946g51cf2481x1c5d6fc9fc83b845@mail.gmail.com>
	<9457e7c80806041244i7dc0cb90h109c10ff782ab6a1@mail.gmail.com>
	<6ce0ac130806041304p199e1eb6kf1a91f9129186f3c@mail.gmail.com>
Message-ID: <1212634779.13915.42.camel@bbc8>

On Wed, 2008-06-04 at 14:04 -0600, Brian Granger wrote:
> So....
> 
> I have a branch of ipython1-dev (ipython1-fc) that I want to merge
> back into ipython1-dev.  Previously, I had been doing a simple push
> from my local ipython1-fc to ipython1-dev.  But, what is the best way
> (after all this discussion) of doing the merge that will get the
> history right?

The easy way I think it to always keep a mirror of the branch you intend
to commit to (ipython1-dev here):

bzr branch lp:ipython1-dev
bzr branch ipython1-dev mybranch
# Hack into mybranch

When you feel like publishing your changes:

cd ipython-dev
bzr pull (to be up-to-date)
bzr merge ../mybranch
bzr ci -m "Summary of the merged branch work"

Then, you avoid this folding issue I believe: you keep the mainline as a
reference, and do your work in another branch.

David



From cournapeau at cslab.kecl.ntt.co.jp  Thu Jun  5 01:27:48 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 05 Jun 2008 14:27:48 +0900
Subject: [IPython-dev] Bzr merge idiosyncracies...
In-Reply-To: <db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
References: <db6b5ecc0806031647t6a63c13aj47970e88e0296028@mail.gmail.com>
	<9457e7c80806031829r361dfe7ax76e6c6cceb2b680d@mail.gmail.com>
	<db6b5ecc0806031901q61cd6d29j6647cb6ec1825919@mail.gmail.com>
Message-ID: <1212643668.13915.53.camel@bbc8>

On Tue, 2008-06-03 at 19:01 -0700, Fernando Perez wrote:
> 
> I can't believe that this is actually something that bazaar considers
> a 'feature' and they promote as a valid design point.  The fact that
> you've merged someone else's work into your branch because you happen
> to be a maintainer, for example, doesn't make their work in any way
> 'second class'.  I agree 100% percent with Linus here (post linked to
> in the vcscompare post):
> 
> http://www.gelato.unsw.edu.au/archives/git/0611/31361.html
> 
> 

To see a good explanation why it is a design feature of bzr, you can
follow this discussion:

https://lists.ubuntu.com/archives/bazaar/2008q1/039144.html

Again, both POV are definitely valid, and have their strong
points/weaknesses. But bzr's workflow here has *some* advantages, and
the above definitely *is* a feature. I am not saying it is important for
ipython, I don't know honestly; if people run things from "trunk", it
may be. I can definitely see this as a good feature in numpy, where many
people do build from trunk I believe.

> 
> I await enlightenment...
> 

I hope it explains why bzr is the way it is at least. Maybe it was not
the best choice for ipython, I honestly don't know; git speed and
toolbox design is really nice for a unix-inclined guy like me. But the
point is that any DVCS is really much better than svn. I can't wait to
ditch svn for other projects linked to ipython :)

cheers,

David



From jorgen.stenarson at bostream.nu  Thu Jun  5 15:37:21 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 05 Jun 2008 21:37:21 +0200
Subject: [IPython-dev] Quick launchpad guide for would-be contributors
In-Reply-To: <46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com>
References: <46cb515a0806031101p541c947q74d829b986b115b4@mail.gmail.com>	
	<4845A3DF.60504@bostream.nu>	
	<46cb515a0806031311i5c4dec40l4f0decbad137eb06@mail.gmail.com>
	<46cb515a0806031353t6c519ea2o13e5904a77e65a2d@mail.gmail.com>
Message-ID: <48484071.6060407@bostream.nu>

Ville M. Vainio skrev:
> On Tue, Jun 3, 2008 at 11:11 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> 
>> I'll try to get pyreadline imported to launchpad, stay tuned.
> 
> Of course we are having the same problem as with ipython. See my import request:
> 
> https://answers.launchpad.net/launchpad-bazaar/+question/24416
> 
> I assume they can sort this out shortly.
> 
nothing has happend yet. Looks like another try is scheduled for tomorrow.

With the showmedo-guide you linked and some googling I got it to work. I 
have been able to get pyreadline from svn to my computer. But I have 
been unable to merge to a branch from launchpad.

I'm off to a conference for a week now. Will be back June 16. Hopefully 
launchpad has been able to import by then.

/J?rgen

C:\python\launchpad\pyreadline-trunk>bzr merge ../pyreadline-svnrepo/trunk
bzr: ERROR: Repository 
KnitPackRepository('file:///C:/python/launchpad/pyreadlin
e-trunk/.bzr/repository/') is not compatible with repository 
KnitPackRepository(
'file:///C:/python/launchpad/pyreadline-svnrepo/.bzr/repository/')

C:\python\launchpad\pyreadline-trunk>bzr info
Standalone tree (format: pack-0.92)
Location:
   branch root: .

Related branches:
   submit branch: C:/python/launchpad/pyreadline-svnrepo/trunk



From jdh2358 at gmail.com  Thu Jun  5 18:30:03 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Thu, 5 Jun 2008 17:30:03 -0500
Subject: [IPython-dev] cd a little hyper
Message-ID: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>

To due a readline bug on solaris, cd ~/somedTAB used to insert extra
white space after completing directories, which was a major headache
when navigating deeply nested directories since I had to backspace
after every directory completion.   Using the latest ipython rom bzr,
this appears to be fixed.  I don't know how it was fixed, but it is
great.  (thanks).

But I notice a new buglet.  If I am cd-ing into a dir which has a
bunch of files and one other dir, cd will take me one level too deep.
Eg,  I want to cd into "api"::

  In [18]: !ls -laF /home/titan/johnh/mpl/examples/api/
  total 144
  drwx------   3 johnh    research    1024 Jun  5 17:21 ./
  drwxr-----  13 johnh    research   16896 Jun  3 15:55 ../
  drwx------   6 johnh    research     512 Jun  5 17:23 .svn/
  -rw-------   1 johnh    research    1780 Jun  3 15:54 README.txt
  -rw-------   1 johnh    research     400 Jun  3 15:54 agg_oo.py
  ..snipsnip (lots more plain files but .svn is the only subdir)

Now when I do::

  In [19]: cd /home/titan/johnh/mpl/examples/ap<TAB>

I get the following completion::

  In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/

Ie, it puts me one directory too deep.

Any ideas?
JDH
In [19]: import IPython

In [20]: IPython.__version__
Out[20]: '0.8.4'

In [21]: !uname -a
SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc


From fperez.net at gmail.com  Thu Jun  5 19:54:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 5 Jun 2008 16:54:55 -0700
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
Message-ID: <db6b5ecc0806051654p32bfcecfoedafd98a703d877f@mail.gmail.com>

On Thu, Jun 5, 2008 at 3:30 PM, John Hunter <jdh2358 at gmail.com> wrote:
> To due a readline bug on solaris, cd ~/somedTAB used to insert extra
> white space after completing directories, which was a major headache
> when navigating deeply nested directories since I had to backspace
> after every directory completion.   Using the latest ipython rom bzr,
> this appears to be fixed.  I don't know how it was fixed, but it is
> great.  (thanks).
>
> But I notice a new buglet.  If I am cd-ing into a dir which has a
> bunch of files and one other dir, cd will take me one level too deep.
> Eg,  I want to cd into "api"::
>
>  In [18]: !ls -laF /home/titan/johnh/mpl/examples/api/
>  total 144
>  drwx------   3 johnh    research    1024 Jun  5 17:21 ./
>  drwxr-----  13 johnh    research   16896 Jun  3 15:55 ../
>  drwx------   6 johnh    research     512 Jun  5 17:23 .svn/
>  -rw-------   1 johnh    research    1780 Jun  3 15:54 README.txt
>  -rw-------   1 johnh    research     400 Jun  3 15:54 agg_oo.py
>  ..snipsnip (lots more plain files but .svn is the only subdir)
>
> Now when I do::
>
>  In [19]: cd /home/titan/johnh/mpl/examples/ap<TAB>
>
> I get the following completion::
>
>  In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/
>
> Ie, it puts me one directory too deep.
>
> Any ideas?
> JDH
> In [19]: import IPython
>
> In [20]: IPython.__version__
> Out[20]: '0.8.4'
>
> In [21]: !uname -a
> SunOS flag 5.10 Generic_118855-15 i86pc i386 i86pc

Mhh, I don't see that here.  Could you let me know if you see this on BIC?

Cheers,


f


From jdh2358 at gmail.com  Thu Jun  5 22:03:36 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Thu, 5 Jun 2008 21:03:36 -0500
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <db6b5ecc0806051654p32bfcecfoedafd98a703d877f@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<db6b5ecc0806051654p32bfcecfoedafd98a703d877f@mail.gmail.com>
Message-ID: <88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com>

On Thu, Jun 5, 2008 at 6:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:

>>  In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/
> Mhh, I don't see that here.  Could you let me know if you see this on BIC?

Nope,  in the same dir on bic I don't see it.  The .svn subdir doesn't
show up at all in the completion list, as it shouldn't.  Maybe they
"upgraded" readline at work or something, hard to say.  But the
current behavior is still loads better than the old and is not worth
expending any effort trying to resolve.  i thought maybe it was an
ipython change.

JDH


From fperez.net at gmail.com  Thu Jun  5 23:00:18 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 5 Jun 2008 20:00:18 -0700
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<db6b5ecc0806051654p32bfcecfoedafd98a703d877f@mail.gmail.com>
	<88e473830806051903i2095c405y77871e79431b32c0@mail.gmail.com>
Message-ID: <db6b5ecc0806052000i346b21ecw77f71c6ebd70e178@mail.gmail.com>

On Thu, Jun 5, 2008 at 7:03 PM, John Hunter <jdh2358 at gmail.com> wrote:
> On Thu, Jun 5, 2008 at 6:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>>>  In [19]: cd /home/titan/johnh/mpl/examples/api/.svn/
>> Mhh, I don't see that here.  Could you let me know if you see this on BIC?
>
> Nope,  in the same dir on bic I don't see it.  The .svn subdir doesn't
> show up at all in the completion list, as it shouldn't.  Maybe they
> "upgraded" readline at work or something, hard to say.  But the
> current behavior is still loads better than the old and is not worth
> expending any effort trying to resolve.  i thought maybe it was an
> ipython change.

None that I can think of.   If it drives you nuts we can look into it further.

Cheers,

f


From vivainio at gmail.com  Fri Jun  6 00:41:48 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 6 Jun 2008 07:41:48 +0300
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
Message-ID: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>

On Fri, Jun 6, 2008 at 1:30 AM, John Hunter <jdh2358 at gmail.com> wrote:

> To due a readline bug on solaris, cd ~/somedTAB used to insert extra
> white space after completing directories, which was a major headache
> when navigating deeply nested directories since I had to backspace
> after every directory completion.   Using the latest ipython rom bzr,
> this appears to be fixed.  I don't know how it was fixed, but it is
> great.  (thanks).

Yes, I fixed that by introducing the pseudo-annoying behaviour you
mention (I noticed the same thing on linux + scratchbox). It's the
single_dir_expand call in ipy_completers.py (cd completer)

Perhaps we should "special case" the .svn / dot-something thing.

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


From jdh2358 at gmail.com  Fri Jun  6 01:05:05 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Fri, 6 Jun 2008 00:05:05 -0500
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
Message-ID: <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com>

On Thu, Jun 5, 2008 at 11:41 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, Jun 6, 2008 at 1:30 AM, John Hunter <jdh2358 at gmail.com> wrote:
>
>> To due a readline bug on solaris, cd ~/somedTAB used to insert extra
>> white space after completing directories, which was a major headache
>> when navigating deeply nested directories since I had to backspace
>> after every directory completion.   Using the latest ipython rom bzr,
>> this appears to be fixed.  I don't know how it was fixed, but it is
>> great.  (thanks).
>
> Yes, I fixed that by introducing the pseudo-annoying behaviour you
> mention (I noticed the same thing on linux + scratchbox). It's the
> single_dir_expand call in ipy_completers.py (cd completer)
>
> Perhaps we should "special case" the .svn / dot-something thing.

Oh, I see.  I initially thought I wasn't seeing it on bic (fernando's
linux machine on which I have an acct) because I wasn't using a recent
bzr ipython there.  After I did an update to::

    > bzr branch lp:ipython

I see the same behavior as I described on my work machine.

I don't think this is the behavior you want.  *Certainly* you do not
want to be completing on hidden dirs unless a user has explicitly
requested to do so in your rc file (regardless of whether it is a
".svn" hidden dir).  But I don't think you want to (by default)
complete on single dirs either, at least not if other nondir files are
around.

Eg, if as in the original post, I have something like::

    In [3]: !mkdir -p somedir/subdir1

    In [4]: !touch somedir/file1

    In [5]: !touch somedir/file2

    In [6]: cd somedi<TAB>

we do not want to go to somedir/subdir1 by default (unless it is an rc
choice) because somedir is a perfectly reasonable place to go.   On
the bzr HEAD (what do you call HEAD in bzr?) I am being taken to
subdir1.   Ie,

    In [6]: cd some<TAB>

takes me to::

    In [6]: cd somedir/subdir1
    /home/jdhunter/somedir/subdir1

Now in the case of somedir containing only a *single* non-hidden dir
and *no* plain files, I think the current hyper-completion is a
feature.  But if there are files and/or dirs in the target dir, I
don't think you want to assume a subdir for completion.

But many thanks for fixing my trailing space completion bug, however you did it.

JDH


From jdh2358 at gmail.com  Fri Jun  6 01:38:39 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Fri, 6 Jun 2008 00:38:39 -0500
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
Message-ID: <88e473830806052238o560cf60aw56d8030a9d2fb4e6@mail.gmail.com>

On Thu, Jun 5, 2008 at 11:41 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> Yes, I fixed that by introducing the pseudo-annoying behaviour you
> mention (I noticed the same thing on linux + scratchbox). It's the
> single_dir_expand call in ipy_completers.py (cd completer)

If you are working on completions, here are some features I think
would be great:

 * for 'run' or 'ls' or 'cat' completions, complete only on files, not
 local python namespaces.  Eg, in pylab mode, the localname "hist" is
defined in mpl and "histogram", "histogram2d" and "histogramdd" are
defined in numpy.  But when I do an an "ls" completion on the
mpl/examples/hist<TAB> directory, I want to see the mpl histogram
examples.  If I expilcitly ask for them, all is well::

    In [3]: ls /home/jdhunter/mpl/examples/pylab_examples/hist*
    /home/jdhunter/mpl/examples/pylab_examples/hist_colormapped.py
    /home/jdhunter/mpl/examples/pylab_examples/histogram_demo_extended.py
    /home/jdhunter/mpl/examples/pylab_examples/histogram_demo.py

But if I cd into that dir, and do an 'ls hist<TAB>'

    In [6]: cd /home/jdhunter/mpl/examples/pylab_examples
    /home/jdhunter/mpl/examples/pylab_examples

    In [7]: ls hist<TAB>
    hist                        histogramdd
    hist_colormapped.py         histogram_demo_extended.py
    histogram                   histogram_demo.py
    histogram2d

I get files in that dir *and* names in the local namespace.
Interestingly, if I cd back to home and give the full path on to "ls"
followed by TAB, I get the desired behavior:

    In [8]: cd
    /home/jdhunter

    In [9]: ls mpl/examples/pylab_examples/hist<TAB>
    mpl/examples/pylab_examples/hist_colormapped.py
    mpl/examples/pylab_examples/histogram_demo_extended.py
    mpl/examples/pylab_examples/histogram_demo.py

However, 'run' is working as expected, usggesting this may be an easy fix::

    In [14]: cd mpl/examples/pylab_examples/

    In [15]: run hist<TAB>
    hist_colormapped.py         histogram_demo.py
    histogram_demo_extended.py

though 'ls' is not (as before)::

    In [15]: ls hist<TAB>
    hist                        histogramdd
    hist_colormapped.py         histogram_demo_extended.py
    histogram                   histogram_demo.py
    histogram2d

nor is 'cat', which  seems to suffer the same problem as 'ls'

Thats all for now!

JDH


From vivainio at gmail.com  Fri Jun  6 02:55:03 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 6 Jun 2008 09:55:03 +0300
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
	<88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com>
Message-ID: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com>

On Fri, Jun 6, 2008 at 8:05 AM, John Hunter <jdh2358 at gmail.com> wrote:

> Now in the case of somedir containing only a *single* non-hidden dir
> and *no* plain files, I think the current hyper-completion is a
> feature.  But if there are files and/or dirs in the target dir, I
> don't think you want to assume a subdir for completion.

I agree that it's not desirable. However, it was a compromise to get
this bug fixed.

Perhaps I'll add an option for this, so that it will only be a
workaround for those who have the buggy readline.

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


From fperez.net at gmail.com  Fri Jun  6 12:40:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 6 Jun 2008 09:40:23 -0700
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
	<88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com>
	<46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com>
Message-ID: <db6b5ecc0806060940j244532ads3dabfc788ec93834@mail.gmail.com>

On Thu, Jun 5, 2008 at 11:55 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, Jun 6, 2008 at 8:05 AM, John Hunter <jdh2358 at gmail.com> wrote:
>
>> Now in the case of somedir containing only a *single* non-hidden dir
>> and *no* plain files, I think the current hyper-completion is a
>> feature.  But if there are files and/or dirs in the target dir, I
>> don't think you want to assume a subdir for completion.
>
> I agree that it's not desirable. However, it was a compromise to get
> this bug fixed.
>
> Perhaps I'll add an option for this, so that it will only be a
> workaround for those who have the buggy readline.

Just here to mention that I saw you seem to have just committed a fix
into bzr, so John (or anyone else) can update from bzr and report if
they still see any problems.

Regards,

f


From ellisonbg.net at gmail.com  Fri Jun  6 13:22:07 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 6 Jun 2008 11:22:07 -0600
Subject: [IPython-dev] How do I do this in bzr? (again)
Message-ID: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com>

Hi,

I am wondering how I can take a file/files from one bzr branch
(ipython1-dev) and bring them into another branch (ipython) if the two
branches have no common heritage.  In this case, the two branches
hardly have the same structure and the incoming files will have to be
put into new location.  Is this even possible?  I know I could do mv
and then bzr add, but then I loose the history of the individual
files.  Any ideas?

Thanks

Brian


From ellisonbg.net at gmail.com  Fri Jun  6 16:11:08 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 6 Jun 2008 14:11:08 -0600
Subject: [IPython-dev] The merge has begun...
Message-ID: <6ce0ac130806061311k422e58fel67cae0996fd912b9@mail.gmail.com>

Hi,

I have created a ipython-ipython1a branch as the first ("a") branch
that is being used to merge ipython1-dev into IPython.  I wanted to
keep people posted on what exactly I am doing.

I am hoping that there will be a series of branches with names like
ipython-ipython1a, ipython-ipython1b, etc.  Each of these will be used
to merge new things from ipython1-dev into IPython.

https://code.launchpad.net/~ipython/ipython/ipython-ipython1a

Here is what is going on in ipython-ipython1a:

1) Moved the following by hand

ipython1.config -> IPython.config
ipython1.kernel -> IPython.kernel
ipython1.external/* -> IPython.external/* (removing repetitions)
ipython1.core -> IPython.kernel.core
ipython1.testutils -> IPython.testing
ipython1.tools -> IPython.tools

2) Moved IPython.tools.guid -> IPython1.external.guid

3) Renamed:

ipython1 -> IPython
IPython.core -> IPython.kernel.core
IPython.testutils -> IPython.testing

These subpackages that have been moved into IPython are relatively
stable and well tested and will immediately give IPython all of the
parallel computing capabilties of IPython1.

The next things I am going to do in this branch is get the setup.py
script (and friends into good condition).  This is the only thing that
is a little scary, as I will be doing quite a bit of refactoring.
When I am done with this and ready to merge back into the mainline
ipython branch, I will let people know and request lots of testing.

After I get these things done, I will merge into ipython and then make
a new branch to begin cleaning up other things.  Next on my scopes:

1) Merge the documentation for the two projects.

2) Clean up and merge other misc things like COPYRIGHT, etc.

IMPORTANT: I am not going to touch, reorganize or refactor any of the
"old" stuff in the ipython branch.  I don't know this codebase well
and I will leave that to other who know that stuff well.  My goal is
to get things from ipython1 -> ipython as quickly as possible to end
this transition.

The truly curious, can subscribe to this branch and follow what I am doing.

Cheers,

Brian


From vivian at vdesmedt.com  Sat Jun  7 03:32:06 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sat, 07 Jun 2008 09:32:06 +0200
Subject: [IPython-dev] Synchronization with Editor
In-Reply-To: <db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
References: <484553B1.9020405@vdesmedt.com>
	<db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
Message-ID: <484A3976.5040207@vdesmedt.com>

Dear All,

Just to tell you that I just push my "synchronize-editor" branch.

Again for the one that don't know the purpose of this submission the 
goal of it is to let you ask to IPython to synchronize itself with an 
external editor.

If the hook is set:

    * When IPython raise an uncaught exception the hook synchronize the
      external editor to the line IPython highlight
    * When IPython navigate through the stack in debug mode the hook
      synchronize the external editor to highlight the corresponding
      part of the code.

To set the hook just import the corresponding ip_synchronize_with_xxx 
extension in your ip_user.conf file.
I have developed six hooks for six different editors:

    * Scite (ip_synchronize_with_scite.py)
    * GVim (ip_synchronize_with_gvim.py)
    * Emacs (ip_synchronize_with_emacs.py)
    * Notepad++ (ip_synchronize_with_nppp.py)
    * PsPad (ip_synchronize_with_pspad.py)
    * UltraEdit (ip_synchronize_with_ue.py)

The hook are developed on the Windows platform and some of they code is 
specific to that platform.
In particular the small part of the code that give back the focus to the 
console after the synchronization with the editor took place but it 
should be possible to adapt it for Linux. I don't have a Linux box and 
I'm not in the best position to make it but I'll be glad to help.

Please tell me what you think of this proposition.

Regards,
Vivian.

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

From vds at aisystems.be  Sat Jun  7 04:40:02 2008
From: vds at aisystems.be (Vivian De Smedt)
Date: Sat, 07 Jun 2008 10:40:02 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
Message-ID: <484A4962.5050606@aisystems.be>

Dear All,

This is mail concerning pyreadline. I'm  a Window user and I'm using 
pyreadline. Because of my VisualStudio background I have configured code 
completion to be Ctrl+' ' and tab to be tab insertion.

Here is the corresponding section ipythonrc.ini

    #readline_parse_and_bind tab: complete
    #readline_parse_and_bind tab: menu-complete
    readline_parse_and_bind tab: tab-insert
    readline_parse_and_bind Control-space: complete

The completion part of that configuration works well but if I hit the 
tab touch I get a traceback in IPython basically because tabstop and 
line_cursor are not defined.

C:>ipython

In [1]: Readline internal error
Traceback (most recent call last):
  File "C:\Python25\lib\site-packages\pyreadline\console\console.py", 
line 671,
in hook_wrapper_23
    res = ensure_str(readline_hook(prompt))
  File "C:\Python25\lib\site-packages\pyreadline\rlmain.py", line 342, 
in readli
ne
    return self.mode.readline(prompt)
  File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 
133, in r
eadline
    self._readline_from_keyboard()
  File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 
90, in _r
eadline_from_keyboard
    r = dispatch_func(event)
  File "C:\Python25\lib\site-packages\pyreadline\modes\emacs.py", line 
289, in t
ab_insert
    ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop))
AttributeError: 'EmacsMode' object has no attribute 'line_cursor'

To address the problem I have define a default for tabstop in 
rlmain.Readline:

    class Readline(object):
        def __init__(self):
            self.startup_hook = None
            self.pre_input_hook = None
            self.completer = None
            self.completer_delims = " \t\n\"\\'`@$><=;|&{("
            self.console = console.Console()
            self.size = self.console.size()
            self.prompt_color = None
            self.command_color = None
            self.selection_color = self.console.saveattr<<4
            self.key_dispatch = {}
            self.previous_func = None
            self.first_prompt = True
            self.next_meta = False # True to force meta on next character
            self.tabstop = 4
            self.allow_ctrl_c=False
            self.ctrl_c_tap_time_interval=0.3
            self.debug=False

And slightly change the emacs and notemacs modes:

    class EmacsMode(basemode.BaseMode):
        ...
        def tab_insert(self, e): # (M-TAB)
            '''Insert a tab character. '''
            line_cursor = len(self.l_buffer)
            ws = ' ' * (self.tabstop - (line_cursor%self.tabstop))
            #ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop))
            self.insert_text(ws)

    class NotEmacsMode(basemode.BaseMode):
        ...
        def tab_insert(self, e): # (M-TAB)
            '''Insert a tab character. '''
            line_cursor = len(self.l_buffer)
            ws = ' ' * (self.tabstop - (line_cursor%self.tabstop))
            #ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop))
            self.insert_text(ws)

Please tell if you think about these propositions of changes.

Regards,
Vivian.

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

From vds at aisystems.be  Mon Jun  9 09:25:45 2008
From: vds at aisystems.be (Vivian De Smedt)
Date: Mon, 09 Jun 2008 15:25:45 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <200806091242.47835.meine@informatik.uni-hamburg.de>
References: <484A4962.5050606@aisystems.be>
	<200806091242.47835.meine@informatik.uni-hamburg.de>
Message-ID: <484D2F59.9080206@aisystems.be>

Hans,

I'll be glad to send you a patch but I don't know from which version 
control system. I understand from your mail that Bazaar is the one I 
should care about.

But when I try:

    bzr branch lp:pyreadline

I get:

    Connected (version 2.0, client Twisted)
    Authentication (publickey) successful!
    Secsh channel 1 opened.
    bzr: ERROR: Not a branch:
    "bzr+ssh://vivian-vdesmedt at bazaar.launchpad.net/~pyrea
    dline/pyreadline/trunk/".

What do you think I should do.

Regards,
Vivian.

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

From ondrej at certik.cz  Mon Jun  9 09:28:19 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 9 Jun 2008 15:28:19 +0200
Subject: [IPython-dev] man page errors
Message-ID: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com>

Hi,

while packaging 0.8.4 for Debian, we run into this minor problem with
the manpage:

$ man --warnings -l doc/ipython.1.gz > /dev/null
<standard input>:55: warning: `wxversion'' not defined
<standard input>:116: warning: `str(43)'' not defined
<standard input>:223: warning: `sh' not defined
<standard input>:234: warning: `snapshot'' not defined

One possible way to fix these is attached in the patch. Please apply,
or let's discuss how to fix it some other way. The reason is that
otherwise we are getting these warnings in Debian:

$ lintian ipython_0.8.4-1_i386.changes
W: ipython: manpage-has-errors-from-man
usr/share/man/man1/ipython.1.gz 55: warning: `wxversion'' not defined

All packages should be lintian clean -- but if this is not a bug, we
can add a lintian override.

Thanks,
Ondrej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: man_fix.patch
Type: text/x-patch
Size: 1815 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080609/15c5d20a/attachment.bin>

From stefan at sun.ac.za  Mon Jun  9 10:02:14 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 9 Jun 2008 16:02:14 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <484D2F59.9080206@aisystems.be>
References: <484A4962.5050606@aisystems.be>
	<200806091242.47835.meine@informatik.uni-hamburg.de>
	<484D2F59.9080206@aisystems.be>
Message-ID: <9457e7c80806090702t734e25c6l4096656e89b12fba@mail.gmail.com>

Hi Vivian

2008/6/9 Vivian De Smedt <vds at aisystems.be>:
> Hans,
>
> I'll be glad to send you a patch but I don't know from which version control
> system. I understand from your mail that Bazaar is the one I should care
> about.
>
> But when I try:
>
> bzr branch lp:pyreadline

That branch is still empty, for some reason.  In the meantime, there
is an svn branch here:

http://ipython.scipy.org/svn/ipython/pyreadline/trunk

Regards
St?fan


From vds at aisystems.be  Mon Jun  9 10:34:59 2008
From: vds at aisystems.be (Vivian De Smedt)
Date: Mon, 09 Jun 2008 16:34:59 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <200806091624.35935.meine@informatik.uni-hamburg.de>
References: <484A4962.5050606@aisystems.be>
	<200806091242.47835.meine@informatik.uni-hamburg.de>
	<484D2F59.9080206@aisystems.be>
	<200806091624.35935.meine@informatik.uni-hamburg.de>
Message-ID: <484D3F93.807@aisystems.be>

Dear All,

Here is my proposition of patch in a diff form.

Regards,
Vivian.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tab-insertion.patch
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080609/38e5dd9f/attachment.ksh>

From vivainio at gmail.com  Mon Jun  9 13:09:40 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 9 Jun 2008 20:09:40 +0300
Subject: [IPython-dev] Synchronization with Editor
In-Reply-To: <484A3976.5040207@vdesmedt.com>
References: <484553B1.9020405@vdesmedt.com>
	<db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
	<484A3976.5040207@vdesmedt.com>
Message-ID: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com>

On Sat, Jun 7, 2008 at 10:32 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:

> Dear All,
>
> Just to tell you that I just push my "synchronize-editor" branch.

Thank you, especially for taking the time to create a bzr branch!
Makes the process so much cleaner...

I have added notes to the whiteboard of the branch on launchpad.

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


From vivainio at gmail.com  Mon Jun  9 13:43:39 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 9 Jun 2008 20:43:39 +0300
Subject: [IPython-dev] man page errors
In-Reply-To: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com>
References: <85b5c3130806090628w52109978l63a5b0e4c5cad37b@mail.gmail.com>
Message-ID: <46cb515a0806091043j4c83d7cbscc4dd9f0287d79a3@mail.gmail.com>

On Mon, Jun 9, 2008 at 4:28 PM, Ondrej Certik <ondrej at certik.cz> wrote:

> while packaging 0.8.4 for Debian, we run into this minor problem with
> the manpage:

Thank you, fixed in bzr.

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


From ondrej at certik.cz  Mon Jun  9 14:41:34 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 9 Jun 2008 20:41:34 +0200
Subject: [IPython-dev] Old 'broken terminal' bug finally fixed
In-Reply-To: <db6b5ecc0804181511q5b23c166o5d9f0d851986ffb1@mail.gmail.com>
References: <db6b5ecc0804181511q5b23c166o5d9f0d851986ffb1@mail.gmail.com>
Message-ID: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com>

On Sat, Apr 19, 2008 at 12:11 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> there's a very old, *extremely* annoying bug that multiple people have
> asked about (on list and in person) that is finally just fixed.  The
> behavior was that at some point during a normal session, after a call
> to 'foo?', your terminal would be totally messed up, with no displayed
> input.  You could (blindly) type !reset to issue the system terminal
> reset command, but that would only help until the next time foo? was
> called, and the problem would then return.  Most of us would end up
> just quitting ipython and restarting, often losing useful session
> state.
>
> The problem with this is that we never knew how to reliably reproduce
> it...  Anyway, it's fixed now in current bzr:

Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug
indeed goes away in 0.8.4):

http://code.google.com/p/sympy/issues/detail?id=822

together with a screenshot how the terminal looks like (see the
comment #6 for the exact sympy revision to use). Maybe you could use
it to track the bug down in curses, as your patch only seems to be a
workaround (albeit working).

Ondrej


From ellisonbg.net at gmail.com  Mon Jun  9 16:10:36 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 9 Jun 2008 14:10:36 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
Message-ID: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>

Hello all,

I have just merged the ipython-ipython1a branch into ipython trunk.
This means that most of the stable stuff from ipython1 is now in
IPython.  This includes the following new subpackages:

IPython.kernel
IPython.kernel.core
IPython.config
IPython.tools

The biggest change though is that I have refectored the setup.py
script.  Because these new subpackages have lots of other
dependencies, we needed a nice way of handling these things.  Here is
a skech of how it is being handled:

1.  If setuptools is being used, we declare optional requires for the
additional deps

2.  If setuptools is not being used, we check for the deps manually
and simple tell the user what was found and what is required for what
features.

While this will likely take some find tuning, it is a start.

PLEASE, try out the new setup.py in trunk on various platforms and in
various situations.  We need to test this well as it is a huge change.

But, the bottom line is that IPython trunk now has full parallel
computing capabilities.  I will also announce on IPython-users

Next stop: documentation merge!!!

Cheers,

Brian


From ellisonbg.net at gmail.com  Mon Jun  9 16:18:05 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 9 Jun 2008 14:18:05 -0600
Subject: [IPython-dev] ipython1 -> IPython documentation merge about to begin
Message-ID: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com>

Hello all,

I wanted to let all the devs know that I am about to do a major
reorganization of the IPython documentation.  Part of this will be to
merge in the ipython1 documentation.  Because of this, I would ask
that people stay clear of the doc directory in trunk for a few days.
If you have changes in the docs that need to happen please wait for a
few days.  Feel free to ask me questions if needed.

Cheers,

Brian


From fperez.net at gmail.com  Mon Jun  9 18:43:46 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 9 Jun 2008 15:43:46 -0700
Subject: [IPython-dev] ipython1 -> IPython documentation merge about to
	begin
In-Reply-To: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com>
References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com>
Message-ID: <db6b5ecc0806091543h46522fbax8751f34846da3400@mail.gmail.com>

On Mon, Jun 9, 2008 at 1:18 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hello all,
>
> I wanted to let all the devs know that I am about to do a major
> reorganization of the IPython documentation.  Part of this will be to
> merge in the ipython1 documentation.  Because of this, I would ask
> that people stay clear of the doc directory in trunk for a few days.
> If you have changes in the docs that need to happen please wait for a
> few days.  Feel free to ask me questions if needed.

Go for it.  While I'm offline for the rest of the week, I'll work on a
private branch purely on automatic testing for the old code.  So no
chance of conflicts.

Thanks for the big merge!  I'll let you know of any gremlins I may hit.

Cheers,

f


From fperez.net at gmail.com  Mon Jun  9 18:44:46 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 9 Jun 2008 15:44:46 -0700
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>
References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>
Message-ID: <db6b5ecc0806091544v44ee3ea7y98b1b553a9f82af7@mail.gmail.com>

On Mon, Jun 9, 2008 at 1:10 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hello all,

> PLEASE, try out the new setup.py in trunk on various platforms and in
> various situations.  We need to test this well as it is a huge change.

I will let you know of any problems.  Since I'll be offline, any
changes I make will happen on a private branch and I'll test the
merges locally before any public push.

Cheers,

f


From stefan at sun.ac.za  Mon Jun  9 21:26:29 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 10 Jun 2008 03:26:29 +0200
Subject: [IPython-dev] ipython1 -> IPython documentation merge about to
	begin
In-Reply-To: <db6b5ecc0806091543h46522fbax8751f34846da3400@mail.gmail.com>
References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com>
	<db6b5ecc0806091543h46522fbax8751f34846da3400@mail.gmail.com>
Message-ID: <9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com>

Hey Brian

2008/6/10 Fernando Perez <fperez.net at gmail.com>:
> On Mon, Jun 9, 2008 at 1:18 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hello all,
>>
>> I wanted to let all the devs know that I am about to do a major
>> reorganization of the IPython documentation.  Part of this will be to
>> merge in the ipython1 documentation.  Because of this, I would ask
>> that people stay clear of the doc directory in trunk for a few days.
>> If you have changes in the docs that need to happen please wait for a
>> few days.  Feel free to ask me questions if needed.
>
> Go for it.  While I'm offline for the rest of the week, I'll work on a
> private branch purely on automatic testing for the old code.  So no
> chance of conflicts.

I merged the sconfig branch into ipython1b.  The tests aren't run
automatically at the moment, so do:

nosetests -v --with-doctest --doctest-tests IPython.config

to make sure everything is OK.

I wrote a first implementation of round-tripping, so a person can now:

a) Instantiate a new configuration
b) Update the configuration from a file
c) Modify the configuration
d) Dump the configuration back to file

The file writing is done using ConfigObj.  The one thing I haven't
tried yet is to write back to the same file I read from (to see
whether comments and structure are preserved).

Regards
St?fan


From ellisonbg.net at gmail.com  Mon Jun  9 22:45:22 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 9 Jun 2008 20:45:22 -0600
Subject: [IPython-dev] ipython1 -> IPython documentation merge about to
	begin
In-Reply-To: <9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com>
References: <6ce0ac130806091318jc96077aw1e6443b3639586a2@mail.gmail.com>
	<db6b5ecc0806091543h46522fbax8751f34846da3400@mail.gmail.com>
	<9457e7c80806091826w532b4c7dl73f7b5752d1aae17@mail.gmail.com>
Message-ID: <6ce0ac130806091945s1e94b927m1bb419a4f653a88a@mail.gmail.com>

> I merged the sconfig branch into ipython1b.  The tests aren't run
> automatically at the moment, so do:
>
> nosetests -v --with-doctest --doctest-tests IPython.config
>
> to make sure everything is OK.

Great!  Thanks for doing this.  Now I just to find some time to look
at this new stuff  and begin to use it.

> I wrote a first implementation of round-tripping, so a person can now:
>
> a) Instantiate a new configuration
> b) Update the configuration from a file
> c) Modify the configuration
> d) Dump the configuration back to file

This is exactly why going with ConfigObj makes sense for us.  I will
merge this stuff from ipython-ipython1b into ipython trunk soon.
Thanks again Stefan for doing this!

Brian

> The file writing is done using ConfigObj.  The one thing I haven't
> tried yet is to write back to the same file I read from (to see
> whether comments and structure are preserved).
>
> Regards
> St?fan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From gael.varoquaux at normalesup.org  Tue Jun 10 01:51:43 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 10 Jun 2008 07:51:43 +0200
Subject: [IPython-dev] Development on Launchpad, odds and ends
In-Reply-To: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
References: <db6b5ecc0806020027h320a671dtc618a8bdd819c434@mail.gmail.com>
Message-ID: <20080610055143.GB30061@phare.normalesup.org>

On Mon, Jun 02, 2008 at 12:27:13AM -0700, Fernando Perez wrote:
> IPython0/1 are dead.  Long live IPython! ;)

I feel I am getting to the battlefield a bit late, but just to give you
my gut feeling about this: this feels just right. I think this will help
us move forward.

Ga?l


From fperez.net at gmail.com  Tue Jun 10 03:10:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 10 Jun 2008 00:10:23 -0700
Subject: [IPython-dev] Old 'broken terminal' bug finally fixed
In-Reply-To: <85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com>
References: <db6b5ecc0804181511q5b23c166o5d9f0d851986ffb1@mail.gmail.com>
	<85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com>
Message-ID: <db6b5ecc0806100010n3db5cd9fjf42c8bcc9c073ffb@mail.gmail.com>

On Mon, Jun 9, 2008 at 11:41 AM, Ondrej Certik <ondrej at certik.cz> wrote:

> Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug
> indeed goes away in 0.8.4):
>
> http://code.google.com/p/sympy/issues/detail?id=822

Thanks!  I took the liberty to add your comment to the bug report I'd
filed for this at the python tracker:

http://bugs.python.org/issue2657

I doubt I'll spend much time myself on it now, but at least they have
all the info to reliably reproduce it.  That should make it much
easier to work on the problem (it was really annoying since we'd never
found a reliable way to reproduce it).

Regards,

f


From ondrej at certik.cz  Tue Jun 10 04:08:41 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 10 Jun 2008 10:08:41 +0200
Subject: [IPython-dev] Old 'broken terminal' bug finally fixed
In-Reply-To: <db6b5ecc0806100010n3db5cd9fjf42c8bcc9c073ffb@mail.gmail.com>
References: <db6b5ecc0804181511q5b23c166o5d9f0d851986ffb1@mail.gmail.com>
	<85b5c3130806091141v51b79160vf336d5a638074a68@mail.gmail.com>
	<db6b5ecc0806100010n3db5cd9fjf42c8bcc9c073ffb@mail.gmail.com>
Message-ID: <85b5c3130806100108l25310c32y5b05b6225f2ec967@mail.gmail.com>

On Tue, Jun 10, 2008 at 9:10 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 9, 2008 at 11:41 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>
>> Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug
>> indeed goes away in 0.8.4):
>>
>> http://code.google.com/p/sympy/issues/detail?id=822
>
> Thanks!  I took the liberty to add your comment to the bug report I'd
> filed for this at the python tracker:
>
> http://bugs.python.org/issue2657

Thanks.

>
> I doubt I'll spend much time myself on it now, but at least they have
> all the info to reliably reproduce it.  That should make it much
> easier to work on the problem (it was really annoying since we'd never
> found a reliable way to reproduce it).

Right. It was extremely annoying, I lost many sessions that way, so I
basically stopped using "?". It is very easy to trigger this in sympy
(with ipython 0.8.2), so I think it has something to do with unicode
printing. Anyway, I don't have time to dig into this either, so I am
glad it's finally fixed.

Ondrej


From jdh2358 at gmail.com  Tue Jun 10 12:01:30 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Tue, 10 Jun 2008 11:01:30 -0500
Subject: [IPython-dev] pylab executable
Message-ID: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com>

This came through the mpl feature request tracker (add a "pylab"
executable to the bin dir")

  https://sourceforge.net/tracker/index.php?func=detail&aid=1910613&group_id=80706&atid=560723

SInce this is really an ipython feature request, I'm moving it over
here (it is assigned to fer_perez on the mpl tracker).

JDH


From dfj225 at gmail.com  Tue Jun 10 13:02:12 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Tue, 10 Jun 2008 13:02:12 -0400
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>
References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>
Message-ID: <1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com>

Hi All,

I just gave the newest setup.py a go on my machine and ran into some
problems. I've copied its output below. If you need more information, let me
know and I will do my best to provide it.

Thanks,
~doug


python setup.py build
============================================================================
BUILDING IPYTHON
                python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
                        4.1.2 (Gentoo 4.1.2 p1.0.1)]
              platform: linux2

OPTIONAL DEPENDENCIES
        Zope.Interface: yes
               Twisted: 2.5.0
              Foolscap: 0.2.8
               OpenSSL: Not found (required if you want security in the
                        parallel computing capabilities)
                sphinx: 0.3
              pygments: 0.10
                  nose: 0.9.3
               pexpect: 2.1
running build
running build_py
creating build
creating build/lib
creating build/lib/IPython
copying IPython/wildcard.py -> build/lib/IPython
copying IPython/deep_reload.py -> build/lib/IPython
copying IPython/macro.py -> build/lib/IPython
copying IPython/ipapi.py -> build/lib/IPython
copying IPython/rlineimpl.py -> build/lib/IPython
copying IPython/CrashHandler.py -> build/lib/IPython
copying IPython/Shell.py -> build/lib/IPython
copying IPython/ultraTB.py -> build/lib/IPython
copying IPython/ipmaker.py -> build/lib/IPython
copying IPython/upgrade_dir.py -> build/lib/IPython
copying IPython/excolors.py -> build/lib/IPython
copying IPython/Release.py -> build/lib/IPython
copying IPython/demo.py -> build/lib/IPython
copying IPython/OutputTrap.py -> build/lib/IPython
copying IPython/shadowns.py -> build/lib/IPython
copying IPython/__init__.py -> build/lib/IPython
copying IPython/ColorANSI.py -> build/lib/IPython
copying IPython/platutils_posix.py -> build/lib/IPython
copying IPython/strdispatch.py -> build/lib/IPython
copying IPython/generics.py -> build/lib/IPython
copying IPython/platutils.py -> build/lib/IPython
copying IPython/Debugger.py -> build/lib/IPython
copying IPython/GnuplotInteractive.py -> build/lib/IPython
copying IPython/ipstruct.py -> build/lib/IPython
copying IPython/completer.py -> build/lib/IPython
copying IPython/FakeModule.py -> build/lib/IPython
copying IPython/usage.py -> build/lib/IPython
copying IPython/GnuplotRuntime.py -> build/lib/IPython
copying IPython/Logger.py -> build/lib/IPython
copying IPython/Prompts.py -> build/lib/IPython
copying IPython/numutils.py -> build/lib/IPython
copying IPython/ConfigLoader.py -> build/lib/IPython
copying IPython/platutils_dummy.py -> build/lib/IPython
copying IPython/DPyGetOpt.py -> build/lib/IPython
copying IPython/platutils_win32.py -> build/lib/IPython
copying IPython/background_jobs.py -> build/lib/IPython
copying IPython/iplib.py -> build/lib/IPython
copying IPython/dtutils.py -> build/lib/IPython
copying IPython/prefilter.py -> build/lib/IPython
copying IPython/PyColorize.py -> build/lib/IPython
copying IPython/twshell.py -> build/lib/IPython
copying IPython/history.py -> build/lib/IPython
copying IPython/winconsole.py -> build/lib/IPython
copying IPython/shellglobals.py -> build/lib/IPython
copying IPython/genutils.py -> build/lib/IPython
copying IPython/hooks.py -> build/lib/IPython
copying IPython/OInspect.py -> build/lib/IPython
copying IPython/Magic.py -> build/lib/IPython
copying IPython/irunner.py -> build/lib/IPython
copying IPython/Gnuplot2.py -> build/lib/IPython
copying IPython/Itpl.py -> build/lib/IPython
creating build/lib/IPython/config
copying IPython/config/api.py -> build/lib/IPython/config
copying IPython/config/__init__.py -> build/lib/IPython/config
copying IPython/config/cutils.py -> build/lib/IPython/config
copying IPython/config/sconfig.py -> build/lib/IPython/config
package init file 'IPython/config/tests/__init__.py' not found (or not a
regular file)
creating build/lib/IPython/config/tests
copying IPython/config/tests/simpleconf.py -> build/lib/IPython/config/tests
copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
creating build/lib/IPython/Extensions
copying IPython/Extensions/ipy_autoreload.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_rehashdir.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_sh.py -> build/lib/IPython/Extensions
copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions
copying IPython/Extensions/PhysicalQInteractive.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_system_conf.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_doctest.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_gnuglobal.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_traits_completer.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/numeric_formats.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_scipy.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions
copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_vimserver.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
copying IPython/Extensions/InterpreterExec.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions
copying IPython/Extensions/pspersistence.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
copying IPython/Extensions/PhysicalQInput.py -> build/lib/IPython/Extensions
copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_none.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_greedycompleter.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_numpy.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ext_rescapture.py -> build/lib/IPython/Extensions
copying IPython/Extensions/InterpreterPasteInput.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_constants.py -> build/lib/IPython/Extensions
copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_stock_completers.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_app_completers.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_completers.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
copying IPython/Extensions/ipy_profile_zope.py ->
build/lib/IPython/Extensions
copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions
copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
creating build/lib/IPython/external
copying IPython/external/mglob.py -> build/lib/IPython/external
copying IPython/external/path.py -> build/lib/IPython/external
copying IPython/external/__init__.py -> build/lib/IPython/external
copying IPython/external/simplegeneric.py -> build/lib/IPython/external
copying IPython/external/validate.py -> build/lib/IPython/external
copying IPython/external/configobj.py -> build/lib/IPython/external
copying IPython/external/guid.py -> build/lib/IPython/external
copying IPython/external/Itpl.py -> build/lib/IPython/external
creating build/lib/IPython/gui
copying IPython/gui/__init__.py -> build/lib/IPython/gui
creating build/lib/IPython/gui/wx
copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx
copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
creating build/lib/IPython/kernel
copying IPython/kernel/client.py -> build/lib/IPython/kernel
copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
copying IPython/kernel/map.py -> build/lib/IPython/kernel
copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
copying IPython/kernel/magic.py -> build/lib/IPython/kernel
copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
copying IPython/kernel/util.py -> build/lib/IPython/kernel
copying IPython/kernel/task.py -> build/lib/IPython/kernel
copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
copying IPython/kernel/error.py -> build/lib/IPython/kernel
copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
creating build/lib/IPython/kernel/config
copying IPython/kernel/config/__init__.py -> build/lib/IPython/kernel/config
creating build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_multienginefc.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_controllerservice.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_engineservice.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_task.py -> build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_pendingdeferred.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/engineservicetest.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_newserialized.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests
copying IPython/kernel/tests/multienginetest.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_taskfc.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_enginefc.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/test_multiengine.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/controllertest.py ->
build/lib/IPython/kernel/tests
copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests
creating build/lib/IPython/kernel/scripts
copying IPython/kernel/scripts/ipcluster.py ->
build/lib/IPython/kernel/scripts
copying IPython/kernel/scripts/__init__.py ->
build/lib/IPython/kernel/scripts
copying IPython/kernel/scripts/ipengine.py ->
build/lib/IPython/kernel/scripts
copying IPython/kernel/scripts/ipcontroller.py ->
build/lib/IPython/kernel/scripts
creating build/lib/IPython/kernel/core
copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/display_formatter.py ->
build/lib/IPython/kernel/core
copying IPython/kernel/core/message_cache.py ->
build/lib/IPython/kernel/core
copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/traceback_trap.py ->
build/lib/IPython/kernel/core
copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/output_trap.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/display_trap.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/interpreter.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
copying IPython/kernel/core/traceback_formatter.py ->
build/lib/IPython/kernel/core
copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
creating build/lib/IPython/kernel/core/config
copying IPython/kernel/core/config/__init__.py ->
build/lib/IPython/kernel/core/config
creating build/lib/IPython/kernel/core/tests
copying IPython/kernel/core/tests/test_shell.py ->
build/lib/IPython/kernel/core/tests
copying IPython/kernel/core/tests/__init__.py ->
build/lib/IPython/kernel/core/tests
creating build/lib/IPython/testing
copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
copying IPython/testing/__init__.py -> build/lib/IPython/testing
copying IPython/testing/parametric.py -> build/lib/IPython/testing
copying IPython/testing/util.py -> build/lib/IPython/testing
copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
copying IPython/testing/tutils.py -> build/lib/IPython/testing
copying IPython/testing/tstTEMPLATE_doctest.py -> build/lib/IPython/testing
copying IPython/testing/tcommon.py -> build/lib/IPython/testing
creating build/lib/IPython/testing/tests
copying IPython/testing/tests/__init__.py -> build/lib/IPython/testing/tests
copying IPython/testing/tests/test_testutils.py ->
build/lib/IPython/testing/tests
creating build/lib/IPython/tools
copying IPython/tools/__init__.py -> build/lib/IPython/tools
copying IPython/tools/utils.py -> build/lib/IPython/tools
copying IPython/tools/growl.py -> build/lib/IPython/tools
creating build/lib/IPython/tools/tests
copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
build/lib/IPython/tools/tests
copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
copying IPython/tools/tests/test_tools_utils.py ->
build/lib/IPython/tools/tests
copying IPython/tools/tests/tst_tools_utils_doctest.py ->
build/lib/IPython/tools/tests
package init file 'IPython/UserConfig/__init__.py' not found (or not a
regular file)
creating build/lib/IPython/UserConfig
copying IPython/UserConfig/ipy_user_conf.py -> build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc-physics -> build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc-tutorial ->
build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc-numeric -> build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig
copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig
package init file 'IPython/config/tests/__init__.py' not found (or not a
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a
regular file)
running build_scripts
creating build/scripts-2.5
error: file 'ipython/kernel/scripts/ipengine' does not exist


On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net at gmail.com>
wrote:

> Hello all,
>
> I have just merged the ipython-ipython1a branch into ipython trunk.
> This means that most of the stable stuff from ipython1 is now in
> IPython.  This includes the following new subpackages:
>
> IPython.kernel
> IPython.kernel.core
> IPython.config
> IPython.tools
>
> The biggest change though is that I have refectored the setup.py
> script.  Because these new subpackages have lots of other
> dependencies, we needed a nice way of handling these things.  Here is
> a skech of how it is being handled:
>
> 1.  If setuptools is being used, we declare optional requires for the
> additional deps
>
> 2.  If setuptools is not being used, we check for the deps manually
> and simple tell the user what was found and what is required for what
> features.
>
> While this will likely take some find tuning, it is a start.
>
> PLEASE, try out the new setup.py in trunk on various platforms and in
> various situations.  We need to test this well as it is a huge change.
>
> But, the bottom line is that IPython trunk now has full parallel
> computing capabilities.  I will also announce on IPython-users
>
> Next stop: documentation merge!!!
>
> Cheers,
>
> Brian
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080610/d5a3dfae/attachment.html>

From fperez.net at gmail.com  Tue Jun 10 13:54:51 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 10 Jun 2008 10:54:51 -0700
Subject: [IPython-dev] pylab executable
In-Reply-To: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com>
References: <88e473830806100901h1175da70r83bffdb54784f92b@mail.gmail.com>
Message-ID: <db6b5ecc0806101054n4e7ae6d7v55cc761314d62569@mail.gmail.com>

On Tue, Jun 10, 2008 at 9:01 AM, John Hunter <jdh2358 at gmail.com> wrote:
> This came through the mpl feature request tracker (add a "pylab"
> executable to the bin dir")
>
>  https://sourceforge.net/tracker/index.php?func=detail&aid=1910613&group_id=80706&atid=560723
>
> SInce this is really an ipython feature request, I'm moving it over
> here (it is assigned to fer_perez on the mpl tracker).

I'm  not fully opposed, but to some extent I'm not sure it's really
needed.  It's one of  those things along Guido's "not every 2-line
function has to be part of the stdlib".  But if you think that  it
would help the beginners, we can certainly include  it.

I would, however, suggest:

- make it a python rather than a shell script, for portability reasons
(we have Win32 users for whom a /bin/sh script won't work  right).

- Make it the equivalent of 'ipython  -pylab -p pylab'. I know it
sounds a bit confusing,  but there's a method to the madness: -pylab
should do the absolute minimum: basically load pylab and figure out
the threading issues.  It's a special option because it encodes a lot
of initialization behavior that can't be done afterwards.  But by
having this script call a pylab *profile*, we can put other
customizations that we may think of later in the profile, and it gives
users a clean way to tweak it by making a personal profile if they
feel like it.

Feel free to tag this into ipython's bug tracker:

https://bugs.launchpad.net/ipython

Cheers,

f


From cohen at slac.stanford.edu  Tue Jun 10 13:54:35 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 19:54:35 +0200
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
Message-ID: <484EBFDB.3010500@slac.stanford.edu>

Doug,
replace ipython by IPython in setupbase.py, at the line where ipengine 
is called and the 2 next ones.
Johann

ipython-dev-request at scipy.org wrote:
> Send IPython-dev mailing list submissions to
> 	ipython-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> or, via email, send a message with subject or body 'help' to
> 	ipython-dev-request at scipy.org
>
> You can reach the person managing the list at
> 	ipython-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPython-dev digest..."
>   
> ------------------------------------------------------------------------
>
> Today's Topics:
>
>    1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones)
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
> From:
> "Doug Jones" <dfj225 at gmail.com>
> Date:
> Tue, 10 Jun 2008 13:02:12 -0400
> To:
> "Brian Granger" <ellisonbg.net at gmail.com>
>
> To:
> "Brian Granger" <ellisonbg.net at gmail.com>
> CC:
> IPython Development list <ipython-dev at scipy.net>
>
>
> Hi All,
>
> I just gave the newest setup.py a go on my machine and ran into some 
> problems. I've copied its output below. If you need more information, 
> let me know and I will do my best to provide it.
>
> Thanks,
> ~doug
>
>
> python setup.py build
> ============================================================================
> BUILDING IPYTHON
>                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
>                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>               platform: linux2
>
> OPTIONAL DEPENDENCIES
>         Zope.Interface: yes
>                Twisted: 2.5.0
>               Foolscap: 0.2.8
>                OpenSSL: Not found (required if you want security in the
>                         parallel computing capabilities)
>                 sphinx: 0.3
>               pygments: 0.10
>                   nose: 0.9.3
>                pexpect: 2.1
> running build
> running build_py
> creating build
> creating build/lib
> creating build/lib/IPython
> copying IPython/wildcard.py -> build/lib/IPython
> copying IPython/deep_reload.py -> build/lib/IPython
> copying IPython/macro.py -> build/lib/IPython
> copying IPython/ipapi.py -> build/lib/IPython
> copying IPython/rlineimpl.py -> build/lib/IPython
> copying IPython/CrashHandler.py -> build/lib/IPython
> copying IPython/Shell.py -> build/lib/IPython
> copying IPython/ultraTB.py -> build/lib/IPython
> copying IPython/ipmaker.py -> build/lib/IPython
> copying IPython/upgrade_dir.py -> build/lib/IPython
> copying IPython/excolors.py -> build/lib/IPython
> copying IPython/Release.py -> build/lib/IPython
> copying IPython/demo.py -> build/lib/IPython
> copying IPython/OutputTrap.py -> build/lib/IPython
> copying IPython/shadowns.py -> build/lib/IPython
> copying IPython/__init__.py -> build/lib/IPython
> copying IPython/ColorANSI.py -> build/lib/IPython
> copying IPython/platutils_posix.py -> build/lib/IPython
> copying IPython/strdispatch.py -> build/lib/IPython
> copying IPython/generics.py -> build/lib/IPython
> copying IPython/platutils.py -> build/lib/IPython
> copying IPython/Debugger.py -> build/lib/IPython
> copying IPython/GnuplotInteractive.py -> build/lib/IPython
> copying IPython/ipstruct.py -> build/lib/IPython
> copying IPython/completer.py -> build/lib/IPython
> copying IPython/FakeModule.py -> build/lib/IPython
> copying IPython/usage.py -> build/lib/IPython
> copying IPython/GnuplotRuntime.py -> build/lib/IPython
> copying IPython/Logger.py -> build/lib/IPython
> copying IPython/Prompts.py -> build/lib/IPython
> copying IPython/numutils.py -> build/lib/IPython
> copying IPython/ConfigLoader.py -> build/lib/IPython
> copying IPython/platutils_dummy.py -> build/lib/IPython
> copying IPython/DPyGetOpt.py -> build/lib/IPython
> copying IPython/platutils_win32.py -> build/lib/IPython
> copying IPython/background_jobs.py -> build/lib/IPython
> copying IPython/iplib.py -> build/lib/IPython
> copying IPython/dtutils.py -> build/lib/IPython
> copying IPython/prefilter.py -> build/lib/IPython
> copying IPython/PyColorize.py -> build/lib/IPython
> copying IPython/twshell.py -> build/lib/IPython
> copying IPython/history.py -> build/lib/IPython
> copying IPython/winconsole.py -> build/lib/IPython
> copying IPython/shellglobals.py -> build/lib/IPython
> copying IPython/genutils.py -> build/lib/IPython
> copying IPython/hooks.py -> build/lib/IPython
> copying IPython/OInspect.py -> build/lib/IPython
> copying IPython/Magic.py -> build/lib/IPython
> copying IPython/irunner.py -> build/lib/IPython
> copying IPython/Gnuplot2.py -> build/lib/IPython
> copying IPython/Itpl.py -> build/lib/IPython
> creating build/lib/IPython/config
> copying IPython/config/api.py -> build/lib/IPython/config
> copying IPython/config/__init__.py -> build/lib/IPython/config
> copying IPython/config/cutils.py -> build/lib/IPython/config
> copying IPython/config/sconfig.py -> build/lib/IPython/config
> package init file 'IPython/config/tests/__init__.py' not found (or not 
> a regular file)
> creating build/lib/IPython/config/tests
> copying IPython/config/tests/simpleconf.py -> 
> build/lib/IPython/config/tests
> copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
> creating build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_autoreload.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_rehashdir.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_sh.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/PhysicalQInteractive.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_system_conf.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_doctest.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_gnuglobal.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_traits_completer.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/numeric_formats.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_scipy.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_vimserver.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/InterpreterExec.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/pspersistence.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/PhysicalQInput.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_none.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_greedycompleter.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_numpy.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ext_rescapture.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/InterpreterPasteInput.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_constants.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_stock_completers.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_app_completers.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_completers.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_zope.py -> 
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
> creating build/lib/IPython/external
> copying IPython/external/mglob.py -> build/lib/IPython/external
> copying IPython/external/path.py -> build/lib/IPython/external
> copying IPython/external/__init__.py -> build/lib/IPython/external
> copying IPython/external/simplegeneric.py -> build/lib/IPython/external
> copying IPython/external/validate.py -> build/lib/IPython/external
> copying IPython/external/configobj.py -> build/lib/IPython/external
> copying IPython/external/guid.py -> build/lib/IPython/external
> copying IPython/external/Itpl.py -> build/lib/IPython/external
> creating build/lib/IPython/gui
> copying IPython/gui/__init__.py -> build/lib/IPython/gui
> creating build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
> creating build/lib/IPython/kernel
> copying IPython/kernel/client.py -> build/lib/IPython/kernel
> copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
> copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
> copying IPython/kernel/map.py -> build/lib/IPython/kernel
> copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
> copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
> copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
> copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
> copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
> copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
> copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
> copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
> copying IPython/kernel/magic.py -> build/lib/IPython/kernel
> copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
> copying IPython/kernel/util.py -> build/lib/IPython/kernel
> copying IPython/kernel/task.py -> build/lib/IPython/kernel
> copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
> copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
> copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
> copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
> copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/error.py -> build/lib/IPython/kernel
> copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
> creating build/lib/IPython/kernel/config
> copying IPython/kernel/config/__init__.py -> 
> build/lib/IPython/kernel/config
> creating build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_multienginefc.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_controllerservice.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_engineservice.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_task.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_pendingdeferred.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/engineservicetest.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_newserialized.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/multienginetest.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_taskfc.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_enginefc.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_multiengine.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/controllertest.py -> 
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests
> creating build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipcluster.py -> 
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/__init__.py -> 
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipengine.py -> 
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipcontroller.py -> 
> build/lib/IPython/kernel/scripts
> creating build/lib/IPython/kernel/core
> copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/display_formatter.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/message_cache.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/traceback_trap.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/output_trap.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/display_trap.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/interpreter.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/traceback_formatter.py -> 
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
> creating build/lib/IPython/kernel/core/config
> copying IPython/kernel/core/config/__init__.py -> 
> build/lib/IPython/kernel/core/config
> creating build/lib/IPython/kernel/core/tests
> copying IPython/kernel/core/tests/test_shell.py -> 
> build/lib/IPython/kernel/core/tests
> copying IPython/kernel/core/tests/__init__.py -> 
> build/lib/IPython/kernel/core/tests
> creating build/lib/IPython/testing
> copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
> copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
> copying IPython/testing/__init__.py -> build/lib/IPython/testing
> copying IPython/testing/parametric.py -> build/lib/IPython/testing
> copying IPython/testing/util.py -> build/lib/IPython/testing
> copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
> copying IPython/testing/tutils.py -> build/lib/IPython/testing
> copying IPython/testing/tstTEMPLATE_doctest.py -> 
> build/lib/IPython/testing
> copying IPython/testing/tcommon.py -> build/lib/IPython/testing
> creating build/lib/IPython/testing/tests
> copying IPython/testing/tests/__init__.py -> 
> build/lib/IPython/testing/tests
> copying IPython/testing/tests/test_testutils.py -> 
> build/lib/IPython/testing/tests
> creating build/lib/IPython/tools
> copying IPython/tools/__init__.py -> build/lib/IPython/tools
> copying IPython/tools/utils.py -> build/lib/IPython/tools
> copying IPython/tools/growl.py -> build/lib/IPython/tools
> creating build/lib/IPython/tools/tests
> copying IPython/tools/tests/tst_tools_utils_doctest2.py -> 
> build/lib/IPython/tools/tests
> copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
> copying IPython/tools/tests/test_tools_utils.py -> 
> build/lib/IPython/tools/tests
> copying IPython/tools/tests/tst_tools_utils_doctest.py -> 
> build/lib/IPython/tools/tests
> package init file 'IPython/UserConfig/__init__.py' not found (or not a 
> regular file)
> creating build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipy_user_conf.py -> 
> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-physics -> 
> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-tutorial -> 
> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-numeric -> 
> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig
> package init file 'IPython/config/tests/__init__.py' not found (or not 
> a regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a 
> regular file)
> running build_scripts
> creating build/scripts-2.5
> error: file 'ipython/kernel/scripts/ipengine' does not exist
>
>
> On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net 
> <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
>
>     Hello all,
>
>     I have just merged the ipython-ipython1a branch into ipython trunk.
>     This means that most of the stable stuff from ipython1 is now in
>     IPython.  This includes the following new subpackages:
>
>     IPython.kernel
>     IPython.kernel.core
>     IPython.config
>     IPython.tools
>
>     The biggest change though is that I have refectored the setup.py
>     script.  Because these new subpackages have lots of other
>     dependencies, we needed a nice way of handling these things.  Here is
>     a skech of how it is being handled:
>
>     1.  If setuptools is being used, we declare optional requires for the
>     additional deps
>
>     2.  If setuptools is not being used, we check for the deps manually
>     and simple tell the user what was found and what is required for what
>     features.
>
>     While this will likely take some find tuning, it is a start.
>
>     PLEASE, try out the new setup.py in trunk on various platforms and in
>     various situations.  We need to test this well as it is a huge change.
>
>     But, the bottom line is that IPython trunk now has full parallel
>     computing capabilities.  I will also announce on IPython-users
>
>     Next stop: documentation merge!!!
>
>     Cheers,
>
>     Brian
>     _______________________________________________
>     IPython-dev mailing list
>     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>   


From dfj225 at gmail.com  Tue Jun 10 14:01:58 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Tue, 10 Jun 2008 14:01:58 -0400
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <484EBFDB.3010500@slac.stanford.edu>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
Message-ID: <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>

Johann,

Thanks, that seemed to have fixed the problem. I still got the following
warnings, not sure if they impact anything or not.

package init file 'IPython/config/tests/__init__.py' not found (or not a
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a
regular file)
package init file 'IPython/config/tests/__init__.py' not found (or not a
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a
regular file)


On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi <
cohen at slac.stanford.edu> wrote:

> Doug,
> replace ipython by IPython in setupbase.py, at the line where ipengine
> is called and the 2 next ones.
> Johann
>
> ipython-dev-request at scipy.org wrote:
> > Send IPython-dev mailing list submissions to
> >       ipython-dev at scipy.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> > or, via email, send a message with subject or body 'help' to
> >       ipython-dev-request at scipy.org
> >
> > You can reach the person managing the list at
> >       ipython-dev-owner at scipy.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of IPython-dev digest..."
> >
> > ------------------------------------------------------------------------
> >
> > Today's Topics:
> >
> >    1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones)
> >
> >
> > ------------------------------------------------------------------------
> >
> > Subject:
> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
> > From:
> > "Doug Jones" <dfj225 at gmail.com>
> > Date:
> > Tue, 10 Jun 2008 13:02:12 -0400
> > To:
> > "Brian Granger" <ellisonbg.net at gmail.com>
> >
> > To:
> > "Brian Granger" <ellisonbg.net at gmail.com>
> > CC:
> > IPython Development list <ipython-dev at scipy.net>
> >
> >
> > Hi All,
> >
> > I just gave the newest setup.py a go on my machine and ran into some
> > problems. I've copied its output below. If you need more information,
> > let me know and I will do my best to provide it.
> >
> > Thanks,
> > ~doug
> >
> >
> > python setup.py build
> >
> ============================================================================
> > BUILDING IPYTHON
> >                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
> >                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
> >               platform: linux2
> >
> > OPTIONAL DEPENDENCIES
> >         Zope.Interface: yes
> >                Twisted: 2.5.0
> >               Foolscap: 0.2.8
> >                OpenSSL: Not found (required if you want security in the
> >                         parallel computing capabilities)
> >                 sphinx: 0.3
> >               pygments: 0.10
> >                   nose: 0.9.3
> >                pexpect: 2.1
> > running build
> > running build_py
> > creating build
> > creating build/lib
> > creating build/lib/IPython
> > copying IPython/wildcard.py -> build/lib/IPython
> > copying IPython/deep_reload.py -> build/lib/IPython
> > copying IPython/macro.py -> build/lib/IPython
> > copying IPython/ipapi.py -> build/lib/IPython
> > copying IPython/rlineimpl.py -> build/lib/IPython
> > copying IPython/CrashHandler.py -> build/lib/IPython
> > copying IPython/Shell.py -> build/lib/IPython
> > copying IPython/ultraTB.py -> build/lib/IPython
> > copying IPython/ipmaker.py -> build/lib/IPython
> > copying IPython/upgrade_dir.py -> build/lib/IPython
> > copying IPython/excolors.py -> build/lib/IPython
> > copying IPython/Release.py -> build/lib/IPython
> > copying IPython/demo.py -> build/lib/IPython
> > copying IPython/OutputTrap.py -> build/lib/IPython
> > copying IPython/shadowns.py -> build/lib/IPython
> > copying IPython/__init__.py -> build/lib/IPython
> > copying IPython/ColorANSI.py -> build/lib/IPython
> > copying IPython/platutils_posix.py -> build/lib/IPython
> > copying IPython/strdispatch.py -> build/lib/IPython
> > copying IPython/generics.py -> build/lib/IPython
> > copying IPython/platutils.py -> build/lib/IPython
> > copying IPython/Debugger.py -> build/lib/IPython
> > copying IPython/GnuplotInteractive.py -> build/lib/IPython
> > copying IPython/ipstruct.py -> build/lib/IPython
> > copying IPython/completer.py -> build/lib/IPython
> > copying IPython/FakeModule.py -> build/lib/IPython
> > copying IPython/usage.py -> build/lib/IPython
> > copying IPython/GnuplotRuntime.py -> build/lib/IPython
> > copying IPython/Logger.py -> build/lib/IPython
> > copying IPython/Prompts.py -> build/lib/IPython
> > copying IPython/numutils.py -> build/lib/IPython
> > copying IPython/ConfigLoader.py -> build/lib/IPython
> > copying IPython/platutils_dummy.py -> build/lib/IPython
> > copying IPython/DPyGetOpt.py -> build/lib/IPython
> > copying IPython/platutils_win32.py -> build/lib/IPython
> > copying IPython/background_jobs.py -> build/lib/IPython
> > copying IPython/iplib.py -> build/lib/IPython
> > copying IPython/dtutils.py -> build/lib/IPython
> > copying IPython/prefilter.py -> build/lib/IPython
> > copying IPython/PyColorize.py -> build/lib/IPython
> > copying IPython/twshell.py -> build/lib/IPython
> > copying IPython/history.py -> build/lib/IPython
> > copying IPython/winconsole.py -> build/lib/IPython
> > copying IPython/shellglobals.py -> build/lib/IPython
> > copying IPython/genutils.py -> build/lib/IPython
> > copying IPython/hooks.py -> build/lib/IPython
> > copying IPython/OInspect.py -> build/lib/IPython
> > copying IPython/Magic.py -> build/lib/IPython
> > copying IPython/irunner.py -> build/lib/IPython
> > copying IPython/Gnuplot2.py -> build/lib/IPython
> > copying IPython/Itpl.py -> build/lib/IPython
> > creating build/lib/IPython/config
> > copying IPython/config/api.py -> build/lib/IPython/config
> > copying IPython/config/__init__.py -> build/lib/IPython/config
> > copying IPython/config/cutils.py -> build/lib/IPython/config
> > copying IPython/config/sconfig.py -> build/lib/IPython/config
> > package init file 'IPython/config/tests/__init__.py' not found (or not
> > a regular file)
> > creating build/lib/IPython/config/tests
> > copying IPython/config/tests/simpleconf.py ->
> > build/lib/IPython/config/tests
> > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
> > creating build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_autoreload.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_rehashdir.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_sh.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/PhysicalQInteractive.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_system_conf.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_doctest.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_gnuglobal.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_traits_completer.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/numeric_formats.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_scipy.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_vimserver.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/InterpreterExec.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_exportdb.py ->
> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/pspersistence.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/PhysicalQInput.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_none.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_greedycompleter.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_numpy.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ext_rescapture.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/InterpreterPasteInput.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_constants.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_defaults.py ->
> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_stock_completers.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_app_completers.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_completers.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_profile_zope.py ->
> > build/lib/IPython/Extensions
> > copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions
> > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
> > creating build/lib/IPython/external
> > copying IPython/external/mglob.py -> build/lib/IPython/external
> > copying IPython/external/path.py -> build/lib/IPython/external
> > copying IPython/external/__init__.py -> build/lib/IPython/external
> > copying IPython/external/simplegeneric.py -> build/lib/IPython/external
> > copying IPython/external/validate.py -> build/lib/IPython/external
> > copying IPython/external/configobj.py -> build/lib/IPython/external
> > copying IPython/external/guid.py -> build/lib/IPython/external
> > copying IPython/external/Itpl.py -> build/lib/IPython/external
> > creating build/lib/IPython/gui
> > copying IPython/gui/__init__.py -> build/lib/IPython/gui
> > creating build/lib/IPython/gui/wx
> > copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx
> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
> > creating build/lib/IPython/kernel
> > copying IPython/kernel/client.py -> build/lib/IPython/kernel
> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
> > copying IPython/kernel/map.py -> build/lib/IPython/kernel
> > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
> > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
> > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel
> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
> > copying IPython/kernel/util.py -> build/lib/IPython/kernel
> > copying IPython/kernel/task.py -> build/lib/IPython/kernel
> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
> > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
> > copying IPython/kernel/error.py -> build/lib/IPython/kernel
> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
> > creating build/lib/IPython/kernel/config
> > copying IPython/kernel/config/__init__.py ->
> > build/lib/IPython/kernel/config
> > creating build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_multienginefc.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_controllerservice.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_engineservice.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_task.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_pendingdeferred.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/engineservicetest.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_newserialized.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/__init__.py ->
> build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/multienginetest.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_taskfc.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_enginefc.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/test_multiengine.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/controllertest.py ->
> > build/lib/IPython/kernel/tests
> > copying IPython/kernel/tests/tasktest.py ->
> build/lib/IPython/kernel/tests
> > creating build/lib/IPython/kernel/scripts
> > copying IPython/kernel/scripts/ipcluster.py ->
> > build/lib/IPython/kernel/scripts
> > copying IPython/kernel/scripts/__init__.py ->
> > build/lib/IPython/kernel/scripts
> > copying IPython/kernel/scripts/ipengine.py ->
> > build/lib/IPython/kernel/scripts
> > copying IPython/kernel/scripts/ipcontroller.py ->
> > build/lib/IPython/kernel/scripts
> > creating build/lib/IPython/kernel/core
> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/display_formatter.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/message_cache.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/traceback_trap.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/output_trap.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/display_trap.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/interpreter.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
> > copying IPython/kernel/core/traceback_formatter.py ->
> > build/lib/IPython/kernel/core
> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
> > creating build/lib/IPython/kernel/core/config
> > copying IPython/kernel/core/config/__init__.py ->
> > build/lib/IPython/kernel/core/config
> > creating build/lib/IPython/kernel/core/tests
> > copying IPython/kernel/core/tests/test_shell.py ->
> > build/lib/IPython/kernel/core/tests
> > copying IPython/kernel/core/tests/__init__.py ->
> > build/lib/IPython/kernel/core/tests
> > creating build/lib/IPython/testing
> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
> > copying IPython/testing/__init__.py -> build/lib/IPython/testing
> > copying IPython/testing/parametric.py -> build/lib/IPython/testing
> > copying IPython/testing/util.py -> build/lib/IPython/testing
> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
> > copying IPython/testing/tutils.py -> build/lib/IPython/testing
> > copying IPython/testing/tstTEMPLATE_doctest.py ->
> > build/lib/IPython/testing
> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing
> > creating build/lib/IPython/testing/tests
> > copying IPython/testing/tests/__init__.py ->
> > build/lib/IPython/testing/tests
> > copying IPython/testing/tests/test_testutils.py ->
> > build/lib/IPython/testing/tests
> > creating build/lib/IPython/tools
> > copying IPython/tools/__init__.py -> build/lib/IPython/tools
> > copying IPython/tools/utils.py -> build/lib/IPython/tools
> > copying IPython/tools/growl.py -> build/lib/IPython/tools
> > creating build/lib/IPython/tools/tests
> > copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
> > build/lib/IPython/tools/tests
> > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
> > copying IPython/tools/tests/test_tools_utils.py ->
> > build/lib/IPython/tools/tests
> > copying IPython/tools/tests/tst_tools_utils_doctest.py ->
> > build/lib/IPython/tools/tests
> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
> > regular file)
> > creating build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipy_user_conf.py ->
> > build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc-physics ->
> > build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc-tutorial ->
> > build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc-numeric ->
> > build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig
> > copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig
> > package init file 'IPython/config/tests/__init__.py' not found (or not
> > a regular file)
> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
> > regular file)
> > running build_scripts
> > creating build/scripts-2.5
> > error: file 'ipython/kernel/scripts/ipengine' does not exist
> >
> >
> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
> > <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
> >
> >     Hello all,
> >
> >     I have just merged the ipython-ipython1a branch into ipython trunk.
> >     This means that most of the stable stuff from ipython1 is now in
> >     IPython.  This includes the following new subpackages:
> >
> >     IPython.kernel
> >     IPython.kernel.core
> >     IPython.config
> >     IPython.tools
> >
> >     The biggest change though is that I have refectored the setup.py
> >     script.  Because these new subpackages have lots of other
> >     dependencies, we needed a nice way of handling these things.  Here is
> >     a skech of how it is being handled:
> >
> >     1.  If setuptools is being used, we declare optional requires for the
> >     additional deps
> >
> >     2.  If setuptools is not being used, we check for the deps manually
> >     and simple tell the user what was found and what is required for what
> >     features.
> >
> >     While this will likely take some find tuning, it is a start.
> >
> >     PLEASE, try out the new setup.py in trunk on various platforms and in
> >     various situations.  We need to test this well as it is a huge
> change.
> >
> >     But, the bottom line is that IPython trunk now has full parallel
> >     computing capabilities.  I will also announce on IPython-users
> >
> >     Next stop: documentation merge!!!
> >
> >     Cheers,
> >
> >     Brian
> >     _______________________________________________
> >     IPython-dev mailing list
> >     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
> >     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080610/77ec7cc2/attachment.html>

From cohen at slac.stanford.edu  Tue Jun 10 14:02:55 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 20:02:55 +0200
Subject: [IPython-dev] building current bzr trunk :
Message-ID: <484EC1CF.90602@slac.stanford.edu>

hi there,
after the modif to setupbase of my earlier post, I get:
[cohen at jarrett ipython]$ python setup.py build
============================================================================
BUILDING IPYTHON
python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
4.1.2 20070925 (Red Hat 4.1.2-33)]
platform: linux2

OPTIONAL DEPENDENCIES
Zope.Interface: yes
Twisted: 2.5.0
Foolscap: Not found (required for parallel computing
capabilities)
OpenSSL: 0.6
sphinx: Not found (required for building documentation)
pygments: Not found (required for syntax highlighting
documentation)
nose: 0.10.0
pexpect: 2.3
running build
running build_py
package init file 'IPython/config/tests/__init__.py' not found (or not a 
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a 
regular file)
package init file 'IPython/config/tests/__init__.py' not found (or not a 
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a 
regular file)
running build_scripts

So the first thing I want to try then is to get Foolscap.... but:
[root at jarrett ~]# easy_install Foolscap
Searching for Foolscap
Reading http://pypi.python.org/simple/Foolscap/
Couldn't find index page for 'Foolscap' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
Reading http://pypi.python.org/simple/foolscap/
Reading http://foolscap.lothar.com/
Reading http://foolscap.lothar.com/trac
Best match: foolscap 0.2.8
Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
Processing foolscap-0.2.8.tar.gz
Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
zip_safe flag not set; analyzing archive contents...
Adding foolscap 0.2.8 to easy-install.pth file
Installing flogtool script to /usr/bin

Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
Processing dependencies for Foolscap
Searching for twisted>=2.4.0
Reading http://pypi.python.org/simple/twisted/
Reading http://pypi.python.org/simple/Twisted/
Reading http://twistedmatrix.com/
Reading http://www.twistedmatrix.com
Reading http://twistedmatrix.com/products/download
Reading http://twistedmatrix.com/projects/core/
Best match: Twisted 8.1.0
Downloading 
http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
Processing Twisted-8.1.0.tar.bz2
Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
twisted/protocols/_c_urlarg.c: In function ?unquote?:
twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing 
argument 2 of ?PycStringIO->cwrite? differ in signedness
twisted/python/_epoll.c: In function ?__pyx_f_6_epoll_5epoll___dealloc__?:
twisted/python/_epoll.c:168: attention : label ?__pyx_L1? defined but 
not used
twisted/python/_epoll.c: In function ?__pyx_f_6_epoll_5epoll_wait?:
twisted/python/_epoll.c:432: attention : label ?__pyx_L7? defined but 
not used
twisted/python/_epoll.c:430: attention : label ?__pyx_L6? defined but 
not used
twisted/python/_epoll.c: In function ?__pyx_tp_new_6_epoll_epoll?:
twisted/python/_epoll.c:508: attention : unused variable ?p?
twisted/python/_epoll.c: In function ?__pyx_tp_dealloc_6_epoll_epoll?:
twisted/python/_epoll.c:513: attention : unused variable ?p?
twisted/python/_epoll.c: In function ?__pyx_tp_traverse_6_epoll_epoll?:
twisted/python/_epoll.c:528: attention : unused variable ?p?
twisted/python/_epoll.c:527: attention : unused variable ?e?
twisted/python/_epoll.c: In function ?__pyx_tp_clear_6_epoll_epoll?:
twisted/python/_epoll.c:533: attention : unused variable ?p?
twisted/python/_epoll.c: Hors de toute fonction :
twisted/python/_epoll.c:32: attention : ?__Pyx_UnpackItem? declared 
?static? but never defined
twisted/python/_epoll.c:33: attention : ?__Pyx_EndUnpack? declared 
?static? but never defined
twisted/python/_epoll.c:34: attention : ?__Pyx_PrintItem? declared 
?static? but never defined
twisted/python/_epoll.c:35: attention : ?__Pyx_PrintNewline? declared 
?static? but never defined
twisted/python/_epoll.c:37: attention : ?__Pyx_ReRaise? declared 
?static? but never defined
twisted/python/_epoll.c:38: attention : ?__Pyx_Import? declared ?static? 
but never defined
twisted/python/_epoll.c:39: attention : ?__Pyx_GetExcValue? declared 
?static? but never defined
twisted/python/_epoll.c:40: attention : ?__Pyx_ArgTypeTest? declared 
?static? but never defined
twisted/python/_epoll.c:41: attention : ?__Pyx_TypeTest? declared 
?static? but never defined
twisted/python/_epoll.c:42: attention : ?__Pyx_GetStarArgs? declared 
?static? but never defined
twisted/python/_epoll.c:43: attention : ?__Pyx_WriteUnraisable? declared 
?static? but never defined
twisted/python/_epoll.c:45: attention : ?__Pyx_ImportType? declared 
?static? but never defined
twisted/python/_epoll.c:46: attention : ?__Pyx_SetVtable? declared 
?static? but never defined
twisted/python/_epoll.c:47: attention : ?__Pyx_GetVtable? declared 
?static? but never defined
twisted/python/_epoll.c:48: attention : ?__Pyx_CreateClass? declared 
?static? but never defined
twisted/python/_epoll.c:50: attention : ?__Pyx_InitStrings? declared 
?static? but never defined
twisted/python/_epoll.c:51: attention : ?__Pyx_InitCApi? declared 
?static? but never defined
twisted/python/_epoll.c:52: attention : ?__Pyx_ImportModuleCApi? 
declared ?static? but never defined
Adding Twisted 8.1.0 to easy-install.pth file
Installing mailmail script to /usr/bin
Installing cftp script to /usr/bin
Installing tkconch script to /usr/bin
Installing im script to /usr/bin
Installing pyhtmlizer script to /usr/bin
Installing lore script to /usr/bin
Installing tapconvert script to /usr/bin
Installing tap2deb script to /usr/bin
Installing ckeygen script to /usr/bin
Installing t-im script to /usr/bin
Installing twistd script to /usr/bin
Installing trial script to /usr/bin
Installing tap2rpm script to /usr/bin
Installing bookify script to /usr/bin
Installing mktap script to /usr/bin
Installing manhole script to /usr/bin
Installing conch script to /usr/bin

Installed 
/usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
Searching for zope.interface
Reading http://pypi.python.org/simple/zope.interface/
Reading http://zope.org/Wikis/Interfaces/FrontPage
Best match: zope.interface 3.4.1
Downloading 
http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
Processing zope.interface-3.4.1.tar.gz
Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
Traceback (most recent call last):
File "/usr/bin/easy_install", line 8, in <module>
load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')()
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1670, in main
with_ei_usage(lambda:
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1659, in with_ei_usage
return f()
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1674, in <lambda>
distclass=DistributionWithoutHelpCommands, **kw
File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 211, in run
self.easy_install(spec, not self.no_deps)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 446, in easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 473, in install_item
self.process_distribution(spec, dist, deps)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 519, in process_distribution
[requirement], self.local_index, self.easy_install
File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in 
resolve
dist = best[req.key] = env.best_match(req, self, installer)
File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in 
best_match
return self.obtain(req, installer) # try and download/install
File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in 
obtain
return installer(requirement)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 446, in easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 471, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 655, in install_eggs
return self.build_and_install(setup_script, setup_base)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 930, in build_and_install
self.run_setup(setup_script, setup_base, args)
File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 919, in run_setup
run_setup(setup_script, args)
File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27, 
in run_setup
lambda: execfile(
File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63, 
in run
return func()
File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29, 
in <lambda>
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 85, in <module>
File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", 
line 174, in run
cmd = self.call_command('install_lib', warn_dir=0)
File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", 
line 161, in call_command
self.run_command(cmdname)
File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 20, in run
self.build()
File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in 
build
self.run_command('build_ext')
File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", 
line 46, in run
_build_ext.run(self)
File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
self.build_extensions()
File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", 
line 82, in build_extensions
self.build_extension(ext)
File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", 
line 175, in build_extension
_build_ext.build_extension(self,ext)
File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in 
build_extension
sources = self.swig_sources(sources, ext)
File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", 
line 77, in swig_sources
sources = _build_ext.swig_sources(self, sources) or sources
TypeError: swig_sources() takes exactly 3 arguments (2 given)


and that I do not know what to do with it :) Her is what I have for swig:
[root at jarrett ~]# rpm -qa | grep -i swig
swig-1.3.33-1.fc8
[root at jarrett ~]#



From cohen at slac.stanford.edu  Tue Jun 10 14:15:19 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 20:15:19 +0200
Subject: [IPython-dev] feature?
Message-ID: <484EC4B7.6010309@slac.stanford.edu>

More on my issues with current bzr  trunk : I installed sphinx without 
trouble so only Foolscap seems to be a problem. But when I try to build 
ipython again, just for the sake of it, it now outputs :
[cohen at jarrett ipython]$ python setup.py build
============================================================================
BUILDING IPYTHON
                python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)  [GCC
                        4.1.2 20070925 (Red Hat 4.1.2-33)]
              platform: linux2

OPTIONAL DEPENDENCIES
        Zope.Interface: yes
               Twisted: 8.1.0
              Foolscap: 0.2.8
               OpenSSL: 0.6
                sphinx: 0.3
              pygments: 0.10
                  nose: 0.10.0
               pexpect: 2.3
running build
running build_py
package init file 'IPython/config/tests/__init__.py' not found (or not a 
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a 
regular file)
package init file 'IPython/config/tests/__init__.py' not found (or not a 
regular file)
package init file 'IPython/UserConfig/__init__.py' not found (or not a 
regular file)
running build_scripts

Only the Foolscap egg is there, which seems to be enough for ipython at 
this stage. Do we really want that behavior?
best,
Johann


From ellisonbg.net at gmail.com  Tue Jun 10 14:23:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:23:12 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <484EBFDB.3010500@slac.stanford.edu>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
Message-ID: <6ce0ac130806101123q580da9adha3bdbb32042ea11f@mail.gmail.com>

I will fix this ASAP!  Thanks for trying this out!  I run OS X (which
is case insensitive) so this didn't show up for me.

Brian

On Tue, Jun 10, 2008 at 11:54 AM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> Doug,
> replace ipython by IPython in setupbase.py, at the line where ipengine
> is called and the 2 next ones.
> Johann
>
> ipython-dev-request at scipy.org wrote:
>> Send IPython-dev mailing list submissions to
>>       ipython-dev at scipy.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> or, via email, send a message with subject or body 'help' to
>>       ipython-dev-request at scipy.org
>>
>> You can reach the person managing the list at
>>       ipython-dev-owner at scipy.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of IPython-dev digest..."
>>
>> ------------------------------------------------------------------------
>>
>> Today's Topics:
>>
>>    1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones)
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
>> From:
>> "Doug Jones" <dfj225 at gmail.com>
>> Date:
>> Tue, 10 Jun 2008 13:02:12 -0400
>> To:
>> "Brian Granger" <ellisonbg.net at gmail.com>
>>
>> To:
>> "Brian Granger" <ellisonbg.net at gmail.com>
>> CC:
>> IPython Development list <ipython-dev at scipy.net>
>>
>>
>> Hi All,
>>
>> I just gave the newest setup.py a go on my machine and ran into some
>> problems. I've copied its output below. If you need more information,
>> let me know and I will do my best to provide it.
>>
>> Thanks,
>> ~doug
>>
>>
>> python setup.py build
>> ============================================================================
>> BUILDING IPYTHON
>>                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
>>                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>>               platform: linux2
>>
>> OPTIONAL DEPENDENCIES
>>         Zope.Interface: yes
>>                Twisted: 2.5.0
>>               Foolscap: 0.2.8
>>                OpenSSL: Not found (required if you want security in the
>>                         parallel computing capabilities)
>>                 sphinx: 0.3
>>               pygments: 0.10
>>                   nose: 0.9.3
>>                pexpect: 2.1
>> running build
>> running build_py
>> creating build
>> creating build/lib
>> creating build/lib/IPython
>> copying IPython/wildcard.py -> build/lib/IPython
>> copying IPython/deep_reload.py -> build/lib/IPython
>> copying IPython/macro.py -> build/lib/IPython
>> copying IPython/ipapi.py -> build/lib/IPython
>> copying IPython/rlineimpl.py -> build/lib/IPython
>> copying IPython/CrashHandler.py -> build/lib/IPython
>> copying IPython/Shell.py -> build/lib/IPython
>> copying IPython/ultraTB.py -> build/lib/IPython
>> copying IPython/ipmaker.py -> build/lib/IPython
>> copying IPython/upgrade_dir.py -> build/lib/IPython
>> copying IPython/excolors.py -> build/lib/IPython
>> copying IPython/Release.py -> build/lib/IPython
>> copying IPython/demo.py -> build/lib/IPython
>> copying IPython/OutputTrap.py -> build/lib/IPython
>> copying IPython/shadowns.py -> build/lib/IPython
>> copying IPython/__init__.py -> build/lib/IPython
>> copying IPython/ColorANSI.py -> build/lib/IPython
>> copying IPython/platutils_posix.py -> build/lib/IPython
>> copying IPython/strdispatch.py -> build/lib/IPython
>> copying IPython/generics.py -> build/lib/IPython
>> copying IPython/platutils.py -> build/lib/IPython
>> copying IPython/Debugger.py -> build/lib/IPython
>> copying IPython/GnuplotInteractive.py -> build/lib/IPython
>> copying IPython/ipstruct.py -> build/lib/IPython
>> copying IPython/completer.py -> build/lib/IPython
>> copying IPython/FakeModule.py -> build/lib/IPython
>> copying IPython/usage.py -> build/lib/IPython
>> copying IPython/GnuplotRuntime.py -> build/lib/IPython
>> copying IPython/Logger.py -> build/lib/IPython
>> copying IPython/Prompts.py -> build/lib/IPython
>> copying IPython/numutils.py -> build/lib/IPython
>> copying IPython/ConfigLoader.py -> build/lib/IPython
>> copying IPython/platutils_dummy.py -> build/lib/IPython
>> copying IPython/DPyGetOpt.py -> build/lib/IPython
>> copying IPython/platutils_win32.py -> build/lib/IPython
>> copying IPython/background_jobs.py -> build/lib/IPython
>> copying IPython/iplib.py -> build/lib/IPython
>> copying IPython/dtutils.py -> build/lib/IPython
>> copying IPython/prefilter.py -> build/lib/IPython
>> copying IPython/PyColorize.py -> build/lib/IPython
>> copying IPython/twshell.py -> build/lib/IPython
>> copying IPython/history.py -> build/lib/IPython
>> copying IPython/winconsole.py -> build/lib/IPython
>> copying IPython/shellglobals.py -> build/lib/IPython
>> copying IPython/genutils.py -> build/lib/IPython
>> copying IPython/hooks.py -> build/lib/IPython
>> copying IPython/OInspect.py -> build/lib/IPython
>> copying IPython/Magic.py -> build/lib/IPython
>> copying IPython/irunner.py -> build/lib/IPython
>> copying IPython/Gnuplot2.py -> build/lib/IPython
>> copying IPython/Itpl.py -> build/lib/IPython
>> creating build/lib/IPython/config
>> copying IPython/config/api.py -> build/lib/IPython/config
>> copying IPython/config/__init__.py -> build/lib/IPython/config
>> copying IPython/config/cutils.py -> build/lib/IPython/config
>> copying IPython/config/sconfig.py -> build/lib/IPython/config
>> package init file 'IPython/config/tests/__init__.py' not found (or not
>> a regular file)
>> creating build/lib/IPython/config/tests
>> copying IPython/config/tests/simpleconf.py ->
>> build/lib/IPython/config/tests
>> copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
>> creating build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_autoreload.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_rehashdir.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_sh.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/PhysicalQInteractive.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_system_conf.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_doctest.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_gnuglobal.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_traits_completer.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/numeric_formats.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_scipy.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_vimserver.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/InterpreterExec.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/pspersistence.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/PhysicalQInput.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_none.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_greedycompleter.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_numpy.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ext_rescapture.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/InterpreterPasteInput.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_constants.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_stock_completers.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_app_completers.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_completers.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_profile_zope.py ->
>> build/lib/IPython/Extensions
>> copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions
>> copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
>> creating build/lib/IPython/external
>> copying IPython/external/mglob.py -> build/lib/IPython/external
>> copying IPython/external/path.py -> build/lib/IPython/external
>> copying IPython/external/__init__.py -> build/lib/IPython/external
>> copying IPython/external/simplegeneric.py -> build/lib/IPython/external
>> copying IPython/external/validate.py -> build/lib/IPython/external
>> copying IPython/external/configobj.py -> build/lib/IPython/external
>> copying IPython/external/guid.py -> build/lib/IPython/external
>> copying IPython/external/Itpl.py -> build/lib/IPython/external
>> creating build/lib/IPython/gui
>> copying IPython/gui/__init__.py -> build/lib/IPython/gui
>> creating build/lib/IPython/gui/wx
>> copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx
>> copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
>> copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
>> copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
>> copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
>> copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
>> creating build/lib/IPython/kernel
>> copying IPython/kernel/client.py -> build/lib/IPython/kernel
>> copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
>> copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
>> copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
>> copying IPython/kernel/map.py -> build/lib/IPython/kernel
>> copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
>> copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
>> copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
>> copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
>> copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
>> copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
>> copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
>> copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
>> copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
>> copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
>> copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
>> copying IPython/kernel/magic.py -> build/lib/IPython/kernel
>> copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
>> copying IPython/kernel/util.py -> build/lib/IPython/kernel
>> copying IPython/kernel/task.py -> build/lib/IPython/kernel
>> copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
>> copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
>> copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
>> copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
>> copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
>> copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
>> copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
>> copying IPython/kernel/error.py -> build/lib/IPython/kernel
>> copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
>> creating build/lib/IPython/kernel/config
>> copying IPython/kernel/config/__init__.py ->
>> build/lib/IPython/kernel/config
>> creating build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_multienginefc.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_controllerservice.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_engineservice.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_task.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_pendingdeferred.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/engineservicetest.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_newserialized.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/multienginetest.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_taskfc.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_enginefc.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/test_multiengine.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/controllertest.py ->
>> build/lib/IPython/kernel/tests
>> copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests
>> creating build/lib/IPython/kernel/scripts
>> copying IPython/kernel/scripts/ipcluster.py ->
>> build/lib/IPython/kernel/scripts
>> copying IPython/kernel/scripts/__init__.py ->
>> build/lib/IPython/kernel/scripts
>> copying IPython/kernel/scripts/ipengine.py ->
>> build/lib/IPython/kernel/scripts
>> copying IPython/kernel/scripts/ipcontroller.py ->
>> build/lib/IPython/kernel/scripts
>> creating build/lib/IPython/kernel/core
>> copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/display_formatter.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/message_cache.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/traceback_trap.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/output_trap.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/display_trap.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/interpreter.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/traceback_formatter.py ->
>> build/lib/IPython/kernel/core
>> copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
>> creating build/lib/IPython/kernel/core/config
>> copying IPython/kernel/core/config/__init__.py ->
>> build/lib/IPython/kernel/core/config
>> creating build/lib/IPython/kernel/core/tests
>> copying IPython/kernel/core/tests/test_shell.py ->
>> build/lib/IPython/kernel/core/tests
>> copying IPython/kernel/core/tests/__init__.py ->
>> build/lib/IPython/kernel/core/tests
>> creating build/lib/IPython/testing
>> copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
>> copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
>> copying IPython/testing/__init__.py -> build/lib/IPython/testing
>> copying IPython/testing/parametric.py -> build/lib/IPython/testing
>> copying IPython/testing/util.py -> build/lib/IPython/testing
>> copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
>> copying IPython/testing/tutils.py -> build/lib/IPython/testing
>> copying IPython/testing/tstTEMPLATE_doctest.py ->
>> build/lib/IPython/testing
>> copying IPython/testing/tcommon.py -> build/lib/IPython/testing
>> creating build/lib/IPython/testing/tests
>> copying IPython/testing/tests/__init__.py ->
>> build/lib/IPython/testing/tests
>> copying IPython/testing/tests/test_testutils.py ->
>> build/lib/IPython/testing/tests
>> creating build/lib/IPython/tools
>> copying IPython/tools/__init__.py -> build/lib/IPython/tools
>> copying IPython/tools/utils.py -> build/lib/IPython/tools
>> copying IPython/tools/growl.py -> build/lib/IPython/tools
>> creating build/lib/IPython/tools/tests
>> copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
>> build/lib/IPython/tools/tests
>> copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
>> copying IPython/tools/tests/test_tools_utils.py ->
>> build/lib/IPython/tools/tests
>> copying IPython/tools/tests/tst_tools_utils_doctest.py ->
>> build/lib/IPython/tools/tests
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> creating build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipy_user_conf.py ->
>> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc-physics ->
>> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc-tutorial ->
>> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc-numeric ->
>> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig
>> copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig
>> package init file 'IPython/config/tests/__init__.py' not found (or not
>> a regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> running build_scripts
>> creating build/scripts-2.5
>> error: file 'ipython/kernel/scripts/ipengine' does not exist
>>
>>
>> On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
>> <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
>>
>>     Hello all,
>>
>>     I have just merged the ipython-ipython1a branch into ipython trunk.
>>     This means that most of the stable stuff from ipython1 is now in
>>     IPython.  This includes the following new subpackages:
>>
>>     IPython.kernel
>>     IPython.kernel.core
>>     IPython.config
>>     IPython.tools
>>
>>     The biggest change though is that I have refectored the setup.py
>>     script.  Because these new subpackages have lots of other
>>     dependencies, we needed a nice way of handling these things.  Here is
>>     a skech of how it is being handled:
>>
>>     1.  If setuptools is being used, we declare optional requires for the
>>     additional deps
>>
>>     2.  If setuptools is not being used, we check for the deps manually
>>     and simple tell the user what was found and what is required for what
>>     features.
>>
>>     While this will likely take some find tuning, it is a start.
>>
>>     PLEASE, try out the new setup.py in trunk on various platforms and in
>>     various situations.  We need to test this well as it is a huge change.
>>
>>     But, the bottom line is that IPython trunk now has full parallel
>>     computing capabilities.  I will also announce on IPython-users
>>
>>     Next stop: documentation merge!!!
>>
>>     Cheers,
>>
>>     Brian
>>     _______________________________________________
>>     IPython-dev mailing list
>>     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>>     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Tue Jun 10 14:23:57 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:23:57 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
	<1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>
Message-ID: <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com>

I will fix this as well.  Thanks.

Brian

On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones <dfj225 at gmail.com> wrote:
> Johann,
>
> Thanks, that seemed to have fixed the problem. I still got the following
> warnings, not sure if they impact anything or not.
>
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
>
>
> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>>
>> Doug,
>> replace ipython by IPython in setupbase.py, at the line where ipengine
>> is called and the 2 next ones.
>> Johann
>>
>> ipython-dev-request at scipy.org wrote:
>> > Send IPython-dev mailing list submissions to
>> >       ipython-dev at scipy.org
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> > or, via email, send a message with subject or body 'help' to
>> >       ipython-dev-request at scipy.org
>> >
>> > You can reach the person managing the list at
>> >       ipython-dev-owner at scipy.org
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of IPython-dev digest..."
>> >
>> > ------------------------------------------------------------------------
>> >
>> > Today's Topics:
>> >
>> >    1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones)
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > Subject:
>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
>> > From:
>> > "Doug Jones" <dfj225 at gmail.com>
>> > Date:
>> > Tue, 10 Jun 2008 13:02:12 -0400
>> > To:
>> > "Brian Granger" <ellisonbg.net at gmail.com>
>> >
>> > To:
>> > "Brian Granger" <ellisonbg.net at gmail.com>
>> > CC:
>> > IPython Development list <ipython-dev at scipy.net>
>> >
>> >
>> > Hi All,
>> >
>> > I just gave the newest setup.py a go on my machine and ran into some
>> > problems. I've copied its output below. If you need more information,
>> > let me know and I will do my best to provide it.
>> >
>> > Thanks,
>> > ~doug
>> >
>> >
>> > python setup.py build
>> >
>> > ============================================================================
>> > BUILDING IPYTHON
>> >                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
>> >                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>> >               platform: linux2
>> >
>> > OPTIONAL DEPENDENCIES
>> >         Zope.Interface: yes
>> >                Twisted: 2.5.0
>> >               Foolscap: 0.2.8
>> >                OpenSSL: Not found (required if you want security in the
>> >                         parallel computing capabilities)
>> >                 sphinx: 0.3
>> >               pygments: 0.10
>> >                   nose: 0.9.3
>> >                pexpect: 2.1
>> > running build
>> > running build_py
>> > creating build
>> > creating build/lib
>> > creating build/lib/IPython
>> > copying IPython/wildcard.py -> build/lib/IPython
>> > copying IPython/deep_reload.py -> build/lib/IPython
>> > copying IPython/macro.py -> build/lib/IPython
>> > copying IPython/ipapi.py -> build/lib/IPython
>> > copying IPython/rlineimpl.py -> build/lib/IPython
>> > copying IPython/CrashHandler.py -> build/lib/IPython
>> > copying IPython/Shell.py -> build/lib/IPython
>> > copying IPython/ultraTB.py -> build/lib/IPython
>> > copying IPython/ipmaker.py -> build/lib/IPython
>> > copying IPython/upgrade_dir.py -> build/lib/IPython
>> > copying IPython/excolors.py -> build/lib/IPython
>> > copying IPython/Release.py -> build/lib/IPython
>> > copying IPython/demo.py -> build/lib/IPython
>> > copying IPython/OutputTrap.py -> build/lib/IPython
>> > copying IPython/shadowns.py -> build/lib/IPython
>> > copying IPython/__init__.py -> build/lib/IPython
>> > copying IPython/ColorANSI.py -> build/lib/IPython
>> > copying IPython/platutils_posix.py -> build/lib/IPython
>> > copying IPython/strdispatch.py -> build/lib/IPython
>> > copying IPython/generics.py -> build/lib/IPython
>> > copying IPython/platutils.py -> build/lib/IPython
>> > copying IPython/Debugger.py -> build/lib/IPython
>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython
>> > copying IPython/ipstruct.py -> build/lib/IPython
>> > copying IPython/completer.py -> build/lib/IPython
>> > copying IPython/FakeModule.py -> build/lib/IPython
>> > copying IPython/usage.py -> build/lib/IPython
>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython
>> > copying IPython/Logger.py -> build/lib/IPython
>> > copying IPython/Prompts.py -> build/lib/IPython
>> > copying IPython/numutils.py -> build/lib/IPython
>> > copying IPython/ConfigLoader.py -> build/lib/IPython
>> > copying IPython/platutils_dummy.py -> build/lib/IPython
>> > copying IPython/DPyGetOpt.py -> build/lib/IPython
>> > copying IPython/platutils_win32.py -> build/lib/IPython
>> > copying IPython/background_jobs.py -> build/lib/IPython
>> > copying IPython/iplib.py -> build/lib/IPython
>> > copying IPython/dtutils.py -> build/lib/IPython
>> > copying IPython/prefilter.py -> build/lib/IPython
>> > copying IPython/PyColorize.py -> build/lib/IPython
>> > copying IPython/twshell.py -> build/lib/IPython
>> > copying IPython/history.py -> build/lib/IPython
>> > copying IPython/winconsole.py -> build/lib/IPython
>> > copying IPython/shellglobals.py -> build/lib/IPython
>> > copying IPython/genutils.py -> build/lib/IPython
>> > copying IPython/hooks.py -> build/lib/IPython
>> > copying IPython/OInspect.py -> build/lib/IPython
>> > copying IPython/Magic.py -> build/lib/IPython
>> > copying IPython/irunner.py -> build/lib/IPython
>> > copying IPython/Gnuplot2.py -> build/lib/IPython
>> > copying IPython/Itpl.py -> build/lib/IPython
>> > creating build/lib/IPython/config
>> > copying IPython/config/api.py -> build/lib/IPython/config
>> > copying IPython/config/__init__.py -> build/lib/IPython/config
>> > copying IPython/config/cutils.py -> build/lib/IPython/config
>> > copying IPython/config/sconfig.py -> build/lib/IPython/config
>> > package init file 'IPython/config/tests/__init__.py' not found (or not
>> > a regular file)
>> > creating build/lib/IPython/config/tests
>> > copying IPython/config/tests/simpleconf.py ->
>> > build/lib/IPython/config/tests
>> > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
>> > creating build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_autoreload.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_rehashdir.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_sh.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/pickleshare.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/PhysicalQInteractive.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_system_conf.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_doctest.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_gnuglobal.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_traits_completer.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/numeric_formats.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_scipy.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_lookfor.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_vimserver.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/InterpreterExec.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_exportdb.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_signals.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/pspersistence.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/PhysicalQInput.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_none.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_greedycompleter.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_numpy.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ext_rescapture.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/InterpreterPasteInput.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_constants.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_defaults.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_stock_completers.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_app_completers.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_workdir.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_extutil.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_completers.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_profile_zope.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/ipy_editors.py ->
>> > build/lib/IPython/Extensions
>> > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
>> > creating build/lib/IPython/external
>> > copying IPython/external/mglob.py -> build/lib/IPython/external
>> > copying IPython/external/path.py -> build/lib/IPython/external
>> > copying IPython/external/__init__.py -> build/lib/IPython/external
>> > copying IPython/external/simplegeneric.py -> build/lib/IPython/external
>> > copying IPython/external/validate.py -> build/lib/IPython/external
>> > copying IPython/external/configobj.py -> build/lib/IPython/external
>> > copying IPython/external/guid.py -> build/lib/IPython/external
>> > copying IPython/external/Itpl.py -> build/lib/IPython/external
>> > creating build/lib/IPython/gui
>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui
>> > creating build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/ipshell_nonblocking.py ->
>> > build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
>> > creating build/lib/IPython/kernel
>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel
>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
>> > creating build/lib/IPython/kernel/config
>> > copying IPython/kernel/config/__init__.py ->
>> > build/lib/IPython/kernel/config
>> > creating build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_multienginefc.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_controllerservice.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_engineservice.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_task.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_pendingdeferred.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/engineservicetest.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_newserialized.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/__init__.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/multienginetest.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_taskfc.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_enginefc.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/test_multiengine.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/controllertest.py ->
>> > build/lib/IPython/kernel/tests
>> > copying IPython/kernel/tests/tasktest.py ->
>> > build/lib/IPython/kernel/tests
>> > creating build/lib/IPython/kernel/scripts
>> > copying IPython/kernel/scripts/ipcluster.py ->
>> > build/lib/IPython/kernel/scripts
>> > copying IPython/kernel/scripts/__init__.py ->
>> > build/lib/IPython/kernel/scripts
>> > copying IPython/kernel/scripts/ipengine.py ->
>> > build/lib/IPython/kernel/scripts
>> > copying IPython/kernel/scripts/ipcontroller.py ->
>> > build/lib/IPython/kernel/scripts
>> > creating build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/display_formatter.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/message_cache.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/traceback_trap.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/output_trap.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/display_trap.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/interpreter.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/traceback_formatter.py ->
>> > build/lib/IPython/kernel/core
>> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
>> > creating build/lib/IPython/kernel/core/config
>> > copying IPython/kernel/core/config/__init__.py ->
>> > build/lib/IPython/kernel/core/config
>> > creating build/lib/IPython/kernel/core/tests
>> > copying IPython/kernel/core/tests/test_shell.py ->
>> > build/lib/IPython/kernel/core/tests
>> > copying IPython/kernel/core/tests/__init__.py ->
>> > build/lib/IPython/kernel/core/tests
>> > creating build/lib/IPython/testing
>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing
>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing
>> > copying IPython/testing/util.py -> build/lib/IPython/testing
>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing
>> > copying IPython/testing/tstTEMPLATE_doctest.py ->
>> > build/lib/IPython/testing
>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing
>> > creating build/lib/IPython/testing/tests
>> > copying IPython/testing/tests/__init__.py ->
>> > build/lib/IPython/testing/tests
>> > copying IPython/testing/tests/test_testutils.py ->
>> > build/lib/IPython/testing/tests
>> > creating build/lib/IPython/tools
>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools
>> > copying IPython/tools/utils.py -> build/lib/IPython/tools
>> > copying IPython/tools/growl.py -> build/lib/IPython/tools
>> > creating build/lib/IPython/tools/tests
>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
>> > build/lib/IPython/tools/tests
>> > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
>> > copying IPython/tools/tests/test_tools_utils.py ->
>> > build/lib/IPython/tools/tests
>> > copying IPython/tools/tests/tst_tools_utils_doctest.py ->
>> > build/lib/IPython/tools/tests
>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> > regular file)
>> > creating build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipy_user_conf.py ->
>> > build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc-physics ->
>> > build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc-tutorial ->
>> > build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc-numeric ->
>> > build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc-pysh ->
>> > build/lib/IPython/UserConfig
>> > copying IPython/UserConfig/ipythonrc-math ->
>> > build/lib/IPython/UserConfig
>> > package init file 'IPython/config/tests/__init__.py' not found (or not
>> > a regular file)
>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> > regular file)
>> > running build_scripts
>> > creating build/scripts-2.5
>> > error: file 'ipython/kernel/scripts/ipengine' does not exist
>> >
>> >
>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
>> > <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
>> >
>> >     Hello all,
>> >
>> >     I have just merged the ipython-ipython1a branch into ipython trunk.
>> >     This means that most of the stable stuff from ipython1 is now in
>> >     IPython.  This includes the following new subpackages:
>> >
>> >     IPython.kernel
>> >     IPython.kernel.core
>> >     IPython.config
>> >     IPython.tools
>> >
>> >     The biggest change though is that I have refectored the setup.py
>> >     script.  Because these new subpackages have lots of other
>> >     dependencies, we needed a nice way of handling these things.  Here
>> > is
>> >     a skech of how it is being handled:
>> >
>> >     1.  If setuptools is being used, we declare optional requires for
>> > the
>> >     additional deps
>> >
>> >     2.  If setuptools is not being used, we check for the deps manually
>> >     and simple tell the user what was found and what is required for
>> > what
>> >     features.
>> >
>> >     While this will likely take some find tuning, it is a start.
>> >
>> >     PLEASE, try out the new setup.py in trunk on various platforms and
>> > in
>> >     various situations.  We need to test this well as it is a huge
>> > change.
>> >
>> >     But, the bottom line is that IPython trunk now has full parallel
>> >     computing capabilities.  I will also announce on IPython-users
>> >
>> >     Next stop: documentation merge!!!
>> >
>> >     Cheers,
>> >
>> >     Brian
>> >     _______________________________________________
>> >     IPython-dev mailing list
>> >     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>> >     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>


From ellisonbg.net at gmail.com  Tue Jun 10 14:26:51 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:26:51 -0600
Subject: [IPython-dev] building current bzr trunk :
In-Reply-To: <484EC1CF.90602@slac.stanford.edu>
References: <484EC1CF.90602@slac.stanford.edu>
Message-ID: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>

This issue is in the building of zope.interface, which we have never
had any problems with.  Can you just try the following

easy_install zope.interface



On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> hi there,
> after the modif to setupbase of my earlier post, I get:
> [cohen at jarrett ipython]$ python setup.py build
> ============================================================================
> BUILDING IPYTHON
> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
> 4.1.2 20070925 (Red Hat 4.1.2-33)]
> platform: linux2
>
> OPTIONAL DEPENDENCIES
> Zope.Interface: yes
> Twisted: 2.5.0
> Foolscap: Not found (required for parallel computing
> capabilities)
> OpenSSL: 0.6
> sphinx: Not found (required for building documentation)
> pygments: Not found (required for syntax highlighting
> documentation)
> nose: 0.10.0
> pexpect: 2.3
> running build
> running build_py
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> running build_scripts
>
> So the first thing I want to try then is to get Foolscap.... but:
> [root at jarrett ~]# easy_install Foolscap
> Searching for Foolscap
> Reading http://pypi.python.org/simple/Foolscap/
> Couldn't find index page for 'Foolscap' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading http://pypi.python.org/simple/
> Reading http://pypi.python.org/simple/foolscap/
> Reading http://foolscap.lothar.com/
> Reading http://foolscap.lothar.com/trac
> Best match: foolscap 0.2.8
> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
> Processing foolscap-0.2.8.tar.gz
> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
> zip_safe flag not set; analyzing archive contents...
> Adding foolscap 0.2.8 to easy-install.pth file
> Installing flogtool script to /usr/bin
>
> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
> Processing dependencies for Foolscap
> Searching for twisted>=2.4.0
> Reading http://pypi.python.org/simple/twisted/
> Reading http://pypi.python.org/simple/Twisted/
> Reading http://twistedmatrix.com/
> Reading http://www.twistedmatrix.com
> Reading http://twistedmatrix.com/products/download
> Reading http://twistedmatrix.com/projects/core/
> Best match: Twisted 8.1.0
> Downloading
> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
> Processing Twisted-8.1.0.tar.bz2
> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
> twisted/protocols/_c_urlarg.c: In function 'unquote':
> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing
> argument 2 of 'PycStringIO->cwrite' differ in signedness
> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__':
> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but
> not used
> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait':
> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but
> not used
> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but
> not used
> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll':
> twisted/python/_epoll.c:508: attention : unused variable 'p'
> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll':
> twisted/python/_epoll.c:513: attention : unused variable 'p'
> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll':
> twisted/python/_epoll.c:528: attention : unused variable 'p'
> twisted/python/_epoll.c:527: attention : unused variable 'e'
> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll':
> twisted/python/_epoll.c:533: attention : unused variable 'p'
> twisted/python/_epoll.c: Hors de toute fonction :
> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared
> 'static' but never defined
> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared
> 'static' but never defined
> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared
> 'static' but never defined
> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared
> 'static' but never defined
> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared
> 'static' but never defined
> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static'
> but never defined
> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared
> 'static' but never defined
> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared
> 'static' but never defined
> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared
> 'static' but never defined
> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared
> 'static' but never defined
> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared
> 'static' but never defined
> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared
> 'static' but never defined
> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared
> 'static' but never defined
> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared
> 'static' but never defined
> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared
> 'static' but never defined
> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared
> 'static' but never defined
> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared
> 'static' but never defined
> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi'
> declared 'static' but never defined
> Adding Twisted 8.1.0 to easy-install.pth file
> Installing mailmail script to /usr/bin
> Installing cftp script to /usr/bin
> Installing tkconch script to /usr/bin
> Installing im script to /usr/bin
> Installing pyhtmlizer script to /usr/bin
> Installing lore script to /usr/bin
> Installing tapconvert script to /usr/bin
> Installing tap2deb script to /usr/bin
> Installing ckeygen script to /usr/bin
> Installing t-im script to /usr/bin
> Installing twistd script to /usr/bin
> Installing trial script to /usr/bin
> Installing tap2rpm script to /usr/bin
> Installing bookify script to /usr/bin
> Installing mktap script to /usr/bin
> Installing manhole script to /usr/bin
> Installing conch script to /usr/bin
>
> Installed
> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
> Searching for zope.interface
> Reading http://pypi.python.org/simple/zope.interface/
> Reading http://zope.org/Wikis/Interfaces/FrontPage
> Best match: zope.interface 3.4.1
> Downloading
> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
> Processing zope.interface-3.4.1.tar.gz
> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
> Traceback (most recent call last):
> File "/usr/bin/easy_install", line 8, in <module>
> load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')()
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 1670, in main
> with_ei_usage(lambda:
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 1659, in with_ei_usage
> return f()
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 1674, in <lambda>
> distclass=DistributionWithoutHelpCommands, **kw
> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
> dist.run_commands()
> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
> self.run_command(cmd)
> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
> cmd_obj.run()
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 211, in run
> self.easy_install(spec, not self.no_deps)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 446, in easy_install
> return self.install_item(spec, dist.location, tmpdir, deps)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 473, in install_item
> self.process_distribution(spec, dist, deps)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 519, in process_distribution
> [requirement], self.local_index, self.easy_install
> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in
> resolve
> dist = best[req.key] = env.best_match(req, self, installer)
> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in
> best_match
> return self.obtain(req, installer) # try and download/install
> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in
> obtain
> return installer(requirement)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 446, in easy_install
> return self.install_item(spec, dist.location, tmpdir, deps)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 471, in install_item
> dists = self.install_eggs(spec, download, tmpdir)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 655, in install_eggs
> return self.build_and_install(setup_script, setup_base)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 930, in build_and_install
> self.run_setup(setup_script, setup_base, args)
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
> line 919, in run_setup
> run_setup(setup_script, args)
> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27,
> in run_setup
> lambda: execfile(
> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63,
> in run
> return func()
> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29,
> in <lambda>
> {'__file__':setup_script, '__name__':'__main__'}
> File "setup.py", line 85, in <module>
> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
> dist.run_commands()
> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
> self.run_command(cmd)
> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
> cmd_obj.run()
> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
> line 174, in run
> cmd = self.call_command('install_lib', warn_dir=0)
> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
> line 161, in call_command
> self.run_command(cmdname)
> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
> self.distribution.run_command(command)
> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
> cmd_obj.run()
> File
> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py",
> line 20, in run
> self.build()
> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in
> build
> self.run_command('build_ext')
> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
> self.distribution.run_command(command)
> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
> cmd_obj.run()
> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
> line 46, in run
> _build_ext.run(self)
> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
> self.build_extensions()
> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py",
> line 82, in build_extensions
> self.build_extension(ext)
> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
> line 175, in build_extension
> _build_ext.build_extension(self,ext)
> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in
> build_extension
> sources = self.swig_sources(sources, ext)
> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
> line 77, in swig_sources
> sources = _build_ext.swig_sources(self, sources) or sources
> TypeError: swig_sources() takes exactly 3 arguments (2 given)
>
>
> and that I do not know what to do with it :) Her is what I have for swig:
> [root at jarrett ~]# rpm -qa | grep -i swig
> swig-1.3.33-1.fc8
> [root at jarrett ~]#
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From cohen at slac.stanford.edu  Tue Jun 10 14:30:08 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 20:30:08 +0200
Subject: [IPython-dev] building current bzr trunk :
In-Reply-To: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>
References: <484EC1CF.90602@slac.stanford.edu>
	<6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>
Message-ID: <484EC830.2020309@slac.stanford.edu>

same punishment :

[root at jarrett ~]# easy_install zope.interface
Searching for zope.interface
Reading http://pypi.python.org/simple/zope.interface/
Reading http://zope.org/Wikis/Interfaces/FrontPage
Best match: zope.interface 3.4.1
Downloading 
http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
Processing zope.interface-3.4.1.tar.gz
Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-hfnp7Q/zope.interface-3.4.1/egg-dist-tmp-wxiD_u
Traceback (most recent call last):
  File "/usr/bin/easy_install", line 8, in <module>
    load_entry_point('setuptools==0.6c7', 'console_scripts', 
'easy_install')()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1670, in main
    with_ei_usage(lambda:
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1659, in with_ei_usage
    return f()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1674, in <lambda>
    distclass=DistributionWithoutHelpCommands, **kw
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 211, in run
    self.easy_install(spec, not self.no_deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 471, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 655, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 930, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 919, in run_setup
    run_setup(setup_script, args)
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
27, in run_setup
    lambda: execfile(
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
63, in run
    return func()
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
29, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 85, in <module>
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 
174, in run
    cmd = self.call_command('install_lib', warn_dir=0)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 
161, in call_command
    self.run_command(cmdname)
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 20, in run
    self.build()
  File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, 
in build
    self.run_command('build_ext')
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
46, in run
    _build_ext.run(self)
  File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
    self.build_extensions()
  File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", 
line 82, in build_extensions
    self.build_extension(ext)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
175, in build_extension
    _build_ext.build_extension(self,ext)
  File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in 
build_extension
    sources = self.swig_sources(sources, ext)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
77, in swig_sources
    sources = _build_ext.swig_sources(self, sources) or sources
TypeError: swig_sources() takes exactly 3 arguments (2 given)

Johann

Brian Granger wrote:
> This issue is in the building of zope.interface, which we have never
> had any problems with.  Can you just try the following
>
> easy_install zope.interface
>
>
>
> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>   
>> hi there,
>> after the modif to setupbase of my earlier post, I get:
>> [cohen at jarrett ipython]$ python setup.py build
>> ============================================================================
>> BUILDING IPYTHON
>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
>> 4.1.2 20070925 (Red Hat 4.1.2-33)]
>> platform: linux2
>>
>> OPTIONAL DEPENDENCIES
>> Zope.Interface: yes
>> Twisted: 2.5.0
>> Foolscap: Not found (required for parallel computing
>> capabilities)
>> OpenSSL: 0.6
>> sphinx: Not found (required for building documentation)
>> pygments: Not found (required for syntax highlighting
>> documentation)
>> nose: 0.10.0
>> pexpect: 2.3
>> running build
>> running build_py
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> running build_scripts
>>
>> So the first thing I want to try then is to get Foolscap.... but:
>> [root at jarrett ~]# easy_install Foolscap
>> Searching for Foolscap
>> Reading http://pypi.python.org/simple/Foolscap/
>> Couldn't find index page for 'Foolscap' (maybe misspelled?)
>> Scanning index of all packages (this may take a while)
>> Reading http://pypi.python.org/simple/
>> Reading http://pypi.python.org/simple/foolscap/
>> Reading http://foolscap.lothar.com/
>> Reading http://foolscap.lothar.com/trac
>> Best match: foolscap 0.2.8
>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
>> Processing foolscap-0.2.8.tar.gz
>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
>> zip_safe flag not set; analyzing archive contents...
>> Adding foolscap 0.2.8 to easy-install.pth file
>> Installing flogtool script to /usr/bin
>>
>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
>> Processing dependencies for Foolscap
>> Searching for twisted>=2.4.0
>> Reading http://pypi.python.org/simple/twisted/
>> Reading http://pypi.python.org/simple/Twisted/
>> Reading http://twistedmatrix.com/
>> Reading http://www.twistedmatrix.com
>> Reading http://twistedmatrix.com/products/download
>> Reading http://twistedmatrix.com/projects/core/
>> Best match: Twisted 8.1.0
>> Downloading
>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
>> Processing Twisted-8.1.0.tar.bz2
>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
>> twisted/protocols/_c_urlarg.c: In function 'unquote':
>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__':
>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but
>> not used
>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait':
>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but
>> not used
>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but
>> not used
>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll':
>> twisted/python/_epoll.c:508: attention : unused variable 'p'
>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll':
>> twisted/python/_epoll.c:513: attention : unused variable 'p'
>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll':
>> twisted/python/_epoll.c:528: attention : unused variable 'p'
>> twisted/python/_epoll.c:527: attention : unused variable 'e'
>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll':
>> twisted/python/_epoll.c:533: attention : unused variable 'p'
>> twisted/python/_epoll.c: Hors de toute fonction :
>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static'
>> but never defined
>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi'
>> declared 'static' but never defined
>> Adding Twisted 8.1.0 to easy-install.pth file
>> Installing mailmail script to /usr/bin
>> Installing cftp script to /usr/bin
>> Installing tkconch script to /usr/bin
>> Installing im script to /usr/bin
>> Installing pyhtmlizer script to /usr/bin
>> Installing lore script to /usr/bin
>> Installing tapconvert script to /usr/bin
>> Installing tap2deb script to /usr/bin
>> Installing ckeygen script to /usr/bin
>> Installing t-im script to /usr/bin
>> Installing twistd script to /usr/bin
>> Installing trial script to /usr/bin
>> Installing tap2rpm script to /usr/bin
>> Installing bookify script to /usr/bin
>> Installing mktap script to /usr/bin
>> Installing manhole script to /usr/bin
>> Installing conch script to /usr/bin
>>
>> Installed
>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
>> Searching for zope.interface
>> Reading http://pypi.python.org/simple/zope.interface/
>> Reading http://zope.org/Wikis/Interfaces/FrontPage
>> Best match: zope.interface 3.4.1
>> Downloading
>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
>> Processing zope.interface-3.4.1.tar.gz
>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
>> Traceback (most recent call last):
>> File "/usr/bin/easy_install", line 8, in <module>
>> load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1670, in main
>> with_ei_usage(lambda:
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1659, in with_ei_usage
>> return f()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1674, in <lambda>
>> distclass=DistributionWithoutHelpCommands, **kw
>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>> dist.run_commands()
>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>> self.run_command(cmd)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 211, in run
>> self.easy_install(spec, not self.no_deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 446, in easy_install
>> return self.install_item(spec, dist.location, tmpdir, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 473, in install_item
>> self.process_distribution(spec, dist, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 519, in process_distribution
>> [requirement], self.local_index, self.easy_install
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in
>> resolve
>> dist = best[req.key] = env.best_match(req, self, installer)
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in
>> best_match
>> return self.obtain(req, installer) # try and download/install
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in
>> obtain
>> return installer(requirement)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 446, in easy_install
>> return self.install_item(spec, dist.location, tmpdir, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 471, in install_item
>> dists = self.install_eggs(spec, download, tmpdir)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 655, in install_eggs
>> return self.build_and_install(setup_script, setup_base)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 930, in build_and_install
>> self.run_setup(setup_script, setup_base, args)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 919, in run_setup
>> run_setup(setup_script, args)
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27,
>> in run_setup
>> lambda: execfile(
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63,
>> in run
>> return func()
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29,
>> in <lambda>
>> {'__file__':setup_script, '__name__':'__main__'}
>> File "setup.py", line 85, in <module>
>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>> dist.run_commands()
>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>> self.run_command(cmd)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>> line 174, in run
>> cmd = self.call_command('install_lib', warn_dir=0)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>> line 161, in call_command
>> self.run_command(cmdname)
>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>> self.distribution.run_command(command)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py",
>> line 20, in run
>> self.build()
>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in
>> build
>> self.run_command('build_ext')
>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>> self.distribution.run_command(command)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 46, in run
>> _build_ext.run(self)
>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
>> self.build_extensions()
>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py",
>> line 82, in build_extensions
>> self.build_extension(ext)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 175, in build_extension
>> _build_ext.build_extension(self,ext)
>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in
>> build_extension
>> sources = self.swig_sources(sources, ext)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 77, in swig_sources
>> sources = _build_ext.swig_sources(self, sources) or sources
>> TypeError: swig_sources() takes exactly 3 arguments (2 given)
>>
>>
>> and that I do not know what to do with it :) Her is what I have for swig:
>> [root at jarrett ~]# rpm -qa | grep -i swig
>> swig-1.3.33-1.fc8
>> [root at jarrett ~]#
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>     


From cohen at slac.stanford.edu  Tue Jun 10 14:31:43 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 20:31:43 +0200
Subject: [IPython-dev] building current bzr trunk :
In-Reply-To: <6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>
References: <484EC1CF.90602@slac.stanford.edu>
	<6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>
Message-ID: <484EC88F.6010006@slac.stanford.edu>

note that I have a zope installation seemingly :
[root at jarrett ~]# rpm -qa | grep zope
python-zope-interface-3.0.1-8.fc8
[root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8
erreur: D?pendances requises:
        python-zope-interface est n?cessaire pour (d?j? install?) 
python-twisted-core-2.5.0-2.fc8.i386

Johann

Brian Granger wrote:
> This issue is in the building of zope.interface, which we have never
> had any problems with.  Can you just try the following
>
> easy_install zope.interface
>
>
>
> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>   
>> hi there,
>> after the modif to setupbase of my earlier post, I get:
>> [cohen at jarrett ipython]$ python setup.py build
>> ============================================================================
>> BUILDING IPYTHON
>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
>> 4.1.2 20070925 (Red Hat 4.1.2-33)]
>> platform: linux2
>>
>> OPTIONAL DEPENDENCIES
>> Zope.Interface: yes
>> Twisted: 2.5.0
>> Foolscap: Not found (required for parallel computing
>> capabilities)
>> OpenSSL: 0.6
>> sphinx: Not found (required for building documentation)
>> pygments: Not found (required for syntax highlighting
>> documentation)
>> nose: 0.10.0
>> pexpect: 2.3
>> running build
>> running build_py
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> running build_scripts
>>
>> So the first thing I want to try then is to get Foolscap.... but:
>> [root at jarrett ~]# easy_install Foolscap
>> Searching for Foolscap
>> Reading http://pypi.python.org/simple/Foolscap/
>> Couldn't find index page for 'Foolscap' (maybe misspelled?)
>> Scanning index of all packages (this may take a while)
>> Reading http://pypi.python.org/simple/
>> Reading http://pypi.python.org/simple/foolscap/
>> Reading http://foolscap.lothar.com/
>> Reading http://foolscap.lothar.com/trac
>> Best match: foolscap 0.2.8
>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
>> Processing foolscap-0.2.8.tar.gz
>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
>> zip_safe flag not set; analyzing archive contents...
>> Adding foolscap 0.2.8 to easy-install.pth file
>> Installing flogtool script to /usr/bin
>>
>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
>> Processing dependencies for Foolscap
>> Searching for twisted>=2.4.0
>> Reading http://pypi.python.org/simple/twisted/
>> Reading http://pypi.python.org/simple/Twisted/
>> Reading http://twistedmatrix.com/
>> Reading http://www.twistedmatrix.com
>> Reading http://twistedmatrix.com/products/download
>> Reading http://twistedmatrix.com/projects/core/
>> Best match: Twisted 8.1.0
>> Downloading
>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
>> Processing Twisted-8.1.0.tar.bz2
>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
>> twisted/protocols/_c_urlarg.c: In function 'unquote':
>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing
>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll___dealloc__':
>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but
>> not used
>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait':
>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but
>> not used
>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but
>> not used
>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll':
>> twisted/python/_epoll.c:508: attention : unused variable 'p'
>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll':
>> twisted/python/_epoll.c:513: attention : unused variable 'p'
>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll':
>> twisted/python/_epoll.c:528: attention : unused variable 'p'
>> twisted/python/_epoll.c:527: attention : unused variable 'e'
>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll':
>> twisted/python/_epoll.c:533: attention : unused variable 'p'
>> twisted/python/_epoll.c: Hors de toute fonction :
>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static'
>> but never defined
>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared
>> 'static' but never defined
>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi'
>> declared 'static' but never defined
>> Adding Twisted 8.1.0 to easy-install.pth file
>> Installing mailmail script to /usr/bin
>> Installing cftp script to /usr/bin
>> Installing tkconch script to /usr/bin
>> Installing im script to /usr/bin
>> Installing pyhtmlizer script to /usr/bin
>> Installing lore script to /usr/bin
>> Installing tapconvert script to /usr/bin
>> Installing tap2deb script to /usr/bin
>> Installing ckeygen script to /usr/bin
>> Installing t-im script to /usr/bin
>> Installing twistd script to /usr/bin
>> Installing trial script to /usr/bin
>> Installing tap2rpm script to /usr/bin
>> Installing bookify script to /usr/bin
>> Installing mktap script to /usr/bin
>> Installing manhole script to /usr/bin
>> Installing conch script to /usr/bin
>>
>> Installed
>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
>> Searching for zope.interface
>> Reading http://pypi.python.org/simple/zope.interface/
>> Reading http://zope.org/Wikis/Interfaces/FrontPage
>> Best match: zope.interface 3.4.1
>> Downloading
>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
>> Processing zope.interface-3.4.1.tar.gz
>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
>> Traceback (most recent call last):
>> File "/usr/bin/easy_install", line 8, in <module>
>> load_entry_point('setuptools==0.6c7', 'console_scripts', 'easy_install')()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1670, in main
>> with_ei_usage(lambda:
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1659, in with_ei_usage
>> return f()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 1674, in <lambda>
>> distclass=DistributionWithoutHelpCommands, **kw
>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>> dist.run_commands()
>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>> self.run_command(cmd)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 211, in run
>> self.easy_install(spec, not self.no_deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 446, in easy_install
>> return self.install_item(spec, dist.location, tmpdir, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 473, in install_item
>> self.process_distribution(spec, dist, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 519, in process_distribution
>> [requirement], self.local_index, self.easy_install
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in
>> resolve
>> dist = best[req.key] = env.best_match(req, self, installer)
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in
>> best_match
>> return self.obtain(req, installer) # try and download/install
>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in
>> obtain
>> return installer(requirement)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 446, in easy_install
>> return self.install_item(spec, dist.location, tmpdir, deps)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 471, in install_item
>> dists = self.install_eggs(spec, download, tmpdir)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 655, in install_eggs
>> return self.build_and_install(setup_script, setup_base)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 930, in build_and_install
>> self.run_setup(setup_script, setup_base, args)
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>> line 919, in run_setup
>> run_setup(setup_script, args)
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27,
>> in run_setup
>> lambda: execfile(
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63,
>> in run
>> return func()
>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29,
>> in <lambda>
>> {'__file__':setup_script, '__name__':'__main__'}
>> File "setup.py", line 85, in <module>
>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>> dist.run_commands()
>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>> self.run_command(cmd)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>> line 174, in run
>> cmd = self.call_command('install_lib', warn_dir=0)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>> line 161, in call_command
>> self.run_command(cmdname)
>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>> self.distribution.run_command(command)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File
>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py",
>> line 20, in run
>> self.build()
>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in
>> build
>> self.run_command('build_ext')
>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>> self.distribution.run_command(command)
>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>> cmd_obj.run()
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 46, in run
>> _build_ext.run(self)
>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
>> self.build_extensions()
>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py",
>> line 82, in build_extensions
>> self.build_extension(ext)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 175, in build_extension
>> _build_ext.build_extension(self,ext)
>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in
>> build_extension
>> sources = self.swig_sources(sources, ext)
>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>> line 77, in swig_sources
>> sources = _build_ext.swig_sources(self, sources) or sources
>> TypeError: swig_sources() takes exactly 3 arguments (2 given)
>>
>>
>> and that I do not know what to do with it :) Her is what I have for swig:
>> [root at jarrett ~]# rpm -qa | grep -i swig
>> swig-1.3.33-1.fc8
>> [root at jarrett ~]#
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>     


From ellisonbg.net at gmail.com  Tue Jun 10 14:35:14 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:35:14 -0600
Subject: [IPython-dev] building current bzr trunk :
In-Reply-To: <484EC88F.6010006@slac.stanford.edu>
References: <484EC1CF.90602@slac.stanford.edu>
	<6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>
	<484EC88F.6010006@slac.stanford.edu>
Message-ID: <6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com>

IPython should run fine with these older version of twisted and
zope.interface.  But, I would like to try to understand what the
problem is.  I am going to look at this and get back to you shortly.
Two other questions:

1) What version of setuptools are you running?

2) Can you retry with swig uninstalled?

Thanks



Brian

On Tue, Jun 10, 2008 at 12:31 PM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> note that I have a zope installation seemingly :
> [root at jarrett ~]# rpm -qa | grep zope
> python-zope-interface-3.0.1-8.fc8
> [root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8
> erreur: D?pendances requises:
>       python-zope-interface est n?cessaire pour (d?j? install?)
> python-twisted-core-2.5.0-2.fc8.i386
>
> Johann
>
> Brian Granger wrote:
>>
>> This issue is in the building of zope.interface, which we have never
>> had any problems with.  Can you just try the following
>>
>> easy_install zope.interface
>>
>>
>>
>> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi
>> <cohen at slac.stanford.edu> wrote:
>>
>>>
>>> hi there,
>>> after the modif to setupbase of my earlier post, I get:
>>> [cohen at jarrett ipython]$ python setup.py build
>>>
>>> ============================================================================
>>> BUILDING IPYTHON
>>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
>>> 4.1.2 20070925 (Red Hat 4.1.2-33)]
>>> platform: linux2
>>>
>>> OPTIONAL DEPENDENCIES
>>> Zope.Interface: yes
>>> Twisted: 2.5.0
>>> Foolscap: Not found (required for parallel computing
>>> capabilities)
>>> OpenSSL: 0.6
>>> sphinx: Not found (required for building documentation)
>>> pygments: Not found (required for syntax highlighting
>>> documentation)
>>> nose: 0.10.0
>>> pexpect: 2.3
>>> running build
>>> running build_py
>>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>>> regular file)
>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>> regular file)
>>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>>> regular file)
>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>> regular file)
>>> running build_scripts
>>>
>>> So the first thing I want to try then is to get Foolscap.... but:
>>> [root at jarrett ~]# easy_install Foolscap
>>> Searching for Foolscap
>>> Reading http://pypi.python.org/simple/Foolscap/
>>> Couldn't find index page for 'Foolscap' (maybe misspelled?)
>>> Scanning index of all packages (this may take a while)
>>> Reading http://pypi.python.org/simple/
>>> Reading http://pypi.python.org/simple/foolscap/
>>> Reading http://foolscap.lothar.com/
>>> Reading http://foolscap.lothar.com/trac
>>> Best match: foolscap 0.2.8
>>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
>>> Processing foolscap-0.2.8.tar.gz
>>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir
>>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
>>> zip_safe flag not set; analyzing archive contents...
>>> Adding foolscap 0.2.8 to easy-install.pth file
>>> Installing flogtool script to /usr/bin
>>>
>>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
>>> Processing dependencies for Foolscap
>>> Searching for twisted>=2.4.0
>>> Reading http://pypi.python.org/simple/twisted/
>>> Reading http://pypi.python.org/simple/Twisted/
>>> Reading http://twistedmatrix.com/
>>> Reading http://www.twistedmatrix.com
>>> Reading http://twistedmatrix.com/products/download
>>> Reading http://twistedmatrix.com/projects/core/
>>> Best match: Twisted 8.1.0
>>> Downloading
>>>
>>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
>>> Processing Twisted-8.1.0.tar.bz2
>>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir
>>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
>>> twisted/protocols/_c_urlarg.c: In function 'unquote':
>>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing
>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>> twisted/python/_epoll.c: In function
>>> '__pyx_f_6_epoll_5epoll___dealloc__':
>>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but
>>> not used
>>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait':
>>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but
>>> not used
>>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but
>>> not used
>>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll':
>>> twisted/python/_epoll.c:508: attention : unused variable 'p'
>>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll':
>>> twisted/python/_epoll.c:513: attention : unused variable 'p'
>>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll':
>>> twisted/python/_epoll.c:528: attention : unused variable 'p'
>>> twisted/python/_epoll.c:527: attention : unused variable 'e'
>>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll':
>>> twisted/python/_epoll.c:533: attention : unused variable 'p'
>>> twisted/python/_epoll.c: Hors de toute fonction :
>>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static'
>>> but never defined
>>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared
>>> 'static' but never defined
>>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi'
>>> declared 'static' but never defined
>>> Adding Twisted 8.1.0 to easy-install.pth file
>>> Installing mailmail script to /usr/bin
>>> Installing cftp script to /usr/bin
>>> Installing tkconch script to /usr/bin
>>> Installing im script to /usr/bin
>>> Installing pyhtmlizer script to /usr/bin
>>> Installing lore script to /usr/bin
>>> Installing tapconvert script to /usr/bin
>>> Installing tap2deb script to /usr/bin
>>> Installing ckeygen script to /usr/bin
>>> Installing t-im script to /usr/bin
>>> Installing twistd script to /usr/bin
>>> Installing trial script to /usr/bin
>>> Installing tap2rpm script to /usr/bin
>>> Installing bookify script to /usr/bin
>>> Installing mktap script to /usr/bin
>>> Installing manhole script to /usr/bin
>>> Installing conch script to /usr/bin
>>>
>>> Installed
>>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
>>> Searching for zope.interface
>>> Reading http://pypi.python.org/simple/zope.interface/
>>> Reading http://zope.org/Wikis/Interfaces/FrontPage
>>> Best match: zope.interface 3.4.1
>>> Downloading
>>>
>>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
>>> Processing zope.interface-3.4.1.tar.gz
>>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir
>>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
>>> Traceback (most recent call last):
>>> File "/usr/bin/easy_install", line 8, in <module>
>>> load_entry_point('setuptools==0.6c7', 'console_scripts',
>>> 'easy_install')()
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 1670, in main
>>> with_ei_usage(lambda:
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 1659, in with_ei_usage
>>> return f()
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 1674, in <lambda>
>>> distclass=DistributionWithoutHelpCommands, **kw
>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>>> dist.run_commands()
>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>>> self.run_command(cmd)
>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>> cmd_obj.run()
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 211, in run
>>> self.easy_install(spec, not self.no_deps)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 446, in easy_install
>>> return self.install_item(spec, dist.location, tmpdir, deps)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 473, in install_item
>>> self.process_distribution(spec, dist, deps)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 519, in process_distribution
>>> [requirement], self.local_index, self.easy_install
>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in
>>> resolve
>>> dist = best[req.key] = env.best_match(req, self, installer)
>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in
>>> best_match
>>> return self.obtain(req, installer) # try and download/install
>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in
>>> obtain
>>> return installer(requirement)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 446, in easy_install
>>> return self.install_item(spec, dist.location, tmpdir, deps)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 471, in install_item
>>> dists = self.install_eggs(spec, download, tmpdir)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 655, in install_eggs
>>> return self.build_and_install(setup_script, setup_base)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 930, in build_and_install
>>> self.run_setup(setup_script, setup_base, args)
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>> line 919, in run_setup
>>> run_setup(setup_script, args)
>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27,
>>> in run_setup
>>> lambda: execfile(
>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63,
>>> in run
>>> return func()
>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29,
>>> in <lambda>
>>> {'__file__':setup_script, '__name__':'__main__'}
>>> File "setup.py", line 85, in <module>
>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>>> dist.run_commands()
>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>>> self.run_command(cmd)
>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>> cmd_obj.run()
>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>>> line 174, in run
>>> cmd = self.call_command('install_lib', warn_dir=0)
>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>>> line 161, in call_command
>>> self.run_command(cmdname)
>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>>> self.distribution.run_command(command)
>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>> cmd_obj.run()
>>> File
>>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py",
>>> line 20, in run
>>> self.build()
>>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in
>>> build
>>> self.run_command('build_ext')
>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>>> self.distribution.run_command(command)
>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>> cmd_obj.run()
>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>> line 46, in run
>>> _build_ext.run(self)
>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in
>>> run
>>> self.build_extensions()
>>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py",
>>> line 82, in build_extensions
>>> self.build_extension(ext)
>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>> line 175, in build_extension
>>> _build_ext.build_extension(self,ext)
>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in
>>> build_extension
>>> sources = self.swig_sources(sources, ext)
>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>> line 77, in swig_sources
>>> sources = _build_ext.swig_sources(self, sources) or sources
>>> TypeError: swig_sources() takes exactly 3 arguments (2 given)
>>>
>>>
>>> and that I do not know what to do with it :) Her is what I have for swig:
>>> [root at jarrett ~]# rpm -qa | grep -i swig
>>> swig-1.3.33-1.fc8
>>> [root at jarrett ~]#
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>


From ellisonbg.net at gmail.com  Tue Jun 10 14:37:29 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:37:29 -0600
Subject: [IPython-dev] feature?
In-Reply-To: <484EC4B7.6010309@slac.stanford.edu>
References: <484EC4B7.6010309@slac.stanford.edu>
Message-ID: <6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com>

On Tue, Jun 10, 2008 at 12:15 PM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> More on my issues with current bzr  trunk : I installed sphinx without
> trouble so only Foolscap seems to be a problem. But when I try to build
> ipython again, just for the sake of it, it now outputs :
> [cohen at jarrett ipython]$ python setup.py build
> ============================================================================
> BUILDING IPYTHON
>                python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)  [GCC
>                        4.1.2 20070925 (Red Hat 4.1.2-33)]
>              platform: linux2
>
> OPTIONAL DEPENDENCIES
>        Zope.Interface: yes
>               Twisted: 8.1.0
>              Foolscap: 0.2.8
>               OpenSSL: 0.6
>                sphinx: 0.3
>              pygments: 0.10
>                  nose: 0.10.0
>               pexpect: 2.3
> running build
> running build_py
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> running build_scripts
>
> Only the Foolscap egg is there, which seems to be enough for ipython at
> this stage. Do we really want that behavior?
> best,


I am not sure that I follow you.  The dependency check shows that it
has found acceptable versions of all the dependencies.  Can you just
run:

$ trial IPython

or

nosetests IPython

To run the test suite and see what you get?

Thanks

Brian


From cohen at slac.stanford.edu  Tue Jun 10 14:49:22 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 20:49:22 +0200
Subject: [IPython-dev] building current bzr trunk :
In-Reply-To: <6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com>
References: <484EC1CF.90602@slac.stanford.edu>	
	<6ce0ac130806101126m29130e7fw96488af2b3de5eef@mail.gmail.com>	
	<484EC88F.6010006@slac.stanford.edu>
	<6ce0ac130806101135h5b41a71cm80ac851f834bb0ac@mail.gmail.com>
Message-ID: <484ECCB2.2020703@slac.stanford.edu>



Brian Granger wrote:
> IPython should run fine with these older version of twisted and
> zope.interface.  But, I would like to try to understand what the
> problem is.  I am going to look at this and get back to you shortly.
> Two other questions:
>
> 1) What version of setuptools are you running?
>   
[root at jarrett ~]# rpm -qa | grep setuptools
python-setuptools-0.6c7-2.fc8
python-setuptools-devel-0.6c7-2.fc8

> 2) Can you retry with swig uninstalled?
>
>   
same thing :
[root at jarrett ~]# rpm -qa | grep swig
swig-1.3.33-1.fc8
[root at jarrett ~]# rpm --erase swig-1.3.33-1.fc8
[root at jarrett ~]# easy_install Foolscap
Searching for Foolscap
Best match: foolscap 0.2.8
Processing foolscap-0.2.8-py2.5.egg
foolscap 0.2.8 is already the active version in easy-install.pth
Installing flogtool script to /usr/bin

Using /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
Processing dependencies for Foolscap
Searching for zope.interface
Reading http://pypi.python.org/simple/zope.interface/
Reading http://zope.org/Wikis/Interfaces/FrontPage
Best match: zope.interface 3.4.1
Downloading 
http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
Processing zope.interface-3.4.1.tar.gz
Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-wHIZ1P/zope.interface-3.4.1/egg-dist-tmp-xJAIQI
Traceback (most recent call last):
  File "/usr/bin/easy_install", line 8, in <module>
    load_entry_point('setuptools==0.6c7', 'console_scripts', 
'easy_install')()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1670, in main
    with_ei_usage(lambda:
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1659, in with_ei_usage
    return f()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 1674, in <lambda>
    distclass=DistributionWithoutHelpCommands, **kw
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 211, in run
    self.easy_install(spec, not self.no_deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 476, in install_item
    self.process_distribution(spec, dists[0], deps, "Using")
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 519, in process_distribution
    [requirement], self.local_index, self.easy_install
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in 
resolve
    dist = best[req.key] = env.best_match(req, self, installer)
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in 
best_match
    return self.obtain(req, installer) # try and download/install
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in 
obtain
    return installer(requirement)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 471, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 655, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 930, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 919, in run_setup
    run_setup(setup_script, args)
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
27, in run_setup
    lambda: execfile(
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
63, in run
    return func()
  File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 
29, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 85, in <module>
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 
174, in run
    cmd = self.call_command('install_lib', warn_dir=0)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py", line 
161, in call_command
    self.run_command(cmdname)
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 20, in run
    self.build()
  File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, 
in build
    self.run_command('build_ext')
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
46, in run
    _build_ext.run(self)
  File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in run
    self.build_extensions()
  File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py", 
line 82, in build_extensions
    self.build_extension(ext)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
175, in build_extension
    _build_ext.build_extension(self,ext)
  File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in 
build_extension
    sources = self.swig_sources(sources, ext)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py", line 
77, in swig_sources
    sources = _build_ext.swig_sources(self, sources) or sources
TypeError: swig_sources() takes exactly 3 arguments (2 given)


> Thanks
>
>
>
> Brian
>
> On Tue, Jun 10, 2008 at 12:31 PM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>   
>> note that I have a zope installation seemingly :
>> [root at jarrett ~]# rpm -qa | grep zope
>> python-zope-interface-3.0.1-8.fc8
>> [root at jarrett ~]# rpm --erase python-zope-interface-3.0.1-8.fc8
>> erreur: D?pendances requises:
>>       python-zope-interface est n?cessaire pour (d?j? install?)
>> python-twisted-core-2.5.0-2.fc8.i386
>>
>> Johann
>>
>> Brian Granger wrote:
>>     
>>> This issue is in the building of zope.interface, which we have never
>>> had any problems with.  Can you just try the following
>>>
>>> easy_install zope.interface
>>>
>>>
>>>
>>> On Tue, Jun 10, 2008 at 12:02 PM, Johann Cohen-Tanugi
>>> <cohen at slac.stanford.edu> wrote:
>>>
>>>       
>>>> hi there,
>>>> after the modif to setupbase of my earlier post, I get:
>>>> [cohen at jarrett ipython]$ python setup.py build
>>>>
>>>> ============================================================================
>>>> BUILDING IPYTHON
>>>> python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC
>>>> 4.1.2 20070925 (Red Hat 4.1.2-33)]
>>>> platform: linux2
>>>>
>>>> OPTIONAL DEPENDENCIES
>>>> Zope.Interface: yes
>>>> Twisted: 2.5.0
>>>> Foolscap: Not found (required for parallel computing
>>>> capabilities)
>>>> OpenSSL: 0.6
>>>> sphinx: Not found (required for building documentation)
>>>> pygments: Not found (required for syntax highlighting
>>>> documentation)
>>>> nose: 0.10.0
>>>> pexpect: 2.3
>>>> running build
>>>> running build_py
>>>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>>>> regular file)
>>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>>> regular file)
>>>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>>>> regular file)
>>>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>>> regular file)
>>>> running build_scripts
>>>>
>>>> So the first thing I want to try then is to get Foolscap.... but:
>>>> [root at jarrett ~]# easy_install Foolscap
>>>> Searching for Foolscap
>>>> Reading http://pypi.python.org/simple/Foolscap/
>>>> Couldn't find index page for 'Foolscap' (maybe misspelled?)
>>>> Scanning index of all packages (this may take a while)
>>>> Reading http://pypi.python.org/simple/
>>>> Reading http://pypi.python.org/simple/foolscap/
>>>> Reading http://foolscap.lothar.com/
>>>> Reading http://foolscap.lothar.com/trac
>>>> Best match: foolscap 0.2.8
>>>> Downloading http://foolscap.lothar.com/releases/foolscap-0.2.8.tar.gz
>>>> Processing foolscap-0.2.8.tar.gz
>>>> Running foolscap-0.2.8/setup.py -q bdist_egg --dist-dir
>>>> /tmp/easy_install-QwrLUv/foolscap-0.2.8/egg-dist-tmp-ulrUg8
>>>> zip_safe flag not set; analyzing archive contents...
>>>> Adding foolscap 0.2.8 to easy-install.pth file
>>>> Installing flogtool script to /usr/bin
>>>>
>>>> Installed /usr/lib/python2.5/site-packages/foolscap-0.2.8-py2.5.egg
>>>> Processing dependencies for Foolscap
>>>> Searching for twisted>=2.4.0
>>>> Reading http://pypi.python.org/simple/twisted/
>>>> Reading http://pypi.python.org/simple/Twisted/
>>>> Reading http://twistedmatrix.com/
>>>> Reading http://www.twistedmatrix.com
>>>> Reading http://twistedmatrix.com/products/download
>>>> Reading http://twistedmatrix.com/projects/core/
>>>> Best match: Twisted 8.1.0
>>>> Downloading
>>>>
>>>> http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2#md5=a575f29ead4cc02c54e9061d0e6ac7c3
>>>> Processing Twisted-8.1.0.tar.bz2
>>>> Running Twisted-8.1.0/setup.py -q bdist_egg --dist-dir
>>>> /tmp/easy_install-4PSY8a/Twisted-8.1.0/egg-dist-tmp-RYAHKu
>>>> twisted/protocols/_c_urlarg.c: In function 'unquote':
>>>> twisted/protocols/_c_urlarg.c:65: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:75: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:83: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:85: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:93: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:96: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/protocols/_c_urlarg.c:97: attention : pointer targets in passing
>>>> argument 2 of 'PycStringIO->cwrite' differ in signedness
>>>> twisted/python/_epoll.c: In function
>>>> '__pyx_f_6_epoll_5epoll___dealloc__':
>>>> twisted/python/_epoll.c:168: attention : label '__pyx_L1' defined but
>>>> not used
>>>> twisted/python/_epoll.c: In function '__pyx_f_6_epoll_5epoll_wait':
>>>> twisted/python/_epoll.c:432: attention : label '__pyx_L7' defined but
>>>> not used
>>>> twisted/python/_epoll.c:430: attention : label '__pyx_L6' defined but
>>>> not used
>>>> twisted/python/_epoll.c: In function '__pyx_tp_new_6_epoll_epoll':
>>>> twisted/python/_epoll.c:508: attention : unused variable 'p'
>>>> twisted/python/_epoll.c: In function '__pyx_tp_dealloc_6_epoll_epoll':
>>>> twisted/python/_epoll.c:513: attention : unused variable 'p'
>>>> twisted/python/_epoll.c: In function '__pyx_tp_traverse_6_epoll_epoll':
>>>> twisted/python/_epoll.c:528: attention : unused variable 'p'
>>>> twisted/python/_epoll.c:527: attention : unused variable 'e'
>>>> twisted/python/_epoll.c: In function '__pyx_tp_clear_6_epoll_epoll':
>>>> twisted/python/_epoll.c:533: attention : unused variable 'p'
>>>> twisted/python/_epoll.c: Hors de toute fonction :
>>>> twisted/python/_epoll.c:32: attention : '__Pyx_UnpackItem' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:33: attention : '__Pyx_EndUnpack' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:34: attention : '__Pyx_PrintItem' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:35: attention : '__Pyx_PrintNewline' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:37: attention : '__Pyx_ReRaise' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:38: attention : '__Pyx_Import' declared 'static'
>>>> but never defined
>>>> twisted/python/_epoll.c:39: attention : '__Pyx_GetExcValue' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:40: attention : '__Pyx_ArgTypeTest' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:41: attention : '__Pyx_TypeTest' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:42: attention : '__Pyx_GetStarArgs' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:43: attention : '__Pyx_WriteUnraisable' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:45: attention : '__Pyx_ImportType' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:46: attention : '__Pyx_SetVtable' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:47: attention : '__Pyx_GetVtable' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:48: attention : '__Pyx_CreateClass' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:50: attention : '__Pyx_InitStrings' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:51: attention : '__Pyx_InitCApi' declared
>>>> 'static' but never defined
>>>> twisted/python/_epoll.c:52: attention : '__Pyx_ImportModuleCApi'
>>>> declared 'static' but never defined
>>>> Adding Twisted 8.1.0 to easy-install.pth file
>>>> Installing mailmail script to /usr/bin
>>>> Installing cftp script to /usr/bin
>>>> Installing tkconch script to /usr/bin
>>>> Installing im script to /usr/bin
>>>> Installing pyhtmlizer script to /usr/bin
>>>> Installing lore script to /usr/bin
>>>> Installing tapconvert script to /usr/bin
>>>> Installing tap2deb script to /usr/bin
>>>> Installing ckeygen script to /usr/bin
>>>> Installing t-im script to /usr/bin
>>>> Installing twistd script to /usr/bin
>>>> Installing trial script to /usr/bin
>>>> Installing tap2rpm script to /usr/bin
>>>> Installing bookify script to /usr/bin
>>>> Installing mktap script to /usr/bin
>>>> Installing manhole script to /usr/bin
>>>> Installing conch script to /usr/bin
>>>>
>>>> Installed
>>>> /usr/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-i686.egg
>>>> Searching for zope.interface
>>>> Reading http://pypi.python.org/simple/zope.interface/
>>>> Reading http://zope.org/Wikis/Interfaces/FrontPage
>>>> Best match: zope.interface 3.4.1
>>>> Downloading
>>>>
>>>> http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5=b085f4a774adab688e037ad32fbbf08e
>>>> Processing zope.interface-3.4.1.tar.gz
>>>> Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir
>>>> /tmp/easy_install-15j3pH/zope.interface-3.4.1/egg-dist-tmp--AQrWm
>>>> Traceback (most recent call last):
>>>> File "/usr/bin/easy_install", line 8, in <module>
>>>> load_entry_point('setuptools==0.6c7', 'console_scripts',
>>>> 'easy_install')()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 1670, in main
>>>> with_ei_usage(lambda:
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 1659, in with_ei_usage
>>>> return f()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 1674, in <lambda>
>>>> distclass=DistributionWithoutHelpCommands, **kw
>>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>>>> dist.run_commands()
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>>>> self.run_command(cmd)
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>>> cmd_obj.run()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 211, in run
>>>> self.easy_install(spec, not self.no_deps)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 446, in easy_install
>>>> return self.install_item(spec, dist.location, tmpdir, deps)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 473, in install_item
>>>> self.process_distribution(spec, dist, deps)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 519, in process_distribution
>>>> [requirement], self.local_index, self.easy_install
>>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 522, in
>>>> resolve
>>>> dist = best[req.key] = env.best_match(req, self, installer)
>>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 758, in
>>>> best_match
>>>> return self.obtain(req, installer) # try and download/install
>>>> File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 770, in
>>>> obtain
>>>> return installer(requirement)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 446, in easy_install
>>>> return self.install_item(spec, dist.location, tmpdir, deps)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 471, in install_item
>>>> dists = self.install_eggs(spec, download, tmpdir)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 655, in install_eggs
>>>> return self.build_and_install(setup_script, setup_base)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 930, in build_and_install
>>>> self.run_setup(setup_script, setup_base, args)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py",
>>>> line 919, in run_setup
>>>> run_setup(setup_script, args)
>>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 27,
>>>> in run_setup
>>>> lambda: execfile(
>>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 63,
>>>> in run
>>>> return func()
>>>> File "/usr/lib/python2.5/site-packages/setuptools/sandbox.py", line 29,
>>>> in <lambda>
>>>> {'__file__':setup_script, '__name__':'__main__'}
>>>> File "setup.py", line 85, in <module>
>>>> File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>>>> dist.run_commands()
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>>>> self.run_command(cmd)
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>>> cmd_obj.run()
>>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>>>> line 174, in run
>>>> cmd = self.call_command('install_lib', warn_dir=0)
>>>> File "/usr/lib/python2.5/site-packages/setuptools/command/bdist_egg.py",
>>>> line 161, in call_command
>>>> self.run_command(cmdname)
>>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>>>> self.distribution.run_command(command)
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>>> cmd_obj.run()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py",
>>>> line 20, in run
>>>> self.build()
>>>> File "/usr/lib/python2.5/distutils/command/install_lib.py", line 112, in
>>>> build
>>>> self.run_command('build_ext')
>>>> File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>>>> self.distribution.run_command(command)
>>>> File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>>>> cmd_obj.run()
>>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>>> line 46, in run
>>>> _build_ext.run(self)
>>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 290, in
>>>> run
>>>> self.build_extensions()
>>>> File "/usr/lib/python2.5/site-packages/Pyrex/Distutils/build_ext.py",
>>>> line 82, in build_extensions
>>>> self.build_extension(ext)
>>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>>> line 175, in build_extension
>>>> _build_ext.build_extension(self,ext)
>>>> File "/usr/lib/python2.5/distutils/command/build_ext.py", line 453, in
>>>> build_extension
>>>> sources = self.swig_sources(sources, ext)
>>>> File "/usr/lib/python2.5/site-packages/setuptools/command/build_ext.py",
>>>> line 77, in swig_sources
>>>> sources = _build_ext.swig_sources(self, sources) or sources
>>>> TypeError: swig_sources() takes exactly 3 arguments (2 given)
>>>>
>>>>
>>>> and that I do not know what to do with it :) Her is what I have for swig:
>>>> [root at jarrett ~]# rpm -qa | grep -i swig
>>>> swig-1.3.33-1.fc8
>>>> [root at jarrett ~]#
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>>         


From ellisonbg.net at gmail.com  Tue Jun 10 14:54:11 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:54:11 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com>
References: <6ce0ac130806091310q488c2a84lc70ec368eff4719c@mail.gmail.com>
	<1315be7e0806101002j239706fem68c1142202b4deea@mail.gmail.com>
Message-ID: <6ce0ac130806101154p763fbd2aq2eb72024653c04a1@mail.gmail.com>

This is now fixed in trunk.  Please pull the latest and try again and
let us know how it goes.

Brian

On Tue, Jun 10, 2008 at 11:02 AM, Doug Jones <dfj225 at gmail.com> wrote:
> Hi All,
>
> I just gave the newest setup.py a go on my machine and ran into some
> problems. I've copied its output below. If you need more information, let me
> know and I will do my best to provide it.
>
> Thanks,
> ~doug
>
>
> python setup.py build
> ============================================================================
> BUILDING IPYTHON
>                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
>                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>               platform: linux2
>
> OPTIONAL DEPENDENCIES
>         Zope.Interface: yes
>                Twisted: 2.5.0
>               Foolscap: 0.2.8
>                OpenSSL: Not found (required if you want security in the
>                         parallel computing capabilities)
>                 sphinx: 0.3
>               pygments: 0.10
>                   nose: 0.9.3
>                pexpect: 2.1
> running build
> running build_py
> creating build
> creating build/lib
> creating build/lib/IPython
> copying IPython/wildcard.py -> build/lib/IPython
> copying IPython/deep_reload.py -> build/lib/IPython
> copying IPython/macro.py -> build/lib/IPython
> copying IPython/ipapi.py -> build/lib/IPython
> copying IPython/rlineimpl.py -> build/lib/IPython
> copying IPython/CrashHandler.py -> build/lib/IPython
> copying IPython/Shell.py -> build/lib/IPython
> copying IPython/ultraTB.py -> build/lib/IPython
> copying IPython/ipmaker.py -> build/lib/IPython
> copying IPython/upgrade_dir.py -> build/lib/IPython
> copying IPython/excolors.py -> build/lib/IPython
> copying IPython/Release.py -> build/lib/IPython
> copying IPython/demo.py -> build/lib/IPython
> copying IPython/OutputTrap.py -> build/lib/IPython
> copying IPython/shadowns.py -> build/lib/IPython
> copying IPython/__init__.py -> build/lib/IPython
> copying IPython/ColorANSI.py -> build/lib/IPython
> copying IPython/platutils_posix.py -> build/lib/IPython
> copying IPython/strdispatch.py -> build/lib/IPython
> copying IPython/generics.py -> build/lib/IPython
> copying IPython/platutils.py -> build/lib/IPython
> copying IPython/Debugger.py -> build/lib/IPython
> copying IPython/GnuplotInteractive.py -> build/lib/IPython
> copying IPython/ipstruct.py -> build/lib/IPython
> copying IPython/completer.py -> build/lib/IPython
> copying IPython/FakeModule.py -> build/lib/IPython
> copying IPython/usage.py -> build/lib/IPython
> copying IPython/GnuplotRuntime.py -> build/lib/IPython
> copying IPython/Logger.py -> build/lib/IPython
> copying IPython/Prompts.py -> build/lib/IPython
> copying IPython/numutils.py -> build/lib/IPython
> copying IPython/ConfigLoader.py -> build/lib/IPython
> copying IPython/platutils_dummy.py -> build/lib/IPython
> copying IPython/DPyGetOpt.py -> build/lib/IPython
> copying IPython/platutils_win32.py -> build/lib/IPython
> copying IPython/background_jobs.py -> build/lib/IPython
> copying IPython/iplib.py -> build/lib/IPython
> copying IPython/dtutils.py -> build/lib/IPython
> copying IPython/prefilter.py -> build/lib/IPython
> copying IPython/PyColorize.py -> build/lib/IPython
> copying IPython/twshell.py -> build/lib/IPython
> copying IPython/history.py -> build/lib/IPython
> copying IPython/winconsole.py -> build/lib/IPython
> copying IPython/shellglobals.py -> build/lib/IPython
> copying IPython/genutils.py -> build/lib/IPython
> copying IPython/hooks.py -> build/lib/IPython
> copying IPython/OInspect.py -> build/lib/IPython
> copying IPython/Magic.py -> build/lib/IPython
> copying IPython/irunner.py -> build/lib/IPython
> copying IPython/Gnuplot2.py -> build/lib/IPython
> copying IPython/Itpl.py -> build/lib/IPython
> creating build/lib/IPython/config
> copying IPython/config/api.py -> build/lib/IPython/config
> copying IPython/config/__init__.py -> build/lib/IPython/config
> copying IPython/config/cutils.py -> build/lib/IPython/config
> copying IPython/config/sconfig.py -> build/lib/IPython/config
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> creating build/lib/IPython/config/tests
> copying IPython/config/tests/simpleconf.py -> build/lib/IPython/config/tests
> copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
> creating build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_autoreload.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_rehashdir.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_sh.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/pickleshare.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/PhysicalQInteractive.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_system_conf.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_doctest.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_gnuglobal.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_traits_completer.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/numeric_formats.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_scipy.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_lookfor.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_vimserver.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/InterpreterExec.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_exportdb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_signals.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/pspersistence.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/PhysicalQInput.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_none.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_greedycompleter.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_numpy.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ext_rescapture.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/InterpreterPasteInput.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_constants.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_defaults.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_stock_completers.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_app_completers.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_workdir.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_extutil.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_completers.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_profile_zope.py ->
> build/lib/IPython/Extensions
> copying IPython/Extensions/ipy_editors.py -> build/lib/IPython/Extensions
> copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
> creating build/lib/IPython/external
> copying IPython/external/mglob.py -> build/lib/IPython/external
> copying IPython/external/path.py -> build/lib/IPython/external
> copying IPython/external/__init__.py -> build/lib/IPython/external
> copying IPython/external/simplegeneric.py -> build/lib/IPython/external
> copying IPython/external/validate.py -> build/lib/IPython/external
> copying IPython/external/configobj.py -> build/lib/IPython/external
> copying IPython/external/guid.py -> build/lib/IPython/external
> copying IPython/external/Itpl.py -> build/lib/IPython/external
> creating build/lib/IPython/gui
> copying IPython/gui/__init__.py -> build/lib/IPython/gui
> creating build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipshell_nonblocking.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
> copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
> creating build/lib/IPython/kernel
> copying IPython/kernel/client.py -> build/lib/IPython/kernel
> copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
> copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
> copying IPython/kernel/map.py -> build/lib/IPython/kernel
> copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
> copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
> copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
> copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
> copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
> copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
> copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
> copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
> copying IPython/kernel/magic.py -> build/lib/IPython/kernel
> copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
> copying IPython/kernel/util.py -> build/lib/IPython/kernel
> copying IPython/kernel/task.py -> build/lib/IPython/kernel
> copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
> copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
> copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
> copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
> copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
> copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
> copying IPython/kernel/error.py -> build/lib/IPython/kernel
> copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
> creating build/lib/IPython/kernel/config
> copying IPython/kernel/config/__init__.py -> build/lib/IPython/kernel/config
> creating build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_multienginefc.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_controllerservice.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_engineservice.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_task.py -> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_pendingdeferred.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/engineservicetest.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_newserialized.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/__init__.py -> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/multienginetest.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_taskfc.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_enginefc.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/test_multiengine.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/controllertest.py ->
> build/lib/IPython/kernel/tests
> copying IPython/kernel/tests/tasktest.py -> build/lib/IPython/kernel/tests
> creating build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipcluster.py ->
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/__init__.py ->
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipengine.py ->
> build/lib/IPython/kernel/scripts
> copying IPython/kernel/scripts/ipcontroller.py ->
> build/lib/IPython/kernel/scripts
> creating build/lib/IPython/kernel/core
> copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/display_formatter.py ->
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/message_cache.py ->
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/traceback_trap.py ->
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/output_trap.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/display_trap.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/interpreter.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
> copying IPython/kernel/core/traceback_formatter.py ->
> build/lib/IPython/kernel/core
> copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
> creating build/lib/IPython/kernel/core/config
> copying IPython/kernel/core/config/__init__.py ->
> build/lib/IPython/kernel/core/config
> creating build/lib/IPython/kernel/core/tests
> copying IPython/kernel/core/tests/test_shell.py ->
> build/lib/IPython/kernel/core/tests
> copying IPython/kernel/core/tests/__init__.py ->
> build/lib/IPython/kernel/core/tests
> creating build/lib/IPython/testing
> copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
> copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
> copying IPython/testing/__init__.py -> build/lib/IPython/testing
> copying IPython/testing/parametric.py -> build/lib/IPython/testing
> copying IPython/testing/util.py -> build/lib/IPython/testing
> copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
> copying IPython/testing/tutils.py -> build/lib/IPython/testing
> copying IPython/testing/tstTEMPLATE_doctest.py -> build/lib/IPython/testing
> copying IPython/testing/tcommon.py -> build/lib/IPython/testing
> creating build/lib/IPython/testing/tests
> copying IPython/testing/tests/__init__.py -> build/lib/IPython/testing/tests
> copying IPython/testing/tests/test_testutils.py ->
> build/lib/IPython/testing/tests
> creating build/lib/IPython/tools
> copying IPython/tools/__init__.py -> build/lib/IPython/tools
> copying IPython/tools/utils.py -> build/lib/IPython/tools
> copying IPython/tools/growl.py -> build/lib/IPython/tools
> creating build/lib/IPython/tools/tests
> copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
> build/lib/IPython/tools/tests
> copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
> copying IPython/tools/tests/test_tools_utils.py ->
> build/lib/IPython/tools/tests
> copying IPython/tools/tests/tst_tools_utils_doctest.py ->
> build/lib/IPython/tools/tests
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> creating build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipy_user_conf.py -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-physics -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-tutorial ->
> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-numeric -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-pysh -> build/lib/IPython/UserConfig
> copying IPython/UserConfig/ipythonrc-math -> build/lib/IPython/UserConfig
> package init file 'IPython/config/tests/__init__.py' not found (or not a
> regular file)
> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> regular file)
> running build_scripts
> creating build/scripts-2.5
> error: file 'ipython/kernel/scripts/ipengine' does not exist
>
>
> On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net at gmail.com>
> wrote:
>>
>> Hello all,
>>
>> I have just merged the ipython-ipython1a branch into ipython trunk.
>> This means that most of the stable stuff from ipython1 is now in
>> IPython.  This includes the following new subpackages:
>>
>> IPython.kernel
>> IPython.kernel.core
>> IPython.config
>> IPython.tools
>>
>> The biggest change though is that I have refectored the setup.py
>> script.  Because these new subpackages have lots of other
>> dependencies, we needed a nice way of handling these things.  Here is
>> a skech of how it is being handled:
>>
>> 1.  If setuptools is being used, we declare optional requires for the
>> additional deps
>>
>> 2.  If setuptools is not being used, we check for the deps manually
>> and simple tell the user what was found and what is required for what
>> features.
>>
>> While this will likely take some find tuning, it is a start.
>>
>> PLEASE, try out the new setup.py in trunk on various platforms and in
>> various situations.  We need to test this well as it is a huge change.
>>
>> But, the bottom line is that IPython trunk now has full parallel
>> computing capabilities.  I will also announce on IPython-users
>>
>> Next stop: documentation merge!!!
>>
>> Cheers,
>>
>> Brian
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>


From ellisonbg.net at gmail.com  Tue Jun 10 14:54:52 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 12:54:52 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
	<1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>
	<6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com>
Message-ID: <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com>

This is fixed in trunk.  Please pull the latest and try again.

Cheers,

Brian

On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I will fix this as well.  Thanks.
>
> Brian
>
> On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones <dfj225 at gmail.com> wrote:
>> Johann,
>>
>> Thanks, that seemed to have fixed the problem. I still got the following
>> warnings, not sure if they impact anything or not.
>>
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>>
>>
>> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi
>> <cohen at slac.stanford.edu> wrote:
>>>
>>> Doug,
>>> replace ipython by IPython in setupbase.py, at the line where ipengine
>>> is called and the 2 next ones.
>>> Johann
>>>
>>> ipython-dev-request at scipy.org wrote:
>>> > Send IPython-dev mailing list submissions to
>>> >       ipython-dev at scipy.org
>>> >
>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>> >       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>> > or, via email, send a message with subject or body 'help' to
>>> >       ipython-dev-request at scipy.org
>>> >
>>> > You can reach the person managing the list at
>>> >       ipython-dev-owner at scipy.org
>>> >
>>> > When replying, please edit your Subject line so it is more specific
>>> > than "Re: Contents of IPython-dev digest..."
>>> >
>>> > ------------------------------------------------------------------------
>>> >
>>> > Today's Topics:
>>> >
>>> >    1. Re: First merge of ipython1 -> IPython is completed! (Doug Jones)
>>> >
>>> >
>>> > ------------------------------------------------------------------------
>>> >
>>> > Subject:
>>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
>>> > From:
>>> > "Doug Jones" <dfj225 at gmail.com>
>>> > Date:
>>> > Tue, 10 Jun 2008 13:02:12 -0400
>>> > To:
>>> > "Brian Granger" <ellisonbg.net at gmail.com>
>>> >
>>> > To:
>>> > "Brian Granger" <ellisonbg.net at gmail.com>
>>> > CC:
>>> > IPython Development list <ipython-dev at scipy.net>
>>> >
>>> >
>>> > Hi All,
>>> >
>>> > I just gave the newest setup.py a go on my machine and ran into some
>>> > problems. I've copied its output below. If you need more information,
>>> > let me know and I will do my best to provide it.
>>> >
>>> > Thanks,
>>> > ~doug
>>> >
>>> >
>>> > python setup.py build
>>> >
>>> > ============================================================================
>>> > BUILDING IPYTHON
>>> >                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)  [GCC
>>> >                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>>> >               platform: linux2
>>> >
>>> > OPTIONAL DEPENDENCIES
>>> >         Zope.Interface: yes
>>> >                Twisted: 2.5.0
>>> >               Foolscap: 0.2.8
>>> >                OpenSSL: Not found (required if you want security in the
>>> >                         parallel computing capabilities)
>>> >                 sphinx: 0.3
>>> >               pygments: 0.10
>>> >                   nose: 0.9.3
>>> >                pexpect: 2.1
>>> > running build
>>> > running build_py
>>> > creating build
>>> > creating build/lib
>>> > creating build/lib/IPython
>>> > copying IPython/wildcard.py -> build/lib/IPython
>>> > copying IPython/deep_reload.py -> build/lib/IPython
>>> > copying IPython/macro.py -> build/lib/IPython
>>> > copying IPython/ipapi.py -> build/lib/IPython
>>> > copying IPython/rlineimpl.py -> build/lib/IPython
>>> > copying IPython/CrashHandler.py -> build/lib/IPython
>>> > copying IPython/Shell.py -> build/lib/IPython
>>> > copying IPython/ultraTB.py -> build/lib/IPython
>>> > copying IPython/ipmaker.py -> build/lib/IPython
>>> > copying IPython/upgrade_dir.py -> build/lib/IPython
>>> > copying IPython/excolors.py -> build/lib/IPython
>>> > copying IPython/Release.py -> build/lib/IPython
>>> > copying IPython/demo.py -> build/lib/IPython
>>> > copying IPython/OutputTrap.py -> build/lib/IPython
>>> > copying IPython/shadowns.py -> build/lib/IPython
>>> > copying IPython/__init__.py -> build/lib/IPython
>>> > copying IPython/ColorANSI.py -> build/lib/IPython
>>> > copying IPython/platutils_posix.py -> build/lib/IPython
>>> > copying IPython/strdispatch.py -> build/lib/IPython
>>> > copying IPython/generics.py -> build/lib/IPython
>>> > copying IPython/platutils.py -> build/lib/IPython
>>> > copying IPython/Debugger.py -> build/lib/IPython
>>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython
>>> > copying IPython/ipstruct.py -> build/lib/IPython
>>> > copying IPython/completer.py -> build/lib/IPython
>>> > copying IPython/FakeModule.py -> build/lib/IPython
>>> > copying IPython/usage.py -> build/lib/IPython
>>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython
>>> > copying IPython/Logger.py -> build/lib/IPython
>>> > copying IPython/Prompts.py -> build/lib/IPython
>>> > copying IPython/numutils.py -> build/lib/IPython
>>> > copying IPython/ConfigLoader.py -> build/lib/IPython
>>> > copying IPython/platutils_dummy.py -> build/lib/IPython
>>> > copying IPython/DPyGetOpt.py -> build/lib/IPython
>>> > copying IPython/platutils_win32.py -> build/lib/IPython
>>> > copying IPython/background_jobs.py -> build/lib/IPython
>>> > copying IPython/iplib.py -> build/lib/IPython
>>> > copying IPython/dtutils.py -> build/lib/IPython
>>> > copying IPython/prefilter.py -> build/lib/IPython
>>> > copying IPython/PyColorize.py -> build/lib/IPython
>>> > copying IPython/twshell.py -> build/lib/IPython
>>> > copying IPython/history.py -> build/lib/IPython
>>> > copying IPython/winconsole.py -> build/lib/IPython
>>> > copying IPython/shellglobals.py -> build/lib/IPython
>>> > copying IPython/genutils.py -> build/lib/IPython
>>> > copying IPython/hooks.py -> build/lib/IPython
>>> > copying IPython/OInspect.py -> build/lib/IPython
>>> > copying IPython/Magic.py -> build/lib/IPython
>>> > copying IPython/irunner.py -> build/lib/IPython
>>> > copying IPython/Gnuplot2.py -> build/lib/IPython
>>> > copying IPython/Itpl.py -> build/lib/IPython
>>> > creating build/lib/IPython/config
>>> > copying IPython/config/api.py -> build/lib/IPython/config
>>> > copying IPython/config/__init__.py -> build/lib/IPython/config
>>> > copying IPython/config/cutils.py -> build/lib/IPython/config
>>> > copying IPython/config/sconfig.py -> build/lib/IPython/config
>>> > package init file 'IPython/config/tests/__init__.py' not found (or not
>>> > a regular file)
>>> > creating build/lib/IPython/config/tests
>>> > copying IPython/config/tests/simpleconf.py ->
>>> > build/lib/IPython/config/tests
>>> > copying IPython/config/tests/sctst.py -> build/lib/IPython/config/tests
>>> > creating build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_autoreload.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_rehashdir.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_sh.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/pickleshare.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/PhysicalQInteractive.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_system_conf.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_doctest.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_gnuglobal.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_traits_completer.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/numeric_formats.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_scipy.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_lookfor.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/win32clip.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_pydb.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_legacy.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_render.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/__init__.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_vimserver.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/InterpreterExec.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_exportdb.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_signals.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/pspersistence.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_server.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/PhysicalQInput.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_none.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/clearcmd.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_greedycompleter.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_numpy.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ext_rescapture.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/InterpreterPasteInput.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_winpdb.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_constants.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_defaults.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_kitcfg.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_stock_completers.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_which.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_app_completers.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_workdir.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_fsops.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_extutil.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_completers.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_profile_zope.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/ipy_editors.py ->
>>> > build/lib/IPython/Extensions
>>> > copying IPython/Extensions/envpersist.py -> build/lib/IPython/Extensions
>>> > creating build/lib/IPython/external
>>> > copying IPython/external/mglob.py -> build/lib/IPython/external
>>> > copying IPython/external/path.py -> build/lib/IPython/external
>>> > copying IPython/external/__init__.py -> build/lib/IPython/external
>>> > copying IPython/external/simplegeneric.py -> build/lib/IPython/external
>>> > copying IPython/external/validate.py -> build/lib/IPython/external
>>> > copying IPython/external/configobj.py -> build/lib/IPython/external
>>> > copying IPython/external/guid.py -> build/lib/IPython/external
>>> > copying IPython/external/Itpl.py -> build/lib/IPython/external
>>> > creating build/lib/IPython/gui
>>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui
>>> > creating build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/ipshell_nonblocking.py ->
>>> > build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
>>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
>>> > creating build/lib/IPython/kernel
>>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/clientinterfaces.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/multiengineclient.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/controllerservice.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/parallelfunction.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel
>>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
>>> > creating build/lib/IPython/kernel/config
>>> > copying IPython/kernel/config/__init__.py ->
>>> > build/lib/IPython/kernel/config
>>> > creating build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_multienginefc.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_controllerservice.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_engineservice.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_task.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_pendingdeferred.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/engineservicetest.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_newserialized.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/__init__.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/multienginetest.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_taskfc.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_enginefc.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/test_multiengine.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/controllertest.py ->
>>> > build/lib/IPython/kernel/tests
>>> > copying IPython/kernel/tests/tasktest.py ->
>>> > build/lib/IPython/kernel/tests
>>> > creating build/lib/IPython/kernel/scripts
>>> > copying IPython/kernel/scripts/ipcluster.py ->
>>> > build/lib/IPython/kernel/scripts
>>> > copying IPython/kernel/scripts/__init__.py ->
>>> > build/lib/IPython/kernel/scripts
>>> > copying IPython/kernel/scripts/ipengine.py ->
>>> > build/lib/IPython/kernel/scripts
>>> > copying IPython/kernel/scripts/ipcontroller.py ->
>>> > build/lib/IPython/kernel/scripts
>>> > creating build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/display_formatter.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/message_cache.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/ultraTB.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/__init__.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/traceback_trap.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/prompts.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/output_trap.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/display_trap.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/interpreter.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/history.py -> build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/traceback_formatter.py ->
>>> > build/lib/IPython/kernel/core
>>> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
>>> > creating build/lib/IPython/kernel/core/config
>>> > copying IPython/kernel/core/config/__init__.py ->
>>> > build/lib/IPython/kernel/core/config
>>> > creating build/lib/IPython/kernel/core/tests
>>> > copying IPython/kernel/core/tests/test_shell.py ->
>>> > build/lib/IPython/kernel/core/tests
>>> > copying IPython/kernel/core/tests/__init__.py ->
>>> > build/lib/IPython/kernel/core/tests
>>> > creating build/lib/IPython/testing
>>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
>>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
>>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing
>>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing
>>> > copying IPython/testing/util.py -> build/lib/IPython/testing
>>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
>>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing
>>> > copying IPython/testing/tstTEMPLATE_doctest.py ->
>>> > build/lib/IPython/testing
>>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing
>>> > creating build/lib/IPython/testing/tests
>>> > copying IPython/testing/tests/__init__.py ->
>>> > build/lib/IPython/testing/tests
>>> > copying IPython/testing/tests/test_testutils.py ->
>>> > build/lib/IPython/testing/tests
>>> > creating build/lib/IPython/tools
>>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools
>>> > copying IPython/tools/utils.py -> build/lib/IPython/tools
>>> > copying IPython/tools/growl.py -> build/lib/IPython/tools
>>> > creating build/lib/IPython/tools/tests
>>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
>>> > build/lib/IPython/tools/tests
>>> > copying IPython/tools/tests/__init__.py -> build/lib/IPython/tools/tests
>>> > copying IPython/tools/tests/test_tools_utils.py ->
>>> > build/lib/IPython/tools/tests
>>> > copying IPython/tools/tests/tst_tools_utils_doctest.py ->
>>> > build/lib/IPython/tools/tests
>>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>> > regular file)
>>> > creating build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipy_user_conf.py ->
>>> > build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc-physics ->
>>> > build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc-tutorial ->
>>> > build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc-numeric ->
>>> > build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc-pysh ->
>>> > build/lib/IPython/UserConfig
>>> > copying IPython/UserConfig/ipythonrc-math ->
>>> > build/lib/IPython/UserConfig
>>> > package init file 'IPython/config/tests/__init__.py' not found (or not
>>> > a regular file)
>>> > package init file 'IPython/UserConfig/__init__.py' not found (or not a
>>> > regular file)
>>> > running build_scripts
>>> > creating build/scripts-2.5
>>> > error: file 'ipython/kernel/scripts/ipengine' does not exist
>>> >
>>> >
>>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
>>> > <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
>>> >
>>> >     Hello all,
>>> >
>>> >     I have just merged the ipython-ipython1a branch into ipython trunk.
>>> >     This means that most of the stable stuff from ipython1 is now in
>>> >     IPython.  This includes the following new subpackages:
>>> >
>>> >     IPython.kernel
>>> >     IPython.kernel.core
>>> >     IPython.config
>>> >     IPython.tools
>>> >
>>> >     The biggest change though is that I have refectored the setup.py
>>> >     script.  Because these new subpackages have lots of other
>>> >     dependencies, we needed a nice way of handling these things.  Here
>>> > is
>>> >     a skech of how it is being handled:
>>> >
>>> >     1.  If setuptools is being used, we declare optional requires for
>>> > the
>>> >     additional deps
>>> >
>>> >     2.  If setuptools is not being used, we check for the deps manually
>>> >     and simple tell the user what was found and what is required for
>>> > what
>>> >     features.
>>> >
>>> >     While this will likely take some find tuning, it is a start.
>>> >
>>> >     PLEASE, try out the new setup.py in trunk on various platforms and
>>> > in
>>> >     various situations.  We need to test this well as it is a huge
>>> > change.
>>> >
>>> >     But, the bottom line is that IPython trunk now has full parallel
>>> >     computing capabilities.  I will also announce on IPython-users
>>> >
>>> >     Next stop: documentation merge!!!
>>> >
>>> >     Cheers,
>>> >
>>> >     Brian
>>> >     _______________________________________________
>>> >     IPython-dev mailing list
>>> >     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>>> >     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>> >
>>> >
>>> > ------------------------------------------------------------------------
>>> >
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>> >
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>


From dfj225 at gmail.com  Tue Jun 10 14:57:10 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Tue, 10 Jun 2008 14:57:10 -0400
Subject: [IPython-dev] coercing to Unicode error in IPython.MultiEngineClient
Message-ID: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>

Hi all,

I tried a simple test of the latest IPython branch and the
MultiEngineClient. When I attempted to connect to a running cluster on my
local machine, I got the following error:

 mec = client.MultiEngineClient(('localhost', 10105))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/djones/svn/basin_remote/trunk/scripts/<ipython console> in <module>()

/home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
in get_multiengine_client(furl_or_file)
     67     """
     68     client =
blockingCallFromThread(_client_tub.get_multiengine_client,
---> 69         furl_or_file)
     70     return client.adapt_to_blocking_client()
     71

/home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
in blockingCallFromThread(f, *a, **kw)
     97                 result.raiseException()
     98             except Exception, e:
---> 99                 raise e
    100         return result
    101

TypeError: coercing to Unicode: need string or buffer, tuple found



Thanks,
~Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080610/323bea21/attachment.html>

From dfj225 at gmail.com  Tue Jun 10 14:58:59 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Tue, 10 Jun 2008 14:58:59 -0400
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
	<1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>
	<6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com>
	<6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com>
Message-ID: <1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com>

Done. No errors this time with a 'python setup.py build'.

Thanks,
~doug

On Tue, Jun 10, 2008 at 2:54 PM, Brian Granger <ellisonbg.net at gmail.com>
wrote:

> This is fixed in trunk.  Please pull the latest and try again.
>
> Cheers,
>
> Brian
>
> On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger <ellisonbg.net at gmail.com>
> wrote:
> > I will fix this as well.  Thanks.
> >
> > Brian
> >
> > On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones <dfj225 at gmail.com> wrote:
> >> Johann,
> >>
> >> Thanks, that seemed to have fixed the problem. I still got the following
> >> warnings, not sure if they impact anything or not.
> >>
> >> package init file 'IPython/config/tests/__init__.py' not found (or not a
> >> regular file)
> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> >> regular file)
> >> package init file 'IPython/config/tests/__init__.py' not found (or not a
> >> regular file)
> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a
> >> regular file)
> >>
> >>
> >> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi
> >> <cohen at slac.stanford.edu> wrote:
> >>>
> >>> Doug,
> >>> replace ipython by IPython in setupbase.py, at the line where ipengine
> >>> is called and the 2 next ones.
> >>> Johann
> >>>
> >>> ipython-dev-request at scipy.org wrote:
> >>> > Send IPython-dev mailing list submissions to
> >>> >       ipython-dev at scipy.org
> >>> >
> >>> > To subscribe or unsubscribe via the World Wide Web, visit
> >>> >       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >>> > or, via email, send a message with subject or body 'help' to
> >>> >       ipython-dev-request at scipy.org
> >>> >
> >>> > You can reach the person managing the list at
> >>> >       ipython-dev-owner at scipy.org
> >>> >
> >>> > When replying, please edit your Subject line so it is more specific
> >>> > than "Re: Contents of IPython-dev digest..."
> >>> >
> >>> >
> ------------------------------------------------------------------------
> >>> >
> >>> > Today's Topics:
> >>> >
> >>> >    1. Re: First merge of ipython1 -> IPython is completed! (Doug
> Jones)
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------
> >>> >
> >>> > Subject:
> >>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
> >>> > From:
> >>> > "Doug Jones" <dfj225 at gmail.com>
> >>> > Date:
> >>> > Tue, 10 Jun 2008 13:02:12 -0400
> >>> > To:
> >>> > "Brian Granger" <ellisonbg.net at gmail.com>
> >>> >
> >>> > To:
> >>> > "Brian Granger" <ellisonbg.net at gmail.com>
> >>> > CC:
> >>> > IPython Development list <ipython-dev at scipy.net>
> >>> >
> >>> >
> >>> > Hi All,
> >>> >
> >>> > I just gave the newest setup.py a go on my machine and ran into some
> >>> > problems. I've copied its output below. If you need more information,
> >>> > let me know and I will do my best to provide it.
> >>> >
> >>> > Thanks,
> >>> > ~doug
> >>> >
> >>> >
> >>> > python setup.py build
> >>> >
> >>> >
> ============================================================================
> >>> > BUILDING IPYTHON
> >>> >                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)
>  [GCC
> >>> >                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
> >>> >               platform: linux2
> >>> >
> >>> > OPTIONAL DEPENDENCIES
> >>> >         Zope.Interface: yes
> >>> >                Twisted: 2.5.0
> >>> >               Foolscap: 0.2.8
> >>> >                OpenSSL: Not found (required if you want security in
> the
> >>> >                         parallel computing capabilities)
> >>> >                 sphinx: 0.3
> >>> >               pygments: 0.10
> >>> >                   nose: 0.9.3
> >>> >                pexpect: 2.1
> >>> > running build
> >>> > running build_py
> >>> > creating build
> >>> > creating build/lib
> >>> > creating build/lib/IPython
> >>> > copying IPython/wildcard.py -> build/lib/IPython
> >>> > copying IPython/deep_reload.py -> build/lib/IPython
> >>> > copying IPython/macro.py -> build/lib/IPython
> >>> > copying IPython/ipapi.py -> build/lib/IPython
> >>> > copying IPython/rlineimpl.py -> build/lib/IPython
> >>> > copying IPython/CrashHandler.py -> build/lib/IPython
> >>> > copying IPython/Shell.py -> build/lib/IPython
> >>> > copying IPython/ultraTB.py -> build/lib/IPython
> >>> > copying IPython/ipmaker.py -> build/lib/IPython
> >>> > copying IPython/upgrade_dir.py -> build/lib/IPython
> >>> > copying IPython/excolors.py -> build/lib/IPython
> >>> > copying IPython/Release.py -> build/lib/IPython
> >>> > copying IPython/demo.py -> build/lib/IPython
> >>> > copying IPython/OutputTrap.py -> build/lib/IPython
> >>> > copying IPython/shadowns.py -> build/lib/IPython
> >>> > copying IPython/__init__.py -> build/lib/IPython
> >>> > copying IPython/ColorANSI.py -> build/lib/IPython
> >>> > copying IPython/platutils_posix.py -> build/lib/IPython
> >>> > copying IPython/strdispatch.py -> build/lib/IPython
> >>> > copying IPython/generics.py -> build/lib/IPython
> >>> > copying IPython/platutils.py -> build/lib/IPython
> >>> > copying IPython/Debugger.py -> build/lib/IPython
> >>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython
> >>> > copying IPython/ipstruct.py -> build/lib/IPython
> >>> > copying IPython/completer.py -> build/lib/IPython
> >>> > copying IPython/FakeModule.py -> build/lib/IPython
> >>> > copying IPython/usage.py -> build/lib/IPython
> >>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython
> >>> > copying IPython/Logger.py -> build/lib/IPython
> >>> > copying IPython/Prompts.py -> build/lib/IPython
> >>> > copying IPython/numutils.py -> build/lib/IPython
> >>> > copying IPython/ConfigLoader.py -> build/lib/IPython
> >>> > copying IPython/platutils_dummy.py -> build/lib/IPython
> >>> > copying IPython/DPyGetOpt.py -> build/lib/IPython
> >>> > copying IPython/platutils_win32.py -> build/lib/IPython
> >>> > copying IPython/background_jobs.py -> build/lib/IPython
> >>> > copying IPython/iplib.py -> build/lib/IPython
> >>> > copying IPython/dtutils.py -> build/lib/IPython
> >>> > copying IPython/prefilter.py -> build/lib/IPython
> >>> > copying IPython/PyColorize.py -> build/lib/IPython
> >>> > copying IPython/twshell.py -> build/lib/IPython
> >>> > copying IPython/history.py -> build/lib/IPython
> >>> > copying IPython/winconsole.py -> build/lib/IPython
> >>> > copying IPython/shellglobals.py -> build/lib/IPython
> >>> > copying IPython/genutils.py -> build/lib/IPython
> >>> > copying IPython/hooks.py -> build/lib/IPython
> >>> > copying IPython/OInspect.py -> build/lib/IPython
> >>> > copying IPython/Magic.py -> build/lib/IPython
> >>> > copying IPython/irunner.py -> build/lib/IPython
> >>> > copying IPython/Gnuplot2.py -> build/lib/IPython
> >>> > copying IPython/Itpl.py -> build/lib/IPython
> >>> > creating build/lib/IPython/config
> >>> > copying IPython/config/api.py -> build/lib/IPython/config
> >>> > copying IPython/config/__init__.py -> build/lib/IPython/config
> >>> > copying IPython/config/cutils.py -> build/lib/IPython/config
> >>> > copying IPython/config/sconfig.py -> build/lib/IPython/config
> >>> > package init file 'IPython/config/tests/__init__.py' not found (or
> not
> >>> > a regular file)
> >>> > creating build/lib/IPython/config/tests
> >>> > copying IPython/config/tests/simpleconf.py ->
> >>> > build/lib/IPython/config/tests
> >>> > copying IPython/config/tests/sctst.py ->
> build/lib/IPython/config/tests
> >>> > creating build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_autoreload.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_bzr.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_rehashdir.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_sh.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/pickleshare.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/PhysicalQInteractive.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_system_conf.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_doctest.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_gnuglobal.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_traits_completer.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/numeric_formats.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_scipy.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_leo.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_lookfor.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/win32clip.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_pydb.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_legacy.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_render.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/__init__.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_vimserver.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_jot.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/InterpreterExec.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_exportdb.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_signals.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/pspersistence.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_server.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/PhysicalQInput.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/jobctrl.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_none.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/clearcmd.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_greedycompleter.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_numpy.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ibrowse.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ext_rescapture.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/InterpreterPasteInput.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_winpdb.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_constants.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_defaults.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_kitcfg.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_stock_completers.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_which.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_app_completers.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_workdir.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_fsops.py ->
> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_extutil.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_completers.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_profile_zope.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/ipy_editors.py ->
> >>> > build/lib/IPython/Extensions
> >>> > copying IPython/Extensions/envpersist.py ->
> build/lib/IPython/Extensions
> >>> > creating build/lib/IPython/external
> >>> > copying IPython/external/mglob.py -> build/lib/IPython/external
> >>> > copying IPython/external/path.py -> build/lib/IPython/external
> >>> > copying IPython/external/__init__.py -> build/lib/IPython/external
> >>> > copying IPython/external/simplegeneric.py ->
> build/lib/IPython/external
> >>> > copying IPython/external/validate.py -> build/lib/IPython/external
> >>> > copying IPython/external/configobj.py -> build/lib/IPython/external
> >>> > copying IPython/external/guid.py -> build/lib/IPython/external
> >>> > copying IPython/external/Itpl.py -> build/lib/IPython/external
> >>> > creating build/lib/IPython/gui
> >>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui
> >>> > creating build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/ipshell_nonblocking.py ->
> >>> > build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/ipython_history.py -> build/lib/IPython/gui/wx
> >>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
> >>> > creating build/lib/IPython/kernel
> >>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/clientinterfaces.py ->
> build/lib/IPython/kernel
> >>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/clientconnector.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/multiengineclient.py ->
> build/lib/IPython/kernel
> >>> > copying IPython/kernel/controllerservice.py ->
> build/lib/IPython/kernel
> >>> > copying IPython/kernel/pendingdeferred.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/engineconnector.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/parallelfunction.py ->
> build/lib/IPython/kernel
> >>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel
> >>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
> >>> > creating build/lib/IPython/kernel/config
> >>> > copying IPython/kernel/config/__init__.py ->
> >>> > build/lib/IPython/kernel/config
> >>> > creating build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_multienginefc.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_controllerservice.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_engineservice.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_task.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_pendingdeferred.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/engineservicetest.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_newserialized.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/__init__.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/multienginetest.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_taskfc.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_enginefc.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/test_multiengine.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/controllertest.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > copying IPython/kernel/tests/tasktest.py ->
> >>> > build/lib/IPython/kernel/tests
> >>> > creating build/lib/IPython/kernel/scripts
> >>> > copying IPython/kernel/scripts/ipcluster.py ->
> >>> > build/lib/IPython/kernel/scripts
> >>> > copying IPython/kernel/scripts/__init__.py ->
> >>> > build/lib/IPython/kernel/scripts
> >>> > copying IPython/kernel/scripts/ipengine.py ->
> >>> > build/lib/IPython/kernel/scripts
> >>> > copying IPython/kernel/scripts/ipcontroller.py ->
> >>> > build/lib/IPython/kernel/scripts
> >>> > creating build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/macro.py -> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/display_formatter.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/message_cache.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/ultraTB.py ->
> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/__init__.py ->
> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/magic.py -> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/shell.py -> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/traceback_trap.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/prompts.py ->
> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/output_trap.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/display_trap.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/interpreter.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/history.py ->
> build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/traceback_formatter.py ->
> >>> > build/lib/IPython/kernel/core
> >>> > copying IPython/kernel/core/error.py -> build/lib/IPython/kernel/core
> >>> > creating build/lib/IPython/kernel/core/config
> >>> > copying IPython/kernel/core/config/__init__.py ->
> >>> > build/lib/IPython/kernel/core/config
> >>> > creating build/lib/IPython/kernel/core/tests
> >>> > copying IPython/kernel/core/tests/test_shell.py ->
> >>> > build/lib/IPython/kernel/core/tests
> >>> > copying IPython/kernel/core/tests/__init__.py ->
> >>> > build/lib/IPython/kernel/core/tests
> >>> > creating build/lib/IPython/testing
> >>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/util.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing
> >>> > copying IPython/testing/tstTEMPLATE_doctest.py ->
> >>> > build/lib/IPython/testing
> >>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing
> >>> > creating build/lib/IPython/testing/tests
> >>> > copying IPython/testing/tests/__init__.py ->
> >>> > build/lib/IPython/testing/tests
> >>> > copying IPython/testing/tests/test_testutils.py ->
> >>> > build/lib/IPython/testing/tests
> >>> > creating build/lib/IPython/tools
> >>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools
> >>> > copying IPython/tools/utils.py -> build/lib/IPython/tools
> >>> > copying IPython/tools/growl.py -> build/lib/IPython/tools
> >>> > creating build/lib/IPython/tools/tests
> >>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
> >>> > build/lib/IPython/tools/tests
> >>> > copying IPython/tools/tests/__init__.py ->
> build/lib/IPython/tools/tests
> >>> > copying IPython/tools/tests/test_tools_utils.py ->
> >>> > build/lib/IPython/tools/tests
> >>> > copying IPython/tools/tests/tst_tools_utils_doctest.py ->
> >>> > build/lib/IPython/tools/tests
> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not
> a
> >>> > regular file)
> >>> > creating build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipy_user_conf.py ->
> >>> > build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc-physics ->
> >>> > build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc-tutorial ->
> >>> > build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc-numeric ->
> >>> > build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc-pysh ->
> >>> > build/lib/IPython/UserConfig
> >>> > copying IPython/UserConfig/ipythonrc-math ->
> >>> > build/lib/IPython/UserConfig
> >>> > package init file 'IPython/config/tests/__init__.py' not found (or
> not
> >>> > a regular file)
> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not
> a
> >>> > regular file)
> >>> > running build_scripts
> >>> > creating build/scripts-2.5
> >>> > error: file 'ipython/kernel/scripts/ipengine' does not exist
> >>> >
> >>> >
> >>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
> >>> > <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
> >>> >
> >>> >     Hello all,
> >>> >
> >>> >     I have just merged the ipython-ipython1a branch into ipython
> trunk.
> >>> >     This means that most of the stable stuff from ipython1 is now in
> >>> >     IPython.  This includes the following new subpackages:
> >>> >
> >>> >     IPython.kernel
> >>> >     IPython.kernel.core
> >>> >     IPython.config
> >>> >     IPython.tools
> >>> >
> >>> >     The biggest change though is that I have refectored the setup.py
> >>> >     script.  Because these new subpackages have lots of other
> >>> >     dependencies, we needed a nice way of handling these things.
>  Here
> >>> > is
> >>> >     a skech of how it is being handled:
> >>> >
> >>> >     1.  If setuptools is being used, we declare optional requires for
> >>> > the
> >>> >     additional deps
> >>> >
> >>> >     2.  If setuptools is not being used, we check for the deps
> manually
> >>> >     and simple tell the user what was found and what is required for
> >>> > what
> >>> >     features.
> >>> >
> >>> >     While this will likely take some find tuning, it is a start.
> >>> >
> >>> >     PLEASE, try out the new setup.py in trunk on various platforms
> and
> >>> > in
> >>> >     various situations.  We need to test this well as it is a huge
> >>> > change.
> >>> >
> >>> >     But, the bottom line is that IPython trunk now has full parallel
> >>> >     computing capabilities.  I will also announce on IPython-users
> >>> >
> >>> >     Next stop: documentation merge!!!
> >>> >
> >>> >     Cheers,
> >>> >
> >>> >     Brian
> >>> >     _______________________________________________
> >>> >     IPython-dev mailing list
> >>> >     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
> >>> >     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------
> >>> >
> >>> > _______________________________________________
> >>> > IPython-dev mailing list
> >>> > IPython-dev at scipy.org
> >>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >>> >
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080610/56d6509d/attachment.html>

From ellisonbg.net at gmail.com  Tue Jun 10 15:02:19 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 13:02:19 -0600
Subject: [IPython-dev] First merge of ipython1 -> IPython is completed!
In-Reply-To: <1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com>
References: <mailman.44703.1213117343.27196.ipython-dev@scipy.org>
	<484EBFDB.3010500@slac.stanford.edu>
	<1315be7e0806101101n5407f6a4j33e1ba1860a0bfad@mail.gmail.com>
	<6ce0ac130806101123rb318df7p7fd11e5cbf0995b5@mail.gmail.com>
	<6ce0ac130806101154s2c13831bqf214cc378ea9cfab@mail.gmail.com>
	<1315be7e0806101158y28ab79b0s8df01f75deb8983@mail.gmail.com>
Message-ID: <6ce0ac130806101202l7f019228j4e22b0a5074de0c1@mail.gmail.com>

Great, thanks for testing this.  Please let me know if you have other
questions about the new security stuff.  I am in the process on moving
our docs over to IPython trunk. Until then the docs on how to run
things are a bit minimal.

Cheers,

Brian

On Tue, Jun 10, 2008 at 12:58 PM, Doug Jones <dfj225 at gmail.com> wrote:
> Done. No errors this time with a 'python setup.py build'.
>
> Thanks,
> ~doug
>
> On Tue, Jun 10, 2008 at 2:54 PM, Brian Granger <ellisonbg.net at gmail.com>
> wrote:
>>
>> This is fixed in trunk.  Please pull the latest and try again.
>>
>> Cheers,
>>
>> Brian
>>
>> On Tue, Jun 10, 2008 at 12:23 PM, Brian Granger <ellisonbg.net at gmail.com>
>> wrote:
>> > I will fix this as well.  Thanks.
>> >
>> > Brian
>> >
>> > On Tue, Jun 10, 2008 at 12:01 PM, Doug Jones <dfj225 at gmail.com> wrote:
>> >> Johann,
>> >>
>> >> Thanks, that seemed to have fixed the problem. I still got the
>> >> following
>> >> warnings, not sure if they impact anything or not.
>> >>
>> >> package init file 'IPython/config/tests/__init__.py' not found (or not
>> >> a
>> >> regular file)
>> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> >> regular file)
>> >> package init file 'IPython/config/tests/__init__.py' not found (or not
>> >> a
>> >> regular file)
>> >> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> >> regular file)
>> >>
>> >>
>> >> On Tue, Jun 10, 2008 at 1:54 PM, Johann Cohen-Tanugi
>> >> <cohen at slac.stanford.edu> wrote:
>> >>>
>> >>> Doug,
>> >>> replace ipython by IPython in setupbase.py, at the line where ipengine
>> >>> is called and the 2 next ones.
>> >>> Johann
>> >>>
>> >>> ipython-dev-request at scipy.org wrote:
>> >>> > Send IPython-dev mailing list submissions to
>> >>> >       ipython-dev at scipy.org
>> >>> >
>> >>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >>> >       http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >>> > or, via email, send a message with subject or body 'help' to
>> >>> >       ipython-dev-request at scipy.org
>> >>> >
>> >>> > You can reach the person managing the list at
>> >>> >       ipython-dev-owner at scipy.org
>> >>> >
>> >>> > When replying, please edit your Subject line so it is more specific
>> >>> > than "Re: Contents of IPython-dev digest..."
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------
>> >>> >
>> >>> > Today's Topics:
>> >>> >
>> >>> >    1. Re: First merge of ipython1 -> IPython is completed! (Doug
>> >>> > Jones)
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------
>> >>> >
>> >>> > Subject:
>> >>> > Re: [IPython-dev] First merge of ipython1 -> IPython is completed!
>> >>> > From:
>> >>> > "Doug Jones" <dfj225 at gmail.com>
>> >>> > Date:
>> >>> > Tue, 10 Jun 2008 13:02:12 -0400
>> >>> > To:
>> >>> > "Brian Granger" <ellisonbg.net at gmail.com>
>> >>> >
>> >>> > To:
>> >>> > "Brian Granger" <ellisonbg.net at gmail.com>
>> >>> > CC:
>> >>> > IPython Development list <ipython-dev at scipy.net>
>> >>> >
>> >>> >
>> >>> > Hi All,
>> >>> >
>> >>> > I just gave the newest setup.py a go on my machine and ran into some
>> >>> > problems. I've copied its output below. If you need more
>> >>> > information,
>> >>> > let me know and I will do my best to provide it.
>> >>> >
>> >>> > Thanks,
>> >>> > ~doug
>> >>> >
>> >>> >
>> >>> > python setup.py build
>> >>> >
>> >>> >
>> >>> > ============================================================================
>> >>> > BUILDING IPYTHON
>> >>> >                 python: 2.5.1 (r251:54863, Nov  1 2007, 13:29:57)
>> >>> >  [GCC
>> >>> >                         4.1.2 (Gentoo 4.1.2 p1.0.1)]
>> >>> >               platform: linux2
>> >>> >
>> >>> > OPTIONAL DEPENDENCIES
>> >>> >         Zope.Interface: yes
>> >>> >                Twisted: 2.5.0
>> >>> >               Foolscap: 0.2.8
>> >>> >                OpenSSL: Not found (required if you want security in
>> >>> > the
>> >>> >                         parallel computing capabilities)
>> >>> >                 sphinx: 0.3
>> >>> >               pygments: 0.10
>> >>> >                   nose: 0.9.3
>> >>> >                pexpect: 2.1
>> >>> > running build
>> >>> > running build_py
>> >>> > creating build
>> >>> > creating build/lib
>> >>> > creating build/lib/IPython
>> >>> > copying IPython/wildcard.py -> build/lib/IPython
>> >>> > copying IPython/deep_reload.py -> build/lib/IPython
>> >>> > copying IPython/macro.py -> build/lib/IPython
>> >>> > copying IPython/ipapi.py -> build/lib/IPython
>> >>> > copying IPython/rlineimpl.py -> build/lib/IPython
>> >>> > copying IPython/CrashHandler.py -> build/lib/IPython
>> >>> > copying IPython/Shell.py -> build/lib/IPython
>> >>> > copying IPython/ultraTB.py -> build/lib/IPython
>> >>> > copying IPython/ipmaker.py -> build/lib/IPython
>> >>> > copying IPython/upgrade_dir.py -> build/lib/IPython
>> >>> > copying IPython/excolors.py -> build/lib/IPython
>> >>> > copying IPython/Release.py -> build/lib/IPython
>> >>> > copying IPython/demo.py -> build/lib/IPython
>> >>> > copying IPython/OutputTrap.py -> build/lib/IPython
>> >>> > copying IPython/shadowns.py -> build/lib/IPython
>> >>> > copying IPython/__init__.py -> build/lib/IPython
>> >>> > copying IPython/ColorANSI.py -> build/lib/IPython
>> >>> > copying IPython/platutils_posix.py -> build/lib/IPython
>> >>> > copying IPython/strdispatch.py -> build/lib/IPython
>> >>> > copying IPython/generics.py -> build/lib/IPython
>> >>> > copying IPython/platutils.py -> build/lib/IPython
>> >>> > copying IPython/Debugger.py -> build/lib/IPython
>> >>> > copying IPython/GnuplotInteractive.py -> build/lib/IPython
>> >>> > copying IPython/ipstruct.py -> build/lib/IPython
>> >>> > copying IPython/completer.py -> build/lib/IPython
>> >>> > copying IPython/FakeModule.py -> build/lib/IPython
>> >>> > copying IPython/usage.py -> build/lib/IPython
>> >>> > copying IPython/GnuplotRuntime.py -> build/lib/IPython
>> >>> > copying IPython/Logger.py -> build/lib/IPython
>> >>> > copying IPython/Prompts.py -> build/lib/IPython
>> >>> > copying IPython/numutils.py -> build/lib/IPython
>> >>> > copying IPython/ConfigLoader.py -> build/lib/IPython
>> >>> > copying IPython/platutils_dummy.py -> build/lib/IPython
>> >>> > copying IPython/DPyGetOpt.py -> build/lib/IPython
>> >>> > copying IPython/platutils_win32.py -> build/lib/IPython
>> >>> > copying IPython/background_jobs.py -> build/lib/IPython
>> >>> > copying IPython/iplib.py -> build/lib/IPython
>> >>> > copying IPython/dtutils.py -> build/lib/IPython
>> >>> > copying IPython/prefilter.py -> build/lib/IPython
>> >>> > copying IPython/PyColorize.py -> build/lib/IPython
>> >>> > copying IPython/twshell.py -> build/lib/IPython
>> >>> > copying IPython/history.py -> build/lib/IPython
>> >>> > copying IPython/winconsole.py -> build/lib/IPython
>> >>> > copying IPython/shellglobals.py -> build/lib/IPython
>> >>> > copying IPython/genutils.py -> build/lib/IPython
>> >>> > copying IPython/hooks.py -> build/lib/IPython
>> >>> > copying IPython/OInspect.py -> build/lib/IPython
>> >>> > copying IPython/Magic.py -> build/lib/IPython
>> >>> > copying IPython/irunner.py -> build/lib/IPython
>> >>> > copying IPython/Gnuplot2.py -> build/lib/IPython
>> >>> > copying IPython/Itpl.py -> build/lib/IPython
>> >>> > creating build/lib/IPython/config
>> >>> > copying IPython/config/api.py -> build/lib/IPython/config
>> >>> > copying IPython/config/__init__.py -> build/lib/IPython/config
>> >>> > copying IPython/config/cutils.py -> build/lib/IPython/config
>> >>> > copying IPython/config/sconfig.py -> build/lib/IPython/config
>> >>> > package init file 'IPython/config/tests/__init__.py' not found (or
>> >>> > not
>> >>> > a regular file)
>> >>> > creating build/lib/IPython/config/tests
>> >>> > copying IPython/config/tests/simpleconf.py ->
>> >>> > build/lib/IPython/config/tests
>> >>> > copying IPython/config/tests/sctst.py ->
>> >>> > build/lib/IPython/config/tests
>> >>> > creating build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_autoreload.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_bzr.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_rehashdir.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_sh.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/pickleshare.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/PhysicalQInteractive.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/astyle.py -> build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_system_conf.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_doctest.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_gnuglobal.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_traits_completer.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/numeric_formats.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_scipy.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_leo.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_lookfor.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/win32clip.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_pydb.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_legacy.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_render.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/__init__.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_vimserver.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_jot.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/InterpreterExec.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_exportdb.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipipe.py -> build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_signals.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/pspersistence.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_server.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/PhysicalQInput.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/jobctrl.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_none.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/clearcmd.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_greedycompleter.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_numpy.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ibrowse.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ext_rescapture.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/InterpreterPasteInput.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ledit.py -> build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_winpdb.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_constants.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/igrid.py -> build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_defaults.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_kitcfg.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_stock_completers.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_which.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_app_completers.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_workdir.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_fsops.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_extutil.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_completers.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_p4.py -> build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_profile_zope.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/ipy_editors.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > copying IPython/Extensions/envpersist.py ->
>> >>> > build/lib/IPython/Extensions
>> >>> > creating build/lib/IPython/external
>> >>> > copying IPython/external/mglob.py -> build/lib/IPython/external
>> >>> > copying IPython/external/path.py -> build/lib/IPython/external
>> >>> > copying IPython/external/__init__.py -> build/lib/IPython/external
>> >>> > copying IPython/external/simplegeneric.py ->
>> >>> > build/lib/IPython/external
>> >>> > copying IPython/external/validate.py -> build/lib/IPython/external
>> >>> > copying IPython/external/configobj.py -> build/lib/IPython/external
>> >>> > copying IPython/external/guid.py -> build/lib/IPython/external
>> >>> > copying IPython/external/Itpl.py -> build/lib/IPython/external
>> >>> > creating build/lib/IPython/gui
>> >>> > copying IPython/gui/__init__.py -> build/lib/IPython/gui
>> >>> > creating build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/ipshell_nonblocking.py ->
>> >>> > build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/thread_ex.py -> build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/__init__.py -> build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/wxIPython.py -> build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/ipython_history.py ->
>> >>> > build/lib/IPython/gui/wx
>> >>> > copying IPython/gui/wx/ipython_view.py -> build/lib/IPython/gui/wx
>> >>> > creating build/lib/IPython/kernel
>> >>> > copying IPython/kernel/client.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/multienginefc.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/codeutil.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/engineservice.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/map.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/clientinterfaces.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/taskfc.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/pickleutil.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/contexts.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/taskclient.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/multiengine.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/__init__.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/clientconnector.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/multiengineclient.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/controllerservice.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/pendingdeferred.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/magic.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/engineconnector.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/util.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/task.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/pbconfig.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/parallelfunction.py ->
>> >>> > build/lib/IPython/kernel
>> >>> > copying IPython/kernel/enginefc.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/newserialized.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/asyncclient.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/twistedutil.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/pbutil.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/error.py -> build/lib/IPython/kernel
>> >>> > copying IPython/kernel/fcutil.py -> build/lib/IPython/kernel
>> >>> > creating build/lib/IPython/kernel/config
>> >>> > copying IPython/kernel/config/__init__.py ->
>> >>> > build/lib/IPython/kernel/config
>> >>> > creating build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_multienginefc.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_controllerservice.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_engineservice.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_task.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_pendingdeferred.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/engineservicetest.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_newserialized.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/__init__.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/multienginetest.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_taskfc.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_enginefc.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/test_multiengine.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/controllertest.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > copying IPython/kernel/tests/tasktest.py ->
>> >>> > build/lib/IPython/kernel/tests
>> >>> > creating build/lib/IPython/kernel/scripts
>> >>> > copying IPython/kernel/scripts/ipcluster.py ->
>> >>> > build/lib/IPython/kernel/scripts
>> >>> > copying IPython/kernel/scripts/__init__.py ->
>> >>> > build/lib/IPython/kernel/scripts
>> >>> > copying IPython/kernel/scripts/ipengine.py ->
>> >>> > build/lib/IPython/kernel/scripts
>> >>> > copying IPython/kernel/scripts/ipcontroller.py ->
>> >>> > build/lib/IPython/kernel/scripts
>> >>> > creating build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/macro.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/display_formatter.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/message_cache.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/ultraTB.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/__init__.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/magic.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/shell.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/traceback_trap.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/util.py -> build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/prompts.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/output_trap.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/display_trap.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/interpreter.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/history.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/traceback_formatter.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > copying IPython/kernel/core/error.py ->
>> >>> > build/lib/IPython/kernel/core
>> >>> > creating build/lib/IPython/kernel/core/config
>> >>> > copying IPython/kernel/core/config/__init__.py ->
>> >>> > build/lib/IPython/kernel/core/config
>> >>> > creating build/lib/IPython/kernel/core/tests
>> >>> > copying IPython/kernel/core/tests/test_shell.py ->
>> >>> > build/lib/IPython/kernel/core/tests
>> >>> > copying IPython/kernel/core/tests/__init__.py ->
>> >>> > build/lib/IPython/kernel/core/tests
>> >>> > creating build/lib/IPython/testing
>> >>> > copying IPython/testing/ipdoctest.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/testTEMPLATE.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/__init__.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/parametric.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/util.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/mkdoctests.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/tutils.py -> build/lib/IPython/testing
>> >>> > copying IPython/testing/tstTEMPLATE_doctest.py ->
>> >>> > build/lib/IPython/testing
>> >>> > copying IPython/testing/tcommon.py -> build/lib/IPython/testing
>> >>> > creating build/lib/IPython/testing/tests
>> >>> > copying IPython/testing/tests/__init__.py ->
>> >>> > build/lib/IPython/testing/tests
>> >>> > copying IPython/testing/tests/test_testutils.py ->
>> >>> > build/lib/IPython/testing/tests
>> >>> > creating build/lib/IPython/tools
>> >>> > copying IPython/tools/__init__.py -> build/lib/IPython/tools
>> >>> > copying IPython/tools/utils.py -> build/lib/IPython/tools
>> >>> > copying IPython/tools/growl.py -> build/lib/IPython/tools
>> >>> > creating build/lib/IPython/tools/tests
>> >>> > copying IPython/tools/tests/tst_tools_utils_doctest2.py ->
>> >>> > build/lib/IPython/tools/tests
>> >>> > copying IPython/tools/tests/__init__.py ->
>> >>> > build/lib/IPython/tools/tests
>> >>> > copying IPython/tools/tests/test_tools_utils.py ->
>> >>> > build/lib/IPython/tools/tests
>> >>> > copying IPython/tools/tests/tst_tools_utils_doctest.py ->
>> >>> > build/lib/IPython/tools/tests
>> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not
>> >>> > a
>> >>> > regular file)
>> >>> > creating build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipy_user_conf.py ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc-physics ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc -> build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc-tutorial ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc-numeric ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc-pysh ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > copying IPython/UserConfig/ipythonrc-math ->
>> >>> > build/lib/IPython/UserConfig
>> >>> > package init file 'IPython/config/tests/__init__.py' not found (or
>> >>> > not
>> >>> > a regular file)
>> >>> > package init file 'IPython/UserConfig/__init__.py' not found (or not
>> >>> > a
>> >>> > regular file)
>> >>> > running build_scripts
>> >>> > creating build/scripts-2.5
>> >>> > error: file 'ipython/kernel/scripts/ipengine' does not exist
>> >>> >
>> >>> >
>> >>> > On Mon, Jun 9, 2008 at 4:10 PM, Brian Granger <ellisonbg.net
>> >>> > <http://ellisonbg.net>@gmail.com <http://gmail.com>> wrote:
>> >>> >
>> >>> >     Hello all,
>> >>> >
>> >>> >     I have just merged the ipython-ipython1a branch into ipython
>> >>> > trunk.
>> >>> >     This means that most of the stable stuff from ipython1 is now in
>> >>> >     IPython.  This includes the following new subpackages:
>> >>> >
>> >>> >     IPython.kernel
>> >>> >     IPython.kernel.core
>> >>> >     IPython.config
>> >>> >     IPython.tools
>> >>> >
>> >>> >     The biggest change though is that I have refectored the setup.py
>> >>> >     script.  Because these new subpackages have lots of other
>> >>> >     dependencies, we needed a nice way of handling these things.
>> >>> >  Here
>> >>> > is
>> >>> >     a skech of how it is being handled:
>> >>> >
>> >>> >     1.  If setuptools is being used, we declare optional requires
>> >>> > for
>> >>> > the
>> >>> >     additional deps
>> >>> >
>> >>> >     2.  If setuptools is not being used, we check for the deps
>> >>> > manually
>> >>> >     and simple tell the user what was found and what is required for
>> >>> > what
>> >>> >     features.
>> >>> >
>> >>> >     While this will likely take some find tuning, it is a start.
>> >>> >
>> >>> >     PLEASE, try out the new setup.py in trunk on various platforms
>> >>> > and
>> >>> > in
>> >>> >     various situations.  We need to test this well as it is a huge
>> >>> > change.
>> >>> >
>> >>> >     But, the bottom line is that IPython trunk now has full parallel
>> >>> >     computing capabilities.  I will also announce on IPython-users
>> >>> >
>> >>> >     Next stop: documentation merge!!!
>> >>> >
>> >>> >     Cheers,
>> >>> >
>> >>> >     Brian
>> >>> >     _______________________________________________
>> >>> >     IPython-dev mailing list
>> >>> >     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>> >>> >     http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------
>> >>> >
>> >>> > _______________________________________________
>> >>> > IPython-dev mailing list
>> >>> > IPython-dev at scipy.org
>> >>> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >>> >
>> >>> _______________________________________________
>> >>> IPython-dev mailing list
>> >>> IPython-dev at scipy.org
>> >>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >
>
>


From ellisonbg.net at gmail.com  Tue Jun 10 15:55:57 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 10 Jun 2008 13:55:57 -0600
Subject: [IPython-dev] coercing to Unicode error in
	IPython.MultiEngineClient
In-Reply-To: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
Message-ID: <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>

This is not a unicode error, but rather, our API for starting the
client has changed due to the new security stuff.  This is the stuff
that I am working on documenting as we speak.

Here is a minimal description:

1) When the controller now starts, it creates a set of files (in your
.ipython directory by default)

ipcontroller-tc.furl
ipcontroller-mec.furl
ipcontroller-engine.furl

2)  These files contain a secure URL that 1) tells the engine and
clients where the controller is running and 2) gives the engine and
clients authority to connect to the controller in a secure manner.

3) To use these files, they have to be available to the client and
engines when they start.  The easiest way of handling this is to

a) copy ipcontroller-engine.furl to the .ipython directory on the
machine(s) where the engines will run

b) copy ipcontroller-tc and -mec to the .ipython dir of the machine
where the clients will run.

Then everything will "just work".  By this, I mean that you can create
the clients with no arguments:

mec = client.MultiEngineClient()

If you have put the .furl files in different locations you can do:

mec = client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')

In all of this, you can think of the furl files as being keys (just
like a house key) that grants an entity access to a particular
resource.  The controller creates the keys and the engines/client must
present/use them to use the capabilities of the controller.

See if you can use this to get things working.  The big benefit of
using all this is:

1) Users don't have to track what ip/port the controller is running on.

2) Everything is secure by default - authentication + encryption (if
you have pyOpenSSL installed

3) The controller now uses random port numbers, making it even more
difficult for hostiles to discover.

Let me know if you have any more problems getting this working.  We
would love feedback if you have ideas of how things could be made
easier.

Also, check out the new command line flags on the ipcontroller and
ipengine scripts to control where the furl files are created and
looked for.

Cheers,

Brian

On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com> wrote:
> Hi all,
>
> I tried a simple test of the latest IPython branch and the
> MultiEngineClient. When I attempted to connect to a running cluster on my
> local machine, I got the following error:
>
>  mec = client.MultiEngineClient(('localhost', 10105))
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)
>
> /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in <module>()
>
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
> in get_multiengine_client(furl_or_file)
>      67     """
>      68     client =
> blockingCallFromThread(_client_tub.get_multiengine_client,
> ---> 69         furl_or_file)
>      70     return client.adapt_to_blocking_client()
>      71
>
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
> in blockingCallFromThread(f, *a, **kw)
>      97                 result.raiseException()
>      98             except Exception, e:
> ---> 99                 raise e
>     100         return result
>     101
>
> TypeError: coercing to Unicode: need string or buffer, tuple found
>
>
>
> Thanks,
> ~Doug
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
>


From cohen at slac.stanford.edu  Tue Jun 10 16:49:06 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 10 Jun 2008 22:49:06 +0200
Subject: [IPython-dev] feature?
In-Reply-To: <6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com>
References: <484EC4B7.6010309@slac.stanford.edu>
	<6ce0ac130806101137p6e55b2c6ncf621e63d2d053ff@mail.gmail.com>
Message-ID: <484EE8C2.4010006@slac.stanford.edu>

well, with Brian great help, we figured out offline that the problem is 
a faulty setuptools in my system (FC8), so Brian suggested:

easy_install -U setuptools

and it then worked! After installation, I get :
[cohen at jarrett ~]$ nosetests IPython
......................................................................................................................................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 310 tests in 40.059s

OK

hth,
Johann

Brian Granger wrote:
> On Tue, Jun 10, 2008 at 12:15 PM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>   
>> More on my issues with current bzr  trunk : I installed sphinx without
>> trouble so only Foolscap seems to be a problem. But when I try to build
>> ipython again, just for the sake of it, it now outputs :
>> [cohen at jarrett ipython]$ python setup.py build
>> ============================================================================
>> BUILDING IPYTHON
>>                python: 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)  [GCC
>>                        4.1.2 20070925 (Red Hat 4.1.2-33)]
>>              platform: linux2
>>
>> OPTIONAL DEPENDENCIES
>>        Zope.Interface: yes
>>               Twisted: 8.1.0
>>              Foolscap: 0.2.8
>>               OpenSSL: 0.6
>>                sphinx: 0.3
>>              pygments: 0.10
>>                  nose: 0.10.0
>>               pexpect: 2.3
>> running build
>> running build_py
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/config/tests/__init__.py' not found (or not a
>> regular file)
>> package init file 'IPython/UserConfig/__init__.py' not found (or not a
>> regular file)
>> running build_scripts
>>
>> Only the Foolscap egg is there, which seems to be enough for ipython at
>> this stage. Do we really want that behavior?
>> best,
>>     
>
>
> I am not sure that I follow you.  The dependency check shows that it
> has found acceptable versions of all the dependencies.  Can you just
> run:
>
> $ trial IPython
>
> or
>
> nosetests IPython
>
> To run the test suite and see what you get?
>
> Thanks
>
> Brian
>   


From barrywark at gmail.com  Tue Jun 10 19:43:59 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 10 Jun 2008 16:43:59 -0700
Subject: [IPython-dev] coercing to Unicode error in
	IPython.MultiEngineClient
In-Reply-To: <6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>
References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
	<6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>
Message-ID: <cd7634ce0806101643l746a8afbo602781754d94ac53@mail.gmail.com>

Brian,

This looks like a great system! Thanks for implementing a security
model. This will make deploying IPython on "open" networks much less
scary!

Barry

On Tue, Jun 10, 2008 at 12:55 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> This is not a unicode error, but rather, our API for starting the
> client has changed due to the new security stuff.  This is the stuff
> that I am working on documenting as we speak.
>
> Here is a minimal description:
>
> 1) When the controller now starts, it creates a set of files (in your
> .ipython directory by default)
>
> ipcontroller-tc.furl
> ipcontroller-mec.furl
> ipcontroller-engine.furl
>
> 2)  These files contain a secure URL that 1) tells the engine and
> clients where the controller is running and 2) gives the engine and
> clients authority to connect to the controller in a secure manner.
>
> 3) To use these files, they have to be available to the client and
> engines when they start.  The easiest way of handling this is to
>
> a) copy ipcontroller-engine.furl to the .ipython directory on the
> machine(s) where the engines will run
>
> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine
> where the clients will run.
>
> Then everything will "just work".  By this, I mean that you can create
> the clients with no arguments:
>
> mec = client.MultiEngineClient()
>
> If you have put the .furl files in different locations you can do:
>
> mec = client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')
>
> In all of this, you can think of the furl files as being keys (just
> like a house key) that grants an entity access to a particular
> resource.  The controller creates the keys and the engines/client must
> present/use them to use the capabilities of the controller.
>
> See if you can use this to get things working.  The big benefit of
> using all this is:
>
> 1) Users don't have to track what ip/port the controller is running on.
>
> 2) Everything is secure by default - authentication + encryption (if
> you have pyOpenSSL installed
>
> 3) The controller now uses random port numbers, making it even more
> difficult for hostiles to discover.
>
> Let me know if you have any more problems getting this working.  We
> would love feedback if you have ideas of how things could be made
> easier.
>
> Also, check out the new command line flags on the ipcontroller and
> ipengine scripts to control where the furl files are created and
> looked for.
>
> Cheers,
>
> Brian
>
> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com> wrote:
>> Hi all,
>>
>> I tried a simple test of the latest IPython branch and the
>> MultiEngineClient. When I attempted to connect to a running cluster on my
>> local machine, I got the following error:
>>
>>  mec = client.MultiEngineClient(('localhost', 10105))
>> ---------------------------------------------------------------------------
>> TypeError                                 Traceback (most recent call last)
>>
>> /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in <module>()
>>
>> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
>> in get_multiengine_client(furl_or_file)
>>      67     """
>>      68     client =
>> blockingCallFromThread(_client_tub.get_multiengine_client,
>> ---> 69         furl_or_file)
>>      70     return client.adapt_to_blocking_client()
>>      71
>>
>> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
>> in blockingCallFromThread(f, *a, **kw)
>>      97                 result.raiseException()
>>      98             except Exception, e:
>> ---> 99                 raise e
>>     100         return result
>>     101
>>
>> TypeError: coercing to Unicode: need string or buffer, tuple found
>>
>>
>>
>> Thanks,
>> ~Doug
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> 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 Jun 11 18:35:15 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Jun 2008 16:35:15 -0600
Subject: [IPython-dev] IPython documentation
Message-ID: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>

Hello all,

So, I have finished merging in the ipython1 documentation into IPython
proper.  Now all the docs are in one place.

In addition to doing this merge, I have taken the liberty of
completely reorganizing the docs.  Previously, the IPython docs were a
single rst file, which was really awkward and didn't take advantage of
Sphinx's nice features.  In the process of doing all this, I realized
that the IPython docs (not the parallel computing stuff) need quite a
bit of care and attention.  I would like to see if we can get people
to put in time to get our docs back up to where they should be.  Here
is what I am thinking:

The docs are now organized into the following sections (these are
either files or subdirectories in docs/source):

Introduction
Installation
Using IPython for interactive work
Using IPython for parallel computing
Configuration and customization
What's new
Development
Frequently asked questions
History
License and Copyright
Credits

Each of these sections needs someone to go through it and do the
following things:

1) Read through and make sure that the content is up to date and
correct.  For some sections this will be a lot of work.  For example,
because of the ipython1 -> IPython merge, our installation docs are
completely outdated.

2) Make sure that all the internal links are working correctly.  For
this we are using Shinx's "ref" capability.  See the Sphinx docs for
more details.  In some cases, this will require that you make new
labels for things.

If people need doc-writing inspiration check out your favorite well
documented project.  Some of my favorites are django and sqlalchemy.

The good news is that we now have lots of docs.  The bad news is that
I can't do all of this myself.  I can take the following sections
though:

Installation
Using IPython for parallel computing
Development

If you are interested in helping improve our docs, let us know and we
will figure out the best way for you to contribute.  Some of the
sections will probably need to be worked on by specific people.  But
we can surely find a way for eager people to help out.

Cheers,

Brian


From ellisonbg.net at gmail.com  Wed Jun 11 18:40:02 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Jun 2008 16:40:02 -0600
Subject: [IPython-dev] IPython 0.9 release...
Message-ID: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com>

Hello all,

So, everything that is coming in from ipython1-dev is now in ipython
trunk.  Barry is going to merge in the cocoa frontend and frontendbase
from his ipython1-cocoa branch.  I would like us to think about doing
a 0.9 release of IPython sometime in the next few weeks.  The sooner
the better, because I don't want to leave ipython1 users in limbo.

I am wondering what else needs to be done before we but the release.
Here are some things that I can think of:

1.  Update the docs (see my other email on what needs to be done).

2.  Test, test, test all the new stuff

3.  Fernando and I need to finish a few more things in the kernel to
make it easier to use for parallel computing

Is there anything else that people can think of.  Because 0.8.4 came
out, I imagine that not much has changed with the old stuff.  But that
is fine - the main purpose of this release is to get the ipython1 ->
IPython stuff info people's hands.

Cheers,

Brian


From fperez.net at gmail.com  Wed Jun 11 20:55:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 11 Jun 2008 17:55:48 -0700
Subject: [IPython-dev] IPython 0.9 release...
In-Reply-To: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com>
References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com>
Message-ID: <db6b5ecc0806111755s484e49c3t689a47b6da4f76d4@mail.gmail.com>

On Wed, Jun 11, 2008 at 3:40 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hello all,
>
> So, everything that is coming in from ipython1-dev is now in ipython
> trunk.  Barry is going to merge in the cocoa frontend and frontendbase
> from his ipython1-cocoa branch.  I would like us to think about doing
> a 0.9 release of IPython sometime in the next few weeks.  The sooner
> the better, because I don't want to leave ipython1 users in limbo.
>
> I am wondering what else needs to be done before we but the release.
> Here are some things that I can think of:
>
> 1.  Update the docs (see my other email on what needs to be done).
>
> 2.  Test, test, test all the new stuff
>
> 3.  Fernando and I need to finish a few more things in the kernel to
> make it easier to use for parallel computing

I'm mostly offline til next week, but I'm +1 on a quick release.  I'll
be working on the test stuff for the next few days, I'd like to have
at least the scaffolding for testing everything together (that means,
to coherently test both all the new code AND the old) for 0.9.  That
way we'll get off the ground with the new series with solid testing
across the board (even if the actual amount of tests for the old code
is small, I want to put in the machinery).

Min just got back too, and I'll meet up with him next week when I
return to California (we missed each other today).  That will put us
all on the same page.

Question: did you merge sconfig?  I missed the details of that with Stefan...

Cheers,

f


From fperez.net at gmail.com  Wed Jun 11 20:58:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 11 Jun 2008 17:58:47 -0700
Subject: [IPython-dev] IPython documentation
In-Reply-To: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
Message-ID: <db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>

On Wed, Jun 11, 2008 at 3:35 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hello all,
>
> So, I have finished merging in the ipython1 documentation into IPython
> proper.  Now all the docs are in one place.
>
> In addition to doing this merge, I have taken the liberty of
> completely reorganizing the docs.  Previously, the IPython docs were a
> single rst file, which was really awkward and didn't take advantage of
> Sphinx's nice features.  In the process of doing all this, I realized
> that the IPython docs (not the parallel computing stuff) need quite a
> bit of care and attention.  I would like to see if we can get people
> to put in time to get our docs back up to where they should be.  Here
> is what I am thinking:

Thanks for doing this, it was needed.  For one thing, search was
broken with the single-file one.

One thing that I've been mulling is using the new scipy doc system

http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/

for the manuals as well.  I know it's doable, I just don't know right
now how closely tied to docstring editing (the original purpose) it
is.  Stefan can tell us...

Cheers,

f


From stefan at sun.ac.za  Wed Jun 11 21:12:11 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Jun 2008 03:12:11 +0200
Subject: [IPython-dev] IPython 0.9 release...
In-Reply-To: <db6b5ecc0806111755s484e49c3t689a47b6da4f76d4@mail.gmail.com>
References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com>
	<db6b5ecc0806111755s484e49c3t689a47b6da4f76d4@mail.gmail.com>
Message-ID: <9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com>

2008/6/12 Fernando Perez <fperez.net at gmail.com>:
> Question: did you merge sconfig?  I missed the details of that with Stefan...

I merged it into Brian's branch, so I assume it went in.  If you could
give me a couple of common use cases, I shall make sure they are
implemented.  Run the tests in the current version with:

nosetests -v --with-doctest --doctest-tests IPython.config

Regards
St?fan


From ellisonbg.net at gmail.com  Wed Jun 11 23:05:10 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Jun 2008 21:05:10 -0600
Subject: [IPython-dev] IPython 0.9 release...
In-Reply-To: <9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com>
References: <6ce0ac130806111540s45b81874td81463deec1d5045@mail.gmail.com>
	<db6b5ecc0806111755s484e49c3t689a47b6da4f76d4@mail.gmail.com>
	<9457e7c80806111812j37277854m16ca9588ccef50e@mail.gmail.com>
Message-ID: <6ce0ac130806112005n7b56fa65g926f51b6b3d28161@mail.gmail.com>

Yep, the sconfig stuff made it in.  Barry is also going to clean up
and commit the frontendbase and the cocoa frontend.  The only major
things from ipython1 that won't be in yet are the notebook and the
daemon.

Brian




On Wed, Jun 11, 2008 at 7:12 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/6/12 Fernando Perez <fperez.net at gmail.com>:
>> Question: did you merge sconfig?  I missed the details of that with Stefan...
>
> I merged it into Brian's branch, so I assume it went in.  If you could
> give me a couple of common use cases, I shall make sure they are
> implemented.  Run the tests in the current version with:
>
> nosetests -v --with-doctest --doctest-tests IPython.config
>
> Regards
> St?fan
>


From vivian at vdesmedt.com  Wed Jun 11 23:41:20 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Thu, 12 Jun 2008 05:41:20 +0200
Subject: [IPython-dev] Synchronization with Editor
In-Reply-To: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com>
References: <484553B1.9020405@vdesmedt.com>	
	<db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>	
	<484A3976.5040207@vdesmedt.com>
	<46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com>
Message-ID: <48509AE0.3040200@vdesmedt.com>

Ville,

I have updated my branch according to the comment you put on the white 
board.

I have removed the ip_synchronize_with_xxx.py file and add a 
ipy_synchronize_with.py version that contains the code for each 
supported editor.

Now if you want that IPython synchronize the code it highlight and your 
favorite editor you have to add the following line to your 
ip_user_conf.py file:

    import ipy_synchronize_with
    py_synchronize_with.scite()

Supposing the that scite is your favorite editor. Currently emacs, gvim, 
scite, notepadplusplus, pspad and ultraedit are supported but it should 
be easy to add some more.

Please tell what should I do to help you testing or reviewing my 
propositions.

Regards,
Vivian.

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

From cohen at slac.stanford.edu  Thu Jun 12 04:01:30 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Thu, 12 Jun 2008 10:01:30 +0200
Subject: [IPython-dev] an issue in replaying  logs with profile
Message-ID: <4850D7DA.2090903@slac.stanford.edu>

hi there,
I am using a very recent bazaar build of ipython and python 2.5. I have 
the following profile in my IPYTHONDIR:

[cohen at jarrett ~]$ more .ipython/ipy_profile_test.py
import IPython.ipapi
ip = IPython.ipapi.get()

ip.ex("print '*****************************************************'")
ip.ex("print '* TEST *'")
ip.ex("print '*****************************************************'")

ip.ex("import os")


I then run the following :
[cohen at jarrett ~]$ ipython -profile test -log
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : rotate
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: n=5.2

In [2]: os
Out[2]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

after exiting the session, the log looks like :
[cohen at jarrett ~]$ more ipython_log.py
#log# Automatic Logger file. *** THIS MUST BE THE FIRST LINE ***
#log# DO NOT CHANGE THIS LINE OR THE TWO BELOW
#log# opts = Struct({'__allownew': True, 'log': 1, 'logfile': 
'ipython_log.py', 'profile': ''})
#log# args = []
#log# It is safe to make manual edits below here.
#log#-----------------------------------------------------------------------
n=5.2
os

That does *not* look good because the 'profile' value is blank, and indeed :
[cohen at jarrett ~]$ ipython -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>

The following lines/blocks in file <ipython_log.py> reported errors:
os
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: os
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/cohen/<ipython console> in <module>()

NameError: name 'os' is not defined

There was no 'TEST' banner and no importing of os, as anticipated as the 
profile is not filled in the log.
Even more problematic :
[cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>

The following lines/blocks in file <ipython_log.py> reported errors:
os
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

Here the -profile argument request is not even honored....
If I add test as the profile in the log file, then I get
the correct behavior in both cases :
[cohen at jarrett ~]$ ipython -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: os
Out[1]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

In [2]: n
Out[2]: 5.2000000000000002

In [3]:
Do you really want to exit ([y]/n)?
[cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: os
Out[1]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

In [2]: n
Out[2]: 5.2000000000000002


So to make a long story short : there is a faulty behavior of the logger 
that does not correctly save the profile used. I am trying to read the 
code (Logger.py and ipilib.py seem to be the natural candidates) but if 
someone finds the correct patch more quickly, I will be happy too :).
cheers,
Johann


From vivainio at gmail.com  Thu Jun 12 07:37:46 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 12 Jun 2008 14:37:46 +0300
Subject: [IPython-dev] IPython documentation
In-Reply-To: <db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
Message-ID: <46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com>

On Thu, Jun 12, 2008 at 3:58 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> Thanks for doing this, it was needed.  For one thing, search was
> broken with the single-file one.

Actually, with single file, search is just ctrl + F away ;-)

Additional advantage of a single big file is that it's easy to print
(both the source and built documentation), if need be (e.g. if you
don't happen have the pdf handy). The .rst document is usable as a
documentation as such, on systems that don't have viewers for other
file systems.

It's true, though, that Sphinx is optimized for multiple source files,
so either way is fine.

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


From fperez.net at gmail.com  Thu Jun 12 08:41:35 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Jun 2008 05:41:35 -0700
Subject: [IPython-dev] Synchronization with Editor
In-Reply-To: <46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com>
References: <484553B1.9020405@vdesmedt.com>
	<db6b5ecc0806031259hc1d84abt1bd4ac80375fae2@mail.gmail.com>
	<484A3976.5040207@vdesmedt.com>
	<46cb515a0806091009j2b2959b9m1b8df74547a82937@mail.gmail.com>
Message-ID: <db6b5ecc0806120541w775920adobb31f140f401b985@mail.gmail.com>

On Mon, Jun 9, 2008 at 10:09 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sat, Jun 7, 2008 at 10:32 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:
>
>> Dear All,
>>
>> Just to tell you that I just push my "synchronize-editor" branch.
>
> Thank you, especially for taking the time to create a bzr branch!
> Makes the process so much cleaner...

Yes, extra brownie points to Vivian for doing it this way.  We really
appreciate it.

Cheers,

f


From vivainio at gmail.com  Thu Jun 12 11:00:33 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 12 Jun 2008 18:00:33 +0300
Subject: [IPython-dev] cd a little hyper
In-Reply-To: <46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com>
References: <88e473830806051530h57e64dfat2aab3d8a71f6a5f0@mail.gmail.com>
	<46cb515a0806052141o3ab81fbdh29d209a9e32d1f3e@mail.gmail.com>
	<88e473830806052205h21531ffavee76d87d20145dd0@mail.gmail.com>
	<46cb515a0806052355r1bed2c55tcb3e37e92fa35b33@mail.gmail.com>
Message-ID: <46cb515a0806120800s3e3c5916ob0854774985fecf3@mail.gmail.com>

On Fri, Jun 6, 2008 at 9:55 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

>> Now in the case of somedir containing only a *single* non-hidden dir
>> and *no* plain files, I think the current hyper-completion is a
>> feature.  But if there are files and/or dirs in the target dir, I
>> don't think you want to assume a subdir for completion.
>
> I agree that it's not desirable. However, it was a compromise to get
> this bug fixed.
>
> Perhaps I'll add an option for this, so that it will only be a
> workaround for those who have the buggy readline.

I have now disabled this "feature".

The only thing we can do for people with buggy readline is to suggest
them to re-enable it by

import ipy_completers
ipy_completer.greedy_cd_completer = True

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


From ellisonbg.net at gmail.com  Thu Jun 12 13:03:39 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 11:03:39 -0600
Subject: [IPython-dev] IPython documentation
In-Reply-To: <46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
	<46cb515a0806120437p49420a06oad59ce9c141084ea@mail.gmail.com>
Message-ID: <6ce0ac130806121003n53e84893t6705fa1c30e444f@mail.gmail.com>

>
> Actually, with single file, search is just ctrl + F away ;-)
>
> Additional advantage of a single big file is that it's easy to print
> (both the source and built documentation), if need be (e.g. if you
> don't happen have the pdf handy). The .rst document is usable as a
> documentation as such, on systems that don't have viewers for other
> file systems.
>
> It's true, though, that Sphinx is optimized for multiple source files,
> so either way is fine.

The main reason that I did this is that the size of the single file
was becoming a bit crazy with all of the new parallel computing docs
merged in.  I really want the docs to be easy for us devs to maintain
and having multiple files really help a lot.

Brian


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


From pav at iki.fi  Thu Jun 12 14:32:16 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 12 Jun 2008 21:32:16 +0300
Subject: [IPython-dev] Fwd:  IPython documentation
In-Reply-To: <9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
	<9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com>
Message-ID: <1213295536.10989.27.camel@localhost.localdomain>

On ?2008/6/12 ?Fernando Perez wrote:
[clip]
> One thing that I've been mulling is using the new scipy doc system
> 
> http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/
> 
> for the manuals as well.  I know it's doable, I just don't know right
> now how closely tied to docstring editing (the original purpose) it
> is.  Stefan can tell us...

Actually using it also for manuals could be in the interest of the Scipy
documentation project too.

The system itself is not really tied to docstring editing: what needs to
be done depends on whether you need 3-way merging with SVN (or bzr or
whatever) or not.

If yes, it's probably easiest to modify the docstring collector script
to also collect text from given .rst files, implement support for text
files in the patch generation, and adjust the logic in the web interface
slightly so that it knows that the docstring standard shouldn't be
enforced for some entries. All of this is not a lot of extra work.

If 3-way merges are not needed, one could simply use the wiki
functionality in the program as an RST editor, and possibly write some
code to easily export multiple wiki pages at once.

For writing Sphinx documents, some amount of work would probably be
needed in adding support for the Sphinx special directives. Writing this
code is probably the hardest part as it requires some familiarity with
the internals of the docutils package.

	Pauli




From ellisonbg.net at gmail.com  Thu Jun 12 14:36:50 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 12:36:50 -0600
Subject: [IPython-dev] ChangLog vs changes.txt
Message-ID: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com>

Hi,

In the process of reorganizing the IPython documentation, I ran into
something related to the ChangeLog.  In the past, IPython has used a
traditional ChangeLog for devs to record the changes they have made to
the project.  This was used to keep track of who has done what and
what things have been done since the last release.  In IPython1 on the
other hand, I had moved away from using the ChangeLog for the
following reasons:

1.  A linear ChangeLog is a poor reflection of what happens to the
core when a distributed VCS is used.  In fact, I would say it could
potentially be downright confusing.

2.  The ChangeLog really is a repetition of the information that is
contained in the commit messages (which in a DVCS do reflect the
distributed/parallel nature of development).

3.  The ChangeLog doesn't really give users anything useful.  Sure
they could read it, but it is not written in a user focused manner and
they would have to sift through a lot of irrelevant information.

4.  To generate things like release notes, what's new, api changes
etc. (user focused docs), someone has to do the tedious task of
looking through the ChangeLog and summarizing the changes in user
friendly form.  The success of this is shown in the lack of user
focued high quality release notes, what new and api change
documentation for IPython.

5. For those of us who don't use emacs, the format of the ChangeLog
leaves something to be desired.

6.  The ChangeLog format does not integrate with our Sphinx docs as it
is not rst.

To address these issue with IPython1, we recently went the following route:

1.  We no longer maintain a ChangeLog

2.  We instead have a changes.txt files that is 1) regular rst and 2)
part of our Sphinx based docs.

This document lists changes for each release of IPython separately and
for each release, includes three sections: new features, bug fixes and
backward incompatible changes.  The goal of this document is to record
in a user focused way all of the changes to IPython.  I was inspired
to create this after looking at how a number of different projects
handle this issue.

So, for now I have left the IPython ChangeLog in place, but I propose
that we abandon it (move it to docs/attic) and begin using the new
document that I have created:

docs/source/changes.txt

At some level, I picture this file as part of our contract with users.
 If there is something new that a user needs to know about IPython,
this is where they should look.  Also note that the file immediately
provides a usable release notes for our releases.

Here is what that document looks like currently, to give you an idea:


########################## changes.txt

.. _changes:

==========
What's new
==========

.. contents::

Release 0.9
===========

New features
------------

	* All of the parallel computing capabilities from `ipython1-dev` have
been merged into
	  IPython proper.  This resulted in the following new subpackages:
	  :mod:`IPython.kernel`, :mod:`IPython.kernel.core`, :mod:`IPython.config`,
	  :mod:`IPython.tools` and :mod:`IPython.testing`.
	* As part of merging in the `ipython1-dev` stuff, the `setup.py`
script and friends
	  have been completely refactored.  Now we are checking for dependencies using
	  the approach that matplotlib uses.
	* The documentation has been completely reorganized to accept the documentation
	  from `ipython1-dev`.
	* We have switched to using Foolscap for all of our network protocols in
	  :mod:`IPython.kernel`.  This gives us secure connections that are
both encrypted
	  and authenticated.
	* We have a brand new `COPYING.txt` files that describes the IPython license
	  and copyright.  The biggest change is that we are putting "The IPython
	  Development Team" as the copyright holder.  We give more details
about exactly
	  what this means in this file.  All developer should read this and use the new
	  banner in all IPython source code files.

Bug fixes
---------

	* A few subpackages has missing `__init__.py` files.
	* The documentation is only created is Sphinx is found.  Previously,
the `setup.py`
	  script would fail if it was missing.

Backwards incompatible changes
------------------------------

	* IPython has a larger set of dependencies if you want all of its capabilities.
	  See the `setup.py` script for details.
	* The constructors for :class:`IPython.kernel.client.MultiEngineClient` and
	  :class:`IPython.kernel.client.TaskClient` no longer take the (ip,port) tuple.
	  Instead they take the filename of a file that contains the FURL for that
	  client.  If the FURL file is in your IPYTHONDIR, it will be found
automatically
	  and the constructor can be left empty.
	* The asynchronous clients in :mod:`IPython.kernel.asyncclient` are
now created
	  using the factory functions :func:`get_multiengine_client` and
	  :func:`get_task_client`.  These return a `Deferred` to the actual client.
	* The command line options to `ipcontroller` and `ipengine` have changed to
	  reflect the new Foolscap network protocol and the FURL files.  Please see the
	  help for these scripts for details.
	* The configuration files for the kernel have changed because of the
Foolscap stuff.
	  If you were using custom config files before, you should delete
them and regenerate
	  new ones.

Changes merged in from IPython1
-------------------------------

New features
............

	* Much improved ``setup.py`` and ``setupegg.py`` scripts.  Because Twisted
	  and zope.interface are now easy installable, we can declare them as
dependencies
	  in our setupegg.py script.
	* IPython is now compatible with Twisted 2.5.0 and 8.x.
	* Added a new example of how to use :mod:`ipython1.kernel.asynclient`.
	* Initial draft of a process daemon in :mod:`ipython1.daemon`.  This has not
	  been merged into IPython and is still in `ipython1-dev`.
	* The ``TaskController`` now has methods for getting the queue status.
	* The ``TaskResult`` objects not have information about how long the task
	  took to run.
	* We are attaching additional attributes to exceptions ``(_ipython_*)`` that
	  we use to carry additional info around.
	* New top-level module :mod:`asyncclient` that has asynchronous versions (that
	  return deferreds) of the client classes.  This is designed to users who want
	  to run their own Twisted reactor
	* All the clients in :mod:`client` are now based on Twisted.  This is done by
	  running the Twisted reactor in a separate thread and using the
	  :func:`blockingCallFromThread` function that is in recent versions
of Twisted.
	* Functions can now be pushed/pulled to/from engines using
	  :meth:`MultiEngineClient.push_function` and
:meth:`MultiEngineClient.pull_function`.
	* Gather/scatter are now implemented in the client to reduce the work load
	  of the controller and improve performance.
	* Complete rewrite of the IPython docuementation.  All of the documentation
	  from the IPython website has been moved into docs/source as restructured
	  text documents.  PDF and HTML documentation are being generated using
	  Sphinx.
	* New developer oriented documentation: development guidelines and roadmap.
	* Traditional ``ChangeLog`` has been changed to a more useful
``changes.txt`` file
	  that is organized by release and is meant to provide something more relevant
	  for users.

Bug fixes
.........

	* Created a proper ``MANIFEST.in`` file to create source distributions.
	* Fixed a bug in the ``MultiEngine`` interface.  Previously, multi-engine
	  actions were being collected with a :class:`DeferredList` with
	  ``fireononeerrback=1``.  This meant that methods were returning
	  before all engines had given their results.  This was causing extremely odd
	  bugs in certain cases. To fix this problem, we have 1) set
	  ``fireononeerrback=0`` to make sure all results (or exceptions) are in
	  before returning and 2) introduced a :exc:`CompositeError` exception
	  that wraps all of the engine exceptions.  This is a huge change as it means
	  that users will have to catch :exc:`CompositeError` rather than the actual
	  exception.

Backwards incompatible changes
..............................

	* All names have been renamed to conform to the lowercase_with_underscore
	  convention.  This will require users to change references to all names like
	  ``queueStatus`` to ``queue_status``.
	* Previously, methods like :meth:`MultiEngineClient.push` and    	
	  :meth:`MultiEngineClient.push` used ``*args`` and ``**kwargs``.  This was
	  becoming a problem as we weren't able to introduce new keyword arguments into
	  the API.  Now these methods simple take a dict or sequence.  This
has also allowed
	  us to get rid of the ``*All`` methods like :meth:`pushAll` and
:meth:`pullAll`.
	  These things are now handled with the ``targets`` keyword argument
that defaults
	  to ``'all'``.
	* The :attr:`MultiEngineClient.magicTargets` has been renamed to
	  :attr:`MultiEngineClient.targets`.
	* All methods in the MultiEngine interface now accept the optional
keyword argument
	  ``block``.
	* Renamed :class:`RemoteController` to :class:`MultiEngineClient` and
	  :class:`TaskController` to :class:`TaskClient`.
	* Renamed the top-level module from :mod:`api` to :mod:`client`.
	* Most methods in the multiengine interface now raise a
:exc:`CompositeError` exception
	  that wraps the user's exceptions, rather than just raising the raw
user's exception.
	* Changed the ``setupNS`` and ``resultNames`` in the ``Task`` class
to ``push``
	  and ``pull``.

Release 0.8.4
=============

Someone needs to describe what went into 0.8.4.

Release 0.8.2
=============

* %pushd/%popd behave differently; now "pushd /foo" pushes CURRENT directory
  and jumps to /foo. The current behaviour is closer to the documented
  behaviour, and should not trip anyone.

Release 0.8.3
=============

* pydb is now disabled by default (due to %run -d problems). You can enable
  it by passing -pydb command line argument to IPython. Note that setting
  it in config file won't work.

Older releases
==============

Changes in earlier releases of IPython are described in the older file
``ChangeLog``.
Please refer to this document for details.

########################## /changes.txt

So, what do people think about this proposal?

Cheers,

Brian


From ellisonbg.net at gmail.com  Thu Jun 12 14:41:07 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 12:41:07 -0600
Subject: [IPython-dev] IPython documentation
In-Reply-To: <db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
Message-ID: <6ce0ac130806121141k696d3f3bx8537db46dade79c@mail.gmail.com>

On Wed, Jun 11, 2008 at 6:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Wed, Jun 11, 2008 at 3:35 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hello all,
>>
>> So, I have finished merging in the ipython1 documentation into IPython
>> proper.  Now all the docs are in one place.
>>
>> In addition to doing this merge, I have taken the liberty of
>> completely reorganizing the docs.  Previously, the IPython docs were a
>> single rst file, which was really awkward and didn't take advantage of
>> Sphinx's nice features.  In the process of doing all this, I realized
>> that the IPython docs (not the parallel computing stuff) need quite a
>> bit of care and attention.  I would like to see if we can get people
>> to put in time to get our docs back up to where they should be.  Here
>> is what I am thinking:
>
> Thanks for doing this, it was needed.  For one thing, search was
> broken with the single-file one.
>
> One thing that I've been mulling is using the new scipy doc system
>
> http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/
>
> for the manuals as well.  I know it's doable, I just don't know right
> now how closely tied to docstring editing (the original purpose) it
> is.  Stefan can tell us...

Something like this would be a huge help.  I agree with you that it is
likely that it can be done, but we would need to make sure that it can
handle all of the custom Sphinx rst directives.  I would be very
curious to heard from Stefan on this

At the same time, I strongly feel that our new Sphinx/rst based docs
are nice enough that we have no excuses for not writing great
documentation :)



Brian




> Cheers,
>
> f
>


From dfj225 at gmail.com  Thu Jun 12 15:33:22 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Thu, 12 Jun 2008 15:33:22 -0400
Subject: [IPython-dev] coercing to Unicode error in
	IPython.MultiEngineClient
In-Reply-To: <6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com>
References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
	<6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>
	<1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com>
	<6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com>
	<1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com>
	<6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com>
Message-ID: <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com>

Hi Brian,

I ran into some more issues installing IPython on a different machine. This
machine runs Python 2.4 and it seems that some of the IPython code is now
using the 'with' statement, which I don't think is included in Python 2.4.
Is 2.4 no longer supported?

The trace from my setup.py install attempt has been copied at the end of the
message.

Thanks,
~Doug

Note: I'd already executed a python setup.py build without error.

 python setup.py install --prefix=$HOME/local
============================================================================
BUILDING IPYTHON
                python: 2.4.4 (#1, Jul 29 2007, 19:42:10)  [GCC 4.1.1
                        (Gentoo 4.1.1-r3)]
              platform: linux2

OPTIONAL DEPENDENCIES
        Zope.Interface: yes
               Twisted: 2.5.0
              Foolscap: 0.2.8
               OpenSSL: 0.6
                sphinx: 0.3
              pygments: 0.10
                  nose: 0.10.3
               pexpect: 0.999
running install
running build
running build_py
running build_scripts
running install_lib
byte-compiling
/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py to
config.pyc
  File
"/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py",
line 49
    with raw(self):
           ^
SyntaxError: invalid syntax
byte-compiling
/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py to
contexts.pyc
  File
"/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py",
line 171
    with parallel as pr:
                ^
SyntaxError: invalid syntax
running install_scripts
changing mode of /home/djones/local/bin/pycolor to 755
changing mode of /home/djones/local/bin/ipengine to 755
changing mode of /home/djones/local/bin/ipcontroller to 755
changing mode of /home/djones/local/bin/ipcluster to 755
changing mode of /home/djones/local/bin/ipython to 755
changing mode of /home/djones/local/bin/irunner to 755
running install_data
Traceback (most recent call last):
  File "setup.py", line 174, in ?
    setup(**setup_args)
  File "/usr/lib/python2.4/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.4/distutils/command/install.py", line 510, in run
    self.run_command(cmd_name)
  File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
    cmd_obj.run()
  File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line
75, in run
    (out, _) = self.copy_file(f, dir)
  File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file
    dry_run=self.dry_run)
  File "/usr/lib/python2.4/distutils/file_util.py", line 117, in copy_file
    if not os.path.isfile(src):
  File "/usr/lib/python2.4/posixpath.py", line 208, in isfile
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, list found




On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger <ellisonbg.net at gmail.com>
wrote:

> > Connecting with the MultiEngineClient is working now. It seems that it
> was
> > simply from passing the wrong arguments to the constructor that I was
> having
> > problems before.
> >
> > All in all, I think the furl files are an improvement and the addition of
> > secure connections is certainly appreciated.
>
> Thanks for the feedback.  We _really_ needed to address the security
> issue and I think Foolscap and the furls really work well.  They give
> a high level of security, but make it pretty easy to setup.
>
> Brian
>
> > Thanks,
> > ~doug
> >
> > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger <ellisonbg.net at gmail.com>
> > wrote:
> >>
> >> > Thanks for the information. I thought I had used the configuration
> >> > creation
> >> > command to create .furl files in my home directory. Right now, i'm
> using
> >> > mpiexec to start the engines, so perhaps this is creating some sort of
> >> > issue
> >> > with the shell environment the engines are created in. I'll double
> check
> >> > and
> >> > let you know if I continue to have problems.
> >>
> >> Hmm, if you are editing the ipython config files to set the locations
> >> of the furl files, that should work.  Maybe the only thing you need to
> >> change is how you are creating the MultiEngineClient.
> >>
> >> It no longer takes the (ip, port) tuple.  It now takes the name of the
> >> furl file, or if empty it will use the location given in the config
> >> files.
> >>
> >> Keep me posted.
> >>
> >> Brian
> >>
> >> > ~doug
> >> >
> >> >
> >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger <ellisonbg.net@
> gmail.com>
> >> > wrote:
> >> >>
> >> >> This is not a unicode error, but rather, our API for starting the
> >> >> client has changed due to the new security stuff.  This is the stuff
> >> >> that I am working on documenting as we speak.
> >> >>
> >> >> Here is a minimal description:
> >> >>
> >> >> 1) When the controller now starts, it creates a set of files (in your
> >> >> .ipython directory by default)
> >> >>
> >> >> ipcontroller-tc.furl
> >> >> ipcontroller-mec.furl
> >> >> ipcontroller-engine.furl
> >> >>
> >> >> 2)  These files contain a secure URL that 1) tells the engine and
> >> >> clients where the controller is running and 2) gives the engine and
> >> >> clients authority to connect to the controller in a secure manner.
> >> >>
> >> >> 3) To use these files, they have to be available to the client and
> >> >> engines when they start.  The easiest way of handling this is to
> >> >>
> >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the
> >> >> machine(s) where the engines will run
> >> >>
> >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine
> >> >> where the clients will run.
> >> >>
> >> >> Then everything will "just work".  By this, I mean that you can
> create
> >> >> the clients with no arguments:
> >> >>
> >> >> mec = client.MultiEngineClient()
> >> >>
> >> >> If you have put the .furl files in different locations you can do:
> >> >>
> >> >> mec =
> >> >> client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')
> >> >>
> >> >> In all of this, you can think of the furl files as being keys (just
> >> >> like a house key) that grants an entity access to a particular
> >> >> resource.  The controller creates the keys and the engines/client
> must
> >> >> present/use them to use the capabilities of the controller.
> >> >>
> >> >> See if you can use this to get things working.  The big benefit of
> >> >> using all this is:
> >> >>
> >> >> 1) Users don't have to track what ip/port the controller is running
> on.
> >> >>
> >> >> 2) Everything is secure by default - authentication + encryption (if
> >> >> you have pyOpenSSL installed
> >> >>
> >> >> 3) The controller now uses random port numbers, making it even more
> >> >> difficult for hostiles to discover.
> >> >>
> >> >> Let me know if you have any more problems getting this working.  We
> >> >> would love feedback if you have ideas of how things could be made
> >> >> easier.
> >> >>
> >> >> Also, check out the new command line flags on the ipcontroller and
> >> >> ipengine scripts to control where the furl files are created and
> >> >> looked for.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Brian
> >> >>
> >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com>
> wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > I tried a simple test of the latest IPython branch and the
> >> >> > MultiEngineClient. When I attempted to connect to a running cluster
> >> >> > on
> >> >> > my
> >> >> > local machine, I got the following error:
> >> >> >
> >> >> >  mec = client.MultiEngineClient(('localhost', 10105))
> >> >> >
> >> >> >
> >> >> >
> ---------------------------------------------------------------------------
> >> >> > TypeError                                 Traceback (most recent
> call
> >> >> > last)
> >> >> >
> >> >> > /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in
> >> >> > <module>()
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
> >> >> > in get_multiengine_client(furl_or_file)
> >> >> >      67     """
> >> >> >      68     client =
> >> >> > blockingCallFromThread(_client_tub.get_multiengine_client,
> >> >> > ---> 69         furl_or_file)
> >> >> >      70     return client.adapt_to_blocking_client()
> >> >> >      71
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
> >> >> > in blockingCallFromThread(f, *a, **kw)
> >> >> >      97                 result.raiseException()
> >> >> >      98             except Exception, e:
> >> >> > ---> 99                 raise e
> >> >> >     100         return result
> >> >> >     101
> >> >> >
> >> >> > TypeError: coercing to Unicode: need string or buffer, tuple found
> >> >> >
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> > ~Doug
> >> >> >
> >> >> > _______________________________________________
> >> >> > IPython-dev mailing list
> >> >> > IPython-dev at scipy.org
> >> >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080612/a22992f3/attachment.html>

From ellisonbg.net at gmail.com  Thu Jun 12 16:05:20 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:05:20 -0600
Subject: [IPython-dev] coercing to Unicode error in
	IPython.MultiEngineClient
In-Reply-To: <1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com>
References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
	<6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>
	<1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com>
	<6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com>
	<1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com>
	<6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com>
	<1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com>
Message-ID: <6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com>

Doug,

We haven't thought about this yet and it is a big issue.  I will make
another post about this that we can all use to work out this issue.

Brian

On Thu, Jun 12, 2008 at 1:33 PM, Doug Jones <dfj225 at gmail.com> wrote:
> Hi Brian,
>
> I ran into some more issues installing IPython on a different machine. This
> machine runs Python 2.4 and it seems that some of the IPython code is now
> using the 'with' statement, which I don't think is included in Python 2.4.
> Is 2.4 no longer supported?
>
> The trace from my setup.py install attempt has been copied at the end of the
> message.
>
> Thanks,
> ~Doug
>
> Note: I'd already executed a python setup.py build without error.
>
>  python setup.py install --prefix=$HOME/local
> ============================================================================
> BUILDING IPYTHON
>                 python: 2.4.4 (#1, Jul 29 2007, 19:42:10)  [GCC 4.1.1
>                         (Gentoo 4.1.1-r3)]
>               platform: linux2
>
> OPTIONAL DEPENDENCIES
>         Zope.Interface: yes
>                Twisted: 2.5.0
>               Foolscap: 0.2.8
>                OpenSSL: 0.6
>                 sphinx: 0.3
>               pygments: 0.10
>                   nose: 0.10.3
>                pexpect: 0.999
> running install
> running build
> running build_py
> running build_scripts
> running install_lib
> byte-compiling
> /home/djones/local/lib/python2.4/site-packages/IPython/config/config.py to
> config.pyc
>   File
> "/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py",
> line 49
>     with raw(self):
>            ^
> SyntaxError: invalid syntax
> byte-compiling
> /home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py to
> contexts.pyc
>   File
> "/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py",
> line 171
>     with parallel as pr:
>                 ^
> SyntaxError: invalid syntax
> running install_scripts
> changing mode of /home/djones/local/bin/pycolor to 755
> changing mode of /home/djones/local/bin/ipengine to 755
> changing mode of /home/djones/local/bin/ipcontroller to 755
> changing mode of /home/djones/local/bin/ipcluster to 755
> changing mode of /home/djones/local/bin/ipython to 755
> changing mode of /home/djones/local/bin/irunner to 755
> running install_data
> Traceback (most recent call last):
>   File "setup.py", line 174, in ?
>     setup(**setup_args)
>   File "/usr/lib/python2.4/distutils/core.py", line 149, in setup
>     dist.run_commands()
>   File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands
>     self.run_command(cmd)
>   File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
>     cmd_obj.run()
>   File "/usr/lib/python2.4/distutils/command/install.py", line 510, in run
>     self.run_command(cmd_name)
>   File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command
>     self.distribution.run_command(command)
>   File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
>     cmd_obj.run()
>   File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line
> 75, in run
>     (out, _) = self.copy_file(f, dir)
>   File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file
>     dry_run=self.dry_run)
>   File "/usr/lib/python2.4/distutils/file_util.py", line 117, in copy_file
>     if not os.path.isfile(src):
>   File "/usr/lib/python2.4/posixpath.py", line 208, in isfile
>     st = os.stat(path)
> TypeError: coercing to Unicode: need string or buffer, list found
>
>
>
>
> On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger <ellisonbg.net at gmail.com>
> wrote:
>>
>> > Connecting with the MultiEngineClient is working now. It seems that it
>> > was
>> > simply from passing the wrong arguments to the constructor that I was
>> > having
>> > problems before.
>> >
>> > All in all, I think the furl files are an improvement and the addition
>> > of
>> > secure connections is certainly appreciated.
>>
>> Thanks for the feedback.  We _really_ needed to address the security
>> issue and I think Foolscap and the furls really work well.  They give
>> a high level of security, but make it pretty easy to setup.
>>
>> Brian
>>
>> > Thanks,
>> > ~doug
>> >
>> > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger <ellisonbg.net at gmail.com>
>> > wrote:
>> >>
>> >> > Thanks for the information. I thought I had used the configuration
>> >> > creation
>> >> > command to create .furl files in my home directory. Right now, i'm
>> >> > using
>> >> > mpiexec to start the engines, so perhaps this is creating some sort
>> >> > of
>> >> > issue
>> >> > with the shell environment the engines are created in. I'll double
>> >> > check
>> >> > and
>> >> > let you know if I continue to have problems.
>> >>
>> >> Hmm, if you are editing the ipython config files to set the locations
>> >> of the furl files, that should work.  Maybe the only thing you need to
>> >> change is how you are creating the MultiEngineClient.
>> >>
>> >> It no longer takes the (ip, port) tuple.  It now takes the name of the
>> >> furl file, or if empty it will use the location given in the config
>> >> files.
>> >>
>> >> Keep me posted.
>> >>
>> >> Brian
>> >>
>> >> > ~doug
>> >> >
>> >> >
>> >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger
>> >> > <ellisonbg.net at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> This is not a unicode error, but rather, our API for starting the
>> >> >> client has changed due to the new security stuff.  This is the stuff
>> >> >> that I am working on documenting as we speak.
>> >> >>
>> >> >> Here is a minimal description:
>> >> >>
>> >> >> 1) When the controller now starts, it creates a set of files (in
>> >> >> your
>> >> >> .ipython directory by default)
>> >> >>
>> >> >> ipcontroller-tc.furl
>> >> >> ipcontroller-mec.furl
>> >> >> ipcontroller-engine.furl
>> >> >>
>> >> >> 2)  These files contain a secure URL that 1) tells the engine and
>> >> >> clients where the controller is running and 2) gives the engine and
>> >> >> clients authority to connect to the controller in a secure manner.
>> >> >>
>> >> >> 3) To use these files, they have to be available to the client and
>> >> >> engines when they start.  The easiest way of handling this is to
>> >> >>
>> >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the
>> >> >> machine(s) where the engines will run
>> >> >>
>> >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine
>> >> >> where the clients will run.
>> >> >>
>> >> >> Then everything will "just work".  By this, I mean that you can
>> >> >> create
>> >> >> the clients with no arguments:
>> >> >>
>> >> >> mec = client.MultiEngineClient()
>> >> >>
>> >> >> If you have put the .furl files in different locations you can do:
>> >> >>
>> >> >> mec =
>> >> >>
>> >> >> client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')
>> >> >>
>> >> >> In all of this, you can think of the furl files as being keys (just
>> >> >> like a house key) that grants an entity access to a particular
>> >> >> resource.  The controller creates the keys and the engines/client
>> >> >> must
>> >> >> present/use them to use the capabilities of the controller.
>> >> >>
>> >> >> See if you can use this to get things working.  The big benefit of
>> >> >> using all this is:
>> >> >>
>> >> >> 1) Users don't have to track what ip/port the controller is running
>> >> >> on.
>> >> >>
>> >> >> 2) Everything is secure by default - authentication + encryption (if
>> >> >> you have pyOpenSSL installed
>> >> >>
>> >> >> 3) The controller now uses random port numbers, making it even more
>> >> >> difficult for hostiles to discover.
>> >> >>
>> >> >> Let me know if you have any more problems getting this working.  We
>> >> >> would love feedback if you have ideas of how things could be made
>> >> >> easier.
>> >> >>
>> >> >> Also, check out the new command line flags on the ipcontroller and
>> >> >> ipengine scripts to control where the furl files are created and
>> >> >> looked for.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Brian
>> >> >>
>> >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com>
>> >> >> wrote:
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I tried a simple test of the latest IPython branch and the
>> >> >> > MultiEngineClient. When I attempted to connect to a running
>> >> >> > cluster
>> >> >> > on
>> >> >> > my
>> >> >> > local machine, I got the following error:
>> >> >> >
>> >> >> >  mec = client.MultiEngineClient(('localhost', 10105))
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ---------------------------------------------------------------------------
>> >> >> > TypeError                                 Traceback (most recent
>> >> >> > call
>> >> >> > last)
>> >> >> >
>> >> >> > /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in
>> >> >> > <module>()
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
>> >> >> > in get_multiengine_client(furl_or_file)
>> >> >> >      67     """
>> >> >> >      68     client =
>> >> >> > blockingCallFromThread(_client_tub.get_multiengine_client,
>> >> >> > ---> 69         furl_or_file)
>> >> >> >      70     return client.adapt_to_blocking_client()
>> >> >> >      71
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
>> >> >> > in blockingCallFromThread(f, *a, **kw)
>> >> >> >      97                 result.raiseException()
>> >> >> >      98             except Exception, e:
>> >> >> > ---> 99                 raise e
>> >> >> >     100         return result
>> >> >> >     101
>> >> >> >
>> >> >> > TypeError: coercing to Unicode: need string or buffer, tuple found
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Thanks,
>> >> >> > ~Doug
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > IPython-dev mailing list
>> >> >> > IPython-dev at scipy.org
>> >> >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>


From ellisonbg.net at gmail.com  Thu Jun 12 16:11:29 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:11:29 -0600
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 - we
	need to fix this
Message-ID: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>

Hi,

Now that all of the stuff from ipython1 has moved into IPython,
IPython has new fancy parallel computing capabilities.....and..... a
dependency on Python 2.5.

Here is the story.  In IPython.kernel there is a likely lots of code
that requires python 2.4, and a little that requires 2.5.  At this
point, it is probably too late to get rid of the 2.4 specific stuff,
but we still have to figure out what to do about 2.5 specific syntax
and features.

The main things are our usage of the with statement.  Currently
building IPython with <2.5 gives a syntax error because of this.  We
clearly need to fix this as IPython definitely needs to run under 2.4.
 But, how do we want to handle these things?  Requires 2.4 and make
2.5 features optional?  Thoughts?

Brian


From dfj225 at gmail.com  Thu Jun 12 16:24:22 2008
From: dfj225 at gmail.com (Doug Jones)
Date: Thu, 12 Jun 2008 16:24:22 -0400
Subject: [IPython-dev] coercing to Unicode error in
	IPython.MultiEngineClient
In-Reply-To: <6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com>
References: <1315be7e0806101157v32887855mb6ad81de4a6e795d@mail.gmail.com>
	<6ce0ac130806101255n5f9fd364w2bef31d4883b09c@mail.gmail.com>
	<1315be7e0806101319la74b7fcyf041443765b419d2@mail.gmail.com>
	<6ce0ac130806101322m25e3c473nfb3b4904b7d7e640@mail.gmail.com>
	<1315be7e0806111337l31514ce1s61745db66ef9c742@mail.gmail.com>
	<6ce0ac130806111349q3a69757bo3b99af7d6d642883@mail.gmail.com>
	<1315be7e0806121233s7d5bb645pfb82ee32c124aff1@mail.gmail.com>
	<6ce0ac130806121305p1b3aca25mbd74ab1b9b7ff49f@mail.gmail.com>
Message-ID: <1315be7e0806121324s25d6ac77g1499c14218356750@mail.gmail.com>

Ok. The traceback at the end of my last message also seems to occur with
Python 2.5 now. This issue seems to have cropped up in one of the most
recent commits, since I didn't notice it yesterday.

~doug

python setup.py install --prefix=$HOME/local
============================================================================
BUILDING IPYTHON
                python: 2.5.2 (r252:60911, Jun 10 2008, 15:09:04)  [GCC
                        4.1.2 (Gentoo 4.1.2 p1.0.1)]
              platform: linux2

OPTIONAL DEPENDENCIES
        Zope.Interface: yes
               Twisted: 2.5.0
              Foolscap: 0.2.8
               OpenSSL: 0.7
                sphinx: 0.3
              pygments: 0.10
                  nose: 0.9.3
               pexpect: 2.1
running install
running build
running build_py
running build_scripts
running install_lib
copying build/lib/IPython/Extensions/ipy_completers.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/Extensions
copying build/lib/IPython/Release.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython
copying build/lib/IPython/config/api.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config
copying build/lib/IPython/config/tests/sample_config.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests
copying build/lib/IPython/config/tests/test_config.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests
copying build/lib/IPython/config/tests/__init__.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests
copying build/lib/IPython/config/config.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config
copying build/lib/IPython/config/traitlets.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/config
copying build/lib/IPython/UserConfig/__init__.py ->
/home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig
copying build/lib/IPython/UserConfig/__init__.pyc ->
/home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig
copying build/lib/IPython/UserConfig/ipy_user_conf.pyc ->
/home/djones/local/lib64/python2.5/site-packages/IPython/UserConfig
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/Extensions/ipy_completers.py
to ipy_completers.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/Release.py to
Release.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/api.py to
api.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/sample_config.py
to sample_config.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/test_config.py
to test_config.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/tests/__init__.py
to __init__.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/config.py to
config.pyc
byte-compiling
/home/djones/local/lib64/python2.5/site-packages/IPython/config/traitlets.py
to traitlets.pyc
running install_scripts
copying build/scripts-2.5/ipengine -> /home/djones/local/bin
copying build/scripts-2.5/irunner -> /home/djones/local/bin
copying build/scripts-2.5/pycolor -> /home/djones/local/bin
copying build/scripts-2.5/ipcluster -> /home/djones/local/bin
copying build/scripts-2.5/ipcontroller -> /home/djones/local/bin
copying build/scripts-2.5/ipython -> /home/djones/local/bin
changing mode of /home/djones/local/bin/ipengine to 755
changing mode of /home/djones/local/bin/irunner to 755
changing mode of /home/djones/local/bin/pycolor to 755
changing mode of /home/djones/local/bin/ipcluster to 755
changing mode of /home/djones/local/bin/ipcontroller to 755
changing mode of /home/djones/local/bin/ipython to 755
running install_data
Traceback (most recent call last):
  File "setup.py", line 174, in <module>
    setup(**setup_args)
  File "/usr/lib64/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib64/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/usr/lib64/python2.5/distutils/command/install.py", line 510, in run
    self.run_command(cmd_name)
  File "/usr/lib64/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py", line
75, in run
    (out, _) = self.copy_file(f, dir)
  File "/usr/lib64/python2.5/distutils/cmd.py", line 376, in copy_file
    dry_run=self.dry_run)
  File "/usr/lib64/python2.5/distutils/file_util.py", line 117, in copy_file
    if not os.path.isfile(src):
  File "/usr/lib64/python2.5/posixpath.py", line 208, in isfile
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, list found


On Thu, Jun 12, 2008 at 4:05 PM, Brian Granger <ellisonbg.net at gmail.com>
wrote:

> Doug,
>
> We haven't thought about this yet and it is a big issue.  I will make
> another post about this that we can all use to work out this issue.
>
> Brian
>
> On Thu, Jun 12, 2008 at 1:33 PM, Doug Jones <dfj225 at gmail.com> wrote:
> > Hi Brian,
> >
> > I ran into some more issues installing IPython on a different machine.
> This
> > machine runs Python 2.4 and it seems that some of the IPython code is now
> > using the 'with' statement, which I don't think is included in Python
> 2.4.
> > Is 2.4 no longer supported?
> >
> > The trace from my setup.py install attempt has been copied at the end of
> the
> > message.
> >
> > Thanks,
> > ~Doug
> >
> > Note: I'd already executed a python setup.py build without error.
> >
> >  python setup.py install --prefix=$HOME/local
> >
> ============================================================================
> > BUILDING IPYTHON
> >                 python: 2.4.4 (#1, Jul 29 2007, 19:42:10)  [GCC 4.1.1
> >                         (Gentoo 4.1.1-r3)]
> >               platform: linux2
> >
> > OPTIONAL DEPENDENCIES
> >         Zope.Interface: yes
> >                Twisted: 2.5.0
> >               Foolscap: 0.2.8
> >                OpenSSL: 0.6
> >                 sphinx: 0.3
> >               pygments: 0.10
> >                   nose: 0.10.3
> >                pexpect: 0.999
> > running install
> > running build
> > running build_py
> > running build_scripts
> > running install_lib
> > byte-compiling
> > /home/djones/local/lib/python2.4/site-packages/IPython/config/config.py
> to
> > config.pyc
> >   File
> >
> "/home/djones/local/lib/python2.4/site-packages/IPython/config/config.py",
> > line 49
> >     with raw(self):
> >            ^
> > SyntaxError: invalid syntax
> > byte-compiling
> > /home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py
> to
> > contexts.pyc
> >   File
> >
> "/home/djones/local/lib/python2.4/site-packages/IPython/kernel/contexts.py",
> > line 171
> >     with parallel as pr:
> >                 ^
> > SyntaxError: invalid syntax
> > running install_scripts
> > changing mode of /home/djones/local/bin/pycolor to 755
> > changing mode of /home/djones/local/bin/ipengine to 755
> > changing mode of /home/djones/local/bin/ipcontroller to 755
> > changing mode of /home/djones/local/bin/ipcluster to 755
> > changing mode of /home/djones/local/bin/ipython to 755
> > changing mode of /home/djones/local/bin/irunner to 755
> > running install_data
> > Traceback (most recent call last):
> >   File "setup.py", line 174, in ?
> >     setup(**setup_args)
> >   File "/usr/lib/python2.4/distutils/core.py", line 149, in setup
> >     dist.run_commands()
> >   File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands
> >     self.run_command(cmd)
> >   File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
> >     cmd_obj.run()
> >   File "/usr/lib/python2.4/distutils/command/install.py", line 510, in
> run
> >     self.run_command(cmd_name)
> >   File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command
> >     self.distribution.run_command(command)
> >   File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
> >     cmd_obj.run()
> >   File "/home/djones/ipython_src/ipython/setupext/install_data_ext.py",
> line
> > 75, in run
> >     (out, _) = self.copy_file(f, dir)
> >   File "/usr/lib/python2.4/distutils/cmd.py", line 376, in copy_file
> >     dry_run=self.dry_run)
> >   File "/usr/lib/python2.4/distutils/file_util.py", line 117, in
> copy_file
> >     if not os.path.isfile(src):
> >   File "/usr/lib/python2.4/posixpath.py", line 208, in isfile
> >     st = os.stat(path)
> > TypeError: coercing to Unicode: need string or buffer, list found
> >
> >
> >
> >
> > On Wed, Jun 11, 2008 at 4:49 PM, Brian Granger <ellisonbg.net at gmail.com>
> > wrote:
> >>
> >> > Connecting with the MultiEngineClient is working now. It seems that it
> >> > was
> >> > simply from passing the wrong arguments to the constructor that I was
> >> > having
> >> > problems before.
> >> >
> >> > All in all, I think the furl files are an improvement and the addition
> >> > of
> >> > secure connections is certainly appreciated.
> >>
> >> Thanks for the feedback.  We _really_ needed to address the security
> >> issue and I think Foolscap and the furls really work well.  They give
> >> a high level of security, but make it pretty easy to setup.
> >>
> >> Brian
> >>
> >> > Thanks,
> >> > ~doug
> >> >
> >> > On Tue, Jun 10, 2008 at 4:22 PM, Brian Granger <ellisonbg.net@
> gmail.com>
> >> > wrote:
> >> >>
> >> >> > Thanks for the information. I thought I had used the configuration
> >> >> > creation
> >> >> > command to create .furl files in my home directory. Right now, i'm
> >> >> > using
> >> >> > mpiexec to start the engines, so perhaps this is creating some sort
> >> >> > of
> >> >> > issue
> >> >> > with the shell environment the engines are created in. I'll double
> >> >> > check
> >> >> > and
> >> >> > let you know if I continue to have problems.
> >> >>
> >> >> Hmm, if you are editing the ipython config files to set the locations
> >> >> of the furl files, that should work.  Maybe the only thing you need
> to
> >> >> change is how you are creating the MultiEngineClient.
> >> >>
> >> >> It no longer takes the (ip, port) tuple.  It now takes the name of
> the
> >> >> furl file, or if empty it will use the location given in the config
> >> >> files.
> >> >>
> >> >> Keep me posted.
> >> >>
> >> >> Brian
> >> >>
> >> >> > ~doug
> >> >> >
> >> >> >
> >> >> > On Tue, Jun 10, 2008 at 3:55 PM, Brian Granger
> >> >> > <ellisonbg.net at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> This is not a unicode error, but rather, our API for starting the
> >> >> >> client has changed due to the new security stuff.  This is the
> stuff
> >> >> >> that I am working on documenting as we speak.
> >> >> >>
> >> >> >> Here is a minimal description:
> >> >> >>
> >> >> >> 1) When the controller now starts, it creates a set of files (in
> >> >> >> your
> >> >> >> .ipython directory by default)
> >> >> >>
> >> >> >> ipcontroller-tc.furl
> >> >> >> ipcontroller-mec.furl
> >> >> >> ipcontroller-engine.furl
> >> >> >>
> >> >> >> 2)  These files contain a secure URL that 1) tells the engine and
> >> >> >> clients where the controller is running and 2) gives the engine
> and
> >> >> >> clients authority to connect to the controller in a secure manner.
> >> >> >>
> >> >> >> 3) To use these files, they have to be available to the client and
> >> >> >> engines when they start.  The easiest way of handling this is to
> >> >> >>
> >> >> >> a) copy ipcontroller-engine.furl to the .ipython directory on the
> >> >> >> machine(s) where the engines will run
> >> >> >>
> >> >> >> b) copy ipcontroller-tc and -mec to the .ipython dir of the
> machine
> >> >> >> where the clients will run.
> >> >> >>
> >> >> >> Then everything will "just work".  By this, I mean that you can
> >> >> >> create
> >> >> >> the clients with no arguments:
> >> >> >>
> >> >> >> mec = client.MultiEngineClient()
> >> >> >>
> >> >> >> If you have put the .furl files in different locations you can do:
> >> >> >>
> >> >> >> mec =
> >> >> >>
> >> >> >>
> client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')
> >> >> >>
> >> >> >> In all of this, you can think of the furl files as being keys
> (just
> >> >> >> like a house key) that grants an entity access to a particular
> >> >> >> resource.  The controller creates the keys and the engines/client
> >> >> >> must
> >> >> >> present/use them to use the capabilities of the controller.
> >> >> >>
> >> >> >> See if you can use this to get things working.  The big benefit of
> >> >> >> using all this is:
> >> >> >>
> >> >> >> 1) Users don't have to track what ip/port the controller is
> running
> >> >> >> on.
> >> >> >>
> >> >> >> 2) Everything is secure by default - authentication + encryption
> (if
> >> >> >> you have pyOpenSSL installed
> >> >> >>
> >> >> >> 3) The controller now uses random port numbers, making it even
> more
> >> >> >> difficult for hostiles to discover.
> >> >> >>
> >> >> >> Let me know if you have any more problems getting this working.
>  We
> >> >> >> would love feedback if you have ideas of how things could be made
> >> >> >> easier.
> >> >> >>
> >> >> >> Also, check out the new command line flags on the ipcontroller and
> >> >> >> ipengine scripts to control where the furl files are created and
> >> >> >> looked for.
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Brian
> >> >> >>
> >> >> >> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com>
> >> >> >> wrote:
> >> >> >> > Hi all,
> >> >> >> >
> >> >> >> > I tried a simple test of the latest IPython branch and the
> >> >> >> > MultiEngineClient. When I attempted to connect to a running
> >> >> >> > cluster
> >> >> >> > on
> >> >> >> > my
> >> >> >> > local machine, I got the following error:
> >> >> >> >
> >> >> >> >  mec = client.MultiEngineClient(('localhost', 10105))
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> ---------------------------------------------------------------------------
> >> >> >> > TypeError                                 Traceback (most recent
> >> >> >> > call
> >> >> >> > last)
> >> >> >> >
> >> >> >> > /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in
> >> >> >> > <module>()
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
> >> >> >> > in get_multiengine_client(furl_or_file)
> >> >> >> >      67     """
> >> >> >> >      68     client =
> >> >> >> > blockingCallFromThread(_client_tub.get_multiengine_client,
> >> >> >> > ---> 69         furl_or_file)
> >> >> >> >      70     return client.adapt_to_blocking_client()
> >> >> >> >      71
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
> >> >> >> > in blockingCallFromThread(f, *a, **kw)
> >> >> >> >      97                 result.raiseException()
> >> >> >> >      98             except Exception, e:
> >> >> >> > ---> 99                 raise e
> >> >> >> >     100         return result
> >> >> >> >     101
> >> >> >> >
> >> >> >> > TypeError: coercing to Unicode: need string or buffer, tuple
> found
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > ~Doug
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > IPython-dev mailing list
> >> >> >> > IPython-dev at scipy.org
> >> >> >> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080612/180b0858/attachment.html>

From fperez.net at gmail.com  Thu Jun 12 16:27:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Jun 2008 13:27:40 -0700
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
Message-ID: <db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>

On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> Now that all of the stuff from ipython1 has moved into IPython,
> IPython has new fancy parallel computing capabilities.....and..... a
> dependency on Python 2.5.
>
> Here is the story.  In IPython.kernel there is a likely lots of code
> that requires python 2.4, and a little that requires 2.5.  At this
> point, it is probably too late to get rid of the 2.4 specific stuff,
> but we still have to figure out what to do about 2.5 specific syntax
> and features.
>
> The main things are our usage of the with statement.  Currently
> building IPython with <2.5 gives a syntax error because of this.  We
> clearly need to fix this as IPython definitely needs to run under 2.4.
>  But, how do we want to handle these things?  Requires 2.4 and make
> 2.5 features optional?  Thoughts?

I have a few minutes of network...

I can't test which step fails right now,  because the setup.py install
is crashing for me with all versions:

Traceback (most recent call last):
  File "setup.py", line 174, in <module>
    setup(**setup_args)
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run
    self.run_command(cmd_name)
  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py",
line 75, in run
    (out, _) = self.copy_file(f, dir)
  File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file
    dry_run=self.dry_run)
  File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file
    if not os.path.isfile(src):
  File "/usr/lib/python2.5/posixpath.py", line 208, in isfile
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, list found


In a couple of hours I may be able to pull bzr again and will test.  I
can play with alternatives for the 2.5 dependency.

I think we'll have to be OK with 2.4 as a dependency for versions >=
0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
context managers in there, the idea is too cool not to put it  in.
But we need them to be optional.  The trick is to exclude them from
the build process if the  setup.py file is processed with python2.4,
since they simply won't compile at all (the with statement is a syntax
error).

It may require a bit of distutils hackery with the MANIFEST.in, but I
don't think it's impossible to make them optional.

Cheers,

f


From ellisonbg.net at gmail.com  Thu Jun 12 16:29:37 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:29:37 -0600
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
Message-ID: <6ce0ac130806121329m22ad7ecfo17b90a48fe751adb@mail.gmail.com>

Yep, Doug just pointed this problem out to me.  I will fix right now.
I think I am the responsible one for this.  Sorry.

Brian

On Thu, Jun 12, 2008 at 2:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hi,
>>
>> Now that all of the stuff from ipython1 has moved into IPython,
>> IPython has new fancy parallel computing capabilities.....and..... a
>> dependency on Python 2.5.
>>
>> Here is the story.  In IPython.kernel there is a likely lots of code
>> that requires python 2.4, and a little that requires 2.5.  At this
>> point, it is probably too late to get rid of the 2.4 specific stuff,
>> but we still have to figure out what to do about 2.5 specific syntax
>> and features.
>>
>> The main things are our usage of the with statement.  Currently
>> building IPython with <2.5 gives a syntax error because of this.  We
>> clearly need to fix this as IPython definitely needs to run under 2.4.
>>  But, how do we want to handle these things?  Requires 2.4 and make
>> 2.5 features optional?  Thoughts?
>
> I have a few minutes of network...
>
> I can't test which step fails right now,  because the setup.py install
> is crashing for me with all versions:
>
> Traceback (most recent call last):
>  File "setup.py", line 174, in <module>
>    setup(**setup_args)
>  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>    dist.run_commands()
>  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>    self.run_command(cmd)
>  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>    cmd_obj.run()
>  File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run
>    self.run_command(cmd_name)
>  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>    self.distribution.run_command(command)
>  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>    cmd_obj.run()
>  File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py",
> line 75, in run
>    (out, _) = self.copy_file(f, dir)
>  File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file
>    dry_run=self.dry_run)
>  File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file
>    if not os.path.isfile(src):
>  File "/usr/lib/python2.5/posixpath.py", line 208, in isfile
>    st = os.stat(path)
> TypeError: coercing to Unicode: need string or buffer, list found
>
>
> In a couple of hours I may be able to pull bzr again and will test.  I
> can play with alternatives for the 2.5 dependency.
>
> I think we'll have to be OK with 2.4 as a dependency for versions >=
> 0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
> context managers in there, the idea is too cool not to put it  in.
> But we need them to be optional.  The trick is to exclude them from
> the build process if the  setup.py file is processed with python2.4,
> since they simply won't compile at all (the with statement is a syntax
> error).
>
> It may require a bit of distutils hackery with the MANIFEST.in, but I
> don't think it's impossible to make them optional.
>
> Cheers,
>
> f
>


From robert.kern at gmail.com  Thu Jun 12 16:34:43 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 12 Jun 2008 15:34:43 -0500
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
 we need to fix this
In-Reply-To: <db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
Message-ID: <g2s194$gcs$1@ger.gmane.org>

Fernando Perez wrote:

> I think we'll have to be OK with 2.4 as a dependency for versions >=
> 0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
> context managers in there, the idea is too cool not to put it  in.

You can define the context managers all you like as long as you don't use them 
in the library code itself. As far as I can tell, the only place you actually 
use a with statement is in the demo code at the bottom of context.py which, as 
noted in the comments, really ought to be moved into a real test suite.

> But we need them to be optional.  The trick is to exclude them from
> the build process if the  setup.py file is processed with python2.4,
> since they simply won't compile at all (the with statement is a syntax
> error).

I have seen this give warnings, but I don't think it stops the build, usually.

-- 
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 fperez.net at gmail.com  Thu Jun 12 16:41:37 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Jun 2008 13:41:37 -0700
Subject: [IPython-dev] ChangLog vs changes.txt
In-Reply-To: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com>
References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com>
Message-ID: <db6b5ecc0806121341r5ad73b01lc3c6f5f24b7425b6@mail.gmail.com>

On Thu, Jun 12, 2008 at 11:36 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> In the process of reorganizing the IPython documentation, I ran into
> something related to the ChangeLog.  In the past, IPython has used a
> traditional ChangeLog for devs to record the changes they have made to
> the project.  This was used to keep track of who has done what and
> what things have been done since the last release.  In IPython1 on the
> other hand, I had moved away from using the ChangeLog for the
> following reasons:
>
> 1.  A linear ChangeLog is a poor reflection of what happens to the
> core when a distributed VCS is used.  In fact, I would say it could
> potentially be downright confusing.
>
> 2.  The ChangeLog really is a repetition of the information that is
> contained in the commit messages (which in a DVCS do reflect the
> distributed/parallel nature of development).
>
> 3.  The ChangeLog doesn't really give users anything useful.  Sure
> they could read it, but it is not written in a user focused manner and
> they would have to sift through a lot of irrelevant information.
>
> 4.  To generate things like release notes, what's new, api changes
> etc. (user focused docs), someone has to do the tedious task of
> looking through the ChangeLog and summarizing the changes in user
> friendly form.  The success of this is shown in the lack of user
> focued high quality release notes, what new and api change
> documentation for IPython.
>
> 5. For those of us who don't use emacs, the format of the ChangeLog
> leaves something to be desired.
>
> 6.  The ChangeLog format does not integrate with our Sphinx docs as it
> is not rst.
>
> To address these issue with IPython1, we recently went the following route:
>
> 1.  We no longer maintain a ChangeLog
>
> 2.  We instead have a changes.txt files that is 1) regular rst and 2)
> part of our Sphinx based docs.
>
> This document lists changes for each release of IPython separately and
> for each release, includes three sections: new features, bug fixes and
> backward incompatible changes.  The goal of this document is to record
> in a user focused way all of the changes to IPython.  I was inspired
> to create this after looking at how a number of different projects
> handle this issue.
>
> So, for now I have left the IPython ChangeLog in place, but I propose
> that we abandon it (move it to docs/attic) and begin using the new
> document that I have created:
>
> docs/source/changes.txt
>
> At some level, I picture this file as part of our contract with users.
>  If there is something new that a user needs to know about IPython,
> this is where they should look.  Also note that the file immediately
> provides a usable release notes for our releases.


Yup, when I did the big bzr merge I mentioned that the old-style
changelog was likely the only file that would probably cause recurrent
merge conflicts if we tried to use it, so it would be best to stop
now.  Ville concurred, if I recall correctly.

One comment on this: with SVN, we were used to very terse commit
messages and the more detailed info in the changelog.  I'd like to
encourage everyone now to do the following, since the commit log will
be *the* history: use a docstring-like approach in the commit
messages:

"""Single line summary of  changes being committed.
# BLANK LINE
- more
- details
- when
- warranted ...
- including crediting outside contributors if they sent the code/bug/idea!
"""

If we couple this with a policy of making single commits for each
reasonably atomic change, the bzr log should give an excellent view of
the project, and the --short log option becomes a nice summary.

I've added this to the rst dev guidelines now.


Cheers,

f


From ellisonbg.net at gmail.com  Thu Jun 12 16:45:37 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:45:37 -0600
Subject: [IPython-dev] ChangLog vs changes.txt
In-Reply-To: <db6b5ecc0806121341r5ad73b01lc3c6f5f24b7425b6@mail.gmail.com>
References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com>
	<db6b5ecc0806121341r5ad73b01lc3c6f5f24b7425b6@mail.gmail.com>
Message-ID: <6ce0ac130806121345v3af7afb3t7ab6bdb61d630358@mail.gmail.com>

On Thu, Jun 12, 2008 at 2:41 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jun 12, 2008 at 11:36 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hi,
>>
>> In the process of reorganizing the IPython documentation, I ran into
>> something related to the ChangeLog.  In the past, IPython has used a
>> traditional ChangeLog for devs to record the changes they have made to
>> the project.  This was used to keep track of who has done what and
>> what things have been done since the last release.  In IPython1 on the
>> other hand, I had moved away from using the ChangeLog for the
>> following reasons:
>>
>> 1.  A linear ChangeLog is a poor reflection of what happens to the
>> core when a distributed VCS is used.  In fact, I would say it could
>> potentially be downright confusing.
>>
>> 2.  The ChangeLog really is a repetition of the information that is
>> contained in the commit messages (which in a DVCS do reflect the
>> distributed/parallel nature of development).
>>
>> 3.  The ChangeLog doesn't really give users anything useful.  Sure
>> they could read it, but it is not written in a user focused manner and
>> they would have to sift through a lot of irrelevant information.
>>
>> 4.  To generate things like release notes, what's new, api changes
>> etc. (user focused docs), someone has to do the tedious task of
>> looking through the ChangeLog and summarizing the changes in user
>> friendly form.  The success of this is shown in the lack of user
>> focued high quality release notes, what new and api change
>> documentation for IPython.
>>
>> 5. For those of us who don't use emacs, the format of the ChangeLog
>> leaves something to be desired.
>>
>> 6.  The ChangeLog format does not integrate with our Sphinx docs as it
>> is not rst.
>>
>> To address these issue with IPython1, we recently went the following route:
>>
>> 1.  We no longer maintain a ChangeLog
>>
>> 2.  We instead have a changes.txt files that is 1) regular rst and 2)
>> part of our Sphinx based docs.
>>
>> This document lists changes for each release of IPython separately and
>> for each release, includes three sections: new features, bug fixes and
>> backward incompatible changes.  The goal of this document is to record
>> in a user focused way all of the changes to IPython.  I was inspired
>> to create this after looking at how a number of different projects
>> handle this issue.
>>
>> So, for now I have left the IPython ChangeLog in place, but I propose
>> that we abandon it (move it to docs/attic) and begin using the new
>> document that I have created:
>>
>> docs/source/changes.txt
>>
>> At some level, I picture this file as part of our contract with users.
>>  If there is something new that a user needs to know about IPython,
>> this is where they should look.  Also note that the file immediately
>> provides a usable release notes for our releases.
>
>
> Yup, when I did the big bzr merge I mentioned that the old-style
> changelog was likely the only file that would probably cause recurrent
> merge conflicts if we tried to use it, so it would be best to stop
> now.  Ville concurred, if I recall correctly.
>
> One comment on this: with SVN, we were used to very terse commit
> messages and the more detailed info in the changelog.  I'd like to
> encourage everyone now to do the following, since the commit log will
> be *the* history: use a docstring-like approach in the commit
> messages:
>
> """Single line summary of  changes being committed.
> # BLANK LINE
> - more
> - details
> - when
> - warranted ...
> - including crediting outside contributors if they sent the code/bug/idea!
> """
>
> If we couple this with a policy of making single commits for each
> reasonably atomic change, the bzr log should give an excellent view of
> the project, and the --short log option becomes a nice summary.
>
> I've added this to the rst dev guidelines now.

Great!

Brian

>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Thu Jun 12 16:46:46 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Jun 2008 13:46:46 -0700
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <g2s194$gcs$1@ger.gmane.org>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
	<g2s194$gcs$1@ger.gmane.org>
Message-ID: <db6b5ecc0806121346o20ba80bch6d23410d4e892c63@mail.gmail.com>

On Thu, Jun 12, 2008 at 1:34 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Fernando Perez wrote:
>
>> I think we'll have to be OK with 2.4 as a dependency for versions >=
>> 0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
>> context managers in there, the idea is too cool not to put it  in.
>
> You can define the context managers all you like as long as you don't use them
> in the library code itself. As far as I can tell, the only place you actually
> use a with statement is in the demo code at the bottom of context.py which, as
> noted in the comments, really ought to be moved into a real test suite.

Yup, correct, I forgot that the actual  managers do NOT use 'with',
they only define the special methods the with protocol uses.

We just need to move that code into the tests and make sure they get
cleanly skipped with 2.4, and we're clear.  Thanks for the reminder.

Since I'll be working on the tests, I'll take care of this.

Cheers,

f


From ellisonbg.net at gmail.com  Thu Jun 12 16:48:27 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:48:27 -0600
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <db6b5ecc0806121346o20ba80bch6d23410d4e892c63@mail.gmail.com>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
	<g2s194$gcs$1@ger.gmane.org>
	<db6b5ecc0806121346o20ba80bch6d23410d4e892c63@mail.gmail.com>
Message-ID: <6ce0ac130806121348l49a37110kabcc9f7de3b58242@mail.gmail.com>

>> You can define the context managers all you like as long as you don't use them
>> in the library code itself. As far as I can tell, the only place you actually
>> use a with statement is in the demo code at the bottom of context.py which, as
>> noted in the comments, really ought to be moved into a real test suite.

This is true, I don't think we actually need to use the with statement
at this point in library code.  We just need to be able to define the
context managers.

> Since I'll be working on the tests, I'll take care of this.

Thanks.

Brian

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


From ellisonbg.net at gmail.com  Thu Jun 12 16:51:16 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Jun 2008 14:51:16 -0600
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
Message-ID: <6ce0ac130806121351q1f909facs970db886e8a34f35@mail.gmail.com>

I have removed the offending code in setupbase.find_data_files.  My
fix is only temporary, for now the method returns an empty list so no
data_files will be installed.  But I am doing a full audit/fix of this
code.

Cheers and sorry about this.

Brian

On Thu, Jun 12, 2008 at 2:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Jun 12, 2008 at 1:11 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hi,
>>
>> Now that all of the stuff from ipython1 has moved into IPython,
>> IPython has new fancy parallel computing capabilities.....and..... a
>> dependency on Python 2.5.
>>
>> Here is the story.  In IPython.kernel there is a likely lots of code
>> that requires python 2.4, and a little that requires 2.5.  At this
>> point, it is probably too late to get rid of the 2.4 specific stuff,
>> but we still have to figure out what to do about 2.5 specific syntax
>> and features.
>>
>> The main things are our usage of the with statement.  Currently
>> building IPython with <2.5 gives a syntax error because of this.  We
>> clearly need to fix this as IPython definitely needs to run under 2.4.
>>  But, how do we want to handle these things?  Requires 2.4 and make
>> 2.5 features optional?  Thoughts?
>
> I have a few minutes of network...
>
> I can't test which step fails right now,  because the setup.py install
> is crashing for me with all versions:
>
> Traceback (most recent call last):
>  File "setup.py", line 174, in <module>
>    setup(**setup_args)
>  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
>    dist.run_commands()
>  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
>    self.run_command(cmd)
>  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>    cmd_obj.run()
>  File "/usr/lib/python2.5/distutils/command/install.py", line 510, in run
>    self.run_command(cmd_name)
>  File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command
>    self.distribution.run_command(command)
>  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
>    cmd_obj.run()
>  File "/home/fperez/ipython/bzr-repo/trunk-dev/setupext/install_data_ext.py",
> line 75, in run
>    (out, _) = self.copy_file(f, dir)
>  File "/usr/lib/python2.5/distutils/cmd.py", line 376, in copy_file
>    dry_run=self.dry_run)
>  File "/usr/lib/python2.5/distutils/file_util.py", line 117, in copy_file
>    if not os.path.isfile(src):
>  File "/usr/lib/python2.5/posixpath.py", line 208, in isfile
>    st = os.stat(path)
> TypeError: coercing to Unicode: need string or buffer, list found
>
>
> In a couple of hours I may be able to pull bzr again and will test.  I
> can play with alternatives for the 2.5 dependency.
>
> I think we'll have to be OK with 2.4 as a dependency for versions >=
> 0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
> context managers in there, the idea is too cool not to put it  in.
> But we need them to be optional.  The trick is to exclude them from
> the build process if the  setup.py file is processed with python2.4,
> since they simply won't compile at all (the with statement is a syntax
> error).
>
> It may require a bit of distutils hackery with the MANIFEST.in, but I
> don't think it's impossible to make them optional.
>
> Cheers,
>
> f
>


From benjaminrk at gmail.com  Thu Jun 12 16:54:32 2008
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 12 Jun 2008 13:54:32 -0700
Subject: [IPython-dev] Critical: For now IPython requires Python 2.5 -
	we need to fix this
In-Reply-To: <g2s194$gcs$1@ger.gmane.org>
References: <6ce0ac130806121311u273b9402p7506e0a3d5af8341@mail.gmail.com>
	<db6b5ecc0806121327o124173e4o41d6d9f1290e5643@mail.gmail.com>
	<g2s194$gcs$1@ger.gmane.org>
Message-ID: <ea108cfa0806121354x32bf48d1qff93bb25477f55e7@mail.gmail.com>

I just did a test install in 2.4, and it works fine.  It throws SyntaxErrors
during setup, but the install still completes and regular IPython works
fine.  I get the SyntaxErrors again (in kernel.config) if I try to import
kernel.client, but it's certainly not a widespread problem.  Only
kernel/config and kernel/contexts seem to have the issue, which should be
easy to remedy.

-MinRK

On Thu, Jun 12, 2008 at 1:34 PM, Robert Kern <robert.kern at gmail.com> wrote:

> Fernando Perez wrote:
>
> > I think we'll have to be OK with 2.4 as a dependency for versions >=
> > 0.9, but 2.5 is definitely a little harsh.  I *really* want those cool
> > context managers in there, the idea is too cool not to put it  in.
>
> You can define the context managers all you like as long as you don't use
> them
> in the library code itself. As far as I can tell, the only place you
> actually
> use a with statement is in the demo code at the bottom of context.py which,
> as
> noted in the comments, really ought to be moved into a real test suite.
>
> > But we need them to be optional.  The trick is to exclude them from
> > the build process if the  setup.py file is processed with python2.4,
> > since they simply won't compile at all (the with statement is a syntax
> > error).
>
> I have seen this give warnings, but I don't think it stops the build,
> usually.
>
> --
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080612/c473b469/attachment.html>

From fperez.net at gmail.com  Thu Jun 12 16:57:56 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Jun 2008 13:57:56 -0700
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1012: Merging
	edits to development.txt
In-Reply-To: <-5364037501704686174@unknownmsgid>
References: <-5364037501704686174@unknownmsgid>
Message-ID: <db6b5ecc0806121357l26ed330lb32b257c67bb12e7@mail.gmail.com>

Hey guys,

we're still getting this 'folding' problem it seems.  I think with
true merges we can't avoid it, but I thought if we all used pull on
our local copy of the trunk we could minimize it, no?  That's what I
was trying to use (bzr pull instead of bzr merge) and it seemed to be
working...

No big deal, but I'd like to keep our log linear when the underlying
development was indeed linear (as this little change was).  Let's see
if the pull approach works better.

Anyway, I'm offline now again...

Cheers,

f

On Thu, Jun 12, 2008 at 1:47 PM,  <noreply at launchpad.net> wrote:
> ------------------------------------------------------------
> revno: 1012
> committer: Brian E Granger <ellisonbg at gmail.com>
> branch nick: ipython
> timestamp: Thu 2008-06-12 14:46:16 -0600
> message:
>  Merging edits to development.txt
> modified:
>  docs/source/development/development.txt
>    ------------------------------------------------------------
>    revno: 1010.1.1
>    committer: Fernando Perez <Fernando.Perez at berkeley.edu>
>    branch nick: trunk-dev
>    timestamp: Thu 2008-06-12 13:39:18 -0700
>    message:
>      Update dev guide with commit message guidelines
>    modified:
>      docs/source/development/development.txt
>
> === modified file 'docs/source/development/development.txt'
> --- a/docs/source/development/development.txt   2008-06-12 19:44:12 +0000
> +++ b/docs/source/development/development.txt   2008-06-12 20:39:18 +0000
> @@ -137,6 +137,22 @@
>        $ ...do work in ipython-mybranch...
>        $ bzr ci -m "the commit message goes here"
>
> +Please note that since we now don't use an old-style linear ChangeLog
> +(that tends to cause problems with distributed version control
> +systems), you should ensure that your log messages are reasonably
> +detailed.  Use a docstring-like approach in the commit messages
> +(including the second line being left *blank*)::
> +
> +  Single line summary of  changes being committed.
> +
> +  - more details when warranted ...
> +  - including crediting outside contributors if they sent the
> +    code/bug/idea!
> +
> +If we couple this with a policy of making single commits for each
> +reasonably atomic change, the bzr log should give an excellent view of
> +the project, and the `--short` log option becomes a nice summary.
> +
>  While working with this branch, it is a good idea to merge in changes that have been
>  made upstream in the parent branch.  This can be done by doing::
>
>
>
>
> --
> Main line of IPython development (stable)
> https://code.launchpad.net/~ipython/ipython/trunk
>
> You are receiving this branch notification because you are subscribed to it.
> To unsubscribe from this branch go to https://code.launchpad.net/~ipython/ipython/trunk/+edit-subscription.
>


From stefan at sun.ac.za  Thu Jun 12 17:32:21 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Jun 2008 23:32:21 +0200
Subject: [IPython-dev] ChangLog vs changes.txt
In-Reply-To: <db6b5ecc0806121341r5ad73b01lc3c6f5f24b7425b6@mail.gmail.com>
References: <6ce0ac130806121136i728f2838q28cc0bfc0fe8767e@mail.gmail.com>
	<db6b5ecc0806121341r5ad73b01lc3c6f5f24b7425b6@mail.gmail.com>
Message-ID: <9457e7c80806121432v5556714didc9ece238d1707a6@mail.gmail.com>

2008/6/12 Fernando Perez <fperez.net at gmail.com>:
> If we couple this with a policy of making single commits for each
> reasonably atomic change, the bzr log should give an excellent view of
> the project, and the --short log option becomes a nice summary.

I spoke to some Launchpad guys last night, and they assured me that
they are working on an improved log display, like the one in olive.
While not ideal, the following view is marginally more useful:

http://bazaar.launchpad.net/~ipython/ipython/trunk/changes

As for the folding back:

- The 'pull' command is really only for mirroring branches.  If you
don't want an identical copy of a branch, you shouldn't need to pull.

- If two branches diverge (which happens when you add revisions to
*both* branches at the node where they were split), a merge is
necessary to bring them together again.  In SVN, we were used to doing
"svn update", which then brought all the changes from the trunk into
your local working copy.  Only if there was a conflict were you
required to do a merge.  In bzr, these merges are no longer optional
(and you are forced to check in before merging, which is a good
idea!).

Since bzr needs to track those merges, you can also see them in the
log file.  If you prefer, you may choose to suppress these log
entries, but with sensical merge messages (as David suggested), they
become useful.

I suspect they bother us mainly because merging has become such a
scary word in the SVN world.  In the end, it is more of a display
issue, that, to some extent, you have worked around by having an
external release notes file.

I've satisfied my own concerns about bzr, but if you have any further
concerns, I'd gladly research the issue further.

Regards
St?fan


From fperez.net at gmail.com  Fri Jun 13 08:41:15 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 13 Jun 2008 05:41:15 -0700
Subject: [IPython-dev] Fwd: EuroSciPy Early Registration Reminder
Message-ID: <db6b5ecc0806130541o6294a83am53ecfd1fdfab0517@mail.gmail.com>

# From Travis Vaught @ Enthought:

Greetings,

This is a friendly reminder that the Early Registration deadline for
the EuroSciPy Conference is June 15th.  If you're interested in
attending, but have not yet registered, please visit:

http://www.scipy.org/EuroSciPy2008

The talks schedule is also now available there.

Also, the keynote speaker this year will be Travis Oliphant, the
primary author of the recent NumPy rewrite.  For those doing
scientific computing using Python, this is a conference you'll not
want to miss.

See you there.

Travis


From barrywark at gmail.com  Sun Jun 15 19:03:31 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 15 Jun 2008 16:03:31 -0700
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
Message-ID: <cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>

I'm getting close to being ready to merge the ipython-frontend branch
into trunk. At this point, I would like to update folks on the status
of IPython.frontend and solicit comments and review before things get
merged to trunk..

====
Overview
====

IPython's InteractiveShell (in 0.8.4) is currently tied to the
terminal. Thus, alternative frontends that integrate with native GUI
toolkits and provide alternative rendering functionality (something
like a Mathematica notebook-style interface) are currently very
difficult implement with the IPython InteractiveShell. With the
integration of ipython1 into IPython, we now have the opportunity to
separate the interpreter/engine from the UI and to make it easier to
write other types of frontends for IPython. In the IPython.frontend
package, we intend to provide base functionality to make writing these
frontends easier.

As a proof of concept, I've written a frontend for IPython in the
Cocoa toolkit for OS X. This Cocoa frontend is implemented as a
drop-in component that can be included by devleopers of Cocoa apps.
I've also written a demo application that provides a Matlab-style
workspace (command-line and user namespace browser) using this Cocoa
frontend. With the IPython.frontend.frontend.FrontEndBase and the
GUI-integration provided by Twisted, the Cocoa frontend requires about
400 lines of code (including managing the text widget to simulate a
CLI interface).

If you would like to try out the Cocoa interface on OSX, you will
currently need OS X 10.5 or greater with Developer Tools installed.
Download the ipython-frontend branch from launchpad.net. In the
IPython/frontend/cocoa/examples/ folder, you will find an Xcode
project for IPython1Sandbox. Building and running this app should get
you started. Feel free to ask me if you have any questions. Of course
the normal caveats apply: this is VERY new code and many things may
not work. Use at your own risk. When you find bugs, please report them
on launchpad.net/ipython.

====
For Developers
====

The purpose of IPython.frontend is to provide a base class
(frontend.frontendbase.FrontEndBase) for frontend writers to use in
developing GUI frontends for IPython. FrontendBase provides all of the
basic functionality required by the front end (testing for block
completeness, managing history, executing blocks on an
IPython.kernel.engineservice.IEngineBasic-implementing engine, and
rendering results and errors asynchronously (via Twisted deferreds)).
GUI frontends will want to subclass FrontEndBase and override the
render methods (render_result and render_error) to render results and
errors respectively. Each execute request can be assigned a "blockID"
to allow the frontend to identify the block corresponding to the
result/error. The frontend can assign this blockID or a UUID will be
assigned automatically. Frontends may also override update_prompt to
update the input prompt for a block once it's number is known (it may
not be known until the engine executes the block if more than one
client is using the same engine). The subclass must also decide when
to send a block to the engine. For this, FrontEndBase provides
is_complete to test whether a block is a complete statement. Once a
block is complete, the frontend can send it to the engine by passing
it to FrontEndBase's execute method. The result of execute is a
twisted.internet.deferred.Deferred result of the execution of that
block.


At this point, I would appreciate comments on the entire frontend
package before we consider merging ipython-frontend into trunk. There
aren't any changes in the ipython-frontend branch outside of the
IPython.frontend package EXCEPT to
IPython.kernel.engineservice.ThreadedEngineService. I updated
I.kernel.engineservice.ThreadedEngineService so that it now works and
added associated tests in I.kernel.tests.test_engineservice.py. All
tests pass on my Mac. ThreadedEngineService is required to prevent
long-running execute calls from blocking the main GUI thread. There
currently isn't any method for canceling or interrupting an executing
block, but at least it doesn't block the GUI thread. Moving to a
TaskClient instead of ThreadedEngineService might fix this... but
that's for the future.

I'm currently working to improve the documentation/comments, but the
code in there are at least tests for most of the code in
frontend.frontendbase at this point.

- Barry


From barrywark at gmail.com  Mon Jun 16 01:46:35 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 15 Jun 2008 22:46:35 -0700
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <20080616025814.GA31696@phare.normalesup.org>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080616025814.GA31696@phare.normalesup.org>
Message-ID: <cd7634ce0806152246n4f84c03an5bd3306469b53075@mail.gmail.com>

Ga?l,

I hope you don't mind me cc-ing this to the list, in case anyone else
is curious.

You'll need Mac OS X 10.5 and the Apple Developer Tools (Xcode >=
3.0), which come with the OS (or can be downloaded from
developer.apple.com). You can play with the frontend by getting the
ipython-frontend branch from launchpad ('bzr branch
lp:~barrywark/ipython/ipython-frontend'). The demo application depends
on ipython-frontend being installed in the system site-packages, so
install ('sudo setupegg.py install' or 'sudo setupegg.py develop' in
the ipython-frontend/ directory) the ipython-frontend branch. On OS X
10.5, it's best to use setuptools to make sure that the
ipython-frontend installation plays nicely with Apple's system python.
Once installed, you can open the Xcode project file in
ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/.
Running the project from within Xcode _should_ (fingers crossed!)
start the demo frontend.

You'll quickly find that the Cocoa frontend is still quite rough
around the edges. For example, failures are not rendered very
intelligently. There may be many other rendering/UI errors in my text
view-related code. There's also no way to cancel a long-running task
(except by quitting the app), there's no easy way to start an IPython
cluster via Xgrid (though that's an obvious thing to do).... the list
goes on. It's intended (at this point) as just a proof-of-concept for
the frontend package. Eventually, I would like to get away from the
CLI-based frontend and move to a more notebook-like interface.

Barry



On Sun, Jun 15, 2008 at 7:58 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi Barry,
>
> Just a quick question: how can we try out your work (on an Apple box,
> obviously)?
>
> Cheers,
>
> Ga?l
>


From hans_meine at gmx.net  Mon Jun 16 08:30:14 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 16 Jun 2008 14:30:14 +0200
Subject: [IPython-dev] Close to giving up (was: Re: Synchronization with
	Editor)
Message-ID: <200806161430.15508.hans_meine@gmx.net>

Hi Vivian,

this is my Nth try to send you a little feedback, where N must be > 4 I 
think..  Obviously, I always sent from the wrong address.

Ciao, /  /
     /--/
    /  / ANS
-------------- next part --------------
An embedded message was scrubbed...
From: Hans Meine <meine at informatik.uni-hamburg.de>
Subject: Re: [IPython-dev] Synchronization with Editor
Date: Mon, 9 Jun 2008 16:42:24 +0200
Size: 8871
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080616/5c558c8b/attachment.mht>

From vivian at vdesmedt.com  Mon Jun 16 09:50:20 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Mon, 16 Jun 2008 15:50:20 +0200
Subject: [IPython-dev] Close to giving up (was: Re: Synchronization with
 Editor)
In-Reply-To: <200806161430.15508.hans_meine@gmx.net>
References: <200806161430.15508.hans_meine@gmx.net>
Message-ID: <48566F9C.6070203@vdesmedt.com>

Hi Heinz,

Thanks for your technical feedback.

Here are my answer to the three points I have isolated in your mails. 
Tell me if I have missed one.
> * IMO hooks.synchronize_with_editor should be merged with
>   hooks.fix_error_editor.
>   
I suspect IPython to assume that when fix_error_editor hook will return 
the error will be fixed.

So that hook should be synchronous. It should give back the hand to the 
editor and wait that the user validate the changes by closing the editor 
or sending a signal (e.g. emacs).

The synchronize_with_editor hook don't have to be synchronous. It has to 
synchronize the editor with IPython, opening the script file at the 
right line, and return (no user input needed).

So if we merge both hooks I think we should at least add a parameter to 
tell what should be the action of the hook:
 - synchronize and wait for validation before returning or
 - synchronize only and return.

With the multi tab editor or multi buffer editor the first kind of hooks 
are not so easy to write. You don't want to quit the editor at the end 
of the edition and you have no built in way to signal that you have 
finish with the edition of a particular file opened in the editor (emacs 
is the exception).
> * I think the win32 imports should be wrapped in a conditional block 
>   for *nix users to benefit from this.
>   
About the unix version I'll be glad to improve the code to support them 
what I think should be improved is the following:
- The .exe extention should be removed (I just remove them)
 - The name of the executables should be checked (scite, emacsclient, 
gvim, ...)
 - We should provide alternative for runCommand, sleep and 
restoreConsoleFocus

Unfortunately I have no access to a linux box to test possible 
alternatives. If someone could propose something I'll be glad to 
incorporate it into the ip_synchronize_width.py propositions of hooks.

> * Nearly the same code can be used for XEmacs/gnuserv (using gnuclient instead 
>   of gvim as command).
>   
In the emacs version of the hook I have implemented something based on 
emacsclient that seems to works well for emacs at least on the win32 
platform.

Tell me what you think.

Did you had a chance to test the hooks for some editor. Did you find it 
useful or handy?

Kindest regards,
Vivian.



From gael.varoquaux at normalesup.org  Mon Jun 16 10:02:52 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 16 Jun 2008 16:02:52 +0200
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <cd7634ce0806152246n4f84c03an5bd3306469b53075@mail.gmail.com>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080616025814.GA31696@phare.normalesup.org>
	<cd7634ce0806152246n4f84c03an5bd3306469b53075@mail.gmail.com>
Message-ID: <20080616140252.GA3938@phare.normalesup.org>

On Sun, Jun 15, 2008 at 10:46:35PM -0700, Barry Wark wrote:
> I hope you don't mind me cc-ing this to the list, in case anyone else
> is curious.

No, not replying to the list was actually unintended.

> Running the project from within Xcode _should_ (fingers crossed!)
> start the demo frontend.

That was the part that took us a while to get: we just tried to "python
foobar.py" the thing, but apparently Apple likes to "think different",
and this does not work.

> You'll quickly find that the Cocoa frontend is still quite rough
> around the edges. 

My one question is: what is the plan for interacting with the GUI
mainloop. For example how to I open matlplotlib windows?

I guess this is a more general question: what is the road forward on
frontends for this problem?

Ga?l


From barrywark at gmail.com  Mon Jun 16 11:30:02 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 16 Jun 2008 08:30:02 -0700
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <20080616140252.GA3938@phare.normalesup.org>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080616025814.GA31696@phare.normalesup.org>
	<cd7634ce0806152246n4f84c03an5bd3306469b53075@mail.gmail.com>
	<20080616140252.GA3938@phare.normalesup.org>
Message-ID: <cd7634ce0806160830r43d22ed8x39c7d04bcf01bbef@mail.gmail.com>

On Mon, Jun 16, 2008 at 7:02 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Jun 15, 2008 at 10:46:35PM -0700, Barry Wark wrote:
>> I hope you don't mind me cc-ing this to the list, in case anyone else
>> is curious.
>
> No, not replying to the list was actually unintended.
>
>> Running the project from within Xcode _should_ (fingers crossed!)
>> start the demo frontend.
>
> That was the part that took us a while to get: we just tried to "python
> foobar.py" the thing, but apparently Apple likes to "think different",
> and this does not work.

You can write Cocoa apps with this method (PyObjCTools.AppHelper
includes functions to start/stop the main loop and you can build the
entire Cocoa stack in code), but the Xcode project wraps the whole
thing in a true native OS X app. It includes one compiled file
(main.m) which loads the python interpreter, adds any
application-specific python packages/modules (which are included in
the app bundle) to the sys.path and exec's the main.py file. My guess
is that using 'python main.py' with an appropriate PYTHONPATH would do
the trick, though I haven't tried it. The "benefit" of Apple's
approach is that the app is a native OS X application bundle with all
the associated LaunchServices support, icons, ability to include
frameworks/python/resources/plugins in the app bundle etc.

>
>> You'll quickly find that the Cocoa frontend is still quite rough
>> around the edges.
>
> My one question is: what is the plan for interacting with the GUI
> mainloop. For example how to I open matlplotlib windows?

That's a great question. You can currently use matplotlib exactly as
you would from a standard python prompt (ie with show()). The caveat
is that all of the matplotlib backends on OS X think they are being
run from a CLI, not GUI and so attempt to create/hijack their own
event loop, often by instantiating a run loop in backend's toolkit.
Since Wx, Tk, and Qt are implemented in Carbon on OS X, they don't mix
very well with the Cocoa run loop. This leads to some weird menu bar
behavior etc. and, with some backends, causes the matplotlib windows
to get stuck on screen. This is a general problem with matplotlib, not
with the Cocoa front end, per-se (the same problems crop up using the
PyInterpreter example in the Developer Tools/Examples folder).

So, how can we get all this working? There are really two parts of
this question...

>
> I guess this is a more general question: what is the road forward on
> frontends for this problem?

1. There's no reason that matplotlib needs to create its own run loop.
I've been working off and on on a true Cocoa backend form Matplotlib.
My intention is to make it play nicely with an existing Cocoa run loop
etc. This would address the issue you asked about above, namely using
matplotlib interactively from the frontend's own engine.

2. There's a deeper issue in the ipython1 architecture that Brian and
I have just started to have a couple of discussions about (he may have
had similar conversations with other folks too, of course). What
happens if a client executes code on a remote engine such as
"pyplot.plot([1,2,3]);show()" that produces something besides stout
output? What do we want to happen? One possibility is that we'd like
the resulting plot to be displayed to the user by their client, either
in-line in a notebook style interface or in a separate window in a
command-line style interface. Brian and I discussed adding a rendering
package to IPython.kernel.core. Renderers would be registered by
object type, so that a specific renderer could be registered for
matplotlib figure or Lines2D or whatever. A default, pprint renderer
would catch all cases of types that don't have a registered renderer.
When the core returns the result of an exec, it could instead
substitute the renderer for that result. Alternatively, the client
could explicty request the renderer for a particular object in the
engine's namespace.

In the case of matplotlib plots that renderer could produce a static
image of the plot to be passed to the client (easy) or a proxy object
that could continue to interact with the plot remotely (harder, but
doable). Objects might also be able to specify their own rederer via a
__renderer__ property, for example. In this way, the matplotlib or
chaco or MayaVi etc. developers could add IPython renderer support to
their library directly.

Well, at least that's the idea... as always, there's a lot to do and a
real functional/technical spec or code will speak much louder than
words.

Cheers,
Barry


From barrywark at gmail.com  Mon Jun 16 11:33:18 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 16 Jun 2008 08:33:18 -0700
Subject: [IPython-dev] Error in cocoa frontend build.
In-Reply-To: <76D322BD-A981-454A-944E-B4A09B995A89@tamu.edu>
References: <76D322BD-A981-454A-944E-B4A09B995A89@tamu.edu>
Message-ID: <cd7634ce0806160833qb82aef5tbffd1a40ab497341@mail.gmail.com>

Hi Rob!

It looks to me like you're somehow getting PyObjC 1.4 rather than
PyObjC2. Do you have the python.org framework installed in
/Library/Frameworks and/or have you installed PyObjC 1.4 into the
system python? In my experience, Xcode and/or the compiled app gets
confused when there's the /Library/Frameworks python. I've removed
/Library/Frameowrks/Python.framework completely and haven't looked
back.

Barry

On Mon, Jun 16, 2008 at 12:04 AM, Rob Hetland <hetland at tamu.edu> wrote:
>
> I'm pretty excited about the development you've been doing on a cocoa
> frontend.  I got the code, and tried to compile, but it fails on run.
>  Here's what the concol says after a debug compile:
>
> I'm not sure how to fix this, but figure you might know.
>
> I'm on 10.5 now (previously when we were exchanging emails about kd-trees, I
> was still on 10.4), use the system python, and have successfully tried out
> ipython1 stuff (so Twisted and all that are there and working.)
>
> Any ideas?
>
> -Rob
>
>
>
> 6/16/08 8:55:58 AM IPython1Sandbox[1201] *** Terminating app due to uncaught
> exception 'NSInternalInconsistencyException', reason:
> '/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/main.m:44
> main() PyRun_SimpleFile failed with file
> '/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/main.py'.
>  See console for errors.'
> 6/16/08 8:55:58 AM IPython1Sandbox[1201] Stack: (
>    2497098059,
>    2518483195,
>    2497097515,
>    2497097578
> )
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> Traceback (most recent call last):
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> File
> "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/main.py",
> line 20, in <module>
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> import IPython1SandboxAppDelegate
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> File
> "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/IPython1SandboxAppDelegate.py",
> line 17, in <module>
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> class IPython1SandboxAppDelegate(NSObject):
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> File
> "/Users/rob/src/python/ipython-frontend/IPython/frontend/cocoa/examples/IPython1Sandbox/build/Debug/IPython1Sandbox.app/Contents/Resources/IPython1SandboxAppDelegate.py",
> line 18, in IPython1SandboxAppDelegate
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> ipythonController = objc.IBOutlet()
> 6/16/08 8:55:58 AM [0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]
> TypeError: IBOutlet() takes exactly 1 argument (0 given)
> 6/16/08 8:56:01 AM com.apple.launchd[115]
> ([0x0-0x4e04e].com.yourcompany.IPython1Sandbox[1201]) Exited abnormally:
> Trace/BPT trap
>
>
>
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
>
>
>
>


From jorgen.stenarson at bostream.nu  Mon Jun 16 14:52:10 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 16 Jun 2008 20:52:10 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
Message-ID: <4856B65A.1000903@bostream.nu>

Fernando Perez skrev:
> Hey,
> 
> On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> Hi,
>>
>> I just registered pyreadline at launchpad. Considering all the traffic
>> on bzr problems. I just thought I should ask here what is the best way
>> to move svn over to launchpad? How do I handle the branches and tags?
> 
...
> 
> - Do an import from the raw svn repo.  I can run an svn dump of the
> whole repo and put it up for you to download if you want to play with
> things there (I can probably dump just the pyreadline part so it's
> smaller).
> 
> 

I've tried a few different ways that didn't work out satisfactorily. The 
launchpad-import branch that Ville created doesn't seem to work. So I 
would like to try to work from a svn dump. If you can do a dump of 
pyreadline/trunk and put it somewhere I can download it I'd be happy.

/J?rgen



From fperez.net at gmail.com  Tue Jun 17 02:34:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 16 Jun 2008 23:34:40 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <4856B65A.1000903@bostream.nu>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
Message-ID: <db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>

Hey,

On Mon, Jun 16, 2008 at 11:52 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:

> I've tried a few different ways that didn't work out satisfactorily. The
> launchpad-import branch that Ville created doesn't seem to work. So I would
> like to try to work from a svn dump. If you can do a dump of
> pyreadline/trunk and put it somewhere I can download it I'd be happy.

I just dumped the whole ipython repo here:

http://ipython.scipy.org/dist/iprepo.svndump.bz2

Let me know how it goes.  Note that this is the entire repo (as best I
could see, svnadmind dump doesn't take any path options, only
revisions).  This should give you all the data needed to play locally
with the bzr import tools.

Cheers,

f


From ondrej at certik.cz  Tue Jun 17 06:28:20 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 17 Jun 2008 12:28:20 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
Message-ID: <85b5c3130806170328k27858a4bl7b371de112c4c320@mail.gmail.com>

On Mon, Jun 2, 2008 at 8:35 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hey,
>
> On Mon, Jun 2, 2008 at 10:40 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> Hi,
>>
>> I just registered pyreadline at launchpad. Considering all the traffic
>> on bzr problems. I just thought I should ask here what is the best way
>> to move svn over to launchpad? How do I handle the branches and tags?
>
> Great!  I just approved you for the ip team as well.
>
> I'm not an expert, but you can follow one of several routes:
>
> - use the bzr svn plugin.  This will let you do imports of the svn
> history with a fair bit of control.
>
> - Register a branch for their vcs-imports team, typically the trunk.
> Here's the ipython one:
>
> https://code.launchpad.net/~vcs-imports/ipython/main
>
> Yesterday what I did was to use that one for the ipython svn->bzr
> final move, and basically ditch all the svn tags.  Our svn repo is not
> going away, so we can always refer to that for historical purposes.
> And if there's ever a move to destroy the svn repo on scipy.org, we
> can also convert the whole thing to bzr.
>
> - Do an import from the raw svn repo.  I can run an svn dump of the
> whole repo and put it up for you to download if you want to play with
> things there (I can probably dump just the pyreadline part so it's
> smaller).
>
>
> In my case, I just went for easy: launchpad did the original svn
> import of trunk for us, so it was the least amount of effort to start
> from there.  Unless you really want to keep all branches and tags also
> in bzr, that will get you off the ground quickly and with full history
> (as I said, you can keep on referring to SVN for the foreseeable
> future, and if anything ever changes there I'll let you know).
>
>> By the way is anyone here going to EuroSciPy in Leipzig? I'm planning to
>> go but this year I'm not going to do a presentation.
>
> I think John Hunter was considering swinging by, but I'm not sure what
> his final plans are, check with him.  I know some of the Enthought
> guys will go, and perhaps Ondrej could make it, since he's not too
> far.  I have too much other stuff going on, and no travel budget for
> that kind of trip right now.

I am definitely going and we'll have a presentation about sfepy and
sympy with Robert Cimrman:

http://www.scipy.org/EuroSciPy2008Abstracts#rcimrman

It'd be great of some ipython developers could come too.

Ondrej

From jorgen.stenarson at bostream.nu  Tue Jun 17 14:09:10 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 17 Jun 2008 20:09:10 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
References: <4844307C.80308@bostream.nu>	
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>	
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
Message-ID: <4857FDC6.7050202@bostream.nu>

Fernando Perez skrev:
> Hey,
> 
> On Mon, Jun 16, 2008 at 11:52 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
> 
>> I've tried a few different ways that didn't work out satisfactorily. The
>> launchpad-import branch that Ville created doesn't seem to work. So I would
>> like to try to work from a svn dump. If you can do a dump of
>> pyreadline/trunk and put it somewhere I can download it I'd be happy.
> 
> I just dumped the whole ipython repo here:
> 
> http://ipython.scipy.org/dist/iprepo.svndump.bz2
> 
> Let me know how it goes.  Note that this is the entire repo (as best I
> could see, svnadmind dump doesn't take any path options, only
> revisions).  This should give you all the data needed to play locally
> with the bzr import tools.

Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile
you made has version 3 and svn2bzr requires version 2. Is dumpfile 
format 3 for svn 1.5?

I used svn2bzr from 'bzr branch lp:svn2bzr'.

My svndumpfilter command (svn 1.4.6) also complains that dumpfile format 
3 is not supported.

/J?rgen







From fperez.net at gmail.com  Tue Jun 17 14:25:13 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 17 Jun 2008 11:25:13 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <4857FDC6.7050202@bostream.nu>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
Message-ID: <db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>

On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:

> Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile
> you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3
> for svn 1.5?

Mmh, that's weird.  The svn version on that machine is very old:

ipython at scipy[~]$ svn --version
svn, version 1.2.3 (r15833)
   compiled Aug 26 2005, 03:42:45

I did a dump with --deltas to make it a bit smaller, let me try again
without deltas and see if that helps.

I'll be back as soon as it completes.

f


From fperez.net at gmail.com  Tue Jun 17 14:47:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 17 Jun 2008 11:47:54 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
Message-ID: <db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>

On Tue, Jun 17, 2008 at 11:25 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>
>> Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile
>> you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3
>> for svn 1.5?
>
> Mmh, that's weird.  The svn version on that machine is very old:
>
> ipython at scipy[~]$ svn --version
> svn, version 1.2.3 (r15833)
>   compiled Aug 26 2005, 03:42:45
>
> I did a dump with --deltas to make it a bit smaller, let me try again
> without deltas and see if that helps.

OK, here it is.  Note that this file is 50MB large, but it's the plain
'svn dump' output without any --deltas, so it might be easier to
process.

http://ipython.scipy.org/dist/iprepo.svndump-full.bz2

Let me know if that still doesn't work, I could also make a tarball of
the raw repo. Since nobody is committing to it and we use the FSFS
backend, that should be safe to simply dump to a file and transport
over to another machine.

Cheers,

f


From jorgen.stenarson at bostream.nu  Tue Jun 17 16:13:32 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 17 Jun 2008 22:13:32 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
References: <4844307C.80308@bostream.nu>	
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>	
	<4856B65A.1000903@bostream.nu>	
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>	
	<4857FDC6.7050202@bostream.nu>	
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
Message-ID: <48581AEC.1070803@bostream.nu>

Fernando Perez skrev:
> On Tue, Jun 17, 2008 at 11:25 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Tue, Jun 17, 2008 at 11:09 AM, J?rgen Stenarson
>> <jorgen.stenarson at bostream.nu> wrote:
>>
>>> Unfortunately svn2bzr.py complains about the dumpformat. The dumpfile
>>> you made has version 3 and svn2bzr requires version 2. Is dumpfile format 3
>>> for svn 1.5?
>> Mmh, that's weird.  The svn version on that machine is very old:
>>
>> ipython at scipy[~]$ svn --version
>> svn, version 1.2.3 (r15833)
>>   compiled Aug 26 2005, 03:42:45
>>
>> I did a dump with --deltas to make it a bit smaller, let me try again
>> without deltas and see if that helps.
> 
> OK, here it is.  Note that this file is 50MB large, but it's the plain
> 'svn dump' output without any --deltas, so it might be easier to
> process.
> 
> http://ipython.scipy.org/dist/iprepo.svndump-full.bz2
> 
> Let me know if that still doesn't work, I could also make a tarball of
> the raw repo. Since nobody is committing to it and we use the FSFS
> backend, that should be safe to simply dump to a file and transport
> over to another machine.
> 

Argh, this is frustrating. The full dump worked better. But I had to 
change svn2bzr to open files in binary mode. But then it barfs when 
there is a Node-action: change in the dump file. Apparently svn2bzr does 
not support the full dump file format or there is some other problem. 
Can you run svn2bzr on the dumpfile without problems?

I could try the other svn2bzr branch which is supposed to work directly 
on the repo. But that will have to wait until tomorrow. Well I did a 
quick test but that branch crashes hard when I try to work directly to 
the repo on ipython.scipy.org. Perhaps we could try to do the tarball of 
the whole repo.

It seems these more advanced problems are tricky to do on windows. I 
sure hope it is easier to work with bzr in a normal situation.

/J?rgen



From eyecat at gmail.com  Tue Jun 17 16:27:23 2008
From: eyecat at gmail.com (Yuhui H)
Date: Tue, 17 Jun 2008 13:27:23 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <48581AEC.1070803@bostream.nu>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
Message-ID: <eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>

On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> It seems these more advanced problems are tricky to do on windows. I
> sure hope it is easier to work with bzr in a normal situation.

Hi,

I'm not an expert on either bzr or IPython/PyReadline, But branching
from svn to bzr seems to work without a hitch for me (for this svn
repo anyway).

I'm using Windows, python2.5 with bzr source distribution 1.6b2, and
bzr-svn from
http://d5190871.u44.websitesource.net/bzr-svn/
(and official win32 subversion binary).

All I need to do to is:

bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline

If you want, I can upload my bzr branch somewhere as a zip package. Or
I can push it to launchpad somewhere.

Yuhui


From jorgen.stenarson at bostream.nu  Tue Jun 17 16:50:12 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 17 Jun 2008 22:50:12 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
References: <4844307C.80308@bostream.nu>	
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>	
	<4856B65A.1000903@bostream.nu>	
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>	
	<4857FDC6.7050202@bostream.nu>	
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>	
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>	
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
Message-ID: <48582384.5040100@bostream.nu>

Yuhui H skrev:
> On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> It seems these more advanced problems are tricky to do on windows. I
>> sure hope it is easier to work with bzr in a normal situation.
> 
> Hi,
> 
> I'm not an expert on either bzr or IPython/PyReadline, But branching
> from svn to bzr seems to work without a hitch for me (for this svn
> repo anyway).
> 
> I'm using Windows, python2.5 with bzr source distribution 1.6b2, and
> bzr-svn from
> http://d5190871.u44.websitesource.net/bzr-svn/
> (and official win32 subversion binary).
> 
> All I need to do to is:
> 
> bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline
> 
> If you want, I can upload my bzr branch somewhere as a zip package. Or
> I can push it to launchpad somewhere.
> 
> Yuhui
> 
I'll try to use 1.6 tomorrow. If it doesn't work out for me I'll let you 
know and we can try to use your branch. Thanks for the tip.

/J?rgen


From fperez.net at gmail.com  Tue Jun 17 19:26:51 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 17 Jun 2008 16:26:51 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <48581AEC.1070803@bostream.nu>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
Message-ID: <db6b5ecc0806171626u7be1d47cj8f8ba7d3cec08756@mail.gmail.com>

Hey,

On Tue, Jun 17, 2008 at 1:13 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:

> Argh, this is frustrating. The full dump worked better. But I had to change
> svn2bzr to open files in binary mode. But then it barfs when there is a
> Node-action: change in the dump file. Apparently svn2bzr does not support
> the full dump file format or there is some other problem. Can you run
> svn2bzr on the dumpfile without problems?
>
> I could try the other svn2bzr branch which is supposed to work directly on
> the repo. But that will have to wait until tomorrow. Well I did a quick test
> but that branch crashes hard when I try to work directly to the repo on
> ipython.scipy.org. Perhaps we could try to do the tarball of the whole repo.
>
> It seems these more advanced problems are tricky to do on windows. I sure
> hope it is easier to work with bzr in a normal situation.

OK, in order to give you all the possible options, I just made a dump
of the raw filesystem directory containing the repo:

http://ipython.scipy.org/dist/iprepo.svnraw.tar.bz2

This file is 14MB.  I hope one of these works...

Cheers,

f


From fperez.net at gmail.com  Tue Jun 17 20:17:50 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 17 Jun 2008 17:17:50 -0700
Subject: [IPython-dev] Fwd: IPython documentation
In-Reply-To: <1213295536.10989.27.camel@localhost.localdomain>
References: <6ce0ac130806111535h1f005668wbcdeb641debc4f1f@mail.gmail.com>
	<db6b5ecc0806111758s62598f98gb841069e8a57d760@mail.gmail.com>
	<9457e7c80806111814w37633538ic49f26817e8df8d5@mail.gmail.com>
	<1213295536.10989.27.camel@localhost.localdomain>
Message-ID: <db6b5ecc0806171717k510310b9obc47491314f8c4c4@mail.gmail.com>

On Thu, Jun 12, 2008 at 11:32 AM, Pauli Virtanen <pav at iki.fi> wrote:

> If yes, it's probably easiest to modify the docstring collector script
> to also collect text from given .rst files, implement support for text
> files in the patch generation, and adjust the logic in the web interface
> slightly so that it knows that the docstring standard shouldn't be
> enforced for some entries. All of this is not a lot of extra work.
>
> If 3-way merges are not needed, one could simply use the wiki
> functionality in the program as an RST editor, and possibly write some
> code to easily export multiple wiki pages at once.
>
> For writing Sphinx documents, some amount of work would probably be
> needed in adding support for the Sphinx special directives. Writing this
> code is probably the hardest part as it requires some familiarity with
> the internals of the docutils package.

I'm focusing right now on all the testing machinery (not completely
trivial, given that 'ipython is not python'), so I won't touch any of
this yet.  And I agree with Brian that at least our current system is
eminently functional, and we can write nice docs with little overhead
beyond the writing itself.

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.

But if this is too much work, the simple 'wiki as rst editor' approach
would suffice initially, as long as the user changes can be applied
into the tree with some near-zero-overhead process (beyond reading the
actual patch).

Still, I wouldn't worry too much about this for now. You guys are
using this heavily for numpy/scipy and that's the current focus.
Experience gained there will be reused by the other projects later.  A
good target would be to work on this at the Scipy'08 sprint; will you
be there?

Cheers,

f


From vivainio at gmail.com  Wed Jun 18 12:25:37 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 18 Jun 2008 19:25:37 +0300
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
Message-ID: <46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com>

On Tue, Jun 17, 2008 at 11:27 PM, Yuhui H <eyecat at gmail.com> wrote:

> If you want, I can upload my bzr branch somewhere as a zip package. Or
> I can push it to launchpad somewhere.

Just push it to launchpad somewhere, the problem is basically solved by that.

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


From eyecat at gmail.com  Wed Jun 18 13:33:12 2008
From: eyecat at gmail.com (Yuhui H)
Date: Wed, 18 Jun 2008 10:33:12 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
	<46cb515a0806180925l39e16b5dm46b6b63edf722cf5@mail.gmail.com>
Message-ID: <eb9527b60806181033t41a8105egfcfb6ae2f430c085@mail.gmail.com>

On Wed, Jun 18, 2008 at 9:25 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> Just push it to launchpad somewhere, the problem is basically solved by that.
>

See if this works:

lp:~eyecat/pyreadline/svnimport



Yuhui


From jorgen.stenarson at bostream.nu  Wed Jun 18 13:56:38 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 18 Jun 2008 19:56:38 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
References: <4844307C.80308@bostream.nu>	
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>	
	<4856B65A.1000903@bostream.nu>	
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>	
	<4857FDC6.7050202@bostream.nu>	
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>	
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>	
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
Message-ID: <48594C56.9060409@bostream.nu>

Yuhui H skrev:
> 
> All I need to do to is:
> 
> bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline
> 
Yuhui,

thanks for your pointers it worked finally. There were some additional 
problems caused by the configuration of my machine (my home directory 
has both spaces and non-ascii characters, I really should change that).

Now there is an official launchpad branch for pyreadline!!

/J?rgen



From cournapeau at cslab.kecl.ntt.co.jp  Wed Jun 18 22:18:36 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Thu, 19 Jun 2008 11:18:36 +0900
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <48594C56.9060409@bostream.nu>
References: <4844307C.80308@bostream.nu>
	<db6b5ecc0806021135x4d2e986ap12eaa582aa0c2efd@mail.gmail.com>
	<4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
	<48594C56.9060409@bostream.nu>
Message-ID: <1213841916.29726.3.camel@bbc8>

On Wed, 2008-06-18 at 19:56 +0200, J?rgen Stenarson wrote:
> Yuhui H skrev:
> > 
> > All I need to do to is:
> > 
> > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline
> > 

For the record, if the need appears again: in my experience, the fastest
and most reliable way to import svn into bzr is to use fast-import bzr
plugin. It uses the same format as git-export, which means you can use a
lot of exporters (git, svn, cvs, hg):

svn-export file:///repo | (cd bzr-rep && bzr fast-import - -v)

The only drawback is it requires you to have a fast access to the repo,
which is trivial if you have the svn dump. But the code is stable, much
better than bzr-svn which tries to be too smart IMHO for this kind of
tasks (one time import).

cheers,

David



From fperez.net at gmail.com  Thu Jun 19 00:08:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 18 Jun 2008 21:08:19 -0700
Subject: [IPython-dev] Moving pyreadline to launchpad
In-Reply-To: <1213841916.29726.3.camel@bbc8>
References: <4844307C.80308@bostream.nu> <4856B65A.1000903@bostream.nu>
	<db6b5ecc0806162334g3ee7fa3ay67afb95a5c4c8164@mail.gmail.com>
	<4857FDC6.7050202@bostream.nu>
	<db6b5ecc0806171125q20886a6mdb71816a61260009@mail.gmail.com>
	<db6b5ecc0806171147o9a47a39s886a4223b8c453e@mail.gmail.com>
	<48581AEC.1070803@bostream.nu>
	<eb9527b60806171327w4cbbd6f1s4f896e07f57411e7@mail.gmail.com>
	<48594C56.9060409@bostream.nu> <1213841916.29726.3.camel@bbc8>
Message-ID: <db6b5ecc0806182108p3f3c0ca3g5f841a464b399cd8@mail.gmail.com>

Hey David,

On Wed, Jun 18, 2008 at 7:18 PM, David Cournapeau
<cournapeau at cslab.kecl.ntt.co.jp> wrote:
> On Wed, 2008-06-18 at 19:56 +0200, J?rgen Stenarson wrote:
>> Yuhui H skrev:
>> >
>> > All I need to do to is:
>> >
>> > bzr branch svn+http://ipython.scipy.org/svn/ipython/pyreadline/trunk pyreadline
>> >
>
> For the record, if the need appears again: in my experience, the fastest
> and most reliable way to import svn into bzr is to use fast-import bzr
> plugin. It uses the same format as git-export, which means you can use a
> lot of exporters (git, svn, cvs, hg):
>
> svn-export file:///repo | (cd bzr-rep && bzr fast-import - -v)
>
> The only drawback is it requires you to have a fast access to the repo,
> which is trivial if you have the svn dump. But the code is stable, much
> better than bzr-svn which tries to be too smart IMHO for this kind of
> tasks (one time import).

Thanks for the pointer.  In this case it seems that bzr-svn ended up
working OK for Jorgen's needs, but if anything funky turns up after
closer examination, the raw dumps are still up so he could use your
tip.

Regards,

f


From vishal.vatsa at gmail.com  Fri Jun 20 06:46:45 2008
From: vishal.vatsa at gmail.com (Vishal Vatsa)
Date: Fri, 20 Jun 2008 11:46:45 +0100
Subject: [IPython-dev] async taskclient
Message-ID: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com>

Hi Guys,

I have a question about how to use the async task client.
Given the following code:

def job_runner(code):

    def submit(task_client, cmd):
        t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a'])
        d = task_client.run(t1)
        d.addCallback(lambda tid:
task_client.get_task_result(taskid=tid, block=True))
        d.addBoth(printer)

    d = asyncclient.get_task_client()
    d.addCallback(lambda tc: submit(tc, code))


where code is some python code in a string.

Is it ok to get a new instance of async task client for every
job I want to submit?


From hans_meine at gmx.net  Fri Jun 20 08:00:35 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 20 Jun 2008 14:00:35 +0200
Subject: [IPython-dev] Moving pyreadline to launchpad
Message-ID: <200806201400.35629.hans_meine@gmx.net>

Am Donnerstag, 19. Juni 2008 04:18:36 schrieb David Cournapeau:
> The only drawback is it requires you to have a fast access to the repo,
> which is trivial if you have the svn dump.

For the records: I have had success with using svnsync for fast conversion (to 
mercurial in my case) in order to try out different conversion options.  
Here's a quick walk-through:

FROMREPO="https://spacenav.svn.sourceforge.net/svnroot/spacenav"
TOREPO="file://`pwd`/spacenav-sf"
svnadmin create spacenav-sf
svnsync init "$TOREPO" "$FROMREPO"
svnsync --non-interactive sync "$TOREPO"

Ciao, /  /
     /--/
    /  / ANS


From ellisonbg.net at gmail.com  Fri Jun 20 10:08:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 20 Jun 2008 08:08:12 -0600
Subject: [IPython-dev] async taskclient
In-Reply-To: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com>
References: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com>
Message-ID: <6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com>

> I have a question about how to use the async task client.
> Given the following code:
>
> def job_runner(code):
>
>    def submit(task_client, cmd):
>        t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a'])
>        d = task_client.run(t1)
>        d.addCallback(lambda tid:
> task_client.get_task_result(taskid=tid, block=True))
>        d.addBoth(printer)
>
>    d = asyncclient.get_task_client()
>    d.addCallback(lambda tc: submit(tc, code))
>
>
> where code is some python code in a string.
>
> Is it ok to get a new instance of async task client for every
> job I want to submit?

You can do this but for each new client there will be a new connection
to the controller.  Thus it is best for performance reasons to use a
single TaskClient instance for all of your tasks in a sessions.

Is there a reason you want to use a TaskClient for each task?

Cheers,

Brian


From vishal.vatsa at gmail.com  Fri Jun 20 10:22:08 2008
From: vishal.vatsa at gmail.com (Vishal Vatsa)
Date: Fri, 20 Jun 2008 15:22:08 +0100
Subject: [IPython-dev] async taskclient
In-Reply-To: <6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com>
References: <7ea8f2ed0806200346m7e64b2e3x3ad730e0bde85119@mail.gmail.com>
	<6ce0ac130806200708q3490c33n112080146f2c7d91@mail.gmail.com>
Message-ID: <7ea8f2ed0806200722v6ff30ad8tfe6264161f319758@mail.gmail.com>

2008/6/20 Brian Granger <ellisonbg.net at gmail.com>:
>> I have a question about how to use the async task client.
>> Given the following code:
>>
>> def job_runner(code):
>>
>>    def submit(task_client, cmd):
>>        t1 = Task(cmd, clear_before=True, clear_after=True, pull=['a'])
>>        d = task_client.run(t1)
>>        d.addCallback(lambda tid:
>> task_client.get_task_result(taskid=tid, block=True))
>>        d.addBoth(printer)
>>
>>    d = asyncclient.get_task_client()
>>    d.addCallback(lambda tc: submit(tc, code))
>>
>>
>> where code is some python code in a string.
>>
>> Is it ok to get a new instance of async task client for every
>> job I want to submit?
>
> You can do this but for each new client there will be a new connection
> to the controller.  Thus it is best for performance reasons to use a
> single TaskClient instance for all of your tasks in a sessions.
>
> Is there a reason you want to use a TaskClient for each task?
>
> Cheers,
>
> Brian
>

I tried to reuse the defered that get_task_client() gets me but I was not sure
how to reuse the async task client.  Would you have a suggestion on how
to go about this?

Cheers
Vishal


From gael.varoquaux at normalesup.org  Mon Jun 23 13:11:40 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 23 Jun 2008 19:11:40 +0200
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
Message-ID: <20080623171140.GD13966@phare.normalesup.org>

On Sun, Jun 15, 2008 at 04:03:31PM -0700, Barry Wark wrote:
> At this point, I would appreciate comments on the entire frontend
> package before we consider merging ipython-frontend into trunk.

OK, some first impression comments:

conding standards: 

    * Some lines are longer than 80 characters. I don't like this as I
      keep all my windows open at 80 characters width, and I don't like
      lines wrapping.

    * The function naming convention is not systematic (eg
      frontendbase.py, line 101, there is a method with a CamelCase name,
      but right under there is one with underscore-sperated names.
      CamelCase is reserved for classes. I don't care what twisted, apple
      modules or wx does, they go against pep 8.

On the code side of things, a lot of the methods in cocoa_frontend look
like they are not Cocoa-specific. They should be moved in the
frontendbase, IMHO.

More will probably come, but I wanted to post this right now, less I
never do it.

Just a stupid question: is their a good reason for not merging this
branch with trunk? It will probably get us more people running the code
or reviewing it, though I must admit that the fact that the only
available frontend is a cocoa one prevents me totally forom trying the
code out.

Ga?l



From ellisonbg.net at gmail.com  Mon Jun 23 13:44:27 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 23 Jun 2008 11:44:27 -0600
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <20080623171140.GD13966@phare.normalesup.org>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080623171140.GD13966@phare.normalesup.org>
Message-ID: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com>

>> At this point, I would appreciate comments on the entire frontend
>> package before we consider merging ipython-frontend into trunk.
>
> OK, some first impression comments:
>
> conding standards:
>
>    * Some lines are longer than 80 characters. I don't like this as I
>      keep all my windows open at 80 characters width, and I don't like
>      lines wrapping.

True, when possible, we should stick to 80 chars.

>    * The function naming convention is not systematic (eg
>      frontendbase.py, line 101, there is a method with a CamelCase name,
>      but right under there is one with underscore-sperated names.
>      CamelCase is reserved for classes. I don't care what twisted, apple
>      modules or wx does, they go against pep 8.

For the most part we do want to follow pep 8 conventions for IPython
code.  But, there are cases (I don't know if things in the Cocoa
frontend fall into this case), like subclassing, where you have to use
the conventions established by a third party (twisted or pyobjc in
Barry's case).  These other projects may go against pep 8, but we do
have to live with their conventions if we want to use their software.
In that sense, they don't care that we don't care :)

> On the code side of things, a lot of the methods in cocoa_frontend look
> like they are not Cocoa-specific. They should be moved in the
> frontendbase, IMHO.
>
> More will probably come, but I wanted to post this right now, less I
> never do it.
>
> Just a stupid question: is their a good reason for not merging this
> branch with trunk? It will probably get us more people running the code
> or reviewing it, though I must admit that the fact that the only
> available frontend is a cocoa one prevents me totally forom trying the
> code out.

The plan is to do a merge very soon.  Barry is just doing good
development by 1) doing his work in a branch and 2) asking for code
review before merging.  Kudos for that!

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  Mon Jun 23 13:56:57 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 23 Jun 2008 19:56:57 +0200
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080623171140.GD13966@phare.normalesup.org>
	<6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com>
Message-ID: <20080623175657.GE13966@phare.normalesup.org>

On Mon, Jun 23, 2008 at 11:44:27AM -0600, Brian Granger wrote:
> For the most part we do want to follow pep 8 conventions for IPython
> code.  But, there are cases (I don't know if things in the Cocoa
> frontend fall into this case), like subclassing, where you have to use
> the conventions established by a third party (twisted or pyobjc in
> Barry's case).  These other projects may go against pep 8, but we do
> have to live with their conventions if we want to use their software.
> In that sense, they don't care that we don't care :)

Fare enough, but for generic stuff (like the frontentbase), we should
stick to pep 8. I do realise that the cocoa frontend inherits both from
the FrontEndBase, and the apple NSObject, but I gather that the interface
are separate, and that none of the FrontEndBase method overrides an
NSObject lethod.

> > Just a stupid question: is their a good reason for not merging this
> > branch with trunk? It will probably get us more people running the code
> > or reviewing it, though I must admit that the fact that the only
> > available frontend is a cocoa one prevents me totally forom trying the
> > code out.

> The plan is to do a merge very soon.  Barry is just doing good
> development by 1) doing his work in a branch and 2) asking for code
> review before merging.  Kudos for that!

Yes, this is good. I do think we will want to move forward pretty soon. I
think I might want to reuse that code, and it sitting in a different
branch might not help.

Cheers,

Ga?l


From gael.varoquaux at normalesup.org  Mon Jun 23 14:16:32 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 23 Jun 2008 20:16:32 +0200
Subject: [IPython-dev] Moving forward with the frontends
Message-ID: <20080623181632.GF13966@phare.normalesup.org>

Hi all,

This is just a heads up to say that I have been allowed to devote some of
my day work's time to working on a frontend for iPython. We want to
integrate IPython in Mayavi and other similar projects. The requirements
are:

 * We want something fast, not after three months of work

 * We do not want it multithreaded. The reason being that this shell will
   be used to manipulate existing Wx objects. As Wx is not multithreaded,
   we cannot execute the code the user enters in a separate thread. As we
   want to manipulate objects displayed by the GUI, we cannot run in a
   seperate process. In the long run we can think of a "%bg" like magic
   to execute in a seperate thread, but on the short term I will make my
   life easier and run everything in one thread.

  * We are interested in wx. I am of course happy sharing the code with
    other frontends, but I will not be developping them.

  * The feature of ipython we are interested in are magics, "?" and "??",
    tab completion, history, and alike...

I am currently reviewing the existing code. I see three code bases for
front end:

    * Laurent Dufrechou's WxIpython, living in the trunk, in
      IPython/gui/wx

    * Barry Wark's cocoa frontend, living in a separate branch;
      ipython-frontend

    * The code Fernando, Eric Jones and myself started a year ago, living
    * in the old ipython1 branch (in ipython1/frontend).

>From a first quick review, they all have there stength and their
weakness. I am probably going to take from all three. I have not decided
where my effort will live.

I will keep on review the code, and exploring better the ipython
codebase. I am interested in any pointers you have, or advice on how to
move forward. I will keep the list posted as things move along.

Cheers,

Ga?l


From fperez.net at gmail.com  Mon Jun 23 14:58:52 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 23 Jun 2008 11:58:52 -0700
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <20080623181632.GF13966@phare.normalesup.org>
References: <20080623181632.GF13966@phare.normalesup.org>
Message-ID: <db6b5ecc0806231158n451cf2d7n464564a0ca9d47ef@mail.gmail.com>

On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi all,
>
> This is just a heads up to say that I have been allowed to devote some of
> my day work's time to working on a frontend for iPython. We want to
> integrate IPython in Mayavi and other similar projects. The requirements
> are:
>
>  * We want something fast, not after three months of work

Great!  Real quick (I'll respond to your message in full later): we
can make this an IPAM project, in the end I *will* make it there after
the SIAM conference, so put it in your schedule for those two weeks
after the talks end.  IPAM is a great place to work anyways...

Timeline for everyone else (the previous paragraph was a bit cryptic):
Gael and I will be physically together for 2 weeks at a workshop at
UCLA July 14-25, and we'll work on this as time allows around
scheduled talks.  If Barry, Laurent or anyone else is interested, we
could schedule irc/skype sessions occasionally to coordinate the
frontend progress during that period (in addition to on-list
discussions).  Gael will likely also visit with me at Berkeley
afterwards, so July/August is a good timeline for this to happen.

I'm working on the nose testing stuff right now, we'll likely have to
ship our own ipython nose plugin for all our testing to work with
nose.  I'll try to have that finished in the next day or so, since I
want us to have that layer in place as we refactor things.

Cheers,

f


From fperez.net at gmail.com  Mon Jun 23 15:19:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 23 Jun 2008 12:19:00 -0700
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080623171140.GD13966@phare.normalesup.org>
	<6ce0ac130806231044s4c69d797u59f80c05ce9feb2a@mail.gmail.com>
Message-ID: <db6b5ecc0806231219n151fba1dv66d85e7d9b525d49@mail.gmail.com>

On Mon, Jun 23, 2008 at 10:44 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> At this point, I would appreciate comments on the entire frontend
>>> package before we consider merging ipython-frontend into trunk.
>>
>> OK, some first impression comments:
>>
>> conding standards:
>>
>>    * Some lines are longer than 80 characters. I don't like this as I
>>      keep all my windows open at 80 characters width, and I don't like
>>      lines wrapping.
>
> True, when possible, we should stick to 80 chars.

Again, just follow PEP-8 (http://www.python.org/dev/peps/pep-0008/)

""" Maximum Line Length

    Limit all lines to a maximum of 79 characters."""

The default python mode for emacs does this, as I imagine do the
python modes for other editors if they've been written to be pep-8
conformant.

Unless there's a very good reason not to, we stick to pep-8 for
everything.  The case of subclassing existing interfaces is an obvious
case where we have to do whatever the parent class does and not what
pep8/we want.

Cheers,

f


From barrywark at gmail.com  Mon Jun 23 15:40:08 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 23 Jun 2008 12:40:08 -0700
Subject: [IPython-dev] IPython.fronend progress
In-Reply-To: <20080623171140.GD13966@phare.normalesup.org>
References: <cd7634ce0806151532i79b909c5p9b2f011b7d3e84bf@mail.gmail.com>
	<cd7634ce0806151603p6f85387ci3f9800c4c4d35c37@mail.gmail.com>
	<20080623171140.GD13966@phare.normalesup.org>
Message-ID: <cd7634ce0806231240t6c3de2car356a86783920409f@mail.gmail.com>

On Mon, Jun 23, 2008 at 10:11 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Jun 15, 2008 at 04:03:31PM -0700, Barry Wark wrote:
>> At this point, I would appreciate comments on the entire frontend
>> package before we consider merging ipython-frontend into trunk.
>
> OK, some first impression comments:
>
> conding standards:
>
>    * Some lines are longer than 80 characters. I don't like this as I
>      keep all my windows open at 80 characters width, and I don't like
>      lines wrapping.

Quite right. Sorry. That will definitely be fixed.

>
>    * The function naming convention is not systematic (eg
>      frontendbase.py, line 101, there is a method with a CamelCase name,
>      but right under there is one with underscore-sperated names.
>      CamelCase is reserved for classes. I don't care what twisted, apple
>      modules or wx does, they go against pep 8.

I thought I had cleaned up everything that didn't override Twisted or
Cocoa methods to be PEP 8 compliant. I will double check that again.

>
> On the code side of things, a lot of the methods in cocoa_frontend look
> like they are not Cocoa-specific. They should be moved in the
> frontendbase, IMHO.

Good point. I will have an other look at that separation. Some things
ended up in the cocoa-specific frontend because they are specific to
how the cocoa frontend renders its UI -- a notebook based frontend
would be very different. In fact, the cocoa frontend is more a test
fixture at this point. Ultimately I would like to move it towards a
notebook-like interface. I will see whether there's anything in there
that is generall applicable to ALL frontend UIs, but I suspect there
isn't.

>
> More will probably come, but I wanted to post this right now, less I
> never do it.
>
> Just a stupid question: is their a good reason for not merging this
> branch with trunk? It will probably get us more people running the code
> or reviewing it, though I must admit that the fact that the only
> available frontend is a cocoa one prevents me totally forom trying the
> code out.

My intention was to merge as soon as some other eyes had taken a look
at, and OK'd, the code. It sounds like resolving the issues you raise
here will get me to being ready to merge. I will announce on the list
as soon as the merge to trunk is complete.

Thanks for your comments!

Barry

>
> Ga?l
>
>


From barrywark at gmail.com  Mon Jun 23 16:26:18 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 23 Jun 2008 13:26:18 -0700
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <20080623181632.GF13966@phare.normalesup.org>
References: <20080623181632.GF13966@phare.normalesup.org>
Message-ID: <cd7634ce0806231326r5ae5a121i304e342c996d701d@mail.gmail.com>

On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi all,
>
> This is just a heads up to say that I have been allowed to devote some of
> my day work's time to working on a frontend for iPython. We want to
> integrate IPython in Mayavi and other similar projects. The requirements
> are:
>
>  * We want something fast, not after three months of work
>
>  * We do not want it multithreaded. The reason being that this shell will
>   be used to manipulate existing Wx objects. As Wx is not multithreaded,
>   we cannot execute the code the user enters in a separate thread. As we
>   want to manipulate objects displayed by the GUI, we cannot run in a
>   seperate process. In the long run we can think of a "%bg" like magic
>   to execute in a seperate thread, but on the short term I will make my
>   life easier and run everything in one thread.

I don't want to sound like a broken record and I don't have personal
pride staked on this solution so it's OK if you choose otherwise, but
I think going with a Twisted-based approach is the right plan. I would
look forward to working with you to make FrontEndBase work for your
use. There's a WX reactor for Twisted so we can guarantee that code
gets executed in the WX runloop thread. Using Twisted's deferToThread
(eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it
possible for long-running code to not block the UI.

>
>  * We are interested in wx. I am of course happy sharing the code with
>    other frontends, but I will not be developping them.
>
>  * The feature of ipython we are interested in are magics, "?" and "??",
>    tab completion, history, and alike...

As soon as we can refactor the IPython 0.8 core so that it plays
nicely with the IPython.kernel.engineservice.IEngineBase interface,
all frontends could get this behavior for free. If you can't wait for
that refactoring, going with the existing Wx frontend is your only
option at this point.

>
> I am currently reviewing the existing code. I see three code bases for
> front end:
>
>    * Laurent Dufrechou's WxIpython, living in the trunk, in
>      IPython/gui/wx

Like I said above, this is the only option if you can't wait for the
refactoring of the current core to work with I.k.e.IEngineBase [1]

>
>    * Barry Wark's cocoa frontend, living in a separate branch;
>      ipython-frontend

As we discussed in a separate thread, this will hoepfully be merged
into trunk soon.

>
>    * The code Fernando, Eric Jones and myself started a year ago, living
>    * in the old ipython1 branch (in ipython1/frontend).

The frontend that I will merge into trunk does not include your
original code. I would like to revisit whether your line-oriented
approach could be incorporated into a FrontEndBase subclass
specifiically for line-oriented frontends.

>
> >From a first quick review, they all have there stength and their
> weakness. I am probably going to take from all three. I have not decided
> where my effort will live.
>
> I will keep on review the code, and exploring better the ipython
> codebase. I am interested in any pointers you have, or advice on how to
> move forward. I will keep the list posted as things move along.
>
> Cheers,
>
> Ga?l
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From barrywark at gmail.com  Mon Jun 23 16:28:40 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 23 Jun 2008 13:28:40 -0700
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <db6b5ecc0806231158n451cf2d7n464564a0ca9d47ef@mail.gmail.com>
References: <20080623181632.GF13966@phare.normalesup.org>
	<db6b5ecc0806231158n451cf2d7n464564a0ca9d47ef@mail.gmail.com>
Message-ID: <cd7634ce0806231328w475501c1r8e6bc252cc4906fd@mail.gmail.com>

8 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> Hi all,
>>
>> This is just a heads up to say that I have been allowed to devote some of
>> my day work's time to working on a frontend for iPython. We want to
>> integrate IPython in Mayavi and other similar projects. The requirements
>> are:
>>
>>  * We want something fast, not after three months of work
>
> Great!  Real quick (I'll respond to your message in full later): we
> can make this an IPAM project, in the end I *will* make it there after
> the SIAM conference, so put it in your schedule for those two weeks
> after the talks end.  IPAM is a great place to work anyways...
>
> Timeline for everyone else (the previous paragraph was a bit cryptic):
> Gael and I will be physically together for 2 weeks at a workshop at
> UCLA July 14-25, and we'll work on this as time allows around
> scheduled talks.  If Barry, Laurent or anyone else is interested, we
> could schedule irc/skype sessions occasionally to coordinate the
> frontend progress during that period (in addition to on-list
> discussions).  Gael will likely also visit with me at Berkeley
> afterwards, so July/August is a good timeline for this to happen.

I am stuck in Seattle, then Woods Hole, MA over this period but would
be happy to irc/skype as the need arises. Hopefully Gael and I can
touch base some time late this week and come to a united front on the
frontend tactics.

[1] Is it acceptable to abreviate IPython.kernel.engineservice.[blah]
as I.k.e.blah as the Twisted folks do? Since we now have a somewhat
deep namespace, it's getting a tiny bit tiresome to write it all out
every time...?

>
> I'm working on the nose testing stuff right now, we'll likely have to
> ship our own ipython nose plugin for all our testing to work with
> nose.  I'll try to have that finished in the next day or so, since I
> want us to have that layer in place as we refactor things.
>
> 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  Mon Jun 23 16:36:36 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 23 Jun 2008 22:36:36 +0200
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <cd7634ce0806231326r5ae5a121i304e342c996d701d@mail.gmail.com>
References: <20080623181632.GF13966@phare.normalesup.org>
	<cd7634ce0806231326r5ae5a121i304e342c996d701d@mail.gmail.com>
Message-ID: <20080623203636.GL13966@phare.normalesup.org>

On Mon, Jun 23, 2008 at 01:26:18PM -0700, Barry Wark wrote:
> >  * We do not want it multithreaded. The reason being that this shell will
> >   be used to manipulate existing Wx objects. As Wx is not multithreaded,
> >   we cannot execute the code the user enters in a separate thread. As we
> >   want to manipulate objects displayed by the GUI, we cannot run in a
> >   seperate process. In the long run we can think of a "%bg" like magic
> >   to execute in a seperate thread, but on the short term I will make my
> >   life easier and run everything in one thread.

> I don't want to sound like a broken record and I don't have personal
> pride staked on this solution so it's OK if you choose otherwise, but
> I think going with a Twisted-based approach is the right plan. I would
> look forward to working with you to make FrontEndBase work for your
> use. There's a WX reactor for Twisted so we can guarantee that code
> gets executed in the WX runloop thread. Using Twisted's deferToThread
> (eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it
> possible for long-running code to not block the UI.

OK, I am not sure I understand fully this approach. The name made me
think there were threads involved, and thus it wouldn't work in the
context of Wx. I guess I need to do some googling/reading to find out
more about the reactors.

> >  * The feature of ipython we are interested in are magics, "?" and "??",
> >    tab completion, history, and alike...

> As soon as we can refactor the IPython 0.8 core so that it plays
> nicely with the IPython.kernel.engineservice.IEngineBase interface,
> all frontends could get this behavior for free. If you can't wait for
> that refactoring, going with the existing Wx frontend is your only
> option at this point.

Fernando, Brian, Ville, what is the timeframe for this? What is the
amount of work required?

Ga?l


From fperez.net at gmail.com  Mon Jun 23 21:10:07 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 23 Jun 2008 18:10:07 -0700
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <20080623203636.GL13966@phare.normalesup.org>
References: <20080623181632.GF13966@phare.normalesup.org>
	<cd7634ce0806231326r5ae5a121i304e342c996d701d@mail.gmail.com>
	<20080623203636.GL13966@phare.normalesup.org>
Message-ID: <db6b5ecc0806231810td68bf20lbc172dcd2812688f@mail.gmail.com>

Hey,

On Mon, Jun 23, 2008 at 1:36 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Mon, Jun 23, 2008 at 01:26:18PM -0700, Barry Wark wrote:

>
>> >  * The feature of ipython we are interested in are magics, "?" and "??",
>> >    tab completion, history, and alike...
>
>> As soon as we can refactor the IPython 0.8 core so that it plays
>> nicely with the IPython.kernel.engineservice.IEngineBase interface,
>> all frontends could get this behavior for free. If you can't wait for
>> that refactoring, going with the existing Wx frontend is your only
>> option at this point.
>
> Fernando, Brian, Ville, what is the timeframe for this? What is the
> amount of work required?

The way I see things right now, this can be done gradually.  Min,
Brian and I just spent several hours today working on the
foolscap/security integration for the daemon work to be merged in the
next couple of weeks.  I'm also working on the testing code, writing a
custom Nose plugin to suit all our (rather complicated) testing needs.
 Those two features are what I see as being next in line for our 0.9
release.  Brian and I will meet at a conference July 7-11, so that
would be a good time to make the release, and it looks like both Min
and I can finish what we're doing for that time.

In the meantime, you can consider the WX integration work, in
conjunction with Barry, as being precisely the beginning of this
refactoring.  I don't want to draw us again into the 'once the *huge*
refactoring is done, we can do X' mindset, because that's precisely
what was paralyzing us with ipython0/1.  Instead, try to find a light
way of using the existing bits of Wx code (which you've already
identified) and work with Barry on the Twisted ideas.  Envisage
already has a million nasty dependencies, so I don't see Twisted being
a problem there.

The way I hope we'll be able to build this whole thing will be:

1. A NON-Twisted using terminal frontend like today, that is fully
blocking (no deferreds since there's no twisted).  But it uses the
same interfaces the Twisted ones will use.

2. We keep the threading hacks we have today to provide terminal-based
acccess to GUIs (the -Xthread options).  Note that this is NOT meant
to be the way to develop full GUI clients that use ipython, simply a
way to use the terminal to run GUI code like many people do today.
It's not perfect but it's lightweight and useful, and I see no need to
get rid of it.

3. For building full-blown GUI clients, we use the Twisted reactors
that know how to integrate with the various toolkits in existence,
including Cocoa.

With that as a long-term view, I'd suggest you hack away incrementally
so that you can build something that mimics what Barry is doing.  If
not all the pieces are fully elegantly refactored yet, big deal.  As
long as you have something that works, we can incrementally fix it up.
 Don't let the idea of a 'big refactor' hold back the work you and
Barry can do *now*.

Note: I'll be at a conference Wed-Saturday, mostly offline.

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Jun 24 00:11:39 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 24 Jun 2008 06:11:39 +0200
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <db6b5ecc0806231810td68bf20lbc172dcd2812688f@mail.gmail.com>
References: <20080623181632.GF13966@phare.normalesup.org>
	<cd7634ce0806231326r5ae5a121i304e342c996d701d@mail.gmail.com>
	<20080623203636.GL13966@phare.normalesup.org>
	<db6b5ecc0806231810td68bf20lbc172dcd2812688f@mail.gmail.com>
Message-ID: <20080624041138.GA2269@phare.normalesup.org>

On Mon, Jun 23, 2008 at 06:10:07PM -0700, Fernando Perez wrote:
> >> As soon as we can refactor the IPython 0.8 core so that it plays
> >> nicely with the IPython.kernel.engineservice.IEngineBase interface,
> >> all frontends could get this behavior for free. If you can't wait for
> >> that refactoring, going with the existing Wx frontend is your only
> >> option at this point.

> > Fernando, Brian, Ville, what is the timeframe for this? What is the
> > amount of work required?

> The way I see things right now, this can be done gradually.

Cool. I think that is indeed the way to go.

> In the meantime, you can consider the WX integration work, in
> conjunction with Barry, as being precisely the beginning of this
> refactoring.  I don't want to draw us again into the 'once the *huge*
> refactoring is done, we can do X' mindset,

I have started working on that today. Currently what I am doing is not
Ipython specific (though I hope it will go in the ipython repository), it
can be adapted to ipython0 or to ipython1. Hopefully the work on
ipython0/ipython1 will move fast-enough so that I will be able to use
that, rather than pushing string to an ipython0 terminal.

> Envisage already has a million nasty dependencies, so I don't see
> Twisted being a problem there.

As long as it brings us something. I have read a bit about the twisted
reactor, and I must admit I haven't understood how it will allow us to
run arbitrary code without blocking the gui loop, but in a thread-safe
way with Wx. I am probably just being heavy.

Anyway, I think in the long run we will want twisted integrated in all
this. I am just saying I have the feeling this is outside the current
scope of my work. Though, if I have understood well, switching from an
engine abstracted through twisted to one running in the same thread as
the calls should be simply a matter of replacing an instance by another,
right?

> The way I hope we'll be able to build this whole thing will be:

> 1. A NON-Twisted using terminal frontend like today, that is fully
> blocking (no deferreds since there's no twisted).  But it uses the
> same interfaces the Twisted ones will use.

I see it slightly differently. I think it is the engine who should come
in different flavors, exposing the same interface. Line 39 of
http://bazaar.launchpad.net/~barrywark/ipython/ipython-frontend/annotate/barrywark%40gmail.com-20080616054258-7jjo8w1tt7sc1zfg?file_id=cocoa_frontend.py-20080611225339-bjp8mnnd2tnxj9n5-8
makes me believe this might already be the case, but I still haven't
wrapped my head around the code, and I can't execute it, as it is Mac
only.

> 2. We keep the threading hacks we have today to provide terminal-based
> acccess to GUIs (the -Xthread options).  Note that this is NOT meant
> to be the way to develop full GUI clients that use ipython, simply a
> way to use the terminal to run GUI code like many people do today.
> It's not perfect but it's lightweight and useful, and I see no need to
> get rid of it.

Sure, I agree the are useful. I can't however worry about them right now.

> 3. For building full-blown GUI clients, we use the Twisted reactors
> that know how to integrate with the various toolkits in existence,
> including Cocoa.


Will this allow me to execute arbitrary wx commands without killing the
application? Can somebody point me to a document hinting how to do this.
I am kind of lost here because I don't really understand how the reactors
works. Anyhow, hopefully this can also be hidden in an object presenting
the same interface as an EngineService.

I think we are on the same wavelength. I am going to focus on trying to get
something done, clean and hopefully extendable, but maybe with a reduce
feature-set. This can be the basis of future work.

Ga?l


From vivainio at gmail.com  Tue Jun 24 02:03:40 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 24 Jun 2008 09:03:40 +0300
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <20080623181632.GF13966@phare.normalesup.org>
References: <20080623181632.GF13966@phare.normalesup.org>
Message-ID: <46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com>

On Mon, Jun 23, 2008 at 9:16 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> integrate IPython in Mayavi and other similar projects. The requirements
> are:
>
>  * We want something fast, not after three months of work

>  * We are interested in wx. I am of course happy sharing the code with
>    other frontends, but I will not be developping them.

>  * The feature of ipython we are interested in are magics, "?" and "??",
>    tab completion, history, and alike...

> I am currently reviewing the existing code. I see three code bases for
> front end:
>
>    * Laurent Dufrechou's WxIpython, living in the trunk, in
>      IPython/gui/wx

I think this is the winner here, given the preconditions above. It
seems it would be pretty easy to integrate.

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


From barrywark at gmail.com  Tue Jun 24 03:09:37 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 00:09:37 -0700
Subject: [IPython-dev] ipython-frontend branch merged to trunk
Message-ID: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>

After cleaning up the code in ipython-frontend to be fully pep 8
compliant (except when overriding non-PEP 8 compliant methods from
Cocoa or Twisted), I've merged the ipython-frontend branch into trunk
and marked the ipython-frontend branch as "merged" on launchpad. I
expect all further work on the IPython.frontend package to happen from
trunk. I'll try to work up a tutorial on writing a frontend in the
next few days. In the mean time, happy hacking.

Cheers,
Barry


From stefan at sun.ac.za  Tue Jun 24 05:50:28 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 24 Jun 2008 11:50:28 +0200
Subject: [IPython-dev] Questin regarding pager
Message-ID: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>

Hi all,

Doing TAB-completion makes use of the readline pager, which isn't All
That Great.  With pyreadline available, is there an easy way to
default to a more advanced completion pager?

Regards
St?fan


From gael.varoquaux at normalesup.org  Tue Jun 24 08:56:45 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 24 Jun 2008 14:56:45 +0200
Subject: [IPython-dev] ipython-frontend branch merged to trunk
In-Reply-To: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
References: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
Message-ID: <20080624125645.GA27589@phare.normalesup.org>

Thanks for all the work, Barry, and thank you for being receptive to
comments.

Ga?l

On Tue, Jun 24, 2008 at 12:09:37AM -0700, Barry Wark wrote:
> After cleaning up the code in ipython-frontend to be fully pep 8
> compliant (except when overriding non-PEP 8 compliant methods from
> Cocoa or Twisted), I've merged the ipython-frontend branch into trunk
> and marked the ipython-frontend branch as "merged" on launchpad. I
> expect all further work on the IPython.frontend package to happen from
> trunk. I'll try to work up a tutorial on writing a frontend in the
> next few days. In the mean time, happy hacking.



From ellisonbg.net at gmail.com  Tue Jun 24 11:40:34 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 24 Jun 2008 09:40:34 -0600
Subject: [IPython-dev] ipython-frontend branch merged to trunk
In-Reply-To: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
References: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
Message-ID: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>

Barry,

I don't have time to look at this yet, but thanks for the great work!
In addition to having basic Cocoa frontend (which I most definitely
want as an OS X user) we also have a great start on the more general
frontend work because of your efforts.

Thanks!

Brian

On Tue, Jun 24, 2008 at 1:09 AM, Barry Wark <barrywark at gmail.com> wrote:
> After cleaning up the code in ipython-frontend to be fully pep 8
> compliant (except when overriding non-PEP 8 compliant methods from
> Cocoa or Twisted), I've merged the ipython-frontend branch into trunk
> and marked the ipython-frontend branch as "merged" on launchpad. I
> expect all further work on the IPython.frontend package to happen from
> trunk. I'll try to work up a tutorial on writing a frontend in the
> next few days. In the mean time, happy hacking.
>
> Cheers,
> Barry
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Jun 24 12:59:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 24 Jun 2008 09:59:48 -0700
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017: Merged
	ipython-frontend branch. All changes in IPython.frontend
	except for updates to IPython.ker...
In-Reply-To: <4425715799121846470@unknownmsgid>
References: <4425715799121846470@unknownmsgid>
Message-ID: <db6b5ecc0806240959v7493ff21s1960b6bdf87506f6@mail.gmail.com>

Wow Barry,

huge commit :)

On Tue, Jun 24, 2008 at 12:06 AM,  <noreply at launchpad.net> wrote:
> ------------------------------------------------------------
> revno: 1017
> committer: Barry Wark <barrywark at gmail.com>
> branch nick: ipython
> timestamp: Tue 2008-06-24 00:02:30 -0700
> message:
>  Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.kernel.engineservice.ThreadedEngineService and associated tests.
> added:

>  IPython/frontend/cocoa/examples/.DS_Store
>  IPython/frontend/cocoa/examples/IPython1Sandbox/
>  IPython/frontend/cocoa/examples/IPython1Sandbox/.DS_Store

Please don't commit those .DS_Store files.

As a general rule, before making a large commit, open it in your
editor/GUI of choice and check carefully every file you're about to
commit.  Perhaps adding a proper .bzrignore is what we need right now.
 Volunteer?

>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/
>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/InfoPlist.strings
>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/MainMenu.xib

I assume these others are indeed needed for your Cocoa work, but given
the omission above, I'd appreciate if you double-checked the entire
log of added files and made sure nothing else made it in that
shouldn't have.

Thanks,

f


From fperez.net at gmail.com  Tue Jun 24 13:01:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 24 Jun 2008 10:01:20 -0700
Subject: [IPython-dev] Questin regarding pager
In-Reply-To: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>
References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>
Message-ID: <db6b5ecc0806241001k3a33759aw359915aaaf2ef27c@mail.gmail.com>

On Tue, Jun 24, 2008 at 2:50 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Hi all,
>
> Doing TAB-completion makes use of the readline pager, which isn't All
> That Great.  With pyreadline available, is there an easy way to
> default to a more advanced completion pager?

Ville recently added an option to *disable* the pager altogether, but
I don't know if one can hook a different pager into readline.  When
ipython pages, it honors the $PAGER variable, but I have no idea if
readline does as well.  Have you tried setting $PAGER to what you want
to use?

Cheers,

f


From fperez.net at gmail.com  Tue Jun 24 13:02:31 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 24 Jun 2008 10:02:31 -0700
Subject: [IPython-dev] ipython-frontend branch merged to trunk
In-Reply-To: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>
References: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
	<6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>
Message-ID: <db6b5ecc0806241002x5a7470e7i74ec5f3f25161f72@mail.gmail.com>

On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Barry,
>
> I don't have time to look at this yet, but thanks for the great work!
> In addition to having basic Cocoa frontend (which I most definitely
> want as an OS X user) we also have a great start on the more general
> frontend work because of your efforts.

Seconded from here.  Other than the minor .DS_Store commit mixup which
is easy to fix, many many thanks both for this work, and for being
active/interested in the design discussion!  Glad to have you on board
:)

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Jun 24 14:03:33 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 24 Jun 2008 20:03:33 +0200
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017:	Merged
	ipython-frontend branch. All changes in
	IPython.frontend	except for updates to IPython.ker...
In-Reply-To: <db6b5ecc0806240959v7493ff21s1960b6bdf87506f6@mail.gmail.com>
References: <4425715799121846470@unknownmsgid>
	<db6b5ecc0806240959v7493ff21s1960b6bdf87506f6@mail.gmail.com>
Message-ID: <20080624180333.GA935@phare.normalesup.org>

On Tue, Jun 24, 2008 at 09:59:48AM -0700, Fernando Perez wrote:
> As a general rule, before making a large commit, open it in your
> editor/GUI of choice and check carefully every file you're about to
> commit.  

Meld is a fantastic tool for reviewing local changes before commiting.

Ga?l


From vivainio at gmail.com  Tue Jun 24 14:15:49 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 24 Jun 2008 21:15:49 +0300
Subject: [IPython-dev] Questin regarding pager
In-Reply-To: <db6b5ecc0806241001k3a33759aw359915aaaf2ef27c@mail.gmail.com>
References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>
	<db6b5ecc0806241001k3a33759aw359915aaaf2ef27c@mail.gmail.com>
Message-ID: <46cb515a0806241115w4dc5a92bwd2ef73e517179bc5@mail.gmail.com>

On Tue, Jun 24, 2008 at 8:01 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Ville recently added an option to *disable* the pager altogether, but
> I don't know if one can hook a different pager into readline.  When

I don't really see the point in pager at all, since you can page up /
page down in terminal window anyway...

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


From jorgen.stenarson at bostream.nu  Tue Jun 24 15:28:58 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 24 Jun 2008 21:28:58 +0200
Subject: [IPython-dev] Questin regarding pager
In-Reply-To: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>
References: <9457e7c80806240250v7fe98b2cyb0bcb8a796e5a92a@mail.gmail.com>
Message-ID: <48614AFA.2050703@bostream.nu>

St?fan van der Walt skrev:
> Hi all,
> 
> Doing TAB-completion makes use of the readline pager, which isn't All
> That Great.  With pyreadline available, is there an easy way to
> default to a more advanced completion pager?
> 
> Regards
> St?fan

St?fan,

in pyreadline there is currently no way to easily choose a more advanced 
pager. However if you feel like working on a patch the relevant method 
is _display_completions in pyreadline.modes.basemode

/J?rgen

ps. the official repository for pyreadline is now on launchpad



From barrywark at gmail.com  Tue Jun 24 15:41:25 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 12:41:25 -0700
Subject: [IPython-dev] [Branch ~ipython/ipython/trunk] Rev 1017: Merged
	ipython-frontend branch. All changes in IPython.frontend
	except for updates to IPython.ker...
In-Reply-To: <db6b5ecc0806240959v7493ff21s1960b6bdf87506f6@mail.gmail.com>
References: <4425715799121846470@unknownmsgid>
	<db6b5ecc0806240959v7493ff21s1960b6bdf87506f6@mail.gmail.com>
Message-ID: <cd7634ce0806241241m75324532haa7d7df995296308@mail.gmail.com>

On Tue, Jun 24, 2008 at 9:59 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Wow Barry,
>
> huge commit :)
>
> On Tue, Jun 24, 2008 at 12:06 AM,  <noreply at launchpad.net> wrote:
>> ------------------------------------------------------------
>> revno: 1017
>> committer: Barry Wark <barrywark at gmail.com>
>> branch nick: ipython
>> timestamp: Tue 2008-06-24 00:02:30 -0700
>> message:
>>  Merged ipython-frontend branch. All changes in IPython.frontend except for updates to IPython.kernel.engineservice.ThreadedEngineService and associated tests.
>> added:
>
>>  IPython/frontend/cocoa/examples/.DS_Store
>>  IPython/frontend/cocoa/examples/IPython1Sandbox/
>>  IPython/frontend/cocoa/examples/IPython1Sandbox/.DS_Store
>
> Please don't commit those .DS_Store files.

Oops. Those ones slipped by. I'll remove them.
>
> As a general rule, before making a large commit, open it in your
> editor/GUI of choice and check carefully every file you're about to
> commit.  Perhaps adding a proper .bzrignore is what we need right now.
>  Volunteer?
>
>>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/
>>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/InfoPlist.strings
>>  IPython/frontend/cocoa/examples/IPython1Sandbox/English.lproj/MainMenu.xib
>
> I assume these others are indeed needed for your Cocoa work, but given
> the omission above, I'd appreciate if you double-checked the entire
> log of added files and made sure nothing else made it in that
> shouldn't have.

Yes, these are all for the Cocoa frontend example.

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


From jorgen.stenarson at bostream.nu  Tue Jun 24 15:42:05 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 24 Jun 2008 21:42:05 +0200
Subject: [IPython-dev] pyreadline refactoring
Message-ID: <48614E0D.30901@bostream.nu>

Hi,

I have started to work on a refactoring of pyreadline with the goal to 
untangle the class interactions that have made it difficult to reuse 
pyreadline in other circumstances than a shell on win32.

The basic idea is that it should be possible to call a readline object 
with keypress events containing (control, shift, meta, char, keyname)
where keyname is for special keys like space, f1, return etc.

The readline object would be responsible for keeping track of current 
prompt, line_buffer, cursor_position and selection_position. But the 
caller of the object will have to render the buffer.

I have also merged the callback branch I worked on a few months back.
The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor

If anyone has any ideas or suggestions on how things should work please 
let me know.

/J?rgen



From barrywark at gmail.com  Tue Jun 24 17:54:27 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 14:54:27 -0700
Subject: [IPython-dev] ipython-frontend branch merged to trunk
In-Reply-To: <6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>
References: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
	<6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>
Message-ID: <cd7634ce0806241454k772f5025r233319737be49106@mail.gmail.com>

On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Barry,
>
> I don't have time to look at this yet, but thanks for the great work!
> In addition to having basic Cocoa frontend (which I most definitely
> want as an OS X user) we also have a great start on the more general
> frontend work because of your efforts.
>
> Thanks!
>
> Brian

Brian,

No worries... as a mac user, I have a bit of interest in a good
frontend too ;) I'm just having fun.

cheers,
Barry

>
> On Tue, Jun 24, 2008 at 1:09 AM, Barry Wark <barrywark at gmail.com> wrote:
>> After cleaning up the code in ipython-frontend to be fully pep 8
>> compliant (except when overriding non-PEP 8 compliant methods from
>> Cocoa or Twisted), I've merged the ipython-frontend branch into trunk
>> and marked the ipython-frontend branch as "merged" on launchpad. I
>> expect all further work on the IPython.frontend package to happen from
>> trunk. I'll try to work up a tutorial on writing a frontend in the
>> next few days. In the mean time, happy hacking.
>>
>> Cheers,
>> Barry
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>


From barrywark at gmail.com  Tue Jun 24 17:57:33 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 14:57:33 -0700
Subject: [IPython-dev] ipython-frontend branch merged to trunk
In-Reply-To: <db6b5ecc0806241002x5a7470e7i74ec5f3f25161f72@mail.gmail.com>
References: <cd7634ce0806240009h402e8032ld95a0eee696af3ac@mail.gmail.com>
	<6ce0ac130806240840w184bfd38n3a4814d8439d31c4@mail.gmail.com>
	<db6b5ecc0806241002x5a7470e7i74ec5f3f25161f72@mail.gmail.com>
Message-ID: <cd7634ce0806241457g7cc33d17y21ac3724ea98229c@mail.gmail.com>

On Tue, Jun 24, 2008 at 10:02 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 24, 2008 at 8:40 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Barry,
>>
>> I don't have time to look at this yet, but thanks for the great work!
>> In addition to having basic Cocoa frontend (which I most definitely
>> want as an OS X user) we also have a great start on the more general
>> frontend work because of your efforts.
>
> Seconded from here.  Other than the minor .DS_Store commit mixup which
> is easy to fix, many many thanks both for this work, and for being
> active/interested in the design discussion!  Glad to have you on board
> :)

Happy to be aboard. This is a very exciting time and I really
appreciate how welcoming you all have been!

Barry

>
> Cheers,
>
> f
>


From barrywark at gmail.com  Tue Jun 24 17:58:20 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 14:58:20 -0700
Subject: [IPython-dev] Bazaar on OS X
Message-ID: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>

Just a side note on the VCS side of things...

Bazaar appears to have a bunch of problems on OS X with directories
that are reached via AFP (Apple's file sharing protocol). I've filed a
bug with the bazaar folks, but as we start to push towards having a
more full featured Cocoa frontend for ipython, it's worth remembering
that some potential developers on OS X will have trouble using bazaar.
I'll keep the list posted on progress resolving this issue.

Barry


From fperez.net at gmail.com  Tue Jun 24 18:13:29 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 24 Jun 2008 15:13:29 -0700
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
Message-ID: <db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>

On Tue, Jun 24, 2008 at 2:58 PM, Barry Wark <barrywark at gmail.com> wrote:
> Just a side note on the VCS side of things...
>
> Bazaar appears to have a bunch of problems on OS X with directories
> that are reached via AFP (Apple's file sharing protocol). I've filed a
> bug with the bazaar folks, but as we start to push towards having a
> more full featured Cocoa frontend for ipython, it's worth remembering
> that some potential developers on OS X will have trouble using bazaar.
> I'll keep the list posted on progress resolving this issue.

Bummer!  Please keep us posted.

I have to say that I've given up on the whole 'history folding'
problem, so I'm not 100% happy with bzr/lp either.  Basically if you
have truly diverged lines of work where you did work and committed
locally while other devs pushed, a merge is inevitable (even if you
keep several branches and push only from one that you don't develop
in).  And at that point, bzr does the whole 'dropped revisions' dance
and folds history.

But on the whole we do gain from the ability to flexibly merge (even
with ugly history) and the support for contributors from launchpad is
vastly better than manually managing accounts on scipy.org and playing
admin-by-night, so it's a net gain.  Just not a perfect one :)

But definitely keep us posted on the nature of the OSX issues.

Cheers,

f


From barrywark at gmail.com  Tue Jun 24 18:25:30 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 15:25:30 -0700
Subject: [IPython-dev] Bug? in cocoa_frontend
In-Reply-To: <20080624221156.GC26559@phare.normalesup.org>
References: <20080624220401.GB26559@phare.normalesup.org>
	<cd7634ce0806241508w25ff1762ie9f8e2bdc8b3f342@mail.gmail.com>
	<20080624221156.GC26559@phare.normalesup.org>
Message-ID: <cd7634ce0806241525x449c6a9aw9365e804b1cb4d98@mail.gmail.com>

On Tue, Jun 24, 2008 at 3:11 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Jun 24, 2008 at 03:08:58PM -0700, Barry Wark wrote:
>> No, you're absolutely right. It should be
>> currentIndent = len(lines[-1]) - len(lines[-1].lstrip())
>
> OK, now I understand what it is supposed to do. Thanks (PS; code review
> rocks !).

I agree. That's why I wanted a review ;) I'm cc'ing this to
ipython-dev to propose that we set up a code review tool for IPython.
GvR's rietveld (http://code.google.com/appengine/articles/rietveld.html)
seems like an option, as does http://review-board.org/. I don't think
either tool works natively with bzr, but it might be worth looking
into...

I know we're not looking for a rigid code-review process, but an easy
code review tool couldn't hurt...  just a thought.

Barry


>
> Ga?l
>


From barrywark at gmail.com  Tue Jun 24 18:36:43 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 15:36:43 -0700
Subject: [IPython-dev] pyreadline refactoring
In-Reply-To: <48614E0D.30901@bostream.nu>
References: <48614E0D.30901@bostream.nu>
Message-ID: <cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>

On Tue, Jun 24, 2008 at 12:42 PM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Hi,
>
> I have started to work on a refactoring of pyreadline with the goal to
> untangle the class interactions that have made it difficult to reuse
> pyreadline in other circumstances than a shell on win32.
>
> The basic idea is that it should be possible to call a readline object
> with keypress events containing (control, shift, meta, char, keyname)
> where keyname is for special keys like space, f1, return etc.
>
> The readline object would be responsible for keeping track of current
> prompt, line_buffer, cursor_position and selection_position. But the
> caller of the object will have to render the buffer.
>
> I have also merged the callback branch I worked on a few months back.
> The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor
>
> If anyone has any ideas or suggestions on how things should work please
> let me know.

J?rgen,

Wow, this is an exciting move in view of the plans to separate
ipython0's core from the terminal/readline. I am still learning about
pyreadline, but your description above makes me think that you, me,
and Ga?l should think about using the new (refactored) pyreadline in
developing a base class for front ends that are based on a
line-oriented interface (i.e. mimicking the terminal interface).

Barry

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


From ellisonbg.net at gmail.com  Tue Jun 24 18:41:50 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 24 Jun 2008 16:41:50 -0600
Subject: [IPython-dev] Bug? in cocoa_frontend
In-Reply-To: <cd7634ce0806241525x449c6a9aw9365e804b1cb4d98@mail.gmail.com>
References: <20080624220401.GB26559@phare.normalesup.org>
	<cd7634ce0806241508w25ff1762ie9f8e2bdc8b3f342@mail.gmail.com>
	<20080624221156.GC26559@phare.normalesup.org>
	<cd7634ce0806241525x449c6a9aw9365e804b1cb4d98@mail.gmail.com>
Message-ID: <6ce0ac130806241541u13d9b63dw32cfe10ea4261c69@mail.gmail.com>

We have actually talked about establishing a slightly formal code
review policy.  I too like the idea.  While I think rietveld looks
very nice, launchpad recently add some features that basically let you
do code review on launchpad.  I have tried this out (OK, I just
"reviewed" my own branch) and it worked rather well and is very well
integrated with everything else we are doing with launchpad/bzr.  I
encourage others to have a look at these launchpad capabilities and
see if they think they would help us.  If I remember correctly, if you
click on a branches "propose for merging" link, you can 1) provide
comments about the branch and 2) vote in merging.

Simple, but probably enough for what we need.

Cheers,

Brian

On Tue, Jun 24, 2008 at 4:25 PM, Barry Wark <barrywark at gmail.com> wrote:
> On Tue, Jun 24, 2008 at 3:11 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Tue, Jun 24, 2008 at 03:08:58PM -0700, Barry Wark wrote:
>>> No, you're absolutely right. It should be
>>> currentIndent = len(lines[-1]) - len(lines[-1].lstrip())
>>
>> OK, now I understand what it is supposed to do. Thanks (PS; code review
>> rocks !).
>
> I agree. That's why I wanted a review ;) I'm cc'ing this to
> ipython-dev to propose that we set up a code review tool for IPython.
> GvR's rietveld (http://code.google.com/appengine/articles/rietveld.html)
> seems like an option, as does http://review-board.org/. I don't think
> either tool works natively with bzr, but it might be worth looking
> into...
>
> I know we're not looking for a rigid code-review process, but an easy
> code review tool couldn't hurt...  just a thought.
>
> Barry
>
>
>>
>> Ga?l
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Tue Jun 24 18:47:08 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 24 Jun 2008 16:47:08 -0600
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
Message-ID: <6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com>

> Bummer!  Please keep us posted.
>
> I have to say that I've given up on the whole 'history folding'
> problem, so I'm not 100% happy with bzr/lp either.  Basically if you
> have truly diverged lines of work where you did work and committed
> locally while other devs pushed, a merge is inevitable (even if you
> keep several branches and push only from one that you don't develop
> in).  And at that point, bzr does the whole 'dropped revisions' dance
> and folds history.

> But on the whole we do gain from the ability to flexibly merge (even
> with ugly history) and the support for contributors from launchpad is
> vastly better than manually managing accounts on scipy.org and playing
> admin-by-night, so it's a net gain.  Just not a perfect one :)

Definitely not perfect, but I do agree that it is a net gain from
before.  I would characterize this in the "Just Works" category, but
with a "Not always quite the way you want it to" clause.  Judging from
past experience (CVS-> SVN->bzr) these decisions are likely not final
for all eternity.

Cheers,

Brian

> But definitely keep us posted on the nature of the OSX issues.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From stefan at sun.ac.za  Tue Jun 24 18:56:50 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 25 Jun 2008 00:56:50 +0200
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
Message-ID: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>

2008/6/25 Fernando Perez <fperez.net at gmail.com>:
> On Tue, Jun 24, 2008 at 2:58 PM, Barry Wark <barrywark at gmail.com> wrote:
>> Just a side note on the VCS side of things...
>>
>> Bazaar appears to have a bunch of problems on OS X with directories
>> that are reached via AFP (Apple's file sharing protocol). I've filed a
>> bug with the bazaar folks, but as we start to push towards having a
>> more full featured Cocoa frontend for ipython, it's worth remembering
>> that some potential developers on OS X will have trouble using bazaar.
>> I'll keep the list posted on progress resolving this issue.

What kind of trouble?  I haven't come across any, but it would be good
to know what to watch out for.

> I have to say that I've given up on the whole 'history folding'
> problem, so I'm not 100% happy with bzr/lp either.  Basically if you
> have truly diverged lines of work where you did work and committed
> locally while other devs pushed, a merge is inevitable (even if you
> keep several branches and push only from one that you don't develop
> in).  And at that point, bzr does the whole 'dropped revisions' dance
> and folds history.

When branches diverge, a merge is necessary.  Some revision control
systems hide the merges, others (like bzr) don't.  How does mercurial
handle the issue?

Maybe I'm missing the whole point (feel free to tell me so): why is it
such a problem that there is extra information in the log?  Do any of
the log formats alleviate the problem?  Or is it mainly the issue that
launchpad has such a sucky log display?

Sorry if these are stupid questions, but I'd like to get to the bottom
of the whole thing.

Cheers!
St?fan


From barrywark at gmail.com  Tue Jun 24 19:03:46 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 24 Jun 2008 16:03:46 -0700
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
	<6ce0ac130806241547p4600c21fj14c3a8b4cb32e0ab@mail.gmail.com>
Message-ID: <cd7634ce0806241603l309946bat347d77ac3faad563@mail.gmail.com>

On Tue, Jun 24, 2008 at 3:47 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Bummer!  Please keep us posted.
>>
>> I have to say that I've given up on the whole 'history folding'
>> problem, so I'm not 100% happy with bzr/lp either.  Basically if you
>> have truly diverged lines of work where you did work and committed
>> locally while other devs pushed, a merge is inevitable (even if you
>> keep several branches and push only from one that you don't develop
>> in).  And at that point, bzr does the whole 'dropped revisions' dance
>> and folds history.
>
>> But on the whole we do gain from the ability to flexibly merge (even
>> with ugly history) and the support for contributors from launchpad is
>> vastly better than manually managing accounts on scipy.org and playing
>> admin-by-night, so it's a net gain.  Just not a perfect one :)
>
> Definitely not perfect, but I do agree that it is a net gain from
> before.  I would characterize this in the "Just Works" category, but
> with a "Not always quite the way you want it to" clause.  Judging from
> past experience (CVS-> SVN->bzr) these decisions are likely not final
> for all eternity.

I agree that it's not perfect, but much better than before. Progress
is always a bumpy road, and as Brian says, we can always choose to go
through this again in the future :)

>
> Cheers,
>
> Brian
>
>> But definitely keep us posted on the nature of the OSX issues.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>


From hans_meine at gmx.net  Wed Jun 25 08:14:25 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 25 Jun 2008 14:14:25 +0200
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
	<9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>
Message-ID: <200806251414.26194.hans_meine@gmx.net>

Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt:
> When branches diverge, a merge is necessary.  Some revision control
> systems hide the merges, others (like bzr) don't.  How does mercurial
> handle the issue?

(Background: I have recently switched to Mercurial with many of my projects 
and am constantly using it a lot, incl. many extensions and following the 
mailing list.  My bzr experience is near zero though.)

Mercurial does not handle any line of development special, i.e. you get to see 
the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg 
view").  AFAICS, bzr decides that one path from this graphs "root" to the tip 
is somehow special (IIRC called the "mainline") and only displays this by 
default (i.e. you see only one changeset when a branch is merged).

For example, here's an excerpt from an actual "hg log" output of mine, in 
which branching and merging occured:

...

changeset:   228:765851775ca5
user:        Hans Meine <hans_meine at gmx.net>
date:        Fri Apr 04 22:19:40 2008 +0200
summary:     Added tag release_0_4 for changeset 4180934dce9d

changeset:   227:4180934dce9d
tag:         release_0_4
parent:      226:fc47fb9bf558
parent:      225:29273fb40578
user:        Hans Meine <hans_meine at gmx.net>
date:        Fri Apr 04 22:04:00 2008 +0200
summary:     merged branch/dist.sh changes from Qt3 version

changeset:   226:fc47fb9bf558
parent:      222:1b6fee2f3be2
user:        Hans Meine <hans_meine at gmx.net>
date:        Fri Apr 04 22:03:13 2008 +0200
summary:     get rid of necessary VigraQt symlink

changeset:   225:29273fb40578
user:        Hans Meine <hans_meine at gmx.net>
date:        Fri Apr 04 21:59:46 2008 +0200
summary:     don't delete vigraqt.testing

changeset:   224:5d6c94f6de48
user:        Hans Meine <meine at informatik.uni-hamburg.de>
date:        Thu Apr 03 14:14:00 2008 +0200
summary:     adapt script to mercurial needs (remove CVS stuff)

changeset:   223:c478238d5ec0
parent:      179:776243786443
user:        Hans Meine <meine at informatik.uni-hamburg.de>
date:        Thu Apr 03 14:13:39 2008 +0200
summary:     Added tag release_0_4 for changeset 776243786443

changeset:   222:1b6fee2f3be2
user:        Hans Meine <hans_meine at gmx.net>
date:        Fri Apr 04 21:54:42 2008 +0200
summary:     remove old autotools-README

...

All changesets are displayed in the same format, no matter on which branch 
they occured.  (If I had used named branches, the above would 
include "branch: somebranch" though.)  The parent: lines indicate
a) branching, e.g. a specified parent that is != the previous revision (in 
which case "hg log" omits the line for brevity) and
b) merging, e.g. more than one parent.

Of course, graphical tools display this more nicely.  There's also "glog" 
("graphical log") which uses ASCII art:

...
|
o  changeset:   228:765851775ca5
|  user:        Hans Meine <hans_meine at gmx.net>
|  date:        Fri Apr 04 22:19:40 2008 +0200
|  summary:     Added tag release_0_4 for changeset 4180934dce9d
|
o    changeset:   227:4180934dce9d
|\   tag:         release_0_4
| |  parent:      226:fc47fb9bf558
| |  parent:      225:29273fb40578
| |  user:        Hans Meine <hans_meine at gmx.net>
| |  date:        Fri Apr 04 22:04:00 2008 +0200
| |  summary:     merged branch/dist.sh changes from Qt3 version
| |
| o  changeset:   226:fc47fb9bf558
| |  parent:      222:1b6fee2f3be2
| |  user:        Hans Meine <hans_meine at gmx.net>
| |  date:        Fri Apr 04 22:03:13 2008 +0200
| |  summary:     get rid of necessary VigraQt symlink
| |
o |  changeset:   225:29273fb40578
| |  user:        Hans Meine <hans_meine at gmx.net>
| |  date:        Fri Apr 04 21:59:46 2008 +0200
| |  summary:     don't delete vigraqt.testing
| |
o |  changeset:   224:5d6c94f6de48
| |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
| |  date:        Thu Apr 03 14:14:00 2008 +0200
| |  summary:     adapt script to mercurial needs (remove CVS stuff)
| |
o |  changeset:   223:c478238d5ec0
| |  parent:      179:776243786443
| |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
| |  date:        Thu Apr 03 14:13:39 2008 +0200
| |  summary:     Added tag release_0_4 for changeset 776243786443
| |
| |  ...
| |
| o  changeset:   181:d90cf77766a5
| |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
| |  date:        Thu Apr 03 15:40:18 2008 +0200
| |  summary:     Qt4 porting:
| |
| o  changeset:   180:f1910ad7c12b
|/   user:        Hans Meine <meine at informatik.uni-hamburg.de>
|    date:        Thu Apr 03 15:36:49 2008 +0200
|    summary:     Qt4 porting: QImage format stuff, add v2qc
|
o  changeset:   179:776243786443
|  user:        Hans Meine <meine at informatik.uni-hamburg.de>
|  date:        Thu Apr 03 14:03:26 2008 +0200
|  summary:     version bump -> 0.4
|
...

(BTW: This looks much better in a terminal than in a mailer who thinks 
that "|" starts a quote...)

In summary, I am extremely happy with mercurial and find it very easy to 
understand and work with.  I believe bzr is not much different, and launchpad 
looks nice, but I see the discussed history folding as the only serious 
reason why I would currently recommend hg over bzr.  OTOH, the situation 
could be much improved if lp would (allow to) display the complete history 
instead of only the "mainline" one AFAICS.

Hope that helped,
 Hans


From barrywark at gmail.com  Wed Jun 25 10:38:37 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 25 Jun 2008 07:38:37 -0700
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <200806251414.26194.hans_meine@gmx.net>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
	<9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
Message-ID: <cd7634ce0806250738o62fb35b1n258a71c12aa981c3@mail.gmail.com>

It does sound like hg has nice behavior in this regard. It wasn't my
intention, however, to restart the debate on DVCS systems. The hosting
and services provided by launchpad.net tip the benefits strongly in
favor of bzr for now and I think that's a good decision. Of course,
it's always nice to keep up with the options. I'm looking forward to
trying hg in the future.

On Wed, Jun 25, 2008 at 5:14 AM, Hans Meine <hans_meine at gmx.net> wrote:
> Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt:
>> When branches diverge, a merge is necessary.  Some revision control
>> systems hide the merges, others (like bzr) don't.  How does mercurial
>> handle the issue?
>
> (Background: I have recently switched to Mercurial with many of my projects
> and am constantly using it a lot, incl. many extensions and following the
> mailing list.  My bzr experience is near zero though.)
>
> Mercurial does not handle any line of development special, i.e. you get to see
> the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg
> view").  AFAICS, bzr decides that one path from this graphs "root" to the tip
> is somehow special (IIRC called the "mainline") and only displays this by
> default (i.e. you see only one changeset when a branch is merged).
>
> For example, here's an excerpt from an actual "hg log" output of mine, in
> which branching and merging occured:
>
> ...
>
> changeset:   228:765851775ca5
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:19:40 2008 +0200
> summary:     Added tag release_0_4 for changeset 4180934dce9d
>
> changeset:   227:4180934dce9d
> tag:         release_0_4
> parent:      226:fc47fb9bf558
> parent:      225:29273fb40578
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:04:00 2008 +0200
> summary:     merged branch/dist.sh changes from Qt3 version
>
> changeset:   226:fc47fb9bf558
> parent:      222:1b6fee2f3be2
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:03:13 2008 +0200
> summary:     get rid of necessary VigraQt symlink
>
> changeset:   225:29273fb40578
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 21:59:46 2008 +0200
> summary:     don't delete vigraqt.testing
>
> changeset:   224:5d6c94f6de48
> user:        Hans Meine <meine at informatik.uni-hamburg.de>
> date:        Thu Apr 03 14:14:00 2008 +0200
> summary:     adapt script to mercurial needs (remove CVS stuff)
>
> changeset:   223:c478238d5ec0
> parent:      179:776243786443
> user:        Hans Meine <meine at informatik.uni-hamburg.de>
> date:        Thu Apr 03 14:13:39 2008 +0200
> summary:     Added tag release_0_4 for changeset 776243786443
>
> changeset:   222:1b6fee2f3be2
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 21:54:42 2008 +0200
> summary:     remove old autotools-README
>
> ...
>
> All changesets are displayed in the same format, no matter on which branch
> they occured.  (If I had used named branches, the above would
> include "branch: somebranch" though.)  The parent: lines indicate
> a) branching, e.g. a specified parent that is != the previous revision (in
> which case "hg log" omits the line for brevity) and
> b) merging, e.g. more than one parent.
>
> Of course, graphical tools display this more nicely.  There's also "glog"
> ("graphical log") which uses ASCII art:
>
> ...
> |
> o  changeset:   228:765851775ca5
> |  user:        Hans Meine <hans_meine at gmx.net>
> |  date:        Fri Apr 04 22:19:40 2008 +0200
> |  summary:     Added tag release_0_4 for changeset 4180934dce9d
> |
> o    changeset:   227:4180934dce9d
> |\   tag:         release_0_4
> | |  parent:      226:fc47fb9bf558
> | |  parent:      225:29273fb40578
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 22:04:00 2008 +0200
> | |  summary:     merged branch/dist.sh changes from Qt3 version
> | |
> | o  changeset:   226:fc47fb9bf558
> | |  parent:      222:1b6fee2f3be2
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 22:03:13 2008 +0200
> | |  summary:     get rid of necessary VigraQt symlink
> | |
> o |  changeset:   225:29273fb40578
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 21:59:46 2008 +0200
> | |  summary:     don't delete vigraqt.testing
> | |
> o |  changeset:   224:5d6c94f6de48
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 14:14:00 2008 +0200
> | |  summary:     adapt script to mercurial needs (remove CVS stuff)
> | |
> o |  changeset:   223:c478238d5ec0
> | |  parent:      179:776243786443
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 14:13:39 2008 +0200
> | |  summary:     Added tag release_0_4 for changeset 776243786443
> | |
> | |  ...
> | |
> | o  changeset:   181:d90cf77766a5
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 15:40:18 2008 +0200
> | |  summary:     Qt4 porting:
> | |
> | o  changeset:   180:f1910ad7c12b
> |/   user:        Hans Meine <meine at informatik.uni-hamburg.de>
> |    date:        Thu Apr 03 15:36:49 2008 +0200
> |    summary:     Qt4 porting: QImage format stuff, add v2qc
> |
> o  changeset:   179:776243786443
> |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> |  date:        Thu Apr 03 14:03:26 2008 +0200
> |  summary:     version bump -> 0.4
> |
> ...
>
> (BTW: This looks much better in a terminal than in a mailer who thinks
> that "|" starts a quote...)
>
> In summary, I am extremely happy with mercurial and find it very easy to
> understand and work with.  I believe bzr is not much different, and launchpad
> looks nice, but I see the discussed history folding as the only serious
> reason why I would currently recommend hg over bzr.  OTOH, the situation
> could be much improved if lp would (allow to) display the complete history
> instead of only the "mainline" one AFAICS.
>
> Hope that helped,
>  Hans
> _______________________________________________
> 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 Jun 25 11:39:47 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 25 Jun 2008 09:39:47 -0600
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <200806251414.26194.hans_meine@gmx.net>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
	<9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
Message-ID: <6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com>

Thanks for the comments on hg.  As Barry said, I don't think we want
to revisit our choice of DVCS at this point.  That said, it actually
seems to be quite difficult to get a fair and accurate evaluation of
the various DVCS systems.  Here is what I have observed (taking the
liberty to make generalizations):

1.  _All_ of the DVCS make design decisions that make certain things
nice and other things less nice.  It is a question of trade offs.

2.  You almost never see the less nice things when you casually try
one of them out.  You really have to "get your hands dirty" before
these things come up.  By then you have already made the decision :)

3.  It is easy to get someone to detail the pros of one choice or the
cons of another, but it is really difficult to get someone to give a
fair and accurate survey of the pros and cons of all the choices.

4.  The few people who can give such an fair and accurate survey of
the choices know so much about DVCS that I can't understand half the
things they are talking about.

Cheers,

Brian

On Wed, Jun 25, 2008 at 6:14 AM, Hans Meine <hans_meine at gmx.net> wrote:
> Am Mittwoch, 25. Juni 2008 00:56:50 schrieb St?fan van der Walt:
>> When branches diverge, a merge is necessary.  Some revision control
>> systems hide the merges, others (like bzr) don't.  How does mercurial
>> handle the issue?
>
> (Background: I have recently switched to Mercurial with many of my projects
> and am constantly using it a lot, incl. many extensions and following the
> mailing list.  My bzr experience is near zero though.)
>
> Mercurial does not handle any line of development special, i.e. you get to see
> the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg
> view").  AFAICS, bzr decides that one path from this graphs "root" to the tip
> is somehow special (IIRC called the "mainline") and only displays this by
> default (i.e. you see only one changeset when a branch is merged).
>
> For example, here's an excerpt from an actual "hg log" output of mine, in
> which branching and merging occured:
>
> ...
>
> changeset:   228:765851775ca5
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:19:40 2008 +0200
> summary:     Added tag release_0_4 for changeset 4180934dce9d
>
> changeset:   227:4180934dce9d
> tag:         release_0_4
> parent:      226:fc47fb9bf558
> parent:      225:29273fb40578
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:04:00 2008 +0200
> summary:     merged branch/dist.sh changes from Qt3 version
>
> changeset:   226:fc47fb9bf558
> parent:      222:1b6fee2f3be2
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 22:03:13 2008 +0200
> summary:     get rid of necessary VigraQt symlink
>
> changeset:   225:29273fb40578
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 21:59:46 2008 +0200
> summary:     don't delete vigraqt.testing
>
> changeset:   224:5d6c94f6de48
> user:        Hans Meine <meine at informatik.uni-hamburg.de>
> date:        Thu Apr 03 14:14:00 2008 +0200
> summary:     adapt script to mercurial needs (remove CVS stuff)
>
> changeset:   223:c478238d5ec0
> parent:      179:776243786443
> user:        Hans Meine <meine at informatik.uni-hamburg.de>
> date:        Thu Apr 03 14:13:39 2008 +0200
> summary:     Added tag release_0_4 for changeset 776243786443
>
> changeset:   222:1b6fee2f3be2
> user:        Hans Meine <hans_meine at gmx.net>
> date:        Fri Apr 04 21:54:42 2008 +0200
> summary:     remove old autotools-README
>
> ...
>
> All changesets are displayed in the same format, no matter on which branch
> they occured.  (If I had used named branches, the above would
> include "branch: somebranch" though.)  The parent: lines indicate
> a) branching, e.g. a specified parent that is != the previous revision (in
> which case "hg log" omits the line for brevity) and
> b) merging, e.g. more than one parent.
>
> Of course, graphical tools display this more nicely.  There's also "glog"
> ("graphical log") which uses ASCII art:
>
> ...
> |
> o  changeset:   228:765851775ca5
> |  user:        Hans Meine <hans_meine at gmx.net>
> |  date:        Fri Apr 04 22:19:40 2008 +0200
> |  summary:     Added tag release_0_4 for changeset 4180934dce9d
> |
> o    changeset:   227:4180934dce9d
> |\   tag:         release_0_4
> | |  parent:      226:fc47fb9bf558
> | |  parent:      225:29273fb40578
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 22:04:00 2008 +0200
> | |  summary:     merged branch/dist.sh changes from Qt3 version
> | |
> | o  changeset:   226:fc47fb9bf558
> | |  parent:      222:1b6fee2f3be2
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 22:03:13 2008 +0200
> | |  summary:     get rid of necessary VigraQt symlink
> | |
> o |  changeset:   225:29273fb40578
> | |  user:        Hans Meine <hans_meine at gmx.net>
> | |  date:        Fri Apr 04 21:59:46 2008 +0200
> | |  summary:     don't delete vigraqt.testing
> | |
> o |  changeset:   224:5d6c94f6de48
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 14:14:00 2008 +0200
> | |  summary:     adapt script to mercurial needs (remove CVS stuff)
> | |
> o |  changeset:   223:c478238d5ec0
> | |  parent:      179:776243786443
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 14:13:39 2008 +0200
> | |  summary:     Added tag release_0_4 for changeset 776243786443
> | |
> | |  ...
> | |
> | o  changeset:   181:d90cf77766a5
> | |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> | |  date:        Thu Apr 03 15:40:18 2008 +0200
> | |  summary:     Qt4 porting:
> | |
> | o  changeset:   180:f1910ad7c12b
> |/   user:        Hans Meine <meine at informatik.uni-hamburg.de>
> |    date:        Thu Apr 03 15:36:49 2008 +0200
> |    summary:     Qt4 porting: QImage format stuff, add v2qc
> |
> o  changeset:   179:776243786443
> |  user:        Hans Meine <meine at informatik.uni-hamburg.de>
> |  date:        Thu Apr 03 14:03:26 2008 +0200
> |  summary:     version bump -> 0.4
> |
> ...
>
> (BTW: This looks much better in a terminal than in a mailer who thinks
> that "|" starts a quote...)
>
> In summary, I am extremely happy with mercurial and find it very easy to
> understand and work with.  I believe bzr is not much different, and launchpad
> looks nice, but I see the discussed history folding as the only serious
> reason why I would currently recommend hg over bzr.  OTOH, the situation
> could be much improved if lp would (allow to) display the complete history
> instead of only the "mainline" one AFAICS.
>
> Hope that helped,
>  Hans
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From hans_meine at gmx.net  Wed Jun 25 12:52:06 2008
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 25 Jun 2008 18:52:06 +0200
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<6ce0ac130806250839h2de3f5feu94ac6b8ad2d0c724@mail.gmail.com>
Message-ID: <200806251852.07200.hans_meine@gmx.net>

Am Mittwoch, 25. Juni 2008 17:39:47 schrieb Brian Granger:
> Thanks for the comments on hg.  As Barry said, I don't think we want
> to revisit our choice of DVCS at this point.

Sure, I just took the opportunity to document the different for future 
reference (maybe I put that up on some Wiki/Blog some day, but even now it 
will get archived).  There are already lots of (mostly outdated) DVCS 
comparisons out there, but I did not see this particular aspect (the presence 
of a "mainline" concept) discussed anywhere.

> 4.  The few people who can give such an fair and accurate survey of
> the choices know so much about DVCS that I can't understand half the
> things they are talking about.

And then people like to improve "their" DVCS such that every such survey 
becomes outdated sooner than you understood it...

Bottom line: I learned a lot from your public discussion of the particular 
warts bzr/lp posed on IPython, but I did not and will not propose a hg 
switch, don't worry.. ;-)

Greetings,
  Hans (who is looking forward to the frontend stuff, esp. for Qt4)


From vivainio at gmail.com  Wed Jun 25 13:22:30 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 25 Jun 2008 20:22:30 +0300
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <200806251414.26194.hans_meine@gmx.net>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<db6b5ecc0806241513w37b5529dre6876ecde7424ec9@mail.gmail.com>
	<9457e7c80806241556s1d014400ta3a6367e9ecd0765@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
Message-ID: <46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>

On Wed, Jun 25, 2008 at 3:14 PM, Hans Meine <hans_meine at gmx.net> wrote:

> Mercurial does not handle any line of development special, i.e. you get to see
> the complete, directed, acyclic graph e.g. in "hg log" (or "hg glog", "hg
> view").  AFAICS, bzr decides that one path from this graphs "root" to the tip

And the same works with bzr (bzr qlog / bzr viz). It's just about
revision numbers (that mean much more in bzr than they do in hg), and
what you see on launchpad revision history page.

This is actually a feature in bzr, and something that makes the UI of
bzr simpler than hg's. The big advantage of hg over bzr is speed, so
as long as we get decent performance out of bzr, this discussion is
not worth spending too much time/brain energy on. We are investigating
the use of hg at workplace, just because we'd like to have one version
control system that is suitable for projects of all sizes. If we were
only working on small projects (~ ipython size), I would have
recommended bzr - it does the "just works" thing quite well.

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


From barrywark at gmail.com  Wed Jun 25 14:33:52 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 25 Jun 2008 11:33:52 -0700
Subject: [IPython-dev] frontend plans
Message-ID: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>

Ga?l and I had a very nice talk this morning on future directions for
the frontend package and IPython frontends in general and I'd like to
let you all know what we were thinking.  I appologize that this
summary is somewhat terse. Writing about software development is not
(yet) one of my strengths. I don't have much time to dedicate to this
today and thought that a brief summary was better than a smoother??but
unsent?write-up.

Our discussion centered around Ga?l's use case. He's planning to write
a Wx frontend for IPython that has some concurency (or lack thereof)
guarantees. Namely, he wants everything to happen synchronously.
Furthermore, he would like to remove the Twisted dependency from
IPython.frontend if possible?if there's no asynchronous results in his
frontend, there appears to be no need for Twisted.  By way of
contrast, my Cocoa frontend is written to be fully asynchronous,
ultimately looking more like a Mathematica notebook than a terminal,
and Twisted is an acceptable dependency. Ga?l's requirements are very
similar to those of the basic terminal frontend, so I think it's in
everyone's interest to think about how to best meet those
requirements.

There seem to be two ways to get synchronous, Twisted-free frontends:

1 We could write an IPython.frontend.frontendbase.IFrontEnd
implementation that talks directly with IPython.kernel.core. A little
bit of trickery would easily remove the twisted.python.failure.Failure
dependency from IPython.frontend.frontendbase.

2, Write an implementation of IEngineCore that does not depend on
Twisted and returns results synchronously. Because the IEngine*
interface specifies that all methods return t.i.d.Deferred results, we
will need a mock Deferred object. The Synchronous-deferred project
(lp;syncrhonous-deferred) appears to fit the bill. License is public
domain, and it's two pure python files (one implementation, one test).
The project appears to be effectively "complete" -- no activity in
several months. I propose we include the syncrhonous deferred as an
external dependency in the IPython distribution. We could then write
an IEngineBase implementation that returns SynchronousDeferreds. This
engine implementation could be passed to FrontEndBase's constructor
and we get synchronous, twisted-free frontends [1]

Since the IEngine* interface is much more stable than the IFrontEnd
interface, I propose going with solution #2. Although it adds an
additional python file as external dependency, it seems conceptually
cleaner (all frontends go through the engine interface) and allows
frontends to decide between synchronous and asynchronous behavior
without any code changes.

If anyone has comments, let's have 'em. If folks think it's a good
idea, I'll create a branch and start making the changes outlined in #2
above.

The second issue Ga?l and I discussed was code completion in the front
end. As I understand it, Brian and Fernando want completion to happen
on the frontend to avoid network latency (and possible blocking engine
latency). In order to do this, however, the frontend needs a complete
copy of the user_ns. This means a large memory overhead and a lot of
synchronization issues. We don't have a very good solution at this
point. In the Cocoa frontend, I've played with mirroring the user_ns
top-level keys for completion but going to the engine after that, not
a very satisfying solution. We need ideas.

Barry

[1] Removing the Twisted dependence completely will require moving the
IEngine* interfaces to a separate module from the implementations. I
propose moving them to IPython.kernel.engineinterface.py.


From ellisonbg.net at gmail.com  Wed Jun 25 18:59:04 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 25 Jun 2008 16:59:04 -0600
Subject: [IPython-dev] frontend plans
In-Reply-To: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
Message-ID: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>

> Ga?l and I had a very nice talk this morning on future directions for
> the frontend package and IPython frontends in general and I'd like to
> let you all know what we were thinking.  I appologize that this
> summary is somewhat terse. Writing about software development is not
> (yet) one of my strengths. I don't have much time to dedicate to this
> today and thought that a brief summary was better than a smoother??but
> unsent?write-up.

Glad you two were able to talk.

> Our discussion centered around Ga?l's use case. He's planning to write
> a Wx frontend for IPython that has some concurency (or lack thereof)
> guarantees. Namely, he wants everything to happen synchronously.
> Furthermore, he would like to remove the Twisted dependency from
> IPython.frontend if possible?if there's no asynchronous results in his
> frontend, there appears to be no need for Twisted.  By way of
> contrast, my Cocoa frontend is written to be fully asynchronous,
> ultimately looking more like a Mathematica notebook than a terminal,
> and Twisted is an acceptable dependency. Ga?l's requirements are very
> similar to those of the basic terminal frontend, so I think it's in
> everyone's interest to think about how to best meet those
> requirements.

I think this is very true that a terminal based frontend and a
synchronous GUI frontend will be very similar in design.

> There seem to be two ways to get synchronous, Twisted-free frontends:
>
> 1 We could write an IPython.frontend.frontendbase.IFrontEnd
> implementation that talks directly with IPython.kernel.core. A little
> bit of trickery would easily remove the twisted.python.failure.Failure
> dependency from IPython.frontend.frontendbase.

I think that we could have a single base class that implements the
actual frontend logic and then have multiple subclasses that handle
the calls to the various types of backends (kernel.core or
kernel.engineservice).  I need to look more at how the frontend is
implemented, but Barry, do you think this would work.

The other idea would be to play around with using adaptors to handle
the impedance mismatches in the interfaces.

> 2, Write an implementation of IEngineCore that does not depend on
> Twisted and returns results synchronously. Because the IEngine*
> interface specifies that all methods return t.i.d.Deferred results, we
> will need a mock Deferred object. The Synchronous-deferred project
> (lp;syncrhonous-deferred) appears to fit the bill. License is public
> domain, and it's two pure python files (one implementation, one test).
> The project appears to be effectively "complete" -- no activity in
> several months. I propose we include the syncrhonous deferred as an
> external dependency in the IPython distribution. We could then write
> an IEngineBase implementation that returns SynchronousDeferreds. This
> engine implementation could be passed to FrontEndBase's constructor
> and we get synchronous, twisted-free frontends [1]

I am not sure about this one.  The dependency is not just twisted, but
also zope.interface and these two can't really be separated from each
other or things in i.k.  Because zope.interface has C code, we can't
depend on it in the core of IPython or the terminal based IPython (we
want it to work on non CPython implementations).  This can be worked
around by simply not having the implementation declare that it
implements the z.i IEngineCore interface.  But, in either case, that
version of the IEngineCore should not live in i.k as there are twisted
imports _everywhere_.  [as an aside, I think we really need to use
subpackages to encapsulate dependencies like twisted.]

Also, the Synchronous deferred does not present the exact same
interface as a true deferred or make the same promises about when
things will happen.  Thus, I my mind, the new IEngineCore
implementation _couldn't_ possible really implement the interface.  In
fact, if I remember correctly, we have a test that can be run on any
IEngineCore implementer.  It actually calls all the methods of the
interface and checks:

self.assert_(isinstance(return_value, t.i.Deferred)

A fake deferred won't pass such tests.

So, in summary, I think more discussion is needed before commiting to
#2.  I am crazy busy, but I will try to have a look at IFrontEnd
tonight.


> Since the IEngine* interface is much more stable than the IFrontEnd
> interface, I propose going with solution #2. Although it adds an
> additional python file as external dependency, it seems conceptually
> cleaner (all frontends go through the engine interface) and allows
> frontends to decide between synchronous and asynchronous behavior
> without any code changes.

I think it is conceptually convoluted because the only significant way
that IEngireCore different from the underlying core is that its
methods return deferreds (and Failures).  Thus to use IEngineCore, but
then try to get rid of the (true) Deferreds by using fake ones seems
like double work (why not just call the class whose methods don't
return deferreds in the first place).

> If anyone has comments, let's have 'em. If folks think it's a good
> idea, I'll create a branch and start making the changes outlined in #2
> above.
>
> The second issue Ga?l and I discussed was code completion in the front
> end. As I understand it, Brian and Fernando want completion to happen
> on the frontend to avoid network latency (and possible blocking engine
> latency). In order to do this, however, the frontend needs a complete
> copy of the user_ns. This means a large memory overhead and a lot of
> synchronization issues. We don't have a very good solution at this
> point. In the Cocoa frontend, I've played with mirroring the user_ns
> top-level keys for completion but going to the engine after that, not
> a very satisfying solution. We need ideas.

Actually, I think we are in agreement that tab completion (the part
that actually looks up things in the users namespace) needs to be done
in the engine/core through its complete method.  There is just no way
it is reasonable to mirror the user_ns in the frontend for the reasons
you mention.  Sorry if we have said anything confusion on this front.
So I guess the complete method of the frontend should just call the
complete method of the engine/core?

Cheers,

Brian

> Barry
>
> [1] Removing the Twisted dependence completely will require moving the
> IEngine* interfaces to a separate module from the implementations. I
> propose moving them to IPython.kernel.engineinterface.py.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From laurent.dufrechou at gmail.com  Thu Jun 26 08:43:20 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Thu, 26 Jun 2008 14:43:20 +0200
Subject: [IPython-dev] Moving forward with the frontends
In-Reply-To: <46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com>
References: <20080623181632.GF13966@phare.normalesup.org>
	<46cb515a0806232303v1d689696ybc99fd0f996e8c9@mail.gmail.com>
Message-ID: <48638eef.02578c0a.5d98.0aee@mx.google.com>

Hi Gael,All
I'm in Canada right now for business, so I missed some email :)
Don't know if it could be interesting but I think you could try to add
ipython1 handling in ipshell_nonblocking.py, Thus we could share this part
of code and improve it together.
(It's up to you :) )
Basically if you go this way, I think you'll have to define an ipython1 init
and ipython1_execute command, and you should be done. (That is indeed a lot
of work :) ).
(Modifying doExecute function should permit you to be or not multithreaded)
Perhaps we can think about doing a base class and deriavate from it to work
with either ipython0 or ipython1 to get a cleaner code... don't know)

Do you plan to use scintilla widget? 

Laurent

> -----Message d'origine-----
> De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-
> bounces at scipy.org] De la part de Ville M. Vainio
> Envoy??: mardi 24 juin 2008 08:04
> ??: Gael Varoquaux
> Cc?: ipython-dev Mailing list
> Objet?: Re: [IPython-dev] Moving forward with the frontends
> 
> On Mon, Jun 23, 2008 at 9:16 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
> 
> > integrate IPython in Mayavi and other similar projects. The
> requirements
> > are:
> >
> >  * We want something fast, not after three months of work
> 
> >  * We are interested in wx. I am of course happy sharing the code
> with
> >    other frontends, but I will not be developping them.
> 
> >  * The feature of ipython we are interested in are magics, "?" and
> "??",
> >    tab completion, history, and alike...
> 
> > I am currently reviewing the existing code. I see three code bases
> for
> > front end:
> >
> >    * Laurent Dufrechou's WxIpython, living in the trunk, in
> >      IPython/gui/wx
> 
> I think this is the winner here, given the preconditions above. It
> seems it would be pretty easy to integrate.
> 
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From laurent.dufrechou at gmail.com  Thu Jun 26 09:05:51 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Thu, 26 Jun 2008 15:05:51 +0200
Subject: [IPython-dev] pyreadline refactoring
In-Reply-To: <cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>
References: <48614E0D.30901@bostream.nu>
	<cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>
Message-ID: <48639436.1f588c0a.5ade.15d5@mx.google.com>

Hi Jorgen,

Good news :)
When i wrote ipython0 wx frontend i ran into some problem with readline.
(And perhaps I ran in these problems because I don't enter enough in
pyreadline code who knows...)
- History (the biggest one):
It was not that easy to get these information:
HistoryBack and HistoryForward, and history current length.
So if you could add some simple and direct method that permit to load a
history from file, and manage an history pointer I'll be very very happy.
If you don't understand what I mean just have a look at line 300 of
ipshell_nonblocking.py in /gui/wx I think you'll see what I didn't found in
pyreadline.
I fact should be good to have some simple function to get easily an history.
Currently to get history I use....:
IP.input_hist_raw[self._history_level].strip('\n')
That is far from ideal...

- In my code I used pyreadline capabilities to get ascii colored outputted
datas.
Do you think it could be possible to add some other output formatter like
for example an xml formatter or html for example. Perhaps just a method to
bypass classical readline formatter and people could add their formatter
(thus we could step by step add new formatter to readline code)
Just an idea...

- Can it be possible to use readline only for history and output formating?
I mean without key handling and cursor management? (If for example I want
for any reason manage them myself)

Laurent

> -----Message d'origine-----
> De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-
> bounces at scipy.org] De la part de Barry Wark
> Envoy??: mercredi 25 juin 2008 00:37
> ??: J?rgen Stenarson
> Cc?: IPython-dev List
> Objet?: Re: [IPython-dev] pyreadline refactoring
> 
> On Tue, Jun 24, 2008 at 12:42 PM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
> > Hi,
> >
> > I have started to work on a refactoring of pyreadline with the goal
> to
> > untangle the class interactions that have made it difficult to reuse
> > pyreadline in other circumstances than a shell on win32.
> >
> > The basic idea is that it should be possible to call a readline
> object
> > with keypress events containing (control, shift, meta, char, keyname)
> > where keyname is for special keys like space, f1, return etc.
> >
> > The readline object would be responsible for keeping track of current
> > prompt, line_buffer, cursor_position and selection_position. But the
> > caller of the object will have to render the buffer.
> >
> > I have also merged the callback branch I worked on a few months back.
> > The branch is at lp:~jorgen-stenarson/pyreadline/pyreadline-refactor
> >
> > If anyone has any ideas or suggestions on how things should work
> please
> > let me know.
> 
> J?rgen,
> 
> Wow, this is an exciting move in view of the plans to separate
> ipython0's core from the terminal/readline. I am still learning about
> pyreadline, but your description above makes me think that you, me,
> and Ga?l should think about using the new (refactored) pyreadline in
> developing a base class for front ends that are based on a
> line-oriented interface (i.e. mimicking the terminal interface).
> 
> Barry
> 
> >
> > /J?rgen
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From vivainio at gmail.com  Thu Jun 26 12:49:02 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 26 Jun 2008 19:49:02 +0300
Subject: [IPython-dev] pyreadline refactoring
In-Reply-To: <48639436.1f588c0a.5ade.15d5@mx.google.com>
References: <48614E0D.30901@bostream.nu>
	<cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>
	<48639436.1f588c0a.5ade.15d5@mx.google.com>
Message-ID: <46cb515a0806260949k1ede361dq3791754dcb9ac940@mail.gmail.com>

On Thu, Jun 26, 2008 at 4:05 PM, Laurent Dufr?chou
<laurent.dufrechou at gmail.com> wrote:

> I fact should be good to have some simple function to get easily an history.
> Currently to get history I use....:
> IP.input_hist_raw[self._history_level].strip('\n')
> That is far from ideal...

It's trivial to wrap; it just needs to be done :).

> - In my code I used pyreadline capabilities to get ascii colored outputted
> datas.
> Do you think it could be possible to add some other output formatter like
> for example an xml formatter or html for example. Perhaps just a method to

Yes, but you will still need to support the colored output from system
commands, so the ANSI code handling needs to be there in the end.

Someone could write a html/xml colorizer to allow convenient/readable
color coding, of course, but it could as well be a simple function
that converts stuff to ANSI color codes.

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


From vivainio at gmail.com  Thu Jun 26 12:56:40 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 26 Jun 2008 19:56:40 +0300
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <200806261341.14255.hans_meine@gmx.net>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
Message-ID: <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>

On Thu, Jun 26, 2008 at 2:41 PM, Hans Meine <hans_meine at gmx.net> wrote:

> I tend to think it's again the Zen of Python (explicit is better than
> implicit).  I would reconsider it as a "good" feature if you had explicit
> control over which path through history is considered to be the mainline.

You have explicit control of that - I guess that's what is the reason
for the history folding problem ;-)

The sole cause of the history folding problem is that people push the
wrong branch to the wrong place. Once you observe some caution as to
what you push and where, it's a non-issue. We wouldn't even be talking
about this if launchpad had a checkbox somewhere that prevented
pushing to the wrong branch, or at least required some kind of --force
option to do it. That not being the case, we have to observe some
caution. I guess this is comparable to python vs. C++ - we don't have
a compiler, so we can't count on our tools to safeguard us against
something, but we get by.

This should be pretty easy to fix by bzr developers, but I'm not sure
how much it has been talked about (and am rather too busy to engage in
the conversation on bzr mailing list ATM).

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


From jorgen.stenarson at bostream.nu  Thu Jun 26 13:37:18 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 26 Jun 2008 19:37:18 +0200
Subject: [IPython-dev] pyreadline refactoring
In-Reply-To: <cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>
References: <48614E0D.30901@bostream.nu>
	<cd7634ce0806241536g16fffb96saa5449180b8a3d0c@mail.gmail.com>
Message-ID: <4863D3CE.2010707@bostream.nu>

Barry Wark skrev:
> 
> Wow, this is an exciting move in view of the plans to separate
> ipython0's core from the terminal/readline. I am still learning about
> pyreadline, but your description above makes me think that you, me,
> and Ga?l should think about using the new (refactored) pyreadline in
> developing a base class for front ends that are based on a
> line-oriented interface (i.e. mimicking the terminal interface).
> 
> Barry
> 

I'm happy to hear you would like to help out. Attached is a mockup of a 
gui calling readline, does this approach seem reasonable to you as a 
starting point.

I'm inexperienced in building guis so I would appreciate some help in 
improving the eventhandler to translate keyevents to a KeyEvent object.
At a first glance at the event handling in Tk it seems it requires some 
work to get the control, shift, meta modifiers that were used for a 
certain keypress. So right now this example needs improvement so we can 
handle those modifiers. This is where I would appreciate to get some 
assistance, I would prefer to have such an example in Tk or Wx since 
those are the systems I use the most.

It would also be nice to able to draw the cursor and also to mark a text 
selection as well.

best regards,
J?rgen



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tk_gui.py
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080626/1d8745d3/attachment.ksh>

From jorgen.stenarson at bostream.nu  Thu Jun 26 16:17:49 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 26 Jun 2008 22:17:49 +0200
Subject: [IPython-dev] pyreadline tkgui example
Message-ID: <4863F96D.8020304@bostream.nu>

Hi,

in the lp:~jorgen-stenarson/pyreadline/pyreadline-refactor branch there 
is now an example in pyreadline/examples/tk_gui.py.

It uses the BaseReadline class to implement readline. The basic edit 
functionality is there. But there is now cursor or selection marking.

/J?rgen


From barrywark at gmail.com  Thu Jun 26 16:54:52 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 26 Jun 2008 13:54:52 -0700
Subject: [IPython-dev] frontend plans
In-Reply-To: <6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
Message-ID: <cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>

On Wed, Jun 25, 2008 at 3:59 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Ga?l and I had a very nice talk this morning on future directions for
>> the frontend package and IPython frontends in general and I'd like to
>> let you all know what we were thinking.  I appologize that this
>> summary is somewhat terse. Writing about software development is not
>> (yet) one of my strengths. I don't have much time to dedicate to this
>> today and thought that a brief summary was better than a smoother??but
>> unsent?write-up.
>
> Glad you two were able to talk.
>
>> Our discussion centered around Ga?l's use case. He's planning to write
>> a Wx frontend for IPython that has some concurency (or lack thereof)
>> guarantees. Namely, he wants everything to happen synchronously.
>> Furthermore, he would like to remove the Twisted dependency from
>> IPython.frontend if possible?if there's no asynchronous results in his
>> frontend, there appears to be no need for Twisted.  By way of
>> contrast, my Cocoa frontend is written to be fully asynchronous,
>> ultimately looking more like a Mathematica notebook than a terminal,
>> and Twisted is an acceptable dependency. Ga?l's requirements are very
>> similar to those of the basic terminal frontend, so I think it's in
>> everyone's interest to think about how to best meet those
>> requirements.
>
> I think this is very true that a terminal based frontend and a
> synchronous GUI frontend will be very similar in design.
>
>> There seem to be two ways to get synchronous, Twisted-free frontends:
>>
>> 1 We could write an IPython.frontend.frontendbase.IFrontEnd
>> implementation that talks directly with IPython.kernel.core. A little
>> bit of trickery would easily remove the twisted.python.failure.Failure
>> dependency from IPython.frontend.frontendbase.
>
> I think that we could have a single base class that implements the
> actual frontend logic and then have multiple subclasses that handle
> the calls to the various types of backends (kernel.core or
> kernel.engineservice).  I need to look more at how the frontend is
> implemented, but Barry, do you think this would work.

Yes, I think this would work. I thought zope.interface was pure
python. Since we can't require zope.interface in the stripped-down
ipython, I now think option 1 is the best approach. I'll work on that.

>
> The other idea would be to play around with using adaptors to handle
> the impedance mismatches in the interfaces.
>
>> 2, Write an implementation of IEngineCore that does not depend on
>> Twisted and returns results synchronously. Because the IEngine*
>> interface specifies that all methods return t.i.d.Deferred results, we
>> will need a mock Deferred object. The Synchronous-deferred project
>> (lp;syncrhonous-deferred) appears to fit the bill. License is public
>> domain, and it's two pure python files (one implementation, one test).
>> The project appears to be effectively "complete" -- no activity in
>> several months. I propose we include the syncrhonous deferred as an
>> external dependency in the IPython distribution. We could then write
>> an IEngineBase implementation that returns SynchronousDeferreds. This
>> engine implementation could be passed to FrontEndBase's constructor
>> and we get synchronous, twisted-free frontends [1]
>
> I am not sure about this one.  The dependency is not just twisted, but
> also zope.interface and these two can't really be separated from each
> other or things in i.k.  Because zope.interface has C code, we can't
> depend on it in the core of IPython or the terminal based IPython (we
> want it to work on non CPython implementations).

I didn't realize this. I thought zope.interface was pure Python. That
seems to be a show-stopper for option 2.

This can be worked
> around by simply not having the implementation declare that it
> implements the z.i IEngineCore interface.  But, in either case, that
> version of the IEngineCore should not live in i.k as there are twisted
> imports _everywhere_.  [as an aside, I think we really need to use
> subpackages to encapsulate dependencies like twisted.]

By moving the interfaces to a separate module, we could import
i.k.engineinterfaces.py without needing twisted, though obviously
zope.interface would still be required.

>
> Also, the Synchronous deferred does not present the exact same
> interface as a true deferred or make the same promises about when
> things will happen.

What is your understanding of the differences?

Thus, I my mind, the new IEngineCore
> implementation _couldn't_ possible really implement the interface.  In
> fact, if I remember correctly, we have a test that can be run on any
> IEngineCore implementer.  It actually calls all the methods of the
> interface and checks:
>
> self.assert_(isinstance(return_value, t.i.Deferred)
>
> A fake deferred won't pass such tests.

I don't think this is an appropriate test then. The interface should
specify the behavior of the returned object, not its implementation.
If the Synchronous Deferred behaves the same as a t.i.defer.Deferred,
then it should pass the test. The fact that it may not behave the same
is a bigger issue.

>
> So, in summary, I think more discussion is needed before commiting to
> #2.  I am crazy busy, but I will try to have a look at IFrontEnd
> tonight.

>
>
>> Since the IEngine* interface is much more stable than the IFrontEnd
>> interface, I propose going with solution #2. Although it adds an
>> additional python file as external dependency, it seems conceptually
>> cleaner (all frontends go through the engine interface) and allows
>> frontends to decide between synchronous and asynchronous behavior
>> without any code changes.
>
> I think it is conceptually convoluted because the only significant way
> that IEngireCore different from the underlying core is that its
> methods return deferreds (and Failures).  Thus to use IEngineCore, but
> then try to get rid of the (true) Deferreds by using fake ones seems
> like double work (why not just call the class whose methods don't
> return deferreds in the first place).

It feels weird that there are two ways to interact with ipython?engine
and core directly. It seemed that making a common interface was
cleaner in that it allowed users of that interface to be able to use
engine or core without modification of the frontend. Since that's not
really an option anymore (because of zope.interface), I'm happy to
give up that opinion and move on.
>
>> If anyone has comments, let's have 'em. If folks think it's a good
>> idea, I'll create a branch and start making the changes outlined in #2
>> above.
>>
>> The second issue Ga?l and I discussed was code completion in the front
>> end. As I understand it, Brian and Fernando want completion to happen
>> on the frontend to avoid network latency (and possible blocking engine
>> latency). In order to do this, however, the frontend needs a complete
>> copy of the user_ns. This means a large memory overhead and a lot of
>> synchronization issues. We don't have a very good solution at this
>> point. In the Cocoa frontend, I've played with mirroring the user_ns
>> top-level keys for completion but going to the engine after that, not
>> a very satisfying solution. We need ideas.
>
> Actually, I think we are in agreement that tab completion (the part
> that actually looks up things in the users namespace) needs to be done
> in the engine/core through its complete method.  There is just no way
> it is reasonable to mirror the user_ns in the frontend for the reasons
> you mention.  Sorry if we have said anything confusion on this front.
> So I guess the complete method of the frontend should just call the
> complete method of the engine/core?

Yes. I agree. frontend.complete() calls engine/core.complete().

>
> Cheers,
>
> Brian
>
>> Barry
>>
>> [1] Removing the Twisted dependence completely will require moving the
>> IEngine* interfaces to a separate module from the implementations. I
>> propose moving them to IPython.kernel.engineinterface.py.
>> _______________________________________________
>> 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 Jun 26 17:32:01 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 26 Jun 2008 14:32:01 -0700
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
Message-ID: <db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>

On Thu, Jun 26, 2008 at 9:56 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

> The sole cause of the history folding problem is that people push the
> wrong branch to the wrong place. Once you observe some caution as to
> what you push and where, it's a non-issue.

Mmh, then there's something I've missed.  Because even though I'm
using the two-branch model, one to keep pulling/pushing upstream and
one for local development, I'm *still* getting the same folding issue
when true merging is required.  Basically if there's the need for a
real merge, because I've done work in my local branch while someone
else has pushed to trunk, we get that.  In that  case, --pull fails
with the 'branches have diverged' message and one is forced to merge.

I think that we only have a small issue, and it's one I'm willing to
ignore from now on: Launchpad (*not* bzr, since bzr viz/log is
faithful to the full history) ignores all but one branch when showing
history, and what it actually shows can change with each commit.  When
they improve their display, great, but until then let's just ignore
that point (we're all too busy here to spend time fixing lp).

But the fact that sometimes one *must* merge is unavoidable with
distributed development: even using a special branch for communicating
with upstream, merges sometimes are unavoidable.  Else I'm really
missing something here.

Cheers,

f


From ellisonbg.net at gmail.com  Thu Jun 26 19:03:35 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 26 Jun 2008 17:03:35 -0600
Subject: [IPython-dev] frontend plans
In-Reply-To: <cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
Message-ID: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>

Barry,

>> I think that we could have a single base class that implements the
>> actual frontend logic and then have multiple subclasses that handle
>> the calls to the various types of backends (kernel.core or
>> kernel.engineservice).  I need to look more at how the frontend is
>> implemented, but Barry, do you think this would work.
>
> Yes, I think this would work. I thought zope.interface was pure
> python. Since we can't require zope.interface in the stripped-down
> ipython, I now think option 1 is the best approach. I'll work on that.

Great, I think that will be best, even though it has its own downsides.

>> Also, the Synchronous deferred does not present the exact same
>> interface as a true deferred or make the same promises about when
>> things will happen.
>
> What is your understanding of the differences?

For Deferreds, I think the interface is not a complete specification
of the objects behavior.  For Deferreds, there are subtle cases that
arise when you chain them together.  The behavior exhibited in complex
Deferred chaining _can_ depend on whether or a given Deferred has
fired or not when the chaining is setup.  We have in various places
that handles these odd edge cases.  Also, we sometimes access the
semi-private attributes of Deferreds.  Another thing is that if you
have multiple unfired Deferreds, the order in which they will fire is
not deterministic.  For the synchronous deferreds, I think the
ordering has to be deterministic.  But in my mind, this constitues a
different behavior and thus "interface" in the board sense of the
word.

We might be able to get the synchronous deferreds to work, but I am a
little hesitant to go down that route simply because all of these
things are _super_ subtle and nearly impossible to debug.

> Thus, I my mind, the new IEngineCore
>> implementation _couldn't_ possible really implement the interface.  In
>> fact, if I remember correctly, we have a test that can be run on any
>> IEngineCore implementer.  It actually calls all the methods of the
>> interface and checks:
>>
>> self.assert_(isinstance(return_value, t.i.Deferred)
>>
>> A fake deferred won't pass such tests.
>
> I don't think this is an appropriate test then. The interface should
> specify the behavior of the returned object, not its implementation.
> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred,
> then it should pass the test. The fact that it may not behave the same
> is a bigger issue.

True, I could write a better test for this.  The current test is only
a super weak test behavior wise, but given the fact that there are no
other objects that truly act like a Deferred, the test suffices.

>>
>> So, in summary, I think more discussion is needed before commiting to
>> #2.  I am crazy busy, but I will try to have a look at IFrontEnd
>> tonight.
>
>>
>>
>>> Since the IEngine* interface is much more stable than the IFrontEnd
>>> interface, I propose going with solution #2. Although it adds an
>>> additional python file as external dependency, it seems conceptually
>>> cleaner (all frontends go through the engine interface) and allows
>>> frontends to decide between synchronous and asynchronous behavior
>>> without any code changes.
>>
>> I think it is conceptually convoluted because the only significant way
>> that IEngireCore different from the underlying core is that its
>> methods return deferreds (and Failures).  Thus to use IEngineCore, but
>> then try to get rid of the (true) Deferreds by using fake ones seems
>> like double work (why not just call the class whose methods don't
>> return deferreds in the first place).
>
> It feels weird that there are two ways to interact with ipython?engine
> and core directly. It seemed that making a common interface was
> cleaner in that it allowed users of that interface to be able to use
> engine or core without modification of the frontend. Since that's not
> really an option anymore (because of zope.interface), I'm happy to
> give up that opinion and move on.

I do sort of agree with this, but I think having two interfaces is
appropriate because they have vastly different behaviors (synchronous
vs asynchronous).

>> Actually, I think we are in agreement that tab completion (the part
>> that actually looks up things in the users namespace) needs to be done
>> in the engine/core through its complete method.  There is just no way
>> it is reasonable to mirror the user_ns in the frontend for the reasons
>> you mention.  Sorry if we have said anything confusion on this front.
>> So I guess the complete method of the frontend should just call the
>> complete method of the engine/core?
>
> Yes. I agree. frontend.complete() calls engine/core.complete().

Cool,

Cheers,

Brian

>>
>> Cheers,
>>
>> Brian
>>
>>> Barry
>>>
>>> [1] Removing the Twisted dependence completely will require moving the
>>> IEngine* interfaces to a separate module from the implementations. I
>>> propose moving them to IPython.kernel.engineinterface.py.
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>


From gael.varoquaux at normalesup.org  Thu Jun 26 22:12:12 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 27 Jun 2008 04:12:12 +0200
Subject: [IPython-dev] frontend plans
In-Reply-To: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
	<6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
Message-ID: <20080627021212.GA11323@phare.normalesup.org>

Hey guys,

And wanted to thank you very much for hashing down the ideas to get this
working. I have no understanding of the code we are talking about and it
is very valuable to have you around. I am sorry I haven't contributed
much to the discussion. I just taught a class on Mayavi and preparing it
and teaching it got me out of order for a day and a half.

I am time sharing between this project and another one, and the rest of
this week will be spent on the other project, so I won't come up with
interesting questions or comments, but don't worry, I'll switch back to
this next week.

Cheers,

Ga?l


From barrywark at gmail.com  Thu Jun 26 23:12:39 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 26 Jun 2008 20:12:39 -0700
Subject: [IPython-dev] frontend plans
In-Reply-To: <20080627021212.GA11323@phare.normalesup.org>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
	<6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
	<20080627021212.GA11323@phare.normalesup.org>
Message-ID: <cd7634ce0806262012i34618defx4a96ff276cae12c9@mail.gmail.com>

On Thu, Jun 26, 2008 at 7:12 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hey guys,
>
> And wanted to thank you very much for hashing down the ideas to get this
> working. I have no understanding of the code we are talking about and it
> is very valuable to have you around. I am sorry I haven't contributed
> much to the discussion. I just taught a class on Mayavi and preparing it
> and teaching it got me out of order for a day and a half.
>
> I am time sharing between this project and another one, and the rest of
> this week will be spent on the other project, so I won't come up with
> interesting questions or comments, but don't worry, I'll switch back to
> this next week.

No worries. I'm not likely to get to this in ernest until then either.
We can walk blindly into the abyss together :)

cheers,
barry

>
> Cheers,
>
> Ga?l
>


From barrywark at gmail.com  Thu Jun 26 23:18:27 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 26 Jun 2008 20:18:27 -0700
Subject: [IPython-dev] frontend plans
In-Reply-To: <6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
	<6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
Message-ID: <cd7634ce0806262018g2deae150w9f39d7db82e55eb1@mail.gmail.com>

On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Barry,
>
>>> I think that we could have a single base class that implements the
>>> actual frontend logic and then have multiple subclasses that handle
>>> the calls to the various types of backends (kernel.core or
>>> kernel.engineservice).  I need to look more at how the frontend is
>>> implemented, but Barry, do you think this would work.
>>
>> Yes, I think this would work. I thought zope.interface was pure
>> python. Since we can't require zope.interface in the stripped-down
>> ipython, I now think option 1 is the best approach. I'll work on that.
>
> Great, I think that will be best, even though it has its own downsides.

We're in agreement then. I'll try option 1 and see how that shakes out.

>
>>> Also, the Synchronous deferred does not present the exact same
>>> interface as a true deferred or make the same promises about when
>>> things will happen.
>>
>> What is your understanding of the differences?
>
> For Deferreds, I think the interface is not a complete specification
> of the objects behavior.  For Deferreds, there are subtle cases that
> arise when you chain them together.  The behavior exhibited in complex
> Deferred chaining _can_ depend on whether or a given Deferred has
> fired or not when the chaining is setup.  We have in various places
> that handles these odd edge cases.  Also, we sometimes access the
> semi-private attributes of Deferreds.  Another thing is that if you
> have multiple unfired Deferreds, the order in which they will fire is
> not deterministic.  For the synchronous deferreds, I think the
> ordering has to be deterministic.  But in my mind, this constitues a
> different behavior and thus "interface" in the board sense of the
> word.
>
> We might be able to get the synchronous deferreds to work, but I am a
> little hesitant to go down that route simply because all of these
> things are _super_ subtle and nearly impossible to debug.

I see the issues. Too bad; the Twisted universe seems to want to
swallow its victims whole. I should have really seen this coming--I've
worked on a Cocoa framework that uses OS X's NSOperationQueue to
emulate the Twisted reactor/Deferred system. You're exactly right that
the Deferred behavior is _very_ complicated when you dig into it. Oh,
well. As long as we're willing to skip the engineservice layer for
synchronous interface to core, it's not an issue and we can forget
about Synchronous Deferreds.

>
>> Thus, I my mind, the new IEngineCore
>>> implementation _couldn't_ possible really implement the interface.  In
>>> fact, if I remember correctly, we have a test that can be run on any
>>> IEngineCore implementer.  It actually calls all the methods of the
>>> interface and checks:
>>>
>>> self.assert_(isinstance(return_value, t.i.Deferred)
>>>
>>> A fake deferred won't pass such tests.
>>
>> I don't think this is an appropriate test then. The interface should
>> specify the behavior of the returned object, not its implementation.
>> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred,
>> then it should pass the test. The fact that it may not behave the same
>> is a bigger issue.
>
> True, I could write a better test for this.  The current test is only
> a super weak test behavior wise, but given the fact that there are no
> other objects that truly act like a Deferred, the test suffices.
>
>>>
>>> So, in summary, I think more discussion is needed before commiting to
>>> #2.  I am crazy busy, but I will try to have a look at IFrontEnd
>>> tonight.
>>
>>>
>>>
>>>> Since the IEngine* interface is much more stable than the IFrontEnd
>>>> interface, I propose going with solution #2. Although it adds an
>>>> additional python file as external dependency, it seems conceptually
>>>> cleaner (all frontends go through the engine interface) and allows
>>>> frontends to decide between synchronous and asynchronous behavior
>>>> without any code changes.
>>>
>>> I think it is conceptually convoluted because the only significant way
>>> that IEngireCore different from the underlying core is that its
>>> methods return deferreds (and Failures).  Thus to use IEngineCore, but
>>> then try to get rid of the (true) Deferreds by using fake ones seems
>>> like double work (why not just call the class whose methods don't
>>> return deferreds in the first place).
>>
>> It feels weird that there are two ways to interact with ipython?engine
>> and core directly. It seemed that making a common interface was
>> cleaner in that it allowed users of that interface to be able to use
>> engine or core without modification of the frontend. Since that's not
>> really an option anymore (because of zope.interface), I'm happy to
>> give up that opinion and move on.
>
> I do sort of agree with this, but I think having two interfaces is
> appropriate because they have vastly different behaviors (synchronous
> vs asynchronous).

Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core
is still the 'real' IPython. I.kernel is just a Twised wrapper around
that core. Naturally anything that doesn't want what Twisted has to
offer should talk directly with I.kernel.core and the price they pay
is that they loose all the goodies that come with the I.kernel layer.
Now that I just wrote this out, it seems wrong that I.kernel.core is a
subpackage of I.kernel. I know that it's there to isolate the ipython1
stuff from ipython0 stuff, but before too many people start writing
code using I.kernel.core, is it worth discussing if there's a better
spot for it in the IPython tree?

>
>>> Actually, I think we are in agreement that tab completion (the part
>>> that actually looks up things in the users namespace) needs to be done
>>> in the engine/core through its complete method.  There is just no way
>>> it is reasonable to mirror the user_ns in the frontend for the reasons
>>> you mention.  Sorry if we have said anything confusion on this front.
>>> So I guess the complete method of the frontend should just call the
>>> complete method of the engine/core?
>>
>> Yes. I agree. frontend.complete() calls engine/core.complete().
>
> Cool,
>
> Cheers,
>
> Brian
>
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>> Barry
>>>>
>>>> [1] Removing the Twisted dependence completely will require moving the
>>>> IEngine* interfaces to a separate module from the implementations. I
>>>> propose moving them to IPython.kernel.engineinterface.py.
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>
>


From ellisonbg.net at gmail.com  Thu Jun 26 23:31:19 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 26 Jun 2008 21:31:19 -0600
Subject: [IPython-dev] frontend plans
In-Reply-To: <cd7634ce0806262018g2deae150w9f39d7db82e55eb1@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
	<6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
	<cd7634ce0806262018g2deae150w9f39d7db82e55eb1@mail.gmail.com>
Message-ID: <6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com>

On Thu, Jun 26, 2008 at 9:18 PM, Barry Wark <barrywark at gmail.com> wrote:
> On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Barry,
>>
>>>> I think that we could have a single base class that implements the
>>>> actual frontend logic and then have multiple subclasses that handle
>>>> the calls to the various types of backends (kernel.core or
>>>> kernel.engineservice).  I need to look more at how the frontend is
>>>> implemented, but Barry, do you think this would work.
>>>
>>> Yes, I think this would work. I thought zope.interface was pure
>>> python. Since we can't require zope.interface in the stripped-down
>>> ipython, I now think option 1 is the best approach. I'll work on that.
>>
>> Great, I think that will be best, even though it has its own downsides.
>
> We're in agreement then. I'll try option 1 and see how that shakes out.
>
>>
>>>> Also, the Synchronous deferred does not present the exact same
>>>> interface as a true deferred or make the same promises about when
>>>> things will happen.
>>>
>>> What is your understanding of the differences?
>>
>> For Deferreds, I think the interface is not a complete specification
>> of the objects behavior.  For Deferreds, there are subtle cases that
>> arise when you chain them together.  The behavior exhibited in complex
>> Deferred chaining _can_ depend on whether or a given Deferred has
>> fired or not when the chaining is setup.  We have in various places
>> that handles these odd edge cases.  Also, we sometimes access the
>> semi-private attributes of Deferreds.  Another thing is that if you
>> have multiple unfired Deferreds, the order in which they will fire is
>> not deterministic.  For the synchronous deferreds, I think the
>> ordering has to be deterministic.  But in my mind, this constitues a
>> different behavior and thus "interface" in the board sense of the
>> word.
>>
>> We might be able to get the synchronous deferreds to work, but I am a
>> little hesitant to go down that route simply because all of these
>> things are _super_ subtle and nearly impossible to debug.
>
> I see the issues. Too bad; the Twisted universe seems to want to
> swallow its victims whole. I should have really seen this coming--I've
> worked on a Cocoa framework that uses OS X's NSOperationQueue to
> emulate the Twisted reactor/Deferred system. You're exactly right that
> the Deferred behavior is _very_ complicated when you dig into it. Oh,
> well. As long as we're willing to skip the engineservice layer for
> synchronous interface to core, it's not an issue and we can forget
> about Synchronous Deferreds.
>
>>
>>> Thus, I my mind, the new IEngineCore
>>>> implementation _couldn't_ possible really implement the interface.  In
>>>> fact, if I remember correctly, we have a test that can be run on any
>>>> IEngineCore implementer.  It actually calls all the methods of the
>>>> interface and checks:
>>>>
>>>> self.assert_(isinstance(return_value, t.i.Deferred)
>>>>
>>>> A fake deferred won't pass such tests.
>>>
>>> I don't think this is an appropriate test then. The interface should
>>> specify the behavior of the returned object, not its implementation.
>>> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred,
>>> then it should pass the test. The fact that it may not behave the same
>>> is a bigger issue.
>>
>> True, I could write a better test for this.  The current test is only
>> a super weak test behavior wise, but given the fact that there are no
>> other objects that truly act like a Deferred, the test suffices.
>>
>>>>
>>>> So, in summary, I think more discussion is needed before commiting to
>>>> #2.  I am crazy busy, but I will try to have a look at IFrontEnd
>>>> tonight.
>>>
>>>>
>>>>
>>>>> Since the IEngine* interface is much more stable than the IFrontEnd
>>>>> interface, I propose going with solution #2. Although it adds an
>>>>> additional python file as external dependency, it seems conceptually
>>>>> cleaner (all frontends go through the engine interface) and allows
>>>>> frontends to decide between synchronous and asynchronous behavior
>>>>> without any code changes.
>>>>
>>>> I think it is conceptually convoluted because the only significant way
>>>> that IEngireCore different from the underlying core is that its
>>>> methods return deferreds (and Failures).  Thus to use IEngineCore, but
>>>> then try to get rid of the (true) Deferreds by using fake ones seems
>>>> like double work (why not just call the class whose methods don't
>>>> return deferreds in the first place).
>>>
>>> It feels weird that there are two ways to interact with ipython?engine
>>> and core directly. It seemed that making a common interface was
>>> cleaner in that it allowed users of that interface to be able to use
>>> engine or core without modification of the frontend. Since that's not
>>> really an option anymore (because of zope.interface), I'm happy to
>>> give up that opinion and move on.
>>
>> I do sort of agree with this, but I think having two interfaces is
>> appropriate because they have vastly different behaviors (synchronous
>> vs asynchronous).
>
> Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core
> is still the 'real' IPython. I.kernel is just a Twised wrapper around
> that core. Naturally anything that doesn't want what Twisted has to
> offer should talk directly with I.kernel.core and the price they pay
> is that they loose all the goodies that come with the I.kernel layer.
> Now that I just wrote this out, it seems wrong that I.kernel.core is a
> subpackage of I.kernel. I know that it's there to isolate the ipython1
> stuff from ipython0 stuff, but before too many people start writing
> code using I.kernel.core, is it worth discussing if there's a better
> spot for it in the IPython tree?

Yes, probably.  I had originally thoughts about moving it to
IPython.core.  But the problem with that is I am afraid that it
suggests that it is a complete and working core.  My plan originally
was thus:

1.  Move the old core IPython.*.py -> IPython.core.*.py

2.  Refactor that stuff until it looks more like IPython.kernel.core

3.  At that point, get rid of IPython.kernel.core

But maybe the better approach is:

1.  Just move IPython.kernel.core -> IPython.core

2.  Also move IPython.*.py -< IPython.core

3.  Refactor/combine the two inplace

What do you think?  This probably needs more disucssion in a separate
thread on the list.

Cheers,

Brian

>>
>>>> Actually, I think we are in agreement that tab completion (the part
>>>> that actually looks up things in the users namespace) needs to be done
>>>> in the engine/core through its complete method.  There is just no way
>>>> it is reasonable to mirror the user_ns in the frontend for the reasons
>>>> you mention.  Sorry if we have said anything confusion on this front.
>>>> So I guess the complete method of the frontend should just call the
>>>> complete method of the engine/core?
>>>
>>> Yes. I agree. frontend.complete() calls engine/core.complete().
>>
>> Cool,
>>
>> Cheers,
>>
>> Brian
>>
>>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>>> Barry
>>>>>
>>>>> [1] Removing the Twisted dependence completely will require moving the
>>>>> IEngine* interfaces to a separate module from the implementations. I
>>>>> propose moving them to IPython.kernel.engineinterface.py.
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>>>
>>>>
>>>
>>
>


From barrywark at gmail.com  Thu Jun 26 23:38:25 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 26 Jun 2008 20:38:25 -0700
Subject: [IPython-dev] Moving IPython.kernel.core
Message-ID: <cd7634ce0806262038n22a07ab7u4f712e8a0ede2e34@mail.gmail.com>

Brian and I thought it would be good to bring this discussion to
everyone's attention, separate from the frontend plans. Below is the
entire thread, but I've copied the relevant bits just here:

>> It seems wrong that I.kernel.core is a
>> subpackage of I.kernel. I know that it's there to isolate the ipython1
>> stuff from ipython0 stuff, but before too many people start writing
>> code using I.kernel.core, is it worth discussing if there's a better
>> spot for it in the IPython tree?
>
> Yes, probably.  I had originally thoughts about moving it to
> IPython.core.  But the problem with that is I am afraid that it
> suggests that it is a complete and working core.  My plan originally
> was thus:
>
> 1.  Move the old core IPython.*.py -> IPython.core.*.py
>
> 2.  Refactor that stuff until it looks more like IPython.kernel.core
>
> 3.  At that point, get rid of IPython.kernel.core
>
> But maybe the better approach is:
>
> 1.  Just move IPython.kernel.core -> IPython.core
>
> 2.  Also move IPython.*.py -< IPython.core
>
> 3.  Refactor/combine the two inplace
>
> What do you think?  This probably needs more disucssion in a separate
> thread on the list.

Since I don't have any significant code that depends on ipython0, I'd vote for
1. Move IPython.kernel.core -> IPython.core
2. Move IPython.*.py -> IPython.old_core
3. Deprecate IPython.old_core as soon as IPython.core is capable of
replacing ipython0

I'm sure others who have legacy code that depends on ipython0 will
have an opinion...

Barry

On Thu, Jun 26, 2008 at 8:31 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> On Thu, Jun 26, 2008 at 9:18 PM, Barry Wark <barrywark at gmail.com> wrote:
>> On Thu, Jun 26, 2008 at 4:03 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>>> Barry,
>>>
>>>>> I think that we could have a single base class that implements the
>>>>> actual frontend logic and then have multiple subclasses that handle
>>>>> the calls to the various types of backends (kernel.core or
>>>>> kernel.engineservice).  I need to look more at how the frontend is
>>>>> implemented, but Barry, do you think this would work.
>>>>
>>>> Yes, I think this would work. I thought zope.interface was pure
>>>> python. Since we can't require zope.interface in the stripped-down
>>>> ipython, I now think option 1 is the best approach. I'll work on that.
>>>
>>> Great, I think that will be best, even though it has its own downsides.
>>
>> We're in agreement then. I'll try option 1 and see how that shakes out.
>>
>>>
>>>>> Also, the Synchronous deferred does not present the exact same
>>>>> interface as a true deferred or make the same promises about when
>>>>> things will happen.
>>>>
>>>> What is your understanding of the differences?
>>>
>>> For Deferreds, I think the interface is not a complete specification
>>> of the objects behavior.  For Deferreds, there are subtle cases that
>>> arise when you chain them together.  The behavior exhibited in complex
>>> Deferred chaining _can_ depend on whether or a given Deferred has
>>> fired or not when the chaining is setup.  We have in various places
>>> that handles these odd edge cases.  Also, we sometimes access the
>>> semi-private attributes of Deferreds.  Another thing is that if you
>>> have multiple unfired Deferreds, the order in which they will fire is
>>> not deterministic.  For the synchronous deferreds, I think the
>>> ordering has to be deterministic.  But in my mind, this constitues a
>>> different behavior and thus "interface" in the board sense of the
>>> word.
>>>
>>> We might be able to get the synchronous deferreds to work, but I am a
>>> little hesitant to go down that route simply because all of these
>>> things are _super_ subtle and nearly impossible to debug.
>>
>> I see the issues. Too bad; the Twisted universe seems to want to
>> swallow its victims whole. I should have really seen this coming--I've
>> worked on a Cocoa framework that uses OS X's NSOperationQueue to
>> emulate the Twisted reactor/Deferred system. You're exactly right that
>> the Deferred behavior is _very_ complicated when you dig into it. Oh,
>> well. As long as we're willing to skip the engineservice layer for
>> synchronous interface to core, it's not an issue and we can forget
>> about Synchronous Deferreds.
>>
>>>
>>>> Thus, I my mind, the new IEngineCore
>>>>> implementation _couldn't_ possible really implement the interface.  In
>>>>> fact, if I remember correctly, we have a test that can be run on any
>>>>> IEngineCore implementer.  It actually calls all the methods of the
>>>>> interface and checks:
>>>>>
>>>>> self.assert_(isinstance(return_value, t.i.Deferred)
>>>>>
>>>>> A fake deferred won't pass such tests.
>>>>
>>>> I don't think this is an appropriate test then. The interface should
>>>> specify the behavior of the returned object, not its implementation.
>>>> If the Synchronous Deferred behaves the same as a t.i.defer.Deferred,
>>>> then it should pass the test. The fact that it may not behave the same
>>>> is a bigger issue.
>>>
>>> True, I could write a better test for this.  The current test is only
>>> a super weak test behavior wise, but given the fact that there are no
>>> other objects that truly act like a Deferred, the test suffices.
>>>
>>>>>
>>>>> So, in summary, I think more discussion is needed before commiting to
>>>>> #2.  I am crazy busy, but I will try to have a look at IFrontEnd
>>>>> tonight.
>>>>
>>>>>
>>>>>
>>>>>> Since the IEngine* interface is much more stable than the IFrontEnd
>>>>>> interface, I propose going with solution #2. Although it adds an
>>>>>> additional python file as external dependency, it seems conceptually
>>>>>> cleaner (all frontends go through the engine interface) and allows
>>>>>> frontends to decide between synchronous and asynchronous behavior
>>>>>> without any code changes.
>>>>>
>>>>> I think it is conceptually convoluted because the only significant way
>>>>> that IEngireCore different from the underlying core is that its
>>>>> methods return deferreds (and Failures).  Thus to use IEngineCore, but
>>>>> then try to get rid of the (true) Deferreds by using fake ones seems
>>>>> like double work (why not just call the class whose methods don't
>>>>> return deferreds in the first place).
>>>>
>>>> It feels weird that there are two ways to interact with ipython?engine
>>>> and core directly. It seemed that making a common interface was
>>>> cleaner in that it allowed users of that interface to be able to use
>>>> engine or core without modification of the frontend. Since that's not
>>>> really an option anymore (because of zope.interface), I'm happy to
>>>> give up that opinion and move on.
>>>
>>> I do sort of agree with this, but I think having two interfaces is
>>> appropriate because they have vastly different behaviors (synchronous
>>> vs asynchronous).
>>
>> Fair enough. I'm convinced. I had it wrong in my head-- I.kernel.core
>> is still the 'real' IPython. I.kernel is just a Twised wrapper around
>> that core. Naturally anything that doesn't want what Twisted has to
>> offer should talk directly with I.kernel.core and the price they pay
>> is that they loose all the goodies that come with the I.kernel layer.
>> Now that I just wrote this out, it seems wrong that I.kernel.core is a
>> subpackage of I.kernel. I know that it's there to isolate the ipython1
>> stuff from ipython0 stuff, but before too many people start writing
>> code using I.kernel.core, is it worth discussing if there's a better
>> spot for it in the IPython tree?
>
> Yes, probably.  I had originally thoughts about moving it to
> IPython.core.  But the problem with that is I am afraid that it
> suggests that it is a complete and working core.  My plan originally
> was thus:
>
> 1.  Move the old core IPython.*.py -> IPython.core.*.py
>
> 2.  Refactor that stuff until it looks more like IPython.kernel.core
>
> 3.  At that point, get rid of IPython.kernel.core
>
> But maybe the better approach is:
>
> 1.  Just move IPython.kernel.core -> IPython.core
>
> 2.  Also move IPython.*.py -< IPython.core
>
> 3.  Refactor/combine the two inplace
>
> What do you think?  This probably needs more disucssion in a separate
> thread on the list.
>
> Cheers,
>
> Brian
>
>>>
>>>>> Actually, I think we are in agreement that tab completion (the part
>>>>> that actually looks up things in the users namespace) needs to be done
>>>>> in the engine/core through its complete method.  There is just no way
>>>>> it is reasonable to mirror the user_ns in the frontend for the reasons
>>>>> you mention.  Sorry if we have said anything confusion on this front.
>>>>> So I guess the complete method of the frontend should just call the
>>>>> complete method of the engine/core?
>>>>
>>>> Yes. I agree. frontend.complete() calls engine/core.complete().
>>>
>>> Cool,
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>>> Barry
>>>>>>
>>>>>> [1] Removing the Twisted dependence completely will require moving the
>>>>>> IEngine* interfaces to a separate module from the implementations. I
>>>>>> propose moving them to IPython.kernel.engineinterface.py.
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>>
>>>>
>>>
>>
>


From gael.varoquaux at normalesup.org  Fri Jun 27 01:18:47 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 27 Jun 2008 07:18:47 +0200
Subject: [IPython-dev] Student sponsorship for the SciPy08 conference
Message-ID: <20080627051847.GM11323@phare.normalesup.org>

We are delighted to announce that the Python Software Foundation has
answered our call and is providing sponsoring to the SciPy08 conference.

We will use this money to sponsor the registration fees and travel for up
to 10 college or graduate students to attend the conference. The PSF did
not provide all the founds required for all 10 students and once again
Enthought Inc. (http://www.enthought.com) is stepping up to fill in.

To apply, please send a short description of what you are studying and
why you?d like to attend to info at enthought.com. Please include telephone
contact information.

Thanks a lot to Travis Vaught from Enthought for bringing this project to
a success.

Please don't hesitate to forward this announcement to anybody who might
be interested.

Ga?l, on behalf of the Scipy08 organisation committee

SciPy coneference site:   http://conference.scipy.org


From cohen at slac.stanford.edu  Fri Jun 27 05:00:26 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Fri, 27 Jun 2008 02:00:26 -0700
Subject: [IPython-dev] Reposting : an issue in replaying logs with profile
Message-ID: <4864AC2A.3030004@slac.stanford.edu>

hello,
my problem below did not get addressed. Can someone help me understand 
what I am doing wrong?
thanks in advance,
Johann

-------------------
hi there,
I am using a very recent bazaar build of ipython and python 2.5. I have 
the following profile in my IPYTHONDIR:

[cohen at jarrett ~]$ more .ipython/ipy_profile_test.py
import IPython.ipapi
ip = IPython.ipapi.get()

ip.ex("print '*****************************************************'")
ip.ex("print '* TEST *'")
ip.ex("print '*****************************************************'")

ip.ex("import os")


I then run the following :
[cohen at jarrett ~]$ ipython -profile test -log
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : rotate
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: n=5.2

In [2]: os
Out[2]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

after exiting the session, the log looks like :
[cohen at jarrett ~]$ more ipython_log.py
#log# Automatic Logger file. *** THIS MUST BE THE FIRST LINE ***
#log# DO NOT CHANGE THIS LINE OR THE TWO BELOW
#log# opts = Struct({'__allownew': True, 'log': 1, 'logfile': 
'ipython_log.py', 'profile': ''})
#log# args = []
#log# It is safe to make manual edits below here.
#log#----------------------------------------------------------------------- 

n=5.2
os

That does *not* look good because the 'profile' value is blank, and 
indeed :
[cohen at jarrett ~]$ ipython -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>

The following lines/blocks in file <ipython_log.py> reported errors:
os
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: os
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/cohen/<ipython console> in <module>()

NameError: name 'os' is not defined

There was no 'TEST' banner and no importing of os, as anticipated as the 
profile is not filled in the log.
Even more problematic :
[cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>

The following lines/blocks in file <ipython_log.py> reported errors:
os
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

Here the -profile argument request is not even honored....
If I add test as the profile in the log file, then I get
the correct behavior in both cases :
[cohen at jarrett ~]$ ipython -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: os
Out[1]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

In [2]: n
Out[2]: 5.2000000000000002

In [3]:
Do you really want to exit ([y]/n)?
[cohen at jarrett ~]$ ipython -profile test -logplay ipython_log.py
Activating auto-logging. Current session state plus future input saved.
Filename       : ipython_log.py
Mode           : append
Output logging : False
Raw input log  : False
Timestamping   : False
State          : active
*****************************************************
* TEST *
*****************************************************
Replaying log...
Loading log file <ipython_log.py> one line at a time...
Finished replaying log file <ipython_log.py>
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: test

In [1]: os
Out[1]: <module 'os' from '/usr/lib/python2.5/os.pyc'>

In [2]: n
Out[2]: 5.2000000000000002


So to make a long story short : there is a faulty behavior of the logger 
that does not correctly save the profile used. I am trying to read the 
code (Logger.py and ipilib.py seem to be the natural candidates) but if 
someone finds the correct patch more quickly, I will be happy too :) .
cheers,
Johann


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



From gael.varoquaux at normalesup.org  Fri Jun 27 14:24:29 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 27 Jun 2008 20:24:29 +0200
Subject: [IPython-dev] Scipy08 Paper submission deadline extention to Monday
	30th
Message-ID: <20080627182429.GH5103@phare.normalesup.org>

The deadline for submitting abstracts to the Scipy conference was tonight.
In order to give you more time to submit excellent abstracts, the review
committee is extending the deadline to Monday (June 30th), and will work
hastily to get all of them reviewed in time for the program announcement,
on Thursday July 3rd.

----

The SciPy 2008 Conference will be held 21-22 August 2008 at the
California Institute of Technology, Pasadena, California. SciPy is a
scientific computing package, written in the Python language. It is
widely used in research, the industry and academia.

The program features tutorials, contributed papers, lightning talks, and
bird-of-a-feather sessions. We are soliciting talks and accompanying
papers (either formal academic or magazine-style articles) that discuss
topics which center around scientific computing using Python. These
include applications, teaching, future development directions and
research. A collection of peer-reviewed articles will be published as
part of the proceedings.

Proposals for talks are submitted as extended abstracts. There are two
categories of talks:
Lightning talks

These talks are 10 minutes in duration. An abstract of between 300 and
700 words should describe the topic and motivate its relevance to
scientific computing. Lightning talks do not require an accompanying
article (although, if submitted, these will still be published).
Paper presentations

These talks are 35 minutes in duration (including questions). A one page
abstract of no less than 500 words (excluding figures and references)
should give an outline of the final paper. Papers are due two weeks
before the conference, and may be in a formal academic style, or in a
more relaxed magazine-style format.

If you wish to present a talk at the conference, please create an account
on the website http://conference.scipy.org. You may then submit an
abstract by logging in, clicking on your profile and following the "
Submit an abstract " link.

Ga?l, on behalf on the SciPy08 organizing committee.


From robert.kern at gmail.com  Fri Jun 27 17:04:29 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 27 Jun 2008 16:04:29 -0500
Subject: [IPython-dev] Moving IPython.kernel.core
In-Reply-To: <cd7634ce0806262038n22a07ab7u4f712e8a0ede2e34@mail.gmail.com>
References: <cd7634ce0806262038n22a07ab7u4f712e8a0ede2e34@mail.gmail.com>
Message-ID: <g43kku$a1u$1@ger.gmane.org>

Barry Wark wrote:
> Brian and I thought it would be good to bring this discussion to
> everyone's attention, separate from the frontend plans. Below is the
> entire thread, but I've copied the relevant bits just here:
> 
>>> It seems wrong that I.kernel.core is a
>>> subpackage of I.kernel. I know that it's there to isolate the ipython1
>>> stuff from ipython0 stuff, but before too many people start writing
>>> code using I.kernel.core, is it worth discussing if there's a better
>>> spot for it in the IPython tree?
>> Yes, probably.  I had originally thoughts about moving it to
>> IPython.core.  But the problem with that is I am afraid that it
>> suggests that it is a complete and working core.  My plan originally
>> was thus:
>>
>> 1.  Move the old core IPython.*.py -> IPython.core.*.py
>>
>> 2.  Refactor that stuff until it looks more like IPython.kernel.core
>>
>> 3.  At that point, get rid of IPython.kernel.core
>>
>> But maybe the better approach is:
>>
>> 1.  Just move IPython.kernel.core -> IPython.core
>>
>> 2.  Also move IPython.*.py -< IPython.core
>>
>> 3.  Refactor/combine the two inplace
>>
>> What do you think?  This probably needs more disucssion in a separate
>> thread on the list.
> 
> Since I don't have any significant code that depends on ipython0, I'd vote for
> 1. Move IPython.kernel.core -> IPython.core
> 2. Move IPython.*.py -> IPython.old_core
> 3. Deprecate IPython.old_core as soon as IPython.core is capable of
> replacing ipython0

When I started working on IPython.kernel.core, I copied over a bunch of the 
utilities like InputList. Do we want to change all of the 
IPython[.old_core].utils to import the duplicated functions from there so we 
have one copy to modify (and test!)? I ask because I would like to add a feature 
to InputList.

For the curious, I would like to make InputList allow this behavior:

   In[2:4,6,8] == In[2:4] + In[6] + In[8]

-- 
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 robert.kern at gmail.com  Fri Jun 27 19:59:38 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 27 Jun 2008 18:59:38 -0500
Subject: [IPython-dev] Replacing the user context with a non-dict
Message-ID: <g43utb$7q7$1@ger.gmane.org>

In iplib.py, we have this piece of code

                 # Embedded instances require separate global/local namespaces
                 # so they can see both the surrounding (local) namespace and
                 # the module-level globals when called inside another function.
                 if self.embedded:
                     exec code_obj in self.user_global_ns, self.user_ns
                 # Normal (non-embedded) instances should only have a single
                 # namespace for user code execution, otherwise functions won't
                 # see interactive top-level globals.
                 else:
                     exec code_obj in self.user_ns

Can we add a hook in here to allow the namespace to be more flexible? For some 
background: Python 2.4 allows one to use a non-dict mapping for the locals 
namespace in an exec statement, but a real dict is necessary for the globals. If 
there is only one namespace, it is considered a globals dict.

I would like to replace the namespace with a non-dict mapping to issue 
notifications when the namespace is changed. If the latter exec statement were 
changed to always execute in both namespaces (if the shell is not embedded, by 
default both user_global_ns and user_ns would point to the same dictionary), 
then I think I could replace user_ns with my non-dict and user_globals_ns with 
the real dict that underlies my non-dict. This would give me my feature while 
still avoiding the problem noted in the comment. I've tested this locally.

-- 
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 fperez.net at gmail.com  Fri Jun 27 21:04:33 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 27 Jun 2008 18:04:33 -0700
Subject: [IPython-dev] Replacing the user context with a non-dict
In-Reply-To: <g43utb$7q7$1@ger.gmane.org>
References: <g43utb$7q7$1@ger.gmane.org>
Message-ID: <db6b5ecc0806271804u7b30e4a4xc72a0c39dd05d6de@mail.gmail.com>

On Fri, Jun 27, 2008 at 4:59 PM, Robert Kern <robert.kern at gmail.com> wrote:

> Can we add a hook in here to allow the namespace to be more flexible? For some
> background: Python 2.4 allows one to use a non-dict mapping for the locals
> namespace in an exec statement, but a real dict is necessary for the globals. If
> there is only one namespace, it is considered a globals dict.

Sorry I haven't been more responsive, I'm at a conference and the
talks have actually been very good :)  But the answer is absolutely
yes to your request, after the whole context/with discusson with Eric,
it became clear that this is something we should support, it just
hadn't been done yet.

Please just make the lp ipython team membership request so we can add
you right away.

Cheers,

f


From fperez.net at gmail.com  Sat Jun 28 14:38:02 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 28 Jun 2008 11:38:02 -0700
Subject: [IPython-dev] Win32 IPython1?
In-Reply-To: <4865AB18.4040000@uml.edu>
References: <48457029.8020401@uml.edu>
	<db6b5ecc0806031222x672c6524m64043723da45afa5@mail.gmail.com>
	<48459D9F.9020900@uml.edu>
	<db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>
	<4864549D.2010407@uml.edu>
	<db6b5ecc0806262219w424ae80eh39c54321c789a91c@mail.gmail.com>
	<48659443.4050109@uml.edu>
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>
	<4865AB18.4040000@uml.edu>
Message-ID: <db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>

Hi Alex,

again, please send these messages on-list, so they get properly
archived and others may also help you if I'm not available (I'm at a
conference right now).

On Fri, Jun 27, 2008 at 8:08 PM, Alex Brown <Alexander_Brown at uml.edu> wrote:

> I could not find a way to uninstall a module either with setup.py or
> easy_install
> (http://mail.python.org/pipermail/python-list/2004-December/294789.html) -

easy_install and distutils have no automated uninstallation, unfortunately.

> I've simply moved ipython1* out of the tree, OK?   I can't find anything
> other than comment and docstring references to ipython1 after removal.

That is OK.

Cheers,

f


From barrywark at gmail.com  Sat Jun 28 14:53:59 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sat, 28 Jun 2008 11:53:59 -0700
Subject: [IPython-dev] Win32 IPython1?
In-Reply-To: <db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>
References: <48457029.8020401@uml.edu>
	<db6b5ecc0806031222x672c6524m64043723da45afa5@mail.gmail.com>
	<48459D9F.9020900@uml.edu>
	<db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>
	<4864549D.2010407@uml.edu>
	<db6b5ecc0806262219w424ae80eh39c54321c789a91c@mail.gmail.com>
	<48659443.4050109@uml.edu>
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>
	<4865AB18.4040000@uml.edu>
	<db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>
Message-ID: <cd7634ce0806281153h5ac76143ie825a0bfa2a41eca@mail.gmail.com>

On Sat, Jun 28, 2008 at 11:38 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi Alex,
>
> again, please send these messages on-list, so they get properly
> archived and others may also help you if I'm not available (I'm at a
> conference right now).
>
> On Fri, Jun 27, 2008 at 8:08 PM, Alex Brown <Alexander_Brown at uml.edu> wrote:
>
>> I could not find a way to uninstall a module either with setup.py or
>> easy_install
>> (http://mail.python.org/pipermail/python-list/2004-December/294789.html) -
>
> easy_install and distutils have no automated uninstallation, unfortunately.

I believe you can do easy_install -m to effectively uninstall an app
that was installed using setuptools (not one that was installed via
distutils). The -m (or --multi-version) flag removes the package from
the setuptools .pth file, but doesn't remove it from the
site-directory. This way, anyone that wants to use it has to
explicitly require it from setuptools but everything else will not
know it's there. This is one way to have multiple versions of
setuptools-installed packages available or to "uninstall" a package
without breaking any other packages that depend on that package.


>
>> I've simply moved ipython1* out of the tree, OK?   I can't find anything
>> other than comment and docstring references to ipython1 after removal.
>
> That is OK.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From stefan at sun.ac.za  Sat Jun 28 18:43:52 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 29 Jun 2008 00:43:52 +0200
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
Message-ID: <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>

2008/6/26 Fernando Perez <fperez.net at gmail.com>:
> I think that we only have a small issue, and it's one I'm willing to
> ignore from now on: Launchpad (*not* bzr, since bzr viz/log is
> faithful to the full history) ignores all but one branch when showing
> history, and what it actually shows can change with each commit.  When
> they improve their display, great, but until then let's just ignore
> that point (we're all too busy here to spend time fixing lp).
>
> But the fact that sometimes one *must* merge is unavoidable with
> distributed development: even using a special branch for communicating
> with upstream, merges sometimes are unavoidable.  Else I'm really
> missing something here.

The above two paragraphs give a good summary of the "problem" and the
solution, which corresponds with my understanding of the situation.

Cheers
St?fan


From vivainio at gmail.com  Sun Jun 29 06:02:40 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 29 Jun 2008 13:02:40 +0300
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
Message-ID: <46cb515a0806290302k528a7928nd8a09fcad3ec67b0@mail.gmail.com>

On Fri, Jun 27, 2008 at 12:32 AM, Fernando Perez <fperez.net at gmail.com> wrote:


> Mmh, then there's something I've missed.  Because even though I'm
> using the two-branch model, one to keep pulling/pushing upstream and
> one for local development, I'm *still* getting the same folding issue
> when true merging is required.  Basically if there's the need for a

There is only a short time window when this can happen - between "bzr
pull" and "bzr push". Between those operations, you should only do ONE
merge operation (from your work branch to the trunk branch). If you
get diverged branches error when trying to push, just uncommit until
you can pull again (i.e. your local trunk is exact copy of server
trunk), then merge from your work branch, commit and push.

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


From cournapeau at cslab.kecl.ntt.co.jp  Sun Jun 29 22:12:23 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Mon, 30 Jun 2008 11:12:23 +0900
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
	<9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>
Message-ID: <1214791943.7956.33.camel@bbc8>

On Sun, 2008-06-29 at 00:43 +0200, St?fan van der Walt wrote:
> 2008/6/26 Fernando Perez <fperez.net at gmail.com>:
> > I think that we only have a small issue, and it's one I'm willing to
> > ignore from now on: Launchpad (*not* bzr, since bzr viz/log is
> > faithful to the full history) ignores all but one branch when showing
> > history, and what it actually shows can change with each commit.  When
> > they improve their display, great, but until then let's just ignore
> > that point (we're all too busy here to spend time fixing lp).
> >
> > But the fact that sometimes one *must* merge is unavoidable with
> > distributed development: even using a special branch for communicating
> > with upstream, merges sometimes are unavoidable.  Else I'm really
> > missing something here.
> 
> The above two paragraphs give a good summary of the "problem" and the
> solution, which corresponds with my understanding of the situation.

I think the problem is kind of different, actually. At first, I got the
same understanding of the issue as you, but I realized later that that's
not the problem at all. The 'ugly' history is inherent to bzr way of
doing things; as Villo noted, it more a trade off than a weakness of
bzr.

bzr emphasizes the current branch (mainline) as special. That's the
fundamental difference between bzr and hg/git here. In git and hg, what
happens when you merge a branch is that you 'append' the new revisions
to the DAG. It means you have a flat log, and you can see every commit
at the same level:

   /------B ----- C ------\
A -                        -----> merge -> F
   \------D ------ E -----/

Here is what you get with git (and hg, too, I think; I am more into git
ATM, for an alternative to hg):

commit a1effecf343bb69e931670eedf3e68c1b6e135b6
Merge: be91f09... 0745401...
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:27 2008 +0900

    Merge branch 'b1' into b2

commit be91f099bb570f381bb79d6091f7453cac05c857
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:13 2008 +0900

    Commit E.

commit 0745401f2601c0595e294f3cb29f58c94b57292f
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:35:00 2008 +0900

    Commit C.

commit da6b022593196cf15b9491b23efad3003f6a60fe
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:34:36 2008 +0900

    commit D

commit 1a1b17e4b48861b3d29b184d9ea65736a8a4ed30
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:33:44 2008 +0900

    Commit B

commit 66bfd488a0848e10e677eba2c26a56e02413b686
Author: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
Date:   Mon Jun 30 10:32:47 2008 +0900

    Commit A

With bzr, you have something quite different:

------------------------------------------------------------
revno: 4
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:39:49 +0900
message:
  Merge b2.
    ------------------------------------------------------------
    revno: 1.1.2
    committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
    branch nick: b2
    timestamp: Mon 2008-06-30 10:39:27 +0900
    message:
      Commit E.
    ------------------------------------------------------------
    revno: 1.1.1
    committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
    branch nick: b2
    timestamp: Mon 2008-06-30 10:38:57 +0900
    message:
      Commit D.
------------------------------------------------------------
revno: 3
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:39:13 +0900
message:
  Commit C.
------------------------------------------------------------
revno: 2
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: b1
timestamp: Mon 2008-06-30 10:38:30 +0900
message:
  Commit B.
------------------------------------------------------------
revno: 1
committer: David Cournapeau <cournapeau at bbc8.cslab.kecl.ntt.co.jp>
branch nick: trunk
timestamp: Mon 2008-06-30 10:37:56 +0900
message:
  Commit A.

The 'ugly' history, to use Fernando's words. The difference:
	- the log does look confusing if you are used to git/hg
	- you can *not* have a flat log ala git/hg, contrary to what I thought
previously. I was confused by the description of some bzr developers,
when they mentioned merge --pull. It is actually not really useful, and
does not do what git/hg do at all when you merge. Better forget it, I
think.
	- but this has a nice property: at any revision of the mainline, the
tree is in a workable state. In bzr development itself, the merge to the
mainline are not done manually, but through a gatekeeper: in particular,
the merge will be refused if it does not pass the test suite. You cannot
do that with git/hg I think (at least not as naturally). bzr developers
call this the merge-review-commit workflow.

Honestly, I don't really see the problem with the code browsing on
launchpad: I just never use it and don't see a big use for it. Since now
you have the whole history, what's the point (as a regular developer, at
least, that is if you have the branch on your computer) ? Having the DAG
displayed would be much better, yes. But since again, you can do it
locally (bzr visualize)... The problem is more the availability of those
tools on non free OS (windows and mac os X).

Concerning history folding, it can become really ugly when you work on
several branches at the same time and need to merge one from the other
(typically, I encountered this in the following quite usual scenario:
start a feature branch, then see a bug in this branch, fix the bug in
another branch, and then merge the fix into mainline and merge mainline
into feature branch). You can do with rebase, but it does not work that
well with bzr (I think this is because contrary to git, which
essentially guesses everything, bzr uses a lot of meta-data; again, this
has advantages and disadvantages); and rebase has its own problem, too.
There is no win-win scenario that I am aware of.

I think what Brian said is really important (you never the nice things
of the tools you are using, you never see the bad things of the tools
you are not using). The only way is to use the tools on a daily basis.

cheers,

David





From stefan at sun.ac.za  Mon Jun 30 02:06:34 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 30 Jun 2008 08:06:34 +0200
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <1214791943.7956.33.camel@bbc8>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
	<9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>
	<1214791943.7956.33.camel@bbc8>
Message-ID: <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com>

2008/6/30 David Cournapeau <cournapeau at cslab.kecl.ntt.co.jp>:
> bzr emphasizes the current branch (mainline) as special. That's the
> fundamental difference between bzr and hg/git here. In git and hg, what
> happens when you merge a branch is that you 'append' the new revisions
> to the DAG. It means you have a flat log, and you can see every commit
> at the same level:
>
>   /------B ----- C ------\
> A -                        -----> merge -> F
>   \------D ------ E -----/

Knowing that bzr preserves the mainline, looks like you did:

 /------B ----- C -------.------> merge -> F
A -                       /
 \------D ------ E ------/

Otherwise you get something like:

------------------------------------------------------------
revno: 2
committer: Stefan van der Walt <bzr at mentat.za.net>
branch nick: bzrtest
timestamp: Mon 2008-06-30 07:25:43 +0200
message:
  Merge dev branches.
    ------------------------------------------------------------
    revno: 1.2.2
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest1
    timestamp: Mon 2008-06-30 07:24:39 +0200
    message:
      C
    ------------------------------------------------------------
    revno: 1.2.1
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest1
    timestamp: Mon 2008-06-30 07:24:31 +0200
    message:
      B
    ------------------------------------------------------------
    revno: 1.1.2
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest2
    timestamp: Mon 2008-06-30 07:24:57 +0200
    message:
      E
    ------------------------------------------------------------
    revno: 1.1.1
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest2
    timestamp: Mon 2008-06-30 07:24:50 +0200
    message:
      D
------------------------------------------------------------
revno: 1
committer: Stefan van der Walt <bzr at mentat.za.net>
branch nick: bzrtest
timestamp: Mon 2008-06-30 07:22:17 +0200
message:
  A

(I just merged both branches at the same time)

`pull` and `push` should only be used when you want to create an exact
copy of another branch.  It has the effect of flattening out the log,
so I'd imagine it is a bad idea to "force" through merges that way.

> Concerning history folding, it can become really ugly when you work on
> several branches at the same time and need to merge one from the other
> (typically, I encountered this in the following quite usual scenario:
> start a feature branch, then see a bug in this branch, fix the bug in
> another branch, and then merge the fix into mainline and merge mainline
> into feature branch). You can do with rebase, but it does not work that
> well with bzr (I think this is because contrary to git, which
> essentially guesses everything, bzr uses a lot of meta-data; again, this
> has advantages and disadvantages); and rebase has its own problem, too.
> There is no win-win scenario that I am aware of.

Do you know whether other systems try to work around this, and how they do it?

Here is what I see under bzr:

$ bzr log
------------------------------------------------------------
revno: 3
committer: Stefan van der Walt <bzr at mentat.za.net>
branch nick: bzrtest
timestamp: Mon 2008-06-30 07:55:32 +0200
message:
  Merge changes from interface branch into mainline.
    ------------------------------------------------------------
    revno: 1.2.3
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest_interface
    timestamp: Mon 2008-06-30 07:55:14 +0200
    message:
      Make some more changes to the interface branch.
    ------------------------------------------------------------
    revno: 1.2.2
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest_interface
    timestamp: Mon 2008-06-30 07:54:33 +0200
    message:
      Merge changes from mainline with the interface branch.
    ------------------------------------------------------------
    revno: 1.2.1
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest_interface
    timestamp: Mon 2008-06-30 07:54:06 +0200
    message:
      Checkin to improve the calculator interface. Branch: interface.
------------------------------------------------------------
revno: 2
committer: Stefan van der Walt <bzr at mentat.za.net>
branch nick: bzrtest
timestamp: Mon 2008-06-30 07:53:24 +0200
message:
  Merge in calculator engine fixes into "mainline".
    ------------------------------------------------------------
    revno: 1.1.1
    committer: Stefan van der Walt <bzr at mentat.za.net>
    branch nick: bzrtest_addition
    timestamp: Mon 2008-06-30 07:53:10 +0200
    message:
      Fix addition in calculator.  Branch: addition.
------------------------------------------------------------
revno: 1
committer: Stefan van der Walt <bzr at mentat.za.net>
branch nick: bzrtest
timestamp: Mon 2008-06-30 07:52:31 +0200
message:
  Project root is here. It is a fake pocket calculator.

I don't see any history folding as such; I *do* see a log message
saying that I committed changes from the main branch into the addition
branch, but those changes *themselves* were not re-merged with
mainline.

> I think what Brian said is really important (you never the nice things
> of the tools you are using, you never see the bad things of the tools
> you are not using). The only way is to use the tools on a daily basis.

That's true.  I am trying to understand these issues, so that I can
tell whether the "bad things" I see are due to the tool or my abuse of
it.

Cheers
St?fan


From cournapeau at cslab.kecl.ntt.co.jp  Mon Jun 30 02:55:03 2008
From: cournapeau at cslab.kecl.ntt.co.jp (David Cournapeau)
Date: Mon, 30 Jun 2008 15:55:03 +0900
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
	<9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>
	<1214791943.7956.33.camel@bbc8>
	<9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com>
Message-ID: <1214808903.7956.54.camel@bbc8>

On Mon, 2008-06-30 at 08:06 +0200, St?fan van der Walt wrote:
> 
> Knowing that bzr preserves the mainline, looks like you did:
> 
>  /------B ----- C -------.------> merge -> F
> A -                       /
>  \------D ------ E ------/
> 

Yes, I merged D/E into the top branch in both git and bzr cases, I
should have been clearer here.

> 
> `pull` and `push` should only be used when you want to create an exact
> copy of another branch.  It has the effect of flattening out the log,
> so I'd imagine it is a bad idea to "force" through merges that way.

I don't think it is right to see pull as "flattening" the log. That's
what I thought first too, but it is wrong. In particular, in the case
above, it is not possible to get a flat log in bzr (wo using rebase,
that is).

> 
> Do you know whether other systems try to work around this, and how they do it?

git does not have a mainline concept at all. It is just a DAG at both
implementation and UI levels, and the log is just time-sorted as far as
I understand (contrary to bzr where the log is topologically sorted,
which is one of the reason why it is much slower, BTW).

If you look at git output, there is only one indentation, whatever the
branch a commit is coming from. Git does not work around this, because
they don't need to: there is not version in git, just the sha-1 of each
commit. Contrary to version, sha-1 does not have any order concept.

What happens a lot in git is the use of rebase, that is changing the
order of the commits of a branch, to make the history 'nicer'. But you
have to be careful when using rebase because obviously, since you
cut/paste in the DAG, once the branch is published, other people cannot
depend on your branch if you rebase. See for example:

http://kerneltrap.org/Linux/Git_Management

Another solution, albeit with a different purpose, is the patchqueue
concept (loom in bzr, mercurial queues in hg, I don't know in git), but
I still haven't got my head around this one properly to really talk
about it.

> I don't see any history folding as such; I *do* see a log message
> saying that I committed changes from the main branch into the addition
> branch, but those changes *themselves* were not re-merged with
> mainline.

Maybe I don't understand exactly what Fernando meant by history folding,
then. For me, the above log is a typical example of history folding,
because you have two levels of log (one for the mainline, one for the
merged branch).

cheers,

David



From fperez.net at gmail.com  Mon Jun 30 18:12:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 30 Jun 2008 15:12:40 -0700
Subject: [IPython-dev] Python/Sage minisymposium at SIAM Annual meeting July
	9/10 2008
Message-ID: <db6b5ecc0806301512j4fff0558u45f635fc7ed524e2@mail.gmail.com>

Hi all,

this is just a reminder, in case you'll be attending the SIAM 2008
annual meeting next week in San Diego, that there will be a 3-part
minisymposium focusing on the uses of Python and Sage in scientific
computing:

http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447

We hope to see many of you there!

Regards,

Fernando and Randy


From fperez.net at gmail.com  Mon Jun 30 19:00:16 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 30 Jun 2008 16:00:16 -0700
Subject: [IPython-dev] Bazaar on OS X
In-Reply-To: <1214808903.7956.54.camel@bbc8>
References: <cd7634ce0806241458y5206c2a5q7c75b56088b66ee2@mail.gmail.com>
	<200806251414.26194.hans_meine@gmx.net>
	<46cb515a0806251022y21c3cf26s52ca4f9f39c293e@mail.gmail.com>
	<200806261341.14255.hans_meine@gmx.net>
	<46cb515a0806260956v409a8ec3r6bd465d9c766fb6b@mail.gmail.com>
	<db6b5ecc0806261432t2e9df50fw1bd7d4e348da11d0@mail.gmail.com>
	<9457e7c80806281543r7277f42fm7d2b97c19a139995@mail.gmail.com>
	<1214791943.7956.33.camel@bbc8>
	<9457e7c80806292306p45126db2ucb3338f8ea0767cb@mail.gmail.com>
	<1214808903.7956.54.camel@bbc8>
Message-ID: <db6b5ecc0806301600u3ab3f9c3x755680646f91d8e8@mail.gmail.com>

Howdy,

> Maybe I don't understand exactly what Fernando meant by history folding,
> then. For me, the above log is a typical example of history folding,
> because you have two levels of log (one for the mainline, one for the
> merged branch).

I just meant the fact that lp only shows the 'mainline' in its history
view, and what mainline is shown actually changes depending on who
does the last push.  The last person to merge and push gets 'his' view
of the world to appear in lp's view.  We've seen that type of change
very frequently already, but I've just decided to ignore that
'feature' of lp and move on.  Otherwise ipython-dev is going to turn
into a parallel version of bzr/lp-dev :)

Cheers,

f


From fperez.net at gmail.com  Mon Jun 30 20:37:44 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 30 Jun 2008 17:37:44 -0700
Subject: [IPython-dev] frontend plans
In-Reply-To: <6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com>
References: <cd7634ce0806251133i305d0b1dsccf083e3c64fcf73@mail.gmail.com>
	<6ce0ac130806251559s7350cc6csd1ce6ab65b7510f6@mail.gmail.com>
	<cd7634ce0806261354y7d6b228id4f17c04e9921e36@mail.gmail.com>
	<6ce0ac130806261603m24868dedh26cd9243ff389b20@mail.gmail.com>
	<cd7634ce0806262018g2deae150w9f39d7db82e55eb1@mail.gmail.com>
	<6ce0ac130806262031l191304d9xbd49100ab09def8@mail.gmail.com>
Message-ID: <db6b5ecc0806301737k7d5c0cafo5395a9fc4c933935@mail.gmail.com>

Hey folks,

I'm sorry that I failed to respond during this thread, but as it
happened I was at a conference with only micro-breaks for 'easy'
emails, but not to digest all of this :)

Having said that, here are a few thoughts on  what has been said so far:

- Gael: as Brian asked, what are your design parameters regarding GUI
blocking?  If you put the exec calls in a thread (like ipython
-Xthread does) you have some hope of interface responsiveness, if you
put them in a process you get full GUI responsiveness at the cost of
other complexities.  Are you OK with a non-responsive GUI while exec()
is busy?

- Zope interfaces: what do they exactly bring us?  Nose uses
interfaces in a non-enforcing way by making them pure python classes
that are meant to document behavior but *not* to be subclassed.
Perhaps we could have something similar for the pure python version
and then a ZI version for the rest of the twisted layer:

class BasicInterface(object):
  def foo(self,x,y):
    """does z with x and y"""
    raise NotImplementedError()

class RealInterface(BasicInterface,zope.interfaces.whatever):
  pass

Code NOT using twisted would inherit from the first type of functions,
and all twisted-based code would inherit from the second.

- basic observation: exec() is fundamentally a blocking primitive.  At
the end of the day, you have to wait for that particular chunk of code
to finish, and that's the python interpreter itself you're waiting
for.  For this reason, it makes sense that the lowest level
abstractions we have should be blocking, and asynchronous interfaces
are wrapped around those for systems that are 'removed' from this
execution core (by being out of process, in another computer, etc).
Yes, I know that exec() could be calling threaded code, but that
simply means that exec(x) can finish quickly and some of the results
will be ready later.  But the overall operation of completing the
execution of 'x' is still a blocking one.

- Because of the above, I'm not crazy about the whole "synchronous
deferred" use.  In my mind, the logical containment chain is:

(0 - python VM - fundamentally synchronous object) < (1 - Ipython
layer that manages this) < (2 - Asynchronous wrappers for systems that
will work out of process, over the network, etc).


- Tab completion: this is just one case of the more generic case of
how to represent out-of-process information.  We have to assume that
in general, only the core has true access to the real in-memory
objects of the user's namespace.  Clients may request information
about this for display purposes, and some communication of reduced
data may happen with such clients, but we can't expect to  copy the
user's namespace across the wire in a general sense.  So yes, tab
completion and similar introspection will always happen by clients
requesting the operation on the core, and the core sending back
something reasonable back (a list of strings, for example).


In summary:  it seems from what Barry said in the end, as well as
Gael, that we're all happy with the notion of a core, blocking system
that ultimately is just a bells-and-whistles version of python's "exec
code in namespace" statement.  It lets you manage that namespace,
introspect it, it offers extensions, history, etc, but ultimately it's
just wrapping that one single statement.  Because that statement
*fundamentally* blocks, this system blocks.  You can embed it in a GUI
or use it in a terminal, but it still blocks.

Beyond that, it makes sense to wrap this in a Twisted layer that turns
the result of exec() into a deferred.  This makes complete sense when
the process doing exec() is different than your own (gui, network,
etc) and you actively want to move on with your life, while having a
notification mechanism for handling results/errors arising from the
exec call.  At this point, the Twisted callback/errback system seems
well tailored for this.

And I certainly want to ensure that Gael finds the code that's in
there sufficient for him to use in his WX project.   It seems to me
that's the case, but have we left any question unanswered on that
front?

Cheers,

f


From fperez.net at gmail.com  Mon Jun 30 20:41:08 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 30 Jun 2008 17:41:08 -0700
Subject: [IPython-dev] Reposting : an issue in replaying logs with
	profile
In-Reply-To: <4864AC2A.3030004@slac.stanford.edu>
References: <4864AC2A.3030004@slac.stanford.edu>
Message-ID: <db6b5ecc0806301741p7993dah76fa23ac25b1e1b@mail.gmail.com>

Hi Jonathan,

On Fri, Jun 27, 2008 at 2:00 AM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> hello,
> my problem below did not get addressed. Can someone help me understand
> what I am doing wrong?

I'm sorry if it appears we're ignoring you: this is a bit of a subtle
problem and noone has simply had the time to dig into it.  If you do
come up with a patch, great!  Else, please file it as an actual bug
report so we don't forget it.  All the 'core' people are right now
knee deep in the huge amount of work that the merge is bringing upon
us, so there's a good chance an issue like this may go unattended for
longer than we'd like.

I hope that once the dust settles and our merged codes are
functioning, we could start scheduling a few bug days as part of our
release plans.  One more reason to encourage you to file it on LP,
even if we don't act on it right away.

If you do figure out a fix/patch, by all means send it in!

Cheers,

f