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@xxxxxxxxx> 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! -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review