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 #40 from Maciej Fijalkowski fijall@gmail.com 2010-12-18 02:16:59 EST --- (In reply to comment #38)
(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.
well, it goes into "don't ship stuff in a way that does not work" 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?)
I don't think it's reasonable. People tinkering with pypy are very likely required to have a very recent HG checkout anyway and everything works from the checkout directory (as a source code, it doesn't require to be installed).
There are few tools that would use pypy as a module, but they're all fairly internal (like JIT trace viewer).
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.
Yop.
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.
That's really weird. We usually run this by py.test -A over the whole suite, however we have ways to invoke separate directories in separate test processes (reasons vary).
I'll look into having a way to run this in a simple manner, will get back later.
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!