From fperez.net at gmail.com  Sat Aug  2 05:23:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 2 Aug 2008 02:23:28 -0700
Subject: [IPython-dev] Notes from the testing trenches...
Message-ID: <db6b5ecc0808020223g2afaa911j711c6bfebf3caf0b@mail.gmail.com>

Hi all,

I'm very sorry that I've completely neglected all the (critically
important) discussion here over the last few days.  Basically I
decided that I needed to focus 100% on pushing on the testing work,
which I've become convinced was endangering seriously the long-term
viability of IPython.

I'm *very* happy to report this now:

tlon[plugin]> nosetests -vvs --with-ipdoctest --doctest-tests
--doctest-extension=txt IPython
... lots of output ...
Doctest: IPython.testing.tutils.fullPath ... ok

----------------------------------------------------------------------
Ran 445 tests in 75.199s

OK

Yes!!!  (the above includes all the IPython1 tests, in addition to
many scattered docstrings and small tests from IPython0, many with
actual IPython syntax in the docstrings).

This is the first time that we've had real testing for all of IPython,
and this has proved to be surprisingly difficult to get working.  I
have nobody but myself to blame for some of it, since precisely the
lack of clean tests led to an over-coupled API, but part of the
difficulty also stems from the fact that IPython, nose and doctest are
effectively all colliding and fighting each other for control of the
execution namespace.

In fact, there are still things that don't quite work right, and at
least one of them (having to do with namespace control) is very
important.  I have a solution in my head for it, but I need to sleep
now and it may be a couple of days before I get to it.

For now I'm putting all of this in a branch:

https://code.launchpad.net/~ipython/ipython/test-tools

where I've been regularly pushing.  I don't expect any of this to run
on anything but *nix (maybe not even OSX, I'm not sure) for now.
We'll eventually make it run under all platforms, but we're not there
yet.  If you're brave, you can pull that branch and go to the
IPython/testing/plugin directory, and type

make all

let me know how much blows up :)

I will be offline for a day or two (visitors), and will try to get
back to the notification/API discussion on Monday.  A big apology to
Barry and Gael for ignoring you, really.  But I'd neglected the
testing machinery on ipython for years, it was really time to fix this
or else it was going to drag the whole project down into the ground.

So if anyone is brave/foolish enough to try to run this branch and
these tests, please let me know what happens.  Eventually we obviously
need this to work for everyone, and once the machinery is stable it
will allow us to have much more strict policies regarding tests for
the project.

Cheers,

f


From barrywark at gmail.com  Wed Aug  6 15:54:50 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 6 Aug 2008 15:54:50 -0400
Subject: [IPython-dev] ipython1 and synchronous printing of stdout
In-Reply-To: <20080731005528.GA13565@phare.normalesup.org>
References: <cd7634ce0807202136k397006bqcc7bbe23069581e@mail.gmail.com>
	<cd7634ce0807221105q78ba3f89h65e9f777e2f17d78@mail.gmail.com>
	<6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com>
	<db6b5ecc0807232022r550c5639j1035568269f9f910@mail.gmail.com>
	<6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com>
	<cd7634ce0807241322w760e90ackf676b6a21958f40d@mail.gmail.com>
	<cd7634ce0807241323k2fe098fay8b16986f4d312642@mail.gmail.com>
	<db6b5ecc0807241945g3d1dc610r5ae0162a95558bde@mail.gmail.com>
	<cd7634ce0807271902n2d0fa7bbp49ccb6ec8f2192c8@mail.gmail.com>
	<20080731005528.GA13565@phare.normalesup.org>
Message-ID: <cd7634ce0808061254y21f0d9amee8c109d48aaff83@mail.gmail.com>

On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi,
>
> Sorry for the silence, I have been working my ass off on a release of
> Mayavi. Now I can go back to working on ipython.

No problem. I'm not finding tons of time to play either.

>
> On Sun, Jul 27, 2008 at 10:02:08PM -0400, Barry Wark wrote:
>> Taking a bit of my own medicine?that working code is better than
>> awesome theory?I've checked in the ipython-notification branch and
>> proposed it for merging into trunk. It includes a functional spec in
>> /blueprints (it's a bit tounge-in-cheek; I hope no one is offended) as
>> well as an implementation of the NotificationCenter I've been
>> discussin in IPython.kernel.core.notification.
>
> I had a look at that. I seems to me like a (good) textbook implementation
> of the patterns we are discussing. I still fail to see the point of
> having this in Ipython, at least at the state we are in right now. My
> point is that there are many implementation of such frameworks. The one
> you have developed is a simple one, but when you start using it a lot,
> you will need to add features, like delegations, or ordering the
> callbacks. Also, something that is very important is how does this blend
> in the code people write? How do you make it easy for people to write
> notifications without thinking too much about it, and registering
> handlers (hint decorators are cool). But once again, this looks a lot to
> me like traits 1. I am not trying to sell traits here, I don't think
> IPyhton should use traits, I am just flashing a warning: this smells like
> weel reinvention, and on top of that developing a framework, which is
> something you want to limit as much as possible: we already have too many
> frameworks. I have the feeling every single person coming to develop an
> app using Ipython will already have his notification framework (traits,
> cocoa, does Qt have one?). So now he will to write adapting code to use
> your framework.

Yes, but I claim writing an adaptor layer for each GUI toolkit at the
level of ipython.frontend is better than writing the same in
ipython.kernel.core.

>
> Now there is value in having an iptyhon-specific notification layer, and
> it is not having uniform code across backends; matplotlib tried that, and
> it doesn't bring much value, amongst other things because the backend are
> anyhow riddled with toolkit-specific code. The value is that we could
> think of network-transparent notifications. That is much harder
> (obviously, the simple problems don't need solutions), and I would like
> to know if twisted doesn't provide this kind of service.

I think you've misunderstood the point. I am not trying to create a
universal GUI toolkit. I am concerned with notifications of events in
the core -- things that have nothing to do with the GUI toolkit. It's
up to the frontend writers to decide (1) what to do with those events
and (2) how to translate their GUI tookit's UI events into appropriate
calls into the ipython API.

>
> I guess my point is not that we shouldn't do this, but that we should do
> this when the need arises, and not now, for no benefit. Doing this too
> early is a good way of getting it wrong. In addition this will just slow
> our progress towards getting frontends and we absolutely do not need this
> to get the simple frontends. I am not going to spend anytime on this, and
> spending too much time on this is a good way of not having any useable
> code for a long time, I believe.

That's your choice. You can write your code as you wish.

>
> Sorry, not only am I not paid to worry about distant future, or
> network-transparency problems, I am also having difficulties being
> interested in something that I cannot specify properly because it doesn't
> answer a problem I have. I am not in the business of making a framework,
> I am in the business of making a widget. The whole notification framework
> stuff, for me, will be done in traits, because this is what we use all
> over our apps, because we have a lot of code that works well with it, and
> because is it a mature and powerful library. I develop my apps using
> traits, and I want an ipython widget to plug in my apps. If the objects
> used internally in the ipython widget are standard object like dicts or
> lists, I can use traits without any problem. If there are part of a
> notification framework that I have to adapt to, I probably have to double
> the size of my codebase. Let us see where we really need this framework.
> Maybe it can also be developed in a subclass of the standard objects we
> use in ipython, say a different frontend base class?
>
> I hope I am not being to rough or criticizing too much your software
> engineering efforts. I am just trying to be practical and figure out how
> to ship software that is useful to users (and yes this includes
> open-source software) in a reasonable amount of time. And the basis of
> agile methods is to get it working, ship it to your users, see the
> limitations in your implementation, refactor, ship it again, always
> focusing on what benefits to your users, rather than on the architecture
> or the software engineering, which is a tool, not a goal.

Fine. You have your requirements and if you don't have time to
consider alternatives, that's fine with me. I think going down the
road you've chosen will force others to recreate much of the
functionality you're working on, but it doesn't seem that you have
time to think about the more general case.

>
> As for your code, if you want to merge it in, it is fine by me, but I am
> afraid it won't be used for a while, and when we get to use it, we might
> want to change it because we have more insight on our problems.

Isn't that always the case?

>
> Thanks for bringing up on interesting discussion,
>
> Ga?l
>


From barrywark at gmail.com  Thu Aug  7 09:44:50 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 7 Aug 2008 09:44:50 -0400
Subject: [IPython-dev] ipython1 and synchronous printing of stdout
In-Reply-To: <cd7634ce0808061254y21f0d9amee8c109d48aaff83@mail.gmail.com>
References: <cd7634ce0807202136k397006bqcc7bbe23069581e@mail.gmail.com>
	<6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com>
	<db6b5ecc0807232022r550c5639j1035568269f9f910@mail.gmail.com>
	<6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com>
	<cd7634ce0807241322w760e90ackf676b6a21958f40d@mail.gmail.com>
	<cd7634ce0807241323k2fe098fay8b16986f4d312642@mail.gmail.com>
	<db6b5ecc0807241945g3d1dc610r5ae0162a95558bde@mail.gmail.com>
	<cd7634ce0807271902n2d0fa7bbp49ccb6ec8f2192c8@mail.gmail.com>
	<20080731005528.GA13565@phare.normalesup.org>
	<cd7634ce0808061254y21f0d9amee8c109d48aaff83@mail.gmail.com>
Message-ID: <cd7634ce0808070644i4e4450ffoae4eae77ee2de2d7@mail.gmail.com>

Gael,

I appologize. In my haste to reply, I'm afraid that my speed may have
come off as impatient. Let me try again:
Although I was initially a bit offended by your remarks, I realize
that we all have too much to do and not enough time to do it. I am not
(and won't be) offended if you don't want to use the notification
framework. We should always prefer working code and I am looking
forward to benefiting from your efforts, no mater what architecture
you choose.

- Barry

On Wed, Aug 6, 2008 at 3:54 PM, Barry Wark <barrywark at gmail.com> wrote:
> On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> Hi,
>>
>> Sorry for the silence, I have been working my ass off on a release of
>> Mayavi. Now I can go back to working on ipython.
>
> No problem. I'm not finding tons of time to play either.
>
>>
>> On Sun, Jul 27, 2008 at 10:02:08PM -0400, Barry Wark wrote:
>>> Taking a bit of my own medicine?that working code is better than
>>> awesome theory?I've checked in the ipython-notification branch and
>>> proposed it for merging into trunk. It includes a functional spec in
>>> /blueprints (it's a bit tounge-in-cheek; I hope no one is offended) as
>>> well as an implementation of the NotificationCenter I've been
>>> discussin in IPython.kernel.core.notification.
>>
>> I had a look at that. I seems to me like a (good) textbook implementation
>> of the patterns we are discussing. I still fail to see the point of
>> having this in Ipython, at least at the state we are in right now. My
>> point is that there are many implementation of such frameworks. The one
>> you have developed is a simple one, but when you start using it a lot,
>> you will need to add features, like delegations, or ordering the
>> callbacks. Also, something that is very important is how does this blend
>> in the code people write? How do you make it easy for people to write
>> notifications without thinking too much about it, and registering
>> handlers (hint decorators are cool). But once again, this looks a lot to
>> me like traits 1. I am not trying to sell traits here, I don't think
>> IPyhton should use traits, I am just flashing a warning: this smells like
>> weel reinvention, and on top of that developing a framework, which is
>> something you want to limit as much as possible: we already have too many
>> frameworks. I have the feeling every single person coming to develop an
>> app using Ipython will already have his notification framework (traits,
>> cocoa, does Qt have one?). So now he will to write adapting code to use
>> your framework.
>
> Yes, but I claim writing an adaptor layer for each GUI toolkit at the
> level of ipython.frontend is better than writing the same in
> ipython.kernel.core.
>
>>
>> Now there is value in having an iptyhon-specific notification layer, and
>> it is not having uniform code across backends; matplotlib tried that, and
>> it doesn't bring much value, amongst other things because the backend are
>> anyhow riddled with toolkit-specific code. The value is that we could
>> think of network-transparent notifications. That is much harder
>> (obviously, the simple problems don't need solutions), and I would like
>> to know if twisted doesn't provide this kind of service.
>
> I think you've misunderstood the point. I am not trying to create a
> universal GUI toolkit. I am concerned with notifications of events in
> the core -- things that have nothing to do with the GUI toolkit. It's
> up to the frontend writers to decide (1) what to do with those events
> and (2) how to translate their GUI tookit's UI events into appropriate
> calls into the ipython API.
>
>>
>> I guess my point is not that we shouldn't do this, but that we should do
>> this when the need arises, and not now, for no benefit. Doing this too
>> early is a good way of getting it wrong. In addition this will just slow
>> our progress towards getting frontends and we absolutely do not need this
>> to get the simple frontends. I am not going to spend anytime on this, and
>> spending too much time on this is a good way of not having any useable
>> code for a long time, I believe.
>
> That's your choice. You can write your code as you wish.
>
>>
>> Sorry, not only am I not paid to worry about distant future, or
>> network-transparency problems, I am also having difficulties being
>> interested in something that I cannot specify properly because it doesn't
>> answer a problem I have. I am not in the business of making a framework,
>> I am in the business of making a widget. The whole notification framework
>> stuff, for me, will be done in traits, because this is what we use all
>> over our apps, because we have a lot of code that works well with it, and
>> because is it a mature and powerful library. I develop my apps using
>> traits, and I want an ipython widget to plug in my apps. If the objects
>> used internally in the ipython widget are standard object like dicts or
>> lists, I can use traits without any problem. If there are part of a
>> notification framework that I have to adapt to, I probably have to double
>> the size of my codebase. Let us see where we really need this framework.
>> Maybe it can also be developed in a subclass of the standard objects we
>> use in ipython, say a different frontend base class?
>>
>> I hope I am not being to rough or criticizing too much your software
>> engineering efforts. I am just trying to be practical and figure out how
>> to ship software that is useful to users (and yes this includes
>> open-source software) in a reasonable amount of time. And the basis of
>> agile methods is to get it working, ship it to your users, see the
>> limitations in your implementation, refactor, ship it again, always
>> focusing on what benefits to your users, rather than on the architecture
>> or the software engineering, which is a tool, not a goal.
>
> Fine. You have your requirements and if you don't have time to
> consider alternatives, that's fine with me. I think going down the
> road you've chosen will force others to recreate much of the
> functionality you're working on, but it doesn't seem that you have
> time to think about the more general case.
>
>>
>> As for your code, if you want to merge it in, it is fine by me, but I am
>> afraid it won't be used for a while, and when we get to use it, we might
>> want to change it because we have more insight on our problems.
>
> Isn't that always the case?
>
>>
>> Thanks for bringing up on interesting discussion,
>>
>> Ga?l
>>
>


From gael.varoquaux at normalesup.org  Thu Aug  7 10:56:58 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 7 Aug 2008 16:56:58 +0200
Subject: [IPython-dev] ipython1 and synchronous printing of stdout
In-Reply-To: <cd7634ce0808070644i4e4450ffoae4eae77ee2de2d7@mail.gmail.com>
References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com>
	<db6b5ecc0807232022r550c5639j1035568269f9f910@mail.gmail.com>
	<6ce0ac130807232222j295701denfa660731fc729f07@mail.gmail.com>
	<cd7634ce0807241322w760e90ackf676b6a21958f40d@mail.gmail.com>
	<cd7634ce0807241323k2fe098fay8b16986f4d312642@mail.gmail.com>
	<db6b5ecc0807241945g3d1dc610r5ae0162a95558bde@mail.gmail.com>
	<cd7634ce0807271902n2d0fa7bbp49ccb6ec8f2192c8@mail.gmail.com>
	<20080731005528.GA13565@phare.normalesup.org>
	<cd7634ce0808061254y21f0d9amee8c109d48aaff83@mail.gmail.com>
	<cd7634ce0808070644i4e4450ffoae4eae77ee2de2d7@mail.gmail.com>
Message-ID: <20080807145658.GA11600@phare.normalesup.org>

On Thu, Aug 07, 2008 at 09:44:50AM -0400, Barry Wark wrote:
> Although I was initially a bit offended by your remarks,

Sorry, Barry, I really do not want to critisize or downplay your efforts.
I value a lot your opinion. I must confess what you are bringing up does
not solve at all the problems I am battling for with my frontend, so I
don't look at this on a high priority.

> I realize that we all have too much to do and not enough time to do it.
> I am not (and won't be) offended if you don't want to use the
> notification framework. We should always prefer working code and I am
> looking forward to benefiting from your efforts, no mater what
> architecture you choose.

Well, I have come to realize that one of the reasons why we where having
this discussion, and not understanding eachothers is that our calls are
different: you want asyncrhonous, I want synchronous. As a result, you
have much bigger requirements on a notification framework to the engine
than I do.

I have been fighting with other difficulties, like solid trapping of
output (not only at the Python level), redirection of stdin in a GUI
eventloop, subprocess manipulation... For what I am trying to do, these
are much more important than a notification framework.

I will not be using the notification framework, but my code is
opensource, and moreover in a DVCS. I strongly hope that you will be able
to benefit from it to move foward with your goals. In addition, I am more
than happy if my code gets refactored to include this. Let me be clear, I
don't consider at all that this code belongs to me in any way. It is
there to be refactored, and I will try to make it as easy as possible for
people to do it. But for the time being I need to get something working.

Cheers,

Ga?l


From ellisonbg.net at gmail.com  Thu Aug  7 14:11:00 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 7 Aug 2008 11:11:00 -0700
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
Message-ID: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>

Hello all (especially Barry and Gael),

We would like to merge the ipython-sync-frontend branch into trunk
ASAP.  Fernando will be sending out an email later today describing
our timeframe for the upcoming release.  Meanwhile, I wanted to
provide some informal code review and feedback on the stuff in
IPython.frontend.  I haven't looked over the wx or cocoa specific
stuff, just the general stuff.

Overall, I am _really_ excited about this code.  Many thanks to Barry
and Gael for pushing this stuff forward and making the first go and
using the new core.  I talked to Fernando last night and both of us
are completely committed to getting this stuff into the next IPython
release, which is coming soon.  I should preface my comments by saying
that I don't think all of the comments need to be address before the
merge or the release.  Some of the comments are more long term.  Also,
Fernando is going to look over the new stuff in IPython.kernel.core (I
haven't looked at this stuff).


Here are my comments:

===============================
Comments about IPython.frontend
===============================

General
=======

We need a robust way for modules in the frontend to handle interfaces
if zope.interface is not installed.  Currently each module tries to
import zope.interface and then builds a mock zope.interface, like
this::

	try:
	    from zope.interface import Interface, Attribute, implements, classProvides
	except ImportError:
	    Interface = object
	    def Attribute(name, doc): pass
	    def implements(interface): pass
	    def classProvides(interface): pass

This code should probably be put into a common location, something
like frontend.zopeinterface, so that it can be reused.  But eventually
when
IPython.core is created, this should probably be moved there.

The docstrings are vague and outdated at points.  More detailed and
updated docstrings would be helpful.  Also, all docstrings should use
the epydoc+ReST format.

IPython.kernel.core should probably be moved to IPython.core.

Once Fernando's testing branch has been merged, more tests should be written.

frontendbase.py
===============

Configuration should be done using the approach in IPython.config.
See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
examples.

IFrontEnd has references to Twisted in its docstrings.  Because the
basic frontend should work without Twisted, the docstrings should be
updated to clarify how the interface plays with Twisted, even though
it is optional.  We really want to document for developers that the
base frontend is synchronous and doesn't require Twisted, but that the
interface has a particular design that allows it to be wrapped into an
asynchronous frontend (like some methods pass through the result).

The design of the frontend seems good though.  We might eventually
want to think about using the notification stuff in the frontend
though.

Why does FrontEndBase not have a complete method?  Other frontend
classes do have this method and its seems like the base class should
have it too.  Also, there are oher methods in the interpreter that we
might want to propagate up to the frontend, like push and pull.
Thoughts?  If these additional methods go in, there should be separate
asynchronous versions that return deferreds, but these would go into
asyncfrontend.py.

asyncfrontendbase.py
====================

Because this frontend us designed for use with Twisted, I don't think
we need to protect the zope.interface and Twisted imports.  Also setting
Failure to Exception will break things as they don't have the same interface.

Design looks good though.

linefrontendbase.py
===================

This looks good as it is simply a concrete subclass of FrontEndBase.
General comments above about docstrings apply.

prefilterfrontend.py
====================

It is fantastic that we can combine ipython0 and IPython.kernel.core
code like this.  This is a great way of using the new stuff, but
getting the more complete feature set of IPython.*  But I think this
type of thing should be done in the lower-level Interpreter, rather
than the frontend.  This is for a couple of reasons:

	1. This would give all users of the Interpreter access to completion and the
	   prefilter stuff.  We really need this stuff in the parallel
computing stuff,
	   as well as non-line-oriented frontends.
	2. The Interpreter already has some of this logic and it is simply being
	   repeated.
	3. The current implementation requires that the Interpreter is in-process.
	   For connecting to a remote Interpreter, this won't work.
	
But, we might run into a problem with doing this stuff (that cool hack
that is begin used currently) in the Interpreter.  The reason is that
the Interpreter is block based, whereas the prefilter stuff in IPython
is only line based.  Thus, doing this refactoring might be a little
more involved.  But it is the eventual design we want to go for.  This
stuff probably won't be done before the merge. We can work on this at
SciPy.


Great work everyone!!!

Brian


From gael.varoquaux at normalesup.org  Thu Aug  7 15:18:12 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 7 Aug 2008 21:18:12 +0200
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready	for merge of ipython-sync-frontend
In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
Message-ID: <20080807191812.GD26341@phare.normalesup.org>

Hi Brian,

Thanks a lot for your comments, they are very valuable.

I have to run to catch St?fan at the airport, I just wanted to give an
informal overview of the status of my work. I am currently battling with
subprocess execution, including under windows. The hard stuff is the
stdin capture, and it happens more often than I would like. Once I am
done with that (hopefully today, though my afternoon will be busy working
with St?fan), I have to make sure that 'Ctrl-C' stops Python execution,
which should be easy. After this I was planning to clean up the code, add
comments and ask for merge.

All your comments are very much to the points. Some of them where already
on my todo list. Can you prioritize them, and tell me at which point I
should do the merge. I also would like to merge ASAP, I just don't want
to have bad crashers in the code before I merge (but if you think it is
acceptable, I'll go for it), and I want to refactor some names and
interfaces before the merge. Hopefully merge is a few work days away. Is
that good enough, or should I try to get this done faster?

Obviously this is a first cut, and there will be some lessons to learn.

> We need a robust way for modules in the frontend to handle interfaces
> if zope.interface is not installed.  Currently each module tries to
> import zope.interface and then builds a mock zope.interface, like
> this::

> 	try:
> 	    from zope.interface import Interface, Attribute, implements, classProvides
> 	except ImportError:
> 	    Interface = object
> 	    def Attribute(name, doc): pass
> 	    def implements(interface): pass
> 	    def classProvides(interface): pass

> This code should probably be put into a common location, something
> like frontend.zopeinterface, so that it can be reused.  But eventually
> when
> IPython.core is created, this should probably be moved there.

Sounds good.

> The docstrings are vague and outdated at points.  More detailed and
> updated docstrings would be helpful.  Also, all docstrings should use
> the epydoc+ReST format.

Oh yes, definitely. The docstring are not good enough, and some of the
names are not explicite enough.

> IPython.kernel.core should probably be moved to IPython.core.

> Once Fernando's testing branch has been merged, more tests should be written.

+1. My stuff is hard to test, but I want to have a go and see what I can
do.

> frontendbase.py
> ===============

> Configuration should be done using the approach in IPython.config.
> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
> examples.

OK.

> IFrontEnd has references to Twisted in its docstrings.  Because the
> basic frontend should work without Twisted, the docstrings should be
> updated to clarify how the interface plays with Twisted, even though
> it is optional.  We really want to document for developers that the
> base frontend is synchronous and doesn't require Twisted, but that the
> interface has a particular design that allows it to be wrapped into an
> asynchronous frontend (like some methods pass through the result).

> The design of the frontend seems good though.  We might eventually
> want to think about using the notification stuff in the frontend
> though.

> Why does FrontEndBase not have a complete method?  Other frontend
> classes do have this method and its seems like the base class should
> have it too. 

I need to come back on all this and define the interfaces in a more
formal way. Currently this is messy, and I have been coding the frontend
implementation to figure out what the right interface is. So yes, I'll do
that before the merge.

> Also, there are oher methods in the interpreter that we
> might want to propagate up to the frontend, like push and pull.
> Thoughts? 

Not sure this is urgent. I haven't used them so far. But maybe. I want to
have a "pyshell" interface for my frontend, maybe in a subclass. This is
important as the frontend should be a drop-in replacmeent for pyshell.

> prefilterfrontend.py
> ====================

> It is fantastic that we can combine ipython0 and IPython.kernel.core
> code like this.  This is a great way of using the new stuff, but
> getting the more complete feature set of IPython.*  But I think this
> type of thing should be done in the lower-level Interpreter, rather
> than the frontend.  This is for a couple of reasons:

> 	1. This would give all users of the Interpreter access to completion and the
> 	   prefilter stuff.  We really need this stuff in the parallel
> computing stuff,
> 	   as well as non-line-oriented frontends.
> 	2. The Interpreter already has some of this logic and it is simply being
> 	   repeated.
> 	3. The current implementation requires that the Interpreter is in-process.
> 	   For connecting to a remote Interpreter, this won't work.

Absolutely. This is an experiment, and I was waiting for Fernando to be
done with his testing to be able to work on that. prefilterfrontend.py
should be called "dirtyhackfrontend.py" IMHO.

> But, we might run into a problem with doing this stuff (that cool hack
> that is begin used currently) in the Interpreter.  The reason is that
> the Interpreter is block based, whereas the prefilter stuff in IPython
> is only line based.  Thus, doing this refactoring might be a little
> more involved.  But it is the eventual design we want to go for.  This
> stuff probably won't be done before the merge. We can work on this at
> SciPy.

Once again, thanks a lot for your detailed feedback, it is very valuable
to me.

Ga?l


From barrywark at gmail.com  Thu Aug  7 19:36:52 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 7 Aug 2008 19:36:52 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
Message-ID: <cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>

Brian et al.,

I don't have time to give your comments the time they deserve tonight
so I wanted to just weigh in quickly on merging Gael's branch before
the upcoming release. There are some significant changes I want to
make to the frontendbase interface, mainly making the concept of a
execution block more explicit, but I realize Gael has made great
progress with his branch that diverged before I made those changes. I
think the synchronous frontend should be merged in for the release if
possible. I will hold of on my changes until the release has settled
and we have time to evaluate how the newer frontend architecture. I
have just one other comment, in line below, for the moment and will
try to get you a more proper response soon.

On Thu, Aug 7, 2008 at 2:11 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hello all (especially Barry and Gael),
>
> We would like to merge the ipython-sync-frontend branch into trunk
> ASAP.  Fernando will be sending out an email later today describing
> our timeframe for the upcoming release.  Meanwhile, I wanted to
> provide some informal code review and feedback on the stuff in
> IPython.frontend.  I haven't looked over the wx or cocoa specific
> stuff, just the general stuff.
>
> Overall, I am _really_ excited about this code.  Many thanks to Barry
> and Gael for pushing this stuff forward and making the first go and
> using the new core.  I talked to Fernando last night and both of us
> are completely committed to getting this stuff into the next IPython
> release, which is coming soon.  I should preface my comments by saying
> that I don't think all of the comments need to be address before the
> merge or the release.  Some of the comments are more long term.  Also,
> Fernando is going to look over the new stuff in IPython.kernel.core (I
> haven't looked at this stuff).
>
>
> Here are my comments:
>
> ===============================
> Comments about IPython.frontend
> ===============================
>
> General
> =======
>
> We need a robust way for modules in the frontend to handle interfaces
> if zope.interface is not installed.  Currently each module tries to
> import zope.interface and then builds a mock zope.interface, like
> this::
>
>        try:
>            from zope.interface import Interface, Attribute, implements, classProvides
>        except ImportError:
>            Interface = object
>            def Attribute(name, doc): pass
>            def implements(interface): pass
>            def classProvides(interface): pass
>
> This code should probably be put into a common location, something
> like frontend.zopeinterface, so that it can be reused.  But eventually
> when
> IPython.core is created, this should probably be moved there.
>
> The docstrings are vague and outdated at points.  More detailed and
> updated docstrings would be helpful.  Also, all docstrings should use
> the epydoc+ReST format.
>
> IPython.kernel.core should probably be moved to IPython.core.
>
> Once Fernando's testing branch has been merged, more tests should be written.
>
> frontendbase.py
> ===============
>
> Configuration should be done using the approach in IPython.config.
> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
> examples.
>
> IFrontEnd has references to Twisted in its docstrings.  Because the
> basic frontend should work without Twisted, the docstrings should be
> updated to clarify how the interface plays with Twisted, even though
> it is optional.  We really want to document for developers that the
> base frontend is synchronous and doesn't require Twisted, but that the
> interface has a particular design that allows it to be wrapped into an
> asynchronous frontend (like some methods pass through the result).
>
> The design of the frontend seems good though.  We might eventually
> want to think about using the notification stuff in the frontend
> though.
>
> Why does FrontEndBase not have a complete method?  Other frontend
> classes do have this method and its seems like the base class should
> have it too.  Also, there are oher methods in the interpreter that we
> might want to propagate up to the frontend, like push and pull.
> Thoughts?  If these additional methods go in, there should be separate
> asynchronous versions that return deferreds, but these would go into
> asyncfrontend.py.
>
> asyncfrontendbase.py
> ====================
>
> Because this frontend us designed for use with Twisted, I don't think
> we need to protect the zope.interface and Twisted imports.  Also setting
> Failure to Exception will break things as they don't have the same interface.
>
> Design looks good though.
>
> linefrontendbase.py
> ===================
>
> This looks good as it is simply a concrete subclass of FrontEndBase.
> General comments above about docstrings apply.
>
> prefilterfrontend.py
> ====================
>
> It is fantastic that we can combine ipython0 and IPython.kernel.core
> code like this.  This is a great way of using the new stuff, but
> getting the more complete feature set of IPython.*  But I think this
> type of thing should be done in the lower-level Interpreter, rather
> than the frontend.  This is for a couple of reasons:
>
>        1. This would give all users of the Interpreter access to completion and the
>           prefilter stuff.  We really need this stuff in the parallel
> computing stuff,
>           as well as non-line-oriented frontends.
>        2. The Interpreter already has some of this logic and it is simply being
>           repeated.
>        3. The current implementation requires that the Interpreter is in-process.
>           For connecting to a remote Interpreter, this won't work.
>
> But, we might run into a problem with doing this stuff (that cool hack
> that is begin used currently) in the Interpreter.  The reason is that
> the Interpreter is block based, whereas the prefilter stuff in IPython
> is only line based.  Thus, doing this refactoring might be a little
> more involved.  But it is the eventual design we want to go for.  This
> stuff probably won't be done before the merge. We can work on this at
> SciPy.

I think we should, as Gael points out, think carefully about design
decisions early on. Namely, is there a philosophy about what belongs
in the core, what in the Interpreter itself, and what in the, e.g.
frontend? I tend to think that the Interpreter should be *just* an
enhanced python execution engine, knowing as little as possible about
where input comes from or where it goes. Even the terminal frontend is
a frontend. Similarly, the more we can separate the concerns of
input/output from the Interpreter the easier it is to move things
between processes/hosts/etc. later on. I realize there is a tension
between those who want a lean, fast, Interpreter and those who want an
abstracted, layered architecture. I obviously don't have the solution,
but hope that in the coming days/weeks we could all articulate a
philosophy or blueprint for where we want things to end up.

>
>
> Great work everyone!!!

Thanks. Cheers,
Barry

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


From barrywark at gmail.com  Thu Aug  7 19:40:37 2008
From: barrywark at gmail.com (Barry Wark)
Date: Thu, 7 Aug 2008 19:40:37 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <20080807191812.GD26341@phare.normalesup.org>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<20080807191812.GD26341@phare.normalesup.org>
Message-ID: <cd7634ce0808071640m6714408by3b9e3d2d3f9b69a1@mail.gmail.com>

On Thu, Aug 7, 2008 at 3:18 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi Brian,
>
> Thanks a lot for your comments, they are very valuable.
>
> I have to run to catch St?fan at the airport, I just wanted to give an
> informal overview of the status of my work. I am currently battling with
> subprocess execution, including under windows. The hard stuff is the
> stdin capture, and it happens more often than I would like. Once I am
> done with that (hopefully today, though my afternoon will be busy working
> with St?fan), I have to make sure that 'Ctrl-C' stops Python execution,
> which should be easy. After this I was planning to clean up the code, add
> comments and ask for merge.
>
> All your comments are very much to the points. Some of them where already
> on my todo list. Can you prioritize them, and tell me at which point I
> should do the merge. I also would like to merge ASAP, I just don't want
> to have bad crashers in the code before I merge (but if you think it is
> acceptable, I'll go for it), and I want to refactor some names and
> interfaces before the merge. Hopefully merge is a few work days away. Is
> that good enough, or should I try to get this done faster?
>
> Obviously this is a first cut, and there will be some lessons to learn.
>
>> We need a robust way for modules in the frontend to handle interfaces
>> if zope.interface is not installed.  Currently each module tries to
>> import zope.interface and then builds a mock zope.interface, like
>> this::
>
>>       try:
>>           from zope.interface import Interface, Attribute, implements, classProvides
>>       except ImportError:
>>           Interface = object
>>           def Attribute(name, doc): pass
>>           def implements(interface): pass
>>           def classProvides(interface): pass
>
>> This code should probably be put into a common location, something
>> like frontend.zopeinterface, so that it can be reused.  But eventually
>> when
>> IPython.core is created, this should probably be moved there.
>
> Sounds good.
>
>> The docstrings are vague and outdated at points.  More detailed and
>> updated docstrings would be helpful.  Also, all docstrings should use
>> the epydoc+ReST format.
>
> Oh yes, definitely. The docstring are not good enough, and some of the
> names are not explicite enough.
>
>> IPython.kernel.core should probably be moved to IPython.core.
>
>> Once Fernando's testing branch has been merged, more tests should be written.
>
> +1. My stuff is hard to test, but I want to have a go and see what I can
> do.

Please, please have (near) complete test coverage for your work. It
will be infinitely harder to make the (likely) needed refactorings in
the future if we can't test easily. I've been working on several
changes to the internal working of FrontEndBase to make notebook-style
interfaces more natural and think that I can keep backwards compatible
API, but the implementation may change. Complete test will make
integrating those changes much easier.

>
>> frontendbase.py
>> ===============
>
>> Configuration should be done using the approach in IPython.config.
>> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
>> examples.
>
> OK.
>
>> IFrontEnd has references to Twisted in its docstrings.  Because the
>> basic frontend should work without Twisted, the docstrings should be
>> updated to clarify how the interface plays with Twisted, even though
>> it is optional.  We really want to document for developers that the
>> base frontend is synchronous and doesn't require Twisted, but that the
>> interface has a particular design that allows it to be wrapped into an
>> asynchronous frontend (like some methods pass through the result).
>
>> The design of the frontend seems good though.  We might eventually
>> want to think about using the notification stuff in the frontend
>> though.
>
>> Why does FrontEndBase not have a complete method?  Other frontend
>> classes do have this method and its seems like the base class should
>> have it too.
>
> I need to come back on all this and define the interfaces in a more
> formal way. Currently this is messy, and I have been coding the frontend
> implementation to figure out what the right interface is. So yes, I'll do
> that before the merge.
>
>> Also, there are oher methods in the interpreter that we
>> might want to propagate up to the frontend, like push and pull.
>> Thoughts?
>
> Not sure this is urgent. I haven't used them so far. But maybe. I want to
> have a "pyshell" interface for my frontend, maybe in a subclass. This is
> important as the frontend should be a drop-in replacmeent for pyshell.
>
>> prefilterfrontend.py
>> ====================
>
>> It is fantastic that we can combine ipython0 and IPython.kernel.core
>> code like this.  This is a great way of using the new stuff, but
>> getting the more complete feature set of IPython.*  But I think this
>> type of thing should be done in the lower-level Interpreter, rather
>> than the frontend.  This is for a couple of reasons:
>
>>       1. This would give all users of the Interpreter access to completion and the
>>          prefilter stuff.  We really need this stuff in the parallel
>> computing stuff,
>>          as well as non-line-oriented frontends.
>>       2. The Interpreter already has some of this logic and it is simply being
>>          repeated.
>>       3. The current implementation requires that the Interpreter is in-process.
>>          For connecting to a remote Interpreter, this won't work.
>
> Absolutely. This is an experiment, and I was waiting for Fernando to be
> done with his testing to be able to work on that. prefilterfrontend.py
> should be called "dirtyhackfrontend.py" IMHO.
>
>> But, we might run into a problem with doing this stuff (that cool hack
>> that is begin used currently) in the Interpreter.  The reason is that
>> the Interpreter is block based, whereas the prefilter stuff in IPython
>> is only line based.  Thus, doing this refactoring might be a little
>> more involved.  But it is the eventual design we want to go for.  This
>> stuff probably won't be done before the merge. We can work on this at
>> SciPy.
>
> Once again, thanks a lot for your detailed feedback, it is very valuable
> to me.
>
> Ga?l
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Fri Aug  8 05:05:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 02:05:54 -0700
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <20080807191812.GD26341@phare.normalesup.org>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<20080807191812.GD26341@phare.normalesup.org>
Message-ID: <db6b5ecc0808080205m7d45f6dam36d72d6b6a7a8407@mail.gmail.com>

Howdy,

On Thu, Aug 7, 2008 at 12:18 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi Brian,
>
> Thanks a lot for your comments, they are very valuable.
>
> I have to run to catch St?fan at the airport, I just wanted to give an
> informal overview of the status of my work. I am currently battling with
> subprocess execution, including under windows. The hard stuff is the
> stdin capture, and it happens more often than I would like. Once I am
> done with that (hopefully today, though my afternoon will be busy working
> with St?fan), I have to make sure that 'Ctrl-C' stops Python execution,
> which should be easy. After this I was planning to clean up the code, add
> comments and ask for merge.

I'm going to put in here my comments regarding the code in
kernel.core, and will send  a separate email regarding merge plans,
since Barry made some comments on that matter too.

Modulo any possible conflicts with Barry's changes that we might need
to sort out, I think we can also merge in what you've done, so we have
an integrated codebase to work off from at scipy.

My comments follow, some are generic about files that were in
kernel.core before your branch, and some are specific to your code.
Overall I don't see any problem though, so I think it's just a matter
of moving forward with minimal collisions.

====================================
 Comments about IPython.kernel.core
====================================

General
=======

We'll likely push this over as IPython.core, but I'd like to do this after we
get this release out.  It will be much easier to do this refactoring at SciPy,
where at the very least we'll have Brian, Gael, Stefan and myself present, plus
other possible volunteers.  For now it's OK to do the merge where the code is.

General naming comment: we have a ton of modules_with_underscores in their
names.  In trying to keep to pep-8, let's at least make an effort to not let
this grow unnecessarily (while keeping in mind pep-8's first advice, "A Foolish
Consistency is the Hobgoblin of Little Minds" :)  Note: I'm not being petty
here, I actually happen to like the package namespace to use that convention...

Some of my comments below relate to code in kernel.core in general, not
specifically to Gael's recent changes.


Testing
=======

Ultimately I'd like us to be able to run a substantial fraction of the test
suite against each frontend, to ensure that the basic session runs in each
correctly.  This won't probe the UI aspects, but it will ensure that all
frontends conform to the same uses of the core objects for namespace handling,
completion, history, etc.  If it's not possible right now to do this, it should
be a high priority to enable the current code to run the tests.  This might be
a job for scipy so we can do it together.

In the meantime, I concur with Barry's assessment of the need for more tests.
I expect we'll be refactoring like mad at Scipy, and doing so without tests is
like juggling dual-edge knifes with no handles.

Even if there's no time for detailed coverage, at least having a set of small,
near-trivial tests for each file that minimally call the various
functions/methods makes a big difference.  They may not cover every corner
case, but they ensure that key invariants are honored, and they remind you of
what API breakage you're likely to incur when moving stuff around.


display_formatter.py
====================

[ This file is in trunk, so the comments apply to all of us, not specifically
to Gael's changes ]

I'm assuming that the return value must always be a string (or None), right?
Since this is meant to declare the interface, it should be explicit about the
valid return types.


display_trap.py
===============

[ This file is in trunk, so the comments apply to all of us, not specifically
to Gael's changes ]

What exactly is the purpose of the callback list?  Since the callbacks don't
return anything, what exactly are they supposed to do?

The slight lack of tests/fuller docstrings already mentioned needs some work.
 On the topic of docstrings, let's keep to pep-8 convention: one-line summary,
blank, full text (using reST format).  There are GUI tools that use the
one-line summary, and I'd like the GUI ipython versions to provide nice api
summaries of objects.  This works better if you can assume that the first line
is readable by itself.  add_to_message doesn't conform to this, for
example. __init__ needs a docstring

In hook, shouldn't obj be stored first, in case an error is raised by a
callback?  And how are errors in callbacks handled?


fd_redirector
=============

I imagine this is the part you've been struggling with, from your comments.  We
certainly need this to gracefully handle i/o under GUIs.  Docstrings and tests
are critically needed though, and the docstrings should conform to the reST api
for sphinx.

All attributes should be declared in the constructor, even if they are set to
None with a comment of what they do and that their true value is given later
(such as in start() ).  The fact that Python allows us to create attributes at
any point doesn't mean we should do it in normal code, its a feature whose
valid use cases are in decorating/annotating external objects.  But classes we
write should declare their attribute API completely in the constructor, for
readability/comprehensibility reasons.

Is it necessary to call stop() in getvalue()?

file_like.py
============

- writelines should read simply "map(self.write,lines)".  Faster, cleaner,
shorter.

- why are the other methods implemented as 'pass'?  Wouldn't it be better not
  to have them?  Making them pass means they return None, which can lead to
  them being used by other code which will then strangely break when None is
  the wrong thing to get.


output_trap.py
==============

This one implements a smaller set of functionality than the original
OutputTrap.  Why?  Do we need to merge the two?  Right now we have in
core.shell uses of the old module and in core.interpreter, of the new, so
likely some sort of merge will be needed.


redirector_output_trap.py
=========================

No docstrings on constructor.


sync_traceback_trap.py
======================

No docstrings on constructor.   The top-level docstring could be a bit more
verbose.


From fperez.net at gmail.com  Fri Aug  8 05:34:44 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 02:34:44 -0700
Subject: [IPython-dev] Release plan for 0.9
Message-ID: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>

Hi all,

recently a lot of activity on ipython has been happening in three
branches: one for testing support that I'm working on, one for
notifications by Barry and one for the wx frontend by Gael.  With
Scipy fast approaching and Enthought planning an EPD release next
week, we'd like to cut a release now.  The 'ipython0' functionality
will for now remain mostly unchanged, other than being (partly) tested
for the first time.  Gael's and Barry's work are mostly infrastructure
for moving forward, and we have all the IPython1 code now merged in.

So the question is how to make this merge happen.  Here's the branches we have:

1. Testing support code that lives in

https://code.launchpad.net/~ipython/ipython/test-tools

That touches code in quite a few places but in a mostly harmless
manner, and builds tools for testing that are as of yet a bit
developer-only.  I'll put the user-sugar on top later.

I've made the branch proposed for merging, which shows exactly what
revisions haven't been merged yet.  Unless anyone sees a problem, I'll
merge this tomorrow.

2. Gael's work hasn't been merged at all yet.  I marked it for merging:

https://code.launchpad.net/~gael-varoquaux/ipython/ipython-sync-frontend


3. Barry's notification branch has been merged.

4. Vivian's editor branch:

https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor

I'm sorry that I haven't been following this one in detail.  Vivian
and Ville had been working on it together, is it basically ready for
merge?  If so, marking it 'proposed for merge' will let us easily
review it and see what changesets are different from trunk (I just did
that).  Ville had some comments on it, have they been addressed by the
latest changesets?


5. Ville's pyreadline branch:

https://code.launchpad.net/~villemvainio/ipython/pyreadline

This branch shows no code yet.  Ville, what's your plan on this one?

6. Robert Kern's contexts branch:

https://code.launchpad.net/~robert-kern/ipython/contexts

Robert, what's your plan on this one?  Keep it as branch for now, or
push it into this release?


7. Min's daemon branch:

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

Min, what's your take on this?  Do you want it merged in, or should we
postpone this to work on it at scipy?  This is extremely important
functionality, but I don't know if it's solid enough for merge yet. I
marked it for merging so we can see the differences more easily.

# end branches

Whew.  That's actually a lot...

Does anyone else have anything in the pipeline that they want in for a
release?  Keep in mind that this will be very much a 'tech preview'
release, whose purpose is the large codebase integration of
ipython0/1.  I'm sure we'll see some rough spots, and I hope at Scipy
we'll have a chance to work together on smoothing them.  So I expect
to be putting out a 0.10 fairly close after this.

Which means that if a particular feature you have in mind or in a
branch isn't quite ready, no worries.  0.10 should be not too far
behind.


So with this, it would be nice if we could cut an RC for 0.9 on Monday.

I'll be likely merging the testing stuff tomorrow, and after that the
two big ones seem to be Gael's and Min's.  Thoughts?

f


From fperez.net at gmail.com  Fri Aug  8 05:36:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 02:36:20 -0700
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
Message-ID: <db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>

Hi Barry,

On Thu, Aug 7, 2008 at 4:36 PM, Barry Wark <barrywark at gmail.com> wrote:
> Brian et al.,
>
> I don't have time to give your comments the time they deserve tonight
> so I wanted to just weigh in quickly on merging Gael's branch before
> the upcoming release. There are some significant changes I want to
> make to the frontendbase interface, mainly making the concept of a
> execution block more explicit, but I realize Gael has made great
> progress with his branch that diverged before I made those changes. I
> think the synchronous frontend should be merged in for the release if
> possible. I will hold of on my changes until the release has settled
> and we have time to evaluate how the newer frontend architecture. I
> have just one other comment, in line below, for the moment and will
> try to get you a more proper response soon.

Do you have a sense of how serious the conflicts are?  I've marked
Gael's branch and my testing one 'for merge' so we can easily see the
differences.

And will you be attending SciPy?  It seems Brian will be there, and so
will Gael and Stefan, so we may have a bunch of people simultaneously
available to discuss and hack (and anyone else on the list who will
make it to scipy is obviously welcome!).

Cheers,
f


From barrywark at gmail.com  Fri Aug  8 10:15:46 2008
From: barrywark at gmail.com (Barry Wark)
Date: Fri, 8 Aug 2008 10:15:46 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
Message-ID: <cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>

On Fri, Aug 8, 2008 at 5:36 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi Barry,
>
> On Thu, Aug 7, 2008 at 4:36 PM, Barry Wark <barrywark at gmail.com> wrote:
>> Brian et al.,
>>
>> I don't have time to give your comments the time they deserve tonight
>> so I wanted to just weigh in quickly on merging Gael's branch before
>> the upcoming release. There are some significant changes I want to
>> make to the frontendbase interface, mainly making the concept of a
>> execution block more explicit, but I realize Gael has made great
>> progress with his branch that diverged before I made those changes. I
>> think the synchronous frontend should be merged in for the release if
>> possible. I will hold of on my changes until the release has settled
>> and we have time to evaluate how the newer frontend architecture. I
>> have just one other comment, in line below, for the moment and will
>> try to get you a more proper response soon.
>
> Do you have a sense of how serious the conflicts are?  I've marked
> Gael's branch and my testing one 'for merge' so we can easily see the
> differences.

Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
and asyncfrontendbase et al), the most significant diff between Gael's
branch and mine is that I've made the concept of an execution Block
more explicit. Instead of just an input string, a block is now an
object containing prompts, input and output as well as, possibly,
sub-blocks. The Block maps, conceptually, pretty directly to a
Mathematica notebook cell (you can see the Block definition in my
ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
that the API for FrontEndBase can be made largely backwards
compatible, but some of the internal implementation must change to
support passing around Blocks instead of just strings.

OK, so I'd say the conflicts will not be too serious. They may be
serious enough to merge one at a time, especially working up to a
release. I'll hold off on my branch until things settle out from
Gael's merge.

>
> And will you be attending SciPy?  It seems Brian will be there, and so
> will Gael and Stefan, so we may have a bunch of people simultaneously
> available to discuss and hack (and anyone else on the list who will
> make it to scipy is obviously welcome!).

Unfortunately, I can't make it. I'd be happy to check in remotely
(Skype etc.) while you all are working if that makes sense.

>
> Cheers,
> f
>


From barrywark at gmail.com  Fri Aug  8 10:24:16 2008
From: barrywark at gmail.com (Barry Wark)
Date: Fri, 8 Aug 2008 10:24:16 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <db6b5ecc0808080205m7d45f6dam36d72d6b6a7a8407@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<20080807191812.GD26341@phare.normalesup.org>
	<db6b5ecc0808080205m7d45f6dam36d72d6b6a7a8407@mail.gmail.com>
Message-ID: <cd7634ce0808080724t484c9d8bi75bde648d5abe210@mail.gmail.com>

On Fri, Aug 8, 2008 at 5:05 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> On Thu, Aug 7, 2008 at 12:18 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> Hi Brian,
>>
>> Thanks a lot for your comments, they are very valuable.
>>
>> I have to run to catch St?fan at the airport, I just wanted to give an
>> informal overview of the status of my work. I am currently battling with
>> subprocess execution, including under windows. The hard stuff is the
>> stdin capture, and it happens more often than I would like. Once I am
>> done with that (hopefully today, though my afternoon will be busy working
>> with St?fan), I have to make sure that 'Ctrl-C' stops Python execution,
>> which should be easy. After this I was planning to clean up the code, add
>> comments and ask for merge.
>
> I'm going to put in here my comments regarding the code in
> kernel.core, and will send  a separate email regarding merge plans,
> since Barry made some comments on that matter too.
>
> Modulo any possible conflicts with Barry's changes that we might need
> to sort out, I think we can also merge in what you've done, so we have
> an integrated codebase to work off from at scipy.
>
> My comments follow, some are generic about files that were in
> kernel.core before your branch, and some are specific to your code.
> Overall I don't see any problem though, so I think it's just a matter
> of moving forward with minimal collisions.
>
> ====================================
>  Comments about IPython.kernel.core
> ====================================
>
> General
> =======
>
> We'll likely push this over as IPython.core, but I'd like to do this after we
> get this release out.  It will be much easier to do this refactoring at SciPy,
> where at the very least we'll have Brian, Gael, Stefan and myself present, plus
> other possible volunteers.  For now it's OK to do the merge where the code is.
>
> General naming comment: we have a ton of modules_with_underscores in their
> names.  In trying to keep to pep-8, let's at least make an effort to not let
> this grow unnecessarily (while keeping in mind pep-8's first advice, "A Foolish
> Consistency is the Hobgoblin of Little Minds" :)  Note: I'm not being petty
> here, I actually happen to like the package namespace to use that convention...
>
> Some of my comments below relate to code in kernel.core in general, not
> specifically to Gael's recent changes.
>
>
> Testing
> =======
>
> Ultimately I'd like us to be able to run a substantial fraction of the test
> suite against each frontend, to ensure that the basic session runs in each
> correctly.  This won't probe the UI aspects, but it will ensure that all
> frontends conform to the same uses of the core objects for namespace handling,
> completion, history, etc.  If it's not possible right now to do this, it should
> be a high priority to enable the current code to run the tests.  This might be
> a job for scipy so we can do it together.
>
> In the meantime, I concur with Barry's assessment of the need for more tests.
> I expect we'll be refactoring like mad at Scipy, and doing so without tests is
> like juggling dual-edge knifes with no handles.
>
> Even if there's no time for detailed coverage, at least having a set of small,
> near-trivial tests for each file that minimally call the various
> functions/methods makes a big difference.  They may not cover every corner
> case, but they ensure that key invariants are honored, and they remind you of
> what API breakage you're likely to incur when moving stuff around.
>
>
> display_formatter.py
> ====================
>
> [ This file is in trunk, so the comments apply to all of us, not specifically
> to Gael's changes ]
>
> I'm assuming that the return value must always be a string (or None), right?
> Since this is meant to declare the interface, it should be explicit about the
> valid return types.

I'd like to play devil's advocate for a minute here: I think display
formatting should be done exclusively in the frontend. If not,
frontends have no choice what to do with, e.g. matplotlib figures.
Putting it in core smells of the poor separation of concerns we have
in the ipython0 shell.

>
>
> display_trap.py
> ===============
>
> [ This file is in trunk, so the comments apply to all of us, not specifically
> to Gael's changes ]
>
> What exactly is the purpose of the callback list?  Since the callbacks don't
> return anything, what exactly are they supposed to do?
>
> The slight lack of tests/fuller docstrings already mentioned needs some work.
>  On the topic of docstrings, let's keep to pep-8 convention: one-line summary,
> blank, full text (using reST format).  There are GUI tools that use the
> one-line summary, and I'd like the GUI ipython versions to provide nice api
> summaries of objects.  This works better if you can assume that the first line
> is readable by itself.  add_to_message doesn't conform to this, for
> example. __init__ needs a docstring
>
> In hook, shouldn't obj be stored first, in case an error is raised by a
> callback?  And how are errors in callbacks handled?
>
>
> fd_redirector
> =============
>
> I imagine this is the part you've been struggling with, from your comments.  We
> certainly need this to gracefully handle i/o under GUIs.  Docstrings and tests
> are critically needed though, and the docstrings should conform to the reST api
> for sphinx.
>
> All attributes should be declared in the constructor, even if they are set to
> None with a comment of what they do and that their true value is given later
> (such as in start() ).  The fact that Python allows us to create attributes at
> any point doesn't mean we should do it in normal code, its a feature whose
> valid use cases are in decorating/annotating external objects.  But classes we
> write should declare their attribute API completely in the constructor, for
> readability/comprehensibility reasons.
>
> Is it necessary to call stop() in getvalue()?
>
> file_like.py
> ============
>
> - writelines should read simply "map(self.write,lines)".  Faster, cleaner,
> shorter.
>
> - why are the other methods implemented as 'pass'?  Wouldn't it be better not
>  to have them?  Making them pass means they return None, which can lead to
>  them being used by other code which will then strangely break when None is
>  the wrong thing to get.
>
>
> output_trap.py
> ==============
>
> This one implements a smaller set of functionality than the original
> OutputTrap.  Why?  Do we need to merge the two?  Right now we have in
> core.shell uses of the old module and in core.interpreter, of the new, so
> likely some sort of merge will be needed.
>
>
> redirector_output_trap.py
> =========================
>
> No docstrings on constructor.
>
>
> sync_traceback_trap.py
> ======================
>
> No docstrings on constructor.   The top-level docstring could be a bit more
> verbose.

Again, playing Devi's advocate: Much of what appears to be the
function of output_trap, sync_traceback_trap, and display_trap could
be handled in frontend by posting notifications from the Interpreter.
Doing so would separate these UI concerns (i.e. what to do with the
Interpreter's output) from the core function (producing that output).

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


From gael.varoquaux at normalesup.org  Fri Aug  8 11:43:18 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 8 Aug 2008 17:43:18 +0200
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready	for merge of ipython-sync-frontend
In-Reply-To: <cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
	<cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
Message-ID: <20080808154318.GA32657@phare.normalesup.org>

On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote:
> > Do you have a sense of how serious the conflicts are?  I've marked
> > Gael's branch and my testing one 'for merge' so we can easily see the
> > differences.

> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
> and asyncfrontendbase et al), the most significant diff between Gael's
> branch and mine is that I've made the concept of an execution Block
> more explicit. Instead of just an input string, a block is now an
> object containing prompts, input and output as well as, possibly,
> sub-blocks. The Block maps, conceptually, pretty directly to a
> Mathematica notebook cell (you can see the Block definition in my
> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
> that the API for FrontEndBase can be made largely backwards
> compatible, but some of the internal implementation must change to
> support passing around Blocks instead of just strings.

> OK, so I'd say the conflicts will not be too serious. They may be
> serious enough to merge one at a time, especially working up to a
> release. I'll hold off on my branch until things settle out from
> Gael's merge.


Barry, do you want check in access to my branch to implement these
changes. I was waiting to add docstrings and tests before proposing this,
but if you think you want to do this ASAP, I don't mind at all. I don't
think I'll be able to merge before Sunday, though.

Ga?l


From barrywark at gmail.com  Fri Aug  8 11:57:27 2008
From: barrywark at gmail.com (Barry Wark)
Date: Fri, 8 Aug 2008 11:57:27 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <20080808154318.GA32657@phare.normalesup.org>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
	<cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
	<20080808154318.GA32657@phare.normalesup.org>
Message-ID: <cd7634ce0808080857o41c76670k21fbd119fb41d261@mail.gmail.com>

On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote:
>> > Do you have a sense of how serious the conflicts are?  I've marked
>> > Gael's branch and my testing one 'for merge' so we can easily see the
>> > differences.
>
>> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
>> and asyncfrontendbase et al), the most significant diff between Gael's
>> branch and mine is that I've made the concept of an execution Block
>> more explicit. Instead of just an input string, a block is now an
>> object containing prompts, input and output as well as, possibly,
>> sub-blocks. The Block maps, conceptually, pretty directly to a
>> Mathematica notebook cell (you can see the Block definition in my
>> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
>> that the API for FrontEndBase can be made largely backwards
>> compatible, but some of the internal implementation must change to
>> support passing around Blocks instead of just strings.
>
>> OK, so I'd say the conflicts will not be too serious. They may be
>> serious enough to merge one at a time, especially working up to a
>> release. I'll hold off on my branch until things settle out from
>> Gael's merge.
>
>
> Barry, do you want check in access to my branch to implement these
> changes. I was waiting to add docstrings and tests before proposing this,
> but if you think you want to do this ASAP, I don't mind at all. I don't
> think I'll be able to merge before Sunday, though.

Thanks for the offer. I think making even relatively minor
architectural changes close before a release, while your code is still
under active development, and without *really* good test coverage is
dangerous. I'm not going to have time to give this the time it would
require before early next week when Fernando wants to push a release.
So I'd say the safest & best plan is to let you try to get your code
ready for release in time. I'll merge my changes in on the next dev
cycle.

>
> Ga?l
>


From ellisonbg.net at gmail.com  Fri Aug  8 12:50:12 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Fri, 8 Aug 2008 10:50:12 -0600
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <cd7634ce0808080857o41c76670k21fbd119fb41d261@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
	<cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
	<20080808154318.GA32657@phare.normalesup.org>
	<cd7634ce0808080857o41c76670k21fbd119fb41d261@mail.gmail.com>
Message-ID: <6ce0ac130808080950m224f7eaal31ad0de64f135626@mail.gmail.com>

Hello all,

Unfortunately, today is the day that we are moving into our new place.
 Thus, I will be mostly offline until early next week unless I can
sneak out to a coffee house some night.  Fernando can help make any
decisions about how to proceed with the merges.  Thanks again everyone
for helping out.

Cheers,

Brian

On Fri, Aug 8, 2008 at 9:57 AM, Barry Wark <barrywark at gmail.com> wrote:
> On Fri, Aug 8, 2008 at 11:43 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Fri, Aug 08, 2008 at 10:15:46AM -0400, Barry Wark wrote:
>>> > Do you have a sense of how serious the conflicts are?  I've marked
>>> > Gael's branch and my testing one 'for merge' so we can easily see the
>>> > differences.
>>
>>> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
>>> and asyncfrontendbase et al), the most significant diff between Gael's
>>> branch and mine is that I've made the concept of an execution Block
>>> more explicit. Instead of just an input string, a block is now an
>>> object containing prompts, input and output as well as, possibly,
>>> sub-blocks. The Block maps, conceptually, pretty directly to a
>>> Mathematica notebook cell (you can see the Block definition in my
>>> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
>>> that the API for FrontEndBase can be made largely backwards
>>> compatible, but some of the internal implementation must change to
>>> support passing around Blocks instead of just strings.
>>
>>> OK, so I'd say the conflicts will not be too serious. They may be
>>> serious enough to merge one at a time, especially working up to a
>>> release. I'll hold off on my branch until things settle out from
>>> Gael's merge.
>>
>>
>> Barry, do you want check in access to my branch to implement these
>> changes. I was waiting to add docstrings and tests before proposing this,
>> but if you think you want to do this ASAP, I don't mind at all. I don't
>> think I'll be able to merge before Sunday, though.
>
> Thanks for the offer. I think making even relatively minor
> architectural changes close before a release, while your code is still
> under active development, and without *really* good test coverage is
> dangerous. I'm not going to have time to give this the time it would
> require before early next week when Fernando wants to push a release.
> So I'd say the safest & best plan is to let you try to get your code
> ready for release in time. I'll merge my changes in on the next dev
> cycle.
>
>>
>> Ga?l
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From robert.kern at gmail.com  Fri Aug  8 16:00:02 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 08 Aug 2008 15:00:02 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
Message-ID: <g7i8k2$fvj$2@ger.gmane.org>

Fernando Perez wrote:
> 6. Robert Kern's contexts branch:
> 
> https://code.launchpad.net/~robert-kern/ipython/contexts
> 
> Robert, what's your plan on this one?  Keep it as branch for now, or
> push it into this release?

I think it can be pushed.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From gael.varoquaux at normalesup.org  Fri Aug  8 16:24:39 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 8 Aug 2008 22:24:39 +0200
Subject: [IPython-dev] ipython1 and synchronous printing of stdout
In-Reply-To: <200808082218.50243.hans_meine@gmx.net>
References: <6ce0ac130807221325y19ffd8dbtafc27d1c6ca5f4ac@mail.gmail.com>
	<200808081211.23827.hans_meine@gmx.net>
	<20080808132359.GB11088@phare.normalesup.org>
	<200808082218.50243.hans_meine@gmx.net>
Message-ID: <20080808202439.GB8104@phare.normalesup.org>

On Fri, Aug 08, 2008 at 10:18:49PM +0200, Hans Meine wrote:
> >   * I execute sub-processes with anonimous-pipes as their stdin/stdout
> >     and use a separate thread to empty these pipes onto the screen
> >     without blocking.

> Hmm - since I did not write a frontend to ipython with its "!" facility, I am 
> not sure I ever tried this.  Wouldn't the filedescriptor-method also work for 
> os.system/subprocess.calls?

Hum, not really, it is cleaner to use pipe, as it allows to make sure
that stdin is in sync with stdout and stderr. That was _hard_ by the way.

> > I am anyhow interested in your ideas for that, do mind posting the link
> > to the discussion you refer to? My google foo doesn't seem to be
> > good-enough to find it.

> To be honest - if I knew how to find it again, I would have sent the link in 
> the first place.

> After some digging, I finally found it, it was in the "Changes to Notebook 
> Format" thread, and it turns out that Robert Kern actually was the one who 
> came up with the working solution.  I only later send his code (with 
> attribution) to C++-Sig, when the question was discussed there, too.
> http://mlblog.osdir.com/python.ipython.devel/2005-08/

OK, I use this, but this by itself is not sufficient, because you want to
have trap to shell back out in the GUI mainloop to refresh the screen and
process events like "Ctrl-C" every once in a while (once again,
multi-threading is unacceptable, because the GUI toolkits that we have
are not thread-safe (none is), and it would lead to crashers when the
users would input code that interacted with the GUI toolkit. I have to
build an event-driven design, but not a multithreaded design.

OK, back to doc-string writing, and test-writing.

Ga?l


From fperez.net at gmail.com  Fri Aug  8 18:41:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 15:41:23 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7i8k2$fvj$2@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
Message-ID: <db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>

On Fri, Aug 8, 2008 at 1:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Fernando Perez wrote:
>> 6. Robert Kern's contexts branch:
>>
>> https://code.launchpad.net/~robert-kern/ipython/contexts
>>
>> Robert, what's your plan on this one?  Keep it as branch for now, or
>> push it into this release?
>
> I think it can be pushed.

I see these issues (doing this on trunk):

lon[IPython]> grin make_user_ns
./Shell.py:
  567 :         user_ns = IPython.ipapi.make_user_ns(user_ns)
./ipapi.py:
  562 : def make_user_ns(user_ns = None):
  586 :     Similar to make_user_ns(), but global namespaces are
really only needed in
./iplib.py:
  287 :         user_ns = IPython.ipapi.make_user_ns(user_ns)


I don't see your changeset addressing either the Shell or the iplib
uses of this, do they?  The Shell one is in the matplotlib Shell
class.

I've now grabbed your branch, so I can test easily if you make fixes
and we can merge.  These changes are small and localized enough that
once we address this, I'm happy to do it.  It would also be good if
you add proper reST parameter descriptions to the docstrings of the
new functions you wrote.

Cheers,

f


From fperez.net at gmail.com  Fri Aug  8 18:49:15 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 15:49:15 -0700
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
	<cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
Message-ID: <db6b5ecc0808081549o65c4f58as56260dea5c08f61d@mail.gmail.com>

On Fri, Aug 8, 2008 at 7:15 AM, Barry Wark <barrywark at gmail.com> wrote:

> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
> and asyncfrontendbase et al), the most significant diff between Gael's
> branch and mine is that I've made the concept of an execution Block
> more explicit. Instead of just an input string, a block is now an
> object containing prompts, input and output as well as, possibly,
> sub-blocks. The Block maps, conceptually, pretty directly to a
> Mathematica notebook cell (you can see the Block definition in my
> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
> that the API for FrontEndBase can be made largely backwards
> compatible, but some of the internal implementation must change to
> support passing around Blocks instead of just strings.
>
> OK, so I'd say the conflicts will not be too serious. They may be
> serious enough to merge one at a time, especially working up to a
> release. I'll hold off on my branch until things settle out from
> Gael's merge.

Sounds good.  Yes, I do worry about breaking too much right before a
release.  Even though we know this will be somewhat of a 'tech
preview' release, we don't want to have a massive mess for users.

I'm working on reviewing the other branches and merging the rest right now.

>> And will you be attending SciPy?  It seems Brian will be there, and so
>> will Gael and Stefan, so we may have a bunch of people simultaneously
>> available to discuss and hack (and anyone else on the list who will
>> make it to scipy is obviously welcome!).
>
> Unfortunately, I can't make it. I'd be happy to check in remotely
> (Skype etc.) while you all are working if that makes sense.

Bummer.  We'll irc/skype then.  We should plan on having you come down
to Berkeley sometime later though.  I'll look into the logistics of a
sprint at Berkeley for perhaps early next year.

Cheers,

f


From fperez.net at gmail.com  Fri Aug  8 19:38:03 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 8 Aug 2008 16:38:03 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
Message-ID: <db6b5ecc0808081638t258acf90qe4f313cece0fc822@mail.gmail.com>

On Fri, Aug 8, 2008 at 2:34 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> recently a lot of activity on ipython has been happening in three
> branches: one for testing support that I'm working on, one for
> notifications by Barry and one for the wx frontend by Gael.  With
> Scipy fast approaching and Enthought planning an EPD release next
> week, we'd like to cut a release now.  The 'ipython0' functionality
> will for now remain mostly unchanged, other than being (partly) tested
> for the first time.  Gael's and Barry's work are mostly infrastructure
> for moving forward, and we have all the IPython1 code now merged in.
>
> So the question is how to make this merge happen.  Here's the branches we have:
>
> 1. Testing support code that lives in
>
> https://code.launchpad.net/~ipython/ipython/test-tools
>
> That touches code in quite a few places but in a mostly harmless
> manner, and builds tools for testing that are as of yet a bit
> developer-only.  I'll put the user-sugar on top later.
>
> I've made the branch proposed for merging, which shows exactly what
> revisions haven't been merged yet.  Unless anyone sees a problem, I'll
> merge this tomorrow.

OK, this has been merged into trunk.  I'll do some more work on it,
but the key pieces are all in.  I should warn that some convenience
routines aren't in place yet, so you can't quite do something like run
'ipython-test' at a shell. But I don't want to worry about that yet,
until a key namespace handling issue is fixed.

If any of the devs is interested in playing with it, there's a little
Makefile in IPython/testing/plugin that does all the nose plugin
installation/test running for you as a convenience.  Just edit the
install path for the nose plugin at the top.  Later I'll add a
top-level user script that handles all this transparently.

Cheers,

f


From jdh2358 at gmail.com  Sat Aug  9 11:57:20 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Sat, 9 Aug 2008 10:57:20 -0500
Subject: [IPython-dev] foolscap
Message-ID: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com>

I was just playing around with ipython1, and noticed that the foolscap
dependency is not listed at
http://ipython.scipy.org/doc/ipython1/html/install.html.  I didn't
catch this til runtime when I got a traceback about the foolscap
ImportError -- I'm attaching a check_for_foolscap patch against the
bzr trunk which will catch this at build time

Brian, I am finally returning to the project you helped me with many
moons ago when you wrote the event_client and event_server examples
for me using the perspective broker framework.  I see on the foolscap
page that it is intended as a replacement for the pb, and I wanted to
know if I should be using it instead.  I see from a previous post that
you will be busy moving this weekend but let me know when your
schedule frees up because I might try and bend your ear a bit for some
more advice on this project...

Thanks,
JDH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.patch
Type: application/octet-stream
Size: 2049 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080809/de70aa5b/attachment.obj>

From barrywark at gmail.com  Sat Aug  9 12:16:37 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sat, 9 Aug 2008 12:16:37 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <db6b5ecc0808081549o65c4f58as56260dea5c08f61d@mail.gmail.com>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<cd7634ce0808071636s25b71abekb27edd1b44b2c02f@mail.gmail.com>
	<db6b5ecc0808080236x543451a1u35667d811796bb22@mail.gmail.com>
	<cd7634ce0808080715q58c971dm3bdbdd443dc2dc25@mail.gmail.com>
	<db6b5ecc0808081549o65c4f58as56260dea5c08f61d@mail.gmail.com>
Message-ID: <cd7634ce0808090916m11572f5di5e73f23a8bba0144@mail.gmail.com>

On Fri, Aug 8, 2008 at 6:49 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, Aug 8, 2008 at 7:15 AM, Barry Wark <barrywark at gmail.com> wrote:
>
>> Besides trivial chanes (e.g. spliitting frontendbase into frontendbase
>> and asyncfrontendbase et al), the most significant diff between Gael's
>> branch and mine is that I've made the concept of an execution Block
>> more explicit. Instead of just an input string, a block is now an
>> object containing prompts, input and output as well as, possibly,
>> sub-blocks. The Block maps, conceptually, pretty directly to a
>> Mathematica notebook cell (you can see the Block definition in my
>> ipython-frontend2 brach:IPython/frontend/frontendbase.py). I believe
>> that the API for FrontEndBase can be made largely backwards
>> compatible, but some of the internal implementation must change to
>> support passing around Blocks instead of just strings.
>>
>> OK, so I'd say the conflicts will not be too serious. They may be
>> serious enough to merge one at a time, especially working up to a
>> release. I'll hold off on my branch until things settle out from
>> Gael's merge.
>
> Sounds good.  Yes, I do worry about breaking too much right before a
> release.  Even though we know this will be somewhat of a 'tech
> preview' release, we don't want to have a massive mess for users.
>
> I'm working on reviewing the other branches and merging the rest right now.

I think that's the best plan. Thanks for managing the merging.


>
>>> And will you be attending SciPy?  It seems Brian will be there, and so
>>> will Gael and Stefan, so we may have a bunch of people simultaneously
>>> available to discuss and hack (and anyone else on the list who will
>>> make it to scipy is obviously welcome!).
>>
>> Unfortunately, I can't make it. I'd be happy to check in remotely
>> (Skype etc.) while you all are working if that makes sense.
>
> Bummer.  We'll irc/skype then.  We should plan on having you come down
> to Berkeley sometime later though.  I'll look into the logistics of a
> sprint at Berkeley for perhaps early next year.
>
> Cheers,
>
> f
>


From fperez.net at gmail.com  Sat Aug  9 16:26:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 9 Aug 2008 13:26:55 -0700
Subject: [IPython-dev] foolscap
In-Reply-To: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com>
References: <88e473830808090857q4dff68fne0e1c6c94a7b78bb@mail.gmail.com>
Message-ID: <db6b5ecc0808091326l547e9adcmcd8bbce132de9633@mail.gmail.com>

Hey John,

On Sat, Aug 9, 2008 at 8:57 AM, John Hunter <jdh2358 at gmail.com> wrote:
> I was just playing around with ipython1, and noticed that the foolscap
> dependency is not listed at
> http://ipython.scipy.org/doc/ipython1/html/install.html.  I didn't
> catch this til runtime when I got a traceback about the foolscap
> ImportError -- I'm attaching a check_for_foolscap patch against the
> bzr trunk which will catch this at build time

Sorry, we need to just remove those docs altogether.  Now that all the
IPython1 code has been merged in, there's no need for that anymore.
And in the bzr trunk, foolscap is correctly checked for at setup time.

We're merging in all the code for a release, and I'll try to work on
cleaning up the docs at the site later to avoid these traps for the
unwary.

Cheers,

f


From gael.varoquaux at normalesup.org  Sat Aug  9 18:17:33 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 10 Aug 2008 00:17:33 +0200
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready	for merge of ipython-sync-frontend
In-Reply-To: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
Message-ID: <20080809221733.GA30048@phare.normalesup.org>

On Thu, Aug 07, 2008 at 11:11:00AM -0700, Brian Granger wrote:
> We need a robust way for modules in the frontend to handle interfaces
> if zope.interface is not installed.  Currently each module tries to
> import zope.interface and then builds a mock zope.interface, like
> this::

> 	try:
> 	    from zope.interface import Interface, Attribute, implements, classProvides
> 	except ImportError:
> 	    Interface = object
> 	    def Attribute(name, doc): pass
> 	    def implements(interface): pass
> 	    def classProvides(interface): pass

> This code should probably be put into a common location, something
> like frontend.zopeinterface, so that it can be reused.

Done.

> The docstrings are vague and outdated at points.  More detailed and
> updated docstrings would be helpful.  Also, all docstrings should use
> the epydoc+ReST format.

Done.

> Configuration should be done using the approach in IPython.config.
> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
> examples.

I am not sure what you mean here. I don't see anything in the current
IPython.kernel.config that is of direct use to the frontends. I do agree
that in the long run we want to move to that, but right now I was more
focussed on getting the frontend right, and punting on configuration. It
can be added later when we are happy with one frontend at least, when the
code is well documented and tested. I would say this is low priority.

> IFrontEnd has references to Twisted in its docstrings.  Because the
> basic frontend should work without Twisted, the docstrings should be
> updated to clarify how the interface plays with Twisted, even though
> it is optional.  We really want to document for developers that the
> base frontend is synchronous and doesn't require Twisted, but that the
> interface has a particular design that allows it to be wrapped into an
> asynchronous frontend (like some methods pass through the result).

Done. However, some methods in there do not make sens in a synchronous
frontend (update_cell_prompt, add_block_id_for_result,
add_block_id_for_failure, compile_ast). I suggest moving them in the
asyncfrontend, as right now they are just making it hard for the
developper to figure out what the core interface of a frontend is.


> The design of the frontend seems good though.  We might eventually
> want to think about using the notification stuff in the frontend
> though.

Sure, we can talk about this at SciPy.

> Why does FrontEndBase not have a complete method?  Other frontend
> classes do have this method and its seems like the base class should
> have it too.  Also, there are oher methods in the interpreter that we
> might want to propagate up to the frontend, like push and pull.
> Thoughts?  If these additional methods go in, there should be separate
> asynchronous versions that return deferreds, but these would go into
> asyncfrontend.py.

Done. The methods grew organicaly from my needs to implement the
front-end. And I suspect some more will come for some speicif needs.

> asyncfrontendbase.py
> ====================

> Because this frontend us designed for use with Twisted, I don't think
> we need to protect the zope.interface and Twisted imports.  Also setting
> Failure to Exception will break things as they don't have the same interface.

Done.

> linefrontendbase.py
> ===================

> This looks good as it is simply a concrete subclass of FrontEndBase.
> General comments above about docstrings apply.

Done.

> prefilterfrontend.py
> ====================

> It is fantastic that we can combine ipython0 and IPython.kernel.core
> code like this.  This is a great way of using the new stuff, but
> getting the more complete feature set of IPython.*  But I think this
> type of thing should be done in the lower-level Interpreter, rather
> than the frontend.  This is for a couple of reasons:

> 	1. This would give all users of the Interpreter access to completion and the
> 	   prefilter stuff.  We really need this stuff in the parallel
> computing stuff,
> 	   as well as non-line-oriented frontends.
> 	2. The Interpreter already has some of this logic and it is simply being
> 	   repeated.
> 	3. The current implementation requires that the Interpreter is in-process.
> 	   For connecting to a remote Interpreter, this won't work.

I fully agree with you. I would even state that the way forward with this
is to abstract out of IPlib the methods used in prefilter frontend, fix
things that don't feel right with them (eg that some code is actual
executed during the prefiltering), and move them out of this file, into
the interpreter. This file should get thinner and thinner as we move
forward, and eventually disappear. I see it as a way to transisition
softly from ipython0 to ipython1. It is a stop-gap solution.

By the way, I have just pushed a cleanup of my branch. I have added
docstrings and reorganized the code. I'd be happy to have some feedback
on where things are hard it understand and where names or docs could be
improved.

Will now work on tests.

Ga?l


From barrywark at gmail.com  Sun Aug 10 13:40:20 2008
From: barrywark at gmail.com (Barry Wark)
Date: Sun, 10 Aug 2008 13:40:20 -0400
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <20080809221733.GA30048@phare.normalesup.org>
References: <6ce0ac130808071111r1ef6ca00s1a427e8a4df093bd@mail.gmail.com>
	<20080809221733.GA30048@phare.normalesup.org>
Message-ID: <cd7634ce0808101040g32453588l8af91777089d1b98@mail.gmail.com>

On Sat, Aug 9, 2008 at 6:17 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Thu, Aug 07, 2008 at 11:11:00AM -0700, Brian Granger wrote:
>> We need a robust way for modules in the frontend to handle interfaces
>> if zope.interface is not installed.  Currently each module tries to
>> import zope.interface and then builds a mock zope.interface, like
>> this::
>
>>       try:
>>           from zope.interface import Interface, Attribute, implements, classProvides
>>       except ImportError:
>>           Interface = object
>>           def Attribute(name, doc): pass
>>           def implements(interface): pass
>>           def classProvides(interface): pass
>
>> This code should probably be put into a common location, something
>> like frontend.zopeinterface, so that it can be reused.
>
> Done.
>
>> The docstrings are vague and outdated at points.  More detailed and
>> updated docstrings would be helpful.  Also, all docstrings should use
>> the epydoc+ReST format.
>
> Done.
>
>> Configuration should be done using the approach in IPython.config.
>> See IPython.kernel.config and IPython.kernel.scripts.ipcontroller for
>> examples.
>
> I am not sure what you mean here. I don't see anything in the current
> IPython.kernel.config that is of direct use to the frontends. I do agree
> that in the long run we want to move to that, but right now I was more
> focussed on getting the frontend right, and punting on configuration. It
> can be added later when we are happy with one frontend at least, when the
> code is well documented and tested. I would say this is low priority.
>
>> IFrontEnd has references to Twisted in its docstrings.  Because the
>> basic frontend should work without Twisted, the docstrings should be
>> updated to clarify how the interface plays with Twisted, even though
>> it is optional.  We really want to document for developers that the
>> base frontend is synchronous and doesn't require Twisted, but that the
>> interface has a particular design that allows it to be wrapped into an
>> asynchronous frontend (like some methods pass through the result).
>
> Done. However, some methods in there do not make sens in a synchronous
> frontend (update_cell_prompt, add_block_id_for_result,
> add_block_id_for_failure, compile_ast). I suggest moving them in the
> asyncfrontend, as right now they are just making it hard for the
> developper to figure out what the core interface of a frontend is.

I disagree; they can make just as much sense in a synchronous frontend
as in an ansychronous one. If you chose not to use them in your
implementation, that's your choice as implementor.

>
>
>> The design of the frontend seems good though.  We might eventually
>> want to think about using the notification stuff in the frontend
>> though.
>
> Sure, we can talk about this at SciPy.
>
>> Why does FrontEndBase not have a complete method?  Other frontend
>> classes do have this method and its seems like the base class should
>> have it too.  Also, there are oher methods in the interpreter that we
>> might want to propagate up to the frontend, like push and pull.
>> Thoughts?  If these additional methods go in, there should be separate
>> asynchronous versions that return deferreds, but these would go into
>> asyncfrontend.py.
>
> Done. The methods grew organicaly from my needs to implement the
> front-end. And I suspect some more will come for some speicif needs.
>
>> asyncfrontendbase.py
>> ====================
>
>> Because this frontend us designed for use with Twisted, I don't think
>> we need to protect the zope.interface and Twisted imports.  Also setting
>> Failure to Exception will break things as they don't have the same interface.
>
> Done.
>
>> linefrontendbase.py
>> ===================
>
>> This looks good as it is simply a concrete subclass of FrontEndBase.
>> General comments above about docstrings apply.
>
> Done.
>
>> prefilterfrontend.py
>> ====================
>
>> It is fantastic that we can combine ipython0 and IPython.kernel.core
>> code like this.  This is a great way of using the new stuff, but
>> getting the more complete feature set of IPython.*  But I think this
>> type of thing should be done in the lower-level Interpreter, rather
>> than the frontend.  This is for a couple of reasons:
>
>>       1. This would give all users of the Interpreter access to completion and the
>>          prefilter stuff.  We really need this stuff in the parallel
>> computing stuff,
>>          as well as non-line-oriented frontends.
>>       2. The Interpreter already has some of this logic and it is simply being
>>          repeated.
>>       3. The current implementation requires that the Interpreter is in-process.
>>          For connecting to a remote Interpreter, this won't work.
>
> I fully agree with you. I would even state that the way forward with this
> is to abstract out of IPlib the methods used in prefilter frontend, fix
> things that don't feel right with them (eg that some code is actual
> executed during the prefiltering), and move them out of this file, into
> the interpreter. This file should get thinner and thinner as we move
> forward, and eventually disappear. I see it as a way to transisition
> softly from ipython0 to ipython1. It is a stop-gap solution.
>
> By the way, I have just pushed a cleanup of my branch. I have added
> docstrings and reorganized the code. I'd be happy to have some feedback
> on where things are hard it understand and where names or docs could be
> improved.
>
> Will now work on tests.
>
> Ga?l
> _______________________________________________
> 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 Aug 11 00:31:00 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 10 Aug 2008 23:31:00 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
Message-ID: <g7ofa7$glt$1@ger.gmane.org>

Fernando Perez wrote:
> On Fri, Aug 8, 2008 at 1:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> Fernando Perez wrote:
>>> 6. Robert Kern's contexts branch:
>>>
>>> https://code.launchpad.net/~robert-kern/ipython/contexts
>>>
>>> Robert, what's your plan on this one?  Keep it as branch for now, or
>>> push it into this release?
>> I think it can be pushed.
> 
> I see these issues (doing this on trunk):
> 
> lon[IPython]> grin make_user_ns
> ./Shell.py:
>   567 :         user_ns = IPython.ipapi.make_user_ns(user_ns)
> ./ipapi.py:
>   562 : def make_user_ns(user_ns = None):
>   586 :     Similar to make_user_ns(), but global namespaces are
> really only needed in
> ./iplib.py:
>   287 :         user_ns = IPython.ipapi.make_user_ns(user_ns)
> 
> 
> I don't see your changeset addressing either the Shell or the iplib
> uses of this, do they?  The Shell one is in the matplotlib Shell
> class.

The iplib one was already gone. The Shell one will be gone as soon as I remember 
how to push to launchpad again.

> I've now grabbed your branch, so I can test easily if you make fixes
> and we can merge.  These changes are small and localized enough that
> once we address this, I'm happy to do it.  It would also be good if
> you add proper reST parameter descriptions to the docstrings of the
> new functions you wrote.

:Parameters:
   something : type
     Description.

:Returns:
   Description.

Right?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Mon Aug 11 02:53:26 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 10 Aug 2008 23:53:26 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7ofa7$glt$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
Message-ID: <db6b5ecc0808102353h43ad2619y608b8c3b463e4d1@mail.gmail.com>

On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:

>> I don't see your changeset addressing either the Shell or the iplib
>> uses of this, do they?  The Shell one is in the matplotlib Shell
>> class.
>
> The iplib one was already gone. The Shell one will be gone as soon as I remember
> how to push to launchpad again.

Great, thanks.  I'll then pull and merge.

>> I've now grabbed your branch, so I can test easily if you make fixes
>> and we can merge.  These changes are small and localized enough that
>> once we address this, I'm happy to do it.  It would also be good if
>> you add proper reST parameter descriptions to the docstrings of the
>> new functions you wrote.
>
> :Parameters:
>   something : type
>     Description.
>
> :Returns:
>   Description.

Yup, we're using epydoc-rest.  At scipy I'd like to talk with everyone
about uniformizing doc standards (M. Droetboom who did the lion's
share of the work for MPL will be there).  It  would be nice if
ipython/numpy/scipy/matplotlib/mayavi2/sympy all used the same doc
standard (we're already using sphinx in several of these, I think it's
worth integrating further).

Cheers,

f


From fperez.net at gmail.com  Mon Aug 11 13:40:17 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 10:40:17 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808102353h43ad2619y608b8c3b463e4d1@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
	<db6b5ecc0808102353h43ad2619y608b8c3b463e4d1@mail.gmail.com>
Message-ID: <db6b5ecc0808111040p415d55idb90c425004e64e8@mail.gmail.com>

On Sun, Aug 10, 2008 at 11:53 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> about uniformizing doc standards (M. Droetboom who did the lion's
> share of the work for MPL will be there).  It  would be nice if

BTW, in my haste to compose this message, I inadvertently glossed over
the fact that the mpl team had its own documentation marathon, where
Darren Dale, Eric Firing, John Hunter (and likely others) all put a
great amount of work.  I shouldn't have put a single name on that
message for something that's been a great collective effort (they have
several hundred pages of docs by now!).

My apologies to those in the mpl team I left aside...

Cheers,

f


From gael.varoquaux at normalesup.org  Mon Aug 11 14:44:31 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 11 Aug 2008 20:44:31 +0200
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready	for merge of ipython-sync-frontend (fwd)
Message-ID: <20080811184431.GH31632@phare.normalesup.org>

Forgot to Cc the mailing list.

----- Forwarded message from Gael Varoquaux <gael.varoquaux at normalesup.org> -----

Date: Mon, 11 Aug 2008 20:43:43 +0200
From: Gael Varoquaux <gael.varoquaux at normalesup.org>
To: Fernando Perez <fperez.net at gmail.com>
Subject: Re:  [IPython-dev] Comments about IPython.frontend, getting ready
	for merge of ipython-sync-frontend

On Fri, Aug 08, 2008 at 02:05:54AM -0700, Fernando Perez wrote:

> fd_redirector
> =============

> I imagine this is the part you've been struggling with, from your comments. 

Partly, but that's only a tiny fraction of the tip of the iceberg. The
hardest part was embedding all this in a GUI loop and try to stay
interestive without threads.

> We certainly need this to gracefully handle i/o under GUIs.  Docstrings
> and tests are critically needed though, and the docstrings should
> conform to the reST api for sphinx.

Docstring and tests are now there. All this should work under windows,
including the tests.

> All attributes should be declared in the constructor, even if they are set to
> None with a comment of what they do and that their true value is given later
> (such as in start() ).  The fact that Python allows us to create attributes at
> any point doesn't mean we should do it in normal code, its a feature whose
> valid use cases are in decorating/annotating external objects.  But classes we
> write should declare their attribute API completely in the constructor, for
> readability/comprehensibility reasons.

> Is it necessary to call stop() in getvalue()?

Pretty much. I think I need to close the file descriptor, and redo the
duplication, so I pretty much need to implement the stop method in the
getvalue.

> file_like.py
> ============

> - writelines should read simply "map(self.write,lines)".  Faster, cleaner,
> shorter.

Done.

> - why are the other methods implemented as 'pass'?  Wouldn't it be better not
>   to have them?  Making them pass means they return None, which can lead to
>   them being used by other code which will then strangely break when None is
>   the wrong thing to get.

I have to implement them to satisfy the file-interface. I have documented
this requirement in the code, now.

> output_trap.py
> ==============

> This one implements a smaller set of functionality than the original
> OutputTrap.  Why?  Do we need to merge the two?  Right now we have in
> core.shell uses of the old module and in core.interpreter, of the new, so
> likely some sort of merge will be needed.

Hum, I am not too sure I am following. I haven't created a second
implementation of something, AFAIK.


> redirector_output_trap.py
> =========================

> No docstrings on constructor.

Fixed.

> sync_traceback_trap.py
> ======================

> No docstrings on constructor. The top-level docstring could be a bit more
> verbose.

I improved this, but I must admit I don't fully understand the way
traceback_trap is supposed to work (no docstrings), so I cannot fully
document this object?

I now feel that the branch is in good-enough shape to be merged in.
Obviously there still is some work to be done (more test for a better
coverage, althought the GUI frontends are pretty much impossible to
test). I however feel that we should merge ASAP, and that I will continue
to work on this in the trunk.

I would appreciate another quick review to check that everything is in
order, and for more feedback.

Ga?l


----- End forwarded message -----


From gael.varoquaux at normalesup.org  Mon Aug 11 19:00:35 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 01:00:35 +0200
Subject: [IPython-dev] Test failures
Message-ID: <20080811230035.GC30181@phare.normalesup.org>

Hi,

I have synced my branch with trunk, and I currently have 3 test failing,
2 of which I know are just noise:

===============================================================================
  File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/tests/test_cocoa_frontend.py",
line 21, in <module>
    from IPython.frontend.cocoa.cocoa_frontend import
IPythonCocoaController
  File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/cocoa_frontend.py",
line 28, in <module>
    import objc
ImportError: No module named objc
===============================================================================

and 

===============================================================================
File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/tests/test_enginefc.py",
line 27, in <module>
    from IPython.kernel.fcutil import Tub, UnauthenticatedTub
  File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/fcutil.py",
line 20, in <module>
    from foolscap import Tub, UnauthenticatedTub
ImportError: No module named foolscap
===============================================================================

These tests should be skipped if objc or foolscap cannot be imported.

In addition, I have a test failing for which I am not sure where the
problem is:

======================================================================
FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py",
line 37, in testExecute
    self.assertEquals(result, dict(zip(resultKeys,c)))
AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '',
'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr':
'', 'stdout': '6.2831853071795862\n'}

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

Does this test run on other people's box? If so, I'll look at it more
closely.

Cheers,

Ga?l


From fperez.net at gmail.com  Mon Aug 11 19:07:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 16:07:00 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7ofa7$glt$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
Message-ID: <db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>

On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:

> The iplib one was already gone. The Shell one will be gone as soon as I remember
> how to push to launchpad again.

Care to push?  I'm merging...

Cheers,

f


From fperez.net at gmail.com  Mon Aug 11 19:43:53 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 16:43:53 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080811230035.GC30181@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
Message-ID: <db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>

On Mon, Aug 11, 2008 at 4:00 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi,
>
> I have synced my branch with trunk, and I currently have 3 test failing,
> 2 of which I know are just noise:
>
> ===============================================================================
>  File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/tests/test_cocoa_frontend.py",
> line 21, in <module>
>    from IPython.frontend.cocoa.cocoa_frontend import
> IPythonCocoaController
>  File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/frontend/cocoa/cocoa_frontend.py",
> line 28, in <module>
>    import objc
> ImportError: No module named objc
> ===============================================================================
>
> and
>
> ===============================================================================
> File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/tests/test_enginefc.py",
> line 27, in <module>
>    from IPython.kernel.fcutil import Tub, UnauthenticatedTub
>  File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/fcutil.py",
> line 20, in <module>
>    from foolscap import Tub, UnauthenticatedTub
> ImportError: No module named foolscap
> ===============================================================================


> These tests should be skipped if objc or foolscap cannot be imported.

Both of these later we should mark with skipif() decorators for that purpose.

> In addition, I have a test failing for which I am not sure where the
> problem is:
>
> ======================================================================
> FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py",
> line 37, in testExecute
>    self.assertEquals(result, dict(zip(resultKeys,c)))
> AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '',
> 'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr':
> '', 'stdout': '6.2831853071795862\n'}
>
> ----------------------------------------------------------------------
>
> Does this test run on other people's box? If so, I'll look at it more
> closely.

Passes here.

Cheers,

f


From robert.kern at gmail.com  Mon Aug 11 19:53:03 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 11 Aug 2008 18:53:03 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	<g7i8k2$fvj$2@ger.gmane.org>	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>	<g7ofa7$glt$1@ger.gmane.org>
	<db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>
Message-ID: <g7qjcv$5ls$1@ger.gmane.org>

Fernando Perez wrote:
> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:
> 
>> The iplib one was already gone. The Shell one will be gone as soon as I remember
>> how to push to launchpad again.
> 
> Care to push?  I'm merging...

Pushed sans docstrings. Still
on vacation. Tired from flight.
Sleepytime for me.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Mon Aug 11 20:12:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 17:12:57 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7qjcv$5ls$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
	<db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>
	<g7qjcv$5ls$1@ger.gmane.org>
Message-ID: <db6b5ecc0808111712n7b780de9q72cba772bb6041b8@mail.gmail.com>

On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Fernando Perez wrote:
>> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>>> The iplib one was already gone. The Shell one will be gone as soon as I remember
>>> how to push to launchpad again.
>>
>> Care to push?  I'm merging...
>
> Pushed sans docstrings. Still
> on vacation. Tired from flight.
> Sleepytime for me.

Sorry, I didn't realize you were on vacation!

Sleep, no worries.

Cheers,

f


From fperez.net at gmail.com  Mon Aug 11 21:05:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 18:05:36 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7qjcv$5ls$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
	<db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>
	<g7qjcv$5ls$1@ger.gmane.org>
Message-ID: <db6b5ecc0808111805x1c583376s38515fdc07243e43@mail.gmail.com>

On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Fernando Perez wrote:
>> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>>> The iplib one was already gone. The Shell one will be gone as soon as I remember
>>> how to push to launchpad again.
>>
>> Care to push?  I'm merging...
>
> Pushed sans docstrings. Still
> on vacation. Tired from flight.
> Sleepytime for me.

OK, I just merged and pushed to trunk your changes.  Let me know as
you update the branch and I can merge the rest and push it into trunk.

Cheers,

f


From fperez.net at gmail.com  Mon Aug 11 21:38:06 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 18:38:06 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<489CA6B9.5060006@vdesmedt.com>
	<db6b5ecc0808081308w73e46736o8363425eabb80aa8@mail.gmail.com>
	<46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com>
Message-ID: <db6b5ecc0808111838j77f435b1gd511112b0b967e36@mail.gmail.com>

On Sat, Aug 9, 2008 at 12:34 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, Aug 8, 2008 at 11:08 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> Great, thanks.  I'll have a look then.  Ville, do you have any other
>> specific comments or concerns here, or should I proceed with the merge
>> right away?
>
> No specific comments, so merge ahead.

Mmh, I was getting ready to merge and push, but then I went and looked
at the code, and I see the whole thing is written in camelCase():

http://bazaar.launchpad.net/%7Evivian-vdesmedt/ipython/synchronize-editor/annotate/1007?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1

Why is that the case?  For all new code, we are really trying to stick
to proper PEP-8 within reason, and I don't want to violate that unless
there's a good motive for it.

I also don't see any docstrings in any of the functions at all.

Vivian, I realize that this may be a bit painful, but as you can see,
we're now making an honest effort at building a much higher quality
codebase for IPython, so that all code that goes in is reviewed,
documented and tested.  And we are all living by the same rules (see
recent reviews on other branches, and all the work that has gone into
having testing machinery for ipython itself).

With bzr and launchpad, it's relatively easy for you to track the
trunk (simply keep merging from trunk into your working branch and
pushing back upstream frequently), so that your branch stays up to
date, as you improve it.  But I really think that we can't merge this
code in until it's properly documented and it matches the naming
conventions of the rest of the project.

I realize it's a bit frustrating at this point, but hopefully it's
clear to you that these rules are there to ensure that as the whole
project grows in a very healthy fashion.  We're getting more new code
coming in than any one of us can handle individually, and the only way
we won't crumble under the weight is to enforce that all this new code
is compliant with the rest of the project, documented and
automatically tested.

Regards,

f

ps - I've added the above as a branch review comment on launchpad as well.


From gael.varoquaux at normalesup.org  Mon Aug 11 22:23:20 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 04:23:20 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
Message-ID: <20080812022320.GA27447@phare.normalesup.org>

On Mon, Aug 11, 2008 at 04:43:53PM -0700, Fernando Perez wrote:
> > In addition, I have a test failing for which I am not sure where the
> > problem is:

> > ======================================================================
> > FAIL: testExecute (IPython.kernel.core.tests.test_shell.BasicShellTest)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >  File
> > "/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/tests/test_shell.py",
> > line 37, in testExecute
> >    self.assertEquals(result, dict(zip(resultKeys,c)))
> > AssertionError: {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr': '',
> > 'stdout': ''} != {'commandIndex': 5, 'stdin': '2.0*math.pi', 'stderr':
> > '', 'stdout': '6.2831853071795862\n'}

> > ----------------------------------------------------------------------

> > Does this test run on other people's box? If so, I'll look at it more
> > closely.

> Passes here.

OK, the problem is that, in some of my test, I use code that calls
ipmaker.make_IPython(). As a result, the output gets trap, and apparently
I do not free it well-enough. Any clue to how to free this output?

I think the problem comes from there because if I comment this line out,
or if I do not include these tests, the test we are worried about passes.

Cheers,

Ga?l


From fperez.net at gmail.com  Mon Aug 11 22:42:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 19:42:48 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812022320.GA27447@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
Message-ID: <db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>

On Mon, Aug 11, 2008 at 7:23 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> OK, the problem is that, in some of my test, I use code that calls
> ipmaker.make_IPython(). As a result, the output gets trap, and apparently
> I do not free it well-enough. Any clue to how to free this output?

Do you actually need to use make_ipython?  Would it work for you
instead to get the ipython isntance via ipapi.get()?  Because
explicitly calling make_ip forces the creation of a new, full ipython
instance, and there's enough global noise in there that things are
likely to break.  Yes, we need to work on making it safer to have an
arbitrary number of ipython instances running, but this is historical
cruft from when ipython was only 'the interpreter', so it was coded
with all kinds of global side effects.

Cheers,

f


From gael.varoquaux at normalesup.org  Mon Aug 11 23:03:17 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 05:03:17 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
Message-ID: <20080812030317.GA6567@phare.normalesup.org>

On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote:
> Do you actually need to use make_ipython?  Would it work for you
> instead to get the ipython isntance via ipapi.get()?  

Well, I need a ipython instance, and I need to create it, so I do believe
I need to call make_ipython.

Still working on that,...

Ga?l


From gael.varoquaux at normalesup.org  Tue Aug 12 00:03:28 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 06:03:28 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812030317.GA6567@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
Message-ID: <20080812040328.GB6567@phare.normalesup.org>

On Tue, Aug 12, 2008 at 05:03:17AM +0200, Gael Varoquaux wrote:
> On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote:
> > Do you actually need to use make_ipython?  Would it work for you
> > instead to get the ipython isntance via ipapi.get()?  

> Well, I need a ipython instance, and I need to create it, so I do believe
> I need to call make_ipython.

I pin-pointed the problem quite clearly. Add the following test somewhere
in your test-suite:

def test_stupid():
    from IPython.ipmaker import make_IPython
    i = make_IPython()
    del i

... and the test we are talking about will fail.

This could be a bad interaction between nose, which does some IO magic,
and IPython. If anybody feels like helping me on that, please do: I am
loosing my evening on it.

Cheers,

Ga?l


From fperez.net at gmail.com  Tue Aug 12 00:14:30 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 21:14:30 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812030317.GA6567@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
Message-ID: <db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>

On Mon, Aug 11, 2008 at 8:03 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote:
>> Do you actually need to use make_ipython?  Would it work for you
>> instead to get the ipython isntance via ipapi.get()?
>
> Well, I need a ipython instance, and I need to create it, so I do believe
> I need to call make_ipython.

Again, why not use ipapi.get()?  That object has the public API, and
if you need for now to hook deeper, it keeps the actual ipython
instance inside as .IP.  This is a much better solution than using a
call that's dangerous,  deprecated and 'private' (meaning,  it's not
in ipapi,  which we intend to  expose the visible face of the ipython
instance).

Please let me know why that solution wouldn't work for you so we can
help you get the right thing working,  because the make_IPython call
is very likely to *never* work (there's simpyl way too many global
side effects floating around).

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Aug 12 00:24:14 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 06:24:14 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
Message-ID: <20080812042414.GC6567@phare.normalesup.org>

On Mon, Aug 11, 2008 at 09:14:30PM -0700, Fernando Perez wrote:
> On Mon, Aug 11, 2008 at 8:03 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
> > On Mon, Aug 11, 2008 at 07:42:48PM -0700, Fernando Perez wrote:
> >> Do you actually need to use make_ipython?  Would it work for you
> >> instead to get the ipython isntance via ipapi.get()?

> > Well, I need a ipython instance, and I need to create it, so I do believe
> > I need to call make_ipython.

> Again, why not use ipapi.get()?  That object has the public API, and
> if you need for now to hook deeper, it keeps the actual ipython
> instance inside as .IP.  This is a much better solution than using a
> call that's dangerous,  deprecated and 'private' (meaning,  it's not
> in ipapi,  which we intend to  expose the visible face of the ipython
> instance).

But, I don't get it. I need to create an ipython0 instance, not to
retrieve an existing one. This is pretty-much the entry point of my
frontend: to create an ipython0 instance. I don't see how ipapi.get can
help me on that. I actually don't see how I can do it without
make_IPython. If you have something better to suggest, I am happy to use
it.

Cheers,

Ga?l


From fperez.net at gmail.com  Tue Aug 12 00:37:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 21:37:36 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812042414.GC6567@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
Message-ID: <db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>

On Mon, Aug 11, 2008 at 9:24 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> But, I don't get it. I need to create an ipython0 instance, not to
> retrieve an existing one. This is pretty-much the entry point of my
> frontend: to create an ipython0 instance. I don't see how ipapi.get can
> help me on that. I actually don't see how I can do it without
> make_IPython. If you have something better to suggest, I am happy to use
> it.

But this is during the test suite, right?  In that case, it's going to
be a little tricky, I suspect, because the testing plugin already has
to make an ip0 instance so magics and other similar beasts run.

Could you make your class take optionally the ip0 instance as a
parameter at construction time?  This isn't very elegant, but it may
do for now so you can run in the testing environment until we can fix
it to decouple all the global effects.

In that case, you'd run your constructor passing it the ip0 instance
retrieved from ipapi.get(), and work with that.

Note that with all  the i/o capturing that doctest/nose do, this could
get ugly in a hurry, if you're also trying to do your own i/o
trapping.  So no guarantees that this will actually work.

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Aug 12 01:06:20 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 07:06:20 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
Message-ID: <20080812050620.GD6567@phare.normalesup.org>

On Mon, Aug 11, 2008 at 09:37:36PM -0700, Fernando Perez wrote:
> > But, I don't get it. I need to create an ipython0 instance, not to
> > retrieve an existing one. This is pretty-much the entry point of my
> > frontend: to create an ipython0 instance. I don't see how ipapi.get can
> > help me on that. I actually don't see how I can do it without
> > make_IPython. If you have something better to suggest, I am happy to use
> > it.

> But this is during the test suite, right?  In that case, it's going to
> be a little tricky, I suspect, because the testing plugin already has
> to make an ip0 instance so magics and other similar beasts run.

> Could you make your class take optionally the ip0 instance as a
> parameter at construction time?  This isn't very elegant, but it may
> do for now so you can run in the testing environment until we can fix
> it to decouple all the global effects.

> In that case, you'd run your constructor passing it the ip0 instance
> retrieved from ipapi.get(), and work with that.

I tried, but ipapi.get() returns None.

> Note that with all  the i/o capturing that doctest/nose do, this could
> get ugly in a hurry, if you're also trying to do your own i/o
> trapping.  So no guarantees that this will actually work.

Indeed, and I am trying to test this. But this part works. What doesn't
work is that when and ipython0 instance is instanciated, the output
trapping that you are doing in the ipython1 interpreter is broken. And I
happen to need an ipython0 instance to run the frontend I am trying to
test.

This is a bit frustrating. I have a set of tests for this frontend, but I
can't run them through nose, because they cause side effects and have
another test to fail. The side-effect is quite clearly in something
called by make_IPython, but I am having a hard time figuring out where.

Ga?l


From fperez.net at gmail.com  Tue Aug 12 01:11:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 22:11:54 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812050620.GD6567@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
	<20080812050620.GD6567@phare.normalesup.org>
Message-ID: <db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>

On Mon, Aug 11, 2008 at 10:06 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> I tried, but ipapi.get() returns None.

Ah, I thought you were already running with the ipdoctest plugin
installed/enabled, and not with just plain nose.  That plugin starts
up the ipython testing machinery, and it's the only way to actually
run the existing docstrings as tests.  I haven't advertised much how
to use it yet because it's pretty raw, but since you're fighting in
the frontlines, might as well give you a gun :)

For now, you can use the makefile.  Go to the testing/plugin
directory, edit the PREFIX at the top to whatever you like on your
box, and run

make all

That should run the test suite for you after installing the plugin.
Once that's working, you can use the plugin to run your tests as well
with the command line as defined in the $(NOSE) variable atop the
makefile.

The plugin makes an ipython instance for all  tests, so once it's up
and running (which you get by simply saying --with-ipdoctest at your
nose command line), ipapi.get() in *your* code should then always
return an actual ip instance instead of None.

>> Note that with all  the i/o capturing that doctest/nose do, this could
>> get ugly in a hurry, if you're also trying to do your own i/o
>> trapping.  So no guarantees that this will actually work.
>
> Indeed, and I am trying to test this. But this part works. What doesn't
> work is that when and ipython0 instance is instanciated, the output
> trapping that you are doing in the ipython1 interpreter is broken. And I
> happen to need an ipython0 instance to run the frontend I am trying to
> test.
>
> This is a bit frustrating. I have a set of tests for this frontend, but I
> can't run them through nose, because they cause side effects and have
> another test to fail. The side-effect is quite clearly in something
> called by make_IPython, but I am having a hard time figuring out where.

Yes, I'm sorry you're seeing this.  This particular battle isn't going
to be fun, and we're paying the price of neglecting testing for such a
long time.  But we all know it's the right thing to do, and I really
appreciate your commitment despite how unpleasant it is.

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Aug 12 01:18:11 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 07:18:11 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>
References: <20080811230035.GC30181@phare.normalesup.org>
	<db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
	<20080812050620.GD6567@phare.normalesup.org>
	<db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>
Message-ID: <20080812051811.GE6567@phare.normalesup.org>

On Mon, Aug 11, 2008 at 10:11:54PM -0700, Fernando Perez wrote:
> > This is a bit frustrating. I have a set of tests for this frontend, but I
> > can't run them through nose, because they cause side effects and have
> > another test to fail. The side-effect is quite clearly in something
> > called by make_IPython, but I am having a hard time figuring out where.

> Yes, I'm sorry you're seeing this.  This particular battle isn't going
> to be fun, and we're paying the price of neglecting testing for such a
> long time.  But we all know it's the right thing to do, and I really
> appreciate your commitment despite how unpleasant it is.

I apologise for getting a bit frustated. We all know that ipython0 is old
and curfty code, but I am sooooo happy to use it on a day to day basis,
so really cannot blame anybody for having taken the short way to get
there.

Besides, it is not that unpleasant, just frustating.

I'll buy you a beer for being an unpleasant Frenchmen :)

Ga?l


From fperez.net at gmail.com  Tue Aug 12 01:23:07 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 22:23:07 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812051811.GE6567@phare.normalesup.org>
References: <20080811230035.GC30181@phare.normalesup.org>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
	<20080812050620.GD6567@phare.normalesup.org>
	<db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>
	<20080812051811.GE6567@phare.normalesup.org>
Message-ID: <db6b5ecc0808112223v7e1bae19kcc26d4de8adf4346@mail.gmail.com>

On Mon, Aug 11, 2008 at 10:18 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Mon, Aug 11, 2008 at 10:11:54PM -0700, Fernando Perez wrote:
>> > This is a bit frustrating. I have a set of tests for this frontend, but I
>> > can't run them through nose, because they cause side effects and have
>> > another test to fail. The side-effect is quite clearly in something
>> > called by make_IPython, but I am having a hard time figuring out where.
>
>> Yes, I'm sorry you're seeing this.  This particular battle isn't going
>> to be fun, and we're paying the price of neglecting testing for such a
>> long time.  But we all know it's the right thing to do, and I really
>> appreciate your commitment despite how unpleasant it is.
>
> I apologise for getting a bit frustated. We all know that ipython0 is old
> and curfty code, but I am sooooo happy to use it on a day to day basis,
> so really cannot blame anybody for having taken the short way to get
> there.
>
> Besides, it is not that unpleasant, just frustating.

No worries.  I'm going to be working for a bit longer, so let me know
if you need anything.  And please keep merging with trunk and pushing,
so I can perhaps tomorrow merge your branch.  If you do all the merges
with trunk back in your branch and you push it, I can then do a pull
and your local commits get registered as such (see the  last changes
to trunk showing Robet's individual changesets, which I merged today).
In fact, I've been mulling today, after all the merge work, a slight
reorganization of how we manage branches  to simplify review and
history handling.  But I'll send that in a separate message in a few
days, after we finish the current burning issues.

>
> I'll buy you a beer for being an unpleasant Frenchmen :)

Gladly accepted! (the beer, not that you're unpleasang :)

Cheers,

f


From gael.varoquaux at normalesup.org  Tue Aug 12 01:24:40 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 12 Aug 2008 07:24:40 +0200
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812051811.GE6567@phare.normalesup.org>
References: <db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<20080812022320.GA27447@phare.normalesup.org>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
	<20080812050620.GD6567@phare.normalesup.org>
	<db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>
	<20080812051811.GE6567@phare.normalesup.org>
Message-ID: <20080812052440.GF6567@phare.normalesup.org>

On Tue, Aug 12, 2008 at 07:18:11AM +0200, Gael Varoquaux wrote:
> Besides, it is not that unpleasant, just frustating.

And, in addition, I have solved my problem. It was a sys.displayhook
problem, not an IO problem.

I am happy :).

Ga?l


From fperez.net at gmail.com  Tue Aug 12 01:30:44 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 11 Aug 2008 22:30:44 -0700
Subject: [IPython-dev] Test failures
In-Reply-To: <20080812052440.GF6567@phare.normalesup.org>
References: <db6b5ecc0808111643m977e2a5jc0190f7a2523f855@mail.gmail.com>
	<db6b5ecc0808111942t350bb95fh8b8ece43d6b236a2@mail.gmail.com>
	<20080812030317.GA6567@phare.normalesup.org>
	<db6b5ecc0808112114o4677df12r758c8635bddabca7@mail.gmail.com>
	<20080812042414.GC6567@phare.normalesup.org>
	<db6b5ecc0808112137w7fa40705pf7ae98e907867ed1@mail.gmail.com>
	<20080812050620.GD6567@phare.normalesup.org>
	<db6b5ecc0808112211o780876edva47db06ac7f32301@mail.gmail.com>
	<20080812051811.GE6567@phare.normalesup.org>
	<20080812052440.GF6567@phare.normalesup.org>
Message-ID: <db6b5ecc0808112230r7a1bee15l10e1b1c39a9a83e0@mail.gmail.com>

On Mon, Aug 11, 2008 at 10:24 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Tue, Aug 12, 2008 at 07:18:11AM +0200, Gael Varoquaux wrote:
>> Besides, it is not that unpleasant, just frustating.
>
> And, in addition, I have solved my problem. It was a sys.displayhook
> problem, not an IO problem.

OK, great.

Cheers,

f


From fperez.net at gmail.com  Tue Aug 12 03:30:37 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Aug 2008 00:30:37 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <48A13A57.5090108@vdesmedt.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<489CA6B9.5060006@vdesmedt.com>
	<db6b5ecc0808081308w73e46736o8363425eabb80aa8@mail.gmail.com>
	<46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com>
	<db6b5ecc0808111838j77f435b1gd511112b0b967e36@mail.gmail.com>
	<48A13A57.5090108@vdesmedt.com>
Message-ID: <db6b5ecc0808120030v2bd6cac8xd9d6d0cd2e366b88@mail.gmail.com>

On Tue, Aug 12, 2008 at 12:23 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:

> No problem I will adapt the code of the synchronize-editor branch as soon as
> possible.
> I'll be glad if you could send me the bzr command I should use to merge the
> trunk cod in the synchronize-editor branch.

Basically the easiest workflow is to have the following:

bzr-directory/
  ipython/  -> trunk, you get this with 'bzr branch lp:ipython'
  your_branch/ -> where you're working

then in the checkout of trunk, you periodically do

bzr pull

to pull updates that others have pushed to the trunk.  When new
updates are in, you can propagate them to your working branch via:

cd your_branch
bzr pull ../ipython/

if the above fails because a merge is required, you do instead

bzr commit -m"Checkpointing local changes before merge"
bzr merge ../ipython
bzr commit -m"Merge with upstream"

This keeps your changes in sync with the upstream development on
trunk, which is important to ensure that nothing breaks in your
development.  You can then periodically do:

bzr push

This sends your changes to launchpad, so that I and others can get
them for review, merging, sharing, etc.

I hope this is clear enough, let us know if you have any other questions.

Regards,

f


From vivian at vdesmedt.com  Tue Aug 12 03:23:03 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 12 Aug 2008 09:23:03 +0200
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808111838j77f435b1gd511112b0b967e36@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	
	<489CA6B9.5060006@vdesmedt.com>	
	<db6b5ecc0808081308w73e46736o8363425eabb80aa8@mail.gmail.com>	
	<46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com>
	<db6b5ecc0808111838j77f435b1gd511112b0b967e36@mail.gmail.com>
Message-ID: <48A13A57.5090108@vdesmedt.com>

Fernando,
> Mmh, I was getting ready to merge and push, but then I went and looked
> at the code, and I see the whole thing is written in camelCase():
>
> http://bazaar.launchpad.net/%7Evivian-vdesmedt/ipython/synchronize-editor/annotate/1007?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1
>
> Why is that the case?  For all new code, we are really trying to stick
> to proper PEP-8 within reason, and I don't want to violate that unless
> there's a good motive for it.
>
> I also don't see any docstrings in any of the functions at all.
>
> Vivian, I realize that this may be a bit painful, but as you can see,
> we're now making an honest effort at building a much higher quality
> codebase for IPython, so that all code that goes in is reviewed,
> documented and tested.  And we are all living by the same rules (see
> recent reviews on other branches, and all the work that has gone into
> having testing machinery for ipython itself).
>
> With bzr and launchpad, it's relatively easy for you to track the
> trunk (simply keep merging from trunk into your working branch and
> pushing back upstream frequently), so that your branch stays up to
> date, as you improve it.  But I really think that we can't merge this
> code in until it's properly documented and it matches the naming
> conventions of the rest of the project.
>
> I realize it's a bit frustrating at this point, but hopefully it's
> clear to you that these rules are there to ensure that as the whole
> project grows in a very healthy fashion.  We're getting more new code
> coming in than any one of us can handle individually, and the only way
> we won't crumble under the weight is to enforce that all this new code
> is compliant with the rest of the project, documented and
> automatically tested.
>
> Regards,
>
> f
>
> ps - I've added the above as a branch review comment on launchpad as well.
>
>   
No problem I will adapt the code of the synchronize-editor branch as 
soon as possible.
I'll be glad if you could send me the bzr command I should use to merge 
the trunk cod in the synchronize-editor branch.

Vivian.



From vivian at vdesmedt.com  Tue Aug 12 04:15:15 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 12 Aug 2008 10:15:15 +0200
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808120030v2bd6cac8xd9d6d0cd2e366b88@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	
	<489CA6B9.5060006@vdesmedt.com>	
	<db6b5ecc0808081308w73e46736o8363425eabb80aa8@mail.gmail.com>	
	<46cb515a0808090034m1e2ef57amefe6def7eadf9380@mail.gmail.com>	
	<db6b5ecc0808111838j77f435b1gd511112b0b967e36@mail.gmail.com>	
	<48A13A57.5090108@vdesmedt.com>
	<db6b5ecc0808120030v2bd6cac8xd9d6d0cd2e366b88@mail.gmail.com>
Message-ID: <48A14693.8020704@vdesmedt.com>

Fernando,

Thanks for your explanations.
I have no access to launchpad right now but I'll test your work flow as 
soon as possible.

Vivian.



From robert.kern at gmail.com  Tue Aug 12 13:14:03 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 12 Aug 2008 12:14:03 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808111805x1c583376s38515fdc07243e43@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	<g7i8k2$fvj$2@ger.gmane.org>	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>	<g7ofa7$glt$1@ger.gmane.org>	<db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>	<g7qjcv$5ls$1@ger.gmane.org>
	<db6b5ecc0808111805x1c583376s38515fdc07243e43@mail.gmail.com>
Message-ID: <g7sgcs$lbp$1@ger.gmane.org>

Fernando Perez wrote:
> On Mon, Aug 11, 2008 at 4:53 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> Fernando Perez wrote:
>>> On Sun, Aug 10, 2008 at 9:31 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>>
>>>> The iplib one was already gone. The Shell one will be gone as soon as I remember
>>>> how to push to launchpad again.
>>> Care to push?  I'm merging...
>> Pushed sans docstrings. Still
>> on vacation. Tired from flight.
>> Sleepytime for me.
> 
> OK, I just merged and pushed to trunk your changes.  Let me know as
> you update the branch and I can merge the rest and push it into trunk.

There was a syntax error that I fixed.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Tue Aug 12 16:29:43 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 12 Aug 2008 13:29:43 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7sgcs$lbp$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7i8k2$fvj$2@ger.gmane.org>
	<db6b5ecc0808081541i65f1758hb65380d82a9e934a@mail.gmail.com>
	<g7ofa7$glt$1@ger.gmane.org>
	<db6b5ecc0808111607g1385160fx2c56f0fbf80b58f3@mail.gmail.com>
	<g7qjcv$5ls$1@ger.gmane.org>
	<db6b5ecc0808111805x1c583376s38515fdc07243e43@mail.gmail.com>
	<g7sgcs$lbp$1@ger.gmane.org>
Message-ID: <db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>

On Tue, Aug 12, 2008 at 10:14 AM, Robert Kern <robert.kern at gmail.com> wrote:

>> OK, I just merged and pushed to trunk your changes.  Let me know as
>> you update the branch and I can merge the rest and push it into trunk.
>
> There was a syntax error that I fixed.

Got it, pushed.  Thanks.  If you push docstring updates, let me know.

Cheers,

f


From dsdale24 at gmail.com  Wed Aug 13 09:14:47 2008
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 13 Aug 2008 09:14:47 -0400
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7sgcs$lbp$1@ger.gmane.org>
	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>
Message-ID: <200808130914.47689.dsdale24@gmail.com>

I guess the trunk is in a state of flux at the moment, but I wanted to point 
out before 0.9 is released that -pylab appears to be broken in bzr 1016:

$ ipython -pylab
Traceback (most recent call last):
  File "/usr/bin/ipython", line 28, in <module>
    IPython.Shell.start().mainloop()
  File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1231, in 
start
    return shell(user_ns = user_ns)
  File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1136, in 
__init__
    shell_class=MatplotlibMTShell)
  File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 1035, in 
__init__
    on_kill=[QtGui.qApp.exit])
  File "/usr/lib64/python2.5/site-packages/IPython/ipmaker.py", line 103, in 
make_IPython
    embedded=embedded,**kw)
  File "/usr/lib64/python2.5/site-packages/IPython/Shell.py", line 637, in 
__init__
    user_ns,b2 = self._matplotlib_config(name,user_ns)
ValueError: too many values to unpack

Darren

On Tuesday 12 August 2008 04:29:43 pm Fernando Perez wrote:
> On Tue, Aug 12, 2008 at 10:14 AM, Robert Kern <robert.kern at gmail.com> wrote:
> >> OK, I just merged and pushed to trunk your changes.  Let me know as
> >> you update the branch and I can merge the rest and push it into trunk.
> >
> > There was a syntax error that I fixed.
>
> Got it, pushed.  Thanks.  If you push docstring updates, let me know.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev




From gael.varoquaux at normalesup.org  Wed Aug 13 11:44:09 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 13 Aug 2008 17:44:09 +0200
Subject: [IPython-dev] Evaluation bug in Interpreter?
Message-ID: <20080813154409.GA12897@phare.normalesup.org>

I hit this behavior, with the ipython1 interpreter:

===============================================================================
In [6]: from IPython.kernel.core.interpreter import Interpreter

In [7]: i = Interpreter()

In [8]: i.execute(u'dedent(""" a\n b\n c""")\n\n')
---------------------------------------------------------------------------
IndentationError                          Traceback (most recent call
last)

/home/gvaroquaux/dev/ipython/ipython-frontend/scripts/<ipython console>
in <module>()

/home/gvaroquaux/dev/ipython/ipython-frontend/IPython/kernel/core/interpreter.pyc
in execute_python(self, python)
    352         for cmd in commands:
    353             try:
--> 354                 code = self.command_compiler(cmd, self.filename,
'single')
    355             except (SyntaxError, OverflowError, ValueError), e:
    356                 self.traceback_trap.args = sys.exc_info()

/usr/lib/python2.5/codeop.pyc in __call__(self, source, filename, symbol)
    164         - Raise SyntaxError, ValueError or OverflowError if the
command is a
    165           syntax error (OverflowError and ValueError can be
produced by
    166           malformed literals).
    167         """
--> 168         return _maybe_compile(self.compiler, source, filename,
symbol)

/usr/lib/python2.5/codeop.pyc in _maybe_compile(compiler, source,
filename, symbol)
     97         return code
     98     if not code1 and repr(err1) == repr(err2):
---> 99         raise SyntaxError, err1
    100 
    101 def _compile(source, filename, symbol):

IndentationError: unexpected indent (<string>, line 1)
===============================================================================

It seems to me that the input is valid Python.

Cheers,

Ga?l


From fperez.net at gmail.com  Wed Aug 13 12:50:30 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 13 Aug 2008 09:50:30 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <200808130914.47689.dsdale24@gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7sgcs$lbp$1@ger.gmane.org>
	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>
	<200808130914.47689.dsdale24@gmail.com>
Message-ID: <db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>

On Wed, Aug 13, 2008 at 6:14 AM, Darren Dale <dsdale24 at gmail.com> wrote:
> I guess the trunk is in a state of flux at the moment, but I wanted to point
> out before 0.9 is released that -pylab appears to be broken in bzr 1016:

Thanks for reporting it. I'm in a meeting for several hours, but if
someone can beat me to the fix it would be great.  This has to do with
Robert Kern's recent namespace construction API changes, I guess we
missed a few spots...

Cheers,

f


From robert.kern at gmail.com  Wed Aug 13 16:00:38 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 13 Aug 2008 15:00:38 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	<g7sgcs$lbp$1@ger.gmane.org>	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>	<200808130914.47689.dsdale24@gmail.com>
	<db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>
Message-ID: <g7veh6$kab$1@ger.gmane.org>

Fernando Perez wrote:
> On Wed, Aug 13, 2008 at 6:14 AM, Darren Dale <dsdale24 at gmail.com> wrote:
>> I guess the trunk is in a state of flux at the moment, but I wanted to point
>> out before 0.9 is released that -pylab appears to be broken in bzr 1016:
> 
> Thanks for reporting it. I'm in a meeting for several hours, but if
> someone can beat me to the fix it would be great.  This has to do with
> Robert Kern's recent namespace construction API changes, I guess we
> missed a few spots...

Please pardon my sloppiness.

Fixed pushed to lp:~robert-kern/ipython/contexts

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Wed Aug 13 16:30:04 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 13 Aug 2008 13:30:04 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7veh6$kab$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7sgcs$lbp$1@ger.gmane.org>
	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>
	<200808130914.47689.dsdale24@gmail.com>
	<db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>
	<g7veh6$kab$1@ger.gmane.org>
Message-ID: <db6b5ecc0808131330n76eec3b6q10e9d20a93eaad19@mail.gmail.com>

On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern <robert.kern at gmail.com> wrote:

> Please pardon my sloppiness.

You are forgiven.  We need more tests, more tests, more tests... :)

> Fixed pushed to lp:~robert-kern/ipython/contexts

Thanks, pushed upstream.  Please double-check (I'm having a build
problem with numpy right now on this box that I don't want to report
yet because it may be my fault, so I can't fully test this myself).

Cheers,

f


From robert.kern at gmail.com  Wed Aug 13 19:01:34 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 13 Aug 2008 18:01:34 -0500
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <db6b5ecc0808131330n76eec3b6q10e9d20a93eaad19@mail.gmail.com>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>	<g7sgcs$lbp$1@ger.gmane.org>	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>	<200808130914.47689.dsdale24@gmail.com>	<db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>	<g7veh6$kab$1@ger.gmane.org>
	<db6b5ecc0808131330n76eec3b6q10e9d20a93eaad19@mail.gmail.com>
Message-ID: <g7vp4e$u8u$1@ger.gmane.org>

Fernando Perez wrote:
> On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> Fixed pushed to lp:~robert-kern/ipython/contexts
> 
> Thanks, pushed upstream.  Please double-check (I'm having a build
> problem with numpy right now on this box that I don't want to report
> yet because it may be my fault, so I can't fully test this myself).

ipython -pylab works for me.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Wed Aug 13 19:15:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 13 Aug 2008 16:15:19 -0700
Subject: [IPython-dev] Release plan for 0.9
In-Reply-To: <g7vp4e$u8u$1@ger.gmane.org>
References: <db6b5ecc0808080234s7a72267dhecabdeea4eaf8609@mail.gmail.com>
	<g7sgcs$lbp$1@ger.gmane.org>
	<db6b5ecc0808121329u3afcdfcfl6cf7010146b83590@mail.gmail.com>
	<200808130914.47689.dsdale24@gmail.com>
	<db6b5ecc0808130950t5b162369we0dae0047a868785@mail.gmail.com>
	<g7veh6$kab$1@ger.gmane.org>
	<db6b5ecc0808131330n76eec3b6q10e9d20a93eaad19@mail.gmail.com>
	<g7vp4e$u8u$1@ger.gmane.org>
Message-ID: <db6b5ecc0808131615xb199c29sb9fb44d3bbb7e54f@mail.gmail.com>

On Wed, Aug 13, 2008 at 4:01 PM, Robert Kern <robert.kern at gmail.com> wrote:
> Fernando Perez wrote:
>> On Wed, Aug 13, 2008 at 1:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>> Fixed pushed to lp:~robert-kern/ipython/contexts
>>
>> Thanks, pushed upstream.  Please double-check (I'm having a build
>> problem with numpy right now on this box that I don't want to report
>> yet because it may be my fault, so I can't fully test this myself).
>
> ipython -pylab works for me.

Thanks, I just sorted out my build problem (it was indeed on my end)
and could test things.  Everything looks OK (I also tested the
-Xthread and embedding call modes).

Cheers,

f


From fperez.net at gmail.com  Thu Aug 14 08:55:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 05:55:54 -0700
Subject: [IPython-dev] Evaluation bug in Interpreter?
In-Reply-To: <20080813154409.GA12897@phare.normalesup.org>
References: <20080813154409.GA12897@phare.normalesup.org>
Message-ID: <db6b5ecc0808140555l3fde1bb0n55390630e7247e05@mail.gmail.com>

On Wed, Aug 13, 2008 at 8:44 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> I hit this behavior, with the ipython1 interpreter:
>
> ===============================================================================
> In [6]: from IPython.kernel.core.interpreter import Interpreter
>
> In [7]: i = Interpreter()
>
> In [8]: i.execute(u'dedent(""" a\n b\n c""")\n\n')

Bug.  It's splitting the lines wrong:


ipdb> print cmd
 c""")

File it on lp so we don't lose track...

Cheers,

f


From fperez.net at gmail.com  Thu Aug 14 09:04:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 06:04:55 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
Message-ID: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>

Howdy,

I wanted to make the 0.9 beta tonight (well, last night...) but I've
just burned several hours trying to track an intermittent failure in a
Twisted-using test that I can't seem to pin down.  Since the problem
is only on a single test, I'm giving up for now.  But I just committed
the last critical piece of testing machinery that gave me a hard time:
the ability to correctly execute in docstrings tests that probe
ipython-specific features, like complete(x) where x is in the
namespace.  This requires a delicate dance with nose and doctest, but
I think I finally got a solid solution.

The sugar is still missing, so for now the test suite will be really
only for developers, but hopefully next week I can add a user-visible
layer that makes it easy for users to run and that handles gracefully
missing components (like twisted, guis, objc, etc).

For now I need to get some sleep, and I'm running very badly behind on
things for scipy.  So if anyone has anything pending please respond to
this email and I'll deal with it when I get up.  Otherwise I'll cut an
0.9 beta and shift gears immediately to the scipy tutorial material
for a few days.

Cheers,

f


From fperez.net at gmail.com  Thu Aug 14 09:18:35 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 06:18:35 -0700
Subject: [IPython-dev] Comments about IPython.frontend,
	getting ready for merge of ipython-sync-frontend
In-Reply-To: <20080814131035.GB22202@phare.normalesup.org>
References: <20080813000612.GD631@phare.normalesup.org>
	<20080813205043.GC21473@phare.normalesup.org>
	<db6b5ecc0808131522y142c20caif88a9bf4c27702b5@mail.gmail.com>
	<db6b5ecc0808131721t62998197s5850ba6182d82cf4@mail.gmail.com>
	<db6b5ecc0808131741m48fe2751t2ebe486b3494aba8@mail.gmail.com>
	<20080814065502.GF24893@phare.normalesup.org>
	<db6b5ecc0808140055h5e72d6ecn2b02720fefba2d1b@mail.gmail.com>
	<20080814130728.GA22202@phare.normalesup.org>
	<db6b5ecc0808140609w74e8d46bvea5fe915e2ef712f@mail.gmail.com>
	<20080814131035.GB22202@phare.normalesup.org>
Message-ID: <db6b5ecc0808140618m7743f792weecf38011e53d706@mail.gmail.com>

On Thu, Aug 14, 2008 at 6:10 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Thu, Aug 14, 2008 at 06:09:21AM -0700, Fernando Perez wrote:
>> OK, we'll look at this next week.  The code I just wrote does some
>> things that may actually fix the problem altogether, or offer a
>> cleaner solution.  But I'm not sure and I'm too tired to check now.
>
>> To bed..
>
> Wow, that's late. Can I help with something?

Very, very late...

Yes, if you can do some testing of the installation, it would be
great.  The setup.py we have now has been massively changed from the
old one, merging in the ip1 stuff, but there's a very good chance it
may have holes.  So testing that the various targets build (sdist,
egg, wininst), that the windows installer works (I can't test windows
at all, my vmware image is borked), that the docs get put in the right
place, etc, would be great.

I don't intend to add any more code unless someone jumps at the last
minute with something simple, so now it should be just testing that
all the ip0/1 merge didn't hose the build/install machinery.  Since I
always run from my dev directories I haven't tested that part yet, and
now I really need to crash.

Any help would be very, very much appreciated.

Cheers,

f


From vivainio at gmail.com  Thu Aug 14 16:47:28 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 14 Aug 2008 23:47:28 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
Message-ID: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>

On Thu, Aug 14, 2008 at 4:04 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> For now I need to get some sleep, and I'm running very badly behind on
> things for scipy.  So if anyone has anything pending please respond to
> this email and I'll deal with it when I get up.  Otherwise I'll cut an
> 0.9 beta and shift gears immediately to the scipy tutorial material
> for a few days.

I just implemented cd -foo. I'll make another post about it, and add
it to changes.txt.

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


From vivainio at gmail.com  Thu Aug 14 17:01:09 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 00:01:09 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
Message-ID: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>

On Thu, Aug 14, 2008 at 11:47 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> I just implemented cd -foo. I'll make another post about it, and add
> it to changes.txt.

Well, of course I need to change it to cd --foo due to option parsing.
Stay tuned.

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


From fperez.net at gmail.com  Thu Aug 14 17:31:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 14:31:19 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
Message-ID: <db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>

On Thu, Aug 14, 2008 at 2:01 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Thu, Aug 14, 2008 at 11:47 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> I just implemented cd -foo. I'll make another post about it, and add
>> it to changes.txt.
>
> Well, of course I need to change it to cd --foo due to option parsing.
> Stay tuned.

This is a very handy feature, but I wish you'd brought it up for at
least cursory discussion first, because there's one point I worry
about: you are overloading the '--foo'  syntax to have another
secondary meaning, on top of its original 'long options' one.  This
means special-casing code.  In the new architecture, the magics will
be separate objects with a common options parsing machinery that
should be uniform, so there's a good chance we'll have to change a bit
exactly how this works in the near future.

In any case, it's too late right now, I'm working on scipy stuff and
will cut the beta later, so let's leave it in.  But let's try to all
heed to the discussion/review swing that Barry and Gael got us so well
into for all the recent code.  It will help us all build something
that is well integrated and robust for the long haul.

Cheers,

f


From vivainio at gmail.com  Thu Aug 14 20:37:55 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 03:37:55 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
Message-ID: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>

On Fri, Aug 15, 2008 at 12:31 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> means special-casing code.  In the new architecture, the magics will
> be separate objects with a common options parsing machinery that
> should be uniform, so there's a good chance we'll have to change a bit
> exactly how this works in the near future.

I don't mind if the behaviour changes, as long as it's as convenient
(to type) as using --. However, I don't think forcing the magics to go
through a common parsing machinery is the optimal way to go; we should
retain the possibility for the current behaviour that allows free form
data to be passed to magics.

We could also change the character before the release, if the dual
meaning with long options is a problem. - is something you can type
without pressing shift on most keyboard layout, so I'd rather leave it
as it is now.

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


From fperez.net at gmail.com  Thu Aug 14 20:44:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 17:44:47 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
Message-ID: <db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>

On Thu, Aug 14, 2008 at 5:37 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, Aug 15, 2008 at 12:31 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> means special-casing code.  In the new architecture, the magics will
>> be separate objects with a common options parsing machinery that
>> should be uniform, so there's a good chance we'll have to change a bit
>> exactly how this works in the near future.
>
> I don't mind if the behaviour changes, as long as it's as convenient
> (to type) as using --. However, I don't think forcing the magics to go
> through a common parsing machinery is the optimal way to go; we should
> retain the possibility for the current behaviour that allows free form
> data to be passed to magics.
>
> We could also change the character before the release, if the dual
> meaning with long options is a problem. - is something you can type
> without pressing shift on most keyboard layout, so I'd rather leave it
> as it is now.

The issue is one of avoiding special casing.  Magics will certainly
always be able to be given free-form input, but *if* they take
options, then options should be handled as such via optparse or
similar.  Magics behave at the ipython command line much like system
commands, and using -- for both options and arguments would break
option parsing altogether.  I've never seen a single system command
that accepts

foo --option1 --option2 --freeformarguments

because the option parsing machineries (getopt, optparse, whatever) as
far as I know them, always expect to know the list of valid options in
advance. This is why I don't want this hybrid mode, 'cd is special'
case where -- means two different things.

Any suggestions for alternatives?

Cheers,

f


From ellisonbg.net at gmail.com  Thu Aug 14 20:50:06 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 14 Aug 2008 17:50:06 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
Message-ID: <6ce0ac130808141750x6796436ema26b14c5cc23b7c7@mail.gmail.com>

>> means special-casing code.  In the new architecture, the magics will
>> be separate objects with a common options parsing machinery that
>> should be uniform, so there's a good chance we'll have to change a bit
>> exactly how this works in the near future.
>
> I don't mind if the behaviour changes, as long as it's as convenient
> (to type) as using --. However, I don't think forcing the magics to go
> through a common parsing machinery is the optimal way to go; we should
> retain the possibility for the current behaviour that allows free form
> data to be passed to magics.

I agree that magics in general should allow free form syntax.  But I
do feel that if a magic wants to the usual command line style options,
that we should keep to a standard syntax.

> We could also change the character before the release, if the dual
> meaning with long options is a problem. - is something you can type
> without pressing shift on most keyboard layout, so I'd rather leave it
> as it is now.
>
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg.net at gmail.com  Thu Aug 14 20:53:56 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 14 Aug 2008 17:53:56 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
Message-ID: <6ce0ac130808141753k3877a965ref8f7db0d3dd0faf@mail.gmail.com>

> foo --option1 --option2 --freeformarguments
>
> because the option parsing machineries (getopt, optparse, whatever) as
> far as I know them, always expect to know the list of valid options in
> advance. This is why I don't want this hybrid mode, 'cd is special'
> case where -- means two different things.

Ahh, yes, this does introduce a sort of messyness in the double
interpretation of "--".  Also, now that I think about it, "cd --foo"
would usually have the interpretation "cd to my home dir and do it in
the foo'y way"

That is, "--" options are typically optional modifiers, drawn from a
pre-specified list of options.  The usage "cd --foo" is pretty odd in
this light.

Brian


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


From vivainio at gmail.com  Thu Aug 14 21:34:39 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 04:34:39 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
Message-ID: <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>

On Fri, Aug 15, 2008 at 3:44 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> Any suggestions for alternatives?

This would work for me, keyboardwise:

cd =foo

It seems kinda confusing unless you are writing it yourself, though
(looks like assignment), and it doesn't come as naturally as --
(logical followup of -<n>.

I still prefer "--", cd can be special that way. People don't think of
it as "unix command" and its usage becomes a second reflex. cd is not
a command that needs to follow the logic of more rarely used commands.
We should really consider end-user typing performance with the cost of
slight inconsistency (which magics can have).

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


From fperez.net at gmail.com  Thu Aug 14 21:43:24 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 18:43:24 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
Message-ID: <db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>

On Thu, Aug 14, 2008 at 6:34 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Fri, Aug 15, 2008 at 3:44 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> Any suggestions for alternatives?
>
> This would work for me, keyboardwise:
>
> cd =foo
>
> It seems kinda confusing unless you are writing it yourself, though
> (looks like assignment), and it doesn't come as naturally as --
> (logical followup of -<n>.
>
> I still prefer "--", cd can be special that way. People don't think of
> it as "unix command" and its usage becomes a second reflex. cd is not
> a command that needs to follow the logic of more rarely used commands.
> We should really consider end-user typing performance with the cost of
> slight inconsistency (which magics can have).

Let's go with the '=' option, then.  cd can be special that way :)
Otherwise for cd we'd have to implement special parsing logic, since
normal options handling would break given arbitrary --foo input.  As
'import this' says,

Special cases aren't special enough to break the rules.

and this is a case where I agree with it, here the benefit of a
special case does not in any way outweigh the cost of breaking a
pattern.

We're aiming for much more consistency in the code going forward, so
we should raise the bar pretty high for special cases that break the
rules.

Cheers,

f


From vivainio at gmail.com  Thu Aug 14 22:57:15 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 05:57:15 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
Message-ID: <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>

On Fri, Aug 15, 2008 at 4:43 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> Let's go with the '=' option, then.  cd can be special that way :)

= won't work, it raises NameError and never gets to %cd (it looks like
python assignment to ipython as well) ;-)

> Otherwise for cd we'd have to implement special parsing logic, since
> normal options handling would break given arbitrary --foo input.  As
> 'import this' says,
>
> Special cases aren't special enough to break the rules.
> and this is a case where I agree with it, here the benefit of a
> special case does not in any way outweigh the cost of breaking a
> pattern.

The "parsing" logic we already have in %cd is quite trivial, so we
don't really have to shoehorn %cd to the option parsing formula, esp.
since cd will never have arguments in the long format.

I'd be inclined to say that we should leave it as --, and change it if
it proves problematic at some point. We could change it to ---, but
that gets kind of heavy, and other characters have special meanings
(to python or readline as we currently use it).

And since "cd -<n>" is already a special case, the cd magic can be
considered terminally broken from the strict option handling point of
view...

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


From fperez.net at gmail.com  Thu Aug 14 23:06:38 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 20:06:38 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
Message-ID: <db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>

On Thu, Aug 14, 2008 at 7:57 PM, Ville M. Vainio <vivainio at gmail.com> wrote:

> I'd be inclined to say that we should leave it as --, and change it if
> it proves problematic at some point. We could change it to ---, but
> that gets kind of heavy, and other characters have special meanings
> (to python or readline as we currently use it).

I'm deep fighting with the setup.py which is pretty seriously broken,
so I can't deal with this.  I'm ok leaving it as is, since the code is
written, but no promises: when we restructure magics, I reserve the
right to change this if needed.  If it can be kept without hassles, I
won't change it gratuitously; but my tolerance for special-casing
stuff is dropping dramatically, so this one could go in the future
(into cd -p foo or similar).

Cheers,

f


From fperez.net at gmail.com  Thu Aug 14 23:23:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 20:23:47 -0700
Subject: [IPython-dev] Docs - authorship?
Message-ID: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>

Howdy,

I'd like to actually list who's written the documentation/manuals
explicitly, since that is a more book-like type of document (see the
mpl docs for example at
http://matplotlib.sourceforge.net/doc/html/index.html, click on the
PDF link).  I wrote over 90 pages of documentation originally for
that, and Brian has also written a ton of rst docs.  But because I
haven't kept track of the doc details since the latest reorganization,
I'd like to know who else I should list.

Please consider that I'm happy to follow purely an honor system here:
if you feel your contributions to that document (the PDF clocks in at
128 pages right now) make you a co-author, simply tell me and I'll add
your name to the list.  I will list 'authors: foo, bar, ...; with
contributions from: a,b,c,...' to credit both people who wrote major
portions and those who have contributed smaller but valuable parts.

Please just tell me and I'll be happy to add your names, listed
alphabetically by last name.  I think currently I have:

- authors: Brian and me.
- contributors: Ville (docstrings, wiki pages I imagine will be soon
ported since the problem used to be that we had lyx sources).

Don't know: Min, Stefan, Gael, Barry, etc.  Have you guys written
parts of the manual?

Does this sound OK to all?

Cheers,

f


From fperez.net at gmail.com  Fri Aug 15 00:51:43 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 21:51:43 -0700
Subject: [IPython-dev] Branches merged...
Message-ID: <db6b5ecc0808142151h5fb44ac8o916efc5cce093294@mail.gmail.com>

Howdy,

I've marked as merged Gael's sync frontend branch and Robert's context one.

I imagine they can be reopened for new work as needed, this was just
for bookeeping purposes.  We need to do a bit of branch house cleaning
on lp, but not now.  On to the beta...

f


From gael.varoquaux at normalesup.org  Fri Aug 15 01:40:22 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 15 Aug 2008 07:40:22 +0200
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
Message-ID: <20080815054022.GA23607@phare.normalesup.org>

On Thu, Aug 14, 2008 at 08:23:47PM -0700, Fernando Perez wrote:
> Don't know: Min, Stefan, Gael, Barry, etc.  Have you guys written
> parts of the manual?

Not me.

Ga?l


From ellisonbg.net at gmail.com  Fri Aug 15 02:07:32 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 14 Aug 2008 23:07:32 -0700
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
Message-ID: <6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com>

Min should be listed as a contributor as he wrote some of the parallel
computing docs.

Brian

On Thu, Aug 14, 2008 at 8:23 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> I'd like to actually list who's written the documentation/manuals
> explicitly, since that is a more book-like type of document (see the
> mpl docs for example at
> http://matplotlib.sourceforge.net/doc/html/index.html, click on the
> PDF link).  I wrote over 90 pages of documentation originally for
> that, and Brian has also written a ton of rst docs.  But because I
> haven't kept track of the doc details since the latest reorganization,
> I'd like to know who else I should list.
>
> Please consider that I'm happy to follow purely an honor system here:
> if you feel your contributions to that document (the PDF clocks in at
> 128 pages right now) make you a co-author, simply tell me and I'll add
> your name to the list.  I will list 'authors: foo, bar, ...; with
> contributions from: a,b,c,...' to credit both people who wrote major
> portions and those who have contributed smaller but valuable parts.
>
> Please just tell me and I'll be happy to add your names, listed
> alphabetically by last name.  I think currently I have:
>
> - authors: Brian and me.
> - contributors: Ville (docstrings, wiki pages I imagine will be soon
> ported since the problem used to be that we had lyx sources).
>
> Don't know: Min, Stefan, Gael, Barry, etc.  Have you guys written
> parts of the manual?
>
> Does this sound OK to all?
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Fri Aug 15 02:13:42 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 14 Aug 2008 23:13:42 -0700
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
	<6ce0ac130808142307v3b174e80x16fa515cbbbc3e82@mail.gmail.com>
Message-ID: <db6b5ecc0808142313o580833e9u4b2fdc6e2f3fdeb2@mail.gmail.com>

On Thu, Aug 14, 2008 at 11:07 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Min should be listed as a contributor as he wrote some of the parallel
> computing docs.

Got it, thanks.  I already got some replies off-list too.

Anyone else I'm missing?

Cheers,

f


From fperez.net at gmail.com  Fri Aug 15 06:42:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Aug 2008 03:42:36 -0700
Subject: [IPython-dev] 0.9 beta ready for a look...
Message-ID: <db6b5ecc0808150342k2854e50en4b8435fc3e4174a2@mail.gmail.com>

Hi all,

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

Please have a go at this.  I think I'll be very non-responsive for a
few days, unfortunately (scipy is looming large).  Hopefully the rest
of the gang can pitch in a bit.

But a pounding on everything would be welcome, in particular anyone
who can see if that windows installer does anything remotely sensible
would be great.  I have no vmware right now, and it may well be
putting the docs in the wrong place (or not at all), or worse.  And
I'm too fried to fix any more code right now.  I hate distutils, with
a vicious, depraved, passion.

Cheers,

f


From vivainio at gmail.com  Fri Aug 15 07:46:54 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 14:46:54 +0300
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
Message-ID: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com>

On Fri, Aug 15, 2008 at 6:23 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> Please consider that I'm happy to follow purely an honor system here:
> if you feel your contributions to that document (the PDF clocks in at
> 128 pages right now) make you a co-author, simply tell me and I'll add
> your name to the list.  I will list 'authors: foo, bar, ...; with
> contributions from: a,b,c,...' to credit both people who wrote major
> portions and those who have contributed smaller but valuable parts.

I have written the following chapters:

IPython as a system shell - the 'Sh' profile
String lists
IPython Extension Api
Provided extensions

And done some modifications elsewhere, at least in installation and
configuration. And yes, the stuff extracted from docstrigs.

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


From vivainio at gmail.com  Fri Aug 15 07:58:45 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 15 Aug 2008 14:58:45 +0300
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>
	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
Message-ID: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>

On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez <fperez.net at gmail.com> wrote:

> so I can't deal with this.  I'm ok leaving it as is, since the code is
> written, but no promises: when we restructure magics, I reserve the
> right to change this if needed.  If it can be kept without hassles, I

Of course, though I think there should be no need for that. If the
restructuring kills the freeform magic argument lists, it would need
a redesign before it makes the architecture too rigid.

> won't change it gratuitously; but my tolerance for special-casing
> stuff is dropping dramatically, so this one could go in the future
> (into cd -p foo or similar).

It's not special casing as far as code/architecture goes, it's special
casing as far as interactive usage goes (which is not a sin). User
interfaces are all about special cases like that.

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


From vivian at vdesmedt.com  Fri Aug 15 08:38:16 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Fri, 15 Aug 2008 14:38:16 +0200
Subject: [IPython-dev] synchronize with editor conform to PEP 8 and contains
	doc strings
In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
Message-ID: <48A578B8.80208@vdesmedt.com>

Fernando, Ville,

I have change my code to conform to PEP 8, I get rid of the camel names 
and I have added doc strings.

I'm ready for the next wave of comments :-)

Regards,
Vivian.



From laurent.dufrechou at gmail.com  Fri Aug 15 13:28:18 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Fri, 15 Aug 2008 19:28:18 +0200
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
Message-ID: <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com>

Hi ville,

I've just found that there is missing a file in the packaged thing:
options.conf that must go inside Ipython/gui/wx/
Is ok to add it?
It's a configuration that is used by my ipython0 WX gui to start up and
remind what are the options used by the user.

Cheers,
Laurent

> -----Message d'origine-----
> De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-
> bounces at scipy.org] De la part de Ville M. Vainio
> Envoy??: vendredi 15 ao?t 2008 13:59
> ??: Fernando Perez
> Cc?: IPython Development list
> Objet?: Re: [IPython-dev] 0.9 beta, anything left?
> 
> On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez <fperez.net at gmail.com>
> wrote:
> 
> > so I can't deal with this.  I'm ok leaving it as is, since the code
> is
> > written, but no promises: when we restructure magics, I reserve the
> > right to change this if needed.  If it can be kept without hassles, I
> 
> Of course, though I think there should be no need for that. If the
> restructuring kills the freeform magic argument lists, it would need
> a redesign before it makes the architecture too rigid.
> 
> > won't change it gratuitously; but my tolerance for special-casing
> > stuff is dropping dramatically, so this one could go in the future
> > (into cd -p foo or similar).
> 
> It's not special casing as far as code/architecture goes, it's special
> casing as far as interactive usage goes (which is not a sin). User
> interfaces are all about special cases like that.
> 
> --
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: options.conf
Type: application/octet-stream
Size: 110 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20080815/faadc293/attachment.obj>

From gael.varoquaux at normalesup.org  Fri Aug 15 14:16:06 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Fri, 15 Aug 2008 20:16:06 +0200
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <48a5bcc2.09a1660a.0ec5.62bc@mx.google.com>
References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
	<48a5bcc2.09a1660a.0ec5.62bc@mx.google.com>
Message-ID: <20080815181606.GC31583@phare.normalesup.org>

On Fri, Aug 15, 2008 at 07:28:18PM +0200, Laurent Dufr?chou wrote:
> I've just found that there is missing a file in the packaged thing:
> options.conf that must go inside Ipython/gui/wx/
> Is ok to add it?
> It's a configuration that is used by my ipython0 WX gui to start up and
> remind what are the options used by the user.

You have to keep in mind that it will be installed in a location where
the user might not be able to write. You do have a file in the user home
directory, right?

You need to add this file to the package data, in the setup.py, for it to
be installed. In ipython this is in setupbase.py, function
find_package_data.

Ga?l


From laurent.dufrechou at gmail.com  Fri Aug 15 16:02:01 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Fri, 15 Aug 2008 22:02:01 +0200
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <20080815181606.GC31583@phare.normalesup.org>
References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
	<48a5bcc2.09a1660a.0ec5.62bc@mx.google.com>
	<20080815181606.GC31583@phare.normalesup.org>
Message-ID: <48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com>

Hi Gael

> You have to keep in mind that it will be installed in a location where
> the user might not be able to write. You do have a file in the user
> home
> directory, right?
> 
> You need to add this file to the package data, in the setup.py, for it
> to
> be installed. In ipython this is in setupbase.py, function
> find_package_data.
> 

You mean installed in user directory or Ipython/gui/wx?
For the moment as I've got little time to work on it, I prefer to let it as
is in wx directory, it just permits wxIpython to run and user (under linux)
will not be able to save it's settings.
Will try to find a workaround for the user directory as you said. Do you
have an idea how user directory is defined under windows?
Under linux it's ~/ but under windows I do not have any idea yet how to find
it ... :)

Laurent





From robert.kern at gmail.com  Fri Aug 15 17:18:06 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 15 Aug 2008 16:18:06 -0500
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>	<46cb515a0808141347h2aea591blf8b2694aae0f0180@mail.gmail.com>	<46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
Message-ID: <g84rqe$cl8$1@ger.gmane.org>

Ville M. Vainio wrote:
> On Fri, Aug 15, 2008 at 6:06 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> 
>> so I can't deal with this.  I'm ok leaving it as is, since the code is
>> written, but no promises: when we restructure magics, I reserve the
>> right to change this if needed.  If it can be kept without hassles, I
> 
> Of course, though I think there should be no need for that. If the
> restructuring kills the freeform magic argument lists, it would need
> a redesign before it makes the architecture too rigid.

As stated before, the architecture will still start with freeform argument 
lists. As a matter of *policy* for builtin IPython magics, however, - and -- 
arguments should be processed uniformly with the same internal machinery.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From fperez.net at gmail.com  Fri Aug 15 17:29:19 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Aug 2008 14:29:19 -0700
Subject: [IPython-dev] 0.9 beta, anything left?
In-Reply-To: <48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com>
References: <46cb515a0808141401w635b4218s9dbf4ad35908b358@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
	<48a5bcc2.09a1660a.0ec5.62bc@mx.google.com>
	<20080815181606.GC31583@phare.normalesup.org>
	<48a5e0ca.0af6660a.0ec7.ffffb094@mx.google.com>
Message-ID: <db6b5ecc0808151429p1374cc61gbb1898454c9c8ce6@mail.gmail.com>

On Fri, Aug 15, 2008 at 1:02 PM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Hi Gael
>
>> You have to keep in mind that it will be installed in a location where
>> the user might not be able to write. You do have a file in the user
>> home
>> directory, right?
>>
>> You need to add this file to the package data, in the setup.py, for it
>> to
>> be installed. In ipython this is in setupbase.py, function
>> find_package_data.
>>
>
> You mean installed in user directory or Ipython/gui/wx?
> For the moment as I've got little time to work on it, I prefer to let it as
> is in wx directory, it just permits wxIpython to run and user (under linux)
> will not be able to save it's settings.
> Will try to find a workaround for the user directory as you said. Do you
> have an idea how user directory is defined under windows?
> Under linux it's ~/ but under windows I do not have any idea yet how to find
> it ... :)

The ipython directory is where you should be storing things:

In [6]: from IPython.ipapi import get

In [7]: ip = get()

In [8]: ip.IP.rc.ipythondir
Out[8]: '/home/fperez/.ipython'

This will be correctly computed under windows, users can set it via a
variable, etc.  All ipython code should access that guy instead of
computing it directly.  If you need to get the user's home dir, use
this:

In [9]: from IPython import  genutils

In [10]: genutils.get_home_dir
-------> genutils.get_home_dir()
Out[10]: '/home/fperez'

It also tries to do the right thing under Win32.


As for your code: please follow the pattern we've been using lately:
have a synced branch that we can review on launchpad, keep it synced
to trunk, and mark it for merging with the trunk.  See for example how
Vivian is doing it:

https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor

This way I or others can quickly review your changes, and if they are
OK, the merge process is quick and easy.  For example, right now I can
go to vivian's review section:

https://code.launchpad.net/~vivian-vdesmedt/ipython/synchronize-editor/+merge/676

and see exactly what's there that is unique to this branch.  We've
gone back and forth a few times, and she keeps improving the state of
the code, until we can merge it into the trunk.

Let us know if you have any questions on this, or see my recent email
to Vivian with the details and commands you need to type to make this
work.  Once you have it running, it's very easy to use.

Cheers,

f


From fperez.net at gmail.com  Fri Aug 15 17:39:39 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Aug 2008 14:39:39 -0700
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
	<46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com>
Message-ID: <db6b5ecc0808151439qba9279cu441523ac607e9340@mail.gmail.com>

On Fri, Aug 15, 2008 at 4:46 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

> I have written the following chapters:
>
> IPython as a system shell - the 'Sh' profile
> String lists
> IPython Extension Api
> Provided extensions
>
> And done some modifications elsewhere, at least in installation and
> configuration. And yes, the stuff extracted from docstrigs.

I've listed you as an author, I'll push the changes in a minute (will
go in for beta2).

Cheers,

f


From fperez.net at gmail.com  Fri Aug 15 17:43:38 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Aug 2008 14:43:38 -0700
Subject: [IPython-dev] Docs - authorship?
In-Reply-To: <db6b5ecc0808151439qba9279cu441523ac607e9340@mail.gmail.com>
References: <db6b5ecc0808142023x4ac454cfi492477c0e423dfe3@mail.gmail.com>
	<46cb515a0808150446h2c798554qc341594022c184cf@mail.gmail.com>
	<db6b5ecc0808151439qba9279cu441523ac607e9340@mail.gmail.com>
Message-ID: <db6b5ecc0808151443sa5a91cbna095c90d91bc25f6@mail.gmail.com>

On Fri, Aug 15, 2008 at 2:39 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, Aug 15, 2008 at 4:46 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> I have written the following chapters:
>>
>> IPython as a system shell - the 'Sh' profile
>> String lists
>> IPython Extension Api
>> Provided extensions
>>
>> And done some modifications elsewhere, at least in installation and
>> configuration. And yes, the stuff extracted from docstrigs.
>
> I've listed you as an author, I'll push the changes in a minute (will
> go in for beta2).

It would be great if you could add to the docs now that the system is
in good shape, more info about the various things you'd been putting
in the wiki.  I honestly lost track of much of that, but I'd like to
ensure that our docs keep up again with the funcitonality.  Originally
I was fanatic about not implementing anything without docs and for a
while we ended up with the lyx/wiki split and much
undocumented/scattered material. Let's do our best to catch up now,
with inspiration from the matplotlib guys (their new docs are at 475
pages and counting!).

Cheers,

f


From gael.varoquaux at normalesup.org  Fri Aug 15 18:42:11 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 16 Aug 2008 00:42:11 +0200
Subject: [IPython-dev] Interpreter class: 666
Message-ID: <20080815224211.GI31583@phare.normalesup.org>

I have just noticed that the interpreter class in ipython1 is exactly 666
lines long. I don't believe in coincidences.

Ga?l


From fperez.net at gmail.com  Fri Aug 15 20:51:16 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 15 Aug 2008 17:51:16 -0700
Subject: [IPython-dev] Interpreter class: 666
In-Reply-To: <20080815224211.GI31583@phare.normalesup.org>
References: <20080815224211.GI31583@phare.normalesup.org>
Message-ID: <db6b5ecc0808151751n14b0d765g5211e1d5f0fa998f@mail.gmail.com>

On Fri, Aug 15, 2008 at 3:42 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> I have just noticed that the interpreter class in ipython1 is exactly 666
> lines long. I don't believe in coincidences.

We refactored it not a moment too soon :)

Cheers,

f


From laurent.dufrechou at gmail.com  Sat Aug 16 06:28:59 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Sat, 16 Aug 2008 12:28:59 +0200
Subject: [IPython-dev] IPython Patch
In-Reply-To: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com>
References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com>
Message-ID: <48a6abee.05a0660a.76d1.0635@mx.google.com>

Hi cody,

Wow, thanks a lot for this patch! This was something I didn't knew how to
solve! Thks a lot.

> I made the changes to the code on the editra-plugins svn. Hopefully its
> not too out of date from the latest ipython.

Yeah, ipython guys have undergone big change in the frontend handling, so
I'm waiting the new code base to make the frontend evolve. That's why this
portion of code has not evolved since then :)
Ipython 0.9 (that is going to be commited soon) will have all the new code
base and will be ready for testing new code.
So I will port al my 'old' code to this new arch, soon.
Stay tuned ;)


> -----Message d'origine-----
> De?: Cody Precord [mailto:codyprecord at gmail.com]
> Envoy??: samedi 16 ao?t 2008 04:16
> ??: Laurent Dufrechou
> Objet?: IPython Patch
> 
> Hello,
> 
> I am in the process of trying to catch up on some bugs. Here is a patch
> to fix an encoding issue in the ipython_view.py. Currently its
> hardcoded to use cp1292 for encoding strings, this will fail on
> machines that have character sets that cant be represented by cp1292.
> Changed it to use 'locale.getpreferredencoding()' instead as this will
> return the encoding that the system is using for its native strings.
> 
> I made the changes to the code on the editra-plugins svn. Hopefully its
> not too out of date from the latest ipython.
> 




From fperez.net at gmail.com  Sat Aug 16 23:20:03 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 20:20:03 -0700
Subject: [IPython-dev] branch management getting better...
Message-ID: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>

Hi all,

I just merged Vivian's editor branch (will be in beta2) after she
updated it per our review.  Many thanks, Vivian!

But I wanted to report that both a cleaner workflow on my part (I'm
finally figuring out how to use bzr right) and what I think are
improvements on launchpad itself, mean that the history is being shown
much more cleanly.  For example, if you go to:

http://bazaar.launchpad.net/~ipython/ipython/trunk/changes

and click on the triangle for rev 1101, you'll see it shows the
topmost of Vivian's actual changes.  You can then click on that number
and you'll get:

http://bazaar.launchpad.net/~ipython/ipython/trunk/changes/1001.2.8

So while it would be very nice if lp actually expanded the tree in the
same window, at least now it shows the various merge lines.  I also
now see how to avoid the 'dropped revisions' problem we'd been having.

The only mistake I made was to forget to call the final commit with
--author before the push

For this reason, I'd like to ask *everyone* who has commit rights to,
for a little while, work on their own branches and let me do all the
merging (I promise to be quick).  If after a few weeks this works well
for everyone, we'll document the workflow well and figure out whether
to have a single merge person or a bunch of us with a workflow we all
understand.

But by not having anyone but me merge for a few revisions, we'll avoid
the dropping of revisions we've had multiple times (it's happened to a
bunch of us).

Ultimately I actually think this may be a good way to work in the long
haul, as we move towards more regular/strict code review (which we've
already started doing recently): the person who makes the actual
merge/push is in a way 'signing' the merged work as reviewer.

This seems to give us:

- summarized view of top-level changes, with an indication of who
'signs off' on the changes.
- preservation of the individual change history/authorship for
detailed analysis when needed.

Any comments?

Cheers,

f


From fperez.net at gmail.com  Sat Aug 16 23:41:01 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 20:41:01 -0700
Subject: [IPython-dev] IPython Patch
In-Reply-To: <48a6abee.05a0660a.76d1.0635@mx.google.com>
References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com>
	<48a6abee.05a0660a.76d1.0635@mx.google.com>
Message-ID: <db6b5ecc0808162041s1ac281d9h6197b098a440474b@mail.gmail.com>

Hi Laurent,

On Sat, Aug 16, 2008 at 3:28 AM, Laurent Dufr?chou
<laurent.dufrechou at gmail.com> wrote:
> Hi cody,
>
> Wow, thanks a lot for this patch! This was something I didn't knew how to
> solve! Thks a lot.
>
>> I made the changes to the code on the editra-plugins svn. Hopefully its
>> not too out of date from the latest ipython.
>
> Yeah, ipython guys have undergone big change in the frontend handling, so
> I'm waiting the new code base to make the frontend evolve. That's why this
> portion of code has not evolved since then :)
> Ipython 0.9 (that is going to be commited soon) will have all the new code
> base and will be ready for testing new code.
> So I will port al my 'old' code to this new arch, soon.
> Stay tuned ;)

please put your code in a branch we can all see, by doing something like

cd your_working_branch
bzr push  --remember lp:~laurent-dufrechou/ipython/trunk-dev

This will give everyone access to the code you're working on for
review and merge.  Also please make sure that when you merge a change
sent in by an outside contributor, you list this fact in the commit
message and record it as a standalone change  as

bzr commit --author="Name of other contributor"

This way we can then, on each release, properly credit external users
who make contributions to the project, which is very important.


By the way, I've just done what I suggested above and pushed my local
copy of trunk here:

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

so others can review also whatever I'm doing at any time.  As I said
in my previous email I want to be the only one to handle merging for a
few days, but that's *only while we figure out the details*.  I think
a good way to use launchpad will be for everyone to do their work on a
visible branch like this (in addition to possibly shared branches
where several people are working on something together).  These
branches can be kept forever in 'merge pending' status, as we all go
about implementing things and merging into trunk.

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 00:19:31 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 21:19:31 -0700
Subject: [IPython-dev] Ma branche
In-Reply-To: <20080817032722.GA13945@phare.normalesup.org>
References: <20080817032722.GA13945@phare.normalesup.org>
Message-ID: <db6b5ecc0808162119jdcffc9ey14bcbef086700840@mail.gmail.com>

On Sat, Aug 16, 2008 at 8:27 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

[ on-list, so we keep code reviews there]

> Salut,
>
> Tu pourra marger ma branche avant la release ? J'ai un peu de
> changements, rien d'important, mais j'avais fais une erreur de conception
> avec le maniement des namespaces.

In

+def isolate_ipython0(func):
+    """ Decorator to isolate execution that involves an iptyhon0.
+    """
+    def my_func(*args, **kwargs):
+        ipython0 = get_ipython0().IP
+        user_ns = ipython0.user_ns
+        global_ns = ipython0.global_ns
+        func(*args, **kwargs)
+        ipython0.user_ns = user_ns
+        ipython0.global_ns = global_ns
+
+    return my_func

there should be:

try:
  func...
finally:
  restore namespaces

so that if the test fails, the namespace handling isn't all mucked up, no?

Let me know when you change and I'll proceed.  Otherwise it looks OK.

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 00:23:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 21:23:40 -0700
Subject: [IPython-dev] synchronize with editor conform to PEP 8 and
	contains doc strings
In-Reply-To: <48A578B8.80208@vdesmedt.com>
References: <db6b5ecc0808140604mbefda56iab48b7be1af72459@mail.gmail.com>
	<db6b5ecc0808141431y5787160bxa3d8f3347d2851ab@mail.gmail.com>
	<46cb515a0808141737w284cf1d9xc84cdb7a8ba6eea4@mail.gmail.com>
	<db6b5ecc0808141744v1116dc61o438d8aaee8e07793@mail.gmail.com>
	<46cb515a0808141834u7aa7deadv8001740e56b5af85@mail.gmail.com>
	<db6b5ecc0808141843n77f43b67ra3c7921aea87ff7e@mail.gmail.com>
	<46cb515a0808141957v5bf38893jf8b3e98513fc0b80@mail.gmail.com>
	<db6b5ecc0808142006j541d79f5i4dce06e1909f2775@mail.gmail.com>
	<46cb515a0808150458u3105e024t2a2740391a476d31@mail.gmail.com>
	<48A578B8.80208@vdesmedt.com>
Message-ID: <db6b5ecc0808162123p593bd05ciab740b25cbc401f6@mail.gmail.com>

On Fri, Aug 15, 2008 at 5:38 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:
> Fernando, Ville,
>
> I have change my code to conform to PEP 8, I get rid of the camel names and
> I have added doc strings.
>
> I'm ready for the next wave of comments :-)

I just merged your branch.  Feel free to keep it listed if you intend
to continue polishing this feature, this way we can review other
improvements and merge them again in the future.

And many thanks!

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Aug 17 01:14:19 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 17 Aug 2008 07:14:19 +0200
Subject: [IPython-dev] Ma branche
In-Reply-To: <db6b5ecc0808162119jdcffc9ey14bcbef086700840@mail.gmail.com>
References: <20080817032722.GA13945@phare.normalesup.org>
	<db6b5ecc0808162119jdcffc9ey14bcbef086700840@mail.gmail.com>
Message-ID: <20080817051419.GH15301@phare.normalesup.org>

On Sat, Aug 16, 2008 at 09:19:31PM -0700, Fernando Perez wrote:
> +def isolate_ipython0(func):
> +    """ Decorator to isolate execution that involves an iptyhon0.
> +    """
> +    def my_func(*args, **kwargs):
> +        ipython0 = get_ipython0().IP
> +        user_ns = ipython0.user_ns
> +        global_ns = ipython0.global_ns
> +        func(*args, **kwargs)
> +        ipython0.user_ns = user_ns
> +        ipython0.global_ns = global_ns
> +
> +    return my_func

> there should be:

> try:
>   func...
> finally:
>   restore namespaces

> so that if the test fails, the namespace handling isn't all mucked up, no?

Yup, sounds good. Code review rocks.

> Let me know when you change and I'll proceed.  Otherwise it looks OK.

I am good. However I have a test failing on my box and it doesn't seem to
be due to my code (I have running the test suite without my tests):

======================================================================
FAIL: Doctest: IPython.iplib.InteractiveShell.complete
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
line 343, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
IPython.iplib.InteractiveShell.complete
  File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py",
line 989, in complete

----------------------------------------------------------------------
File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", line
1011, in IPython.iplib.InteractiveShell.complete
Failed example:
    _ip.IP.complete('x.l')
Expected:
    ['x.ljust', 'x.lower', 'x.lstrip']
Got:
    []

>>  raise self.failureException(self.format_failure(<StringIO.StringIO
>>  instance at 0x40201c6c>.getvalue()))
    

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

In addition, I have a test failing due to an import to win32api failing.

Does all this work on your box?

Ga?l


From fperez.net at gmail.com  Sun Aug 17 01:27:55 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 22:27:55 -0700
Subject: [IPython-dev] Ma branche
In-Reply-To: <20080817051419.GH15301@phare.normalesup.org>
References: <20080817032722.GA13945@phare.normalesup.org>
	<db6b5ecc0808162119jdcffc9ey14bcbef086700840@mail.gmail.com>
	<20080817051419.GH15301@phare.normalesup.org>
Message-ID: <db6b5ecc0808162227q57498ccdkc08923135f068406@mail.gmail.com>

Hey,

On Sat, Aug 16, 2008 at 10:14 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> I am good. However I have a test failing on my box and it doesn't seem to
> be due to my code (I have running the test suite without my tests):
>
> ======================================================================
> FAIL: Doctest: IPython.iplib.InteractiveShell.complete
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/usr/local/lib/python2.5/site-packages/IPython_doctest_plugin-0.1-py2.5.egg/ipdoctest.py",
> line 343, in runTest
>    raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for
> IPython.iplib.InteractiveShell.complete
>  File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py",
> line 989, in complete
>
> ----------------------------------------------------------------------
> File "/home/varoquau/dev/ipython/ipython-frontend/IPython/iplib.py", line
> 1011, in IPython.iplib.InteractiveShell.complete
> Failed example:
>    _ip.IP.complete('x.l')
> Expected:
>    ['x.ljust', 'x.lower', 'x.lstrip']
> Got:
>    []
>
>>>  raise self.failureException(self.format_failure(<StringIO.StringIO
>>>  instance at 0x40201c6c>.getvalue()))

This passes fine now, after fixes I did a few days ago.  Have you
merged fully with trunk?  Here's what 'make all' gives on my box:

Ran 463 tests in 71.895s

> In addition, I have a test failing due to an import to win32api failing.

I don't see that, but I'm not sure why (this is on linux).

I'll pull your changes now, my plan for next week after the scipy
tutorial is to harden the test suite and improve its usability so
everyone can start using it.


Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 01:30:16 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 22:30:16 -0700
Subject: [IPython-dev] Ma branche
In-Reply-To: <20080817051419.GH15301@phare.normalesup.org>
References: <20080817032722.GA13945@phare.normalesup.org>
	<db6b5ecc0808162119jdcffc9ey14bcbef086700840@mail.gmail.com>
	<20080817051419.GH15301@phare.normalesup.org>
Message-ID: <db6b5ecc0808162230l45cee20ctae1cd6a4a5366b8c@mail.gmail.com>

On Sat, Aug 16, 2008 at 10:14 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> I am good. However I have a test failing on my box and it doesn't seem to

OK, I just finished the push, many thanks.

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 02:23:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 23:23:48 -0700
Subject: [IPython-dev] FYI: Updated team URL on launchpad
Message-ID: <db6b5ecc0808162323m511d5b29wc89c8db91d038072@mail.gmail.com>

Hi all,

in case you kept any bookmarks for this around, I've changed the name
and description of the IPython team on launchpad, so now we have:

https://launchpad.net/ipython -> project page (code, bugs,...). Unchanged.
https://launchpad.net/~ipython-dev -> "IPython Developers" team. Changed.

Hopefully this will reduce confusion.

If anyone objects let me know, but I figured some simple decisions
like these can just be made :)

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 02:27:44 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 23:27:44 -0700
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <484A4962.5050606@aisystems.be>
References: <484A4962.5050606@aisystems.be>
Message-ID: <db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>

Hi Vivian,

2008/6/7 Vivian De Smedt <vds at aisystems.be>:
> Dear All,
>
> This is mail concerning pyreadline. I'm  a Window user and I'm using
> pyreadline. Because of my VisualStudio background I have configured code
> completion to be Ctrl+' ' and tab to be tab insertion.

I don't know if your patch ever got in or not, but by now Jorgen is
running a proper launchpad setup for pyreadline:

https://code.launchpad.net/pyreadline

Since you're pretty comfortable with bzr/launchpad by now, this should
give you a good way to keep your fixes visible to Jorgen, so he can
review them and possibly merge them in.

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 02:33:38 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 16 Aug 2008 23:33:38 -0700
Subject: [IPython-dev] How do I do this in bzr? (again)
In-Reply-To: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com>
References: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com>
Message-ID: <db6b5ecc0808162333t7244d418i5fd9668328d3d1ad@mail.gmail.com>

Brian,

On Fri, Jun 6, 2008 at 10:22 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> I am wondering how I can take a file/files from one bzr branch
> (ipython1-dev) and bring them into another branch (ipython) if the two
> branches have no common heritage.  In this case, the two branches
> hardly have the same structure and the incoming files will have to be
> put into new location.  Is this even possible?  I know I could do mv
> and then bzr add, but then I loose the history of the individual
> files.  Any ideas?

I don't know if you ever figured out an answer to this, but I'd sure
love to know.

In the svn transition and ip0/1 merge we kind of butchered the ipython
history, which I'm very sad about (and much of it was my fault, so I'm
not blaming anyone here).  It would be cool if some bzr guru came
around and was able to produce a copy of today's trunk with a cleaner
history...

Cheers,

f


From stefan at sun.ac.za  Sun Aug 17 03:57:31 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 17 Aug 2008 02:57:31 -0500
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
Message-ID: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>

2008/8/16 Fernando Perez <fperez.net at gmail.com>:
> much more cleanly.  For example, if you go to:
>
> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes

I can't open this page -- am I doing something stupid?

St?fan


From fperez.net at gmail.com  Sun Aug 17 03:59:51 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 00:59:51 -0700
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
Message-ID: <db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>

On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/8/16 Fernando Perez <fperez.net at gmail.com>:
>> much more cleanly.  For example, if you go to:
>>
>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes
>
> I can't open this page -- am I doing something stupid?

Sorry, as I just changed the team name, the url moved (after I'd
written my original email):

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes

Cheers,

f


From laurent.dufrechou at gmail.com  Sun Aug 17 04:12:30 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Sun, 17 Aug 2008 10:12:30 +0200
Subject: [IPython-dev] IPython Patch
In-Reply-To: <db6b5ecc0808162041s1ac281d9h6197b098a440474b@mail.gmail.com>
References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com>
	<48a6abee.05a0660a.76d1.0635@mx.google.com>
	<db6b5ecc0808162041s1ac281d9h6197b098a440474b@mail.gmail.com>
Message-ID: <7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com>

Excellent, that was i wanted to ask you.
I didn't knew how to create a new branch on launchad. Will do that thx.

Update...:
laurent at Pep:~/dev/ipython-wx_Ipython$ bzr push --remember
lp:~laurent-dufrechou/ipython/trunk-dev
bzr: ERROR: Transport operation not possible: http does not support mkdir()

I've taken a look there (interesting doc by the way, can be a good
tutorial to link in ipython wiki):
http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html

They seem to use bzr+ssh protocol.
bzr push bzr+ssh://laurent-dufrechou at bazaar.launchpad.net/~laurent-dufrechou/ipython/trunk-dev

And now seems ok, but the name is trunk-dev, is it ok?


From stefan at sun.ac.za  Sun Aug 17 04:15:32 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 17 Aug 2008 03:15:32 -0500
Subject: [IPython-dev] How do I do this in bzr? (again)
In-Reply-To: <db6b5ecc0808162333t7244d418i5fd9668328d3d1ad@mail.gmail.com>
References: <6ce0ac130806061022s6fd44fcbj4d59d954ac80fbc1@mail.gmail.com>
	<db6b5ecc0808162333t7244d418i5fd9668328d3d1ad@mail.gmail.com>
Message-ID: <9457e7c80808170115v9de2279n97703cffe445f394@mail.gmail.com>

2008/8/17 Fernando Perez <fperez.net at gmail.com>:
> On Fri, Jun 6, 2008 at 10:22 AM, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> Hi,
>>
>> I am wondering how I can take a file/files from one bzr branch
>> (ipython1-dev) and bring them into another branch (ipython) if the two
>> branches have no common heritage.  In this case, the two branches
>> hardly have the same structure and the incoming files will have to be
>> put into new location.  Is this even possible?  I know I could do mv
>> and then bzr add, but then I loose the history of the individual
>> files.  Any ideas?
>
> I don't know if you ever figured out an answer to this, but I'd sure
> love to know.

This plugin might help:

https://launchpad.net/bzr-merge-into/

St?fan


From fperez.net at gmail.com  Sun Aug 17 04:29:04 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 01:29:04 -0700
Subject: [IPython-dev] IPython Patch
In-Reply-To: <7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com>
References: <0C33BF2A-87BF-43A5-B394-E5BD077D8290@gmail.com>
	<48a6abee.05a0660a.76d1.0635@mx.google.com>
	<db6b5ecc0808162041s1ac281d9h6197b098a440474b@mail.gmail.com>
	<7ced318f0808170112y29de41a8w31532db17ca362d8@mail.gmail.com>
Message-ID: <db6b5ecc0808170129s66895a75w154704175d01e598@mail.gmail.com>

On Sun, Aug 17, 2008 at 1:12 AM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Excellent, that was i wanted to ask you.
> I didn't knew how to create a new branch on launchad. Will do that thx.
>
> Update...:
> laurent at Pep:~/dev/ipython-wx_Ipython$ bzr push --remember
> lp:~laurent-dufrechou/ipython/trunk-dev
> bzr: ERROR: Transport operation not possible: http does not support mkdir()
>
> I've taken a look there (interesting doc by the way, can be a good
> tutorial to link in ipython wiki):
> http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
>
> They seem to use bzr+ssh protocol.
> bzr push bzr+ssh://laurent-dufrechou at bazaar.launchpad.net/~laurent-dufrechou/ipython/trunk-dev
>
> And now seems ok, but the name is trunk-dev, is it ok?

Yes, that's fine: it's where *you* do development of the trunk (I
named mine the same).  It's now visible here:

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

and I've marked it as proposed for merge into ipython trunk, so at any
time it's easy to see any pending differences you may have.

In my mind, I think of

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

as "this is where user 'somebody' does personal development of the
trunk for project ipython".  It seems like an easy and simple
mnemonic.  As I mentioned, mine is identically hosted at

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

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 05:07:22 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 02:07:22 -0700
Subject: [IPython-dev] Thoughts re Leo and Ipython notebooks.
In-Reply-To: <ffb592890807280827m6a00e0cfx68ed0f4e2cb865bb@mail.gmail.com>
References: <ffb592890807280827m6a00e0cfx68ed0f4e2cb865bb@mail.gmail.com>
Message-ID: <db6b5ecc0808170207i5c8a5746h372510c59db6f6d3@mail.gmail.com>

Hi Edward,

2008/7/28 Edward K. Ream <edreamleo at gmail.com>:
> I've just posted some thoughts re Leo as a compound document:
> http://groups.google.com/group/leo-editor/browse_thread/thread/759d20f81119e5ca
>
> Among other things, the post discusses adding spreadsheet-like features to
> Leo in a fairly easy way.  These are just ideas, intended to encourage
> further invention.
>
> My intuition tells me that IPython folk might find these ideas useful or
> provocative:
>
> - Leo could be considered an IPython notebook.
>
> - Generalized spreadsheets might be useful in recording scientific
> experiments.
>
> - Scientific experiments might want to generate notebook/spreadsheet entries
> using scripts.
>
> - The post shows how to declare the "type" of scripts/nodes and show how to
> embed scripts of arbitrary types into notebook entries.
>
> Imo, we have only just scratched the surface of what can be done with
> scripts and notebooks.

While I don't use leo myself, I know Ville has continued to make
improvements to Leo integration, so there's definitely good things to
be found here.  You may have seen that we're now using the launchpad
resources much more, so if at any point in time you find yourself
writing a useful piece of code for the integration of the two that
requires changes to ipython, simply publish it in a branch under your
username on launchpad that we can access.  We'll be happy to review
the code, give you feedback, and merge it in if it all works out
(we're moving towards a regular cycle of reviewing all code that we
put up as much as possible).

Cheers,

f


From laurent.dufrechou at gmail.com  Sun Aug 17 05:38:32 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Sun, 17 Aug 2008 11:38:32 +0200
Subject: [IPython-dev] Ipython frontend (async, sync,
	line or block oriented...)
Message-ID: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>

Hi barry,
I've started to take a look at your work. Seems from my quick review
that you've done an asynchroneous frontend, block oriented while ga?l
as gone through the opposite :) sync and line oriented.

In fact, seems you've used ipython1 while gael has gone ipython0 no?
(If I remember well, ipython1 can instanciate remote ipython instance)

Can you explain me the difference between block oriented and line oriented?

Line oriented is (I think) that you feed ipython instance with line
and ipython instance determine by itself block bounds.
So I think block oriented is that it is the frontend taht determine
the bounds of the block?

Cheers,
Laurent


From vds at aisystems.be  Sun Aug 17 06:34:43 2008
From: vds at aisystems.be (Vivian De Smedt)
Date: Sun, 17 Aug 2008 12:34:43 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>
References: <484A4962.5050606@aisystems.be>
	<db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>
Message-ID: <48A7FEC3.3080008@aisystems.be>

Hi Fernando,

Thanks for the merge in IPython, I'm always very proud to be able to 
contribute to my favorite python tool ;-)

For pyreadline I did what you suggested I have created a tab-insertion 
branch from the pyreadline trunk
I fix the problem in that branch commit and push the result to launchpad.

It should be ready for review and merge :-)

Vivian.



From fperez.net at gmail.com  Sun Aug 17 06:38:28 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 03:38:28 -0700
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <48A7FEC3.3080008@aisystems.be>
References: <484A4962.5050606@aisystems.be>
	<db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>
	<48A7FEC3.3080008@aisystems.be>
Message-ID: <db6b5ecc0808170338j2517bdc7t43b2c120d2b20bd1@mail.gmail.com>

On Sun, Aug 17, 2008 at 3:34 AM, Vivian De Smedt <vds at aisystems.be> wrote:
> Hi Fernando,
>
> Thanks for the merge in IPython, I'm always very proud to be able to
> contribute to my favorite python tool ;-)

Well, we're glad to have you on board and contributing.

> For pyreadline I did what you suggested I have created a tab-insertion
> branch from the pyreadline trunk
> I fix the problem in that branch commit and push the result to launchpad.
>
> It should be ready for review and merge :-)

Great!  Keep in mind that Jorgen Stenarson is the one who really runs
pyreadline, so I'm afraid many of us here won't be able to help much
on that one.  But I'm sure Jorgen (and hopefully others who know the
win32 platform well) will give you feedback for the merge.

Regards,

f


From fperez.net at gmail.com  Sun Aug 17 06:51:23 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 03:51:23 -0700
Subject: [IPython-dev] ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe??
	[was: Re: Win32 IPython1?]
In-Reply-To: <486EA0A3.9020307@uml.edu>
References: <48457029.8020401@uml.edu>
	<db6b5ecc0806031317y6c790992yfed719ed0e8b4c47@mail.gmail.com>
	<4864549D.2010407@uml.edu>
	<db6b5ecc0806262219w424ae80eh39c54321c789a91c@mail.gmail.com>
	<48659443.4050109@uml.edu>
	<db6b5ecc0806271842l208ebc0cwc554ff7756d6f0c4@mail.gmail.com>
	<4865AB18.4040000@uml.edu>
	<db6b5ecc0806281138p4a3f2c83i16f3f6453abca055@mail.gmail.com>
	<cd7634ce0806281153h5ac76143ie825a0bfa2a41eca@mail.gmail.com>
	<486EA0A3.9020307@uml.edu>
Message-ID: <db6b5ecc0808170351q54910b0fh72171d5ba6de7451@mail.gmail.com>

2008/7/4 Alex Brown <Alexander_Brown at uml.edu>:
> Following your recommendations I'm working with your (merged) trunk in
> WinXP.  However I am having continuing difficulty getting
> ipython-0.9.0.bzr.r1016-py2.5 to work with either Python 2.4 or 2.5 (both
> Enthought distributions).  It may be that I'm not familiar enough with the
> setup and installer tools, or with Windows touchup tricks.  Is there any
> chance of getting an exe installer, perhaps
> ipython-0.9.0.bzr.r1016-py2.5.win32-setup.exe?

Sorry for the long delay on this, as you may have noticed, it's been a
bit hectic around here :)

But now at

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

you can find the 0.9 beta #2 ready:

http://ipython.scipy.org/dist/testing/ipython-0.9.beta2.win32-setup.exe

We'd greatly appreciate your feedback on what works and what doesn't.

Cheers,

f


From vivainio at gmail.com  Sun Aug 17 06:52:58 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sun, 17 Aug 2008 13:52:58 +0300
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <484D3F93.807@aisystems.be>
References: <484A4962.5050606@aisystems.be>
	<200806091242.47835.meine@informatik.uni-hamburg.de>
	<484D2F59.9080206@aisystems.be>
	<200806091624.35935.meine@informatik.uni-hamburg.de>
	<484D3F93.807@aisystems.be>
Message-ID: <46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com>

2008/6/9 Vivian De Smedt <vds at aisystems.be>:

> Here is my proposition of patch in a diff form.

> +        line_cursor = len(self.l_buffer)

I think this only works if the cursor is at the end of the line. What
if you go in the middle of entered text and press tab?

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


From fperez.net at gmail.com  Sun Aug 17 06:55:13 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 03:55:13 -0700
Subject: [IPython-dev] 0.9 beta #2 is ready
Message-ID: <db6b5ecc0808170355l2672225co120b4d49939a0b66@mail.gmail.com>

At the usual place:

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

Feedback very much welcome.

Cheers,

f


From jorgen.stenarson at bostream.nu  Sun Aug 17 07:44:45 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sun, 17 Aug 2008 13:44:45 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <48A7FEC3.3080008@aisystems.be>
References: <484A4962.5050606@aisystems.be>	<db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>
	<48A7FEC3.3080008@aisystems.be>
Message-ID: <48A80F2D.4030901@bostream.nu>

Hi Vivian,

I'm happy to get patches and will look at this once I'm back from 
vacation. I'm back 25 aug.

J?rgen

Vivian De Smedt skrev:
> Hi Fernando,
> 
> Thanks for the merge in IPython, I'm always very proud to be able to 
> contribute to my favorite python tool ;-)
> 
> For pyreadline I did what you suggested I have created a tab-insertion 
> branch from the pyreadline trunk
> I fix the problem in that branch commit and push the result to launchpad.
> 
> It should be ready for review and merge :-)
> 
> Vivian.
> 
> _______________________________________________
> 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 Aug 17 11:10:30 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 17 Aug 2008 17:10:30 +0200
Subject: [IPython-dev] Ipython frontend (async, sync,
	line or block oriented...)
In-Reply-To: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>
References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>
Message-ID: <20080817151030.GB14087@phare.normalesup.org>

On Sun, Aug 17, 2008 at 11:38:32AM +0200, Laurent Dufrechou wrote:
> I've started to take a look at your work. Seems from my quick review
> that you've done an asynchroneous frontend, block oriented while ga?l
> as gone through the opposite :) sync and line oriented.

That's exactly it. We try to share a common base object, but as I was
still experimenting with my own interfaces, I may not have shared as much
as possible. If possible, in the long run, we want to move up methods
from the LineFrontend class to the BaseFrontend class.

> In fact, seems you've used ipython1 while gael has gone ipython0 no?
> (If I remember well, ipython1 can instanciate remote ipython instance)

Well, not really. I use an ipython1 instance (the Interpreter), but I
also instanciate an ipython0 to prefilter the lines to give the magics
and other goodies. In the long run, we should try and get rid of this
instance as the magics get abstracted from ipython0.

> Can you explain me the difference between block oriented and line oriented?

In block-oriented you can edit several blocks at a time. Line-oriented
does not know what blocks are, and only knows how to edit the last line
(or set of lines, in my case). Line-oriented is weaker than
block-oriented. For asynchronuous operation, block-oriented makes much
more sens than line-oriented.

Cheers,

Ga?l


From vivian at vdesmedt.com  Sun Aug 17 15:06:01 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 17 Aug 2008 21:06:01 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com>
References: <484A4962.5050606@aisystems.be>	<200806091242.47835.meine@informatik.uni-hamburg.de>	<484D2F59.9080206@aisystems.be>	<200806091624.35935.meine@informatik.uni-hamburg.de>	<484D3F93.807@aisystems.be>
	<46cb515a0808170352k6d6bfed5j2dbb6667b96a5675@mail.gmail.com>
Message-ID: <48A87699.3010209@vdesmedt.com>

Ville,

Thanks for your comment. You are right. Here is an another proposition 
that seems to address the point that you highlight:

+       cursor = min(self.l_buffer.point, len(self.l_buffer.line_buffer))
+       ws = ' ' * (self.tabstop - (cursor % self.tabstop))
-       ws = ' ' * (self.tabstop - (self.line_cursor%self.tabstop))

Vivian.

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

From laurent.dufrechou at gmail.com  Sun Aug 17 15:21:53 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Sun, 17 Aug 2008 21:21:53 +0200
Subject: [IPython-dev] Future of wxIpython
Message-ID: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com>

Hi guys,

I've started to quick review code in frontend.
I must admit I don't know where to go in fact. Gael has implemented a
wx widget that looks like what I've done with other let say
technological choices.
My code in /gui/wx is duplicate to this code (IpythonX.py). Where do
you want to go with this code?
Do you want me, to let it there in /gui or move it to /frontend/???

Seems for me that code base for frontend is in the root of frontend.
Barry has an asynchroneous cocoa frontend in ./frontend/cocoa, gael a
synchroneous in /frontend/wx.
Must I add subdirectory, ./frontend/example/ ./frontend/wx2 ./frontend/wxaui ?_?
If possible I would like not to trash my code :), and make it evolve
with frontend new features.
So what are my options?

Cheers,
Laurent


From gael.varoquaux at normalesup.org  Sun Aug 17 15:29:47 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 17 Aug 2008 21:29:47 +0200
Subject: [IPython-dev] Future of wxIpython
In-Reply-To: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com>
References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com>
Message-ID: <20080817192947.GC692@phare.normalesup.org>

On Sun, Aug 17, 2008 at 09:21:53PM +0200, Laurent Dufrechou wrote:
> My code in /gui/wx is duplicate to this code (IpythonX.py). Where do
> you want to go with this code?
> Do you want me, to let it there in /gui or move it to /frontend/???

I would like the code in frontend to stay general. Your gui code does
more than a frontend, as it introduces menus, and other items that
actually get in the way of somebody who wants to reuse the frontend as
part of a bigger application, without the bells and whistles. I have gone
in my design for a layer structure, with different objects inheriting
from eachother. The application designer is welcome to use any one of
these.

> Seems for me that code base for frontend is in the root of frontend.
> Barry has an asynchroneous cocoa frontend in ./frontend/cocoa, gael a
> synchroneous in /frontend/wx.
> Must I add subdirectory, ./frontend/example/ ./frontend/wx2 ./frontend/wxaui ?_?

I would rather not have another directory with Wx code. It will make it
very confusing to people.

> If possible I would like not to trash my code :), and make it evolve
> with frontend new features.
> So what are my options?

Subclass or reuse either the WxController is wx_frontend, or the IPythonX
one in ipythonx, if you want Ctrl-D to quit, as this is the only
additional feature (appart from title changing).

You have to define what it is that you want to develop: what is the goal
of the code you are writing. This should help us figure out how it will
fit in the big picture.

Ga?l


From fperez.net at gmail.com  Sun Aug 17 15:43:57 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 12:43:57 -0700
Subject: [IPython-dev] Future of wxIpython
In-Reply-To: <20080817192947.GC692@phare.normalesup.org>
References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com>
	<20080817192947.GC692@phare.normalesup.org>
Message-ID: <db6b5ecc0808171243w1b8a38e1sc7da04f63a53120c@mail.gmail.com>

On Sun, Aug 17, 2008 at 12:29 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Aug 17, 2008 at 09:21:53PM +0200, Laurent Dufrechou wrote:

>> If possible I would like not to trash my code :), and make it evolve
>> with frontend new features.
>> So what are my options?
>
> Subclass or reuse either the WxController is wx_frontend, or the IPythonX
> one in ipythonx, if you want Ctrl-D to quit, as this is the only
> additional feature (appart from title changing).
>
> You have to define what it is that you want to develop: what is the goal
> of the code you are writing. This should help us figure out how it will
> fit in the big picture.

As I said in an eariler email, I have the impression that Laurent's
code is a self-contained WX app, while Gael has built a basic
component with an eye for the new architecture.  So from where I stand
(and I could be missing something, I haven't gone in detail over both
codes), Laurent should be able to deploy a nice, full-featured
IPython-Wx app, with menus, side panes, etc, built on top of the core
component developed by Gael.  Gael's is much simpler by design: it is
intended to be almost like a 'wx-ipython widget' to be reused
elsewhere, in particular for possible embedding into Enthought's
Envisage system in the future.

This division of concerns seems reasonable to me: one is a widget-like
component, one is an end-user app.  We can definitely ship both.

And Laurent: we are most certainly interested in keeping your code and
contributions in the project, no question about that.  It's just that
as part of the natural process of software evolution, sometimes parts
of early prototypes do get scrapped for a different
reimplementation/reorganization.  That doesn't mean they were wrong or
not appreciated, quite the opposite: they are often necessary to
better understand the problem and continue making progress.  So I'm
sure that in the end, you'll end up reusing some of your early code,
throwing away other pieces (because you'll be able to use Gael's
components), but using your combined understanding of the problem to
provide a better solution.  Software development is by nature
iterative, and in each cycle a little gets tossed out, a little new
gets added, and hopefully the result is systematically better :)

How does this sound?

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 15:54:43 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 12:54:43 -0700
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
Message-ID: <db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>

Hey,

On Sun, Aug 17, 2008 at 9:41 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/8/17 Fernando Perez <fperez.net at gmail.com>:
>> On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
>>> 2008/8/16 Fernando Perez <fperez.net at gmail.com>:
>>>> much more cleanly.  For example, if you go to:
>>>>
>>>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes
>>>
>>> I can't open this page -- am I doing something stupid?
>>
>> Sorry, as I just changed the team name, the url moved (after I'd
>> written my original email):
>>
>> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes
>
> So, the number to click on is now 1102 (not 1101).  Did this change
> since you wrote the mail?  I'm just wondering whether the graph is
> ever re-labeled.

It shouldn't, but this time it did: in all the storm of doing many
things yesterday, I did a pull instead of a merge, which caused again
the dreaded revision dropping, so the numbers changed.  This is
precisely what I was trying to avoid, so it's a bit embarrassing, I
was just doing too many things and tripped.


If you see now, for example this revision:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1103

got committed (by me) with Gael as author, since I was merging a set
of patches by him.  In a local log you can see the distinction between
committer and author for this one, which is useful: I was committing
work that was 100% Gael's, so this lets us track exactly who did what.
 This message (we've referred to it before) has a nice summary of the
workflow I think we're settling into:

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

and I now find that I really am starting to agree with the various
reasons he explains there, in particular:

"""
So why the distinction between a mainline and a merge commit. We have a
few use cases for them...

1) "These are the patches reviewed by me". I don't review every single
change someone makes. But I *do* review the merge before I commit it.

2) "Every commit on the mainline passes the test suite". This is a
pretty big one for our bzr.dev process.

3) "Summary of changes". It gives an obvious place to summarize the many
(potentially hundreds or more) commits someone made. You frequently want
to keep all of those hundreds of revisions around, because it gives you
nice, fine grained details about things that have changed. (Useful for
annotate, or any sort of digging that needs to be done).

But having a single summary revision, also lets the people who *don't*
want to wade through 100 revisions to understand "Implemented bound
branches".
"""

I'm also starting to use the same approach even when summarizing *my
own* commits: I work on my branch (which is publicly mirrored) and do
lots of small, frequent commits.  Then I merge from it into my local
mirror and push that upstream, with a single summary message.  As we
evolve towards more organized code review, this will be useful.  Once
a set of changes have been reviewed from the developer's branch, they
get merged as a single set into the mainline.  The only direct work
into trunk should be the little tweaks that need to be made at release
time to the version numbering files and such.

Argh, finally getting this...  :)

Cheers,

f


From gael.varoquaux at normalesup.org  Sun Aug 17 15:54:53 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 17 Aug 2008 21:54:53 +0200
Subject: [IPython-dev] Future of wxIpython
In-Reply-To: <db6b5ecc0808171243w1b8a38e1sc7da04f63a53120c@mail.gmail.com>
References: <7ced318f0808171221r46ba2389r55d92de778adcc52@mail.gmail.com>
	<20080817192947.GC692@phare.normalesup.org>
	<db6b5ecc0808171243w1b8a38e1sc7da04f63a53120c@mail.gmail.com>
Message-ID: <20080817195453.GE692@phare.normalesup.org>

On Sun, Aug 17, 2008 at 12:43:57PM -0700, Fernando Perez wrote:
> As I said in an eariler email, I have the impression that Laurent's
> code is a self-contained WX app, while Gael has built a basic
> component with an eye for the new architecture.  So from where I stand
> (and I could be missing something, I haven't gone in detail over both
> codes), Laurent should be able to deploy a nice, full-featured
> IPython-Wx app, with menus, side panes, etc, built on top of the core
> component developed by Gael.  Gael's is much simpler by design: it is
> intended to be almost like a 'wx-ipython widget' to be reused
> elsewhere, in particular for possible embedding into Enthought's
> Envisage system in the future.

That's exactly it. I think the goals of the two code bases are not the
same, and thus Laurent can hopefuly make good use of my implementation.
In addition, I will not be pursuing Laurent's goals.

Ga?l


From gael.varoquaux at normalesup.org  Sun Aug 17 18:10:00 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 18 Aug 2008 00:10:00 +0200
Subject: [IPython-dev] Bug in ultraTB, in current trunk.
Message-ID: <20080817221000.GH692@phare.normalesup.org>

Line 495 of ULtraTB.py, there is a bug that is probably due to the merge
of the synchronize-editor branch on rev 1001.2.1. The filename variable
is not defined anywhere.

Ga?l


From fperez.net at gmail.com  Sun Aug 17 18:40:54 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 15:40:54 -0700
Subject: [IPython-dev] Bug in ultraTB, in current trunk.
In-Reply-To: <20080817221000.GH692@phare.normalesup.org>
References: <20080817221000.GH692@phare.normalesup.org>
Message-ID: <db6b5ecc0808171540k46ad3ea9r6f836b72d0aa6a9f@mail.gmail.com>

On Sun, Aug 17, 2008 at 3:10 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Line 495 of ULtraTB.py, there is a bug that is probably due to the merge
> of the synchronize-editor branch on rev 1001.2.1. The filename variable
> is not defined anywhere.

Actually it was defined above in the same file, but only
conditionally, so there was still a bug.  I've fixed it and pushed an
updated beta out.  Thanks for reporting this.

My goal for the sprints next week is to finish the testing machinery
so that everyone can run the tests (without special installation or
needing twisted/foolscap/anything beyond nose).  Once we're there, I'd
like to institute a policy of not accepting any code, from *anyone*
(that means all of us, starting with me) that is missing tests.  Since
we have so much code already in place, this will mean that if you
touch an existing function that's not already well tested (very
likely), the burden will be on you (that's the royal you, starting
obviously with myself) to first add tests for the function as it is
now, to ensure that your new changes don't break it.

It's the only way we'll be able to refactor what we need without
endless breakage.  Harsh, but IMO necessary.

Thoughts, dissent?

Cheers,

f


From fperez.net at gmail.com  Sun Aug 17 18:41:31 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 17 Aug 2008 15:41:31 -0700
Subject: [IPython-dev] Bug in ultraTB, in current trunk.
In-Reply-To: <db6b5ecc0808171540k46ad3ea9r6f836b72d0aa6a9f@mail.gmail.com>
References: <20080817221000.GH692@phare.normalesup.org>
	<db6b5ecc0808171540k46ad3ea9r6f836b72d0aa6a9f@mail.gmail.com>
Message-ID: <db6b5ecc0808171541k40df1430u770732c4355c405a@mail.gmail.com>

On Sun, Aug 17, 2008 at 3:40 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> Actually it was defined above in the same file, but only

s/file/function/.  Sorry

f


From barrywark at gmail.com  Mon Aug 18 09:57:38 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 18 Aug 2008 09:57:38 -0400
Subject: [IPython-dev] Ipython frontend (async, sync,
	line or block oriented...)
In-Reply-To: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>
References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>
Message-ID: <cd7634ce0808180657kc655f76j6b91bd2dea7c0878@mail.gmail.com>

Laurent,

Sorry to take a couple of days to get back to you. I imagine you'll
see from my responses below that Ga?l and I have differing views on
many of the design decisions that have gone into the curent frontend
package. That's good, I think. Let me give you a quick overview of our
goals in the frontend package and then I'll try to answer your
specific questions inline below.

The new IPython architecture (previously called ipython1) provides
many opportunities to separate the interpreter logic from UI (terminal
or GUI) logic. The frontend package is intended to make it easier
(though not trivial) to write frontends for the IPython interpreter
(where interpreter is IPython.kernel.core.interpreter.Interpreter, the
new ipython1 interpreter, or an
IPython.kernel.engineservice.IEngineService, the new ipython1
network/remote-aware IPython engine). There is a minimal functional
spec in docs/source/development that highlights the many use casess
we're trying to support. Briefly, they fall into three categories:
1) terminal-based frontends to a single Interpreter instance; very
similar to the current IPython UI experience
2) GUI-based frontends to a single Interpreter instance; this is the
category for both your and Ga?l's efforts. Because the current
architecture is more separable, it will (hopefully) be easier to write
a GUI frontend to the Interpreter using the new architecture.
3) GUI-based frontends that make use of Twisted and the
IPython.kernel.engineservice architecture to provide a frontend to one
or more local or remote engine services. This is the goal of my (still
evolving) Cocoa frontend. I personally think this is a very promissing
new possibility for new UI's for interactive computing that we haven't
been able to explore with IPython in the ipyhton0 architecture.

Clearly, supporting a diverse range of use cases is a difficult task.
The goal of frontend is to provide whatever common functionality we
can identify that supports all three of these use cases, embodied in a
common base class FrontendBase. In addition, Gael has spearheaded
creating common base classes for each of these use cases. The
intention *is not* to create a common UI widget or event library for
IPython. Frontend writiers will still have to make decisions (and,
gasp, write code) to do "the right thing" with their UI system's
events and widgets.

Much of the original architecture for the frontend package was
motivated by use case #3 above. Hence, the frontend API is biased
towards treating code in blocks, rather than in lines. Gael's work
required line-oriented APIs. We're still struggling to resolve this
discrepancy. My goal in the next several weeks is to get the Cocoa
frontend (asyncrhonous, block-oriented) to a stable state, thus
stabilizing the frontend API for use case #3 and then to work on
integrating Gael's use case and code in a more seamless way.

more answers below...

cheers,
Barry

On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Hi barry,
> I've started to take a look at your work. Seems from my quick review
> that you've done an asynchroneous frontend, block oriented while ga?l
> as gone through the opposite :) sync and line oriented.

correct

>
> In fact, seems you've used ipython1 while gael has gone ipython0 no?
> (If I remember well, ipython1 can instanciate remote ipython instance)

correct

>
> Can you explain me the difference between block oriented and line oriented?

If you're familiar with Mathematica and Matlab, the UI of Mathematical
provides  good model for block oriented input whereas the Matlab
command line (and the ipython0 terminal UI) provides a good model for
line-oriented input.

Line-oriented input is often more natural for people who are used to
command-line UIs. The distributed nature of the ipython1 architecture
(and the associated network latencies, loss of connections, etc.) make
line-oriented UIs difficult. In this case, the block-oriented UI is a
better model of the underlying architecture and so (I think) a better
UI paradigm because it helps the user's mental model come into line
with the software model.

Having used both Mathematica and Matlab, I've found that my Matlab use
patterns have migrated towards more block-like usage, so I personally
don't find the block-oriented UI a problem, but personal preferences
are, well, personal. We'll see.

>
> Line oriented is (I think) that you feed ipython instance with line
> and ipython instance determine by itself block bounds.
> So I think block oriented is that it is the frontend taht determine
> the bounds of the block?

Correct. This determination is an example of the common code that all
block-oriented frontends will require and is therefore included in the
frontend package.

>
> Cheers,
> Laurent
>


From barrywark at gmail.com  Mon Aug 18 10:01:43 2008
From: barrywark at gmail.com (Barry Wark)
Date: Mon, 18 Aug 2008 10:01:43 -0400
Subject: [IPython-dev] Ipython frontend (async, sync,
	line or block oriented...)
In-Reply-To: <cd7634ce0808180657kc655f76j6b91bd2dea7c0878@mail.gmail.com>
References: <7ced318f0808170238p246c0340ne0b5b953f18139e4@mail.gmail.com>
	<cd7634ce0808180657kc655f76j6b91bd2dea7c0878@mail.gmail.com>
Message-ID: <cd7634ce0808180701l7965ac81o1375985ea2105937@mail.gmail.com>

On Mon, Aug 18, 2008 at 9:57 AM, Barry Wark <barrywark at gmail.com> wrote:
> Laurent,
>
> Sorry to take a couple of days to get back to you. I imagine you'll
> see from my responses below that Ga?l and I have differing views on
> many of the design decisions that have gone into the curent frontend
> package. That's good, I think. Let me give you a quick overview of our
> goals in the frontend package and then I'll try to answer your
> specific questions inline below.
>
> The new IPython architecture (previously called ipython1) provides
> many opportunities to separate the interpreter logic from UI (terminal
> or GUI) logic. The frontend package is intended to make it easier
> (though not trivial) to write frontends for the IPython interpreter
> (where interpreter is IPython.kernel.core.interpreter.Interpreter, the
> new ipython1 interpreter, or an
> IPython.kernel.engineservice.IEngineService, the new ipython1
> network/remote-aware IPython engine). There is a minimal functional
> spec in docs/source/development that highlights the many use casess
> we're trying to support. Briefly, they fall into three categories:
> 1) terminal-based frontends to a single Interpreter instance; very
> similar to the current IPython UI experience
> 2) GUI-based frontends to a single Interpreter instance; this is the
> category for both your and Ga?l's efforts. Because the current
> architecture is more separable, it will (hopefully) be easier to write
> a GUI frontend to the Interpreter using the new architecture.
> 3) GUI-based frontends that make use of Twisted and the
> IPython.kernel.engineservice architecture to provide a frontend to one
> or more local or remote engine services. This is the goal of my (still
> evolving) Cocoa frontend. I personally think this is a very promissing
> new possibility for new UI's for interactive computing that we haven't
> been able to explore with IPython in the ipyhton0 architecture.
>
> Clearly, supporting a diverse range of use cases is a difficult task.
> The goal of frontend is to provide whatever common functionality we
> can identify that supports all three of these use cases, embodied in a
> common base class FrontendBase. In addition, Gael has spearheaded
> creating common base classes for each of these use cases. The
> intention *is not* to create a common UI widget or event library for
> IPython. Frontend writiers will still have to make decisions (and,
> gasp, write code) to do "the right thing" with their UI system's
> events and widgets.
>
> Much of the original architecture for the frontend package was
> motivated by use case #3 above. Hence, the frontend API is biased
> towards treating code in blocks, rather than in lines. Gael's work
> required line-oriented APIs. We're still struggling to resolve this
> discrepancy. My goal in the next several weeks is to get the Cocoa
> frontend (asyncrhonous, block-oriented) to a stable state, thus
> stabilizing the frontend API for use case #3 and then to work on
> integrating Gael's use case and code in a more seamless way.
>
> more answers below...
>
> cheers,
> Barry
>
> On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou
> <laurent.dufrechou at gmail.com> wrote:
>> Hi barry,
>> I've started to take a look at your work. Seems from my quick review
>> that you've done an asynchroneous frontend, block oriented while ga?l
>> as gone through the opposite :) sync and line oriented.
>
> correct
>
>>
>> In fact, seems you've used ipython1 while gael has gone ipython0 no?
>> (If I remember well, ipython1 can instanciate remote ipython instance)
>
> correct

Sorry, not entirely correct. Gael is using both the ipyhon1 and
ipython0 APIs and interpreters in his frontend. This is because the
ipython1 Interpreter is not yet as full-featured as the ipyhon0
frontend. Gael was under time constraints while writing his frontend.
Unfortunatley he didn't have time to bring the ipyhon1 interpreter up
to the feature set he needed and so had to go with this hybrid
approach. As you might guess, this ultimatley leads to his frontend
suffering from some of the tight-integration of UI and Interpreter
suffered by old IPython frontends.


>
>>
>> Can you explain me the difference between block oriented and line oriented?
>
> If you're familiar with Mathematica and Matlab, the UI of Mathematical
> provides  good model for block oriented input whereas the Matlab
> command line (and the ipython0 terminal UI) provides a good model for
> line-oriented input.
>
> Line-oriented input is often more natural for people who are used to
> command-line UIs. The distributed nature of the ipython1 architecture
> (and the associated network latencies, loss of connections, etc.) make
> line-oriented UIs difficult. In this case, the block-oriented UI is a
> better model of the underlying architecture and so (I think) a better
> UI paradigm because it helps the user's mental model come into line
> with the software model.
>
> Having used both Mathematica and Matlab, I've found that my Matlab use
> patterns have migrated towards more block-like usage, so I personally
> don't find the block-oriented UI a problem, but personal preferences
> are, well, personal. We'll see.
>
>>
>> Line oriented is (I think) that you feed ipython instance with line
>> and ipython instance determine by itself block bounds.
>> So I think block oriented is that it is the frontend taht determine
>> the bounds of the block?
>
> Correct. This determination is an example of the common code that all
> block-oriented frontends will require and is therefore included in the
> frontend package.
>
>>
>> Cheers,
>> Laurent
>>
>


From barrywark at gmail.com  Wed Aug 20 16:12:55 2008
From: barrywark at gmail.com (Barry Wark)
Date: Wed, 20 Aug 2008 16:12:55 -0400
Subject: [IPython-dev] pushing python class definition to engines
In-Reply-To: <6ce0ac130807151936o2b8fe47do7ee7900d8df62e4f@mail.gmail.com>
References: <487D3A3F.4000304@astraw.com>
	<6ce0ac130807151936o2b8fe47do7ee7900d8df62e4f@mail.gmail.com>
Message-ID: <cd7634ce0808201312l18489bd7vc4dfc06b1ecadc0d@mail.gmail.com>

If only we had a language in which code and data were interchangeable...
*LISP guru cries in the corner*

~Barry

On Tue, Jul 15, 2008 at 10:36 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Andrew,
>
> As Robert mentioned, this is really a limitation in how Python
> serializes classes and instances.  I have dealt with this in a couple
> of ways:
>
> 1.  Don't use classes :)  More, seriously though, functions, even
> those defined interactively can be pushed and pulled using
> push_function and pull_function.  There are only a few limitations,
> like no closures.
>
> 2.  Define your classes in a standalone module that can be imported by
> the engines, controller and client.  Then, you can push and pull
> instances just fine using push and pull.  This is mostly how I work -
> I develop classes in serial first, put them in a module and then
> simply import.
>
> Ironically, functions work better for this than classes.  Until Python
> has a different way of serializing classes and instances, we are
> stuck.
>
> Cheers,
>
> Brian
>
>
> On Tue, Jul 15, 2008 at 6:01 PM, Andrew Straw <strawman at astraw.com> wrote:
>> After seeing Brian Granger's great demo of the parallel abilities in
>> IPython last week at the SIAM conference, I'm playing with ipython trunk
>> which I just pulled out of launchpad (for this reason, I'm posting on
>> the -dev list).
>>
>> Anyhow, if I start a client in the usual way:
>>
>> from IPython.kernel import client
>> mec = client.MultiEngineClient()
>>
>> I can easily push Python integers:
>>
>> a=5
>> mec['a'] = a
>> print mec.gather('a')
>>
>> But pushing classes doesn't work:
>>
>> class MyObj(object):
>>    def __init__(self,x):
>>        print 'PID',os.getpid()
>>        self.x=x
>>
>> mec['MyObj'] = MyObj
>> print mec.gather('MyObj')
>>
>> That gives the following error. How can I push a class definition to my
>> engines?
>>
>> Traceback (most recent call last):
>>  File "flydra/test_ipython.py", line 14, in <module>
>>    mec.push_function(dict(MyObj= MyObj,))
>>  File
>> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/multiengineclient.py",
>> line 606, in push_function
>>    return self._blockFromThread(self.smultiengine.push_function,
>> namespace, targets=targets, block=block)
>>  File
>> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/multiengineclient.py",
>> line 456, in _blockFromThread
>>    result = blockingCallFromThread(function, *args, **kwargs)
>>  File
>> "/home/astraw/PY_ipython/lib/python2.5/site-packages/IPython/kernel/twistedutil.py",
>> line 69, in blockingCallFromThread
>>    return twisted.internet.threads.blockingCallFromThread(reactor, f,
>> *a, **kw)
>>  File
>> "/home/astraw/PY_ipython/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-x86_64.egg/twisted/internet/threads.py",
>> line 83, in blockingCallFromThread
>>    result.raiseException()
>>  File
>> "/home/astraw/PY_ipython/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-linux-x86_64.egg/twisted/python/failure.py",
>> line 319, in raiseException
>>    raise self.type, self.value, self.tb
>> AttributeError: 'module' object has no attribute 'MyObj'
>>
>> _______________________________________________
>> 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  Sat Aug 23 21:16:01 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 23 Aug 2008 18:16:01 -0700
Subject: [IPython-dev] Help with win32 installer...
Message-ID: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>

Howdy,

we haven't received  any feedback on the 0.9beta3, and it's looking
like we probably had some breakage in the big reorganization of the
setup.py file after the ipython0/1 big merge.  Right now I don't have
a win32 machine at all, and while Brian and Min do, none of us knows
windows much at all.

Is there any chance that someone could have a crack at seeing if the
win32 installer can be made to work correctly? By correctly I mean
like the 0.8.x series, which left ipython links in the Start menu in a
submenu labelled "IPython", with a few profile shortcuts premade and
links to html/pdf versions of the docs.

We've really made great progress, so it would be really good to see a
solid 0.9 release made...

Any help will be very, very welcome.

Cheers,

f


From laurent.dufrechou at gmail.com  Sun Aug 24 15:52:19 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Sun, 24 Aug 2008 21:52:19 +0200
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
Message-ID: <48b1bc06.06e2660a.0218.7ade@mx.google.com>

All seems ok on vista, installer is using privileged right, only html help
is not ok:
It point to : C:\Python25\share\doc\ipython\manual\ipython.html
This file does not exist but index.html exist so...
Pdf one is OK.

The main issue I have is that as I have used egg_setup.py develop, so when I
launch ipython it launch the one in my dev directory...
Any trick to disable develop mode and to help you test beta3?

Laurent

> -----Message d'origine-----
> De?: ipython-dev-bounces at scipy.org [mailto:ipython-dev-
> bounces at scipy.org] De la part de Fernando Perez
> Envoy??: dimanche 24 ao?t 2008 03:16
> ??: IPython Development list
> Objet?: [IPython-dev] Help with win32 installer...
> 
> Howdy,
> 
> we haven't received  any feedback on the 0.9beta3, and it's looking
> like we probably had some breakage in the big reorganization of the
> setup.py file after the ipython0/1 big merge.  Right now I don't have
> a win32 machine at all, and while Brian and Min do, none of us knows
> windows much at all.
> 
> Is there any chance that someone could have a crack at seeing if the
> win32 installer can be made to work correctly? By correctly I mean
> like the 0.8.x series, which left ipython links in the Start menu in a
> submenu labelled "IPython", with a few profile shortcuts premade and
> links to html/pdf versions of the docs.
> 
> We've really made great progress, so it would be really good to see a
> solid 0.9 release made...
> 
> Any help will be very, very welcome.
> 
> Cheers,
> 
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From laurent.dufrechou at gmail.com  Sun Aug 24 16:09:00 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sun, 24 Aug 2008 22:09:00 +0200
Subject: [IPython-dev] ipython0 and sys.displayhook
Message-ID: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com>

Hello guys,

 

I've run into a weird bug in editra ipython plugin. When instanciating
ipython0 shell sys.displayhook was aletred by ipython and that interfered
with classical python shell plugin in editra.

I've quick workarounded it with saving sys.displayhook, then creating
ipython0 instance and finally restoring sys.displayhook.

The strange think is that ipython0 is still working. J

 

In shell.py it seems that you do the same trick I do with "class
IPShellEmbed"

While in iplib.py there is:

        # I don't like assigning globally to sys, because it means when

        # embedding instances, each embedded instance overrides the previous

        # choice. But sys.displayhook seems to be called internally by exec,

        # so I don't see a way around it.  We first save the original and
then

        # overwrite it.

        self.sys_displayhook = sys.displayhook

        sys.displayhook = self.outputcache

 

So why this displayhook is used for?

 

Laurent

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

From gael.varoquaux at normalesup.org  Sun Aug 24 16:13:06 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 24 Aug 2008 22:13:06 +0200
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <48b1bc06.06e2660a.0218.7ade@mx.google.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
Message-ID: <20080824201306.GC16507@phare.normalesup.org>

On Sun, Aug 24, 2008 at 09:52:19PM +0200, Laurent Dufr?chou wrote:
> The main issue I have is that as I have used egg_setup.py develop, so when I
> launch ipython it launch the one in my dev directory...
> Any trick to disable develop mode and to help you test beta3?

Remove the IPython.egg-link in your site-packages and edit
easy-install.pth to remove the line that references ipython.

HTH,

Ga?l


From laurent.dufrechou at gmail.com  Sun Aug 24 16:52:52 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Sun, 24 Aug 2008 22:52:52 +0200
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <20080824201306.GC16507@phare.normalesup.org>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
	<20080824201306.GC16507@phare.normalesup.org>
Message-ID: <48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com>

Ok That Helped :)
Beta3 install works under vista (so must work under XP, Vista is the worst
thing you would like to test no? :p)
Only html help is not OK as said before.

> -----Message d'origine-----
> De?: Gael Varoquaux [mailto:gael.varoquaux at normalesup.org]
> Envoy??: dimanche 24 ao?t 2008 22:13
> ??: Laurent Dufr?chou
> Cc?: 'Fernando Perez'; 'IPython Development list'
> Objet?: Re: [IPython-dev] Help with win32 installer...
> 
> On Sun, Aug 24, 2008 at 09:52:19PM +0200, Laurent Dufr?chou wrote:
> > The main issue I have is that as I have used egg_setup.py develop, so
> when I
> > launch ipython it launch the one in my dev directory...
> > Any trick to disable develop mode and to help you test beta3?
> 
> Remove the IPython.egg-link in your site-packages and edit
> easy-install.pth to remove the line that references ipython.
> 
> HTH,
> 
> Ga?l



From laurent.dufrechou at gmail.com  Sun Aug 24 17:21:11 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sun, 24 Aug 2008 23:21:11 +0200
Subject: [IPython-dev] Important bug correction ofr wxPython
Message-ID: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com>

Hi fernando,

I've recently commited some important bug correction for wxIPython.

This include, encoding problem, options.conf saved in user directory,
sys.displayhook bug correction + addition of wxIpython in ./scripts.

Can you include them for next beta or RC? (That does not interfere with
ipython itself)

 

Cheers,

Laurent

 

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

From fperez.net at gmail.com  Sun Aug 24 18:26:52 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Aug 2008 15:26:52 -0700
Subject: [IPython-dev] Important bug correction ofr wxPython
In-Reply-To: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com>
References: <48b1d0da.0ab6660a.7395.2fd9@mx.google.com>
Message-ID: <db6b5ecc0808241526p2a0a318o17a88f4402bc2549@mail.gmail.com>

Hi Laurent,

On Sun, Aug 24, 2008 at 2:21 PM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Hi fernando,
>
> I've recently commited some important bug correction for wxIPython.
>
> This include, encoding problem, options.conf saved in user directory,
> sys.displayhook bug correction + addition of wxIpython in ./scripts.
>
> Can you include them for next beta or RC? (That does not interfere with
> ipython itself)

Yup, no problem.  I'm leaving Los Angeles right now to go back home
and won't look at this tomorrow, but the RC won't be cut until
Wednesday I think, so no worries.

Thanks!

f


From fperez.net at gmail.com  Sun Aug 24 18:33:45 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 24 Aug 2008 15:33:45 -0700
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
	<20080824201306.GC16507@phare.normalesup.org>
	<48b1ca37.0a4d5e0a.2da8.ffffdafe@mx.google.com>
Message-ID: <db6b5ecc0808241533i25ee431v15ed4977f2bbc221@mail.gmail.com>

Hey Laurent,

Many thanks for the win32 tests!  It will be easy to fix the docs
links, I was worried the breakage had been worse.

Cheers,

f


From vivainio at gmail.com  Mon Aug 25 03:01:32 2008
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 25 Aug 2008 10:01:32 +0300
Subject: [IPython-dev] ipython0 and sys.displayhook
In-Reply-To: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com>
References: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com>
Message-ID: <46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com>

On Sun, Aug 24, 2008 at 11:09 PM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:

> So why this displayhook is used for?

You can see that it's used as outputcache. Also, result_display hooks
are hooked to it.

IPython may appear to work if you change it, but it really doesn't
work properly.

So, you don't really want to forget ipythons display hook.

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


From laurent.dufrechou at gmail.com  Mon Aug 25 05:28:14 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Mon, 25 Aug 2008 11:28:14 +0200
Subject: [IPython-dev] ipython0 and sys.displayhook
In-Reply-To: <46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com>
References: <48b1bfee.0305560a.3d48.ffffc6de@mx.google.com>
	<46cb515a0808250001i209892ebsda54e9d442fec6b@mail.gmail.com>
Message-ID: <48b27b30.09c5660a.0ff6.ffffd07a@mx.google.com>

Hi ville,

> > So why this displayhook is used for?
> 
> You can see that it's used as outputcache. Also, result_display hooks
> are hooked to it.
> 
> IPython may appear to work if you change it, but it really doesn't
> work properly.
> 
> So, you don't really want to forget ipythons display hook.

Arf bad news :/
Thx for your quick reply.
What's strange is that in "class IPShellEmbed" in Shell.py line 178 the same
trick like I did is used. So either, IPShellEmbed could be buggy either
there is a trick used inside that permits to restore sys.display hook...
Will read this code tonight, there must be a trick if you said that
sys.displayhook is important!
(in comment it  is said it used by 'exec' but so far I haven't seen side
effect, perhaps that's because I'm using a recent python interpreter...)
Will check result_display/outputcache too... thx

Cheers,
Laurent





From schut at sarvision.nl  Mon Aug 25 05:54:03 2008
From: schut at sarvision.nl (Vincent Schut)
Date: Mon, 25 Aug 2008 11:54:03 +0200
Subject: [IPython-dev] ipcontroller & ipengine
Message-ID: <48B2813B.80203@sarvision.nl>

Hi,

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

I used to start 'ipcontroller --engine-ip 10.0.0.211' on localhost, and
then 'ipengine -n8' on 10.0.0.211 (an 8-core machine). I could then
connect from localhost to the controller, which connected to the
engines at 10.0.0.211. Or I started ipcluster -n8 on 10.0.0.211, and then
started a client connection from ipython specifying 10.0.0.211 as the
controller-host to connect to.
Neither works anymore.
I know I can fiddle with furl files, but it is not convenient for me to
have to copy a furl file each time I (re)start a cluster. I don't want
to mess with ssh-agent either, if possible.

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

Btw this is the error when I try to start a controller on localhost,
ready to listen for engines on 10.0.0.211:

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




From jorgen.stenarson at bostream.nu  Mon Aug 25 13:15:47 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 25 Aug 2008 19:15:47 +0200
Subject: [IPython-dev] pyreadline and Tab insertion
In-Reply-To: <48A7FEC3.3080008@aisystems.be>
References: <484A4962.5050606@aisystems.be>	<db6b5ecc0808162327r2925d212l1d5cd22e11959664@mail.gmail.com>
	<48A7FEC3.3080008@aisystems.be>
Message-ID: <48B2E8C3.7090102@bostream.nu>

Vivian,

thanks for the patch it has been merged into trunk.

/J?rgen

Vivian De Smedt skrev:
> Hi Fernando,
> 
> Thanks for the merge in IPython, I'm always very proud to be able to 
> contribute to my favorite python tool ;-)
> 
> For pyreadline I did what you suggested I have created a tab-insertion 
> branch from the pyreadline trunk
> I fix the problem in that branch commit and push the result to launchpad.
> 
> It should be ready for review and merge :-)
> 
> Vivian.
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> 



From jorgen.stenarson at bostream.nu  Mon Aug 25 13:30:41 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 25 Aug 2008 19:30:41 +0200
Subject: [IPython-dev] moving a bug
Message-ID: <48B2EC41.3050302@bostream.nu>

Hi,

I would like to move [Bug 257680] over to the pyreadline bugtracker does 
anyone know if it is possible to do so easily? Or do I have to open a 
new bug there and copy the contents over?

/J?rgen



From fperez.net at gmail.com  Tue Aug 26 02:54:18 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 25 Aug 2008 23:54:18 -0700
Subject: [IPython-dev] moving a bug
In-Reply-To: <48B2EC41.3050302@bostream.nu>
References: <48B2EC41.3050302@bostream.nu>
Message-ID: <db6b5ecc0808252354o1458d250t9a7223c1cb3c251d@mail.gmail.com>

Hey,

On Mon, Aug 25, 2008 at 10:30 AM, J?rgen Stenarson
<jorgen.stenarson at bostream.nu> wrote:
> Hi,
>
> I would like to move [Bug 257680] over to the pyreadline bugtracker does
> anyone know if it is possible to do so easily? Or do I have to open a
> new bug there and copy the contents over?

I just did move it to pyreadline by changing the 'affects' field.

Cheers,

f


From jorgen.stenarson at bostream.nu  Tue Aug 26 14:16:15 2008
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 26 Aug 2008 20:16:15 +0200
Subject: [IPython-dev] moving a bug
In-Reply-To: <db6b5ecc0808252354o1458d250t9a7223c1cb3c251d@mail.gmail.com>
References: <48B2EC41.3050302@bostream.nu>
	<db6b5ecc0808252354o1458d250t9a7223c1cb3c251d@mail.gmail.com>
Message-ID: <48B4486F.9000302@bostream.nu>

Fernando Perez skrev:
> Hey,
> 
> On Mon, Aug 25, 2008 at 10:30 AM, J?rgen Stenarson
> <jorgen.stenarson at bostream.nu> wrote:
>> Hi,
>>
>> I would like to move [Bug 257680] over to the pyreadline bugtracker does
>> anyone know if it is possible to do so easily? Or do I have to open a
>> new bug there and copy the contents over?
> 
> I just did move it to pyreadline by changing the 'affects' field.
> 
> Cheers,
> 
> f
> 
Thanks

/J?rgen


From fperez.net at gmail.com  Tue Aug 26 15:28:16 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Aug 2008 12:28:16 -0700
Subject: [IPython-dev] Documenting the recent editor sync extension
Message-ID: <db6b5ecc0808261228p2b9e0f45ncfb21b109b5c6803@mail.gmail.com>

Hi Vivian,

I was today trying to help someone use your new editor sync tool:

http://bazaar.launchpad.net/%7Eipython-dev/ipython/trunk/annotate/1121?file_id=ipy_synchronize_with-20080612032938-lxufpyi2plzu3mlc-1

and I realized that in the review process, I forgot to ask you for any
kind of top-level documentation and examples.  Could you please add a
top-level docstring describing the intended purpose of the tool, its
main use cases, and a simple example of how to use it?  There should
be also a short paragraph about it in the
docs/source/interactive/extension_api.txt file, so that users who read
the manual can find out about it.

We really need to move to ensuring that *all* new code can be used by
new users by:

- finding its capabilities in the documentation with a high-level view
- finding a module-level docstring that explains the purpose of the tool
- having good function/class-level docstrings that explain the
specific use of each call.

Otherwise we'll be forever answering these questions on the mailing list.

Cheers,

f


From sunqiang at gmail.com  Tue Aug 26 22:21:33 2008
From: sunqiang at gmail.com (sunqiang)
Date: Wed, 27 Aug 2008 10:21:33 +0800
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <48b1bc06.06e2660a.0218.7ade@mx.google.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
Message-ID: <b4df18670808261921l61f4c13cpac44af29b60e51d0@mail.gmail.com>

same there, one windows server 2003, on windows xp. woks well except
the html link.

On Mon, Aug 25, 2008 at 3:52 AM, Laurent Dufr?chou
<laurent.dufrechou at gmail.com> wrote:
> All seems ok on vista, installer is using privileged right, only html help
> is not ok:
> It point to : C:\Python25\share\doc\ipython\manual\ipython.html
> This file does not exist but index.html exist so...
> Pdf one is OK.
>
> The main issue I have is that as I have used egg_setup.py develop, so when I
> launch ipython it launch the one in my dev directory...
> Any trick to disable develop mode and to help you test beta3?
>
> Laurent
>
>> -----Message d'origine-----
>> De : ipython-dev-bounces at scipy.org [mailto:ipython-dev-
>> bounces at scipy.org] De la part de Fernando Perez
>> Envoy? : dimanche 24 ao?t 2008 03:16
>> ? : IPython Development list
>> Objet : [IPython-dev] Help with win32 installer...
>>
>> Howdy,
>>
>> we haven't received  any feedback on the 0.9beta3, and it's looking
>> like we probably had some breakage in the big reorganization of the
>> setup.py file after the ipython0/1 big merge.  Right now I don't have
>> a win32 machine at all, and while Brian and Min do, none of us knows
>> windows much at all.
>>
>> Is there any chance that someone could have a crack at seeing if the
>> win32 installer can be made to work correctly? By correctly I mean
>> like the 0.8.x series, which left ipython links in the Start menu in a
>> submenu labelled "IPython", with a few profile shortcuts premade and
>> links to html/pdf versions of the docs.
>>
>> We've really made great progress, so it would be really good to see a
>> solid 0.9 release made...
>>
>> Any help will be very, very welcome.
>>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Aug 26 22:29:00 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 26 Aug 2008 19:29:00 -0700
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <b4df18670808261921l61f4c13cpac44af29b60e51d0@mail.gmail.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
	<b4df18670808261921l61f4c13cpac44af29b60e51d0@mail.gmail.com>
Message-ID: <db6b5ecc0808261929s153d3165oeccc77cad0bc9d@mail.gmail.com>

On Tue, Aug 26, 2008 at 7:21 PM, sunqiang <sunqiang at gmail.com> wrote:
> same there, one windows server 2003, on windows xp. woks well except
> the html link.

Great, thanks.  I'm fixing it literally *right now*.

Cheers,

f


From sunqiang at gmail.com  Tue Aug 26 22:34:16 2008
From: sunqiang at gmail.com (sunqiang)
Date: Wed, 27 Aug 2008 10:34:16 +0800
Subject: [IPython-dev] Help with win32 installer...
In-Reply-To: <db6b5ecc0808261929s153d3165oeccc77cad0bc9d@mail.gmail.com>
References: <db6b5ecc0808231816s46877fdcy932c2e22e67eea97@mail.gmail.com>
	<48b1bc06.06e2660a.0218.7ade@mx.google.com>
	<b4df18670808261921l61f4c13cpac44af29b60e51d0@mail.gmail.com>
	<db6b5ecc0808261929s153d3165oeccc77cad0bc9d@mail.gmail.com>
Message-ID: <b4df18670808261934t2f2ef4d5yc215088789619242@mail.gmail.com>

Fernando, I have reply this to u directly three day before, It looks
Gmail label it as a spam.

On Wed, Aug 27, 2008 at 10:29 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Aug 26, 2008 at 7:21 PM, sunqiang <sunqiang at gmail.com> wrote:
>> same there, one windows server 2003, on windows xp. woks well except
>> the html link.
>
> Great, thanks.  I'm fixing it literally *right now*.
>
> Cheers,
>
> f
>


From vivian at vdesmedt.com  Wed Aug 27 11:02:33 2008
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Wed, 27 Aug 2008 19:32:33 +0430
Subject: [IPython-dev] Documenting the recent editor sync extension
In-Reply-To: <db6b5ecc0808261228p2b9e0f45ncfb21b109b5c6803@mail.gmail.com>
References: <db6b5ecc0808261228p2b9e0f45ncfb21b109b5c6803@mail.gmail.com>
Message-ID: <48B56C89.2060409@vdesmedt.com>

Hi Fernando,
> Could you please add a
> top-level docstring describing the intended purpose of the tool, its
> main use cases, and a simple example of how to use it?  There should
> be also a short paragraph about it in the
> docs/source/interactive/extension_api.txt file, so that users who read
> the manual can find out about it.
>   
Of course. I'm in Iran right now and I have a poor internet access. But 
as soon I come back I'll commit my change in the doc strings and let you 
know.

Cheers,
Vivian.



From fperez.net at gmail.com  Wed Aug 27 14:53:59 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Aug 2008 11:53:59 -0700
Subject: [IPython-dev] Documenting the recent editor sync extension
In-Reply-To: <48B56C89.2060409@vdesmedt.com>
References: <db6b5ecc0808261228p2b9e0f45ncfb21b109b5c6803@mail.gmail.com>
	<48B56C89.2060409@vdesmedt.com>
Message-ID: <db6b5ecc0808271153y13efd7bch4a84cd6db6238a15@mail.gmail.com>

On Wed, Aug 27, 2008 at 8:02 AM, Vivian De Smedt <vivian at vdesmedt.com> wrote:
> Hi Fernando,
>>
>> Could you please add a
>> top-level docstring describing the intended purpose of the tool, its
>> main use cases, and a simple example of how to use it?  There should
>> be also a short paragraph about it in the
>> docs/source/interactive/extension_api.txt file, so that users who read
>> the manual can find out about it.
>>
>
> Of course. I'm in Iran right now and I have a poor internet access. But as
> soon I come back I'll commit my change in the doc strings and let you know.

Totally understood, no problem.  Just push up to your branch as usual,
we'll review it and iterate.

Have a great trip!

Regards,

f


From ondrej at certik.cz  Wed Aug 27 20:17:16 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 28 Aug 2008 02:17:16 +0200
Subject: [IPython-dev] branch management getting better...
In-Reply-To: <db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
References: <db6b5ecc0808162020m21523212kea2b37857d8587f4@mail.gmail.com>
	<9457e7c80808170057g79db66dcr5e3346521e78db6a@mail.gmail.com>
	<db6b5ecc0808170059q6c0bb8a7h664f943ddb0779a9@mail.gmail.com>
	<9457e7c80808170941q4f438843vcbb8ff9a65904a54@mail.gmail.com>
	<db6b5ecc0808171254m2e1ad0bsd12ca6e57c021be@mail.gmail.com>
Message-ID: <85b5c3130808271717j3cf63905x5abdd484d91f9b71@mail.gmail.com>

On Sun, Aug 17, 2008 at 9:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hey,
>
> On Sun, Aug 17, 2008 at 9:41 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
>> 2008/8/17 Fernando Perez <fperez.net at gmail.com>:
>>> On Sun, Aug 17, 2008 at 12:57 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
>>>> 2008/8/16 Fernando Perez <fperez.net at gmail.com>:
>>>>> much more cleanly.  For example, if you go to:
>>>>>
>>>>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes
>>>>
>>>> I can't open this page -- am I doing something stupid?
>>>
>>> Sorry, as I just changed the team name, the url moved (after I'd
>>> written my original email):
>>>
>>> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes
>>
>> So, the number to click on is now 1102 (not 1101).  Did this change
>> since you wrote the mail?  I'm just wondering whether the graph is
>> ever re-labeled.
>
> It shouldn't, but this time it did: in all the storm of doing many
> things yesterday, I did a pull instead of a merge, which caused again
> the dreaded revision dropping, so the numbers changed.  This is
> precisely what I was trying to avoid, so it's a bit embarrassing, I
> was just doing too many things and tripped.
>
>
> If you see now, for example this revision:
>
> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1103
>
> got committed (by me) with Gael as author, since I was merging a set
> of patches by him.  In a local log you can see the distinction between
> committer and author for this one, which is useful: I was committing
> work that was 100% Gael's, so this lets us track exactly who did what.
>  This message (we've referred to it before) has a nice summary of the
> workflow I think we're settling into:
>
> https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html
>
> and I now find that I really am starting to agree with the various
> reasons he explains there, in particular:
>
> """
> So why the distinction between a mainline and a merge commit. We have a
> few use cases for them...
>
> 1) "These are the patches reviewed by me". I don't review every single
> change someone makes. But I *do* review the merge before I commit it.
>
> 2) "Every commit on the mainline passes the test suite". This is a
> pretty big one for our bzr.dev process.
>
> 3) "Summary of changes". It gives an obvious place to summarize the many
> (potentially hundreds or more) commits someone made. You frequently want
> to keep all of those hundreds of revisions around, because it gives you
> nice, fine grained details about things that have changed. (Useful for
> annotate, or any sort of digging that needs to be done).
>
> But having a single summary revision, also lets the people who *don't*
> want to wade through 100 revisions to understand "Implemented bound
> branches".
> """
>
> I'm also starting to use the same approach even when summarizing *my
> own* commits: I work on my branch (which is publicly mirrored) and do
> lots of small, frequent commits.  Then I merge from it into my local
> mirror and push that upstream, with a single summary message.  As we
> evolve towards more organized code review, this will be useful.  Once
> a set of changes have been reviewed from the developer's branch, they
> get merged as a single set into the mainline.  The only direct work
> into trunk should be the little tweaks that need to be made at release
> time to the version numbering files and such.

I have couple more questions to the workflow:

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

Because you said you merge those 30 little commits into one or a few
commits, so people who pulled your branch will have mess in their
repos, right?

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

Ondrej

From laurent.dufrechou at gmail.com  Sat Aug 30 12:44:10 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sat, 30 Aug 2008 18:44:10 +0200
Subject: [IPython-dev] Ipython1 sync frontend crash
Message-ID: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>

Hi Gael,

 

Just integrated your IPythonX widget insde wxIpython, now you can have my
shell based on ipython0 and shell side by side by just pulling the notetab.

I will use it to make a class based on wxfrontend to try to have same
behavior as my previous widget.

 

So here some questions:

-          How can I be able to be in sync with your branch with bzr. Is
there any danger?

-          If I want to change your class to look/behave like my ipython0
widget, I think I should copy IPythonXController and then modify it to match
my needs.

Is it the good way to do? Or do you prefer I hack directly inside
IPythonXController?

 

Ho I've also just seen a little bug :

IN[1]: __IP.

 

Then press tab makes a string index out of range. Should be easy to solve.

I think you should allow else iPython completion or Scintilla one not
both.(Perhaps this bug come from there?) (On vista, I've got the two
completion at the same time)

 

Perhaps it is ever solved because I'm out of sync ^_-

 

By the way, release_output() works well, the two shells don't interact
eachother.

 

Cheers,

Laurent

 

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

From gael.varoquaux at normalesup.org  Sat Aug 30 16:35:49 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 30 Aug 2008 22:35:49 +0200
Subject: [IPython-dev] Ipython1 sync frontend crash
In-Reply-To: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>
References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>
Message-ID: <20080830203549.GE6913@phare.normalesup.org>

On Sat, Aug 30, 2008 at 06:44:10PM +0200, Laurent Dufrechou wrote:
>    -          How can I be able to be in sync with your branch with bzr. Is
>    there any danger?

There is danger of me introducing bugs in the frontend, and you finding
them :). This would however be useful to QA the frontend.
The way you can do it, is simply keep pulling (or merging) from my
branch into your branch. Bzr makes this really easy.

>    -          If I want to change your class to look/behave like my ipython0
>    widget, I think I should copy IPythonXController and then modify it to
>    match my needs.

Hum, I think you shouldn't. I think you should sub-class it. As a general
rule, having to copy something is the sign of bad software design. If you
find yourself having to copy, I would be happy if you tell me, as this
might be the sign of a design mistake on my side.

>    Is it the good way to do? Or do you prefer I hack directly inside
>    IPythonXController?

No. However, I am open to suggestions if you find design fault in the
frontend. I will not add code taylored to specific needs, subclasses are
ment for this, but we may find that the way things that are impossible to
do by subclassing, and this may reveal design faults.

>    Ho I've also just seen a little bug :

>    IN[1]: __IP.



>    Then press tab makes a string index out of range. Should be easy to solve.

Yes. Thank you. I have fixed that.

>    I think you should allow else iPython completion or Scintilla one not
>    both.(Perhaps this bug come from there?) (On vista, I've got the two
>    completion at the same time)

IMHO, this is a feature. Well, not exactly: the fact that the drop-down
menu still pops up after pressing tab is not great, but it is the only
way I have found yet to keep the drop-down menu up. That drop down menu
is really nice, I love it, and I still want it. It should just disappear
when the tab key is pressed, and come back when needed. The problem is
finding the right heuristic for "when needed". I agree that this still
could use some more work.

Ga?l


From laurent.dufrechou at gmail.com  Sat Aug 30 16:46:28 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sat, 30 Aug 2008 22:46:28 +0200
Subject: [IPython-dev] Any user of ipython -wthread over there?
Message-ID: <48b9b1b3.095c5e0a.79ba.ffffeb9c@mx.google.com>

Hi everybody,

 

Does anybody using ipython -wthread to play with wx inside ipython tells me
his use case and send me typical session, playing with wx objects?

How do you use it, and why?

 

I'm trying to get the same behavior in a graphical frontend (not console
based), so any usecase will be very very helpful!

 

Cheers,

Laurent

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

From laurent.dufrechou at gmail.com  Sat Aug 30 17:02:35 2008
From: laurent.dufrechou at gmail.com (Laurent Dufrechou)
Date: Sat, 30 Aug 2008 23:02:35 +0200
Subject: [IPython-dev] Ipython1 sync frontend crash
In-Reply-To: <20080830203549.GE6913@phare.normalesup.org>
References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>
	<20080830203549.GE6913@phare.normalesup.org>
Message-ID: <7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com>

Ok will go with subclassing, but was thinking (and still ;) )that I
add to start subclassing from WxController, because all functions in
IPythonXController are specific to your app...
I will give you feedback when ready.
One day will have to share our skype nick ;)


From laurent.dufrechou at gmail.com  Sat Aug 30 17:19:35 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sat, 30 Aug 2008 23:19:35 +0200
Subject: [IPython-dev] Ipython1 sync frontend crash
In-Reply-To: <20080830203549.GE6913@phare.normalesup.org>
References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>
	<20080830203549.GE6913@phare.normalesup.org>
Message-ID: <48b9b976.0405560a.6570.2584@mx.google.com>

Ok I've merged your branch, but a stupid question remain...
I need then to commit.
But will fernando manage easily the fact that my branch is a merge of my
work and your work?
Does bzr handle that for us? 

Sorry bzr newbie :) ...




From laurent.dufrechou at gmail.com  Sat Aug 30 17:47:10 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sat, 30 Aug 2008 23:47:10 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
Message-ID: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>

Hi gael,

 

import os

import locale

        

def system_call(self, command_string):

        ########## dirty quick hack J specific for windows patform
#############

        sp = command_string.split(' ')

        if sp[0] == 'ls':

            sp[0]='dir'

            command_string = ''.join([word+' ' for word in sp])

        ##############################################

        

        stdin, stdout = os.popen4(command_string)

        result =
stdout.read().decode('cp437').encode(locale.getpreferredencoding())

        #"\x01\x1b[1;36m\x02" <-- add colour to the text...

        self.buffered_write("\x01\x1b[1;36m\x02"+result)

        self._buffer_flush(event=None)

        stdout.close()

        stdin.close()

 

Seems to work better here under vista.(works on linux et osx) This is the
code I use in my frontend.

The code inside ############# is a quick workaround on top of my original
code because seems ipython0 handled the things for me J

So need more work bt seems to work faster and avoid the sleep(.1)

 

Willing to use it?

 

Laurent

 

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

From gael.varoquaux at normalesup.org  Sat Aug 30 19:15:47 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 31 Aug 2008 01:15:47 +0200
Subject: [IPython-dev] Ipython1 sync frontend crash
In-Reply-To: <7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com>
References: <48b978e9.0305560a.4049.ffffe90f@mx.google.com>
	<20080830203549.GE6913@phare.normalesup.org>
	<7ced318f0808301402t66620da4v76a7e909206fa4bd@mail.gmail.com>
Message-ID: <20080830231547.GA32682@phare.normalesup.org>

On Sat, Aug 30, 2008 at 11:02:35PM +0200, Laurent Dufrechou wrote:
> Ok will go with subclassing, but was thinking (and still ;) )that I
> add to start subclassing from WxController, because all functions in
> IPythonXController are specific to your app...

Sure, if you think so, your are probably right. My way of doing software
is to move forward, and maybe not get the best design from the start, but
I try to keep vigilent about my code, and refactor it as soon as I think
I am doing something wrong.

> I will give you feedback when ready. One day will have to share our
> skype nick ;)

gael.varoquaux :). I am in the US right now (actually staying at
Fernando's place), so I am a bit out of sync with you.

Ga?l


From gael.varoquaux at normalesup.org  Sat Aug 30 19:24:36 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 31 Aug 2008 01:24:36 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
Message-ID: <20080830232435.GC32682@phare.normalesup.org>

On Sat, Aug 30, 2008 at 11:47:10PM +0200, Laurent Dufrechou wrote:
>    Seems to work better here under vista.(works on linux et osx) This is the
>    code I use in my frontend.

Hum, how do you deal with IO with the child process? Can you do:

!cat

and have a behavior more or less consistent with the behavior you would
have in a normal terminal? What happens if you do (under linux, as I
don't know the syntax for rm under windows):

In [1]: !touch foobar

In [2]: !rm -i foobar
rm: remove regular empty file `foobar'? y

In [3]: 

This is one the difficulties I have addressed in my frontend, and it is
not trivial.

Ga?l


From laurent.dufrechou at gmail.com  Sat Aug 30 20:07:09 2008
From: laurent.dufrechou at gmail.com (=?us-ascii?Q?Laurent_Dufrechou?=)
Date: Sun, 31 Aug 2008 02:07:09 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <20080830232435.GC32682@phare.normalesup.org>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
Message-ID: <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>

Good point ;)

!del /P myfile.txt don't works at all with my code.
So here is a bug report for you (just to keep a trace) ;) :

In [2]: !ls

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

Traceback (most recent call last):
  File
"c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\kernel\core\sync_
traceback_trap.py", line 49, in hook
    raise
TypeError: exceptions must be classes, instances, or strings (deprecated),
not NoneType

Original exception was:
Traceback (most recent call last):
  File
"C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\ipyth
onx.py", line 42, in _on_key_down
    WxController._on_key_down(self, event, skip=skip) 
  File
"C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr
ontend.py", line 368, in _on_key_down
    ConsoleWidget._on_key_down(self, event, skip=skip)
  File
"c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\frontend\wx\conso
le_widget.py", line 361, in _on_key_down
    self._on_enter()
  File
"C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr
ontend.py", line 440, in _on_enter
    PrefilterFrontEnd._on_enter(self)
  File
"c:\users\ldufrechou\desktop\ipython-dev\trunk-dev\IPython\frontend\linefron
tendbase.py", line 274, in _on_enter
    self.execute(cleaned_buffer, raw_string=current_buffer)
  File
"C:\Users\ldufrechou\Desktop\Ipython-dev\trunk-dev\IPython\frontend\wx\wx_fr
ontend.py", line 288, in execute
    wx.Yield()
  File "C:\Python25\Lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line
7630, in Yield
    return _core_.Yield(*args)
wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed at
..\..\src\msw\app.cpp(695) in wxApp::Yield(): wxYield called recursively

Laurent



From gael.varoquaux at normalesup.org  Sat Aug 30 20:13:14 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 31 Aug 2008 02:13:14 +0200
Subject: [IPython-dev] shell command for ipython1 frontend
In-Reply-To: <48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
References: <48b9bfed.05a0660a.3309.ffff87f0@mx.google.com>
	<20080830232435.GC32682@phare.normalesup.org>
	<48b9e0be.11435e0a.1bbc.ffffe16a@mx.google.com>
Message-ID: <20080831001314.GF32682@phare.normalesup.org>

On Sun, Aug 31, 2008 at 02:07:09AM +0200, Laurent Dufrechou wrote:
> !del /P myfile.txt don't works at all with my code.
> So here is a bug report for you (just to keep a trace) ;) :

Yeah, I have been out of office for two weeks, so I can't test my code
under windows (I have a windows VM at the office, but not on my laptop).
This issue you have found is most probably trivial to fix (it is due to
slightly different event loop behavior under windows and under the other
platforms), but I need windows to develop. I'll fix it next week.

Thanks for reporting though.

Ga?l


From laurent.dufrechou at gmail.com  Sat Aug 30 20:40:52 2008
From: laurent.dufrechou at gmail.com (=?iso-8859-1?Q?Laurent_Dufr=E9chou?=)
Date: Sun, 31 Aug 2008 02:40:52 +0200
Subject: [IPython-dev] Last mail for the night
Message-ID: <48b9e8a4.0437560a.4fc9.2334@mx.google.com>

Ok,

It?s late, i?m bumping my head on the wall here


I?m desperately trying to change the default colors of your widget.

Seems you?ve done the things cleaner than me J

So If I well understood there is two method to change colors
:

Modify self.ANSI_STYLE and/or modify self.style, then call
self._apply_style()

 

What I want is black background and white text a la mode ipython console.

I?ve found no way to get it :/

 

I?ve also tried to modify prompt (I like a lot the green /red original
ones
)

I?ve trie with no success, If you could also help me


self.prompt_in1 = 'In $number:' ? just to try

self.prompt_out = 'Out $number:'

self.output_prompt_template = string.Template(self.prompt_out)

self.input_prompt_template = string.Template(self.prompt_in1)

don?t work, the prompt don?t change


 

>From what I?ve seen from now, I?m quite happy with it, It looks like my old
code with the rounded corner, like self.style (good point there) and the
promp_template, I like a lot! (If I could modify them!)

Subclassing WXController seems ok for now. You just don?t handle by default
fonts, but seems easy to add in my class.

 

if wx.Platform == '__WXMSW__':

            self.faces = { 'times': 'Times New Roman',

                      'mono' : 'Courier New',

                      'helv' : 'Arial',

                      'other': 'Comic Sans MS',

                      'size' : 10,

                      'size2': 8,

                     }

        elif wx.Platform == '__WXMAC__':

            self.faces = { 'times': 'Times New Roman',

                      'mono' : 'Monaco',

                      'helv' : 'Arial',

                      'other': 'Comic Sans MS',

                      'size' : 10,

                      'size2': 8,

                     }

        else:

            self.faces = { 'times': 'Times',

                      'mono' : 'Courier',

                      'helv' : 'Helvetica',

                      'other': 'new century schoolbook',

                      'size' : 10,

                      'size2': 8,

                     }

 

If I can play with self.style.

 

Cheers,

Laurent

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

From gael.varoquaux at normalesup.org  Sat Aug 30 21:04:39 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 31 Aug 2008 03:04:39 +0200
Subject: [IPython-dev] Last mail for the night
In-Reply-To: <48b9e8a4.0437560a.4fc9.2334@mx.google.com>
References: <48b9e8a4.0437560a.4fc9.2334@mx.google.com>
Message-ID: <20080831010439.GJ32682@phare.normalesup.org>

On Sun, Aug 31, 2008 at 02:40:52AM +0200, Laurent Dufr?chou wrote:
>    So If I well understood there is two method to change colors...:

>    Modify self.ANSI_STYLE and/or modify self.style, then call
>    self._apply_style()


Actually, to do this, you need to call "_configure_scintilla". Tell me if
you can't get this working.

This code could be cleaner. If you want to have a go a making a patch to
improve this, I would be happy to accept it, as long as you try to keep
the code quality high.


>    I've also tried to modify prompt (I like a lot the green /red original
>    ones...)

>    I've trie with no success, If you could also help me...

>    self.prompt_in1 = 'In $number:' ? just to try

>    self.prompt_out = 'Out $number:'

>    self.output_prompt_template = string.Template(self.prompt_out)

>    self.input_prompt_template = string.Template(self.prompt_in1)

>    don't work, the prompt don't change...

This won't change the existing prompts, but it should new one. I suspect
your are not setting these variables at the right time. You need to do
this before you call the parent class __init__ as this call print the
first prompt. I think this stinks a bit, but this is a direct consequence
of having the frontend also being a widget. I think more and more the
frontend should be a subobject of the widget, rather than a parent in the
class hierarchy of the widget. I want to discuss this with Barry,
however, as I know he has spent some time thinking about this.

>    From what I've seen from now, I'm quite happy with it, It looks like my
>    old code with the rounded corner,

I didn't code this out of the blue. I spent a while studying your code,
as well as other python graphical shells.

>    Subclassing WXController seems ok for now. You just don't handle by
>    default fonts, but seems easy to add in my class.

Great. I am excited about this new devlopment. I really had this kind of
usecases in mind for the frontend.

A piece of warning, thought, there are still some things that will change
with the frontend. Not only is there too much coupling between the model
and the view (I still haven't identified well what the model is), but
also the code is sometimes too much line-oriented for not good reason,
and should be abstracted for a more general block-oriented approach, with
the line-oriented being a special case (I know Barry is interested in
block-oriented, and I am very much looking forward to working with him on
this issue).

Ga?l