[IPython-dev] IPython on PyPy
Sun Nov 21 11:34:16 CST 2010
On Fri, Nov 19, 2010 at 3:15 PM, Fernando Perez <firstname.lastname@example.org> wrote:
> Hi Alex,
> On Thu, Nov 18, 2010 at 10:03 AM, Alex Gaynor <email@example.com> wrote:
>> Hello all,
>> I've been spending the last couple of days working on getting IPython
>> working on PyPy. Most of this has been easy things like unimplemented
>> features in our readline module (such as get_line_buffer, get_endidx,
>> and insert_text), however now I'm facing some harder issues that I
>> could use some suggestions on. For reference our readline module
>> comes from pyrepl (http://codespeak.net/pyrepl/).
> Great news, thanks for working on this! Just so we know, are you
> working off of trunk (ipython/master) or from one of the older
> branches (0.10.x)?
I've been using .10.1 (what was installed with pip). Is master stable
enough that testing with it is a good idea?
>> 1) First when using Gnome Terminal I get some strange unicode
>> "artifacts": http://i.imgur.com/Vz9uw.png, this doesn't appear when
>> running IPython on CPython in GNOME terminal, nor does it appear with
>> pypy under xterm. I have no idea what causes this, any advice would
>> be great.
> Mmh, very strange. Those are the ansi escape sequences, which somehow
> are getting mangled up. They are defined in (on trunk, in the old
> branches the directory layout was different):
> As you see, those are all plain python strings (in the 2.x sense).
> It's possible that something is messing them up and adding weird
> encoding artifacts when treated as unicode, I don't know...
Yep, I suppose there's somehow a bug in our readline handling them,
but I'm not sure what, any idea how to debug that?
>> 2) When using <tab> to complete the current line gets swallowed up:
>> http://i.imgur.com/9ND2x.png. What was done was 1) `import sys` 2)
>> `sys.pyp<tab><tab>`. I assume this is either a bug in our readline or
>> in IPython, but I have no idea how to diagnose it.
> This may be related to problem #1. I suspect what's happening is that
> the line length calculation is being thrown off by the bogus data in
> the color ansi codes, and when readline rewrites the input line for
> the completion, it writes in the wrong part of the line. So I think
> fixing 1 will fix both.
>> One question I have is: is IPython's autocompletion stuff unittested
>> at all? Unfortunately our readline module isn't well tested at all
>> (especially compared to the rest of our code base).
> Minimally. We're doing better lately as we refactor things and make
> it less readline dependent, which is easier to unittest, but there's
> still a long way to go. Here's what we have so far:
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
More information about the IPython-dev