From strawman at astraw.com  Thu May  1 03:36:07 2008
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 01 May 2008 00:36:07 -0700
Subject: [IPython-dev] message from a launchpad developer
Message-ID: <481972E7.7070006@astraw.com>

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/

-Andrew


From vivainio at gmail.com  Fri May  2 04:56:47 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 2 May 2008 11:56:47 +0300
Subject: [IPython-dev] message from a launchpad developer
In-Reply-To: <481972E7.7070006@astraw.com>
References: <481972E7.7070006@astraw.com>
Message-ID: <46cb515a0805020156j7a492475i5bd63c685aa7717@mail.gmail.com>

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...

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


From strawman at astraw.com  Fri May  2 11:39:02 2008
From: strawman at astraw.com (Andrew Straw)
Date: Fri, 02 May 2008 08:39:02 -0700
Subject: [IPython-dev] message from a launchpad developer
In-Reply-To: <46cb515a0805020156j7a492475i5bd63c685aa7717@mail.gmail.com>
References: <481972E7.7070006@astraw.com>
	<46cb515a0805020156j7a492475i5bd63c685aa7717@mail.gmail.com>
Message-ID: <481B3596.5020709@astraw.com>

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.


From vivainio at gmail.com  Sat May  3 12:18:00 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 3 May 2008 19:18:00 +0300
Subject: [IPython-dev] Testing needed: python 2.3 installation
Message-ID: <46cb515a0805030918t2d681cfaw4cb4e3132bf2a5d9@mail.gmail.com>

I made a change in setup.py (in bzr trunk) that uses package_data
(supported in setuptools, and distutils versions shipped with python
2.4+) to ship UserConfig folder, in order to unbreak easy_install.

Could someone that has python 2.3 installed try doing "python setup.py
install", delete/move away ~/.ipython and see that ipython starts up
normally?

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


From ellisonbg.net at gmail.com  Thu May  8 12:51:09 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 8 May 2008 10:51:09 -0600
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
Message-ID: <6ce0ac130805080951y3c18696cg32dee2f5a769caac@mail.gmail.com>

> This work might be relevant for IPython1
>
>  http://twistedmatrix.com/trac/browser/sandbox/dialtone/process_pool

Thanks, I hadn't seen this.  I really like the AMP protocol, but I
don't think it is well suited to what we are doing with IPython1.  For
reference the project has moved to

https://launchpad.net/ampoule/

>  Also, any further thinking been done on the integration of the twisted
>  event loop with pyreadline?  More generally stated, I guess the question
>  really is, how hard is it to make pyreadline asynchronous (give it
>  cycles based on select or its new/better/different implementation epoll)

I am not the one to comment on this, but I do think people have begun
to think about this.  It would probably be in ipython1/frontend.  But
I don't think people have gotten very far yet.  Also, pyreadline is
Windows only, so I think you are referring to a pyreadline that
doesn't yet exist?

That said, here is my take on this.  Our model in ipython1 is that the
core/kernel of ipython1 will provide the methods that something like
readline (or the GUI equivalent) will need to call when certain things
are triggered.  The core/kernel will provide both blocking versions of
these methods and fully asynchronous versions (that return deferreds).

It will be up to the people who are writting frontends (IPython GUIs
or terminals) to plug into whatever mechanism that exist (readline for
the terminal, events for GUIs) for their context.  Of course, much of
the logic will be the same for all of these things, which is where (I
think) we will need something like a new pyreadline.  And yes, it
would need to be able to handle both asynchronous and blocking
situations.  I think Barry Wark has possibly begun to work on some of
this in the ipython1-cocoa branch - something like frontendbase.py?

Hope this helps, but I will say that we are not focused on this side
of things right now.  But we do have the design pieces in our heads.

Brian


>  Lately this has become a broader issue (for me at least) because similar
>  issues exist with Rpy... so I might be digging into this anyway...
>
>  -glenn
>
>  --
>  Glenn H. Tarbox, PhD    | Don't worry about people stealing your ideas. If your ideas
>  206-494-0819            | are any good, you'll have to ram them down people's throats
>  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer
>
>
>  _______________________________________________
>  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 May  8 13:42:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 8 May 2008 11:42:12 -0600
Subject: [IPython-dev] Ipython1 architecture...
In-Reply-To: <1207951765.6343.169.camel@ghtmyth.hq.tarbox.org>
References: <1207896523.6343.47.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130804111023v51693f3dm4a39b33399ea400b@mail.gmail.com>
	<1207951765.6343.169.camel@ghtmyth.hq.tarbox.org>
Message-ID: <6ce0ac130805081042s248e1186sd1ed845ff678d19d@mail.gmail.com>

Back to this thread after a long break...

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

OK

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

If I am understanding this usage case correctly, I think IPython1
would work in this context with its current capabilities.  But you
would definitely want to use our asynchronous client in asynclient.py.

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

Very true about the examples.  The more the better.

>
>  > >
>  > >  So, I'm interested in how and why threading is used in the client side
>  > >  of Ipython1.  Is it simply to provide support for non-blocking gui
>  > >  activity (like using -q4thread on the ipython command line) or is there
>  > >  some other reason.
>  >
>  > Ah yes, glad you asked.  From my perspective, threads are used in two
>  > broad ways:
>  >
>  > 1) As a model of parallelism/concurrency.  From this perspective,
>  > threads are a way of handling concurrency in a shared memory context.
>  > I personally think that threads are _not_ a good solution in this
>  > arena.  They are simply too low level and difficult to get right.
>
>  Agreed... and at multiple levels... difficult to get right by
>  infrastructure people... virtually impossible as a general capability
>  exposed to the masses.  I think threads are great in the kernel, for
>  example.  Fortunately, very few people are cleared for that kind of work

I agree with this.

>
>  >
>  > 2) As an implementation details for building other models of
>  > parallelism/concurrency.  For example, Erlang uses an actor based,
>  > shared nothing, message passing approach to concurreny.  But,
>  > underneath the hood Erlang uses threads to implement their runtime
>  > system.  I am all for this type of usage of threads.
>
>  Here we descend into the definition of threads...  At one level, the
>  abstraction is the same... but, really, all we're saying is that its
>  useful to maintain the stack frames...
>
>  Most languages (Python included) provide threads which maintain state
>  but also "help" with scheduling, context switching etc... but without
>  much control.... which means synchronization of shared state and, um,
>  proper architecture... again, a place that most users shouldn't be
>  playing.
>
>  Erlang / stackless / greenlets provide more control of what a thread
>  does and how execution is controlled... and this is where we've gone way
>  way beyond what folks understand... which is unfortunate because this
>  could, with proper architecture, provide straightforward code writing
>  without too much concern about this kind of nastiness... note that I
>  haven't even gotten into the real nastiness which is typically exposed
>  inside libraries which aren't thread safe

Yep, I agree that the models of erlang/stackless/greenlets are both
more complicated that most users will tolerate, and also a potentially
nice way of abstracting concurrency.  But, concurrency is very
different things (although they are related).  For example
stackless/greenlets express concurrency, but NOT parallelism.  Erlang
on the other hand handles both concurrency and parallelism.

>
>  >
>  > In my mind, our usage of threads in the ipython1 falls into category
>  > 2).  We are not advocating that users know or care about threads.
>  > But, we do need them in our implementation.  Here is why:
>  >
>  > Long ago, when we first started ipython1, we did not use Twisted.  In
>  > fact, we used plain old blocking sockets for our client.  The reason
>  > is that we have always wanted an API that your average scientists
>  > could understand.  And in our experience (we are scientists),
>  > scientists do not think in terms of event loops or deferreds.  They
>  > think in very blocking terms.  Thus, we have always felt like our
>  > design goals require a blocking (possibly polling) user-facing
>  > interface.
>
>  I've been using twisted for quite a while, and still get major brain
>  damage from time to time trying to figure out how to invert code to be
>  twisted compliant... so I'm very much in agreement...

Yep, I love Twisted, but sometimes it hurts.

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

Here is an example:

In [1]: from ipython1.kernel import client

In [2]: mec = client.MultiEngineClient(('localhost',10105))

In [3]: mec.push(dict(a=10))
Out[3]: [None, None, None, None, None]

In [4]: mec.pull('a')
Out[4]: [10, 10, 10, 10, 10]

All of these commands are fully blocking!  But the implementation uses
twisted!  It seems like you don't want/need a blocking interface, but
our main target audience (working scientists who don't know a thing
about asynchronous things) absolutely need a blocking interface.  At
most they neeed to be able to poll for results:

In [5]: mec.block= False

In [6]: mec.pull('a')
Out[6]: <ipython1.kernel.multiengineclient.PendingResult object at 0x15f3870>

In [7]: _.r
Out[7]: [10, 10, 10, 10, 10]

But, we also have a fully asynchronous client interface
(asynclient.py) that 1) doesn't use threads anywhere and 2) every
method returns a deferred.

Bottom line: we need to support both modes with an implementation that
is Twisted based.  To get the blocking mode with Twisted, you _must_
use threads like we do (with blockingCallFromThread).

>
>  >
>  > So, we asked on the Twisted lists, "how can we block on a deferred?"
>  > There was much laughter and blanket statements like "you don't want to
>  > do that" and "you can't do that."
>
>  I love the twisted guys and think they're onto something really huge...
>  But, they are very very opinionated on stuff like this (more often then
>  not, they're also exactly right)...

Yep absolutely.

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

Yes, coroutines open up other routes for handling these things other
than threads.  But, I am not yet ready to jump on that until true
coroutines have been implemented well without a hacked python
interpreter.

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

True, at some level, we can't prevent users from calling libraries at
will.  But, I am not quite sure what things a user could call that
would cause problems with our approach.  The only thing that would be
problematic is if they want to call Twisted.  But then they should
simply use our non-threaded asynclient.py stuff.

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

Does my above example clarify this point?

>
>  >
>  > >  I'd probably go farther and say that threading might really only have a
>  > >  proper place in the architecture for compute bound problems.  Given that
>  > >  this is a parallel computing activity, that would make sense, but it
>  > >  would really need to be thought through (and it looks like it might very
>  > >  have been very carefully thought through).  Fortunately, twisted
>  > >  provides very nice integration between the "main" thread and compute
>  > >  threads, so I'm sure that all is well... but...
>  >
>  > I still think threads are useful in implementing higher level
>  > concurrency constructs - even though I agree with you that i don't
>  > think they are a good solution many other things.
>
>  I also believe threads are useful... but the care required is very much
>  under appreciated...  There is no better way to introduce
>  non-reproducible, non-deterministic, non-debuggable, spurious errors
>  into infrastructure code than with threads (other than particle
>  emissions from deep space, something Sun can speak to)
>
>  I'll make a completely unsupportable statement that in aggregate we'd
>  get more productivity without threads than with... of course, what a
>  waste that would be because done properly, threads make trivial work of
>  difficult problems... but too few people have enough of a clue or are
>  willing to spend the time to understand the issues.

At some level I completely agree with these statements.  If we had
written IPython1 using low-level threads rather than Twisted, it would
be buggy nasty code.  With Twisted, it is clean robust code.

>
>  >
>  > One thing that is really nice about twisted is that it does play well
>  > with threads.  Our entire model is really message based (shared
>  > nothing) and if python didn't have the GIL, we could do some very cool
>  > single process things.
>
>  If we didn't have the GIL, Python would save 50% of mailing list traffic
>  and have something realistic to say WRT the multicore world we're
>  already in.  I have a feeling this one will get fixed... there are way
>  too many smart people involved and its too important not to get fixed.
>  Good thing we beat that cold virus too huh? :-)

Here to hoping :-)

>
>  >
>  > >  On the client side, it appears as though the reactor itself is spawned
>  > >  in a thread.  Given that my gui code will be entirely reactor driven,
>  > >  I'm probably fine... but how is the thread coordination planned?  From
>  > >  previous posts its clear that the use of the new twisted blocking thread
>  > >  stuff is heavily used (can't recall the proper names right now).  Again,
>  > >  great... but it would be good to know what the intent is and, more
>  > >  importantly, if I'm gonna get bit.
>  >
>  > The interaction between the twisted reactors thread and GUI threads is
>  > something we do need to think more about.  We would love help when we
>  > get around to that.  We need to make sure that people don't get bit
>  > because they choose to use our stuff.
>
>  So, why do we have multiple threads here?  The twisted gui reactors,
>  including the qtreactor I maintain, do everything in one thread.  So,
>  gtk and qt are single threaded already.  the wxreactor used a separate
>  thread because of wierd behavior with wx which may no longer be valid...
>  but if it is valid, we need to get wx fixed (it can't be that hard)...
>  but there is no reason that the gui needs to be in a different thread.

Yes, getting things in one thread is one step.  But it doesn't solve
all of the problems:

1) Assume the GUI+Twisted reactor are running in the main thread.

2) Assume that user code running in that process needs to block on the
result of a deferred.

3) This will require that user code runs in a different thread and
that blockingCallFromThread is used.

4) But changes are, user code will also want to work with GUI objects,
thus user code must run in the main thread.

But, this is a simple contradiction - user code can't run in the main
thread and the non-main thread.  To beat the contradiction, you have
to get rid of either assumption 1 or assumption 2.  I imagine that you
would like to get rid of 2, but our design criteria don't allow for
that.  All of this will become relevant when IPython itself is running
in an event loop.  I don't know what to do about this.  Any ideas?

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

This is beyond my understanding of these things (I know very little
about readline).

>
>  > Coroutines:  I would love to see a demonstration of using coroutines
>  > and twisted, but using stackless or another custom python version is
>  > not an option.  Another option is greenlet and corotwine:
>  >
>  > http://codespeak.net/py/dist/greenlet.html
>  > https://launchpad.net/corotwine/
>  >
>  > These run with the standard Cpython.  I haven't played with them, but
>  > would love it if someone wanted to scope this out and and report back.
>
>  Me too... and perhaps I'll do some of this... but we're into a different
>  client base here also.  While coroutines provide extremely useful
>  abstractions and "can" avoid typical threading difficulties (as well as
>  providing thousands vs. tens of concurrent frames) one is faced with
>  coroutine semantics.

I am not proposing we expose these semantics to users though - only
that we could use them in implementations that are hidden from the
user.  Similar to how we currently use threads.

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

I don't think that most users will want to touch or think about co-routines.

>
>  >
>  > Erlang:  I _really_ like Erlang.  I have been spending some of my free
>  > time messing with Erlang and as far as I am concerned it is the best
>  > language for concurrent/distributed programming.  What do I mean by
>  > this.  It is what I would like Twisted to be.  Twisted is fantastic,
>  > but I really need single process twisted apps to scale to multiple
>  > cores.  An erlang app (at least in principle) can scale across both
>  > threads and processes and that is really amazing.  I should also say
>  > that I am amazed at how far Twisted goes in this direction.  It is
>  > quite amazing!
>
>  Hmmm... so, we're mixing models here and this is the kind of thing which
>  we need to get framed in order to make useful progress...
>
>  coroutines are about maintaining execution state independent of
>  execution resources in order to provide the kind of control needed to
>  work properly at scale and to minimize the waste of resources not really
>  designed for all applications.  So, Erlang is about a lot of parallel
>  threads but not necessarily about compute bound processing...  Whats
>  nice is that state machine management is "implicitly" encoded in a
>  top-down manner (the stack frames are automatically managed by the
>  language).  Of course, Erlang also provids all the other stuff which
>  does lend itself to compute bound processing across cores etc...
>
>  but, what are we trying to do?  Is it MPI type work with python, or
>  coroutines... are we doing huge petri-nets or CFD?  There are many
>  similarities WRT infrastructure... but CFD cares a lot less about state
>  machines than massive petri-nets.

Again, I am only interested in Erlang for implementation purposes, not
for user-facing code.  Our users don't want to implement a distributed
asynchronous system - they want to use the one that we build.  But the
tools and models that we use in the implementation can be completely
different from what the users see.


>
>  >
>  > But, I should say, I think Python is the best language for scientific,
>  > mathematical and numerical computing.  Thus, I don't ever see a day
>  > when I would recommend that a scientist use erlang to solve their
>  > favorite diff-eq.
>
>  agreed.  Python also plays nice with lower level code so wrapping nasty
>  compute bound funcitonality is easy enough...  I think one of the best
>  examples is matplotlib (over scipy/numpy)... just in that you're most of
>  the way to what a lot of folks use matlab for with a much better
>  language
>
>
>  >
>  > But, the combination of Erlang and Python is very interesting.  Here
>  > is what I have been thinking.  There is a not a Twisted implementation
>  > of the Erlang node protocol:
>  >
>  > https://launchpad.net/twotp
>  >
>  > I have played around with this and it is very encouraging.  More work
>  > needs to be done, but there is a great foundation.  This lets
>  > Python+Twisted processes talk seamlessly to Erlang nodes.  You can
>  > imagine the possibilities.  My basic vision would be to have an
>  > implementation of ipython1, where the controller is an erlang node,
>  > and the engines/clients are python.  The advantages would be:
>  >
>  > 1) Better performance in terms of the networking stuff.
>
>  Hmmm... I'm with you on the first part of this... not sure that
>  performance is ever enhanced by python... python is about programmer
>  productivity and very rich semantic constructs... but i doubt you're
>  gonna see overall higher performance

Sorry if I wasn't clear on this - Erlang has much better performance
that Python+Twisted for asynchronous networking stuff.  Bob Ippolito
has done this comparison and has mentioned to me that the difference
was "unbelievable"

>
>  >
>  > 2) The controller is currently a huge bottleneck for us.  It simple
>  > has to do to much.  If we used erlang, it would be much easier to
>  > scale the controller itself to multiple cores or even multiple hosts.
>
>  not sure about this either.  First, I can't imagine the controller has a
>  huge amount to do but I say this without knowing much about it... seems
>  like a twisted process living on a multi-core cpu would work fine... the
>  other cores would provide all the support services (I/O etc) while a
>  single twisted process can handle coordination messaging...  If the
>  controller is doing a bunch of compute heavy work, I think I'd need to
>  know more... but I'd be surprised

The controller has a _massive_ amount to do under heavy load.  It is
the main bottleneck in IPython1 by a long short.  The difficult part
is that the problems don't come from a few CPU bound things - it comes
from lots of small extra overheads that come when you scale to many
engines, many tasks, etc.  It is the overhead of using Python+Twisted.

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

True, as of yet, they have punted on this issue.  It is not nearly as
important as the fault tolerance of the engines.

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

True


>
>  >
>  > Downside of using Erlang:
>  >
>  > 1) Users would have to install Erlang and Python
>
>  yea, but if this is scipyCoroutines, they're already in... they either
>  have this kind of problem or not... if so, we're facilitators...

Yep

>
>  >
>  > Bottom line:  there are lots of really interesting directions to go
>  > in.  We just need good people with vision and ideas.
>
>  The set intersection problem again... :-)

Cheers,

Brian

>  -glenn
>
>
>  >
>  > Cheers,
>  >
>  > Brian
>  >
>  > >  and its on the above that orthogonality need be maintained.
>  > >
>  > >  I could digress into domain specific nastiness... but will spare the
>  > >  larger group... I guess that I hope for some increased radiation on the
>  > >  Ipython1 front.
>  > >
>  > >  -glenn
>  > >
>  > >  --
>  > >  Glenn H. Tarbox, PhD    | Don't worry about people stealing your ideas. If your ideas
>  > >  206-494-0819            | are any good, you'll have to ram them down people's throats
>  > >  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode
>  > >
>  > >  _______________________________________________
>  > >  IPython-dev mailing list
>  > >  IPython-dev at scipy.org
>  > >  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>  > >
>  --
>
> Glenn H. Tarbox, PhD    | Don't worry about people stealing your ideas. If your ideas
>  206-494-0819            | are any good, you'll have to ram them down people's throats
>  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer
>
>
>


From fperez.net at gmail.com  Thu May  8 16:40:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 8 May 2008 13:40:57 -0700
Subject: [IPython-dev] Testing needed: python 2.3 installation
In-Reply-To: <46cb515a0805030918t2d681cfaw4cb4e3132bf2a5d9@mail.gmail.com>
References: <46cb515a0805030918t2d681cfaw4cb4e3132bf2a5d9@mail.gmail.com>
Message-ID: <db6b5ecc0805081340v680a3e55sbf491f832d1f3cc6@mail.gmail.com>

On Sat, May 3, 2008 at 9:18 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> I made a change in setup.py (in bzr trunk) that uses package_data
>  (supported in setuptools, and distutils versions shipped with python
>  2.4+) to ship UserConfig folder, in order to unbreak easy_install.
>
>  Could someone that has python 2.3 installed try doing "python setup.py
>  install", delete/move away ~/.ipython and see that ipython starts up
>  normally?

Well, it looks like ipython hasn't worked with 2.3 for a while:

bic128[bin]$ ./ipython
Traceback (most recent call last):
  File "./ipython", line 27, in ?
    IPython.Shell.start().mainloop()
  File "/home/fperez/tmp/local//lib/python2.3/site-packages/IPython/Shell.py",
line 1215, in start
    shell = _select_shell(sys.argv)
  File "/home/fperez/tmp/local//lib/python2.3/site-packages/IPython/Shell.py",
line 1157, in _select_shell
    all_opts = set(['tk','pylab','gthread','qthread','q4thread','wthread',
NameError: global name 'set' is not defined

The real question is: have we reached the point where we should just
declare 2.4 to be our base requirement?

I'm happy to continue supporting 2.3 (the above problem is trivial to
fix, though there may be more), but 2.4 has been out for 3 1/2 years
already.  We have painfully limited developer time and plenty of
not-done work.  Unless someone makes a good case for why 2.3 support
is key, I'm inclined to dump it for the next release of ipython0.
IPython1 already depends on it anyway (and some of the new goodies
we're putting in actually need 2.5!).

Cheers,

f


From barrywark at gmail.com  Thu May  8 18:21:10 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 8 May 2008 15:21:10 -0700
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
Message-ID: <cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>

Glenn, would you or one of the other Twisted gurus help me understand
pyreadline is the appropriate place for integration with the Twisted
event loop in ipython1? My (very basic) understanding of pyreadline is
that it's a readline/editline replacement, making it most relevant to
terminal-based frontends. Would GUI frontends that use a different
metaphor (e.g. block instead of line oriented) still use pyreadline?

barry

On Sun, Apr 20, 2008 at 6:35 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> This work might be relevant for IPython1
>
>  http://twistedmatrix.com/trac/browser/sandbox/dialtone/process_pool
>
>  Also, any further thinking been done on the integration of the twisted
>  event loop with pyreadline?  More generally stated, I guess the question
>  really is, how hard is it to make pyreadline asynchronous (give it
>  cycles based on select or its new/better/different implementation epoll)
>
>  Lately this has become a broader issue (for me at least) because similar
>  issues exist with Rpy... so I might be digging into this anyway...
>
>  -glenn
>
>  --
>  Glenn H. Tarbox, PhD    | Don't worry about people stealing your ideas. If your ideas
>  206-494-0819            | are any good, you'll have to ram them down people's throats
>  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer
>
>
>  _______________________________________________
>  IPython-dev mailing list
>  IPython-dev at scipy.org
>  http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From barrywark at gmail.com  Thu May  8 18:24:20 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 8 May 2008 15:24:20 -0700
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <6ce0ac130805080951y3c18696cg32dee2f5a769caac@mail.gmail.com>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
	<6ce0ac130805080951y3c18696cg32dee2f5a769caac@mail.gmail.com>
Message-ID: <cd7634ce0805081524t19b42ecfr9dbc673a38df2b2d@mail.gmail.com>

On Thu, May 8, 2008 at 9:51 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> This work might be relevant for IPython1
>>
>>  http://twistedmatrix.com/trac/browser/sandbox/dialtone/process_pool
>
> Thanks, I hadn't seen this.  I really like the AMP protocol, but I
> don't think it is well suited to what we are doing with IPython1.  For
> reference the project has moved to
>
> https://launchpad.net/ampoule/
>
>>  Also, any further thinking been done on the integration of the twisted
>>  event loop with pyreadline?  More generally stated, I guess the question
>>  really is, how hard is it to make pyreadline asynchronous (give it
>>  cycles based on select or its new/better/different implementation epoll)
>
> I am not the one to comment on this, but I do think people have begun
> to think about this.  It would probably be in ipython1/frontend.  But
> I don't think people have gotten very far yet.  Also, pyreadline is
> Windows only, so I think you are referring to a pyreadline that
> doesn't yet exist?
>
> That said, here is my take on this.  Our model in ipython1 is that the
> core/kernel of ipython1 will provide the methods that something like
> readline (or the GUI equivalent) will need to call when certain things
> are triggered.  The core/kernel will provide both blocking versions of
> these methods and fully asynchronous versions (that return deferreds).
>
> It will be up to the people who are writting frontends (IPython GUIs
> or terminals) to plug into whatever mechanism that exist (readline for
> the terminal, events for GUIs) for their context.  Of course, much of
> the logic will be the same for all of these things, which is where (I
> think) we will need something like a new pyreadline.  And yes, it
> would need to be able to handle both asynchronous and blocking
> situations.  I think Barry Wark has possibly begun to work on some of
> this in the ipython1-cocoa branch - something like frontendbase.py?

Correct. The intention is that the ipython1.frontend.frontendbase
contains the common logic for frontends. It's currently async-based,
but will eventually have to encompass both async and sync models, much
like core/kernel vs. engineservice. Unfortunately, ipython1-cocoa is
in a pretty broken state as I'm working on it... I will let folks know
as soon as there's something worth looking at--but feel free to take a
look and comment in the mean time.


>
> Hope this helps, but I will say that we are not focused on this side
> of things right now.  But we do have the design pieces in our heads.
>
> Brian
>
>
>>  Lately this has become a broader issue (for me at least) because similar
>>  issues exist with Rpy... so I might be digging into this anyway...
>>
>>  -glenn
>>
>>  --
>>  Glenn H. Tarbox, PhD    | Don't worry about people stealing your ideas. If your ideas
>>  206-494-0819            | are any good, you'll have to ram them down people's throats
>>  glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer
>>
>>
>>  _______________________________________________
>>  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 gael.varoquaux at normalesup.org  Sun May 11 12:31:47 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 11 May 2008 18:31:47 +0200
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
	<cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>
Message-ID: <20080511163147.GF28418@phare.normalesup.org>

On Thu, May 08, 2008 at 03:21:10PM -0700, Barry Wark wrote:
> Glenn, would you or one of the other Twisted gurus help me understand
> pyreadline is the appropriate place for integration with the Twisted
> event loop in ipython1?

I had a look at this problem a couple of month ago, and came to the
conclusion the pyreadline was not suited for this, as it was not
architectured for callback-driven mechanisms. 

I do believe there is a need for an abstraction of this kind to do
impedance matching between user input, whether it be callback-driven or
line-driven, which can be seen as a special case of callback-driven. We
don't want functionality like testing whether a line is complete or
dealing with history sitting in the front end as this code is not
front-end-specific and we absolutely want to avoid repeating ourselves
(in addition to really bad design from a CS point of view, this would
most probably bring in inconsistent behavior between the different
front-end. We don't want this code sitting in the engine or the
controller as, first of all, we want to avoid extra round trips across
the network, and, most important, sharing this information between
different front ends (and thus users) would yield inconsistent behavior.

I have started something that we decided to call "InputStateManager", in
the ipython1 code base. Its goal is to do exactly what you want: expose
an abstraction layer above the controller, with an interface that can be
used as callbacks in an event loop. This beast is currently very rough.
It emerged organically when trying to adapt the ipython1 interpreter (I
am not sure such a thing still exists) to the Wx frontend. It is not
terribly well coded, and should be seen as a rough cut that is meant to
be improved (I wouldn't feel sorry at all if not one line of this file
was kept in the long run, I think only the interface is important, and
it can still be improved). For me the guiding principle when working on
the InputStateManager seems to be that if you use callbacks, you can fit
you interface to any user-interaction paradigm.

There still is a lot of work on the InputStateManager, and I won't be
able to work on it before August (yes, that's long, sorry), but I don't
regard this as my territory, and I'd be very happy if somebody hacks on
it, especially since I believe different people hacking on it with
different requirements will make the interface more general.

Cheers,

Ga?l


From robert.kern at gmail.com  Mon May 12 19:35:54 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 12 May 2008 18:35:54 -0500
Subject: [IPython-dev] .. hint:: not support in HTML docs?
Message-ID: <g0ak8r$qch$1@ger.gmane.org>

I'm trying to build the HTML docs for ipython0 using SVN Sphinx and docutils. It 
falls over on the .. hint:: node in install.txt.

writing output... index install Exception occurred:
   File "/Users/rkern/src/docutils-svn/docutils/docutils/nodes.py", line 1560, 
in unknown_visit
     % (self.__class__, node.__class__.__name__))
NotImplementedError: sphinx.htmlwriter.SmartyPantsHTMLTranslator visiting 
unknown node type: hint
The full traceback has been saved in 
/var/folders/ZI/ZIYcWiesHNix8+QqtBdmWk+++TI/-Tmp-/sphinx-err-6V2z9g.log, if you 
want to report the issue to the author.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
Send reports to sphinx-dev at googlegroups.com. Thanks!
make: *** [html] Error 1


It's looking for a visit_hint() method in the writer. However, it appears that 
only the LaTeX writers in docutils and Sphinx even *have* a visit_hint() method. 
Has anyone else managed to build the ipython0 documentation in HTML format?

-- 
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  Mon May 12 19:37:05 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 12 May 2008 18:37:05 -0500
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <g0ak8r$qch$1@ger.gmane.org>
References: <g0ak8r$qch$1@ger.gmane.org>
Message-ID: <g0akb1$qch$2@ger.gmane.org>

Robert Kern wrote:
> I'm trying to build the HTML docs for ipython0 using SVN Sphinx and docutils.

Oops. I meant ipython1.

-- 
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 ellisonbg.net at gmail.com  Mon May 12 20:19:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 12 May 2008 18:19:12 -0600
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <g0ak8r$qch$1@ger.gmane.org>
References: <g0ak8r$qch$1@ger.gmane.org>
Message-ID: <6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>

Robert,

Can you retry with the latest stable of Sphinx?  (That is what I am
using and it worked fine)

Brian

On Mon, May 12, 2008 at 5:35 PM, Robert Kern <robert.kern at gmail.com> wrote:
> I'm trying to build the HTML docs for ipython0 using SVN Sphinx and docutils. It
>  falls over on the .. hint:: node in install.txt.
>
>  writing output... index install Exception occurred:
>    File "/Users/rkern/src/docutils-svn/docutils/docutils/nodes.py", line 1560,
>  in unknown_visit
>      % (self.__class__, node.__class__.__name__))
>  NotImplementedError: sphinx.htmlwriter.SmartyPantsHTMLTranslator visiting
>  unknown node type: hint
>  The full traceback has been saved in
>  /var/folders/ZI/ZIYcWiesHNix8+QqtBdmWk+++TI/-Tmp-/sphinx-err-6V2z9g.log, if you
>  want to report the issue to the author.
>  Please also report this if it was a user error, so that a better error message
>  can be provided next time.
>  Send reports to sphinx-dev at googlegroups.com. Thanks!
>  make: *** [html] Error 1
>
>
>  It's looking for a visit_hint() method in the writer. However, it appears that
>  only the LaTeX writers in docutils and Sphinx even *have* a visit_hint() method.
>  Has anyone else managed to build the ipython0 documentation in HTML format?
>
>  --
>  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
>


From robert.kern at gmail.com  Mon May 12 21:52:05 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 12 May 2008 20:52:05 -0500
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>
References: <g0ak8r$qch$1@ger.gmane.org>
	<6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>
Message-ID: <3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com>

On Mon, May 12, 2008 at 7:19 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Robert,
>
> Can you retry with the latest stable of Sphinx?  (That is what I am
> using and it worked fine)

That's what I started with. No luck.

-- 
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 ellisonbg.net at gmail.com  Mon May 12 22:18:23 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 12 May 2008 20:18:23 -0600
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com>
References: <g0ak8r$qch$1@ger.gmane.org>
	<6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>
	<3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com>
Message-ID: <6ce0ac130805121918t470fbd46icb709523440a9978@mail.gmail.com>

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.

Brian

On Mon, May 12, 2008 at 7:52 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Mon, May 12, 2008 at 7:19 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>  > Robert,
>  >
>  > Can you retry with the latest stable of Sphinx?  (That is what I am
>  > using and it worked fine)
>
>  That's what I started with. No luck.
>
>  --
>
>
> 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
>


From robert.kern at gmail.com  Mon May 12 22:29:24 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 12 May 2008 21:29:24 -0500
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <6ce0ac130805121918t470fbd46icb709523440a9978@mail.gmail.com>
References: <g0ak8r$qch$1@ger.gmane.org>
	<6ce0ac130805121719r112692e9n517b2cb4c9e39f1c@mail.gmail.com>
	<3d375d730805121852l758ad592n7cc5e755dfc8f997@mail.gmail.com>
	<6ce0ac130805121918t470fbd46icb709523440a9978@mail.gmail.com>
Message-ID: <3d375d730805121929r16a72402q1cc83b64beba7867@mail.gmail.com>

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.

-- 
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 ellisonbg.net at gmail.com  Mon May 12 22:59:27 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 12 May 2008 20:59:27 -0600
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <3d375d730805121929r16a72402q1cc83b64beba7867@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>
Message-ID: <6ce0ac130805121959k7318b2f1l8838af82336762fb@mail.gmail.com>

I just checked and I am running:

docutils-0.4
Sphinx-0.3

And the html docs build fine.  Let me know if there is something more
problematic going on.

Brian

On Mon, May 12, 2008 at 8: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.
>
>  --
>
>
> 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
>


From ellisonbg.net at gmail.com  Mon May 12 23:05:55 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 12 May 2008 21:05:55 -0600
Subject: [IPython-dev] IPython1 0.3 prerelease
Message-ID: <6ce0ac130805122005td861b88uda3f2067b571d5ab@mail.gmail.com>

Hi,

We are getting ready to release version 0.3 of IPython1.  This version
has been long in the waiting and has lots of new features and
enhancement.  Trying IPython1 out is easier than ever, as it is
easy_installable now (don't worry, we still have a plain distutils
setup.py as well):

easy_install ipython1

This will get the latest ipython1 0.3 prerelease as well as Twisted
and zope.interface if you don't have it.  Please try installing this
prerelease and running the test suite (trial ipython1).  The final
version of ipython1 0.3 will be cut later this week.

For the curious, here are the list of changes:


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.
	* IPython1 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`.
	* 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:`asynclient` 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 IPython1 docuementation.  All of the documentation
	  from the IPython1 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``.

Cheers,

Brian


From ellisonbg.net at gmail.com  Tue May 13 13:34:44 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 13 May 2008 11:34:44 -0600
Subject: [IPython-dev] [IPython-user] IPython1 0.3 prerelease
In-Reply-To: <79990c6b0805130036y406f5134i483bc512cc0a9f2a@mail.gmail.com>
References: <6ce0ac130805122005td861b88uda3f2067b571d5ab@mail.gmail.com>
	<79990c6b0805130036y406f5134i483bc512cc0a9f2a@mail.gmail.com>
Message-ID: <6ce0ac130805131034y4546c4eay54a389c6bfc89e28@mail.gmail.com>

On Tue, May 13, 2008 at 1:36 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 2008/5/13 Brian Granger <ellisonbg.net at gmail.com>:
>
> >  We are getting ready to release version 0.3 of IPython1.  This version
>  >  has been long in the waiting and has lots of new features and
>  >  enhancement.  Trying IPython1 out is easier than ever, as it is
>  >  easy_installable now (don't worry, we still have a plain distutils
>  >  setup.py as well):
>  >
>  >  easy_install ipython1
>  >
>  >  This will get the latest ipython1 0.3 prerelease as well as Twisted
>  >  and zope.interface if you don't have it.  Please try installing this
>  >  prerelease and running the test suite (trial ipython1).  The final
>  >  version of ipython1 0.3 will be cut later this week.
>
>  Given that I don't use eggs, can I check - are Twisted and
>  zope.interface now mandatory prerequisites? They certainly weren't in
>  the previous version. Also, I assume that on Windows, pyreadline is
>  still needed?

Note:  this is a release of IPython1, which is a separate project than
regular ipython (which some are now calling "ipython0".  IPython1
provides parallel computing capabilties and does require both
zope.interface and Twisted.  Sorry about the confusion.

Brian

>  Paul.
>


From steve at shrogers.com  Tue May 13 20:07:19 2008
From: steve at shrogers.com (Steven H. Rogers)
Date: Tue, 13 May 2008 18:07:19 -0600
Subject: [IPython-dev] [IPython-user] IPython1 0.3 prerelease
In-Reply-To: <79990c6b0805131433j5b495e7et89d2c7dcd5bdc2ac@mail.gmail.com>
References: <6ce0ac130805122005td861b88uda3f2067b571d5ab@mail.gmail.com>	<79990c6b0805130036y406f5134i483bc512cc0a9f2a@mail.gmail.com>	<6ce0ac130805131034y4546c4eay54a389c6bfc89e28@mail.gmail.com>
	<79990c6b0805131433j5b495e7et89d2c7dcd5bdc2ac@mail.gmail.com>
Message-ID: <482A2D37.6030201@shrogers.com>

Paul Moore wrote:
> No problem, but I had understood that IPython1 is intended to
> ultimately replace ipython0. If that isn't the case, I'd suggest that
> the name is misleading :-) If it *is* the case, I'd like to try it
> out, but be able to skip the dependencies which relate to features
> such as parallel computing that I don't need.
>   
Paul:

If you don't need parallel computing, you don't need IPython1 at this 
point.  While it will ultimately replace IPython0, it isn't there yet.  
When it is ready to replace IPython0, the Twisted and zope.interface 
dependencies will be optional.  Making this optional at this point would 
probably slow down development.

# Steve


From barrywark at gmail.com  Tue May 13 22:28:01 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 13 May 2008 19:28:01 -0700
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <20080511163147.GF28418@phare.normalesup.org>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
	<cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>
	<20080511163147.GF28418@phare.normalesup.org>
Message-ID: <cd7634ce0805131928g5acca684hf7bf2a814c1e4089@mail.gmail.com>

Gael,

Although I agree with your premises (we want to avoid duplication of
code between core/kernel and frontends), I've come to a different
conclusion as I've worked on the Cocoa frontend. I'll share my
alternative opinion here not to put yours down but to stimulate some
discussion in the group...

I feel that the InputStateManager as it's been outlined conflates two
issues: handling user gestures and provided common functionality. I'll
try to explain what I mean below.

On Sun, May 11, 2008 at 9:31 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Thu, May 08, 2008 at 03:21:10PM -0700, Barry Wark wrote:
>  > Glenn, would you or one of the other Twisted gurus help me understand
>  > pyreadline is the appropriate place for integration with the Twisted
>  > event loop in ipython1?
>
>  I had a look at this problem a couple of month ago, and came to the
>  conclusion the pyreadline was not suited for this, as it was not
>  architectured for callback-driven mechanisms.
>
>  I do believe there is a need for an abstraction of this kind to do
>  impedance matching between user input, whether it be callback-driven or
>  line-driven, which can be seen as a special case of callback-driven. We
>  don't want functionality like testing whether a line is complete or
>  dealing with history sitting in the front end as this code is not
>  front-end-specific and we absolutely want to avoid repeating ourselves
>  (in addition to really bad design from a CS point of view, this would
>  most probably bring in inconsistent behavior between the different
>  front-end. We don't want this code sitting in the engine or the
>  controller as, first of all, we want to avoid extra round trips across
>  the network, and, most important, sharing this information between
>  different front ends (and thus users) would yield inconsistent behavior.

But different frontends may _have_ very different behavior. For
example, the behavior of a block-oriented (e.g. Mathematica's
notebook) frontend is behavior than a line-oriented (e.g. terminal)
frontend. For the block-oriented frontend, the builtin compile
function is sufficient to determine if a block is executable. In
addition, the expectation of users on different systems (e.g. OS X vs.
Gnome vs. Windows) may be very different. To try to produce identical
behavior across all frontends will frustrate everyone (ala Java).

>
>  I have started something that we decided to call "InputStateManager", in
>  the ipython1 code base. Its goal is to do exactly what you want: expose
>  an abstraction layer above the controller, with an interface that can be
>  used as callbacks in an event loop. This beast is currently very rough.
>  It emerged organically when trying to adapt the ipython1 interpreter (I
>  am not sure such a thing still exists) to the Wx frontend. It is not
>  terribly well coded, and should be seen as a rough cut that is meant to
>  be improved (I wouldn't feel sorry at all if not one line of this file
>  was kept in the long run, I think only the interface is important, and
>  it can still be improved). For me the guiding principle when working on
>  the InputStateManager seems to be that if you use callbacks, you can fit
>  you interface to any user-interaction paradigm.

I think attempting to create our own UI event system (as
InputStateManager is doing) is the wrong path. Matplotlib's multiple
backends are a necessary evil (perhaps), but keeping them all in sync
appears to be a huge (and somewhat unsuccesful) effort. Why not let
frontend developers exploit the native event system. I think it's more
useful for us to provide handlers for the actions the frontend might
want to take (e.g. executing a block of code) rather than translate
native events into our own event system. I've started this approach in
the ipython1-cocoa branch in the frontend.frontendbase module.
frontendbase provides common actions (e.g. check if a block is
complete, execute a block, etc.) and provides hooks for implementers
to override to e.g. display the result of an executed block.

>
>  There still is a lot of work on the InputStateManager, and I won't be
>  able to work on it before August (yes, that's long, sorry), but I don't
>  regard this as my territory, and I'd be very happy if somebody hacks on
>  it, especially since I believe different people hacking on it with
>  different requirements will make the interface more general.
>
>  Cheers,
>
>  Ga?l
>


From vivainio at gmail.com  Wed May 14 02:04:23 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 14 May 2008 09:04:23 +0300
Subject: [IPython-dev] [IPython-user] IPython1 0.3 prerelease
In-Reply-To: <79990c6b0805131433j5b495e7et89d2c7dcd5bdc2ac@mail.gmail.com>
References: <6ce0ac130805122005td861b88uda3f2067b571d5ab@mail.gmail.com>
	<79990c6b0805130036y406f5134i483bc512cc0a9f2a@mail.gmail.com>
	<6ce0ac130805131034y4546c4eay54a389c6bfc89e28@mail.gmail.com>
	<79990c6b0805131433j5b495e7et89d2c7dcd5bdc2ac@mail.gmail.com>
Message-ID: <46cb515a0805132304p55afafa9pe493c7ff4c816b@mail.gmail.com>

On Wed, May 14, 2008 at 12:33 AM, Paul Moore <p.f.moore at gmail.com> wrote:

>    1. Clean up the existing codebase and write lots of tests.
>    2. Separate the core functionality of IPython from the terminal to
>  enable IPython to be used from within a variety of GUI applications.
>    3. Implement a system for interactive parallel computing.
>
>  seems to imply that IPython1 will replace IPython. And if it isn't

IPython1 has become a bit more ambitious after that was written, but
the feature parity is still the target. It's just not there yet, and
the dependencies will probably still be there.

>  going to, what are the plans for ipython0 development?

It's still being maintained, most of the work is done by yours truly
(which has been the situation for 2 years already) . We are pretty
much ready to release 0.8.3 when the sphinx doc creation works
properly with pdf (or we work around the bug).

There are no ambitious future plans, apart from getting bugs fixed,
but that doesn't mean 0.8.3 will not have lots of new features ;-)

If you don't care about the docs and want new ipython0, get it from
launchpad (bzr branch lp:ipython)

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


From gael.varoquaux at normalesup.org  Wed May 14 12:21:42 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 14 May 2008 18:21:42 +0200
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <cd7634ce0805131928g5acca684hf7bf2a814c1e4089@mail.gmail.com>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
	<cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>
	<20080511163147.GF28418@phare.normalesup.org>
	<cd7634ce0805131928g5acca684hf7bf2a814c1e4089@mail.gmail.com>
Message-ID: <20080514162142.GG8317@phare.normalesup.org>

I understand your points. I do agree that finding an abstraction that can
be extended-enough to work for all UI concepts is hard. I think it is
doable, but please go ahead with your code. Ideas and vaporware should
never slow down the development of working code.

Ga?l

On Tue, May 13, 2008 at 07:28:01PM -0700, Barry Wark wrote:
> Although I agree with your premises (we want to avoid duplication of
> code between core/kernel and frontends), I've come to a different
> conclusion as I've worked on the Cocoa frontend. I'll share my
> alternative opinion here not to put yours down but to stimulate some
> discussion in the group...

> I feel that the InputStateManager as it's been outlined conflates two
> issues: handling user gestures and provided common functionality. I'll
> try to explain what I mean below.

> On Sun, May 11, 2008 at 9:31 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
> > On Thu, May 08, 2008 at 03:21:10PM -0700, Barry Wark wrote:
> >  > Glenn, would you or one of the other Twisted gurus help me understand
> >  > pyreadline is the appropriate place for integration with the Twisted
> >  > event loop in ipython1?

> >  I had a look at this problem a couple of month ago, and came to the
> >  conclusion the pyreadline was not suited for this, as it was not
> >  architectured for callback-driven mechanisms.

> >  I do believe there is a need for an abstraction of this kind to do
> >  impedance matching between user input, whether it be callback-driven or
> >  line-driven, which can be seen as a special case of callback-driven. We
> >  don't want functionality like testing whether a line is complete or
> >  dealing with history sitting in the front end as this code is not
> >  front-end-specific and we absolutely want to avoid repeating ourselves
> >  (in addition to really bad design from a CS point of view, this would
> >  most probably bring in inconsistent behavior between the different
> >  front-end. We don't want this code sitting in the engine or the
> >  controller as, first of all, we want to avoid extra round trips across
> >  the network, and, most important, sharing this information between
> >  different front ends (and thus users) would yield inconsistent behavior.

> But different frontends may _have_ very different behavior. For
> example, the behavior of a block-oriented (e.g. Mathematica's
> notebook) frontend is behavior than a line-oriented (e.g. terminal)
> frontend. For the block-oriented frontend, the builtin compile
> function is sufficient to determine if a block is executable. In
> addition, the expectation of users on different systems (e.g. OS X vs.
> Gnome vs. Windows) may be very different. To try to produce identical
> behavior across all frontends will frustrate everyone (ala Java).


> >  I have started something that we decided to call "InputStateManager", in
> >  the ipython1 code base. Its goal is to do exactly what you want: expose
> >  an abstraction layer above the controller, with an interface that can be
> >  used as callbacks in an event loop. This beast is currently very rough.
> >  It emerged organically when trying to adapt the ipython1 interpreter (I
> >  am not sure such a thing still exists) to the Wx frontend. It is not
> >  terribly well coded, and should be seen as a rough cut that is meant to
> >  be improved (I wouldn't feel sorry at all if not one line of this file
> >  was kept in the long run, I think only the interface is important, and
> >  it can still be improved). For me the guiding principle when working on
> >  the InputStateManager seems to be that if you use callbacks, you can fit
> >  you interface to any user-interaction paradigm.

> I think attempting to create our own UI event system (as
> InputStateManager is doing) is the wrong path. Matplotlib's multiple
> backends are a necessary evil (perhaps), but keeping them all in sync
> appears to be a huge (and somewhat unsuccesful) effort. Why not let
> frontend developers exploit the native event system. I think it's more
> useful for us to provide handlers for the actions the frontend might
> want to take (e.g. executing a block of code) rather than translate
> native events into our own event system. I've started this approach in
> the ipython1-cocoa branch in the frontend.frontendbase module.
> frontendbase provides common actions (e.g. check if a block is
> complete, execute a block, etc.) and provides hooks for implementers
> to override to e.g. display the result of an executed block.


> >  There still is a lot of work on the InputStateManager, and I won't be
> >  able to work on it before August (yes, that's long, sorry), but I don't
> >  regard this as my territory, and I'd be very happy if somebody hacks on
> >  it, especially since I believe different people hacking on it with
> >  different requirements will make the interface more general.

> >  Cheers,

> >  Ga?l


-- 
  Gael Varoquaux,
  Quantum degenerate gases group
  European Laboratory for Non-Linear Spectroscopy
    University of Florence, Polo Scientifico
    Via Nello Carrara 1, I-50019-Sesto-Fiorentino (Firenze) Italy
    Phone: ++ 390-55-457242145      Fax: ++ 390-55-4572451
  ++ and ++
  Groupe d'optique atomique,
  Laboratoire Charles Fabry de l'Institut d'Optique
    Campus Polytechnique, RD 128, 91127 Palaiseau cedex FRANCE
    Tel : 33 (0) 1 64 53 33 23 - Fax : 33 (0) 1 64 53 31 01
    Labs: 33 (0) 1 64 53 33 63 - 33 (0) 1 64 53 33 62



From ellisonbg.net at gmail.com  Thu May 15 18:46:22 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 15 May 2008 16:46:22 -0600
Subject: [IPython-dev] twisted process pool...
In-Reply-To: <cd7634ce0805131928g5acca684hf7bf2a814c1e4089@mail.gmail.com>
References: <1208741743.12070.76.camel@ghtmyth.hq.tarbox.org>
	<cd7634ce0805081521q429b41b1obd81bf2609222e45@mail.gmail.com>
	<20080511163147.GF28418@phare.normalesup.org>
	<cd7634ce0805131928g5acca684hf7bf2a814c1e4089@mail.gmail.com>
Message-ID: <6ce0ac130805151546p348c66d8u58020ef44141b2d7@mail.gmail.com>

> I think attempting to create our own UI event system (as
> InputStateManager is doing) is the wrong path. Matplotlib's multiple
> backends are a necessary evil (perhaps), but keeping them all in sync
> appears to be a huge (and somewhat unsuccesful) effort. Why not let
> frontend developers exploit the native event system.

I completely agree with this - especially because different UIs have
somewhat different models and capabilities.  I think this is a case
where less abstraction is better as the native event systems are
typically very well thought out.  You just don't get much by putting
another layer of abstraction in.

> I think it's more
> useful for us to provide handlers for the actions the frontend might
> want to take (e.g. executing a block of code) rather than translate
> native events into our own event system. I've started this approach in
> the ipython1-cocoa branch in the frontend.frontendbase module.
> frontendbase provides common actions (e.g. check if a block is
> complete, execute a block, etc.) and provides hooks for implementers
> to override to e.g. display the result of an executed block.

This is the way I have been thinking of the model.  The
core+fontendbase provide the classes+methods that the various UIs will
need to call to "make things happen".


From gael.varoquaux at normalesup.org  Fri May 16 16:29:53 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 16 May 2008 22:29:53 +0200
Subject: [IPython-dev] Offline for three weeks
Message-ID: <20080516202952.GA3535@phare.normalesup.org>

Hi all,

This is just a quick message to say that I will be offline for three
weeks starting anytime soon. I am taking holidays travelling in central
Asia (Uzbekistan, Kyrgyzstan) before I switch jobs.

I don't think I am really needed badly for any project, so I probably
won't be missed. I quake at the thought of the size of my mailbox when I
come back...

Ga?l


From ondrej at certik.cz  Mon May 19 10:35:49 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 19 May 2008 16:35:49 +0200
Subject: [IPython-dev] online sympy shell at live.sympy.org
Message-ID: <85b5c3130805190735h4a13c4c1g8a211aba7cefa524@mail.gmail.com>

Hi,

I've setup:

http://live.sympy.org/

which is a python shell (see the link in the app for sources) and I've
included a sympy module in it. Sample session:

>>> from sympy.interactive import *
>>> integrate(1/(x**3+1), x)
(1/3)*log(1 + x) + (-1/6 - 1/6*I*3**(1/2))*log(-1/2 + x -
1/2*I*3**(1/2)) + (-1/6 + (1/6)*I*3**(1/2))*log(-1/2 + x +
(1/2)*I*3**(1/2))
>>> sin(x).series(x, 0, 5)
x - 1/6*x**3 + O(x**5)


The thing is running on the google app engine (thanks Harald Schilly
for the account).

Anyone interested in improving it? I'll create him an access to the
app engine for this app. Having something like ipython would be nice.
Also the pretty printing is a little broken, e.g.:

>>> pretty_print(1/(x+1))
1
-----
1 + x
>>> pretty_print(Integral(1/(x+1), x))
/
 |
 |   1
 | ----- dx
 | 1 + x
 |
/

i.e. the first line is left stripped. But otherwise it seems to work
very nice. CCing to ipython-dev, as an argument for having ipython
pure python only (otherwise it won't run on google app engine). :)

Ondrej


From ellisonbg.net at gmail.com  Mon May 19 12:36:43 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Mon, 19 May 2008 10:36:43 -0600
Subject: [IPython-dev] online sympy shell at live.sympy.org
In-Reply-To: <85b5c3130805190735h4a13c4c1g8a211aba7cefa524@mail.gmail.com>
References: <85b5c3130805190735h4a13c4c1g8a211aba7cefa524@mail.gmail.com>
Message-ID: <6ce0ac130805190936hde9cc46kfd47b13aa457055d@mail.gmail.com>

On Mon, May 19, 2008 at 8:35 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> Hi,
>
> I've setup:
>
> http://live.sympy.org/
>
> which is a python shell (see the link in the app for sources) and I've
> included a sympy module in it. Sample session:
>
>>>> from sympy.interactive import *
>>>> integrate(1/(x**3+1), x)
> (1/3)*log(1 + x) + (-1/6 - 1/6*I*3**(1/2))*log(-1/2 + x -
> 1/2*I*3**(1/2)) + (-1/6 + (1/6)*I*3**(1/2))*log(-1/2 + x +
> (1/2)*I*3**(1/2))
>>>> sin(x).series(x, 0, 5)
> x - 1/6*x**3 + O(x**5)
>
>
> The thing is running on the google app engine (thanks Harald Schilly
> for the account).
>
> Anyone interested in improving it? I'll create him an access to the
> app engine for this app. Having something like ipython would be nice.
> Also the pretty printing is a little broken, e.g.:
>
>>>> pretty_print(1/(x+1))
> 1
> -----
> 1 + x
>>>> pretty_print(Integral(1/(x+1), x))
> /
>  |
>  |   1
>  | ----- dx
>  | 1 + x
>  |
> /
>
> i.e. the first line is left stripped. But otherwise it seems to work
> very nice. CCing to ipython-dev, as an argument for having ipython
> pure python only (otherwise it won't run on google app engine). :)

Very nice!

The google app engine is definitely a target for ipython - don't
worry, the core of IPython will always remain pure python!

Brian

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


From ondrej at certik.cz  Mon May 19 13:05:46 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 19 May 2008 19:05:46 +0200
Subject: [IPython-dev] online sympy shell at live.sympy.org
In-Reply-To: <6ce0ac130805190936hde9cc46kfd47b13aa457055d@mail.gmail.com>
References: <85b5c3130805190735h4a13c4c1g8a211aba7cefa524@mail.gmail.com>
	<6ce0ac130805190936hde9cc46kfd47b13aa457055d@mail.gmail.com>
Message-ID: <85b5c3130805191005y30de69f1g3f7f90d37088ced3@mail.gmail.com>

On Mon, May 19, 2008 at 6:36 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> On Mon, May 19, 2008 at 8:35 AM, Ondrej Certik <ondrej at certik.cz> wrote:
[...]
>> i.e. the first line is left stripped. But otherwise it seems to work
>> very nice. CCing to ipython-dev, as an argument for having ipython
>> pure python only (otherwise it won't run on google app engine). :)
>
> Very nice!
>
> The google app engine is definitely a target for ipython - don't
> worry, the core of IPython will always remain pure python!
>
> Brian

Excellent. That would create an excellent platform for simple
experiments, or just when showing something to someone, like to our
bosses, so that he doesn't have to install a thing, especially on
windows. :) Something like sagenb.org, but much faster (=more
responsive) and not requiring a login, all of which should (could) be
possible on the app engine.

Do you have any time estimates when something will be usable? I think
the goal on Sage Days 8 was to have something ready by the same time
next year, right? Unfortunately, I don't have time to help much,
unless it's ready to do the 90% of things that I want, then I could
help with the rest 10%.

Ondrej


From fperez.net at gmail.com  Thu May 22 19:04:24 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 May 2008 16:04:24 -0700
Subject: [IPython-dev] Python for sys admin book - with IPython chapter
Message-ID: <db6b5ecc0805221604n4ae3dba0t34dc4ddcbc83c1c3@mail.gmail.com>

Hi all,


I just wanted to provide a link to a new book about using Python for
*nix system administration that was just completed by Jeremy Jones and
Noah Gift (both list regulars):

http://www.oreilly.com/catalog/9780596515829/

http://www.amazon.com/Python-Unix-Linux-Systems-Administration/dp/0596515820

It's still a few months away in print form, but some of you may want
to put it on your gift list :)

The reason this post is relevant is because Jeremy and Noah were nice
enough to write a long, detailed chapter about IPython for the book!
Both Ville and I provided them with feedback, and I'm very happy to
see two of our users find so much use out of the project.   I actually
learned a thing or two about ipython from their book :)

So thanks to both authors for including ipython in their book, and I
hope it's very successful.  I can certainly vouch for the fact that I
only write shell scripts these days when the script is nothing more
than a linear sequence of simple system calls.  For anything more
complicated I immediately switch to Python, so I think this is an area
where many will find useful knowledge in such a book.

Cheers,

f


From ondrej at certik.cz  Sat May 24 04:50:48 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Sat, 24 May 2008 10:50:48 +0200
Subject: [IPython-dev] ipython on google app engine
Message-ID: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>

Hi,

I'd love to use ipython on the google app engine. Currently our shell
looks like this:

http://live.sympy.org/

But I just prefer the ipython style. What I use/like on ipython is just:

1) the look and feel (lines starting with [1] etc.)
2) tab completion
3) ? and ??
4) inteligent up/down arrows history browsing

and I think that's all (sometimes I use some other features, but very
rarely). So when thinking about it again,

1) should be easy to fix, or at least come to a very close look & feel,
2) This will be hard, as it will require an interaction between the
webbrowser and the server. We may learn from Sage, ipython1 or
http://knoboo.com/
3) this should be easy, it will simply copy the command to the server,
and in python we'll parse it and return some help
4) will have to be implemented in javascript, but I could also live
without it quite well,

Note, that the requirement is that it runs on the google app server.


What do you think? How does this fit into the ipython1 model? I'd like
to have something now, but also I'd prefer to work on one thing
ipython1, instead of doing things on my own. Also I probably won't
have much time either. But my motivation to run something like
ipython+sympy on google app engine is also big. :)

Ondrej


From vivainio at gmail.com  Sat May 24 05:16:52 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 24 May 2008 12:16:52 +0300
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
Message-ID: <46cb515a0805240216l54aa81bfyfa7653a4c8d2d67b@mail.gmail.com>

On Sat, May 24, 2008 at 11:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:

> 1) the look and feel (lines starting with [1] etc.)
> 2) tab completion
> 3) ? and ??
> 4) inteligent up/down arrows history browsing
>

> 1) should be easy to fix, or at least come to a very close look & feel,
> 2) This will be hard, as it will require an interaction between the
> webbrowser and the server. We may learn from Sage, ipython1 or
> http://knoboo.com/

It should not be much harder than ?. You just pass the whole statement
to server, just as you would with shift+enter, and it returns a list
of completions. After that, the UI displays the previous command, and
shows the completions in a javascript popup.

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


From ondrej at certik.cz  Sat May 24 06:08:42 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Sat, 24 May 2008 12:08:42 +0200
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <46cb515a0805240216l54aa81bfyfa7653a4c8d2d67b@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<46cb515a0805240216l54aa81bfyfa7653a4c8d2d67b@mail.gmail.com>
Message-ID: <85b5c3130805240308k3191f047w8eb8afc7e4278531@mail.gmail.com>

On Sat, May 24, 2008 at 11:16 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Sat, May 24, 2008 at 11:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>
>> 1) the look and feel (lines starting with [1] etc.)
>> 2) tab completion
>> 3) ? and ??
>> 4) inteligent up/down arrows history browsing
>>
>
>> 1) should be easy to fix, or at least come to a very close look & feel,
>> 2) This will be hard, as it will require an interaction between the
>> webbrowser and the server. We may learn from Sage, ipython1 or
>> http://knoboo.com/
>
> It should not be much harder than ?. You just pass the whole statement
> to server, just as you would with shift+enter, and it returns a list
> of completions. After that, the UI displays the previous command, and
> shows the completions in a javascript popup.

Ah, thanks for the tip. So in this case I'll give it a try soon.

Ondrej


From barrywark at gmail.com  Sun May 25 12:49:03 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 25 May 2008 09:49:03 -0700
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
Message-ID: <cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>

On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> Hi,
>
> I'd love to use ipython on the google app engine. Currently our shell
> looks like this:
>
> http://live.sympy.org/
>
> But I just prefer the ipython style. What I use/like on ipython is just:
>
> 1) the look and feel (lines starting with [1] etc.)
> 2) tab completion
> 3) ? and ??
> 4) inteligent up/down arrows history browsing
>
> and I think that's all (sometimes I use some other features, but very
> rarely). So when thinking about it again,
>
> 1) should be easy to fix, or at least come to a very close look & feel,
> 2) This will be hard, as it will require an interaction between the
> webbrowser and the server. We may learn from Sage, ipython1 or
> http://knoboo.com/

It's my understanding that the current plan is for tab completion to
be handled in the frontend, not at the engine level in ipython1.
Mapping the ipython1 model directly to this situation, the tab
completion would happen in the browser. Since this is a bit
impractical, I'd suggest Ville's solution. The nature of the AppEngine
will mitigate the risk that the server is slow to respond to the tab
completion request (a possiblity in the ipython1 model if the
controller or engine handled the completion request).

> 3) this should be easy, it will simply copy the command to the server,
> and in python we'll parse it and return some help
> 4) will have to be implemented in javascript, but I could also live
> without it quite well,
>
> Note, that the requirement is that it runs on the google app server.
>
>
> What do you think? How does this fit into the ipython1 model? I'd like
> to have something now, but also I'd prefer to work on one thing
> ipython1, instead of doing things on my own. Also I probably won't
> have much time either. But my motivation to run something like
> ipython+sympy on google app engine is also big. :)
>
> Ondrej
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Tue May 27 18:14:57 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 27 May 2008 16:14:57 -0600
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
Message-ID: <6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>

My picture is this (as far as tab completion):

1) The frontend has to handle the event (pressing of TAB).

2) Upon TAB being pressed, the frontend will dispatch the request to a
number of different methods.  It would first see if it (the frontend)
could complete it.  But that is unlikely as the frontend wont' have
the user's namespace.  If it can't complete it, it will ask the
backend to do the completion.  Even that might fail if the backend is
busy though.

But the important point is that for anything that requires
introspecting the users namespace, the backend has to do that as the
frontend doesn't have the required info.

so, I guess I would say that both the frontend and backend work
together to do the tab completion.

Brian


On Sun, May 25, 2008 at 10:49 AM, Barry Wark <barrywark at gmail.com> wrote:
> On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>> Hi,
>>
>> I'd love to use ipython on the google app engine. Currently our shell
>> looks like this:
>>
>> http://live.sympy.org/
>>
>> But I just prefer the ipython style. What I use/like on ipython is just:
>>
>> 1) the look and feel (lines starting with [1] etc.)
>> 2) tab completion
>> 3) ? and ??
>> 4) inteligent up/down arrows history browsing
>>
>> and I think that's all (sometimes I use some other features, but very
>> rarely). So when thinking about it again,
>>
>> 1) should be easy to fix, or at least come to a very close look & feel,
>> 2) This will be hard, as it will require an interaction between the
>> webbrowser and the server. We may learn from Sage, ipython1 or
>> http://knoboo.com/
>
> It's my understanding that the current plan is for tab completion to
> be handled in the frontend, not at the engine level in ipython1.
> Mapping the ipython1 model directly to this situation, the tab
> completion would happen in the browser. Since this is a bit
> impractical, I'd suggest Ville's solution. The nature of the AppEngine
> will mitigate the risk that the server is slow to respond to the tab
> completion request (a possiblity in the ipython1 model if the
> controller or engine handled the completion request).
>
>> 3) this should be easy, it will simply copy the command to the server,
>> and in python we'll parse it and return some help
>> 4) will have to be implemented in javascript, but I could also live
>> without it quite well,
>>
>> Note, that the requirement is that it runs on the google app server.
>>
>>
>> What do you think? How does this fit into the ipython1 model? I'd like
>> to have something now, but also I'd prefer to work on one thing
>> ipython1, instead of doing things on my own. Also I probably won't
>> have much time either. But my motivation to run something like
>> ipython+sympy on google app engine is also big. :)
>>
>> Ondrej
>> _______________________________________________
>> 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 barrywark at gmail.com  Wed May 28 02:11:03 2008
From: barrywark at gmail.com (Barry Wark)
Date: Tue, 27 May 2008 23:11:03 -0700
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
	<6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
Message-ID: <cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>

On Tue, May 27, 2008 at 3:14 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> My picture is this (as far as tab completion):
>
> 1) The frontend has to handle the event (pressing of TAB).
>
> 2) Upon TAB being pressed, the frontend will dispatch the request to a
> number of different methods.  It would first see if it (the frontend)
> could complete it.  But that is unlikely as the frontend wont' have
> the user's namespace.  If it can't complete it, it will ask the
> backend to do the completion.  Even that might fail if the backend is
> busy though.
>
> But the important point is that for anything that requires
> introspecting the users namespace, the backend has to do that as the
> frontend doesn't have the required info.

One of the things that's come up as I'm (very slowly) working on the
cocoa frontend is that implementing something like Matlab's workspace
(i.e. user namespace) browser requires that the frontend query the
engine for the user namespace keys (and their values) after each
operation that might affect the namespace. So, could the engineservice
provide some hints about what keys in the user namespace were
altered/added/removed as a result of execution of a block? Either way,
if the frontend maintains this (flat) local copy of the user
namespace, than many completions could be accomplished locally.

>
> so, I guess I would say that both the frontend and backend work
> together to do the tab completion.
>
> Brian
>
>
> On Sun, May 25, 2008 at 10:49 AM, Barry Wark <barrywark at gmail.com> wrote:
>> On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>>> Hi,
>>>
>>> I'd love to use ipython on the google app engine. Currently our shell
>>> looks like this:
>>>
>>> http://live.sympy.org/
>>>
>>> But I just prefer the ipython style. What I use/like on ipython is just:
>>>
>>> 1) the look and feel (lines starting with [1] etc.)
>>> 2) tab completion
>>> 3) ? and ??
>>> 4) inteligent up/down arrows history browsing
>>>
>>> and I think that's all (sometimes I use some other features, but very
>>> rarely). So when thinking about it again,
>>>
>>> 1) should be easy to fix, or at least come to a very close look & feel,
>>> 2) This will be hard, as it will require an interaction between the
>>> webbrowser and the server. We may learn from Sage, ipython1 or
>>> http://knoboo.com/
>>
>> It's my understanding that the current plan is for tab completion to
>> be handled in the frontend, not at the engine level in ipython1.
>> Mapping the ipython1 model directly to this situation, the tab
>> completion would happen in the browser. Since this is a bit
>> impractical, I'd suggest Ville's solution. The nature of the AppEngine
>> will mitigate the risk that the server is slow to respond to the tab
>> completion request (a possiblity in the ipython1 model if the
>> controller or engine handled the completion request).
>>
>>> 3) this should be easy, it will simply copy the command to the server,
>>> and in python we'll parse it and return some help
>>> 4) will have to be implemented in javascript, but I could also live
>>> without it quite well,
>>>
>>> Note, that the requirement is that it runs on the google app server.
>>>
>>>
>>> What do you think? How does this fit into the ipython1 model? I'd like
>>> to have something now, but also I'd prefer to work on one thing
>>> ipython1, instead of doing things on my own. Also I probably won't
>>> have much time either. But my motivation to run something like
>>> ipython+sympy on google app engine is also big. :)
>>>
>>> Ondrej
>>> _______________________________________________
>>> 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  Wed May 28 03:54:50 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 28 May 2008 10:54:50 +0300
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
	<6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
	<cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
Message-ID: <46cb515a0805280054k4892eef7uab7cc93915ad1e48@mail.gmail.com>

On Wed, May 28, 2008 at 9:11 AM, Barry Wark <barrywark at gmail.com> wrote:

> altered/added/removed as a result of execution of a block? Either way,
> if the frontend maintains this (flat) local copy of the user
> namespace, than many completions could be accomplished locally.

But is it really that important to accomplish completions locally? For
most LAN's, I doubt anyone will perceive the time it takes to
complete, and tab is pressed infrequently enough that it won't congest
the network.

Of course the engine could compress this by returning completion
"guides" like "all attributes of class Foo" as opposed to just
returning the list of strings, but without actually measuring the
performance of the stupid approach it might be a premature
optimization.

As far as object browser goes - I don't think there is any reliable
way to detect what data structures have changed, short of doing
infinitely deep scan. It would make sense to provide a list of
expressions (as opposed to objects) to watch and get callback for
changes in those (new_val != old_val), though - I planned something
like that for ipython0 as well (as an extension that just uses
pre_prompt_hook), but it never happened.

E.g. watch(my_cb,
  ['foo','mylist', 'obj.observers'])

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


From ellisonbg.net at gmail.com  Wed May 28 10:54:56 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 28 May 2008 08:54:56 -0600
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
	<6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
	<cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
Message-ID: <6ce0ac130805280754m51475f8ai39dec8e145fd385c@mail.gmail.com>

> One of the things that's come up as I'm (very slowly) working on the
> cocoa frontend is that implementing something like Matlab's workspace
> (i.e. user namespace) browser requires that the frontend query the
> engine for the user namespace keys (and their values) after each
> operation that might affect the namespace. So, could the engineservice
> provide some hints about what keys in the user namespace were
> altered/added/removed as a result of execution of a block? Either way,
> if the frontend maintains this (flat) local copy of the user
> namespace, than many completions could be accomplished locally.

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:

1) Have an interface that allows the user to specify which variables
to monitor/browse in the frontend.

or

2) For in process engines, it really won't be a problem to get the
keys/values each time.

3) For an out of process engine, it is a bad idea to bring back all
the keys+values no matter how you approach it.  The chances for a user
to unknowingly create a bunch of large objects and bring the system to
a halt is too great.

4) A compromise, would be to bring back the values for only simple
scalar types (ints, floats, str?) and bring back the repr of all other
objects.  Then you could provide an interface to enable "actually
bring back the value of this object" for given keys.  This is probably
the best of both worlds.

>>
>> so, I guess I would say that both the frontend and backend work
>> together to do the tab completion.
>>
>> Brian
>>
>>
>> On Sun, May 25, 2008 at 10:49 AM, Barry Wark <barrywark at gmail.com> wrote:
>>> On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>>>> Hi,
>>>>
>>>> I'd love to use ipython on the google app engine. Currently our shell
>>>> looks like this:
>>>>
>>>> http://live.sympy.org/
>>>>
>>>> But I just prefer the ipython style. What I use/like on ipython is just:
>>>>
>>>> 1) the look and feel (lines starting with [1] etc.)
>>>> 2) tab completion
>>>> 3) ? and ??
>>>> 4) inteligent up/down arrows history browsing
>>>>
>>>> and I think that's all (sometimes I use some other features, but very
>>>> rarely). So when thinking about it again,
>>>>
>>>> 1) should be easy to fix, or at least come to a very close look & feel,
>>>> 2) This will be hard, as it will require an interaction between the
>>>> webbrowser and the server. We may learn from Sage, ipython1 or
>>>> http://knoboo.com/
>>>
>>> It's my understanding that the current plan is for tab completion to
>>> be handled in the frontend, not at the engine level in ipython1.
>>> Mapping the ipython1 model directly to this situation, the tab
>>> completion would happen in the browser. Since this is a bit
>>> impractical, I'd suggest Ville's solution. The nature of the AppEngine
>>> will mitigate the risk that the server is slow to respond to the tab
>>> completion request (a possiblity in the ipython1 model if the
>>> controller or engine handled the completion request).
>>>
>>>> 3) this should be easy, it will simply copy the command to the server,
>>>> and in python we'll parse it and return some help
>>>> 4) will have to be implemented in javascript, but I could also live
>>>> without it quite well,
>>>>
>>>> Note, that the requirement is that it runs on the google app server.
>>>>
>>>>
>>>> What do you think? How does this fit into the ipython1 model? I'd like
>>>> to have something now, but also I'd prefer to work on one thing
>>>> ipython1, instead of doing things on my own. Also I probably won't
>>>> have much time either. But my motivation to run something like
>>>> ipython+sympy on google app engine is also big. :)
>>>>
>>>> Ondrej
>>>> _______________________________________________
>>>> 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  Wed May 28 23:26:50 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 28 May 2008 20:26:50 -0700
Subject: [IPython-dev] 0.8.3 ready
Message-ID: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>

Hi all,

I've finished some last-minute cleanup for 0.8.3 and the files are up
at the usual places:

- http://ipython.scipy.org/dist/
- PyPI registered for easy_install use.

I'll leave it to Ville to provide us with full announcement, since he
did the lion's share of the work and is much more up to speed than I
on the details (this message is not going to ip-user).  If anyone here
catches a last-minute brown-paper bug we might have missed, please
pull on the red handle immediately before the public gets hurt.

Cheers,

f

ps - thanks to all who contributed!  I tried putting in names in the
changelog for all patches/ideas when I was touching the code, but
that's less and less these days.  I'd like to encourage others with
push rights to do the same and always remember to properly credit our
users who send contributions.


From vivainio at gmail.com  Thu May 29 02:36:45 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 29 May 2008 09:36:45 +0300
Subject: [IPython-dev] 0.8.3 ready
In-Reply-To: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>
References: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>
Message-ID: <46cb515a0805282336m36066d57ta9646b0cd1a48976@mail.gmail.com>

On Thu, May 29, 2008 at 6:26 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> ps - thanks to all who contributed!  I tried putting in names in the
> changelog for all patches/ideas when I was touching the code, but
> that's less and less these days.  I'd like to encourage others with
> push rights to do the same and always remember to properly credit our
> users who send contributions.

And if you are providing contributions via Trac tickets, ensure that
the ticket has your full name / address somewhere!

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


From fperez.net at gmail.com  Thu May 29 02:47:35 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 28 May 2008 23:47:35 -0700
Subject: [IPython-dev] 0.8.3 ready
In-Reply-To: <46cb515a0805282336m36066d57ta9646b0cd1a48976@mail.gmail.com>
References: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>
	<46cb515a0805282336m36066d57ta9646b0cd1a48976@mail.gmail.com>
Message-ID: <db6b5ecc0805282347t2d7cd1ebn84dd61f49a4e2e0c@mail.gmail.com>

On Wed, May 28, 2008 at 11:36 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Thu, May 29, 2008 at 6:26 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> ps - thanks to all who contributed!  I tried putting in names in the
>> changelog for all patches/ideas when I was touching the code, but
>> that's less and less these days.  I'd like to encourage others with
>> push rights to do the same and always remember to properly credit our
>> users who send contributions.
>
> And if you are providing contributions via Trac tickets, ensure that
> the ticket has your full name / address somewhere!

We should probably take the post 0.8.3 days as an opportunity to clean
up things a bit, finalize the move to bzr, etc.  That would probably
entail changing the Trac front page to suggest all new bug reports go
to launchpad...

After you have time to check everything (in particular the win32
installer, my vmware is borked and I have no way to run it now) and
put out the release announcement/notes, perhaps we can hash these
things a bit.  Both ip0 and ip1 seem happy on launchpad after this
experiment, so I think we can see what's needed to finalize the
transition next week.

Cheers,

f


From vivainio at gmail.com  Thu May 29 03:30:51 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 29 May 2008 10:30:51 +0300
Subject: [IPython-dev] 0.8.3 ready
In-Reply-To: <db6b5ecc0805282347t2d7cd1ebn84dd61f49a4e2e0c@mail.gmail.com>
References: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>
	<46cb515a0805282336m36066d57ta9646b0cd1a48976@mail.gmail.com>
	<db6b5ecc0805282347t2d7cd1ebn84dd61f49a4e2e0c@mail.gmail.com>
Message-ID: <46cb515a0805290030v67384262l1afa5d8c5ca510e4@mail.gmail.com>

On Thu, May 29, 2008 at 9:47 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> things a bit.  Both ip0 and ip1 seem happy on launchpad after this
> experiment, so I think we can see what's needed to finalize the
> transition next week.

It would also be nice to see pyreadline on launchpad.

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


From fperez.net at gmail.com  Thu May 29 03:33:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 29 May 2008 00:33:20 -0700
Subject: [IPython-dev] 0.8.3 ready
In-Reply-To: <46cb515a0805290030v67384262l1afa5d8c5ca510e4@mail.gmail.com>
References: <db6b5ecc0805282026o516c0e7by7689ab3b5547915f@mail.gmail.com>
	<46cb515a0805282336m36066d57ta9646b0cd1a48976@mail.gmail.com>
	<db6b5ecc0805282347t2d7cd1ebn84dd61f49a4e2e0c@mail.gmail.com>
	<46cb515a0805290030v67384262l1afa5d8c5ca510e4@mail.gmail.com>
Message-ID: <db6b5ecc0805290033y6ee62526o96eba6fefff17fbf@mail.gmail.com>

On Thu, May 29, 2008 at 12:30 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Thu, May 29, 2008 at 9:47 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> things a bit.  Both ip0 and ip1 seem happy on launchpad after this
>> experiment, so I think we can see what's needed to finalize the
>> transition next week.
>
> It would also be nice to see pyreadline on launchpad.

I'm all for that, but I'll leave it to Jorgen to make the move.  If he
needs anything from me in terms of direct access to the svn repo for a
history dump, I'm happy to help.

Cheers,

f


From vivainio at gmail.com  Thu May 29 08:30:59 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 29 May 2008 15:30:59 +0300
Subject: [IPython-dev] Launchpad broken
Message-ID: <46cb515a0805290530j57997a43k21a59046c68e5e17@mail.gmail.com>

Apparently, launchpad made an "upgrade" that broke the push url
display on the branch page.

For reference, here is the push stanza for stable-dev:

bzr push bzr+ssh://villemvainio at bazaar.launchpad.net/%7Eipython/ipython/stable-dev/

(obviously you need to change villemvainio to your own launchpad login).

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


From anand.prabhakar.patil at gmail.com  Thu May 29 10:56:38 2008
From: anand.prabhakar.patil at gmail.com (Anand Patil)
Date: Thu, 29 May 2008 15:56:38 +0100
Subject: [IPython-dev] Leopard readline egg build error
Message-ID: <2DC4C915-E353-4A19-AA25-222426F1B649@gmail.com>

Hi all,

I'm following the instructions here

http://ipython.scipy.org/moin/InstallationOSXLeopard

with a fresh Leopard installation and getting the following error.  
Thanks in advance for any help,

Anand




sihpc03:~ anand$ sudo easy_install -f http://ipython.scipy.org/dist/  
readline
Searching for readline
Reading http://ipython.scipy.org/dist/
Best match: readline 2.5.1
Downloading http://ipython.scipy.org/dist/readline-2.5.1.tar.gz
Processing readline-2.5.1.tar.gz
Running readline-2.5.1/setup.py -q bdist_egg --dist-dir /tmp/ 
easy_install-HgeBQw/readline-2.5.1/egg-dist-tmp-F7vBk3

============ Building the readline library ============

readline-5.2/
readline-5.2/doc/
readline-5.2/doc/Makefile.in
readline-5.2/doc/texinfo.tex
readline-5.2/doc/version.texi
readline-5.2/doc/fdl.texi
readline-5.2/doc/rlman.texi
readline-5.2/doc/rltech.texi
readline-5.2/doc/rluser.texi
readline-5.2/doc/rluserman.texi
readline-5.2/doc/history.texi
readline-5.2/doc/hstech.texi
readline-5.2/doc/hsuser.texi
readline-5.2/doc/readline.3
readline-5.2/doc/history.3
readline-5.2/doc/texi2dvi
readline-5.2/doc/texi2html
readline-5.2/doc/readline.ps
readline-5.2/doc/history.ps
readline-5.2/doc/rluserman.ps
readline-5.2/doc/readline.dvi
readline-5.2/doc/history.dvi
readline-5.2/doc/rluserman.dvi
readline-5.2/doc/readline.info
readline-5.2/doc/history.info
readline-5.2/doc/rluserman.info
readline-5.2/doc/readline.html
readline-5.2/doc/history.html
readline-5.2/doc/rluserman.html
readline-5.2/doc/readline.0
readline-5.2/doc/history.0
readline-5.2/doc/readline_3.ps
readline-5.2/doc/history_3.ps
readline-5.2/doc/history.pdf
readline-5.2/doc/readline.pdf
readline-5.2/doc/rluserman.pdf
readline-5.2/examples/
readline-5.2/examples/rlfe/
readline-5.2/examples/rlfe/ChangeLog
readline-5.2/examples/rlfe/Makefile.in
readline-5.2/examples/rlfe/README
readline-5.2/examples/rlfe/config.h.in
readline-5.2/examples/rlfe/configure
readline-5.2/examples/rlfe/configure.in
readline-5.2/examples/rlfe/extern.h
readline-5.2/examples/rlfe/os.h
readline-5.2/examples/rlfe/pty.c
readline-5.2/examples/rlfe/rlfe.c
readline-5.2/examples/rlfe/screen.h
readline-5.2/examples/Makefile.in
readline-5.2/examples/excallback.c
readline-5.2/examples/fileman.c
readline-5.2/examples/manexamp.c
readline-5.2/examples/readlinebuf.h
readline-5.2/examples/rl-fgets.c
readline-5.2/examples/rlcat.c
readline-5.2/examples/rltest.c
readline-5.2/examples/rl.c
readline-5.2/examples/rlptytest.c
readline-5.2/examples/rlversion.c
readline-5.2/examples/histexamp.c
readline-5.2/examples/Inputrc
readline-5.2/support/
readline-5.2/support/config.guess
readline-5.2/support/config.rpath
readline-5.2/support/config.sub
readline-5.2/support/install.sh
readline-5.2/support/mkdirs
readline-5.2/support/mkdist
readline-5.2/support/mkinstalldirs
readline-5.2/support/shobj-conf
readline-5.2/support/shlib-install
readline-5.2/support/wcwidth.c
readline-5.2/shlib/
readline-5.2/shlib/Makefile.in
readline-5.2/COPYING
readline-5.2/README
readline-5.2/MANIFEST
readline-5.2/INSTALL
readline-5.2/CHANGELOG
readline-5.2/CHANGES
readline-5.2/NEWS
readline-5.2/USAGE
readline-5.2/aclocal.m4
readline-5.2/config.h.in
readline-5.2/configure
readline-5.2/configure.in
readline-5.2/Makefile.in
readline-5.2/ansi_stdlib.h
readline-5.2/chardefs.h
readline-5.2/history.h
readline-5.2/histlib.h
readline-5.2/keymaps.h
readline-5.2/posixdir.h
readline-5.2/posixjmp.h
readline-5.2/readline.h
readline-5.2/posixstat.h
readline-5.2/rlconf.h
readline-5.2/rldefs.h
readline-5.2/rlmbutil.h
readline-5.2/rlprivate.h
readline-5.2/rlshell.h
readline-5.2/rlstdc.h
readline-5.2/rltty.h
readline-5.2/rltypedefs.h
readline-5.2/rlwinsize.h
readline-5.2/tcap.h
readline-5.2/tilde.h
readline-5.2/xmalloc.h
readline-5.2/bind.c
readline-5.2/callback.c
readline-5.2/compat.c
readline-5.2/complete.c
readline-5.2/display.c
readline-5.2/emacs_keymap.c
readline-5.2/funmap.c
readline-5.2/input.c
readline-5.2/isearch.c
readline-5.2/keymaps.c
readline-5.2/kill.c
readline-5.2/macro.c
readline-5.2/mbutil.c
readline-5.2/misc.c
readline-5.2/nls.c
readline-5.2/parens.c
readline-5.2/readline.c
readline-5.2/rltty.c
readline-5.2/savestring.c
readline-5.2/search.c
readline-5.2/shell.c
readline-5.2/signals.c
readline-5.2/terminal.c
readline-5.2/text.c
readline-5.2/tilde.c
readline-5.2/undo.c
readline-5.2/util.c
readline-5.2/vi_keymap.c
readline-5.2/vi_mode.c
readline-5.2/xmalloc.c
readline-5.2/history.c
readline-5.2/histexpand.c
readline-5.2/histfile.c
readline-5.2/histsearch.c
patching file display.c
patching file display.c
patching file display.c
patching file display.c
patching file complete.c
patching file input.c
patching file isearch.c
patching file misc.c
patching file readline.c
patching file text.c
patching file vi_mode.c
patching file display.c
patching file input.c
patching file display.c
patching file display.c
patching file display.c
Hunk #1 succeeded at 1623 (offset 4 lines).
patching file input.c
patching file support/shobj-conf
checking build system type... i386-apple-darwin9.2.1
checking host system type... i386-apple-darwin9.2.1

Beginning configuration for readline-5.2 for i386-apple-darwin9.2.1

checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether gcc needs -traditional... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for ar... ar
checking for ranlib... ranlib
checking for an ANSI C-conforming const... yes
checking for function prototypes... yes
checking whether char is unsigned... no
checking return type of signal handlers... void
checking for size_t... yes
checking for ssize_t... yes
checking for ANSI C header files... (cached) yes
checking whether stat file-mode macros are broken... no
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for fcntl... yes
checking for kill... yes
checking for lstat... yes
checking for memmove... yes
checking for putenv... yes
checking for select... yes
checking for setenv... yes
checking for setlocale... yes
checking for strcasecmp... yes
checking for strpbrk... yes
checking for tcgetattr... yes
checking for vsnprintf... yes
checking for isascii... yes
checking for isxdigit... yes
checking for getpwent... yes
checking for getpwnam... yes
checking for getpwuid... yes
checking for working strcoll... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for stdlib.h... (cached) yes
checking varargs.h usability... no
checking varargs.h presence... no
checking for varargs.h... no
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking for memory.h... (cached) yes
checking termcap.h usability... yes
checking termcap.h presence... yes
checking for termcap.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking termio.h usability... no
checking termio.h presence... no
checking for termio.h... no
checking sys/pte.h usability... no
checking sys/pte.h presence... no
checking for sys/pte.h... no
checking sys/stream.h usability... no
checking sys/stream.h presence... no
checking for sys/stream.h... no
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking for sys/ptem.h... no
checking for type of signal functions... posix
checking if signal handlers must be reinstalled when invoked... no
checking for presence of POSIX-style sigsetjmp/siglongjmp... present
checking for lstat... yes
checking whether or not strcoll and strcmp differ... no
checking whether the ctype macros accept non-ascii characters... yes
checking whether getpw functions are declared in pwd.h... yes
checking whether termios.h defines TIOCGWINSZ... yes
checking whether signal handlers are of type void... yes
checking for TIOCSTAT in sys/ioctl.h... yes
checking for FIONREAD in sys/ioctl.h... yes
checking for speed_t in sys/types.h... no
checking for struct winsize in sys/ioctl.h and termios.h... sys/ioctl.h
checking for struct dirent.d_ino... yes
checking for struct dirent.d_fileno... yes
checking for tgetent... no
checking for tgetent in -ltermcap... yes
checking which library has the termcap functions... using libtermcap
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking for mbsrtowcs... yes
checking for mbrlen... yes
checking for wcrtomb... yes
checking for wcscoll... yes
checking for wcsdup... no
checking for wcwidth... yes
checking for wctype... yes
checking whether mbrtowc and mbstate_t are properly declared... yes
checking for iswlower... yes
checking for iswupper... yes
checking for towlower... yes
checking for towupper... yes
checking for iswctype... yes
checking for nl_langinfo and CODESET... yes
checking for wchar_t in wchar.h... yes
checking for wctype_t in wctype.h... yes
checking for wint_t in wctype.h... yes
checking configuration for building shared libraries... supported
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating examples/Makefile
config.status: creating shlib/Makefile
config.status: creating config.h
config.status: executing default commands
rm -f readline.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 readline.c
rm -f vi_mode.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 vi_mode.c
rm -f funmap.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 funmap.c
rm -f keymaps.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 keymaps.c
rm -f parens.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 parens.c
rm -f search.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 search.c
rm -f rltty.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 rltty.c
rm -f complete.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 complete.c
rm -f bind.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 bind.c
bind.c: In function ?rl_function_of_keyseq?:
bind.c:704: warning: comparison is always true due to limited range of  
data type
bind.c: In function ?rl_function_of_keyseq?:
bind.c:704: warning: comparison is always true due to limited range of  
data type
bind.c: In function ?rl_function_of_keyseq?:
bind.c:704: warning: comparison is always true due to limited range of  
data type
bind.c: In function ?rl_function_of_keyseq?:
bind.c:704: warning: comparison is always true due to limited range of  
data type
rm -f isearch.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 isearch.c
rm -f display.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 display.c
display.c: In function ?rl_character_len?:
display.c:1961: warning: comparison is always true due to limited  
range of data type
display.c: In function ?rl_character_len?:
display.c:1961: warning: comparison is always true due to limited  
range of data type
display.c: In function ?rl_character_len?:
display.c:1961: warning: comparison is always true due to limited  
range of data type
display.c: In function ?rl_character_len?:
display.c:1961: warning: comparison is always true due to limited  
range of data type
rm -f signals.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 signals.c
rm -f util.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 util.c
rm -f kill.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 kill.c
rm -f undo.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 undo.c
rm -f macro.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 macro.c
rm -f input.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 input.c
rm -f callback.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 callback.c
rm -f terminal.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 terminal.c
rm -f text.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 text.c
rm -f nls.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 nls.c
rm -f misc.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 misc.c
rm -f compat.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 compat.c
rm -f xmalloc.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 xmalloc.c
rm -f history.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 history.c
rm -f histexpand.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 histexpand.c
rm -f histfile.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 histfile.c
rm -f histsearch.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 histsearch.c
rm -f shell.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 shell.c
rm -f mbutil.o
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 mbutil.c
rm -f tilde.o
gcc -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -DREADLINE_LIBRARY -c ./ 
tilde.c
rm -f libreadline.a
ar cr libreadline.a readline.o vi_mode.o funmap.o keymaps.o parens.o  
search.o rltty.o complete.o bind.o isearch.o display.o signals.o  
util.o kill.o undo.o macro.o input.o callback.o terminal.o text.o  
nls.o misc.o compat.o xmalloc.o history.o histexpand.o histfile.o  
histsearch.o shell.o mbutil.o tilde.o
test -n "ranlib" && ranlib libreadline.a
rm -f libhistory.a
ar cr libhistory.a history.o histexpand.o histfile.o histsearch.o  
shell.o mbutil.o xmalloc.o
test -n "ranlib" && ranlib libhistory.a
test -d shlib || mkdir shlib
( cd shlib ; make  all )
rm -f readline.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
readline.o ../readline.c
mv readline.o readline.so
rm -f vi_mode.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
vi_mode.o ../vi_mode.c
mv vi_mode.o vi_mode.so
rm -f funmap.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
funmap.o ../funmap.c
mv funmap.o funmap.so
rm -f keymaps.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
keymaps.o ../keymaps.c
mv keymaps.o keymaps.so
rm -f parens.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
parens.o ../parens.c
mv parens.o parens.so
rm -f search.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
search.o ../search.c
mv search.o search.so
rm -f rltty.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o rltty.o ../ 
rltty.c
mv rltty.o rltty.so
rm -f complete.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
complete.o ../complete.c
mv complete.o complete.so
rm -f bind.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o bind.o ../ 
bind.c
../bind.c: In function ?rl_function_of_keyseq?:
../bind.c:704: warning: comparison is always true due to limited range  
of data type
../bind.c: In function ?rl_function_of_keyseq?:
../bind.c:704: warning: comparison is always true due to limited range  
of data type
../bind.c: In function ?rl_function_of_keyseq?:
../bind.c:704: warning: comparison is always true due to limited range  
of data type
../bind.c: In function ?rl_function_of_keyseq?:
../bind.c:704: warning: comparison is always true due to limited range  
of data type
mv bind.o bind.so
rm -f isearch.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
isearch.o ../isearch.c
mv isearch.o isearch.so
rm -f display.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
display.o ../display.c
../display.c: In function ?rl_character_len?:
../display.c:1961: warning: comparison is always true due to limited  
range of data type
../display.c: In function ?rl_character_len?:
../display.c:1961: warning: comparison is always true due to limited  
range of data type
../display.c: In function ?rl_character_len?:
../display.c:1961: warning: comparison is always true due to limited  
range of data type
../display.c: In function ?rl_character_len?:
../display.c:1961: warning: comparison is always true due to limited  
range of data type
mv display.o display.so
rm -f signals.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
signals.o ../signals.c
mv signals.o signals.so
rm -f util.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o util.o ../ 
util.c
mv util.o util.so
rm -f kill.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o kill.o ../ 
kill.c
mv kill.o kill.so
rm -f undo.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o undo.o ../ 
undo.c
mv undo.o undo.so
rm -f macro.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o macro.o ../ 
macro.c
mv macro.o macro.so
rm -f input.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o input.o ../ 
input.c
mv input.o input.so
rm -f callback.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
callback.o ../callback.c
mv callback.o callback.so
rm -f terminal.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
terminal.o ../terminal.c
mv terminal.o terminal.so
rm -f text.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o text.o ../ 
text.c
mv text.o text.so
rm -f nls.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o nls.o ../ 
nls.c
mv nls.o nls.so
rm -f misc.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o misc.o ../ 
misc.c
mv misc.o misc.so
rm -f xmalloc.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
xmalloc.o ../xmalloc.c
mv xmalloc.o xmalloc.so
rm -f history.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
history.o ../history.c
mv history.o history.so
rm -f histexpand.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
histexpand.o ../histexpand.c
mv histexpand.o histexpand.so
rm -f histfile.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
histfile.o ../histfile.c
mv histfile.o histfile.so
rm -f histsearch.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
histsearch.o ../histsearch.c
mv histsearch.o histsearch.so
rm -f shell.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o shell.o ../ 
shell.c
mv shell.o shell.so
rm -f mbutil.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
mbutil.o ../mbutil.c
mv mbutil.o mbutil.so
rm -f tilde.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common - 
DREADLINE_LIBRARY -c -o tilde.o ../tilde.c
mv tilde.o tilde.so
rm -f compat.so
gcc -c -DHAVE_CONFIG_H   -DNEED_EXTERN_PC -I. -I.. -I.. - 
DRL_LIBRARY_VERSION='"5.2"' -isysroot /Developer/SDKs/MacOSX10.5.sdk - 
arch i386 -arch ppc -arch x86_64 -arch ppc64 -fno-common -o  
compat.o ../compat.c
mv compat.o compat.so
rm -f libreadline.5.2.dylib
MACOSX_DEPLOYMENT_TARGET=10.3 gcc -dynamiclib -dynamic -undefined  
dynamic_lookup -arch_only `/usr/bin/arch` -isysroot /Developer/SDKs/ 
MacOSX10.5.sdk -arch i386 -arch ppc -arch x86_64 -arch ppc64 - 
dynamiclib -arch_only `/usr/bin/arch` -install_name /usr/local/lib/ 
libreadline.5.2.dylib -current_version 5.2 -compatibility_version 5 -v  
-o libreadline.5.2.dylib readline.so vi_mode.so funmap.so keymaps.so  
parens.so search.so rltty.so complete.so bind.so isearch.so display.so  
signals.so util.so kill.so undo.so macro.so input.so callback.so  
terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so  
histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so - 
lncurses
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- 
host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
  /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -dylib - 
dylib_compatibility_version 5 -dylib_current_version 5.2 -arch  
i386Using built-in specs.
  -dylib_install_nameUsing built-in specs.
  /usr/local/lib/libreadline.5.2.dylib -dynamic -macosx_version_min  
10.3 -syslibroot /Developer/SDKs/MacOSX10.5.sdk -undefined  
dynamic_lookup -weak_reference_mismatches non-weak -undefined  
dynamic_lookup -o /var/tmp//ccsBtZ3N.out -ldylib1.o -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib/i686-apple-darwin9/4.0.1 -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/ 
lib/gcc/i686-apple-darwin9/4.0.1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/ 
lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple- 
darwin9/4.0.1/../../.. readline.so vi_mode.so funmap.so keymaps.so  
parens.so search.so rltty.so complete.so bind.so isearch.so display.so  
signals.so util.so kill.so undo.so macro.so input.so callback.so  
terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so  
histfile.so histsearch.so shell.soTarget: i686-apple-darwin9
  mbutil.soTarget: powerpc-apple-darwin9
  tilde.so compat.soConfigured with: /var/tmp/gcc/gcc-5465~16/src/ 
configure --disable-checking -enable-werror --prefix=/usr --mandir=/ 
share/man --enable-languages=c,objc,c++,obj-c++ --program-transform- 
name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0  
--with-slibdir=/usr/lib --build=i686-apple-darwin9 --enable-werror- 
always --program-prefix=powerpc-apple-darwin9- --host=i686-apple- 
darwin9 --target=powerpc-apple-darwin9
  -lncursesThread model: posix
  -final_outputConfigured with: /var/tmp/gcc/gcc-5465~16/src/configure  
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- 
enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] 
[^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with- 
slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with- 
tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
  libreadline.5.2.dylib -lgccgcc version 4.0.1 (Apple Inc. build 5465)
  -lSystemThread model: posix

gcc version 4.0.1 (Apple Inc. build 5465)
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --enable-werror-always --program- 
prefix=powerpc-apple-darwin9- --host=i686-apple-darwin9 -- 
target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
  /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/collect2 -dynamic - 
dylib -dylib_compatibility_version 5 -dylib_current_version 5.2 /usr/ 
libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -arch -dynamic ppc - 
dylib -dylib_install_name -dylib_compatibility_version 5 /usr/local/ 
lib/libreadline.5.2.dylib -dynamic -macosx_version_min 10.3 - 
dylib_current_version -syslibroot 5.2 /Developer/SDKs/MacOSX10.5.sdk - 
arch -undefined x86_64 dynamic_lookup -dylib_install_name /usr/local/ 
lib/libreadline.5.2.dylib -weak_reference_mismatches -dynamic non-weak  
-macosx_version_min -undefined 10.3 dynamic_lookup -syslibroot -o /var/ 
tmp//ccnPQh7W.out /Developer/SDKs/MacOSX10.5.sdk -undefined -ldylib1.o  
dynamic_lookup -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/powerpc-apple- 
darwin9/4.0.1 -weak_reference_mismatches -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib non-weak -L/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -undefined -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/../../../powerpc-apple-darwin9/4.0.1 dynamic_lookup -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/../../.. -o readline.so /var/tmp//ccvl46nw.out  
vi_mode.so -ldylib1.o funmap.so -L/Developer/SDKs/MacOSX10.5.sdk/usr/ 
lib/i686-apple-darwin9/4.0.1 keymaps.so -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib parens.so -L/usr/lib/gcc/i686-apple- 
darwin9/4.0.1/x86_64 /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ 
collect2 search.so -dynamic -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 - 
dylib -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64 rltty.so - 
dylib_compatibility_version -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 5  
complete.so -dylib_current_version bind.so 5.2 isearch.so -L/Developer/ 
SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686- 
apple-darwin9/4.0.1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686- 
apple-darwin9/4.0.1/../../.. readline.so -arch vi_mode.so ppc64  
funmap.so -dylib_install_name display.so /usr/local/lib/libreadline. 
5.2.dylib signals.so -dynamic util.so -macosx_version_min kill.so 10.3  
undo.so -syslibroot macro.so /Developer/SDKs/MacOSX10.5.sdk keymaps.so  
-undefined input.so parens.so dynamic_lookup search.so - 
weak_reference_mismatches callback.so non-weak terminal.so -undefined  
dynamic_lookup rltty.so complete.so text.so bind.so -o /var/tmp// 
ccY9dBNr.out isearch.so -ldylib1.o nls.so -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib/powerpc-apple-darwin9/4.0.1 misc.so -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib xmalloc.so -L/usr/lib/gcc/ 
powerpc-apple-darwin9/4.0.1/ppc64 display.so history.so -L/usr/lib/gcc/ 
powerpc-apple-darwin9/4.0.1 signals.so -L/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/ppc64 util.so -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1  
kill.so -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/../../../powerpc-apple-darwin9/4.0.1 undo.so -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/../../.. macro.so readline.so input.so vi_mode.so  
histexpand.so funmap.so histfile.so keymaps.so callback.so parens.so  
terminal.so histsearch.so text.so search.so nls.so shell.so rltty.so  
misc.so complete.so xmalloc.so bind.so history.so mbutil.so isearch.so  
tilde.so display.so compat.so histexpand.so signals.so -lncurses  
histfile.so util.so histsearch.so kill.so shell.so -final_output  
undo.so libreadline.5.2.dylib macro.so -lgcc mbutil.so input.so - 
lSystemStubs callback.so -lmx terminal.so -lSystem
  tilde.so text.so compat.so nls.so -lncurses misc.so -final_output  
xmalloc.so libreadline.5.2.dylib history.so -lgcc histexpand.so - 
lSystem histfile.so
  histsearch.so shell.so mbutil.so tilde.so compat.so -lncurses - 
final_output libreadline.5.2.dylib -lgcc -lSystemStubs -lSystem
lipo -create -o libreadline.5.2.dylib /var/tmp//ccsBtZ3N.out /var/tmp// 
ccnPQh7W.out /var/tmp//ccvl46nw.out /var/tmp//ccY9dBNr.out
rm -f libhistory.5.2.dylib
MACOSX_DEPLOYMENT_TARGET=10.3 gcc -dynamiclib -dynamic -undefined  
dynamic_lookup -arch_only `/usr/bin/arch` -isysroot /Developer/SDKs/ 
MacOSX10.5.sdk -arch i386 -arch ppc -arch x86_64 -arch ppc64 - 
dynamiclib -arch_only `/usr/bin/arch` -install_name /usr/local/lib/ 
libhistory.5.2.dylib -current_version 5.2 -compatibility_version 5 -v - 
o libhistory.5.2.dylib history.so histexpand.so histfile.so  
histsearch.so shell.so mbutil.so xmalloc.so -lncurses
Using built-in specs.
Using built-in specs.
Target: i686-apple-darwin9
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- 
host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --enable-werror-always --program- 
prefix=powerpc-apple-darwin9- --host=i686-apple-darwin9 -- 
target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
  /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -dylib - 
dylib_compatibility_version 5 -dylib_current_version 5.2 -arch i386 - 
dylib_install_name /usr/local/lib/libhistory.5.2.dylib -dynamic - 
macosx_version_min 10.3 -syslibroot /Developer/SDKs/MacOSX10.5.sdk - 
undefined dynamic_lookup -weak_reference_mismatches non-weak - 
undefined dynamic_lookup -o /var/tmp//ccRuPJQ0.out -ldylib1.o -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin9/4.0.1 -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib -L/usr/lib/gcc/i686-apple- 
darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/Developer/ 
SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686- 
apple-darwin9/4.0.1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686- 
apple-darwin9/4.0.1/../../.. history.so histexpand.so histfile.so  
histsearch.so shell.so mbutil.so xmalloc.so -lncurses -final_output  
libhistory.5.2.dylib -lgcc -lSystem
  /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/collect2 -dynamic - 
dylib -dylib_compatibility_version 5 -dylib_current_version 5.2 -arch  
ppc -dylib_install_name /usr/local/lib/libhistory.5.2.dylib -dynamic - 
macosx_version_min 10.3 -syslibroot /Developer/SDKs/MacOSX10.5.sdk - 
undefined dynamic_lookup -weak_reference_mismatches non-weak - 
undefined dynamic_lookup -o /var/tmp//cc5I5HDI.out -ldylib1.o -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/powerpc-apple-darwin9/4.0.1 -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib -L/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -L/Developer/ 
SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../../ 
powerpc-apple-darwin9/4.0.1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/ 
gcc/powerpc-apple-darwin9/4.0.1/../../.. history.so histexpand.so  
histfile.so histsearch.so shell.so mbutil.so xmalloc.so -lncurses - 
final_output libhistory.5.2.dylib -lgcc -lSystemStubs -lmx -lSystem
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --enable-werror-always --program- 
prefix=powerpc-apple-darwin9- --host=i686-apple-darwin9 -- 
target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
Using built-in specs.
  /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/collect2 -dynamic - 
dylib -dylib_compatibility_version 5 -dylib_current_version 5.2 -arch  
ppc64 -dylib_install_name /usr/local/lib/libhistory.5.2.dylib -dynamic  
-macosx_version_min 10.3 -syslibroot /Developer/SDKs/MacOSX10.5.sdk - 
undefined dynamic_lookup -weak_reference_mismatches non-weak - 
undefined dynamic_lookup -o /var/tmp//ccLg3kpV.out -ldylib1.o -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/powerpc-apple-darwin9/4.0.1 -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib -L/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/ppc64 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -L/usr/ 
lib/gcc/powerpc-apple-darwin9/4.0.1/ppc64 -L/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- 
checking -enable-werror --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ 
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ 
lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- 
host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
  -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple- 
darwin9/4.0.1/../../../powerpc-apple-darwin9/4.0.1 -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../..  
history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so  
xmalloc.so -lncurses -final_output libhistory.5.2.dylib -lgcc - 
lSystemStubs -lSystem
  /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -dylib - 
dylib_compatibility_version 5 -dylib_current_version 5.2 -arch x86_64 - 
dylib_install_name /usr/local/lib/libhistory.5.2.dylib -dynamic - 
macosx_version_min 10.3 -syslibroot /Developer/SDKs/MacOSX10.5.sdk - 
undefined dynamic_lookup -weak_reference_mismatches non-weak - 
undefined dynamic_lookup -o /var/tmp//ccjqTckC.out -ldylib1.o -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin9/4.0.1 -L/ 
Developer/SDKs/MacOSX10.5.sdk/usr/lib -L/usr/lib/gcc/i686-apple- 
darwin9/4.0.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/ 
lib/gcc/i686-apple-darwin9/4.0.1/x86_64 -L/usr/lib/gcc/i686-apple- 
darwin9/4.0.1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple- 
darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/Developer/SDKs/ 
MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../..  
history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so  
xmalloc.so -lncurses -final_output libhistory.5.2.dylib -lgcc -lSystem
lipo -create -o libhistory.5.2.dylib /var/tmp//ccRuPJQ0.out /var/tmp// 
cc5I5HDI.out /var/tmp//ccjqTckC.out /var/tmp//ccLg3kpV.out

============ Building the readline extension module ============

Modules/readline.c: In function ?py_remove_history?:Modules/ 
readline.c: In function ?py_remove_history?:

Modules/readline.c:316: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c:316: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c: In function ?py_remove_history?:
Modules/readline.c:316: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c: In function ?py_remove_history?:
Modules/readline.c: In function ?py_replace_history?:
Modules/readline.c:316: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target typeModules/readline.c:353: warning:  
passing argument 1 of ?free? discards qualifiers from pointer target  
typeModules/readline.c: In function ?py_replace_history?:


Modules/readline.c:353: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c: In function ?py_replace_history?:
Modules/readline.c:353: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c: In function ?py_replace_history?:
Modules/readline.c:353: warning: passing argument 1 of ?free? discards  
qualifiers from pointer target type
Modules/readline.c: In function ?flex_complete?:
Modules/readline.c:681: warning: implicit declaration of function  
?rl_completion_matches?
Modules/readline.c:681: error: ?rl_compentry_func_t? undeclared (first  
use in this function)
Modules/readline.c:681: error: (Each undeclared identifier is reported  
only once
Modules/readline.c:681: error: for each function it appears in.)
Modules/readline.c: In function ?flex_complete?:Modules/readline.c: 
681: error: syntax error before ?)? token

Modules/readline.c:681: warning: implicit declaration of function  
?rl_completion_matches?
Modules/readline.c:681: error: ?rl_compentry_func_t? undeclared (first  
use in this function)
Modules/readline.c:681: error: (Each undeclared identifier is reported  
only once
Modules/readline.c:681: warning: return makes pointer from integer  
without a castModules/readline.c:681: error: for each function it  
appears in.)

Modules/readline.c:681: error: syntax error before ?)? token
Modules/readline.c:681: warning: return makes pointer from integer  
without a cast
Modules/readline.c: In function ?flex_complete?:
Modules/readline.c:681: warning: implicit declaration of function  
?rl_completion_matches?
Modules/readline.c:681: error: ?rl_compentry_func_t? undeclared (first  
use in this function)
Modules/readline.c:681: error: (Each undeclared identifier is reported  
only once
Modules/readline.c:681: error: for each function it appears in.)
Modules/readline.c:681: error: syntax error before ?)? token
Modules/readline.c: In function ?readline_until_enter_or_signal?:
Modules/readline.c:758: error: ?rl_catch_signals? undeclared (first  
use in this function)
Modules/readline.c:681: warning: return makes pointer from integer  
without a cast
Modules/readline.c: In function ?readline_until_enter_or_signal?:
Modules/readline.c:758: error: ?rl_catch_signals? undeclared (first  
use in this function)
Modules/readline.c: In function ?flex_complete?:
Modules/readline.c:681: warning: implicit declaration of function  
?rl_completion_matches?
Modules/readline.c:681: error: ?rl_compentry_func_t? undeclared (first  
use in this function)
Modules/readline.c:681: error: (Each undeclared identifier is reported  
only once
Modules/readline.c:681: error: for each function it appears in.)
Modules/readline.c:681: error: syntax error before ?)? token
Modules/readline.c:681: warning: return makes pointer from integer  
without a cast
Modules/readline.c: In function ?readline_until_enter_or_signal?:
Modules/readline.c:758: error: ?rl_catch_signals? undeclared (first  
use in this function)
Modules/readline.c: In function ?call_readline?:
Modules/readline.c:896: warning: assignment discards qualifiers from  
pointer target type
Modules/readline.c: In function ?call_readline?:
Modules/readline.c:896: warning: assignment discards qualifiers from  
pointer target type
Modules/readline.c: In function ?readline_until_enter_or_signal?:
Modules/readline.c:758: error: ?rl_catch_signals? undeclared (first  
use in this function)
Modules/readline.c: In function ?call_readline?:
Modules/readline.c:896: warning: assignment discards qualifiers from  
pointer target type
Modules/readline.c: In function ?call_readline?:
Modules/readline.c:896: warning: assignment discards qualifiers from  
pointer target type
lipo: can't open input file: /var/tmp//ccbeKkMS.out (No such file or  
directory)
error: Setup script exited with error: command 'gcc' failed with exit  
status 1
sihpc03:~ anand$ gcc
i686-apple-darwin9-gcc-4.0.1: no input files
sihpc03:~ anand$



From glenn at tarbox.org  Thu May 29 20:30:41 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Thu, 29 May 2008 17:30:41 -0700
Subject: [IPython-dev] ipython -twisted
Message-ID: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>

ipython -twisted hangs and times out on Ubuntu hardy and Osx

tarbox at ghtmyth:$ ipython -twisted
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) 
Type "copyright", "credits" or "license" for more information.

IPython 0.8.3 -- 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]: whos
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)

-glenn

-- 
?Glenn H. Tarbox, PhD || 206-494-0819 || glenn at tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any 
 good you'll have to ram them down peoples throats" -- Howard Aiken



From fperez.net at gmail.com  Thu May 29 20:54:59 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 29 May 2008 17:54:59 -0700
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
Message-ID: <db6b5ecc0805291754u4860e947l29261feaab381bf9@mail.gmail.com>

Howdy,

On Thu, May 29, 2008 at 5:30 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> ipython -twisted hangs and times out on Ubuntu hardy and Osx

Yup, bug has already been filed:

https://bugs.launchpad.net/ipython/+bug/235911

I have to admit I don't know a thing about that part of the code, so
I'm a bit clueless right now.  But let's keep the discussion on the
bug page so it gets tracked appropriately.  Thanks for the report!

f


From ellisonbg.net at gmail.com  Thu May 29 23:58:18 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 29 May 2008 21:58:18 -0600
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
Message-ID: <6ce0ac130805292058o1e7bfa64i11b02f83bc8eb38f@mail.gmail.com>

Who put that in there.  I also don't know a darn thing about this code
(I didn't know it was there and I haven't looked at it).  It should
probably just be removed.

Brian

On Thu, May 29, 2008 at 6:30 PM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> ipython -twisted hangs and times out on Ubuntu hardy and Osx
>
> tarbox at ghtmyth:$ ipython -twisted
> Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.8.3 -- 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]: whos
> Warning: Timeout for mainloop thread exceeded
> switching to nonthreaded mode (until mainloop wakes up again)
>
> -glenn
>
> --
> ?Glenn H. Tarbox, PhD || 206-494-0819 || glenn at tarbox.org
> "Don't worry about people stealing your ideas. If your ideas are any
>  good you'll have to ram them down peoples throats" -- Howard Aiken
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>

From vivainio at gmail.com  Fri May 30 01:24:11 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 30 May 2008 08:24:11 +0300
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
Message-ID: <46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>

On Fri, May 30, 2008 at 3:30 AM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> ipython -twisted hangs and times out on Ubuntu hardy and Osx

Works on windows, at least. I have to test this at home on ubuntu. The
first call just takes a while to complete.

BTW, I was wondering - does twisted even need an ipython shell thread?
E.g. qt4 event loop uses PyOS_InputHook, so if twisted is doing the
same thing the reactor should just run in background when ipython is
doing raw_input.

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


From glenn at tarbox.org  Fri May 30 01:30:33 2008
From: glenn at tarbox.org (Glenn H Tarbox, PhD)
Date: Thu, 29 May 2008 22:30:33 -0700
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
	<46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
Message-ID: <1212125433.8791.105.camel@ghtmyth.hq.tarbox.org>

On Fri, 2008-05-30 at 08:24 +0300, Ville M. Vainio wrote:
> On Fri, May 30, 2008 at 3:30 AM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
> > ipython -twisted hangs and times out on Ubuntu hardy and Osx
> 
> Works on windows, at least. I have to test this at home on ubuntu. The
> first call just takes a while to complete.
> 
> BTW, I was wondering - does twisted even need an ipython shell thread?
> E.g. qt4 event loop uses PyOS_InputHook, so if twisted is doing the
> same thing the reactor should just run in background when ipython is
> doing raw_input.

An extension to this question would be: Why cant the reactor handle all
IO, passing stdin and stdout to the appropriate reader / writer all in
one thread.  This may be due to blocking calls which are hard to avoid
but I don't know the design well enough...

But this discussion did take place to a degree in previous threads.

-glenn

> 
-- 
?Glenn H. Tarbox, PhD || 206-494-0819 || glenn at tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any 
 good you'll have to ram them down peoples throats" -- Howard Aiken



From vivainio at gmail.com  Fri May 30 01:42:12 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 30 May 2008 08:42:12 +0300
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <1212125433.8791.105.camel@ghtmyth.hq.tarbox.org>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
	<46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
	<1212125433.8791.105.camel@ghtmyth.hq.tarbox.org>
Message-ID: <46cb515a0805292242s7a2f5c33n89bdf0e6c2a54978@mail.gmail.com>

On Fri, May 30, 2008 at 8:30 AM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:

>> BTW, I was wondering - does twisted even need an ipython shell thread?
>> E.g. qt4 event loop uses PyOS_InputHook, so if twisted is doing the
>> same thing the reactor should just run in background when ipython is
>> doing raw_input.
>
> An extension to this question would be: Why cant the reactor handle all
> IO, passing stdin and stdout to the appropriate reader / writer all in
> one thread.  This may be due to blocking calls which are hard to avoid
> but I don't know the design well enough...

It would require making pyreadline and readline twisted-aware, which
is not easy (apparently). Since at least PyQt4 installs
PyOS_InputHook, the Qt4 reactor should work without a separate shell
thread without any additional coding.

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


From fperez.net at gmail.com  Fri May 30 02:19:04 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 29 May 2008 23:19:04 -0700
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
	<46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
Message-ID: <db6b5ecc0805292319o178b3cdexa189ef357fad0815@mail.gmail.com>

On Thu, May 29, 2008 at 10:24 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, May 30, 2008 at 3:30 AM, Glenn H Tarbox, PhD <glenn at tarbox.org> wrote:
>> ipython -twisted hangs and times out on Ubuntu hardy and Osx
>
> Works on windows, at least. I have to test this at home on ubuntu. The
> first call just takes a while to complete.

I just tried it on hardy, and it's fully borked.

In [1]: 4+3
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)

In [2]: 4+3
Out[2]: 7

In [3]:
Closing threads... Done.
Closing threads... Done.
Traceback (most recent call last):
  File "/home/fperez/usr/lib/python2.5/site-packages/IPython/twshell.py",
line 251, in mainloop
    self.reactor.run()
  File "/home/fperez/usr/lib/python2.5/site-packages/IPython/twshell.py",
line 229, in reactorrun
    reactorrun_orig()
  File "/usr/lib/python2.5/site-packages/twisted/internet/posixbase.py",
line 220, in run
    self.mainLoop()
  File "/usr/lib/python2.5/site-packages/twisted/internet/posixbase.py",
line 228, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.5/site-packages/twisted/internet/base.py",
line 561, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python2.5/site-packages/twisted/internet/base.py",
line 411, in _continueSystemEvent
    for callList in sysEvtTriggers[1], sysEvtTriggers[2]:
exceptions.TypeError: 'NoneType' object is unsubscriptable
mainloop ending....
maqroll[share]>


This went in while I was in the middle of my Berkeley move and I have
to admit I didn't even look at a single commit during that period.
Obviously I should have been paying more attention, I'm afraid.

I'd really like to hear from Brian and Yi, if you have a chance, since
both of you know Twisted about 100 times better than me.  But my
inclination right now is to quickly put out an 0.8.4 release that
disables that code completely.  We don't need anything drastic, just
to  ignore the -twisted flag completely until  someone comes back and
can produce that code in an implementation that works on all known
platforms, with some measure of confidence.

We have a tradition of shipping code that actually works with ipython,
let's do our best to keep it that way.  IPython0 may have a messy
architecture and no unit tests, which is why it moves so slowly.  But
typically we test carefully and conservatively what we add, so users
can actually trust it. Code that is so spectacularly broken simply
can't be shipped.

Cheers,

f


From vivainio at gmail.com  Fri May 30 02:49:28 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 30 May 2008 09:49:28 +0300
Subject: [IPython-dev] ipython -twisted
In-Reply-To: <db6b5ecc0805292319o178b3cdexa189ef357fad0815@mail.gmail.com>
References: <1212107441.8791.97.camel@ghtmyth.hq.tarbox.org>
	<46cb515a0805292224h6edd76d5p350ff71880329157@mail.gmail.com>
	<db6b5ecc0805292319o178b3cdexa189ef357fad0815@mail.gmail.com>
Message-ID: <46cb515a0805292349j3d636347rc327d41fbb2fbb92@mail.gmail.com>

On Fri, May 30, 2008 at 9:19 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> I'd really like to hear from Brian and Yi, if you have a chance, since
> both of you know Twisted about 100 times better than me.  But my
> inclination right now is to quickly put out an 0.8.4 release that
> disables that code completely.  We don't need anything drastic, just

The problem probably is that it does not explicitly install a reactor
(qt / gtk) - which does not seem to be a requirement on windows.


> to  ignore the -twisted flag completely until  someone comes back and
> can produce that code in an implementation that works on all known
> platforms, with some measure of confidence.

It should not be too problematic - I guess we should release a fully
fixed version if I can do it, not a "disabled" version.

> We have a tradition of shipping code that actually works with ipython,
> let's do our best to keep it that way.  IPython0 may have a messy
> architecture and no unit tests, which is why it moves so slowly.  But

New features are not guaranteed to work in a trustworthy fashion -
they need to receive *some* field testing before they can be trusted.
Also, there are many features that are not widely used that can remain
in a broken state for a long time (e.g. macros in threaded shells).

I guess the "problem" is that the user base is rather conservative in
their IPython usage patterns, so broken areas are not detected quickly
enough. It's a mixed blessing.

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


From vivainio at gmail.com  Fri May 30 10:21:45 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 30 May 2008 17:21:45 +0300
Subject: [IPython-dev] Twisted disabled on non-win32,
Message-ID: <46cb515a0805300721w17da9aa3wb364869d5a8123c2@mail.gmail.com>

I have now disabled -twisted on non-win32 platforms, as well as made a
small tweak to ipy_profile_sh.py to make ipython work with python 2.3.

After these significant fixes, we are now ready for 0.8.4 quick-fix
release (I have already updated Release.py to reflect that). If you
have some
other complaints, bring them up quickly. If not, Fernando can do the
new release. I don't think we need to "announce" it, I'll just post a
reply to the
usenet thread, and we can delete the 0.8.3 installer from dist/ to
direct the attention at 0.8.4.

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


From fperez.net at gmail.com  Fri May 30 13:47:59 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 May 2008 10:47:59 -0700
Subject: [IPython-dev] Twisted disabled on non-win32,
In-Reply-To: <46cb515a0805300721w17da9aa3wb364869d5a8123c2@mail.gmail.com>
References: <46cb515a0805300721w17da9aa3wb364869d5a8123c2@mail.gmail.com>
Message-ID: <db6b5ecc0805301047j2ecdc5f3lb62e4ad85e298d1b@mail.gmail.com>

On Fri, May 30, 2008 at 7:21 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> I have now disabled -twisted on non-win32 platforms, as well as made a
> small tweak to ipy_profile_sh.py to make ipython work with python 2.3.
>
> After these significant fixes, we are now ready for 0.8.4 quick-fix
> release (I have already updated Release.py to reflect that). If you
> have some
> other complaints, bring them up quickly. If not, Fernando can do the
> new release. I don't think we need to "announce" it, I'll just post a
> reply to the
> usenet thread, and we can delete the 0.8.3 installer from dist/ to
> direct the attention at 0.8.4.

Still broken here.  I got the relevant revisions, but it still hangs:

In [1]: 1+2
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)


I'll clean up this mess later myself, I have to run to a meeting now.

f


From fperez.net at gmail.com  Fri May 30 13:50:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 May 2008 10:50:00 -0700
Subject: [IPython-dev] Twisted disabled on non-win32,
In-Reply-To: <db6b5ecc0805301047j2ecdc5f3lb62e4ad85e298d1b@mail.gmail.com>
References: <46cb515a0805300721w17da9aa3wb364869d5a8123c2@mail.gmail.com>
	<db6b5ecc0805301047j2ecdc5f3lb62e4ad85e298d1b@mail.gmail.com>
Message-ID: <db6b5ecc0805301050w76131a86pe25e951aa7b096df@mail.gmail.com>

On Fri, May 30, 2008 at 10:47 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, May 30, 2008 at 7:21 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>> I have now disabled -twisted on non-win32 platforms, as well as made a
>> small tweak to ipy_profile_sh.py to make ipython work with python 2.3.
>>
>> After these significant fixes, we are now ready for 0.8.4 quick-fix
>> release (I have already updated Release.py to reflect that). If you
>> have some
>> other complaints, bring them up quickly. If not, Fernando can do the
>> new release. I don't think we need to "announce" it, I'll just post a
>> reply to the
>> usenet thread, and we can delete the 0.8.3 installer from dist/ to
>> direct the attention at 0.8.4.
>
> Still broken here.  I got the relevant revisions, but it still hangs:

Never mind, false alarm.

I'll package a release for 0.8.4 and upload a bit later.


f


From fperez.net at gmail.com  Sat May 31 19:01:12 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 16:01:12 -0700
Subject: [IPython-dev] Twisted disabled on non-win32,
In-Reply-To: <db6b5ecc0805301050w76131a86pe25e951aa7b096df@mail.gmail.com>
References: <46cb515a0805300721w17da9aa3wb364869d5a8123c2@mail.gmail.com>
	<db6b5ecc0805301047j2ecdc5f3lb62e4ad85e298d1b@mail.gmail.com>
	<db6b5ecc0805301050w76131a86pe25e951aa7b096df@mail.gmail.com>
Message-ID: <db6b5ecc0805311601y2e4c7f7aw1aa23fb1f38aa3aa@mail.gmail.com>

On Fri, May 30, 2008 at 10:50 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
> I'll package a release for 0.8.4 and upload a bit later.

OK, I'm almost done with this, will announce shortly.  Note that for
now, I've *fully* disabled the -twisted option,  it is NOT a valid
option anymore.

Do NOT even consider re-enabling this until we hash out whether that
code in twshell is actually correct or not, and how it will  play with
the rest of the twisted features in ipython.  Brian was adamant about
this when this discussion happened  (I missed it all in the middle of
my move, but he didn't):

http://lists.ipython.scipy.org/pipermail/ipython-dev/2008-March/003716.html

Quoting Brian:
Noooooo ;-).  Please, don't start doing stuff like this without all of
us discussing the best direction.  The parallel computing stuff in
IPython1 is designed to work with IPython0 and uses a very carefully
crafted approach for integrating with the Twisted main loop.  Doing
something like this could easily break IPython1 for the many current
users - even if it is optional, I don't want it in IPython0.  More
discussion is needed first.  Sorry I don't have more time to
participate in the discussion right now - if you are interested in how
we are handling this in IPython1, please look at that code base.  What
ever ends up in IPython0 _must_ be compatible with that.

and later:

http://lists.ipython.scipy.org/pipermail/ipython-dev/2008-March/003722.html

which said:

Just in terms of dependencies, having IPython0 depend on Twisted
(optionally of course) is not a problem.  But, how IPython0 _uses_
twisted (even though optional) should be compatible with the way
people are currently using Ipython1 for parallel computing - they
simply use it with IPython0.  That is, the any IPython0 Twisted usage
must not break the IPython0+IPython1 usage pattern that is most common
today.

[end quote]

I'm not sure how Brian could have been any more explicit in asking
that this code not be activated by default.  Brian knows Twisted in
and out and the ip1 architecture is based on it, so now I'm belatedly
honoring his request from March 21 and pulling that code out.

The fact that it only works on win32 makes me extra suspicious of its
correctness, because Twisted is pretty cross-platform.  I'm not saying
it's wrong, but until we understand why it happens to work on win32
and not on other platforms, I don't trust it.


Note that if anyone wants to use the feature, it's trivial to do so.
The now removed ipython -twisted can be obtained with a simple:

python -c"from IPython import twshell;twshell.IPShellTwisted().mainloop()"

So anyone can put in an alias or personal script that consists of this
single line if they want to try out the code.  But until we sort out
this mess, it's off.  Given how we're being forced by this into a
quick-fix release, I don't have the time for a more permanent
solution.

Cheers,

f


From fperez.net at gmail.com  Sat May 31 19:54:56 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 16:54:56 -0700
Subject: [IPython-dev] IPython 0.8.4 quickfix release
Message-ID: <db6b5ecc0805311654y78df26ddqa7af90ea19052c2a@mail.gmail.com>

Hi all,

I've just released version 0.8.4 as a quick fix.  The only notable changes are:

- restored python 2.3 compatibility, though this has been only lightly
tested, since none of the core devs use 2.3 anymore.  Please report
problems.

- fully disabled the recent -twisted option.  This will need much more
testing than we can do right now.  If you are on win32 (it's known to
be fully broken elsewhere) and want to use it, simply run this at the
command line or in an alias:

python -c"from IPython import twshell;twshell.IPShellTwisted().mainloop()"

or make the equivalent personal python script:

from IPython import twshell;twshell.IPShellTwisted().mainloop()

Cheers,

f


From fperez.net at gmail.com  Sat May 31 22:12:08 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 19:12:08 -0700
Subject: [IPython-dev] Bzr workflow heads-up
Message-ID: <db6b5ecc0805311912r509f4bc5h223d6cd7649544ab@mail.gmail.com>

Hi all,

Ville recently pointed out to me that  some of us were mis-using bzr
in our normal workflow.  This is something some of you may remember
discussing at the March sprints, where we'd concluded that launchpad
just had a crappy web view of the history, since it only shows a
single branch, with the effect that whoever made the last commit
appeared to overwrite the project history.  In reality no commit
history was ever lost, as a local 'bzr viz' would show you, but the
publicly visible history was indeed mangled.  For example if you see
here:

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

revision 122 appears as a single commit from Ville, which in my local
copy actually consisted of multiple independent commits, and he was
undoing this 'folding of history' effect that occurred when I pushed
those changes upstream.

The origin of the problem was that I was working directly on the
branch I obtained via

bzr branch lp:ipython

and doing *both* commits and pushes from there.  While that doesn't
cause bzr itself any problems, it does confuse the web view that
launchpad uses, since that one flattens the bzr history into a single
line of development (bzr viz does show the full branch/merge evolution
correctly).

Since it's nice to make sure that the public web view remains a more
faithful representation of the actual commit history, and it is
possible to accomplish it with very little extra effort, here's the
required procedure (I'll put this on the wiki as well).  If you are an
ipython developer with push rights to one of the public project
branches  (I'll use the main one here, but the same applies to all),
the workflow you should use is:

1. Make a local copy of the public branch with:

bzr branch lp:ipython ipython-launchpad

You will NOT work on this branch directly!

2. Make a SECOND branch off of this one (you can repeat the lp branch
with a second name, but it's faster to do this locally):

bzr branch ipython-launchpad ipython-local


3. The -local one is where you will do all your work, make local
commits, etc.  As you work in -local, you can make as many commits as
you want, pull from launchpad (to get the changes from other
developers), etc.  But you will NEVER push back up to launchpad from
here.

4. Once you are ready to push your work back up to launchpad to the
main branch, in the -launchpad branch, do (this assumes the two sit
next to each other):

   bzr pull ../ipython-local
   bzr push

(the first time you'll need the full path and the --remember option).
This will then ensure that  the revision history from your -local
branch is merged in correctly with the rest of the changes made by
other developers.


Note: I've now tried the above approach for the small changes I made
for 0.8.4 and it worked fine.  But I don't know all the details and
there may be things in the above description that are not 100% right
or could be done better/easier.  If that's the case, please update the
wiki, I put all this here for permanent reference:

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


Cheers,

f


From fperez.net at gmail.com  Sat May 31 22:17:05 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 19:17:05 -0700
Subject: [IPython-dev] ipython on google app engine
In-Reply-To: <6ce0ac130805280754m51475f8ai39dec8e145fd385c@mail.gmail.com>
References: <85b5c3130805240150j6b6cd3fyaf3f999bf2ed410c@mail.gmail.com>
	<cd7634ce0805250949m5ded13d7t97c8bf16ab7a033c@mail.gmail.com>
	<6ce0ac130805271514p7bf8ee35se1168185738a7548@mail.gmail.com>
	<cd7634ce0805272311v78eea9e1wbe42432288b2a3c3@mail.gmail.com>
	<6ce0ac130805280754m51475f8ai39dec8e145fd385c@mail.gmail.com>
Message-ID: <db6b5ecc0805311917y4f908bdnd515900e30f1ae84@mail.gmail.com>

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__).

Just a side note...

Cheers,

f


From fperez.net at gmail.com  Sat May 31 22:27:14 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 19:27:14 -0700
Subject: [IPython-dev] online sympy shell at live.sympy.org
In-Reply-To: <85b5c3130805191005y30de69f1g3f7f90d37088ced3@mail.gmail.com>
References: <85b5c3130805190735h4a13c4c1g8a211aba7cefa524@mail.gmail.com>
	<6ce0ac130805190936hde9cc46kfd47b13aa457055d@mail.gmail.com>
	<85b5c3130805191005y30de69f1g3f7f90d37088ced3@mail.gmail.com>
Message-ID: <db6b5ecc0805311927o2f029f4fk453ca3ea08f5378d@mail.gmail.com>

On Mon, May 19, 2008 at 10:05 AM, Ondrej Certik <ondrej at certik.cz>


> Do you have any time estimates when something will be usable? I think
> the goal on Sage Days 8 was to have something ready by the same time
> next year, right? Unfortunately, I don't have time to help much,
> unless it's ready to do the 90% of things that I want, then I could
> help with the rest 10%.

Hopefully soon!  See my next email for some plans that we hope will help a lot.

Cheers,

f


From fperez.net at gmail.com  Sat May 31 22:33:56 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 19:33:56 -0700
Subject: [IPython-dev] .. hint:: not support in HTML docs?
In-Reply-To: <3d375d730805121929r16a72402q1cc83b64beba7867@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>
Message-ID: <db6b5ecc0805311933p611b229dx96c2c29008ab6ab1@mail.gmail.com>

Hey Robert,

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.

Cheers,

f


From fperez.net at gmail.com  Sat May 31 22:55:17 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 31 May 2008 19:55:17 -0700
Subject: [IPython-dev] IPython development: course adjustment required
Message-ID: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>

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


From jdh2358 at gmail.com  Sat May 31 23:24:17 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Sat, 31 May 2008 22:24:17 -0500
Subject: [IPython-dev] IPython development: course adjustment required
In-Reply-To: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
References: <db6b5ecc0805311955y1261d166n9c9ca8e653967f44@mail.gmail.com>
Message-ID: <88e473830805312024o76df6d8byda0138cd6940f791@mail.gmail.com>

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.

Clearly I am not an ipython developer, so I know not of what I speak.
But this reminds me of a situation we faced in matplotlib a year or so
ago, when working on mpl1, though we were never as advanced in our
efforts as you are today with ip1.  The goal was to cleanly rewrite
the matplotlib code  to clear out the architectural mistakes we made
in mpl0, and we (I) were prepared to break the existing codebase
heavily if necessary to get there.

Perry Greenfield wrote me offlist, somewhat nervously, and advocated
instead an incremental approach, moving the existing codebase forward
piecemeal, rather than forking/breaking the existing project to get a
clean design.  Obviously Perry had some experience in this arena,
having worked hard for years to get a clean-room implementation of
Numeric (aka numarray), but he encountered a lot of resistance getting
folks off the feature complete, if hairy, Numeric code base they knew
and loved.

Perhaps in the end he was frightened enough about the potential effect
of an mpl1 effort that he put Michael Droettboom on matplotlib (mpl0)
full time for a while to get the *existing* code base past its
problems so that we could move forward.  This was no small or easy
task, and there are few people besides Michael who could have pulled
it off, but mpl is certainly better off for it, since we get the
benefits of a better internal design *and* the continuing use and
support of the installed matplotlib user base, who mostly won't see
the difference.

So I think your proposal is the right one.

JDH