From issues-reply at bitbucket.org Fri Aug 1 10:54:19 2014 From: issues-reply at bitbucket.org (Edd Barrett) Date: Fri, 01 Aug 2014 08:54:19 -0000 Subject: [pypy-issue] Issue #1832: Another misleading RPython error (pypy/pypy) Message-ID: <20140801085419.709.33731@app12.ash-private.bitbucket.org> New issue 1832: Another misleading RPython error https://bitbucket.org/pypy/pypy/issue/1832/another-misleading-rpython-error Edd Barrett: Hi, The following (artificially produced) error is misleading: ``` [translation:ERROR] TyperError: the following functions: [translation:ERROR] (hippy.interpreter:142)W_Globals._setitem_str [translation:ERROR] (hippy.module.pypy_bridge.php_wrappers:201)W_PyBridgeListProxy._setitem_str [translation:ERROR] (hippy.module.pypy_bridge.php_wrappers:289)W_PyBridgeDictProxy._setitem_str [translation:ERROR] (hippy.objects.arrayobject:269)W_ArrayObject._setitem_str [translation:ERROR] (hippy.objects.arrayobject:488)W_ListArrayObject._setitem_str [translation:ERROR] (hippy.objects.arrayobject:674)W_RDictArrayObject._setitem_str [translation:ERROR] are called with inconsistent numbers of arguments [translation:ERROR] sometimes with 3 arguments, sometimes with 4 [translation:ERROR] the callers of these functions are: [translation:ERROR] (hippy.interpreter:131)W_Globals.get_var [translation:ERROR] (hippy.objects.arrayobject:203)W_ArrayObject.setitem2_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:215)W_ArrayObject._setitem_ref [translation:ERROR] (hippy.objects.arrayobject:232)W_ArrayObject.packitem_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:501)W_ListArrayObject._convert_and_setitem_str [translation:ERROR] (hippy.objects.arrayobject:671)W_RDictArrayObject._setitem_int [translation:ERROR] the following functions: [translation:ERROR] (hippy.interpreter:142)W_Globals._setitem_str [translation:ERROR] (hippy.objects.arrayobject:674)W_RDictArrayObject._setitem_str [translation:ERROR] are called with inconsistent numbers of arguments [translation:ERROR] sometimes with 3 arguments, sometimes with 5 [translation:ERROR] the callers of these functions are: [translation:ERROR] (hippy.interpreter:131)W_Globals.get_var [translation:ERROR] (hippy.objects.arrayobject:203)W_ArrayObject.setitem2_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:215)W_ArrayObject._setitem_ref [translation:ERROR] (hippy.objects.arrayobject:232)W_ArrayObject.packitem_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:501)W_ListArrayObject._convert_and_setitem_str [translation:ERROR] (hippy.objects.arrayobject:671)W_RDictArrayObject._setitem_int [translation:ERROR] the following functions: [translation:ERROR] (hippy.interpreter:142)W_Globals._setitem_str [translation:ERROR] (hippy.module.pypy_bridge.php_wrappers:201)W_PyBridgeListProxy._setitem_str [translation:ERROR] (hippy.module.pypy_bridge.php_wrappers:289)W_PyBridgeDictProxy._setitem_str [translation:ERROR] (hippy.objects.arrayobject:269)W_ArrayObject._setitem_str [translation:ERROR] (hippy.objects.arrayobject:488)W_ListArrayObject._setitem_str [translation:ERROR] (hippy.objects.arrayobject:674)W_RDictArrayObject._setitem_str [translation:ERROR] are called with inconsistent numbers of arguments [translation:ERROR] sometimes with 4 arguments, sometimes with 5 [translation:ERROR] the callers of these functions are: [translation:ERROR] (hippy.interpreter:131)W_Globals.get_var [translation:ERROR] (hippy.objects.arrayobject:203)W_ArrayObject.setitem2_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:215)W_ArrayObject._setitem_ref [translation:ERROR] (hippy.objects.arrayobject:232)W_ArrayObject.packitem_maybe_inplace [translation:ERROR] (hippy.objects.arrayobject:501)W_ListArrayObject._convert_and_setitem_str [translation:ERROR] (hippy.objects.arrayobject:671)W_RDictArrayObject._setitem_int ``` The problem has nothing to do with the number of arguments being passed. Rather, it is the name of the arguments that must match those of the superclass. In the superclass `W_ArrayObject` we have: ``` def _setitem_str(self, key, w_value, as_ref, unique_array=False, unique_item=False): ``` Whereas in the subclass `W_PyBridgeDictProxy` we have: ``` def _setitem_str(self, bogus, w_value, as_ref, unique_array=False, unique_item=False): ``` Here `key != bogus` and this is the source of the crash, not # of arguments. Is it possible to show a better message? From issues-reply at bitbucket.org Fri Aug 1 11:25:39 2014 From: issues-reply at bitbucket.org (Konstantin Lopuhin) Date: Fri, 01 Aug 2014 09:25:39 -0000 Subject: [pypy-issue] Issue #1833: PyPy sandbox leaks when writing to stdout (pypy/pypy) Message-ID: <20140801092539.10362.34403@app09.ash-private.bitbucket.org> New issue 1833: PyPy sandbox leaks when writing to stdout https://bitbucket.org/pypy/pypy/issue/1833/pypy-sandbox-leaks-when-writing-to-stdout Konstantin Lopuhin: Here is etl.py: ``` #!python import sys def main(): for i in xrange(100000): sys.stdout.write('%d\n' % i) if __name__ == '__main__': main() ``` I run it like this: ``` sandbox $ /usr/bin/time -l ./pypy_interact.py --tmp=. ../goal/pypy-c /tmp/etl.py > /dev/null 'import site' failed 6.50 real 5.33 user 1.56 sys 422952960 maximum resident set size ... ``` A slighly more complex example (that also reads from stdin) leaks twice as much: gen.py: ``` #!python import sys for i in xrange(100000): sys.stdout.write('%d\n' % i) ``` etl.py ``` #!python import sys def main(): while True: line = sys.stdin.readline() if line: line = line.strip() sys.stdout.write('%d\n' % (int(line) + 1,)) else: break if __name__ == '__main__': main() ``` Run: ``` sandbox $ python gen.py | /usr/bin/time -l ./pypy_interact.py --tmp=. ../goal/pypy-c /tmp/etl.py > /dev/null 'import site' failed 14.69 real 12.35 user 3.20 sys 835825664 maximum resident set size ``` From issues-reply at bitbucket.org Sat Aug 2 17:38:31 2014 From: issues-reply at bitbucket.org (eli.boyarski) Date: Sat, 02 Aug 2014 15:38:31 -0000 Subject: [pypy-issue] Issue #1834: Some _tkinter functions that are available on CPython aren't exported (pypy/pypy) Message-ID: <20140802153831.27190.35657@app12.ash-private.bitbucket.org> New issue 1834: Some _tkinter functions that are available on CPython aren't exported https://bitbucket.org/pypy/pypy/issue/1834/some-_tkinter-functions-that-are-available eli.boyarski: On CPython 2.7.5, the exported names from Tkinter._tkinter are: ``` #!python >>> dir(Tkinter._tkinter) ['ALL_EVENTS', 'DONT_WAIT', 'EXCEPTION', 'FILE_EVENTS', 'IDLE_EVENTS', 'READABLE', 'TCL_VERSION', 'TIMER_EVENTS', 'TK_VERSION', 'TclError', 'Tcl_Obj', 'TkappType', 'TkttType', 'WINDOW_EVENTS', 'WRITABLE', '__doc__', '__file__', '__name__', '__package__', '_flatten', 'create', 'createfilehandler', 'createtimerhandler', 'deletefilehandler', 'dooneevent', 'getbusywaitinterval', 'mainloop', 'quit', 'setbusywaitinterval'] ``` Whlie on Pypy 2.2.1 we get: ``` #!python >>>> dir(Tkinter._tkinter) ['DONT_WAIT', 'EXCEPTION', 'READABLE', 'TCL_VERSION', 'TK_VERSION', 'TclError', 'TkApp', 'WRITABLE', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', '_flatten', 'app', 'cffi', 'create', 'createfilehandler', 'deletefilehandler', 'tclobj', 'tkffi', 'tklib'] ``` Notice dooneevent is missing, for example. There's a Python 2.X pattern of using dooneevent directly, as can be seen [here](https://s3-us-west-2.amazonaws.com/cs188websitecontent/projects/reinforcement/docs/graphicsUtils.html), which is part of [this project](http://inst.eecs.berkeley.edu/~cs188/pacman/html/navigation.html?page=overview). Adding the line: ``` #!python dooneevent = tklib.Tcl_DoOneEvent ``` to lib_pypy/\_tkinter/\_\_init\_\_.py enabled running the code, as ``` #!python int Tcl_DoOneEvent(int flags); ``` appears in lib_pypy/_tkinter/tklib.py. It's worth mentioning that dooneevent isn't exported from tkinter._tkinter in CPython 3.3.2, so the fix might not be very long lived. From issues-reply at bitbucket.org Sat Aug 2 19:11:46 2014 From: issues-reply at bitbucket.org (Martin Matusiak) Date: Sat, 02 Aug 2014 17:11:46 -0000 Subject: [pypy-issue] Issue #1835: py3.3: dir(None) gives TypeError (pypy/pypy) Message-ID: <20140802171146.17523.56756@app05.ash-private.bitbucket.org> New issue 1835: py3.3: dir(None) gives TypeError https://bitbucket.org/pypy/pypy/issue/1835/py33-dir-none-gives-typeerror Martin Matusiak: As seen here (even though the cause is not obvious from the output): http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy-c-app-level-linux-x86-64&build=2379&mod=lib-python.3.test.test_unittest First, a couple of checks: ``` #!python >>>> isinstance(None, object) True >>>> None.__dir__() ['__str__', '__getattribute__', '__lt__', '__init__', '__setattr__', '__reduce_ex__', '__new__', '__format__', '__class__', '__doc__', '__ne__', '__reduce__', '__subclasshook__', '__gt__', '__bool__', '__eq__', '__dir__', '__delattr__', '__le__', '__repr__', '__hash__', '__ge__'] >>>> object.__dir__() Traceback (application-level): File "", line 1 in object.__dir__() TypeError: __dir__() takes exactly 1 argument (0 given) >>>> dir(None) Traceback (application-level): File "", line 1 in dir(None) TypeError: __dir__() takes exactly 1 argument (0 given) ``` Ok, so calling __dir__ directly on None works, but when called through dir() it has the effect of calling object.__dir__ without arguments. The incantation looks like this: ``` #!python dir_meth = lookup_special(obj, "__dir__") if dir_meth is not None: result = dir_meth() # object: > # None: ``` When called on object, dir_meth is a bound method. When called on None, it's just a function, why is that? lookup_special: ``` #!python w_descr = space.lookup(w_obj, meth) if w_descr is None: return space.w_None return space.get(w_descr, w_obj) ``` So: use the wrapped object to find the descriptor, then use the descriptor to get a method. From issues-reply at bitbucket.org Sat Aug 2 23:36:06 2014 From: issues-reply at bitbucket.org (Martin Matusiak) Date: Sat, 02 Aug 2014 21:36:06 -0000 Subject: [pypy-issue] Issue #1836: Unwrapped use of LONGLONG_MASK breaks translation on x86 (pypy/pypy) Message-ID: <20140802213606.28622.50973@app06.ash-private.bitbucket.org> New issue 1836: Unwrapped use of LONGLONG_MASK breaks translation on x86 https://bitbucket.org/pypy/pypy/issue/1836/unwrapped-use-of-longlong_mask-breaks Martin Matusiak: ``` #!python [translation:info] File "/home/alex/inspect/pypy-mine/rpython/annotator/bookkeeper.py", line 231, in immutablevalue [translation:info] raise Exception("seeing a prebuilt long (value %s)" % hex(x)) [translation:ERROR] Exception: seeing a prebuilt long (value 0xffffffffffffffffL) [translation:ERROR] Processing block: [translation:ERROR] block at 76 is a [translation:ERROR] in (pypy.module._lzma.interp_lzma:274)descr_new_dec [translation:ERROR] containing the following operations: [translation:ERROR] v498 = simple_call((type r_ulonglong), (18446744073709551615L)) ``` The constant should be wrapped at module level. From issues-reply at bitbucket.org Wed Aug 6 09:52:39 2014 From: issues-reply at bitbucket.org (Armin Rigo) Date: Wed, 06 Aug 2014 07:52:39 -0000 Subject: [pypy-issue] Issue #1837: test_multiprocessing on OS/X leaves hanged processes behind (pypy/pypy) Message-ID: <20140806075239.13352.44976@app13.ash-private.bitbucket.org> New issue 1837: test_multiprocessing on OS/X leaves hanged processes behind https://bitbucket.org/pypy/pypy/issue/1837/test_multiprocessing-on-os-x-leaves-hanged Armin Rigo: test_multiprocessing.py works on OS/X, but it is reported to leave behind hanged subprocesses. It doesn't seem to occur on Linux. Investigate. From issues-reply at bitbucket.org Fri Aug 8 16:27:27 2014 From: issues-reply at bitbucket.org (Dimitri Vorona) Date: Fri, 08 Aug 2014 14:27:27 -0000 Subject: [pypy-issue] Issue #1838: Can't install ipython on pypy3 (pypy/pypy) Message-ID: <20140808142727.5764.27252@app07.ash-private.bitbucket.org> New issue 1838: Can't install ipython on pypy3 https://bitbucket.org/pypy/pypy/issue/1838/cant-install-ipython-on-pypy3 Dimitri Vorona: To reproduce 1. Download pypy3 2.3.1 from https://bitbucket.org/pypy/pypy/downloads/pypy3-2.3.1-linux64.tar.bz2 and extract it 2. Create virtual environment with pypy executable 3. run pip install ipython (alternatively easy_install ipython) Output: RPython traceback: ... Fatal RPython error: KeyError [1] 17991 abort (core dumped) pip install ipython My system: LinuxMint 17, Kernel 3.15 mainline If additional information is required, please tell. From issues-reply at bitbucket.org Sat Aug 9 08:24:58 2014 From: issues-reply at bitbucket.org (Franklin Lee) Date: Sat, 09 Aug 2014 06:24:58 -0000 Subject: [pypy-issue] Issue #1839: xml.etree.ElementTree relatively slow (pypy/pypy) Message-ID: <20140809062458.24117.64360@app04.ash-private.bitbucket.org> New issue 1839: xml.etree.ElementTree relatively slow https://bitbucket.org/pypy/pypy/issue/1839/xmletreeelementtree-relatively-slow Franklin Lee: I have a 46MB XML file. I parsed it with xml.etree.ElementTree, using CPython, PyPy, 2, and 3. Here's the code. ``` #!python import sys import os from xml.etree import ElementTree as ET from datetime import datetime fpath = os.path.join(os.getenv('appdata'), 'cbloader', 'combined.dnd40') os.path.exists(fpath) start = datetime.now() tree = ET.parse(fpath) root = tree.getroot() end = datetime.now() print (end - start) ``` Rough times (not rigorous): - CPython 2: 25-30 seconds - CPython 3: 4-5 seconds - PyPy2: 11 seconds - PyPy3: 11 seconds Some stats on the XML file (since I have no right to distribute it, I think): - 46.8MB - 541228 nodes - Height of 3 - Root has 38125 children - Biggest text node: 12590 From issues-reply at bitbucket.org Sun Aug 10 09:02:26 2014 From: issues-reply at bitbucket.org (anatoly techtonik) Date: Sun, 10 Aug 2014 07:02:26 -0000 Subject: [pypy-issue] Issue #1840: where to submit docs fixes? (pypy/pypy) Message-ID: <20140810070226.15375.72321@app03.ash-private.bitbucket.org> New issue 1840: where to submit docs fixes? https://bitbucket.org/pypy/pypy/issue/1840/where-to-submit-docs-fixes anatoly techtonik: Information in `improve-docs` seems more fresh, so edits with main one starts to come into conflict. Why it is not merged? What branch to edit? >From https://bitbucket.org/pypy/pypy/pull-request/241/docs-rewrite-objspace-intro/activity From issues-reply at bitbucket.org Sun Aug 10 18:17:22 2014 From: issues-reply at bitbucket.org (Maciej Fijalkowski) Date: Sun, 10 Aug 2014 16:17:22 -0000 Subject: [pypy-issue] Issue #1841: Signal check only in JUMP_ABSOLUTE when jitted (pypy/pypy) Message-ID: <20140810161722.27424.54229@app12.ash-private.bitbucket.org> New issue 1841: Signal check only in JUMP_ABSOLUTE when jitted https://bitbucket.org/pypy/pypy/issue/1841/signal-check-only-in-jump_absolute-when Maciej Fijalkowski: Here is an example that's not interruptable: def f(n): if n: f(n - 1) f(n - 1) f(15) print "x" f(50) The problem is that when jitted we only put signal check in JUMP_ABSOLUTE bytecode which does not exist in recursion. From issues-reply at bitbucket.org Sun Aug 10 19:21:48 2014 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sun, 10 Aug 2014 17:21:48 -0000 Subject: [pypy-issue] Issue #1842: select.select([out-of-range]) dumps core (pypy/pypy) Message-ID: <20140810172148.23138.96466@app09.ash-private.bitbucket.org> New issue 1842: select.select([out-of-range]) dumps core https://bitbucket.org/pypy/pypy/issue/1842/selectselect-out-of-range-dumps-core Armin Rigo: This code dumps core in PyPy (in CPython it gives a clear ValueError): select.select([123456], [] ,[]) From issues-reply at bitbucket.org Tue Aug 12 09:38:45 2014 From: issues-reply at bitbucket.org (Armin Rigo) Date: Tue, 12 Aug 2014 07:38:45 -0000 Subject: [pypy-issue] Issue #1843: Repeated string concatenation performance (pypy/pypy) Message-ID: <20140812073845.10377.22105@app13.ash-private.bitbucket.org> New issue 1843: Repeated string concatenation performance https://bitbucket.org/pypy/pypy/issue/1843/repeated-string-concatenation-performance Armin Rigo: The following is clearly a bogus example, doing precisely what we should not do to concatenate a large list of small strings. However, it is written in such a way that CPython's optimization doesn't work. Nevertheless, CPython runs in 4.5 seconds but PyPy takes 24.6 seconds, which is more than 5x slower. lst = ["xy"] * 200000 def f(): y = '' for x in lst: y += x z = y f() From issues-reply at bitbucket.org Thu Aug 14 15:43:49 2014 From: issues-reply at bitbucket.org (Alexander Schepanovski) Date: Thu, 14 Aug 2014 13:43:49 -0000 Subject: [pypy-issue] Issue #1844: MemoryError in pypy3 (pypy/pypy) Message-ID: <20140814134349.7626.39489@app08.ash-private.bitbucket.org> New issue 1844: MemoryError in pypy3 https://bitbucket.org/pypy/pypy/issue/1844/memoryerror-in-pypy3 Alexander Schepanovski: This code works in cpython3, but raises `MemoryError` in pypy3: args = (1, 0, 1, 0, 0, b'', (), (), (), '', 'operator', 0, b'') types.CodeType(*args) From issues-reply at bitbucket.org Thu Aug 14 16:36:33 2014 From: issues-reply at bitbucket.org (Alexander Schepanovski) Date: Thu, 14 Aug 2014 14:36:33 -0000 Subject: [pypy-issue] Issue #1845: Wrong getattr() on None in pypy3 (pypy/pypy) Message-ID: <20140814143633.18757.36202@app11.ash-private.bitbucket.org> New issue 1845: Wrong getattr() on None in pypy3 https://bitbucket.org/pypy/pypy/issue/1845/wrong-getattr-on-none-in-pypy3 Alexander Schepanovski: ``` >>>> None.__eq__(None) True >>>> getattr(None, "__eq__")(None) Traceback (most recent call last): File "", line 1, in TypeError: __eq__() takes exactly 2 arguments (1 given) ``` From issues-reply at bitbucket.org Fri Aug 15 23:41:48 2014 From: issues-reply at bitbucket.org (Rami Al-Rfou) Date: Fri, 15 Aug 2014 21:41:48 -0000 Subject: [pypy-issue] Issue #1846: Having "~/.local" in user directory adds python2.7 paths (pypy/pypy) Message-ID: <20140815214148.1269.33488@app04.ash-private.bitbucket.org> New issue 1846: Having "~/.local" in user directory adds python2.7 paths https://bitbucket.org/pypy/pypy/issue/1846/having-local-in-user-directory-adds Rami Al-Rfou: Running pypy with "~/.local" exists adds "/usr/lib/python2.7" which leads to errors importing shutil for example. ```traceback [rmyeid at galileo: ~] $ pypy Python 2.7.6 (32f35069a16d, Jun 06 2014, 11:20:40) [PyPy 2.3.1 with GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> sys.path ['', '/data/libs/pylearn2', '/usr/lib/python2.7', '/usr/local/lib/python2.7/dist-packages', '/opt/pypy-2.3.1-linux64/lib_pypy/__extensions__', '/opt/pypy-2.3.1-linux64/lib_pypy', '/opt/pypy-2.3.1-linux64/lib-python/2.7', '/opt/pypy-2.3.1-linux64/lib-python/2.7/lib-tk', '/opt/pypy-2.3.1-linux64/lib-python/2.7/plat-linux2', '/home/rmyeid/.local/lib/python2.7/site-packages'] >>>> ``` Problem is solved once the directory is removed! ```bash [rmyeid at galileo: ~] $ sudo rm -rf ~/.local ``` ```bash [rmyeid at galileo: ~] $ pypy -c "import sys; print sys.path" ['', '/opt/pypy-2.3.1-linux64/lib_pypy/__extensions__', '/opt/pypy-2.3.1-linux64/lib_pypy', '/opt/pypy-2.3.1-linux64/lib-python/2.7', '/opt/pypy-2.3.1-linux64/lib-python/2.7/lib-tk', '/opt/pypy-2.3.1-linux64/lib-python/2.7/plat-linux2', '/opt/pypy-2.3.1-linux64/site-packages'] ``` Responsible: arigo From issues-reply at bitbucket.org Sun Aug 17 06:52:27 2014 From: issues-reply at bitbucket.org (Alex Gaynor) Date: Sun, 17 Aug 2014 04:52:27 -0000 Subject: [pypy-issue] Issue #1847: Creating virtualenv with PyPy much slower than CPython (pypy/pypy) Message-ID: <20140817045227.26841.15570@app11.ash-private.bitbucket.org> New issue 1847: Creating virtualenv with PyPy much slower than CPython https://bitbucket.org/pypy/pypy/issue/1847/creating-virtualenv-with-pypy-much-slower Alex Gaynor: Running `mktmpenv ; deactivate` under PyPy takes about 5 seconds, while under CPython it takes about 2.2 seconds. This is considerably slower, and it'd be good to see if we can bring that difference down. From issues-reply at bitbucket.org Tue Aug 19 00:08:37 2014 From: issues-reply at bitbucket.org (paulie4) Date: Mon, 18 Aug 2014 22:08:37 -0000 Subject: [pypy-issue] Issue #1848: PyPy's REPL/readline is missing numbers in its syntax_table's SYNTAX_WORDs (pypy/pypy) Message-ID: <20140818220837.6907.72378@app08.ash-private.bitbucket.org> New issue 1848: PyPy's REPL/readline is missing numbers in its syntax_table's SYNTAX_WORDs https://bitbucket.org/pypy/pypy/issue/1848/pypys-repl-readline-is-missing-numbers-in paulie4: When using meta-f, meta-b, or meta-backspace, the current PyPy readline incorrectly treats numbers as symbols instead of word characters. To correct this, Line 96 in ```lib_pypy/pyrepl/reader.py``` should change from this: ``` #!python for c in [a for a in map(unichr, range(256)) if a.isalpha()]: ``` to this: ``` #!python for c in [a for a in map(unichr, range(256)) if a.isalnum()]: ``` From issues-reply at bitbucket.org Tue Aug 19 23:26:53 2014 From: issues-reply at bitbucket.org (Markus Unterwaditzer) Date: Tue, 19 Aug 2014 21:26:53 -0000 Subject: [pypy-issue] Issue #1849: Py2: 'a, b, c'.split(u', ') returns wrong/different stringtype (pypy/pypy) Message-ID: <20140819212653.9904.87175@app02.ash-private.bitbucket.org> New issue 1849: Py2: 'a, b, c'.split(u', ') returns wrong/different stringtype https://bitbucket.org/pypy/pypy/issue/1849/py2-a-b-csplit-u-returns-wrong-different Markus Unterwaditzer: Given the following snippet: ``` #!python 'a, b, c'.split(u', ') ``` Result in CPython: ``` $ python2 Python 2.7.8 (default, Jul 1 2014, 17:30:21) [GCC 4.9.0 20140604 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'a, b, c'.split(u', ') [u'a', u'b', u'c'] ``` Result in PyPy: ``` $ pypy Python 2.7.6 (3cf384e86ef7, Jul 09 2014, 04:28:24) [PyPy 2.4.0-alpha0 with GCC 4.9.0 20140604 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``samuele says that we lost a razor. so we can't shave yaks'' >>>> 'a, b, c'.split(u', ') ['a', 'b', 'c'] >>>> ``` I hope the version information given in the shell session is sufficient. From issues-reply at bitbucket.org Wed Aug 20 21:43:46 2014 From: issues-reply at bitbucket.org (mattip) Date: Wed, 20 Aug 2014 19:43:46 -0000 Subject: [pypy-issue] Issue #1850: numpy: array() ignores subok (pypy/pypy) Message-ID: <20140820194346.16508.59584@app03.ash-private.bitbucket.org> New issue 1850: numpy: array() ignores subok https://bitbucket.org/pypy/pypy/issue/1850/numpy-array-ignores-subok mattip: array() calls _array() in ctor.py which ignores subok Responsible: mattip From issues-reply at bitbucket.org Wed Aug 27 07:06:28 2014 From: issues-reply at bitbucket.org (mattip) Date: Wed, 27 Aug 2014 05:06:28 -0000 Subject: [pypy-issue] Issue #1851: arm segfaults on own tests, fails translation with fastgil (pypy/pypy) Message-ID: <20140827050628.9402.30409@app12.ash-private.bitbucket.org> New issue 1851: arm segfaults on own tests, fails translation with fastgil https://bitbucket.org/pypy/pypy/issue/1851/arm-segfaults-on-own-tests-fails mattip: Adding fastgil to the x86 jit backend broke arm. Also, the own tests segfault and abort in test_caching_setfield, apparently before they get to the point of failing the appropriate jit tests for fastgil. http://buildbot.pypy.org/builders/jitbackendonly-own-linux-armhf/builds/517/steps/shell_2/logs/stdio The own tests are run on a raspberry pi, so it should be simple to reproduce. From issues-reply at bitbucket.org Thu Aug 28 05:09:21 2014 From: issues-reply at bitbucket.org (Anton Dubrau) Date: Thu, 28 Aug 2014 03:09:21 -0000 Subject: [pypy-issue] Issue #1852: sum(arrays,[]) is slow (pypy/pypy) Message-ID: <20140828030921.10741.29317@app04.ash-private.bitbucket.org> New issue 1852: sum(arrays,[]) is slow https://bitbucket.org/pypy/pypy/issue/1852/sum-arrays-is-slow Anton Dubrau: sum(strings,"") is very slow (unnecessarily so), but at least there's the "".join(strings) function. when appending a list of arrays together in a similar fashion, there's no join method. Looping over an array and growing a result array using extend is much faster, but still kind of slow (it appears it's superlinear). The fastest way seems to be to pre-allocate a result array and copy the values into that, but it's kind of cumbersome. I feel that sum(arrays,[]) (and incidentally sum(strings,"")) is idiomatic, and pypy should specialize on it. It can also easily avoid re-allocations in theory, compared to using extend. Clearly, the time difference between the different approaches is unreasonable: some profiling: def sumExtend(arrays): result = [] for a in arrays: result.extend(a) return result def sumPreallocate(arrays): length = sum(len(a) for a in arrays) result = [0]*length index = 0; for a in arrays: result[index:index+len(a)] = a index += len(a) return result >> arrays = [[i%10]*i for i in range(10000)] >> %time result = sum(arrays,[]) cancelled after two and half hours ... may take days? >> %time _ = sumPreallocate(arrays) Wall time: 588 ms >> %time _ = sumExtend(arrays) Wall time: 1min 42s From issues-reply at bitbucket.org Thu Aug 28 07:27:57 2014 From: issues-reply at bitbucket.org (Alex Gaynor) Date: Thu, 28 Aug 2014 05:27:57 -0000 Subject: [pypy-issue] Issue #1853: cPickle.Unpickler.load_global isn't respected (pypy/pypy) Message-ID: <20140828052757.7813.84451@app08.ash-private.bitbucket.org> New issue 1853: cPickle.Unpickler.load_global isn't respected https://bitbucket.org/pypy/pypy/issue/1853/cpickleunpicklerload_global-isnt-respected Alex Gaynor: According to the docs, setting this to `None` can be used to prevent deserializing arbitrary objects, on PyPy this is silently ignored. From issues-reply at bitbucket.org Fri Aug 29 00:09:44 2014 From: issues-reply at bitbucket.org (mattip) Date: Thu, 28 Aug 2014 22:09:44 -0000 Subject: [pypy-issue] Issue #1854: windows: jit test_fficall tests fail (pypy/pypy) Message-ID: <20140828220944.3902.10293@app13.ash-private.bitbucket.org> New issue 1854: windows: jit test_fficall tests fail https://bitbucket.org/pypy/pypy/issue/1854/windows-jit-test_fficall-tests-fail mattip: it seems we are not getting a proper frame back from a call to execute token? deadframe = cpu.execute_token(procedure_token, *args1) then the deadframe.jf_descr is None. Here is an example of a failing test http://buildbot.pypy.org/summary/longrepr?testname=TestFfiCall.%28%29.test_simple_call_int&builder=own-win-x86-32&build=237&mod=jit.backend.x86.test.test_fficall and here is the stdout of the jitlog https://gist.github.com/anonymous/33c31acc1075f44572ed Note that these tests are skipped on linux64, so have not yet been able to compare the failing test to one that passes. From issues-reply at bitbucket.org Fri Aug 29 14:21:33 2014 From: issues-reply at bitbucket.org (mattip) Date: Fri, 29 Aug 2014 12:21:33 -0000 Subject: [pypy-issue] Issue #1855: meta issue for 2.4 release (pypy/pypy) Message-ID: <20140829122133.32518.57887@app11.ash-private.bitbucket.org> New issue 1855: meta issue for 2.4 release https://bitbucket.org/pypy/pypy/issue/1855/meta-issue-for-24-release mattip: Here are the issues we need to fix before 2.4 From issues-reply at bitbucket.org Sun Aug 31 01:36:04 2014 From: issues-reply at bitbucket.org (David Ripton) Date: Sat, 30 Aug 2014 23:36:04 -0000 Subject: [pypy-issue] Issue #1856: initpath.find_executable bug (pypy/pypy) Message-ID: <20140830233604.31158.33014@app01.ash-private.bitbucket.org> New issue 1856: initpath.find_executable bug https://bitbucket.org/pypy/pypy/issue/1856/initpathfind_executable-bug David Ripton: If a user has "::" somewhere in his PATH (bogus, but not uncommon), and has a file called "pypy" in the current directory, then running pypy (from elsewhere on the PATH, like /usr/bin) causes pypy to exit with the error: debug: WARNING: Library path not found, using compiled-in sys.path. debug: WARNING: 'sys.prefix' will not be set. debug: WARNING: Make sure the pypy binary is kept inside its tree of files. debug: WARNING: It is ok to create a symlink to it from somewhere else. debug: OperationError: debug: operror-type: ImportError debug: operror-value: No module named os The problem is that initpath.find_executable does not filter out null directories from the PATH. Marking as trivial because this is such an odd combination of circumstances that probably nobody else has ever run into it, but I'll submit a patch for it anyway. (It's a trivial fix.) From issues-reply at bitbucket.org Sun Aug 31 11:12:32 2014 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sun, 31 Aug 2014 09:12:32 -0000 Subject: [pypy-issue] Issue #1857: Stop depending on posixpath/ntpath in RPython (pypy/pypy) Message-ID: <20140831091232.6829.86386@app05.ash-private.bitbucket.org> New issue 1857: Stop depending on posixpath/ntpath in RPython https://bitbucket.org/pypy/pypy/issue/1857/stop-depending-on-posixpath-ntpath-in Armin Rigo: RPython code can call some functions from os.path. This causes problems, most recently because CPython 2.7.8 made a change to (at least) ntpath.splitdrive() that is not RPython any more. I suppose we should add our own version of these functions to rpython.rlib.rpath, supporting both Windows and Posix. To be nice we could then add redirection from os.path.xyz() to rpath.rxyz(), too. Responsible: arigo