[IPython-dev] IPython on PyPy
Fri Nov 19 14:15:08 CST 2010
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
> 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...
> 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:
More information about the IPython-dev