[Bug 588941] Review Request: pypy - Implementation of the Python language, using Python itself

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=588941

--- Comment #38 from Dave Malcolm <dmalcolm at redhat.com> 2010-12-17 17:19:47 EST ---
(In reply to comment #37)
> Sure they are. However, they're not needed (or even advised) for the binary
> build. If you're going to remove them for whatever reason (like policy), please
> also remove translator/jvm as it makes no longer sense.
Sure, if you like, though that goes beyond the requirements of our "no bundled
binaries" policy.

A somewhat-related question about the pypy sources: it looks like the pypy
module hierarchy is useful outside of building pypy itself.  If so, is it
reasonable to make the pypy module be available to the system CPython, by
installing it to, say, /usr/lib/python2.7/site-packages/pypy ?  (and shipping
that module hierarchy within, say, a "python-pypy" subpackage?)

That way you'd be able to "import pypy" from the system CPython, and e.g.
invoke the translator on other python code (provided that code was sufficiently
RPythonic, as I understand it).

If we did that, it only seems fair to also install it below pypy's
site-packages, and ship that within a "pypy-pypy" subpackage :)  (my hope is to
eventually build out a parallel-installable family of pypy-* rpms, mirroring
our python-* rpms)


> What's necessary however for a binary to run is listed by
> pypy/tool/release/package.py in source. If this file seems confusing, it's
> essentially what is present in our nightly runs (with rules how it got created
> listed in package.py, I can elaborate if needed).
Thanks.  I looked briefly through this script: it looks like it's what you use
to make the tarballs.


> PyPy contains lots of stuff and not all of it is necessary for a C/POSIX build
> (but most of it is). If I may ask, is it possible to run the test suite after
> the build to check if stuff actually worked (If so, I can provide more
> information how to actually run this)?
I'd actually started doing this, and ran into some problems, so more
information would be v. useful.

Specifically, I tried putting the built binary through the Python test suite
using:
     ./pypy -m test.regrtest 
from the build's "translator/goal" directory.

I saw a hang in test_asynchat, so I switched to:
     ./pypy -m test.regrtest -x test_asynchat

Various minor failures scroll by, but then I started running into intermittent
segfaults, towards the "s" part of the alphabet (e.g. test_scope, test_shelve,
test_sqlite), which go away when running the tests by themselves.  This makes
me think that there's some kind of state buildup over the course of running the
full test suite.

Unfortunately I wasn't able to get meaningful information out of gdb for these
crashes.

I tried without JIT, by using
  --jit threshold=-1
but this did not fix these segfaults.

I then tried running the whole thing under valgrind, seeing lots of interesting
warnings, so I switched to just launching the interactive interpreter under
valgrind:
  $ valgrind --track-origins=yes --leak-check=full ./pypy --jit threshold=-1
and I see various warnings; I'll attach them to bugzilla (this comment is
getting far too long as is).

There's also the test suite for pypy's modules, is that "just" a case of
running:
  python test_all.py
from the pypy subdirectory?

Thanks!

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.