Mailman 3 June 2011 - pypy-issue

[issue573] get_python_lib unconditionally fails when passing standard_lib
by Tom Burdick 08 Feb '13

08 Feb '13

New submission from Tom Burdick <thomas.burdick(a)gmail.com>: SSL module in pypi fails to install because of the error given in the title. ---------- effort: ??? messages: 1862 nosy: bfrog, pypy-issue priority: bug release: 1.4 status: unread title: get_python_lib unconditionally fails when passing standard_lib _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue573> _______________________________________________________

2 1

[issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB)
by Nirbheek Chauhan 15 Dec '12

15 Dec '12

New submission from Nirbheek Chauhan <nirbheek.chauhan(a)gmail.com>: While trying to lock a file with a pre-existing lock on it, lockf() doesn't raise EACCESS, and just silently returns instead. This behaviour is both wrong, and inconsistent with PyPy's flock() behaviour, and CPython's lockf() and flock() behaviour. The script attached should demonstrate the problem. Run it under CPython, and it'll exit fine, execute with PyPy, and it fails. Replace fcntl.lockf with fcntl.flock and it works fine again. ---------- files: test_lock_nonblock.py messages: 2621 nosy: nirbheek, pypy-issue priority: bug release: 1.5 status: unread title: fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB) ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue747> ________________________________________

5 7

[issue765] Fields get written on frame that is about to be dead
by Alex Gaynor 18 Oct '12

18 Oct '12

New submission from Alex Gaynor <alex.gaynor(a)gmail.com>: http://paste.pocoo.org/show/418371/ ---------- messages: 2677 nosy: agaynor, pypy-issue priority: feature status: unread title: Fields get written on frame that is about to be dead ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue765> ________________________________________

3 4

[issue703] Pypy runs slower that cpython in a function call cache
by Bouchard 18 Oct '12

18 Oct '12

New submission from Bouchard <guillaume.bouchard(a)liris.cnrs.fr>: The attached code works slowly on pypy1.5 than on python 3.2 This is my pypy version % 21:15 guillaume@guillaume-desktop ~/partitions pypy1.5 -V Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34) [PyPy 1.5.0-alpha0 with GCC 4.4.3] On a i7-950, I get the following time running this code with pypy and with python 3.2 Short process: $ time python3.2 partition.py 360 48 360 176175 python3.2 partition.py 360 48 360 0.55s user 0.02s system 99% cpu 0.575 total $ time pypy1.5 partition.py 360 48 360 176175 pypy1.5 partition.py 360 48 360 0.56s user 0.03s system 98% cpu 0.597 total Long process: $ time python3.2 partition.py 460 48 460 5611878 python3.2 partition.py 460 48 460 6.35s user 0.62s system 99% cpu 7.003 total $ time pypy1.5 partition.py 460 48 460 5611878 pypy1.5 partition.py 460 48 460 8.45s user 0.61s system 99% cpu 9.091 total Funny fact, if you remove the lru_cache (just comment out the decorator line 35), pypy run dramatically quicker (~10 times) than python 3.2 Without the lru_cache : $ time python3.2 partition.py 360 48 360 176175 python3.2 partition.py 360 48 360 3.24s user 0.01s system 99% cpu 3.262 total $ time pypy1.5 partition.py 360 48 360 176175 ~/src/pypy/pypy-1.5/bin/pypy partition.py 360 48 360 0.28s user 0.04s system 99% cpu 0.322 total So I *guess* the issue may be in how the jit behave with the lru_cache function. ---------- effort: ??? files: partition.py messages: 2446 nosy: guibou, pypy-issue priority: bug release: ??? status: unread title: Pypy runs slower that cpython in a function call cache _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue703> _______________________________________________________

2 1

[issue551] Support for freebsd8+
by David Naylor 18 Oct '12

18 Oct '12

New submission from David Naylor <naylor.b.david(a)gmail.com>: Add support for compiling on freebsd[89]. This is only on the pypy side, the python libs included with pypy do not support freebsd8+. It should be fairly easy to import the required code from upstream. I'm currently tested this with a build on FreeBSD9/amd64. Will follow up if the build fails. Regards ---------- effort: easy files: patch-pypy2.diff messages: 1797 nosy: DragonSA, pypy-issue priority: bug release: ??? status: unread title: Support for freebsd8+ _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue551> _______________________________________________________

2 1

[issue741] nightly build for windows
by Jose Antonio Martin H. 08 Jun '12

08 Jun '12

New submission from Jose Antonio Martin H. <jamartinh(a)fdi.ucm.es>: Please, I want an updated build for windows,there are many bugs that have been corrected since the last windows build. ---------- messages: 2606 nosy: jamartinh, pypy-issue priority: wish status: unread title: nightly build for windows ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue741> ________________________________________

2 2

[issue674] sysconfig.get_config_var("CC")
by ys 23 Apr '12

23 Apr '12

New submission from ys <ysbalt(a)live.com>: I am using the near-tip version of pypy on OSX. I am trying to install other modules in pypy. The setup file relies on distutils.sysconfig.get_config_var("CC"), which returns None. How can this be added to pypy. To reproduce, in pypy-c: $ pypy-c >>>> import distutils.sysconfig >>>> distutils.sysconfig.get_config_var("CC") >>>> distutils.sysconfig.get_config_var("CC") == None True >>>> distutils.sysconfig.get_config_vars() {'EXE': '', 'SO': '.pypy-14.so', 'SOABI': ''} ---------- effort: ??? messages: 2308 nosy: baltcode, pypy-issue priority: bug release: ??? status: unread title: sysconfig.get_config_var("CC") _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue674> _______________________________________________________

2 1

[issue587] Plain 'strip' in package.py breaks cpyext on Mac OS X
by Dan Villiom Podlaski Christiansen 16 Feb '12

16 Feb '12

New submission from Dan Villiom Podlaski Christiansen <danchr(a)gmail.com>: On Mac OS X, without arguments will strip *all* symbols from the binary. The attached patch changes package.py to use 'strip -x' instead, which will only strip global symbols. ---------- effort: easy files: strip-x.diff messages: 1917 nosy: danchr, pypy-issue priority: bug release: 1.4 status: unread title: Plain 'strip' in package.py breaks cpyext on Mac OS X _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue587> _______________________________________________________

2 1

[issue614] Packaging PyPy: installation path for PyPy's libraries
by Dave Malcolm 06 Feb '12

06 Feb '12

New submission from Dave Malcolm <dmalcolm(a)redhat.com>: Short version: I'm working on packaging PyPy in RPM form for Fedora; see: https://bugzilla.redhat.com/show_bug.cgi?id=588941 and ran into an issue with how the pypy binary searches for its libraries. I'm attaching a patch I've written that fixes things, though it's not good enough yet to be applied to hg. Long version: As I understand things, PyPy's prebuilt tarballs have a directory structure generated by pypy/tool/release/package.py. Looking at e.g. http://pypy.org/download/pypy-1.4.1-linux64.tar.bz2 everything is below: pypy-1.4.1-linux64/ with: pypy-1.4.1-linux64/lib_pypy/ pypy-1.4.1-linux64/lib-python/ pypy-1.4.1-linux64/lib-python/2.5.2/*.py (and subdirs) pypy-1.4.1-linux64/lib-python/modified-2.5.2/*.py (and subdirs) pypy-1.4.1-linux64/site-packages/*.py pypy-1.4.1-linux64/bin/pypy (the JIT binary) pypy-1.4.1-linux64/include/ (some header files) (See also pypy/tool/release/test/test_package.py, which verifies this structure) This works for a standalone distribution of PyPy. However, eventually Linux distribution will want to ship "system" builds of PyPy, deployed as .rpmor .deb packages. Those packages ideally ought to follow the layout recommendations of the Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ In particular this suggests separating out programs (to /usr/bin) from libraries (to /usr/lib) and data (/usr/share). Exactly where the pypy libraries should go is debatable; they're all architecture- independent for now, but I hope we'll soon have a rich collection of extension modules that are stable enough to package. So I'm attempting to split the libraries out to /usr/lib (and /usr/lib64 on 64-bit, which is a Fedora-ism, AIUI). My naive attempt to do this leads to a /usr/bin/pypy which emits this message at startup: $ pypy-jit debug: WARNING: library path not found, using compiled-in sys.path 'import site' failed Python 2.5.2 (78826, Dec 15 2010, 01:41:24) [PyPy 1.4.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. debug: OperationError: debug: operror-type: ImportError debug: operror-value: No module named _pypy_interact and has this sys.path: $ pypy -c 'import sys; print sys.path' debug: WARNING: library path not found, using compiled-in sys.path 'import site' failed ['', '/builddir/build/BUILD/pypy-1.4/lib_pypy', '/builddir/build/BUILD/pypy-1.4/lib-python/modified-2.5.2', '/builddir/build/BUILD/pypy-1.4/lib-python/2.5.2', '/builddir/build/BUILD/pypy-1.4/lib-python/2.5.2/plat-linux2'] pypy/translator/goal/app_main.py's startup code calls into sys's state.py, which has: def getinitialpath(prefix): which searches for the dirs, raising OSError if they're not found. If they're all their, it returns them in a list. app_main wraps this as sys.pypy_initial_path, turning OSError into a return of None. I'm attaching a proof-of-concept patch which adds an initial search for the directory structure, this time within LIBRARY_INSTALLATION_PATH. Ideally this would be an optional, configuration-supplied constant, but for now, this is a non-existant variable, which I pre-process within the build, using sed, thus: sed -i \ -e 's|LIBRARY_INSTALLATION_PATH|"%{pypyprefix}"|' \ pypy/translator/goal/app_main.py where %{pypyprefix} is expanded by another tool, giving the string literal "/usr/lib64/pypy-1.4.1" I wanted to prove the concept, and hour-long builds make for tedious experimentation :( Presumably this should be something like a: --library-installation-path=/usr/lib that gets passed to the translate.py Building with this patch (with the above caveat), I obtain a binary that, when copied to /usr/bin/pypy, successfully finds its libraries within our downstream distribution's directory structure (under /usr/lib64/pypy-1.4.1 on this build): $ pypy Python 2.5.2 (, Dec 22 2010, 23:14:02) [PyPy 1.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``PyPy is an exciting technology that lets you to write fast, portable, multi-platform interpreters with less effort'' >>>> import sys >>>> sys.path ['', '/usr/lib64/pypy-1.4.1/lib_pypy', '/usr/lib64/pypy-1.4.1/lib-python/modified- 2.5.2', '/usr/lib64/pypy-1.4.1/lib-python/2.5.2', '/usr/lib64/pypy-1.4.1/lib- python/2.5.2/plat-linux2', '/usr/lib64/pypy-1.4.1/site-packages'] and also successfully finds its libraries within the build tree, when run from there in the usual "goal" subdirectory. >>>> import collections >>>> collections.__file__ '/usr/lib64/pypy-1.4.1/lib_pypy/collections.pyc' ---------- effort: ??? files: pypy-1.4.1-add-LIBRARY_INSTALLATION_PATH.patch messages: 2031 nosy: dmalcolm, pypy-issue priority: feature release: ??? status: unread title: Packaging PyPy: installation path for PyPy's libraries _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue614> _______________________________________________________

4 5

[issue738] utcfromtimestamp handles time before the epoch differently in pypy and cpython
by behackett 22 Jan '12

22 Jan '12

New submission from behackett <bernie(a)10gen.com>: pypy 1.5: >>>> datetime.datetime.utcfromtimestamp(-62135593139.0) datetime.datetime(1, 1, 1, 1, 1) cpython 2.7: >>> datetime.datetime.utcfromtimestamp(-62135593139.0) datetime.datetime(1, 1, 1, 1, 1, 1) ---------- messages: 2600 nosy: behackett, pypy-issue priority: bug status: unread title: utcfromtimestamp handles time before the epoch differently in pypy and cpython ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue738> ________________________________________

2 1