Mailman 3 August 2013 - pypy-issue

[issue1581] strptime does not like string_
by Wouter van Heyst Dec. 18, 2013

Dec. 18, 2013

New submission from Wouter van Heyst <wouter.pypy(a)richtlijn.be>: The attached code works with cpython but fails with pypy b9699dee6f10. Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "/tmp/bug.py", line 8, in <module> datetime.strptime(a[0], '%Y-%m-%d') File "/home/larstiq/src/pypy/lib_pypy/datetime.py", line 1701, in strptime struct, micros = _strptime(date_string, format) File "/home/larstiq/src/pypy/lib-python/2.7/_strptime.py", line 322, in _strptime found = format_regex.match(data_string) TypeError: unsupported operand type for buffer: 'string_' ---------- messages: 6054 nosy: larstiq, pypy-issue priority: bug status: unread title: strptime does not like string_ ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1581> ________________________________________

2 1

[issue1466] for slices, __array__interface['data'][0] yields adress of base object's data
by kfj Dec. 18, 2013

Dec. 18, 2013

New submission from kfj <_kfj(a)yahoo.com>: Here's what I observed: $ pypy Python 2.7.3 (aa7b56060ddd, Apr 22 2013, 22:03:12) [PyPy 2.0.0-beta2 with GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``PyPy 1.2 released - http://pypy.org/'' >>>> import numpypy as np >>>> a=np.zeros(10) >>>> a.__array_interface__['data'][0] -1220095968 >>>> a[2:].__array_interface__['data'][0] -1220095968 <<<<<<<< same value $ python Python 2.7.3 (default, Apr 10 2013, 05:46:21) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> a=np.zeros(10) >>> a.__array_interface__['data'][0] 162282152 >>> a[2:].__array_interface__['data'][0] 162282168 <<<<<<<<<<< different value ---------- nosy: +kfj status: unread -> chatting ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1466> ________________________________________

2 1

[issue918] implement numpy.matrix in micronumpy
by Peter Dec. 18, 2013

Dec. 18, 2013

New submission from Peter <p.j.a.cock(a)googlemail.com>: Following should work on any version of bumpy, here using 1.5.1 on Python 2.6 on Mac OS X, >>> import numpy >>> m = numpy.matrix([[1,0],[0,1]]) >>> m matrix([[1, 0], [0, 1]]) Fails on pypy 1.6, $ pypy Python 2.7.1 (dcae7aed462b, Aug 17 2011, 09:46:15) [PyPy 1.6.0 with GCC 4.0.1] on darwin Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``it's not a hack, it's a workaround'' >>>> import numpy >>>> m = numpy.matrix([[1,0],[0,1]]) Traceback (most recent call last): File "<console>", line 1, in <module> AttributeError: 'module' object has no attribute 'matrix' The matrix class is generally similar to a 2 dimensional array in numpy except that the * operator does matrix multiplication rather than element wise operation. This is particularly useful in teaching classes, even if many serious bumpy users prefer to avoid the matrix class and work with raw arrays and the dot method/function. ---------- messages: 3373 nosy: pypy-issue priority: bug release: 1.6 status: unread title: implement numpy.matrix in micronumpy ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue918> ________________________________________

3 3

[issue948] Low performance on Stackless PyPy compared to Stackless Python
by Carlos de Paula Nov. 18, 2013

Nov. 18, 2013

New submission from Carlos de Paula <carlosedp(a)gmail.com>: I tested the 1.7 release on Windows XP using some Stackless Python examples I have. Most of them worked fine, the only problem is that the performance when using Stackless is way slower than the 2.7.1 Stackless build from stackless.com Here is one example: Stackless Python 2.7.1 ---------------------- E:\Dev\Python\Scripts\Stackless>\Apps\stackless2.7\python.exe speed.py Started sleep for 5 seconds. Started sleep for 0.2 seconds. Started sleep for 2 seconds. Started sleep for 1 seconds. Started sleep for 3 seconds. 100000 operations took: 0.18700003624 seconds. Woke after 0.2 seconds. ( 0.203000068665 ) 200000 operations took: 0.344000101089 seconds. 300000 operations took: 0.5 seconds. 400000 operations took: 0.625 seconds. 500000 operations took: 0.733999967575 seconds. Woke after 1 seconds. ( 1.0 ) Woke after 2 seconds. ( 2.0 ) Woke after 3 seconds. ( 3.0 ) Woke after 5 seconds. ( 5.0 ) PyPy 1.7 -------- E:\Dev\Python\Scripts\Stackless>..\..\..\sandbox\pypy-1.7\pypy.exe speed.py Started sleep for 5 seconds. Started sleep for 0.2 seconds. Started sleep for 2 seconds. Started sleep for 1 seconds. Started sleep for 3 seconds. Woke after 0.2 seconds. ( 0.234999895096 ) Woke after 1 seconds. ( 1.0 ) Woke after 2 seconds. ( 2.0 ) Woke after 3 seconds. ( 3.0 ) Woke after 5 seconds. ( 5.0 ) 100000 operations took: 13.8280000687 seconds. 200000 operations took: 25.25 seconds. 300000 operations took: 34.3599998951 seconds. 400000 operations took: 41.2819998264 seconds. 500000 operations took: 46.015999794 seconds. The example used is attached as 'speed.py' Probably this is due to JIT being disabled when using Stackless features. Other than the performance, it's working fine with some examples I tested from: http://code.google.com/p/stacklessexamples/ ---------- files: speed.py messages: 3526 nosy: carlosedp, pypy-issue priority: performance bug status: unread title: Low performance on Stackless PyPy compared to Stackless Python ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue948> ________________________________________

1 1

[issue1441] version of sqlite3.dll (and others)
by Armin Rigo Nov. 14, 2013

Nov. 14, 2013

New submission from Armin Rigo <armin.rigo(a)gmail.com>: The nightly builder pick whatever version of sqlite3.dll (and others) that was installed locally, and package that. Someone reported in the blog's comments that it happens to be a very old version. We need a better way to control that. ---------- messages: 5546 nosy: arigo, pypy-issue priority: bug status: unread title: version of sqlite3.dll (and others) ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1441> ________________________________________

3 5

[issue1505] Removing multimethods slows the nojit case
by Armin Rigo Nov. 11, 2013

Nov. 11, 2013

New submission from Armin Rigo <armin.rigo(a)gmail.com>: Removing multimethods had a big performance hit on the no-jit case, sometimes. I suspect it can be fixed relatively easily. We *should* probably fix it. Revision 93322cb79586 (hg merge remove-list-smm-2) makes nbody_modified much slower; we can see that it makes this kind of code almost twice as slow: lst = [1.2, 3.4] for i in range(BIG): lst[1] = lst[1] + n Revision d1459869ce85 (Merge remove-array-smm branch that kills multimethods from the array module) makes crypto_pyaes.py much slower; not surprizingly, it uses array. "Much slower" is almost a factor two in both cases. ---------- messages: 5801 nosy: arigo, pypy-issue priority: performance bug status: unread title: Removing multimethods slows the nojit case ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1505> ________________________________________

2 3

[issue1495] Crash in JIT from Bitbucket latest (checkout of 5/24/2013 at 1pm PST)
by Ben Jolitz Nov. 11, 2013

Nov. 11, 2013

New submission from Ben Jolitz <ben.jolitz(a)gmail.com>: RPython traceback: File "rpython_jit_metainterp_pyjitpl.c", line 20079, in MIFrame_run_one_step File "rpython_jit_metainterp_pyjitpl_1.c", line 3376, in MIFrame_opimpl_jit_merge_point File "rpython_jit_metainterp_pyjitpl_1.c", line 34578, in MetaInterp_reached_loop_header File "rpython_jit_metainterp_pyjitpl_1.c", line 64302, in MetaInterp_compile_loop File "rpython_jit_metainterp_compile.c", line 14996, in compile_retrace Fatal RPython error: AssertionError Abort trap: 6 This is in a program that starts up seven threads of HTTPServer with the ThreadingMixin (mitmproxy) and shuts them down when a client dies. built as: python ../../rpython/bin/rpython -Ojit --gcrootfinder=shadowstack --make-jobs=7 targetpypystandalone.py --withmod-cpyext modules used: slimit, ply, pyOpenSSL (c-extension, built inside virtualenv with pypy), BeautifulSoup4. ---------- messages: 5757 nosy: benjolitz, pypy-issue priority: bug status: unread title: Crash in JIT from Bitbucket latest (checkout of 5/24/2013 at 1pm PST) ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1495> ________________________________________

2 6

[issue1569] PyArg_ParseTupleAndKeywords s# filling in incorrect size
by Damien Miller Nov. 11, 2013

Nov. 11, 2013

New submission from Damien Miller <djm(a)djm.net.au>: Hi, I just tried pypy (today head, JIT) for the first time and noticed that it compiles my py-bcrypt module but produces something that fails at runtime. To recreate the failure: PYPY=/tmp/pypy/pypy/goal/pypy-c # or whatever hg clone https://code.google.com/p/py-bcrypt/ cd py-bcrypt $PYPY setup.py build env PYTHONPATH=$PWD/build/lib.linux-x86_64-2.7/ $PYPY test/test.py It looks like "s#" arguments extracted by PyArg_ParseTupleAndKeywords() are not being filled in correctly. For example, in py-bcrypt/bcrypt/bcrypt_python.c:bcrypt_hashpw() with a password of "" the corresponding password_len ends up being set to -4294967296. I'm using Ubuntu Precise on x86_64. ---------- messages: 6013 nosy: djm, pypy-issue priority: bug status: unread title: PyArg_ParseTupleAndKeywords s# filling in incorrect size ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1569> ________________________________________

3 3

[issue1586] gc.collect doesn't take an argument
by Alex Gaynor Nov. 10, 2013

Nov. 10, 2013

New submission from Alex Gaynor <alex.gaynor(a)gmail.com>: It should take a single "generation" argument" http://docs.python.org/2/library/gc.html#gc.collect not sure what we should do with it though ---------- messages: 6074 nosy: agaynor, pypy-issue priority: bug status: unread title: gc.collect doesn't take an argument ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1586> ________________________________________

2 2

[issue1491] raw_input incorrectly places cursor when given escape sequences
by sn6uv Nov. 10, 2013

Nov. 10, 2013

New submission from sn6uv <16sn6uv(a)gmail.com>: Description: raw_input seems to include the length of ANSI escape sequences in the prompt when positioning the cursor. This does not seem to happen when running the command from a script, only when entered into the PyPy shell. The entered text in put in the right place only the cursor's position is wrong, which is a bit confusing Example: >>> raw_input('\033[31m>>> \033[39m') Screenshot (attached): http://imgur.com/nqOhvfM System Info: $pypy --version Python 2.7.3 (fcb6b056f00e33a72cba5e6769b253b839fe90bb, Nov 24 2012, 02:30:32) [PyPy 2.0.0-beta1 with GCC 4.7.2] $ uname -a Linux angus-laptop 3.6.7-1-ARCH #1 SMP PREEMPT Sun Nov 18 10:11:22 CET 2012 x86_64 GNU/Linux $ xterm -v XTerm(287) $ aterm --version 1.00.01 ---------- files: pypy_escapeseq_cursor_bug.png messages: 5747 nosy: pypy-issue, sn6uv priority: bug status: chatting title: raw_input incorrectly places cursor when given escape sequences ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1491> ________________________________________

2 3