From danmil at comcast.net  Thu Mar  1 21:08:00 2007
From: danmil at comcast.net (Dan Milstein)
Date: Thu, 1 Mar 2007 21:08:00 -0500
Subject: [IPython-dev] Recent iplib line_split changes
Message-ID: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>

Yo,

I just pulled down the newest code from svn (written today/ 
yesterday), and my new tests for prefilter promptly blew up.  I'll  
take that as good news (in the, "look, something changed in the  
behavior and the tests complained" department).

Specifically, in changing from rev 2120 to rev 2124, the following  
things now work differently (which should not work differently, I  
think):

  1) Automagic is masking attempts to run valid python

Before, with %automagic on, lines which looked like, say:

 >>> colors = "red green"

Would see the '=' and thus not run the %colors magic command.  As of  
2124, that's broken -- it interprets it as %colors = "red green".    
Ditto for '!<>(),'.


  2) Similarly, ofind() is getting called near !=() when it shouldn't  
be.

E.g.

 >>> obj.prop = 'thing'

Is calling ofind to lookup prop (with the possible state changes as a  
result).  It wasn't in 2120.


  3) Autocalling is triggered when it can't be syntactically valid

There's a whole set of binary ops which prevent autocalling from  
happening, which are now broken.  E.g.

 >>> len in lst

Is getting transformed to len(in lst), and then bombing.  This was  
getting caught earlier.


I'm pretty sure that these (and other exciting bugs) have to do with  
confusion in the code as to what goes in pre and what goes in iFun as  
a result of the split.  I have ideas on how to clean this up, now  
that the tests seem to be working.

-Dan




From danmil at comcast.net  Thu Mar  1 21:18:00 2007
From: danmil at comcast.net (Dan Milstein)
Date: Thu, 1 Mar 2007 21:18:00 -0500
Subject: [IPython-dev] What was fixed in iplib?
Message-ID: <D3CAF30D-BF7C-49D1-A6B2-9EE9DCBB2A6E@comcast.net>

Also, while I'm asking: what was the bug which was fixed by the code  
change in iplib?  I'd like to add it to the tests.  The ChangeLog  
says something about spurious attribute lookups.  What's an example  
case?

-Dan


From fperez.net at gmail.com  Thu Mar  1 21:26:26 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 1 Mar 2007 19:26:26 -0700
Subject: [IPython-dev] What was fixed in iplib?
In-Reply-To: <D3CAF30D-BF7C-49D1-A6B2-9EE9DCBB2A6E@comcast.net>
References: <D3CAF30D-BF7C-49D1-A6B2-9EE9DCBB2A6E@comcast.net>
Message-ID: <db6b5ecc0703011826s7931fd5p7eb0e46f7cf70b29@mail.gmail.com>

On 3/1/07, Dan Milstein <danmil at comcast.net> wrote:
> Also, while I'm asking: what was the bug which was fixed by the code
> change in iplib?  I'd like to add it to the tests.  The ChangeLog
> says something about spurious attribute lookups.  What's an example
> case?

The bug had been reported by Alex Schmolck:

http://lists.ipython.scipy.org/pipermail/ipython-user/2007-February/004105.html

Cheers,

f


From fperez.net at gmail.com  Thu Mar  1 21:30:09 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 1 Mar 2007 19:30:09 -0700
Subject: [IPython-dev] Recent iplib line_split changes
In-Reply-To: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>
References: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>
Message-ID: <db6b5ecc0703011830m13ca7394g930eea92fbb451f5@mail.gmail.com>

Hey Dan,

On 3/1/07, Dan Milstein <danmil at comcast.net> wrote:
> Yo,
>
> I just pulled down the newest code from svn (written today/
> yesterday), and my new tests for prefilter promptly blew up.  I'll
> take that as good news (in the, "look, something changed in the
> behavior and the tests complained" department).

Well, it seems you arrived not a second too late :)

I have to run now, but I'll look into this later if I can.

I think I'm simply going to revert the patches made for Alex's bug for
now, until I can redo that more carefully using your tests.

The filtering code is a *^&*@! minefield, and walking over it
blindfolded (ie without unit tests) led to the only result that could
have been expected...

Unfortunately I have a couple of crazy days ahead so it may not be
until Sunday that I can get back to Alex's bug and fix it properly.

In the meantime, many thanks for catching all of this!  I'll
incorporate your tests into the trunk as soon as I have a free minute.

Cheers,

f


From fperez.net at gmail.com  Fri Mar  2 01:54:01 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 1 Mar 2007 23:54:01 -0700
Subject: [IPython-dev] Recent iplib line_split changes
In-Reply-To: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>
References: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>
Message-ID: <db6b5ecc0703012254t6b022a42wc433b4156e25ed51@mail.gmail.com>

Hi Dan,

On 3/1/07, Dan Milstein <danmil at comcast.net> wrote:
> Yo,
>
> I just pulled down the newest code from svn (written today/
> yesterday), and my new tests for prefilter promptly blew up.  I'll
> take that as good news (in the, "look, something changed in the
> behavior and the tests complained" department).

I just added your test suite into ipython/test/, thanks again!  And I
deactivated yesterday's changes so that at least we don't have this
broken code out there.  Alex, sorry but that means /your/ problem is
back.

I'm too tired right now to look at this in detail, and for the next
3-4 days I won't have a spare moment for this, unfortunately.  But
next week I'll revisit the problem and try to fix Alex's issue without
introducing any other breakage.  With Dan's test suite, there's
actually hope of that happening :)

Regards, and sorry for the mess :)

f


From danmil at comcast.net  Fri Mar  2 08:56:13 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 2 Mar 2007 08:56:13 -0500
Subject: [IPython-dev] Recent iplib line_split changes
In-Reply-To: <db6b5ecc0703012254t6b022a42wc433b4156e25ed51@mail.gmail.com>
References: <DE9D1950-203F-4A70-B61C-734D31549062@comcast.net>
	<db6b5ecc0703012254t6b022a42wc433b4156e25ed51@mail.gmail.com>
Message-ID: <B1AD2271-8C3E-4BEC-B7C7-ABABBF99533F@comcast.net>

I may have a chance to take a crack at this between in the next few  
days.  I think I understand the prefilter code pretty well at this  
point (or, at least, as well as can be hoped ;-).

Alex: you may already know this (I'm coming late to this discussion),  
but in case not -- if you turn off autocall  (%autocall 0), then it  
doesn't do the bad attribute lookup.  Continuing your example:

In [9]: %autocall 0
Automatic calling is: OFF

In [10]: f.bar()
getattr:  bar
Out[10]: 'nada'

In [11]: f.this('is bad')
getattr:  this
Out[11]: 'nada'

It *should* do the right thing, even with autocalling on (since the  
parens after bar make it clear that autocalling isn't going to get  
triggered), but I just wanted to pass that on as a temp workaround.

-Dan


On Mar 2, 2007, at 1:54 AM, Fernando Perez wrote:

> Hi Dan,
>
> On 3/1/07, Dan Milstein <danmil at comcast.net> wrote:
>> Yo,
>>
>> I just pulled down the newest code from svn (written today/
>> yesterday), and my new tests for prefilter promptly blew up.  I'll
>> take that as good news (in the, "look, something changed in the
>> behavior and the tests complained" department).
>
> I just added your test suite into ipython/test/, thanks again!  And I
> deactivated yesterday's changes so that at least we don't have this
> broken code out there.  Alex, sorry but that means /your/ problem is
> back.
>
> I'm too tired right now to look at this in detail, and for the next
> 3-4 days I won't have a spare moment for this, unfortunately.  But
> next week I'll revisit the problem and try to fix Alex's issue without
> introducing any other breakage.  With Dan's test suite, there's
> actually hope of that happening :)
>
> Regards, and sorry for the mess :)
>
> f



From danmil at comcast.net  Fri Mar  2 09:39:05 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 2 Mar 2007 09:39:05 -0500
Subject: [IPython-dev] iplib fix (#1)
Message-ID: <F7BA7C83-25D9-45A8-8562-947BBE55B23D@comcast.net>

Fernando (/Alex),

Attached is a patch to the most recent version of iplib which fixes  
the problem reported.  Let's call it fix #1 because it doesn't  
represent the full overhaul of prefilter which is oh-so-close ;-).

Also attached is a patch to test_prefilter.py so that it captures  
this problem (thanks to Alex's detailed report).

The change is just in the first part of the line_split regex, from:

     self.line_split = re.compile(r'^([\s*,;/])'

To:

     self.line_split = re.compile(r'^(\s*[,;/]?\s*)'

The \s* doesn't work inside the [] (special chars are turned off, so  
that matches a '*' or a single whitespace), so the match was failing  
when it shouldn't, and falling back on whitespace splitting.  Now  
that first part can match whitespace optionally mixed with a single  
autocall esc char.

This, um, fixed the problem, though I wouldn't swear as to *how* (see  
note about full rewrite above).

-Dan



-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_prefilter.py.patch
Type: application/octet-stream
Size: 562 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070302/4eee0bff/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iplib.py.patch
Type: application/octet-stream
Size: 1068 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070302/4eee0bff/attachment-0001.obj>

From walter at livinglogic.de  Fri Mar  2 10:50:00 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 02 Mar 2007 16:50:00 +0100
Subject: [IPython-dev] igrid
Message-ID: <45E847A8.2070006@livinglogic.de>

I've checked in igrid, the wxPython-based ipipe browser done by Nik
Tautenhahn.

We've tested igrid on Linux with wx 2.6 and wx 2.8 and on Windows with
wx 2.7 and 2.8. igrid will be used as the default browser if wx is
installed on the system, so testing it should be rather simple:

In [1]: from ipipe import *
In [2]: ils

This should give a directory listing in a wx window.

(A short description of the basic ipipe functionality is available at
http://ipython.scipy.org/moin/UsingIPipe)

I guess scrolling speed still requires a little work, and igrid
currently doesn't have all the commands that ibrowse has, but it should
be enough to test the functionality.

Help is available as an HTML file, but the setup script has to be
updated so that the HTML and the CSS file gets installed.

Please give this a try. Comments and suggestions are welcome.

Servus,
   Walter


From clarkdbassett at hotmail.com  Fri Mar  2 14:19:33 2007
From: clarkdbassett at hotmail.com (Clark Bassett)
Date: Fri, 2 Mar 2007 13:19:33 -0600
Subject: [IPython-dev] unsuscribe
References: <mailman.9.1172858404.28084.ipython-dev@scipy.org>
Message-ID: <BAY131-DAV1715D9C1DAB1066F6568A0BA870@phx.gbl>




From jorgen.stenarson at bostream.nu  Mon Mar  5 13:59:17 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 05 Mar 2007 19:59:17 +0100
Subject: [IPython-dev] bug in ipy_default.py
Message-ID: <45EC6885.2030502@bostream.nu>

There is code in ipy_defaults.py that try to use readline functions 
without testing if readline is available.

The attached patch adds such a test.

/J?rgen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 1489 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070305/ea68ebd2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipy_defaults.diff
Type: application/octet-stream
Size: 416 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070305/ea68ebd2/attachment.obj>

From fperez.net at gmail.com  Mon Mar  5 14:36:22 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 5 Mar 2007 12:36:22 -0700
Subject: [IPython-dev] bug in ipy_default.py
In-Reply-To: <45EC6885.2030502@bostream.nu>
References: <45EC6885.2030502@bostream.nu>
Message-ID: <db6b5ecc0703051136j2ffb07b2o93afbd4887925d2b@mail.gmail.com>

On 3/5/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> There is code in ipy_defaults.py that try to use readline functions
> without testing if readline is available.
>
> The attached patch adds such a test.

Feel free to commit, the patch looks clean to me and is OK under *nix.

Cheers,

f


From ellisonbg.net at gmail.com  Tue Mar  6 12:00:26 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 6 Mar 2007 10:00:26 -0700
Subject: [IPython-dev] IPython PyCon talks/movies are on the IPython site
Message-ID: <6ce0ac130703060900i31c4c18ao20aae9b900d417a8@mail.gmail.com>

Hi,

We have had lots of requests for the slides+movies that I presented
about IPython at PyCon 2007.  There are now posted on the ipython web
site:

http://ipython.scipy.org/moin/About/Presentations

Enjoy!

Brian Granger


From ellisonbg.net at gmail.com  Tue Mar  6 12:35:04 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 6 Mar 2007 10:35:04 -0700
Subject: [IPython-dev] Refactoring prefilter and ipython1
Message-ID: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>

Hi,

Dan has been looking at refactoring prefilter lately - this began with
a very nice test suite for the existing one.  I have a question about
this.

Should Dan's target be to rework the prefilter that is in trunk?  Or
should he focus on implementing something from scratch that may have a
completely different architecture (than prefilter).  This approach
would be more focused on moving the prefilter capabilities from trunk
over to ipython1.  This second approach would allow us to start anew
and really think about how ipython does input parsing.  For instance,
it may make sense to build something that doesn't even have a
"prefilter" method that resembles the current one.

The current class (that prefilter is a part of) began as a subclass of
code.InteractiveConsole.  But as we move forward with ipython1, there
is no reason to hold to that tradition.  In fact, it may make more
sense to move away from that - especially as the old version is
inextricably tied to the terminal - a constraint which ipython1
cant'/won't have.  Also, the configuration system that ipython1 uses
is completely different that the hooks that are in trunk.

I can see advantages of both options here.  What do people think?

Cheers,

Brian


From fperez.net at gmail.com  Tue Mar  6 13:34:06 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 6 Mar 2007 11:34:06 -0700
Subject: [IPython-dev] Refactoring prefilter and ipython1
In-Reply-To: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>
References: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>
Message-ID: <db6b5ecc0703061034u634a2746s4ab37f40dd171b8f@mail.gmail.com>

On 3/6/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> Dan has been looking at refactoring prefilter lately - this began with
> a very nice test suite for the existing one.  I have a question about
> this.
>
> Should Dan's target be to rework the prefilter that is in trunk?  Or
> should he focus on implementing something from scratch that may have a
> completely different architecture (than prefilter).  This approach
> would be more focused on moving the prefilter capabilities from trunk
> over to ipython1.  This second approach would allow us to start anew
> and really think about how ipython does input parsing.  For instance,
> it may make sense to build something that doesn't even have a
> "prefilter" method that resembles the current one.
>
> The current class (that prefilter is a part of) began as a subclass of
> code.InteractiveConsole.  But as we move forward with ipython1, there
> is no reason to hold to that tradition.  In fact, it may make more
> sense to move away from that - especially as the old version is
> inextricably tied to the terminal - a constraint which ipython1
> cant'/won't have.  Also, the configuration system that ipython1 uses
> is completely different that the hooks that are in trunk.
>
> I can see advantages of both options here.  What do people think?

Sorry I've been a bit quiet for the past few days, a combination of
super-busy and a cold hasn't helped.

Here's how I see things currently: we have a bunch of accumulated
things in the pipeline for trunk, patches people have sent, small bug
reports, etc.  I created a 0.7.4 milestone, tentatively setting the
date to April 1:

http://projects.scipy.org/ipython/ipython/milestone/0.7.4


It would be great if the trunk guys could help us flush everything
they can on that front; I'll be doing my part as well with any patches
I can take care of myself.

Ville, if that date doesn't work for you, go ahead and edit the
milestone and reset it.

For this to happen, I'd encourage everyone who has something pending
that might fall through the cracks to make a ticket for it, and assign
it to this milestone.  It's the only way for us to ensure we won't
forget.

If we can release 0.7.4 early April, I would then make that release
the code that will become the core component in ipython1.  I (probably
will) have a course to teach using Python in mid-April, so I'd like to
have a stable release for that workshop, and after finishing I hope to
be able to make a quick transition.  At this point I'd make an effort
to make the transition as fast as possible, because code living in
limbo is /very bad/ for a project: people stall out, feel there's no
place to contribute, and lose interest.  I'm aware of that danger.

So my plan is not necessarily to make a grand, super-complicated
reorganization of the code right off the bat.  I simply would like to
move the current trunk code into ipython1, break up the bigger messes
into little more digestible ones (ipmaker, ipythonrc handling, Magic,
etc) and abstract out all console i/o assumptions.  That would give us
a codebase which would be very similar to the current one, but with
the key problems broken up into smaller chunks that hopefully can then
be tackled one at a time.

We have an ipython sprint planned in Boulder for April, and that
sprint would be a great opportunity to move ahead with this
reorganization.

To address Dan's questions about prefilter more specifically: my
biggest worry is not to stall a potential contributor.  It's a bit
late, I think, for a radical reorganization a few weeks before a
release.  But if you can keep that work in a private copy for a while
and move ahead, that would be great.  We can then try to merge the lot
in a few weeks.  If this proves to be a big hassle, we can look into
exposing SVN as a mercurial repo so any developer can have his own
tree.  I've thought about this before, it's just that I don't want to
add more process-related work at this point, else we won't get any
actual work done.

How does that sound for everyone?

Cheers,

f


From vivainio at gmail.com  Wed Mar  7 06:52:36 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 7 Mar 2007 12:52:36 +0100
Subject: [IPython-dev] Refactoring prefilter and ipython1
In-Reply-To: <db6b5ecc0703061034u634a2746s4ab37f40dd171b8f@mail.gmail.com>
References: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>
	<db6b5ecc0703061034u634a2746s4ab37f40dd171b8f@mail.gmail.com>
Message-ID: <46cb515a0703070352le9fe016oce2099c78f330822@mail.gmail.com>

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

> Sorry I've been a bit quiet for the past few days, a combination of
> super-busy and a cold hasn't helped.

I have the same situation - busy, nasty long flu, travelling around,
moving around...

> It would be great if the trunk guys could help us flush everything
> they can on that front; I'll be doing my part as well with any patches
> I can take care of myself.

I'll try to get up to speed asap.

> For this to happen, I'd encourage everyone who has something pending
> that might fall through the cracks to make a ticket for it, and assign
> it to this milestone.  It's the only way for us to ensure we won't
> forget.

I agree. It's not obvious what should go in at this point, and how
well it's been tested.

> To address Dan's questions about prefilter more specifically: my
> biggest worry is not to stall a potential contributor.  It's a bit

I don't really see much need to reorganize the prefilter system. It's
terminal-independent, only deals with strings etc.

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


From danmil at comcast.net  Wed Mar  7 10:39:02 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 7 Mar 2007 10:39:02 -0500
Subject: [IPython-dev] Refactoring prefilter and ipython1
In-Reply-To: <46cb515a0703070352le9fe016oce2099c78f330822@mail.gmail.com>
References: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>
	<db6b5ecc0703061034u634a2746s4ab37f40dd171b8f@mail.gmail.com>
	<46cb515a0703070352le9fe016oce2099c78f330822@mail.gmail.com>
Message-ID: <7813ED00-E697-49F5-83E8-7ABE66D21582@comcast.net>

>> To address Dan's questions about prefilter more specifically: my
>> biggest worry is not to stall a potential contributor.  It's a bit
>
> I don't really see much need to reorganize the prefilter system. It's
> terminal-independent, only deals with strings etc.

The rewrite I've got planned is fairly modest (I think).  The main  
goal is just to make it much clearer what triggers a particular  
handler.  It should be no problem to keep it in a private copy for a  
few weeks, and then figure out how to merge it back over.  As Ville  
says, it actually has a fairly simple interface to much of the rest  
of the system -- it just takes a string and returns a string.  So I'm  
optimistic.

As I find time, I'll work on that, and if it gets to a finished  
point, I'll post changes so people can take a look, with the  
understanding that it likely won't be seriously considered until  
after 0.7.4.

Thanks,
-Dan



From ellisonbg.net at gmail.com  Wed Mar  7 11:54:31 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 7 Mar 2007 09:54:31 -0700
Subject: [IPython-dev] Fwd:  Tests for prefilter
In-Reply-To: <6ce0ac130703060927i47f38c3r286ab628daf9f0b0@mail.gmail.com>
References: <855AA20F-C120-4D45-9795-40B732C15FF9@comcast.net>
	<6ce0ac130703060927i47f38c3r286ab628daf9f0b0@mail.gmail.com>
Message-ID: <6ce0ac130703070854hb886fc7hcf8c80144b064e74@mail.gmail.com>

---------- Forwarded message ----------
From: Brian Granger <ellisonbg.net at gmail.com>
Date: Mar 6, 2007 10:27 AM
Subject: Re: [IPython-dev] Tests for prefilter
To: Dan Milstein <danmil at comcast.net>


Dan,

I have gone through your questions about prefilter (see responses
inline below).  I am not the expert here - Fernando and Ville will
have to fill in details.  But, in many cases, my guess is that you are
running up against our lack of tests in the first place.  The miracle
is that this hasn't prevented ipython from being really useful to lots
of people.

One comment that may be a bit controversial.  I do think that moving
forward, we need to get rid of cases in ipython's syntax where there
is ambiguity.  This may (and I think should) mean that certain
features are removed unless we can fully specify their behavior in all
cases and provide full test coverage.  Fernando and Ville, any
comments about this?  My own feeling is that as we refactor prefilter
and friends we should focus on providing a framework that will make it
easy to maintain/extent/test the core features of ipython.

Thoughts?

Brian


> Bugs / Questions
> ================
>
>   1) Even with %autocall off, '/', ',' and ';' should trigger
> autocalls. Does not work. (I asked about this Monday)

>From the docs, it seems like it should work.

>   2) In several places, the prefilter checks for an input line which
> looks like, e.g.:
>
> thing = rhs
>
> And, if it finds it, doesn't try to look up 'thing' as an alias, etc,
> so that a normal python expr won't get shadowed by ipython magic
> bits.  However, in some places, the set of characters which turn off
> the magic bits are: '!=()', and in others, they are '!=()<>'. I
> *think* they should be the same in both places.  See, e.g. line 2121
> v line 2135.  Or, just possibly it should be all python binary ops,
> which is a much bigger list.

Fernando?  Ville?

>   3) Can aliases have '.' in their names?  If so, there's a problem:
> such aliases *do* expand with %autocall off, but they *don't* expand
> when it's on (because of a subtlety of how ._ofind is used or avoided).

I am guessing that we don't have a spec on exactly what can/cannot
appear in alias names.  The same would probably also hold true of
macros.  It would be good to come up with an official spec and write
tests for that.

>   4) More autocall fun -- what should ipython do (with autocall on),
> with the two following (the comments are my understanding of how it's
> supposed to work currently):
>
>  > "abc".join range(4)     # Should *not* autocall and doesn't
>
>  > /"abc".join range(4)    #2 *Should* autocall, but doesn't.

Hmmm.   Fernando, Ville?  Ideas?  What should the behavior be?

> Currently, #1 should *not* autocall the join method, because autocall
> only triggers for things which look like identifiers mixed with '.'.
> Is that, in fact, how the system should work?

> However, #2 also doesn't autocall the join (and it should, I think).
> In fact, it totally blows up -- ipython somehow ends up with a '//'
> at the start of the line and has no idea what to do.  I think I know
> why this is happening.
>
>
>   5) Binary ops and autocall
>
> Autocalling gets turned off for *most* binary operators, so that,
> e.g. 'fun in lst' won't become 'fun(in list)', even if fun is
> callable.   However, it's missing the % operator.  So that, e.g. 'fun
> % s' will become 'fun(%s)'.

Probably, unless there is some wierd reason not.  Fernando and Ville
might be aware of such a reason.


From jorgen.stenarson at bostream.nu  Wed Mar  7 14:26:17 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 07 Mar 2007 20:26:17 +0100
Subject: [IPython-dev] bug in ipy_default.py
In-Reply-To: <db6b5ecc0703061335h263f594cm85edd27d28d9a5f6@mail.gmail.com>
References: <45EC6885.2030502@bostream.nu>	
	<db6b5ecc0703051136j2ffb07b2o93afbd4887925d2b@mail.gmail.com>	
	<45EDDD4D.3070700@bostream.nu>
	<db6b5ecc0703061335h263f594cm85edd27d28d9a5f6@mail.gmail.com>
Message-ID: <45EF11D9.6010602@bostream.nu>

Fernando Perez skrev:
> On 3/6/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
>> Fernando Perez skrev:
> 
>> > Feel free to commit, the patch looks clean to me and is OK under *nix.
>> >
>> > Cheers,
>> >
>> > f
>> >
>> done
> 
> Thanks.  When you get a chance, let us know what you think of the
> release plan, esp. regarding any patches you may either have pending,
> in your head, or that you could write for reported problems (some of
> which are only on-list and have no tickets yet).
> 
> 
> Cheers,
> 
> f
> 

I forgot to reply on list last time.

I think the release plan sounds fine. I would also like to make a 
release of a new pyreadline at the same time. I have a lot of new 
features in the refactor branch that I would like to merge to trunk. But 
there are so many changes to the layout of the code I don't think a 
merge will be possible without a *lot* of conflicts. So I'm thinking I 
should just delete current trunk and copy the refactor branch to trunk. 
Have you thought about how you will do when it's time to switch over to 
the new ipython? If there are no protests I will probably create a 
maintanence branch for 1.3 and do this delete/copy for 1.4 in the next 
couple of days.

I have been experiencing some inconsistencies with tabcompletion of 
filenames recently. I think the new tab-completion hooks work a bit 
different from the normal tab-completion when it comes to escaping 
spaces in filenames. There is also a bug when completing on filenames 
for %run, when the first character is " then you get an exception. I 
could look into this, unless someone else is already looking into it.

/J?rgen





From vivainio at gmail.com  Wed Mar  7 16:00:54 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 7 Mar 2007 22:00:54 +0100
Subject: [IPython-dev] Tests for prefilter
In-Reply-To: <6ce0ac130703070854hb886fc7hcf8c80144b064e74@mail.gmail.com>
References: <855AA20F-C120-4D45-9795-40B732C15FF9@comcast.net>
	<6ce0ac130703060927i47f38c3r286ab628daf9f0b0@mail.gmail.com>
	<6ce0ac130703070854hb886fc7hcf8c80144b064e74@mail.gmail.com>
Message-ID: <46cb515a0703071300s1ac84727o550443fd43390c27@mail.gmail.com>

On 3/7/07, Brian Granger <ellisonbg.net at gmail.com> wrote:

> One comment that may be a bit controversial.  I do think that moving
> forward, we need to get rid of cases in ipython's syntax where there
> is ambiguity.  This may (and I think should) mean that certain
> features are removed unless we can fully specify their behavior in all
> cases and provide full test coverage.  Fernando and Ville, any
> comments about this?  My own feeling is that as we refactor prefilter
> and friends we should focus on providing a framework that will make it
> easy to maintain/extent/test the core features of ipython.

I think the way forward is to remove as much core features as possible
(and push the features into the plugin/extension area), and not stress
too much about it. I don't think even magics should be too prominent
in ipython "core spec", and we shouldn't too much work into removing
features in a quest of consistency.

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


From Glen.Mabey at swri.org  Fri Mar  9 16:11:58 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Fri, 9 Mar 2007 15:11:58 -0600
Subject: [IPython-dev] starting local ipengines works great but not remote
	ipengines
Message-ID: <20070309211158.GA10670@bams.ccf.swri.edu>

Hello,

Having installed ipython1 on two different machines, I am struggling to
get engines on one to connect to a controller on the other.

However, connecting to local controllers works on both machines.  One is
an AMD64 while the other is a P4.

The only deviation that I have made from the build instructions is in
the recommendation to use Zope Interface version 3.1.0c1, which gave 
an error when I tried to build it.  Version 3.3.0 worked with no issues.

Things start out well:

HOST1:~$ ipcontroller --engine-port=10001
2007-03-09 15:06:54-0600 [-] Log opened.
2007-03-09 15:06:54-0600 [-] <class 'ipython1.kernel.enginevanilla.VanillaEngineServerFactoryFromControllerService'> starting on 10001
2007-03-09 15:06:54-0600 [-] Starting factory <ipython1.kernel.enginevanilla.VanillaEngineServerFactoryFromControllerService object at 0xb63d1a2c>
2007-03-09 15:06:54-0600 [-] <class 'ipython1.kernel.controllervanilla.VanillaControllerFactoryFromService'> starting on 10105
2007-03-09 15:06:54-0600 [-] Starting factory <ipython1.kernel.controllervanilla.VanillaControllerFactoryFromService object at 0xb63d1a6c>
2007-03-09 15:06:54-0600 [-] twisted.spread.pb.PBServerFactory starting on 10111
2007-03-09 15:06:54-0600 [-] Starting factory <twisted.spread.pb.PBServerFactory instance at 0xb63d1b6c>


HOST2:~$ ipengine --controller-port=10001 --controller-ip=gwm
2007-03-09 15:07:50-0600 [-] Log opened.
2007-03-09 15:07:50-0600 [-] Starting factory <ipython1.kernel.enginevanilla.VanillaEngineClientFactoryFromEngineService object at 0x2b43ca3f9790>

and 

2007-03-09 15:07:50-0600 [VanillaEngineServerProtocol,0,129.162.165.123] registered engine: 0

appears on HOST1.

But when I try to call functions on the RemoteController, Things Fall
Apart:

In [1]: import ipython1.kernel.api as kernel

In [2]: ipc = kernel.RemoteController(('127.0.0.1',10001))

In [3]: ipc.getIDs()
Connecting to controller:  ('127.0.0.1', 10001)


Then on HOST1:


2007-03-09 15:10:31-0600 [VanillaEngineServerProtocol,1,127.0.0.1] Unhandled Error
    Traceback (most recent call last):
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/log.py", line 49, in callWithLogger
        return callWithContext({"system": lp}, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/log.py", line 34, in callWithContext
        return context.call({ILogContext: newCtx}, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/context.py", line 59, in callWithContext
        return self.currentContext().callWithContext(ctx, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/context.py", line 37, in callWithContext
        return func(*args,**kw)
    --- <exception caught here> ---
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/selectreactor.py", line 139, in _doReadOrWrite
        why = getattr(selectable, method)()
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/tcp.py", line 362, in doRead
        return self.protocol.dataReceived(data)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/protocols/basic.py", line 99, in dataReceived
        self.doData()
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/protocols/basic.py", line 62, in doData
        self.stringReceived(self.__buffer)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/enginevanilla.py", line 558, in stringReceived
        self.nextHandler(msg)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/enginevanilla.py", line 576, in dispatch
        self.dieLoudly('Command could not be dispatched: ' + msg)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/enginevanilla.py", line 586, in dieLoudly
        log.msg('Protocol Error [%i]: ' % id + repr(a))
    exceptions.TypeError: int argument required
    
2007-03-09 15:10:31-0600 [VanillaEngineServerProtocol,1,127.0.0.1] unregistered engine None
2007-03-09 15:10:31-0600 [VanillaEngineServerProtocol,1,127.0.0.1] Unhandled Error
    Traceback (most recent call last):
      File "/usr/local/bin/ipcontroller", line 51, in main
        reactor.run()
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/posixbase.py", line 220, in run
        self.mainLoop()
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/posixbase.py", line 231, in mainLoop
        self.doIteration(t)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/selectreactor.py", line 133, in doSelect
        _logrun(selectable, _drdw, selectable, method, dict)
    --- <exception caught here> ---
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/log.py", line 49, in callWithLogger
        return callWithContext({"system": lp}, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/log.py", line 34, in callWithContext
        return context.call({ILogContext: newCtx}, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/context.py", line 59, in callWithContext
        return self.currentContext().callWithContext(ctx, func, *args, **kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/python/context.py", line 37, in callWithContext
        return func(*args,**kw)
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/selectreactor.py", line 149, in _doReadOrWrite
        self._disconnectSelectable(selectable, why, method=="doRead")
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/posixbase.py", line 258, in _disconnectSelectable
        selectable.connectionLost(failure.Failure(why))
      File "/usr/local/stow/twisted-20070309_svn/lib/python2.4/site-packages/twisted/internet/tcp.py", line 416, in connectionLost
        protocol.connectionLost(reason)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/enginevanilla.py", line 539, in connectionLost
        self.factory.unregisterEngine(self.id)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/enginevanilla.py", line 1028, in unregisterEngine
        return self.service.unregisterEngine(id)
      File "/usr/local/stow/ipython1-20070309_svn/lib/python2.4/site-packages/ipython1/kernel/controllerservice.py", line 304, in unregisterEngine
        log.msg("engine %i was not registered" % id)
    exceptions.TypeError: int argument required



Any ideas?

Thanks,
Glen Mabey


From fperez.net at gmail.com  Sat Mar 10 03:18:52 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Mar 2007 01:18:52 -0700
Subject: [IPython-dev] starting local ipengines works great but not
	remote ipengines
In-Reply-To: <20070309211158.GA10670@bams.ccf.swri.edu>
References: <20070309211158.GA10670@bams.ccf.swri.edu>
Message-ID: <db6b5ecc0703100018s532cad53m69e0313a621c197a@mail.gmail.com>

On 3/9/07, Glen W. Mabey <Glen.Mabey at swri.org> wrote:
> Hello,
>
> Having installed ipython1 on two different machines, I am struggling to
> get engines on one to connect to a controller on the other.
>
> However, connecting to local controllers works on both machines.  One is
> an AMD64 while the other is a P4.
>
> The only deviation that I have made from the build instructions is in
> the recommendation to use Zope Interface version 3.1.0c1, which gave
> an error when I tried to build it.  Version 3.3.0 worked with no issues.

I'm afraid I have no clue here; but Brian knows this code much better
than I do, and he might be able to help.

One thing we need to do is to modify all components to use the ipython
exception reporting system, so that we get better tracebacks than the
primitive ones python puts out by default.  That will  help a lot in
situations like these.

As a long shot: do you have any firewalls between these two boxes?
The engine is attempting a connection /into/ the controller, so if the
host where the controller is running has a firewall, it may well be
dropping the connection.

Sorry not to be of more assistance at this point...

f


From fperez.net at gmail.com  Sat Mar 10 03:37:30 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Mar 2007 01:37:30 -0700
Subject: [IPython-dev] bug in ipy_default.py
In-Reply-To: <45EF11D9.6010602@bostream.nu>
References: <45EC6885.2030502@bostream.nu>
	<db6b5ecc0703051136j2ffb07b2o93afbd4887925d2b@mail.gmail.com>
	<45EDDD4D.3070700@bostream.nu>
	<db6b5ecc0703061335h263f594cm85edd27d28d9a5f6@mail.gmail.com>
	<45EF11D9.6010602@bostream.nu>
Message-ID: <db6b5ecc0703100037p10e61360r20c15df463e8c980@mail.gmail.com>

On 3/7/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> I think the release plan sounds fine. I would also like to make a
> release of a new pyreadline at the same time. I have a lot of new
> features in the refactor branch that I would like to merge to trunk. But
> there are so many changes to the layout of the code I don't think a
> merge will be possible without a *lot* of conflicts. So I'm thinking I
> should just delete current trunk and copy the refactor branch to trunk.
> Have you thought about how you will do when it's time to switch over to
> the new ipython? If there are no protests I will probably create a
> maintanence branch for 1.3 and do this delete/copy for 1.4 in the next
> couple of days.

Go for it.

When we get to switch, we'll probably make a branch out of the trunk
(for maintenance while people switch) and do as you describe.  A bit
coarse, but effective :)

> I have been experiencing some inconsistencies with tabcompletion of
> filenames recently. I think the new tab-completion hooks work a bit
> different from the normal tab-completion when it comes to escaping
> spaces in filenames. There is also a bug when completing on filenames
> for %run, when the first character is " then you get an exception. I
> could look into this, unless someone else is already looking into it.

I just opened a ticket for it:

http://projects.scipy.org/ipython/ipython/ticket/128

At this point anything we don't put into Trac will slip by, I'm afraid.

Anyone is welcome to fix it, of course :)

cheers,

f


From fperez.net at gmail.com  Sat Mar 10 03:40:07 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Mar 2007 01:40:07 -0700
Subject: [IPython-dev] Refactoring prefilter and ipython1
In-Reply-To: <7813ED00-E697-49F5-83E8-7ABE66D21582@comcast.net>
References: <6ce0ac130703060935u6b3d39e8k76dda88d39f724f2@mail.gmail.com>
	<db6b5ecc0703061034u634a2746s4ab37f40dd171b8f@mail.gmail.com>
	<46cb515a0703070352le9fe016oce2099c78f330822@mail.gmail.com>
	<7813ED00-E697-49F5-83E8-7ABE66D21582@comcast.net>
Message-ID: <db6b5ecc0703100040w61bb3195u7367a66076340d2c@mail.gmail.com>

On 3/7/07, Dan Milstein <danmil at comcast.net> wrote:
> >> To address Dan's questions about prefilter more specifically: my
> >> biggest worry is not to stall a potential contributor.  It's a bit
> >
> > I don't really see much need to reorganize the prefilter system. It's
> > terminal-independent, only deals with strings etc.
>
> The rewrite I've got planned is fairly modest (I think).  The main
> goal is just to make it much clearer what triggers a particular
> handler.  It should be no problem to keep it in a private copy for a
> few weeks, and then figure out how to merge it back over.  As Ville
> says, it actually has a fairly simple interface to much of the rest
> of the system -- it just takes a string and returns a string.  So I'm
> optimistic.
>
> As I find time, I'll work on that, and if it gets to a finished
> point, I'll post changes so people can take a look, with the
> understanding that it likely won't be seriously considered until
> after 0.7.4.

Great, thanks!  Your tests are already useful as it is :)

Cheers,

f


From fperez.net at gmail.com  Sat Mar 10 03:45:44 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Mar 2007 01:45:44 -0700
Subject: [IPython-dev] igrid
In-Reply-To: <45E847A8.2070006@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>
Message-ID: <db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>

On 3/2/07, Walter D?rwald <walter at livinglogic.de> wrote:
> I've checked in igrid, the wxPython-based ipipe browser done by Nik
> Tautenhahn.
>
> We've tested igrid on Linux with wx 2.6 and wx 2.8 and on Windows with
> wx 2.7 and 2.8. igrid will be used as the default browser if wx is
> installed on the system, so testing it should be rather simple:
>
> In [1]: from ipipe import *
> In [2]: ils
>
> This should give a directory listing in a wx window.

A couple of comments:

1. You might want to make the WX part optional somehow.  It will be
really surprising when someone over a slow SSH link types ils and now
instead of a light, fast curses browser, a big WX app tries to squeeze
through the SSH link.

2. I tried using it with

ipython -wthread

but got all kinds of error messages.  It would be great if it could
work there, since then people could pop igrid browsers while retaining
normal control of their shell, much like matplotlib (with the WX
backend) or the Enthought tools work.


Do you think you can try to iron these wrinkles out for the (planned,
dates may slip) April 1 release of 0.7.4?  Feel free to open a ticket
on Trac for this.

Cheers,

f


From fperez.net at gmail.com  Sat Mar 10 04:27:55 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 10 Mar 2007 02:27:55 -0700
Subject: [IPython-dev] iplib fix (#1)
In-Reply-To: <F7BA7C83-25D9-45A8-8562-947BBE55B23D@comcast.net>
References: <F7BA7C83-25D9-45A8-8562-947BBE55B23D@comcast.net>
Message-ID: <db6b5ecc0703100127p597519fl59f7a484524eb0af@mail.gmail.com>

Hi Dan,

On 3/2/07, Dan Milstein <danmil at comcast.net> wrote:
> Fernando (/Alex),
>
> Attached is a patch to the most recent version of iplib which fixes
> the problem reported.  Let's call it fix #1 because it doesn't
> represent the full overhaul of prefilter which is oh-so-close ;-).
>
> Also attached is a patch to test_prefilter.py so that it captures
> this problem (thanks to Alex's detailed report).
>
> The change is just in the first part of the line_split regex, from:
>
>      self.line_split = re.compile(r'^([\s*,;/])'
>
> To:
>
>      self.line_split = re.compile(r'^(\s*[,;/]?\s*)'
>
> The \s* doesn't work inside the [] (special chars are turned off, so
> that matches a '*' or a single whitespace), so the match was failing
> when it shouldn't, and falling back on whitespace splitting.  Now
> that first part can match whitespace optionally mixed with a single
> autocall esc char.
>
> This, um, fixed the problem, though I wouldn't swear as to *how* (see
> note about full rewrite above).

Thanks, I just committed both patches as of r2135.

Cheers,

f


From walter at livinglogic.de  Sat Mar 10 11:49:09 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sat, 10 Mar 2007 17:49:09 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
Message-ID: <45F2E185.3040901@livinglogic.de>

Fernando Perez wrote:

> On 3/2/07, Walter D?rwald <walter at livinglogic.de> wrote:
>> I've checked in igrid, the wxPython-based ipipe browser done by Nik
>> Tautenhahn.
>>
>> We've tested igrid on Linux with wx 2.6 and wx 2.8 and on Windows with
>> wx 2.7 and 2.8. igrid will be used as the default browser if wx is
>> installed on the system, so testing it should be rather simple:
>>
>> In [1]: from ipipe import *
>> In [2]: ils
>>
>> This should give a directory listing in a wx window.
> 
> A couple of comments:
> 
> 1. You might want to make the WX part optional somehow.  It will be
> really surprising when someone over a slow SSH link types ils and now
> instead of a light, fast curses browser, a big WX app tries to squeeze
> through the SSH link.

Done. Now ibrowse (the curses based browser) is preferred over igrid 
(the wx browser). I.e. you'll only get the wx browser if you don't have 
a working curses. And if you don't have wx installed either you'll get 
idump (which simply prints the output).

Changing this default is simple:
In [1]: import ipipe, igrid
In [2]: ipipe.defaultdisplay = igrid.igrid

> 2. I tried using it with
> 
> ipython -wthread
> 
> but got all kinds of error messages.  It would be great if it could
> work there, since then people could pop igrid browsers while retaining
> normal control of their shell, much like matplotlib (with the WX
> backend) or the Enthought tools work.

I don't see any problems here with -wthread (except that the next input 
prompt doesn't start on the next line). This is with wx 2.8/Python 2.4.3 
on Windows.

Can you post what error messages you got?

We'll try -wthread on Nik's Linux box to see what happens there.

> Do you think you can try to iron these wrinkles out for the (planned,
> dates may slip) April 1 release of 0.7.4?  Feel free to open a ticket
> on Trac for this.

That should be doable. And backing out igrid in case this problem can't 
be solved in time for 0.7.4 shouldn't be a problem, as there's only a 
little code in ipipe.py that activates igrid.

Servus,
    Walter


From jorgen.stenarson at bostream.nu  Sun Mar 11 12:02:23 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sun, 11 Mar 2007 17:02:23 +0100
Subject: [IPython-dev] Ticket #127
Message-ID: <45F4280F.9020300@bostream.nu>

hi,

I just attached a possible patch to ticket #127 (by the way #128 seems 
to be a copy of #127). It is not a completely finished I know there are 
some problems left but it fixes the most immediate problems.

This is the patch description I attached to the ticket:

The attachment ipy_stock_completers.diff tries to address this problem.

The %run tabcompletion handler had its own filematcher. The %cd handler 
seemed to rely on the standard completer and thus it would match both on 
files and directories.

The patch addresses these things:

1. With a single " at the beginning of the line it does not crash now. 
There are however still possible problems with \ and ' that are not 
properly handled.

2. The filematcher from ipython.completer has been copied and slightly 
changed to work on its own and not as a method.

3. Both cd and run now uses this extracted filematcher and should have 
more of a standard behaviour.

For the future I think it would be nice to do a refactoring of the 
completer functionality. For instance use the exact same code for file 
matching in the standard completer as in the handlers. It would probably 
also be good to have a standard function to decompose a line for the 
handlers to avoid future problems with "'\ handling. As well as adding 
some tests for this functionality.


/J?rgen



From virtual at gmx.de  Mon Mar 12 04:43:52 2007
From: virtual at gmx.de (Nikolas Tautenhahn)
Date: Mon, 12 Mar 2007 09:43:52 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <45F2E185.3040901@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de>
Message-ID: <45F512C8.1080508@gmx.de>

Hi there,

Walter D?rwald wrote:

>> >> ipython -wthread
>> >>
>> >> but got all kinds of error messages.  It would be great if it could
>> >> work there, since then people could pop igrid browsers while retaining
>> >> normal control of their shell, much like matplotlib (with the WX
>> >> backend) or the Enthought tools work.
> >
> > I don't see any problems here with -wthread (except that the next input
> > prompt doesn't start on the next line). This is with wx 2.8/Python
2.4.3
> > on Windows.
> >
> > Can you post what error messages you got?
> >
> > We'll try -wthread on Nik's Linux box to see what happens there.

I tried -wthread yesterday - and had no problems with it; even multiple
igrid instances were possible. The only thing I see is the deprecated
warning:

==============================
~> ipython -wthread
/usr/local/lib/python2.5/site-packages/ipython-0.7.4.svn.r2120-py2.5.egg/IPython/Shell.py:558:
DeprecationWarning: The wxPython compatibility package is no longer
automatically generated or activly maintained.  Please switch to the wx
package as soon as possible.
 import wxPython
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: ils
In [2]: ils + ienv
==============================

This was python 2.5 and wxPython 2.8.1.1 with openSuSE 10.2...
The only thing I noticed was that the igrid help did not work if you
install the svn version of ipython - but this is because of the setup
script not copying it, I think.

Regards,
Nik



From Glen.Mabey at swri.org  Mon Mar 12 11:44:52 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Mon, 12 Mar 2007 10:44:52 -0500
Subject: [IPython-dev] starting local ipengines works great but not
	remote ipengines
In-Reply-To: <db6b5ecc0703100018s532cad53m69e0313a621c197a@mail.gmail.com>
References: <20070309211158.GA10670@bams.ccf.swri.edu>
	<db6b5ecc0703100018s532cad53m69e0313a621c197a@mail.gmail.com>
Message-ID: <20070312154452.GC32491@bams.ccf.swri.edu>

On Sat, Mar 10, 2007 at 01:18:52AM -0700, Fernando Perez wrote:
> On 3/9/07, Glen W. Mabey <Glen.Mabey at swri.org> wrote:
> >Hello,
> >
> >Having installed ipython1 on two different machines, I am struggling to
> >get engines on one to connect to a controller on the other.
> >
> >However, connecting to local controllers works on both machines.  One is
> >an AMD64 while the other is a P4.
> >
> >The only deviation that I have made from the build instructions is in
> >the recommendation to use Zope Interface version 3.1.0c1, which gave
> >an error when I tried to build it.  Version 3.3.0 worked with no issues.
> 
> I'm afraid I have no clue here; but Brian knows this code much better
> than I do, and he might be able to help.
> 
> One thing we need to do is to modify all components to use the ipython
> exception reporting system, so that we get better tracebacks than the
> primitive ones python puts out by default.  That will  help a lot in
> situations like these.
> 
> As a long shot: do you have any firewalls between these two boxes?
> The engine is attempting a connection /into/ the controller, so if the
> host where the controller is running has a firewall, it may well be
> dropping the connection.

Nope, no firewalls.  I can even open a telnet session to the listening
port.

> Sorry not to be of more assistance at this point...

I wonder whether this has anything to do with the state of svn for
twisted that I happened to pick up last Friday.  Could anyone [hint,
hint, Brian] tell me what svn revision number is working for them?

Thanks,
Glen


From jorgen.stenarson at bostream.nu  Mon Mar 12 15:46:02 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 12 Mar 2007 20:46:02 +0100
Subject: [IPython-dev] Ticket #127
In-Reply-To: <46cb515a0703121020l602680e8p7b165dbcdedeebf9@mail.gmail.com>
References: <45F4280F.9020300@bostream.nu>	
	<46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
	<46cb515a0703121020l602680e8p7b165dbcdedeebf9@mail.gmail.com>
Message-ID: <45F5ADFA.6080304@bostream.nu>

Ville M. Vainio skrev:
> On 3/12/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> 
>> BTW, I don't really like the way you don't replace \ with / in your
>> patch. Is there a problem with getting /'s, i.e. did you hit some bugs
>> because of them?
> 
> (assuming the included file completer doesn't do it properly)
> 
> What I'd really like to see is minimal fix for the " shlex.split case
> (catch, raise trynext) for 0.7.4 and properly refactored completer
> stuff for later versions. This completer stuff has always proved to be
> fragile and problematic.
> 
> Any opinions regarding this?
> 
I think you're right. I will rework the patch to be minimal and then we 
can postpone the other stuff to after 0.7.4.

/J?rgen


From vivainio at gmail.com  Mon Mar 12 13:20:22 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 12 Mar 2007 18:20:22 +0100
Subject: [IPython-dev] Ticket #127
In-Reply-To: <46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
References: <45F4280F.9020300@bostream.nu>
	<46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
Message-ID: <46cb515a0703121020l602680e8p7b165dbcdedeebf9@mail.gmail.com>

On 3/12/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> BTW, I don't really like the way you don't replace \ with / in your
> patch. Is there a problem with getting /'s, i.e. did you hit some bugs
> because of them?

(assuming the included file completer doesn't do it properly)

What I'd really like to see is minimal fix for the " shlex.split case
(catch, raise trynext) for 0.7.4 and properly refactored completer
stuff for later versions. This completer stuff has always proved to be
fragile and problematic.

Any opinions regarding this?

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


From vivainio at gmail.com  Mon Mar 12 12:53:51 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 12 Mar 2007 17:53:51 +0100
Subject: [IPython-dev] Ticket #127
In-Reply-To: <45F4280F.9020300@bostream.nu>
References: <45F4280F.9020300@bostream.nu>
Message-ID: <46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>

On 3/11/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> I just attached a possible patch to ticket #127 (by the way #128 seems
> to be a copy of #127). It is not a completely finished I know there are
> some problems left but it fixes the most immediate problems.

Thanks, some notes:

> 1. With a single " at the beginning of the line it does not crash now.
> There are however still possible problems with \ and ' that are not
> properly handled.

I think the patch is a bit too elaborate and large. I would have
preferred to just catch the exception and raise ipapi.TryNext (i.e.
reverting to "behaviour as usual" if we are unable to be helpful
"easily") on failure. In the spirit of "worse is better" and "the
simplest thing that could possibly work".

> 2. The filematcher from ipython.completer has been copied and slightly
> changed to work on its own and not as a method.
>
> 3. Both cd and run now uses this extracted filematcher and should have
> more of a standard behaviour.
>
> For the future I think it would be nice to do a refactoring of the
> completer functionality. For instance use the exact same code for file
> matching in the standard completer as in the handlers. It would probably
> also be good to have a standard function to decompose a line for the
> handlers to avoid future problems with "'\ handling. As well as adding
> some tests for this functionality.

Now if you could find the time to do that, it would be great! Some
kind of completerutil.py to which we could use to clean up
ipy_stock_completers.py (which is becoming a bit large).

BTW, I don't really like the way you don't replace \ with / in your
patch. Is there a problem with getting /'s, i.e. did you hit some bugs
because of them?

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


From jorgen.stenarson at bostream.nu  Thu Mar 15 15:34:36 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 15 Mar 2007 20:34:36 +0100
Subject: [IPython-dev] pyreadline
Message-ID: <45F99FCC.3030303@bostream.nu>

hi

I have now created a maintenance branch for 1.3. And moved the refactor 
branch to become the new trunk.

/J?rgen


From jorgen.stenarson at bostream.nu  Thu Mar 15 15:39:08 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 15 Mar 2007 20:39:08 +0100
Subject: [IPython-dev] Ticket #127
In-Reply-To: <46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
References: <45F4280F.9020300@bostream.nu>
	<46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
Message-ID: <45F9A0DC.4080504@bostream.nu>

Here is the reworked patch. It only tries to fix the " problem for %run.


/J?rgen

Ville M. Vainio skrev:
> On 3/11/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
>> I just attached a possible patch to ticket #127 (by the way #128 seems
>> to be a copy of #127). It is not a completely finished I know there are
>> some problems left but it fixes the most immediate problems.
> 
> Thanks, some notes:
> 
>> 1. With a single " at the beginning of the line it does not crash now.
>> There are however still possible problems with \ and ' that are not
>> properly handled.
> 
> I think the patch is a bit too elaborate and large. I would have
> preferred to just catch the exception and raise ipapi.TryNext (i.e.
> reverting to "behaviour as usual" if we are unable to be helpful
> "easily") on failure. In the spirit of "worse is better" and "the
> simplest thing that could possibly work".
> 
>> 2. The filematcher from ipython.completer has been copied and slightly
>> changed to work on its own and not as a method.
>>
>> 3. Both cd and run now uses this extracted filematcher and should have
>> more of a standard behaviour.
>>
>> For the future I think it would be nice to do a refactoring of the
>> completer functionality. For instance use the exact same code for file
>> matching in the standard completer as in the handlers. It would probably
>> also be good to have a standard function to decompose a line for the
>> handlers to avoid future problems with "'\ handling. As well as adding
>> some tests for this functionality.
> 
> Now if you could find the time to do that, it would be great! Some
> kind of completerutil.py to which we could use to clean up
> ipy_stock_completers.py (which is becoming a bit large).
> 
> BTW, I don't really like the way you don't replace \ with / in your
> patch. Is there a problem with getting /'s, i.e. did you hit some bugs
> because of them?
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 1499 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070315/3b04f5cb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipy_stock_completers_2.diff
Type: application/octet-stream
Size: 1372 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070315/3b04f5cb/attachment.obj>

From vivainio at gmail.com  Thu Mar 15 17:03:27 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 15 Mar 2007 22:03:27 +0100
Subject: [IPython-dev] Ticket #127
In-Reply-To: <45F9A0DC.4080504@bostream.nu>
References: <45F4280F.9020300@bostream.nu>
	<46cb515a0703120953k26f9f2f5n6673282965bae9f9@mail.gmail.com>
	<45F9A0DC.4080504@bostream.nu>
Message-ID: <46cb515a0703151403n3da95e1aoa4e35ff81dc09462@mail.gmail.com>

On 3/15/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> Here is the reworked patch. It only tries to fix the " problem for %run.

Great! It's committed, tested and the ticket closed.

We can focus on getting stuff out of ipy_stock_completers later on. In
fact, it would be very cool for large magics like %run to have their
own module w/ completers etc. Perhaps someday, though it's probably
more IPython1 material :)

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


From danmil at comcast.net  Fri Mar 16 11:54:06 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 16 Mar 2007 11:54:06 -0400
Subject: [IPython-dev] Prefilter Cleanup
Message-ID: <E762994F-802D-426F-934F-440C50734ECC@comcast.net>

Okay, so I've finished up my private-copy rewrite of the prefiltering  
code.  It turned out to be a decent-sized refactoring, so holding off  
on merging it until after 0.7.4 probably makes sense.

In fact, if things still seem on track for that release, I'll hold  
off on posting patches until then, because I want to make sure that  
everything still works (I made a separate prefilter module and moved  
a bunch of iplib stuff into there).

That said, a few teasers:

  - Here's how the main block of prefilter code now looks:

     for check in [ checkEscChars,
                    checkEmacs,
                    checkMultiLineShell,
                    checkPythonChars,
                    checkAutomagic,
                    checkAlias,
                    checkAutocall,
                    ]:
         handler = check(line_info, ip)
         if handler:
             return handler(line_info)

     return ip.handle_normal(line_info)


Each check sees if the line matches a pattern, and if it does,  
returns a handler to transform the line.  So the sequence of possible  
handlers is totally explicit, and all the hairy sharing of partially  
parsed lines is gone.


  - Cleaned up a few subtle edge cases

Various things I asked about in previous emails now work in non- 
surprising ways.  And some other, very subtle things, having to do  
with order of namespace shadowing, attribute lookups and the like,  
also now work in non-surprising ways.


  - More tests

I added tests to check that the handlers were doing their jobs right,  
and various other tests as I ran into subtle issues.  Decently  
thorough set, and more can be added.


-Dan


From fperez.net at gmail.com  Sat Mar 17 21:09:49 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Mar 2007 19:09:49 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <45F512C8.1080508@gmx.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
Message-ID: <db6b5ecc0703171809r7087667dm5868974383000e6b@mail.gmail.com>

On 3/12/07, Nikolas Tautenhahn <virtual at gmx.de> wrote:

> > > We'll try -wthread on Nik's Linux box to see what happens there.
>
> I tried -wthread yesterday - and had no problems with it; even multiple
> igrid instances were possible. The only thing I see is the deprecated
> warning:
>
> ==============================
> ~> ipython -wthread
> /usr/local/lib/python2.5/site-packages/ipython-0.7.4.svn.r2120-py2.5.egg/IPython/Shell.py:558:
> DeprecationWarning: The wxPython compatibility package is no longer
> automatically generated or activly maintained.  Please switch to the wx
> package as soon as possible.
>  import wxPython
> Python 2.5 (r25:51908, Jan  9 2007, 16:59:32)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
> In [1]: ils
> In [2]: ils + ienv
> ==============================
>
> This was python 2.5 and wxPython 2.8.1.1 with openSuSE 10.2...
> The only thing I noticed was that the igrid help did not work if you
> install the svn version of ipython - but this is because of the setup
> script not copying it, I think.

I'm running on WX 2.6, as I suspect many people still are (since it's
the version still shipping with several linux distros).  It's quite
possible that the problems only appear with 2.6.

I'll fix the above warning, thanks for reporting it.

Cheers,

f


From fperez.net at gmail.com  Sat Mar 17 21:11:56 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Mar 2007 19:11:56 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <45F512C8.1080508@gmx.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
Message-ID: <db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>

On 3/12/07, Nikolas Tautenhahn <virtual at gmx.de> wrote:
> Hi there,
>
> Walter D?rwald wrote:
>
> >> >> ipython -wthread
> >> >>
> >> >> but got all kinds of error messages.  It would be great if it could
> >> >> work there, since then people could pop igrid browsers while retaining
> >> >> normal control of their shell, much like matplotlib (with the WX
> >> >> backend) or the Enthought tools work.
> > >
> > > I don't see any problems here with -wthread (except that the next input
> > > prompt doesn't start on the next line). This is with wx 2.8/Python
> 2.4.3
> > > on Windows.
> > >
> > > Can you post what error messages you got?

Here's what I see:

---------------------------------------------------------------------------
wx._core.PyNoAppError                              Traceback (most
recent call last)

/home/fperez/usr/lib/python2.4/site-packages/IPython/Extensions/igrid.py
in GetAttr(self, *args)
    133     def GetAttr(self, *args):
    134         attr = wx.grid.GridCellAttr()
--> 135         attr.SetFont(wx.Font(self.fontsize, wx.TELETYPE,
wx.NORMAL, wx.NORMAL))
    136         return attr
    137

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_gdi.py in
__init__(self, *args, **kwargs)
   1720         """
   1721         if kwargs.has_key('faceName'): kwargs['face'] =
kwargs['faceName'];del kwargs['faceName']
-> 1722         newobj = _gdi_.new_Font(*args, **kwargs)
   1723         self.this = newobj.this
   1724         self.thisown = 1

PyNoAppError: The wx.App object must be created first!

This message gets printed zillions of times, since it seems to be
triggered by an event handler on mouse movement.  So basically the
screen goes nuts printing this same traceback over and over as fast as
it can.

Cheers,

f


From fperez.net at gmail.com  Sat Mar 17 21:17:49 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Mar 2007 19:17:49 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <45F512C8.1080508@gmx.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
Message-ID: <db6b5ecc0703171817r53bc9629n97597507a877e3d7@mail.gmail.com>

On 3/12/07, Nikolas Tautenhahn <virtual at gmx.de> wrote:

> I tried -wthread yesterday - and had no problems with it; even multiple
> igrid instances were possible. The only thing I see is the deprecated
> warning:
>
> ==============================
> ~> ipython -wthread
> /usr/local/lib/python2.5/site-packages/ipython-0.7.4.svn.r2120-py2.5.egg/IPython/Shell.py:558:
> DeprecationWarning: The wxPython compatibility package is no longer
> automatically generated or activly maintained.  Please switch to the wx
> package as soon as possible.
>  import wxPython

Fixed as of r2151, let me know if you notice any problems.

Thanks for the report,

f


From fperez.net at gmail.com  Sat Mar 17 22:14:34 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 17 Mar 2007 20:14:34 -0600
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <73eb51090608130647q7e4b119dl317afac351dc3778@mail.gmail.com>
References: <ebep0f$c6i$1@sea.gmane.org>
	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
	<44DBBD64.5060201@livinglogic.de> <ebh9k8$2hb$1@sea.gmane.org>
	<46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>
	<73eb51090608130647q7e4b119dl317afac351dc3778@mail.gmail.com>
Message-ID: <db6b5ecc0703171914ne21a0a1md9082f1b430b2eec@mail.gmail.com>

On 8/13/06, Denis Simakov <akinoame1 at gmail.com> wrote:
> I have 'UTF-8' for all the cases (ipython and python,
> sys.stdin.encoding and sys.stdout.encoding).
>
> (And I see the same bug with unicode as described by Alexander.)

I honestly don't know what's going on here, but I opened a ticket for it:

http://projects.scipy.org/ipython/ipython/ticket/129

I tried a few things but nothing fixed the issue, and my ignorance of
unicode is fairly vast.

Input from anyone who actually knows this topic would be very welcome.

Cheers,

f


From fperez.net at gmail.com  Sun Mar 18 22:54:17 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 18 Mar 2007 20:54:17 -0600
Subject: [IPython-dev] breaking readline
In-Reply-To: <1162691610.19366.12.camel@localhost>
References: <1162691610.19366.12.camel@localhost>
Message-ID: <db6b5ecc0703181954m7cb6b5b9u86080abda1f33fe8@mail.gmail.com>

On 11/4/06, Alan Trick <alantrick at gmail.com> wrote:
> Hi
>
> I'm trying to create a wrapper for sys.stdout. I have some code (link at
> bottom) and it works fine on the standards python console, but not so
> well in ipython. In ipython it breaks readline so you end up seeing a
> lot of weird charachters and certain keys stop working. It works fine in
> code.InteractiveConsole. Anyone know what ipython is doing to cause
> this.
>
> n.b. I know my code has issues, like using open('/dev/stdout') and a few
> other thing, but as it is it *should* work. It's mostly a proof off
> concept
>
> Link:
> http://terminate.svn.sourceforge.net/viewvc/terminate/trunk/terminate/wrapper.py?revision=68&view=markup

Sorry this fell through the cracks.  This link doesn't work anymore so
I can't really look.  But basically anything that breaks readline is
going to seriously munge ipython, since it relies so strongly on
readline.  As to /why/ readline breaks, I honestly don't know.

Cheers,

f


From jesus at aguillon.com  Sun Mar 18 23:08:33 2007
From: jesus at aguillon.com (Jesus Aguillon)
Date: Sun, 18 Mar 2007 20:08:33 -0700
Subject: [IPython-dev]  edited file is readonly how to change?
Message-ID: <45FDFEB1.1080506@aguillon.com>

I was wondering if there was anymore information regarding this issue?
This still occurs with the released version of 0.7.3.

I am using Python 2.5 and GVim 7.0 on Windows XP SP2.

I run the %edit command.

Regards,

Jesus Aguillon



On 12/12/06, Ville M. Vainio <vivainio at gmail.com <http://projects.scipy.org/mailman/listinfo/ipython-dev>> wrote:
>/
/>/ On 12/9/06, Jesus Aguillon <jesus at aguillon.com <http://projects.scipy.org/mailman/listinfo/ipython-dev>> wrote:
/>/
/>/ > When I edit a file from within IPython and it has a syntax error, the
/>/ next
/>/ > time time I try to edit the file it is opened as read-only.  I am using
/>/ > Windows XP SP2,  IPython 0.7.3b3.r1975 and Gvim 7.0.
/>/ >
/>/ > I can work around this by writing the file using w! from within vim.  Is
/>/ > there a way to clear the read-only status on the file without leaving
/>/ > IPython?  (It is cleared when I exit IPython)
/>/
/>/ How do you "edit" the file? Executing %edit, or running vim directly?
/>



From fperez.net at gmail.com  Sun Mar 18 23:16:40 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 18 Mar 2007 21:16:40 -0600
Subject: [IPython-dev] edited file is readonly how to change?
In-Reply-To: <45FDFEB1.1080506@aguillon.com>
References: <45FDFEB1.1080506@aguillon.com>
Message-ID: <db6b5ecc0703182016u627911a8g96558e7d6a336795@mail.gmail.com>

On 3/18/07, Jesus Aguillon <jesus at aguillon.com> wrote:
> I was wondering if there was anymore information regarding this issue?
> This still occurs with the released version of 0.7.3.
>
> I am using Python 2.5 and GVim 7.0 on Windows XP SP2.
>
> I run the %edit command.

I'm afraid I have no idea; the problem certainly does NOT occur under
linux, so it must be some particular interaction of GVim and XP.
Given how I use neither, I doubt I'll be of much help.

It would be a good idea if you could file a ticket on this item at the
bug tracker:

http://ipython.scipy.org/trac

This way it won't be forgotten and perhaps one day someone will
understand what's going on (we do have win32 developers, so there's
hope).

Sorry not to be able to help further.

Regards,

f


From fperez.net at gmail.com  Sun Mar 18 23:51:57 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 18 Mar 2007 21:51:57 -0600
Subject: [IPython-dev] cpaste and history
In-Reply-To: <20060720110321.GH23629@mentat.za.net>
References: <20060720110321.GH23629@mentat.za.net>
Message-ID: <db6b5ecc0703182051x56ae04afx1bfac590ce783997@mail.gmail.com>

On 7/20/06, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hi all,
>
> While using cpaste, I noticed that the readline search history does
> not reflect the executed code.  I.e., if you do
>
> In [1]: cpaste
> Pasting code; enter '--' alone on the line to stop.
> :    x = 1
> :--
> x = 1
>
> and then type
>
> In [2]: x =<up-arrow>
>
> it does not complete.  Rather
>
> In [2]:     x =<up-arrow>
>
> does.  I played around a bit, but couldn't see an obvious way to
> retrospectively change the raw_input history.  Does anyone here know
> how?
>
> While I see the logic of the current behaviour, I think it might be
> more useful to put the dedented commands in the history.

Feel free to file a ticket on this one.

We certainly won't get to this for the next release, but without a
ticket the issue will just be forgotten the moment I hit 'archive' in
my gmail account (in 5 seconds :)

Cheers,

f


From walter at livinglogic.de  Mon Mar 19 04:34:29 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Mon, 19 Mar 2007 09:34:29 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
References: <45E847A8.2070006@livinglogic.de>	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>	<45F2E185.3040901@livinglogic.de>
	<45F512C8.1080508@gmx.de>
	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
Message-ID: <45FE4B15.3050003@livinglogic.de>

Fernando Perez wrote:

> On 3/12/07, Nikolas Tautenhahn <virtual at gmx.de> wrote:
>> Hi there,
>>
>> Walter D?rwald wrote:
>>
>>>>>> ipython -wthread
>>>>>>
>>>>>> but got all kinds of error messages.  It would be great if it could
>>>>>> work there, since then people could pop igrid browsers while retaining
>>>>>> normal control of their shell, much like matplotlib (with the WX
>>>>>> backend) or the Enthought tools work.
>>>> I don't see any problems here with -wthread (except that the next input
>>>> prompt doesn't start on the next line). This is with wx 2.8/Python
>> 2.4.3
>>>> on Windows.
>>>>
>>>> Can you post what error messages you got?
> 
> Here's what I see:
> 
> ---------------------------------------------------------------------------
> wx._core.PyNoAppError                              Traceback (most
> recent call last)
> 
> /home/fperez/usr/lib/python2.4/site-packages/IPython/Extensions/igrid.py
> in GetAttr(self, *args)
>     133     def GetAttr(self, *args):
>     134         attr = wx.grid.GridCellAttr()
> --> 135         attr.SetFont(wx.Font(self.fontsize, wx.TELETYPE,
> wx.NORMAL, wx.NORMAL))
>     136         return attr
>     137
> 
> /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_gdi.py in
> __init__(self, *args, **kwargs)
>    1720         """
>    1721         if kwargs.has_key('faceName'): kwargs['face'] =
> kwargs['faceName'];del kwargs['faceName']
> -> 1722         newobj = _gdi_.new_Font(*args, **kwargs)
>    1723         self.this = newobj.this
>    1724         self.thisown = 1
> 
> PyNoAppError: The wx.App object must be created first!
> 
> This message gets printed zillions of times, since it seems to be
> triggered by an event handler on mouse movement.  So basically the
> screen goes nuts printing this same traceback over and over as fast as
> it can.

OK, this seems to be wx related. I'll downgrade my wx on Windows to 2.6 
and we'll see what happens.

Servus,
    Walter


From walter at livinglogic.de  Mon Mar 19 12:03:08 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Mon, 19 Mar 2007 17:03:08 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <45FE4B15.3050003@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>	<45F2E185.3040901@livinglogic.de>	<45F512C8.1080508@gmx.de>	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
	<45FE4B15.3050003@livinglogic.de>
Message-ID: <45FEB43C.40407@livinglogic.de>

Walter D?rwald wrote:
> Fernando Perez wrote:
> 
>> On 3/12/07, Nikolas Tautenhahn <virtual at gmx.de> wrote:
>>> Hi there,
>>>
>>> Walter D?rwald wrote:
>>>
>>>>>>> ipython -wthread
>>>>>>>
>>>>>>> but got all kinds of error messages.  It would be great if it could
>>>>>>> work there, since then people could pop igrid browsers while retaining
>>>>>>> normal control of their shell, much like matplotlib (with the WX
>>>>>>> backend) or the Enthought tools work.
>>>>> I don't see any problems here with -wthread (except that the next input
>>>>> prompt doesn't start on the next line). This is with wx 2.8/Python
>>> 2.4.3
>>>>> on Windows.
>>>>>
>>>>> Can you post what error messages you got?
>> Here's what I see:
>>
>> ---------------------------------------------------------------------------
>> wx._core.PyNoAppError                              Traceback (most
>> recent call last)
>>
>> /home/fperez/usr/lib/python2.4/site-packages/IPython/Extensions/igrid.py
>> in GetAttr(self, *args)
>>     133     def GetAttr(self, *args):
>>     134         attr = wx.grid.GridCellAttr()
>> --> 135         attr.SetFont(wx.Font(self.fontsize, wx.TELETYPE,
>> wx.NORMAL, wx.NORMAL))
>>     136         return attr
>>     137
>>
>> /usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_gdi.py in
>> __init__(self, *args, **kwargs)
>>    1720         """
>>    1721         if kwargs.has_key('faceName'): kwargs['face'] =
>> kwargs['faceName'];del kwargs['faceName']
>> -> 1722         newobj = _gdi_.new_Font(*args, **kwargs)
>>    1723         self.this = newobj.this
>>    1724         self.thisown = 1
>>
>> PyNoAppError: The wx.App object must be created first!
>>
>> This message gets printed zillions of times, since it seems to be
>> triggered by an event handler on mouse movement.  So basically the
>> screen goes nuts printing this same traceback over and over as fast as
>> it can.
> 
> OK, this seems to be wx related. I'll downgrade my wx on Windows to 2.6 
> and we'll see what happens.

OK, with wx 2.6 I can reproduce the problem.

Can you try r2161? For me this delays the problem until you open
multiple igrid browser and close one of them.

One solution might be to only allow one igrid browser. The other would
probably be that all igrid browsers are frames in only one wx application.

Servus,
   Walter


From fperez.net at gmail.com  Tue Mar 20 03:04:09 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 20 Mar 2007 01:04:09 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <45FEB43C.40407@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
	<45FE4B15.3050003@livinglogic.de> <45FEB43C.40407@livinglogic.de>
Message-ID: <db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>

On 3/19/07, Walter D?rwald <walter at livinglogic.de> wrote:

> OK, with wx 2.6 I can reproduce the problem.
>
> Can you try r2161? For me this delays the problem until you open
> multiple igrid browser and close one of them.

Much, much better.

Q: why does it only show the first 40 directories if I do ils ?  I
don't see a way to list anything after that, so doing ils on $HOME is
kind of useless in my case :)

> One solution might be to only allow one igrid browser. The other would
> probably be that all igrid browsers are frames in only one wx application.

I'll leave that decision up to you.  As long as we ship something that
works correctly with wx 2.6 (which is what most distros still have
officially), I trust you on the implementation choices.

Cheers,

f


From vivainio at gmail.com  Tue Mar 20 03:45:26 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 20 Mar 2007 08:45:26 +0100
Subject: [IPython-dev] IPython 0.7.4 timetable concerns
Message-ID: <46cb515a0703200045r34068f20p10956a071b18725f@mail.gmail.com>

Hey,

As you have probably seen, I'm been somewhat unable to get all the
stuff that should go into 0.7.4 done in a timely fashion. Most of this
is because the sub-optimal working conditions at my hotel, and the
general reduction of freetime computer use as a result. Now it appears
that my work period in Sweden will continue for 6 more months, so I'm
not sure I can put in all the work I should for 0.7.4 in the projected
time. At workplace I have zero time for IPython work.

Possible solutions:

- Fernando will do most of the 0.7.4 stuff, which seems to be the case
already. Is it ok for your time plans, Fernando?

- Give SVN rights to more people. I've seen some promising enthusiasm
for doing general code laundering tasks among some people on the
mailing list recently.

I'm not "giving up" by any means, just for 0.7.4 which seems to be the
right way to go right now.

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


From walter at livinglogic.de  Tue Mar 20 04:30:02 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 20 Mar 2007 09:30:02 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>
References: <45E847A8.2070006@livinglogic.de>	
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>	
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>	
	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>	
	<45FE4B15.3050003@livinglogic.de> <45FEB43C.40407@livinglogic.de>
	<db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>
Message-ID: <45FF9B8A.8040102@livinglogic.de>

Fernando Perez wrote:

> On 3/19/07, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> OK, with wx 2.6 I can reproduce the problem.
>>
>> Can you try r2161? For me this delays the problem until you open
>> multiple igrid browser and close one of them.
> 
> Much, much better.
> 
> Q: why does it only show the first 40 directories if I do ils ?  I
> don't see a way to list anything after that, so doing ils on $HOME is
> kind of useless in my case :)

It only fetches enough directory entries to fill one screen. If you want 
to see more you have to scroll down, i.e. putting the cursor in the last 
row fetches more.

>> One solution might be to only allow one igrid browser. The other would
>> probably be that all igrid browsers are frames in only one wx 
>> application.
> 
> I'll leave that decision up to you.  As long as we ship something that
> works correctly with wx 2.6 (which is what most distros still have
> officially), I trust you on the implementation choices.

The second variant would be the better choice of course.

Nik is currently preparing for exams, so he doesn't have much time. I'll 
see what I can do.

Servus,
    Walter


From jorgen.stenarson at bostream.nu  Tue Mar 20 16:10:29 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 20 Mar 2007 21:10:29 +0100
Subject: [IPython-dev] bug in ipy_stock_completer
Message-ID: <46003FB5.5010001@bostream.nu>

the helper function shlex_split that I introduced to help matching when
there are unmatched " on the line did not work properly if there were no 
" at all on the line. I committed a fix for this.

/J?rgen



From fperez.net at gmail.com  Wed Mar 21 02:37:11 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Mar 2007 00:37:11 -0600
Subject: [IPython-dev] IPython 0.7.4 timetable concerns
In-Reply-To: <46cb515a0703200045r34068f20p10956a071b18725f@mail.gmail.com>
References: <46cb515a0703200045r34068f20p10956a071b18725f@mail.gmail.com>
Message-ID: <db6b5ecc0703202337u5770155ctcba668482aa5f3a@mail.gmail.com>

On 3/20/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> Hey,
>
> As you have probably seen, I'm been somewhat unable to get all the
> stuff that should go into 0.7.4 done in a timely fashion. Most of this
> is because the sub-optimal working conditions at my hotel, and the
> general reduction of freetime computer use as a result. Now it appears
> that my work period in Sweden will continue for 6 more months, so I'm
> not sure I can put in all the work I should for 0.7.4 in the projected
> time. At workplace I have zero time for IPython work.
>
> Possible solutions:
>
> - Fernando will do most of the 0.7.4 stuff, which seems to be the case
> already. Is it ok for your time plans, Fernando?

That's fine; I'd like 0.7.4 out in early April because John Hunter
(matplotlib) and I have a workshop to teach.  That's why I tried to
flush the bulk of my accumulated inbox this past weekend, and I'll
continue with the remaining material.

If you have anything in your inbox that I haven't mentioned, it would
greatly help if you remind me (I may have accidentally overlooked
something).  Either on the list if you think it's something I can
quickly dispatch, or with a ticket if you think it may become
post-0.7.4 material.

The other driving concern for me is committing all pending
contributions so that I can start moving the codebase over into the
saw branch for a unification.  Doing that  will take some time, but
now I think it won't be so bad, given how we have an easy way to toss
tests into the system.

> - Give SVN rights to more people. I've seen some promising enthusiasm
> for doing general code laundering tasks among some people on the
> mailing list recently.

I'm certainly not opposed to more contributors in principle.  I
suspect the overhaul of the code in the coming weeks is something that
not too many people will want to get involved with, but contributions
to specific subsystems are easier to get into.  We have several good
examples of this already (Walter, Jorgen, Dan's prefiltering, etc).

If anyone feels that not having SVN access is hindering their ability
to contribute,  please let me know.  If you've already shown interest
and have sent material in, I'll be happy to provide access as long as
you have some specific goals in mind.

> I'm not "giving up" by any means, just for 0.7.4 which seems to be the
> right way to go right now.

No worries, I'm glad you let us know, and I hope that things settle a
bit later in the year.  There will be much more to do :)

Cheers,

f


From fperez.net at gmail.com  Wed Mar 21 02:55:31 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 21 Mar 2007 00:55:31 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <45FF9B8A.8040102@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
	<45FE4B15.3050003@livinglogic.de> <45FEB43C.40407@livinglogic.de>
	<db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>
	<45FF9B8A.8040102@livinglogic.de>
Message-ID: <db6b5ecc0703202355g474d7976vf81cd6d03b677b83@mail.gmail.com>

On 3/20/07, Walter D?rwald <walter at livinglogic.de> wrote:
> Fernando Perez wrote:

> > Q: why does it only show the first 40 directories if I do ils ?  I
> > don't see a way to list anything after that, so doing ils on $HOME is
> > kind of useless in my case :)
>
> It only fetches enough directory entries to fill one screen. If you want
> to see more you have to scroll down, i.e. putting the cursor in the last
> row fetches more.

Ah, OK, thanks.

> >> One solution might be to only allow one igrid browser. The other would
> >> probably be that all igrid browsers are frames in only one wx
> >> application.
> >
> > I'll leave that decision up to you.  As long as we ship something that
> > works correctly with wx 2.6 (which is what most distros still have
> > officially), I trust you on the implementation choices.
>
> The second variant would be the better choice of course.
>
> Nik is currently preparing for exams, so he doesn't have much time. I'll
> see what I can do.

No prob.  Won't be releasing for another 10 days at least...  And now
it's actually quite usable, even if not perfect with wx 2.6.

Cheers,

f


From fperez.net at gmail.com  Thu Mar 22 02:42:21 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Mar 2007 00:42:21 -0600
Subject: [IPython-dev] Strange bug
In-Reply-To: <m2zm8xw9sl.fsf@ucolick.org>
References: <m2zm8xw9sl.fsf@ucolick.org>
Message-ID: <db6b5ecc0703212342p74533fbau53fa984a72fae1c1@mail.gmail.com>

Hi Greg,

On 1/5/07, Gregory Novak <novak at ucolick.org> wrote:
> I just spent the better part of a day trying to figure out what on
> earth was going on with a rather strange bug.  The dramatis personae:
>
> pyIDL is a bit of python + c code that allows you call IDL
> (http://www.ittvis.com/idl/) code from Python
> (http://www.its.caltech.edu/~mmckerns/software.html)
>
> (for Mike: IPython is an enhanced interactive python shell
> http://ipython.scipy.org/moin/)
>
> pyIDL provides getattr/setattr functions to access variables in IDL so
> that instead of typing idl_instance.get('x') you can type
> idl_instance.x
>
> There's also a function called eval that evaluates IDL expressions,
> like so:
> idl_instance.eval('y=x')
>
> When I called idl_instance.eval('y=x') under plain vanilla python, it
> worked fine.  When I called the same thing under IPython, I got
> strange errors coming from IDL:
>
> % Attempt to call undefined procedure/function: 'EVAL'.
> % Execution halted at: $MAIN$

[...]

I just wanted to update you on this.  I'm pretty sure that recent work
on the input parsinng code, with contributions from Dan Milstein and
Alex Schmolck, have squashed this particular bug (Alex got hit
basically by the same problem, and in an oddly similar system: his
matlab call system which is much like your IDL one but for matlab).

Here's a simple demo:

In [3]: !cat attribs.py
class foo(object):
       def __getattr__(self,attr):
           print 'getattr: ', attr; return lambda *args, **kwargs: 'nada'

f=foo()
f.bar()

In [4]: run attribs.py
getattr:  bar

In [5]: f.eval('y=x')
getattr:  eval
Out[5]: 'nada'


So I think that with current SVN, or ipython 0.7.4 (due in a couple of
weeks) you should be good.  It would be nice if you could double check
with an SVN checkout and let us know of any problems before  we put
0.7.4 officially out.

Cheers,

f


From fperez.net at gmail.com  Thu Mar 22 19:28:56 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 22 Mar 2007 17:28:56 -0600
Subject: [IPython-dev] Preparing for the 0.7.4 release
Message-ID: <db6b5ecc0703221628s6a40a40en1fa4df4bc9329f81@mail.gmail.com>

Hi all,

we're getting to be in reasonable shape for a release of 0.7.4.

This page has a summary of the progress:

http://projects.scipy.org/ipython/ipython/milestone/0.7.4

and here's the real meat, the open tickets:

http://projects.scipy.org/ipython/ipython/query?status=new&status=assigned&status=reopened&milestone=0.7.4


I think I can deal with the bulk of these, though obviously help is
always welcome.

But there's one in particular that I'm a bit stumped on, the unicode bug:

http://projects.scipy.org/ipython/ipython/ticket/129

If anyone knows what to do here, I'd be very grateful for help
(patches, ideas, a reference on what to do, whatever).


Also, both for developers and for users: if you see anything that I
may have missed, this is the time to yell.  Either bring it up on the
mailing list or better yet, file a ticketed targeted to 0.7.4 on the
issue.

If all goes well, we should be able to meet the April 1 deadline at
least for a release candidate, maybe with an actual release a week
later.

Cheers,

f


From fperez.net at gmail.com  Fri Mar 23 02:13:06 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 23 Mar 2007 00:13:06 -0600
Subject: [IPython-dev] __file__ bug
In-Reply-To: <46cb515a0606300413p6d07a0cfgaa4dbdcb9878180@mail.gmail.com>
References: <loom.20060627T153933-922@post.gmane.org>
	<46cb515a0606300413p6d07a0cfgaa4dbdcb9878180@mail.gmail.com>
Message-ID: <db6b5ecc0703222313n2c2484ccv51013711a1456940@mail.gmail.com>

On 6/30/06, Ville Vainio <vivainio at gmail.com> wrote:
> On 6/27/06, sebastian rooks <sebastian.rooks at free.fr> wrote:
>
> > but in the same file, the line:
> >   1484          sys.modules[prog_ns['__name__']] = FakeModule(prog_ns)
> >
> > modify the __file__ value through a change introduce by changeset 1322 line 39
> > in FakeModule.py:
> >   38            # modules should have a __file__ attribute
> >   39            adict['__file__'] = __file__
>
> It was made by Fernando to fix misbehaving help() in python 2.3
> (IIRC), so I don't think I should just revert the patch. If this is
> really required for py 2.3 (Fernando's input appreciated, if he still
> remembers the rationale for setting the module of FakeModule.py as the
> __file__ for the %run-ed file), I guess we could put a test for python
> version and provide the correct __file__ for py 2.4 (and leave this
> feature pseudo-broken for py 2.3, i.e. the way it is now).

I made a small change that should fix the reported problem without any
undue side effects.  Committed to SVN as r2169.

Thanks for the original report, and sorry this was so incredibly delayed!

Cheers,

f


From danmil at comcast.net  Fri Mar 23 10:25:34 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 23 Mar 2007 10:25:34 -0400
Subject: [IPython-dev] Trac Notifications
Message-ID: <EF2A9D52-18FD-49D8-8657-26F7E292E516@comcast.net>

Are folks somehow subscribing to Trac ticket changes?  I'd like to  
stay up to date--is everyone just checking the Trac site semi- 
continually?  Or am I not subscribed to a mailing list that would  
send those out?

-D


From fperez.net at gmail.com  Fri Mar 23 16:23:40 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 23 Mar 2007 14:23:40 -0600
Subject: [IPython-dev] Trac Notifications
In-Reply-To: <EF2A9D52-18FD-49D8-8657-26F7E292E516@comcast.net>
References: <EF2A9D52-18FD-49D8-8657-26F7E292E516@comcast.net>
Message-ID: <db6b5ecc0703231323v4f065f5ao48cb86825f2ac50b@mail.gmail.com>

Hi Dan,

On 3/23/07, Dan Milstein <danmil at comcast.net> wrote:
> Are folks somehow subscribing to Trac ticket changes?  I'd like to
> stay up to date--is everyone just checking the Trac site semi-
> continually?  Or am I not subscribed to a mailing list that would
> send those out?

We don't have an SVN commits mailing list, simply because long ago
when I tried to set one up, there were problems with the server setup
that made it not work correctly.  Enthought has overhauled their
system, so it would probably be possible to do it now.

However, I've mostly settled on using an RSS feeed on it:

http://projects.scipy.org/ipython/ipython/timeline?daysback=14&max=30&wiki=on&ticket=on&changeset=on&milestone=on&format=rss


You can make an RSS feed off the parts of the trac timeline that
interest you and only those.

Would that work for you?  If not I can look into setting up a mailing
list for commits, but I have a lot of other things coming first in the
todo plate.

Cheers,


f


From laurent.dufrechou at free.fr  Fri Mar 23 16:46:05 2007
From: laurent.dufrechou at free.fr (Laurent =?iso-8859-1?q?Dufr=E9chou?=)
Date: Fri, 23 Mar 2007 21:46:05 +0100
Subject: [IPython-dev] ipython1 remote import faillure
In-Reply-To: <db6b5ecc0703221628s6a40a40en1fa4df4bc9329f81@mail.gmail.com>
References: <db6b5ecc0703221628s6a40a40en1fa4df4bc9329f81@mail.gmail.com>
Message-ID: <200703232146.05476.laurent.dufrechou@free.fr>

Hello there,
4 : rc.executeAll('import os,sys')
#5 : import os,sys
#6 : sys.path.append(os.path.abspath(os.path.curdir))

I've just dicovered your excellent ipython extension that is the chainsaw 
branch.
I'm currently evaluating it for a project of efficient remote script execution 
on multiple server.(and it seems to be quite good at this!)
During my evaluation, I've found a bug and it's a workaround.
I've seen that somebody had seen it previously with the pushModule method.
In my case, I try to execute an 'import' of a local library/script that is 
present in the working directory of the remote python server.
Let's have an example:

1 : import ipython1.kernel.api as kernel
2 : rc = kernel.RemoteController(('127.0.0.1',10105))
3 : rc.executeAll('import a')
>> fails because a.py can't be found BUT a.py is present in the working 
directory

>> workaround :
4 : rc.executeAll('import os,sys')
5 : rc.executeAll('sys.path.append(os.path.abspath(os.path.curdir))')
6 : rc.executeAll('import a')
>> now works!

Can't it be possible when ipengine starts, that it does exceute the 2 
workaround commands?

I've seen that there is a '-r' option (that i haven't tried yet) but I think 
this behaviour is more a bug than a missing feature, so i prefer to tell it 
on the mailing list.

Regards,

Laurent


From walter at livinglogic.de  Sat Mar 24 16:42:11 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sat, 24 Mar 2007 21:42:11 +0100
Subject: [IPython-dev] igrid
In-Reply-To: <45FF9B8A.8040102@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>		<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>		<45F2E185.3040901@livinglogic.de>
	<45F512C8.1080508@gmx.de>		<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>		<45FE4B15.3050003@livinglogic.de>
	<45FEB43C.40407@livinglogic.de>	<db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>
	<45FF9B8A.8040102@livinglogic.de>
Message-ID: <46058D23.4030709@livinglogic.de>

Walter D?rwald wrote:

> Fernando Perez wrote:
> 
>> On 3/19/07, Walter D?rwald <walter at livinglogic.de> wrote:
>>
> [...]
>>> One solution might be to only allow one igrid browser. The other would
>>> probably be that all igrid browsers are frames in only one wx 
>>> application.
>> I'll leave that decision up to you.  As long as we ship something that
>> works correctly with wx 2.6 (which is what most distros still have
>> officially), I trust you on the implementation choices.
> 
> The second variant would be the better choice of course.
> 
> Nik is currently preparing for exams, so he doesn't have much time. I'll 
> see what I can do.

r2177 should fix the problem. It works for me with and without -wthread 
with both wx 2.6 and wx 2.8 on Windows.

Can you verify that the problem is indeed fixed?

Servus,
    Walter





From Glen.Mabey at swri.org  Sat Mar 24 17:33:41 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Sat, 24 Mar 2007 16:33:41 -0500
Subject: [IPython-dev] display of "[127.0.0.1:*] In [*]: " lines is delayed?
Message-ID: <20070324213341.GC17031@bams.ccf.swri.edu>

Hello,

In using ipython1 (with 4 engines running on a single machine) I have
been trying to look at the amount of time that each function executed on
the engines takes.

As my controlling script runs, I see lines like 

    [127.0.0.1:0] In [7]: 

printed out 4 times for each of the executeAll() calls I make.  However,
it seems that when one of them takes a long time to process, that while
it is running, it is the previous "In" statement that is currently
displayed at the terminal.  So, it looks like it is the previous
executeAll() call that is taking so long.

Is this consistent with what y'all have observed?

Thanks,
Glen



From fperez.net at gmail.com  Sun Mar 25 01:49:11 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 24 Mar 2007 23:49:11 -0600
Subject: [IPython-dev] igrid
In-Reply-To: <46058D23.4030709@livinglogic.de>
References: <45E847A8.2070006@livinglogic.de>
	<db6b5ecc0703100045o3bc3f87fv7e8fd121936575e6@mail.gmail.com>
	<45F2E185.3040901@livinglogic.de> <45F512C8.1080508@gmx.de>
	<db6b5ecc0703171811l16194fb7w1a181a19a87fbc58@mail.gmail.com>
	<45FE4B15.3050003@livinglogic.de> <45FEB43C.40407@livinglogic.de>
	<db6b5ecc0703200004s6a924bfbtfd2a8f9c9a5b696e@mail.gmail.com>
	<45FF9B8A.8040102@livinglogic.de> <46058D23.4030709@livinglogic.de>
Message-ID: <db6b5ecc0703242249h1f8f501bm95f0b86190b95125@mail.gmail.com>

On 3/24/07, Walter D?rwald <walter at livinglogic.de> wrote:
> Walter D?rwald wrote:
>
> > Fernando Perez wrote:
> >
> >> On 3/19/07, Walter D?rwald <walter at livinglogic.de> wrote:
> >>
> > [...]
> >>> One solution might be to only allow one igrid browser. The other would
> >>> probably be that all igrid browsers are frames in only one wx
> >>> application.
> >> I'll leave that decision up to you.  As long as we ship something that
> >> works correctly with wx 2.6 (which is what most distros still have
> >> officially), I trust you on the implementation choices.
> >
> > The second variant would be the better choice of course.
> >
> > Nik is currently preparing for exams, so he doesn't have much time. I'll
> > see what I can do.
>
> r2177 should fix the problem. It works for me with and without -wthread
> with both wx 2.6 and wx 2.8 on Windows.
>
> Can you verify that the problem is indeed fixed?

Looks good here, many thanks.  I'd say go ahead and close the ticket.

I saw a bit of strangeness in that the right-hand vertical scrollbar
sometimes seems to disappear; resizing the window makes it appear
again.  But I don't know if that's a problem with WX itself, I just
mention it in case you happen to know what's going on.

Cheers,

f


From fperez.net at gmail.com  Sun Mar 25 15:10:02 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 25 Mar 2007 13:10:02 -0600
Subject: [IPython-dev] New parsing bug in input
Message-ID: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>

Howdy,

I just ran into this:

In [1]: for i in range(3):

In [1]:     print i,

In [1]:
0 1 2


This is on my laptop, running r2177.  My office machine has r2169, and
it's fine.

Right now I don't have time to look into what's going on, and
unfortunately the Scipy.org servers seem to be down at the moment, so
we can't do a quick SVN history search or bisection.

But if anyone can find what happened here, please let me know; I'll be
back to work on this code probably tomorrow (today I'm busy with other
things).

Cheers,

f


From dfj225 at gmail.com  Mon Mar 26 10:05:51 2007
From: dfj225 at gmail.com (Doug Jones)
Date: Mon, 26 Mar 2007 10:05:51 -0400
Subject: [IPython-dev] ipython1 'saw' status
Message-ID: <1315be7e0703260705h6fdc5105s418398d5184afe3@mail.gmail.com>

Hello All,

I'm curious about the current status of the IPython1 'saw' branch. I
know that it was somewhat recently announced that development was
moving from the chainsaw to the saw branch and that users should begin
to move as well.

I've been trying to follow the list as well as the development of the
code, and it seems that much progress has been made, but the branch is
not yet stable. Is this an accurate assessment? What is the expected
time-line for this branch?

I'm asking because I'd like to move a project that I'm working on to
use the new branch, but I don't want to do that until the code is
stable enough that I won't need to keep adding major updates to our
local install.

Thank you, and keep up the good work.
~Doug


From danmil at comcast.net  Mon Mar 26 12:41:15 2007
From: danmil at comcast.net (Dan Milstein)
Date: Mon, 26 Mar 2007 12:41:15 -0400
Subject: [IPython-dev] ipython1 / python 2.3
Message-ID: <116AC355-D840-4D43-8E05-00DD3037029C@comcast.net>

Just an FYI -- ipython1 doesn't run on python 2.3.

Should it?

I just tried to install and then run it, and ran into the following  
issues, all of which require 2.4:

  1) tests/tutils.py assumes doctest has a DocTestParser class

  2) tools/utils.py uses a generator expression on l. 55:
     return dict((k,callerNS[k]) for k in names)

  3) ipcluster imports subprocess


There may be (many) more, but those were the ones which stopped me  
from getting it working even minimally.


Also, in case it fits into this question: I'm running OS X (10.4),  
and often use the python that comes bundled with it (2.3.5).  I *do*  
have 2.4 installed, but there are some nasty bits to getting that  
working which can make some things tricky.  For (a relevant) example:  
I've so far failed to get Zope Interfaces installed under 2.4,  
because of some strange compilation issue which I haven't had time to  
debug yet.

-Dan


From vivainio at gmail.com  Mon Mar 26 13:07:01 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 26 Mar 2007 19:07:01 +0200
Subject: [IPython-dev] New parsing bug in input
In-Reply-To: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>
References: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>
Message-ID: <46cb515a0703261007p7b466f80lbd786c1eaf0095e1@mail.gmail.com>

On 3/25/07, Fernando Perez <fperez.net at gmail.com> wrote:

> I just ran into this:
>
> In [1]: for i in range(3):
>
> In [1]:     print i,
>
> In [1]:
> 0 1 2
>
>
> This is on my laptop, running r2177.  My office machine has r2169, and
> it's fine.
>
> Right now I don't have time to look into what's going on, and
> unfortunately the Scipy.org servers seem to be down at the moment, so
> we can't do a quick SVN history search or bisection.

Does reverting

http://projects.scipy.org/ipython/ipython/changeset/2173

help?

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


From fperez.net at gmail.com  Tue Mar 27 01:41:58 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Mar 2007 23:41:58 -0600
Subject: [IPython-dev] New parsing bug in input
In-Reply-To: <46cb515a0703261007p7b466f80lbd786c1eaf0095e1@mail.gmail.com>
References: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>
	<46cb515a0703261007p7b466f80lbd786c1eaf0095e1@mail.gmail.com>
Message-ID: <db6b5ecc0703262241g4b5cb9d7h8f921df9fcf6910a@mail.gmail.com>

On 3/26/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> Does reverting
>
> http://projects.scipy.org/ipython/ipython/changeset/2173
>
> help?

Nope, I just did and it doesn't.

If you figure it out,  let me know.  I'll try to look into it
tomorrow, I had a crazy day today and just couldn't make a minute for
it.

Cheers,

f


From fperez.net at gmail.com  Tue Mar 27 01:48:52 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 26 Mar 2007 23:48:52 -0600
Subject: [IPython-dev] ipython1 / python 2.3
In-Reply-To: <116AC355-D840-4D43-8E05-00DD3037029C@comcast.net>
References: <116AC355-D840-4D43-8E05-00DD3037029C@comcast.net>
Message-ID: <db6b5ecc0703262248x5e634bafu55cb0f9de81c1498@mail.gmail.com>

On 3/26/07, Dan Milstein <danmil at comcast.net> wrote:
> Just an FYI -- ipython1 doesn't run on python 2.3.

Yup.

> Should it?

Well, we've more or less settled on using 2.4 for it.  I know Brian is
making more and more use of decorators for a number of things that are
making his life easier, so it's quite likely that 2.4 will remain a
'hard' requirement.  I guess if there's major demand for 2.3 support
we could look into it, since decorators are in the end 'just'
syntactic sugar.  But it's quite possible that the amount of retrofit
work needed becomes too much, in the face of already thinly-spread
developer resources.

There's the additional issue of testing: ubuntu Edgy doesn't even
/have/ an out of the box 2.3 python supplied, which for me would mean
building a separate 2.3 and surrounding support libraries by hand.
Doing so is trivial, but it's another time slot that I simply may not
have.  When deciding on where to spend some dev time, between working
on the code itself and doing 2.3 build work, I'm *very* likely to
ditch the 2.3 support.

Basically right now the situation is just one of developer resources:
I'd be happy supporting 2.3, but it's not likely to come from me.

For ipython trunk, we DO keep 2.3 as a supported version, and that
will continue to be true for 0.7.4 and a possible release after that.

Cheers,

f


From danmil at comcast.net  Tue Mar 27 09:48:37 2007
From: danmil at comcast.net (Dan Milstein)
Date: Tue, 27 Mar 2007 09:48:37 -0400
Subject: [IPython-dev] New parsing bug in input
In-Reply-To: <db6b5ecc0703262241g4b5cb9d7h8f921df9fcf6910a@mail.gmail.com>
References: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>
	<46cb515a0703261007p7b466f80lbd786c1eaf0095e1@mail.gmail.com>
	<db6b5ecc0703262241g4b5cb9d7h8f921df9fcf6910a@mail.gmail.com>
Message-ID: <12642C7F-EF4E-450C-BD0D-7F8AB93E3C3F@comcast.net>

I just checked out a fresh copy of IPython from svn (r. 2180), and I  
don't see that bug.

Specifically,  here's what I get:

In [1]: for i in range(3):
    ...:     print i,
    ...:
    ...:
0 1 2

In [2]:

Which is how it should be, right?

-Dan

On Mar 27, 2007, at 1:41 AM, Fernando Perez wrote:

> On 3/26/07, Ville M. Vainio <vivainio at gmail.com> wrote:
>
>> Does reverting
>>
>> http://projects.scipy.org/ipython/ipython/changeset/2173
>>
>> help?
>
> Nope, I just did and it doesn't.
>
> If you figure it out,  let me know.  I'll try to look into it
> tomorrow, I had a crazy day today and just couldn't make a minute for
> it.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From danmil at comcast.net  Tue Mar 27 09:56:12 2007
From: danmil at comcast.net (danmil at comcast.net)
Date: Tue, 27 Mar 2007 13:56:12 +0000
Subject: [IPython-dev] ipython1 / python 2.3
Message-ID: <032720071356.25752.4609227C000640AF000064982213575333040703020E0B@comcast.net>

This (requiring 2.4) seems totally reasonable to me.  I just got confused by some of the docs.

I'll go get those pesky Zope Interfaces working now...
-Dan

 -------------- Original message ----------------------
From: "Fernando Perez" <fperez.net at gmail.com>
> On 3/26/07, Dan Milstein <danmil at comcast.net> wrote:
> > Just an FYI -- ipython1 doesn't run on python 2.3.
> 
> Yup.
> 
> > Should it?
> 
> Well, we've more or less settled on using 2.4 for it.  I know Brian is
> making more and more use of decorators for a number of things that are
> making his life easier, so it's quite likely that 2.4 will remain a
> 'hard' requirement.  I guess if there's major demand for 2.3 support
> we could look into it, since decorators are in the end 'just'
> syntactic sugar.  But it's quite possible that the amount of retrofit
> work needed becomes too much, in the face of already thinly-spread
> developer resources.
> 
> There's the additional issue of testing: ubuntu Edgy doesn't even
> /have/ an out of the box 2.3 python supplied, which for me would mean
> building a separate 2.3 and surrounding support libraries by hand.
> Doing so is trivial, but it's another time slot that I simply may not
> have.  When deciding on where to spend some dev time, between working
> on the code itself and doing 2.3 build work, I'm *very* likely to
> ditch the 2.3 support.
> 
> Basically right now the situation is just one of developer resources:
> I'd be happy supporting 2.3, but it's not likely to come from me.
> 
> For ipython trunk, we DO keep 2.3 as a supported version, and that
> will continue to be true for 0.7.4 and a possible release after that.
> 
> Cheers,
> 
> f



From fperez.net at gmail.com  Tue Mar 27 12:11:06 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 27 Mar 2007 10:11:06 -0600
Subject: [IPython-dev] New parsing bug in input
In-Reply-To: <12642C7F-EF4E-450C-BD0D-7F8AB93E3C3F@comcast.net>
References: <db6b5ecc0703251210rec6f404o6f6e66e5f198acb4@mail.gmail.com>
	<46cb515a0703261007p7b466f80lbd786c1eaf0095e1@mail.gmail.com>
	<db6b5ecc0703262241g4b5cb9d7h8f921df9fcf6910a@mail.gmail.com>
	<12642C7F-EF4E-450C-BD0D-7F8AB93E3C3F@comcast.net>
Message-ID: <db6b5ecc0703270911m3fe8decct59c6a7c905a417ff@mail.gmail.com>

On 3/27/07, Dan Milstein <danmil at comcast.net> wrote:
> I just checked out a fresh copy of IPython from svn (r. 2180), and I
> don't see that bug.
>
> Specifically,  here's what I get:
>
> In [1]: for i in range(3):
>     ...:     print i,
>     ...:
>     ...:
> 0 1 2
>
> In [2]:
>
> Which is how it should be, right?

Yes.  I'd like to know who fixed it, though, because it wasn't me :)

Cheers,

f


From fperez.net at gmail.com  Fri Mar 30 02:02:38 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 Mar 2007 00:02:38 -0600
Subject: [IPython-dev] ipython1 'saw' status
In-Reply-To: <1315be7e0703260705h6fdc5105s418398d5184afe3@mail.gmail.com>
References: <1315be7e0703260705h6fdc5105s418398d5184afe3@mail.gmail.com>
Message-ID: <db6b5ecc0703292302y42a36ab5t502b7d161b7d39c5@mail.gmail.com>

Hi Doug,

sorry for the delayed reply...

On 3/26/07, Doug Jones <dfj225 at gmail.com> wrote:
> Hello All,
>
> I'm curious about the current status of the IPython1 'saw' branch. I
> know that it was somewhat recently announced that development was
> moving from the chainsaw to the saw branch and that users should begin
> to move as well.
>
> I've been trying to follow the list as well as the development of the
> code, and it seems that much progress has been made, but the branch is
> not yet stable. Is this an accurate assessment? What is the expected
> time-line for this branch?

Yes, that is an accurate assessment right now.  This is what the
current schedule, tentative as always and modulated by 'real life',
looks like:

- On Sunday, I plan on spending most of the day trying to flush out
the remaining tickets and items in my inbox related to trunk.  If all
goes well, we should soon have a release candidate for 0.7.4.

- In the meantime, Brian and Min have been working on the saw branch,
without me offering much more than design discussions but no real
code.  But they are making good progress.

- I'll leave it to Brian to announce when he considers saw to be a
semi-stable replacement for chainsaw (which is at least functionally
equivalent) but I imagine the timeline for that to be under 2 weeks.

- Until mid-April I won't do a whole lot in the way of IPython coding
because of a workshop I'm teaching:

<shameless plug>
If anyone is interested, John Hunter and I will be teaching a workshop
on the uses of Python for scientific computing at the Mathematics
department of U. Michigan at Ann Arbor.  More details here:
http://www.math.lsa.umich.edu/~albauer/pyworkshop.html
</shameless plug>

- With that out of the way, I'll shift my focus towards integrating,
as fast as I can, the trunk codebase with the work in the saw branch.
This should put us on the road towards ipython 1.0, will integrate the
capabilities of the full ipython with the distributed engine, etc.
We'll get a boost on that from a sprint held in Boulder (details in a
separate email) on April 28.

In summary, I'd say: mid-april for Brian and Min to stabilize saw a
bit (they'll correct me if I'm wrong), early May for me to move the
trunk codebase in there and join the fun :)

HTH,

f


From fperez.net at gmail.com  Fri Mar 30 02:06:39 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 Mar 2007 00:06:39 -0600
Subject: [IPython-dev] IPython sprint in Boulder, April 28
Message-ID: <db6b5ecc0703292306mca7c45vae77a543f4f989b@mail.gmail.com>

Hi all,

we wanted to let anyone who may be interested about the IPython coding
sprint we'll hold on April 28 in Boulder, Colorado, as part of the
regular activities of the Front Range Pythoneers group.

More details will be posted as we have them on the wiki:

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

Anyone is welcome to stop by, though we'd appreciate letting us know
so we can have a tentative head count in advance.  We'll set up an IRC
channel for those who may want to join in from other locations as
well.

Regards,

f


From fperez.net at gmail.com  Fri Mar 30 14:44:22 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 30 Mar 2007 12:44:22 -0600
Subject: [IPython-dev] The joys of Unicode... [was Re: weird ipython ansi
	codes]
Message-ID: <db6b5ecc0703301144t11fad757t7ff607b853c2fcdc@mail.gmail.com>

[ Redirecting to the list so that anyone who really knows about
unicode can pitch in with words of wisdom.

context: I've been steadily learning about unicode and improving our
support, but I'm terribly worried that I'm still missing cases.  In
particular, we use shlex.shlex() to parse magic input, and I'm not
really sure that function is unicode-safe.  Perhaps it *is* unicode
safe but it must be used in a particular way, I'm just not sure.
]


On 3/30/07, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hrm, I wonder what caused this behaviour?

Could you check with current SVN please?  I'm still worried that we're
missing other problem spots with unicode handling.  In particular, see
the genutils changes in:

http://projects.scipy.org/ipython/ipython/changeset/2190

the only change there is a comment to flag the possible problem.  This
is called by parse_options:

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/IPython/Magic.py?rev=2190#L330

I've fixed some magics that do python-only arguments to first do
.encode('ascii'), but I'm worried that magics for which unicode input
makes sense will explode when arg_split() is called and shlex messes
up the original input...

I wish I had a good test case to understand this problem in its entirety...

Cheers,

f