From issues-reply at bitbucket.org Mon Nov 2 03:05:29 2015 From: issues-reply at bitbucket.org (David MacIver) Date: Mon, 02 Nov 2015 08:05:29 -0000 Subject: [pypy-issue] Issue #2180: Segfault in Hypothesis test suite on pypy 4.0.0 (pypy/pypy) Message-ID: <20151102080529.891.15397@app16.ash-private.bitbucket.org> New issue 2180: Segfault in Hypothesis test suite on pypy 4.0.0 https://bitbucket.org/pypy/pypy/issues/2180/segfault-in-hypothesis-test-suite-on-pypy David MacIver: When running the test suite for current Hypothesis master (a1cfabe9d7e5ab1ffdbf1be9893c5c3b1667d0f6 of https://github.com/DRMacIver/hypothesis.git), pypy 4.0.0 segfaults pretty consistently. The following command seems to segfault after a few minutes running: ``` PYTHONPATH=src pypy -m pytest tests/cover ``` The following subset segfaults most but not 100% of the time but is a lot faster: ``` PYTHONPATH=src pypy -m pytest tests/cover/test_strategytests.py tests/cover/test_via_the_database.py ``` I am happy to try to minimize this further if you want me to, but in the past it's been suggested that it's not that useful for me to do as long as you can reproduce it easily. From issues-reply at bitbucket.org Mon Nov 2 15:46:17 2015 From: issues-reply at bitbucket.org (Carl Friedrich Bolz) Date: Mon, 02 Nov 2015 20:46:17 -0000 Subject: [pypy-issue] Issue #2181: RPython Generators don't deal with raising other exception kinds (pypy/pypy) Message-ID: <20151102204617.30390.14387@app16.ash-private.bitbucket.org> New issue 2181: RPython Generators don't deal with raising other exception kinds https://bitbucket.org/pypy/pypy/issues/2181/rpython-generators-dont-deal-with-raising Carl Friedrich Bolz: This test fails: ``` def test_different_exception(self): def h(c): if c == 8: raise ValueError def g(c): try: h(c) except Exception, e: if isinstance(e, ValueError): raise raise StopIteration yield c def f(x): try: for x in g(x): pass except ValueError: return -5 return 5 assert f(8) == -5 res = self.interpret(f, [8]) assert res == -5 ``` because the flow space assumes that .next can only raise StopIteration. From issues-reply at bitbucket.org Mon Nov 2 17:34:04 2015 From: issues-reply at bitbucket.org (Stefano Rivera) Date: Mon, 02 Nov 2015 22:34:04 -0000 Subject: [pypy-issue] Issue #2182: Expose SOABI (PEP3149) is sysconfig (pypy/pypy) Message-ID: <20151102223404.1086.69241@app03.ash-private.bitbucket.org> New issue 2182: Expose SOABI (PEP3149) is sysconfig https://bitbucket.org/pypy/pypy/issues/2182/expose-soabi-pep3149-is-sysconfig Stefano Rivera: I'm applying this patch in Debian: ```diff --- a/lib-python/2.7/sysconfig.py +++ b/lib-python/2.7/sysconfig.py @@ -524,6 +524,13 @@ import _osx_support _osx_support.customize_config_vars(_CONFIG_VARS) + # PyPy: + import imp + for suffix, mode, type_ in imp.get_suffixes(): + if type_ == imp.C_EXTENSION: + _CONFIG_VARS['SOABI'] = suffix.split('.')[1] + break + if args: vals = [] for name in args: ``` To Expose SOABI in sysconfig. So that dh_pypy can use it to generate useful dependencies. See https://bugs.debian.org/803689 for context. This is the only way to access the soabi value, that's documented in the PEP. It looks like it was left out of https://bitbucket.org/pypy/pypy/commits/6dde6de7fec4 sysconfig is in general very incomplete hacky in PyPy, and needs hacks like this. I just want a second set of eyes to say this is sane to commit. From issues-reply at bitbucket.org Fri Nov 6 10:50:34 2015 From: issues-reply at bitbucket.org (Cory Benfield) Date: Fri, 06 Nov 2015 15:50:34 -0000 Subject: [pypy-issue] Issue #2183: PyPy 4.0.0 SSL module appears to leak memory. (pypy/pypy) Message-ID: <20151106155034.24994.46973@app11.ash-private.bitbucket.org> New issue 2183: PyPy 4.0.0 SSL module appears to leak memory. https://bitbucket.org/pypy/pypy/issues/2183/pypy-400-ssl-module-appears-to-leak-memory Cory Benfield: Originally raised as [Requests issue #2862](https://github.com/kennethreitz/requests/issues/2862). It seems that somewhere in the PyPy stack, the SSL module leaks memory. The following script slowly but indefinitely leaks memory on my machine (OS X 10.11 El Capitan) under the latest two PyPy releases (4.0.0 and 2.6.1) at least. The script does not leak under CPython 2.7.10. The script is below: ``` #!python import gc import time import socket import ssl import sys def main(): while True: ctx = ssl.create_default_context() s = socket.create_connection(('www.bing.com', 443)) s = ctx.wrap_socket(s, server_hostname='www.bing.com') s.close() time.sleep(0.1) sys.stderr.write('.') sys.stderr.flush() gc.collect() if __name__ == '__main__': main() ``` Please let me know if there's any additional diagnostics you'd like to see. From issues-reply at bitbucket.org Sat Nov 7 03:31:04 2015 From: issues-reply at bitbucket.org (artur) Date: Sat, 07 Nov 2015 08:31:04 -0000 Subject: [pypy-issue] Issue #2184: Big memory leaks when using requests (pypy/pypy) Message-ID: <20151107083104.63393.43084@celery-worker-102.ash1.bb-inf.net> New issue 2184: Big memory leaks when using requests https://bitbucket.org/pypy/pypy/issues/2184/big-memory-leaks-when-using-requests artur: This is related to #2183 (I don't have rights to reopening an issue, and the area seems to be broader than SSL so I'm creating a new issue). The original test script from the [github issue 2862](https://github.com/kennethreitz/requests/issues/2862) still causes a very big memory leak (a few MB/s). The script: ``` #!python import requests import time import sys def main(): while True: r = requests.get('https://www.bing.com/') time.sleep(0.1) sys.stderr.write('.') sys.stderr.flush() if __name__ == '__main__': main() ``` I tested it using PyPy built from 2690aff7d7b0 (-Ojit targetpypystandalone). I don't see a major improvement compared to 4.0.0. The script from #2183 still seems to leak memory using the newest PyPy, although a little slower. Note also that that script caused a much smaller leak than the original one that used `requests`, which probably means the leaking area is broader than SSL alone. Overall the issue is fairly critical, because it makes PyPy unsuitable for any long running server process that uses the `requests` library even in the simplest forms. From issues-reply at bitbucket.org Mon Nov 9 18:02:49 2015 From: issues-reply at bitbucket.org (Chris Adams) Date: Mon, 09 Nov 2015 23:02:49 -0000 Subject: [pypy-issue] Issue #2185: Crash in JIT loading the Django admin (pypy/pypy) Message-ID: <20151109230249.23382.24875@celery-worker-101.ash1.bb-inf.net> New issue 2185: Crash in JIT loading the Django admin https://bitbucket.org/pypy/pypy/issues/2185/crash-in-jit-loading-the-django-admin Chris Adams: I have a fairly complicated Django app, so this still needs a simple reduction but currently simply running the Django 1.8.6 admin under PyPy 4.0.0 encounters the following for most of the URLs in the admin app. All of the other apps work fine, even for hundreds of requests, but in django.contrib.admin every view hits an RPython traceback: ``` RPython traceback: File "pypy_module_pypyjit_interp_jit.c", line 115, in jump_absolute__AccessDirect_None File "rpython_jit_metainterp_warmstate.c", line 18033, in maybe_compile_and_run__star_5_1 File "rpython_jit_metainterp_warmstate.c", line 48547, in bound_reached__star_5_1 File "rpython_jit_metainterp_pyjitpl.c", line 20659, in compile_and_run_once___rpython_jit_metainterp_ji_23 File "rpython_jit_metainterp_pyjitpl.c", line 5292, in MetaInterp__compile_and_run_once File "rpython_jit_metainterp_pyjitpl.c", line 22425, in MetaInterp_interpret File "rpython_jit_metainterp_pyjitpl.c", line 37972, in MetaInterp__interpret File "rpython_jit_metainterp_pyjitpl.c", line 57497, in MIFrame_run_one_step File "rpython_jit_metainterp_pyjitpl_2.c", line 36179, in MIFrame_opimpl_jit_merge_point File "rpython_jit_metainterp_pyjitpl_3.c", line 34510, in MetaInterp_reached_loop_header File "rpython_jit_metainterp_pyjitpl_4.c", line 15341, in MetaInterp_compile_loop File "rpython_jit_metainterp_compile.c", line 12600, in compile_loop File "rpython_jit_metainterp_optimizeopt___init__.c", line 276, in optimize_trace File "rpython_jit_metainterp_optimizeopt_unroll.c", line 6348, in UnrollOptimizer_optimize_peeled_loop File "rpython_jit_metainterp_optimizeopt_unroll.c", line 19129, in UnrollOptimizer_jump_to_existing_trace File "rpython_jit_metainterp_optimizeopt_unroll.c", line 24981, in UnrollOptimizer_inline_short_preamble File "rpython_jit_metainterp_optimizeopt_unroll.c", line 27253, in UnrollOptimizer__map_args ~~~ Crash in JIT! Abort trap: 6 ``` Is there a recommended way to collect a bug report for this kind of crash? Oddly enough, running it with "--jit off" does not affect the problem, although it's noticeably slower. Setting ```PYPYLOG=:-``` produces a lot of output at startup but nothing around the time of the crash. Python 2.7.10 (850edf14b2c75573720f59e95767335fb1affe55, Oct 30 2015, 00:18:28) [PyPy 4.0.0 with GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] This is running inside a virtualenv From issues-reply at bitbucket.org Mon Nov 9 22:59:17 2015 From: issues-reply at bitbucket.org (Roman Sinayev) Date: Tue, 10 Nov 2015 03:59:17 -0000 Subject: [pypy-issue] Issue #2186: PyPy vs CPython2 O(N^2) vs O(N) (pypy/pypy) Message-ID: <20151110035917.52270.85178@celery-worker-102.ash1.bb-inf.net> New issue 2186: PyPy vs CPython2 O(N^2) vs O(N) https://bitbucket.org/pypy/pypy/issues/2186/pypy-vs-cpython2-o-n-2-vs-o-n Roman Sinayev: String concatenation seems to involve copying the whole string, while in Python2 people tend to simply add substrings. Example program: ``` import random import time def timing(f): def wrap(*args): time1 = time.time() ret = f(*args) time2 = time.time() print('%s function took %0.3f ms' % (f.__name__, (time2-time1)*1000.0)) return ret return wrap @timing def test(): s = b'' for i in range(1*1000*1000): c = chr(random.randint(1,128)) s += c return s if __name__=='__main__': test() ``` From issues-reply at bitbucket.org Wed Nov 11 06:15:36 2015 From: issues-reply at bitbucket.org (ibrkanac) Date: Wed, 11 Nov 2015 11:15:36 -0000 Subject: [pypy-issue] Issue #2187: Slow writing bytearray to file (pypy/pypy) Message-ID: <20151111111536.41312.66284@celery-worker-102.ash1.bb-inf.net> New issue 2187: Slow writing bytearray to file https://bitbucket.org/pypy/pypy/issues/2187/slow-writing-bytearray-to-file ibrkanac: he is result on osx ``` #!bash ~/D/P/m/a/app ? pypy -mtimeit -s 'k = open("write", "wb")' 'k.write(bytearray(2048))' 100000 loops, best of 3: 16 usec per loop ~/D/P/m/a/app ? python -mtimeit -s 'k = open("write", "wb")' 'k.write(bytearray(2048))' 100000 loops, best of 3: 5.69 usec per loop ``` ``` #!bash ~/D/P/m/a/app ? pypy Python 2.7.10 (850edf14b2c75573720f59e95767335fb1affe55, Oct 30 2015, 00:18:27) [PyPy 4.0.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> ``` ``` #!bash ~/D/P/m/a/app ? python Python 2.7.10 (default, Sep 23 2015, 04:34:03) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ``` alslo readinto bytearray is alwo slower on pypy then in python From issues-reply at bitbucket.org Thu Nov 12 11:39:44 2015 From: issues-reply at bitbucket.org (richardg867) Date: Thu, 12 Nov 2015 16:39:44 -0000 Subject: [pypy-issue] Issue #2188: multiprocessing.Manager.Queue error on Win32 (pypy/pypy) Message-ID: <20151112163944.30808.95565@celery-worker-102.ash1.bb-inf.net> New issue 2188: multiprocessing.Manager.Queue error on Win32 https://bitbucket.org/pypy/pypy/issues/2188/multiprocessingmanagerqueue-error-on-win32 richardg867: Attempting to create a multiprocessing.Manager.Queue on PyPy 4.0.0 for Win32 results in the following error (followed by others caused by the multiprocessing pipe being broken). While my application triggers the error, I could not reproduce it in REPL. Traceback (most recent call last): File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\process.py", line 258, in _bootstrap self.run() File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\process.py", line 114, in run self._target(*self._args, **self._kwargs) File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\managers.py", line 558, in _run_server server.serve_forever() File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\managers.py", line 179, in serve_forever c = self.listener.accept() File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\connection.py", line 145, in accept c = self._listener.accept() File "...\pypy-4.0.0-win32\lib-python\2.7\multiprocessing\connection.py", line 370, in accept win32.ERROR_NO_DATA): AttributeError: type object 'win32' has no attribute 'ERROR_NO_DATA' After replacing the `win32.ERROR_NO_DATA` reference with constant 232 - which [corresponds to ERROR_NO_DATA](https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx) - the queue works as expected. From issues-reply at bitbucket.org Fri Nov 13 11:20:28 2015 From: issues-reply at bitbucket.org (Scott Joseph) Date: Fri, 13 Nov 2015 16:20:28 -0000 Subject: [pypy-issue] Issue #2189: pypy3 sandbox mode fails (pypy/pypy) Message-ID: <20151113162028.12769.46286@celery-worker-101.ash1.bb-inf.net> New issue 2189: pypy3 sandbox mode fails https://bitbucket.org/pypy/pypy/issues/2189/pypy3-sandbox-mode-fails Scott Joseph: Sandbox mode in pypy3 is not working. I've posted the error message and steps I've taken below. I see it fails right after '/bin/pypy-c', and I see a few verbose lines above that, it says RealFile. I've checked that /Users/josesc/Documents/pypy3-2.4.0-src/pypy/goal/pypy-c does exist. Error message: $ ./pypy_interact.py --verbose ../goal/pypy-c [sandlib:call] ll_os.ll_os_getenv('PYPY_GENERATIONGC_NURSERY') [sandlib:result] None [sandlib:call] ll_os.ll_os_getenv('PYPY_GC_DEBUG') [sandlib:result] None [sandlib:call] ll_os.ll_os_envitems() [sandlib:result] [] [sandlib:call] ll_os.ll_os_stat('/bin/pypy-c') [sandlib:vpath] '/bin/pypy-c' => [sandlib:result] posix.stat_result(st...ctime=0) [sandlib:call] ll_os.ll_os_access('/bin/pypy-c', 1) [sandlib:exception] RuntimeError: no handler for this function debug: OperationError: debug: operror-type: RuntimeError debug: operror-value: None debug: OperationError: debug: operror-type: AttributeError debug: operror-value: stdout [Subprocess exit code: 1] Steps to reproduce: 1. Build pypy3 using https://bitbucket.org/pypy/pypy/downloads/pypy3-2.4.0-src.tar.bz2 2. python2 ../../rpython/bin/rpython -O2 --sandbox targetpypystandalone.py 3. cd ../sandbox 4. ./pypy_interact.py ../goal/pypy-c From issues-reply at bitbucket.org Tue Nov 17 04:06:49 2015 From: issues-reply at bitbucket.org (Tobias Oberstein) Date: Tue, 17 Nov 2015 09:06:49 -0000 Subject: [pypy-issue] Issue #2190: Possible performance regression from 2.6.1 to 4.0.0 (pypy/pypy) Message-ID: <20151117090649.36397.39964@celery-worker-102.ash1.bb-inf.net> New issue 2190: Possible performance regression from 2.6.1 to 4.0.0 https://bitbucket.org/pypy/pypy/issues/2190/possible-performance-regression-from-261 Tobias Oberstein: I've done some measurements comparing JSON and MsgPack serialization/deserialization performance https://github.com/oberstet/scratchbox/tree/master/python/serperf MsgPack deserialization seems significantly slower (>30%), e.g. PyPy 4.0.0: 23642935 objs/sec PyPy 2.6.1: 32081015 objs/sec Note: the MsgPack library used (https://github.com/msgpack/msgpack-python) runs pure Python code when on PyPy and uses PyPy's string builder (https://github.com/msgpack/msgpack-python/blob/master/msgpack/fallback.py). From issues-reply at bitbucket.org Wed Nov 18 15:43:58 2015 From: issues-reply at bitbucket.org (Ryan Campbell) Date: Wed, 18 Nov 2015 20:43:58 -0000 Subject: [pypy-issue] Issue #2191: json.dumps ensure_ascii=False behavior differs from cpython (pypy/pypy) Message-ID: <20151118204358.79126.74596@celery-worker-102.ash1.bb-inf.net> New issue 2191: json.dumps ensure_ascii=False behavior differs from cpython https://bitbucket.org/pypy/pypy/issues/2191/jsondumps-ensure_ascii-false-behavior Ryan Campbell: I ran into this recently while trying out pypy on our codebase. Basically, `json.dumps` with `ensure_ascii=False` seems to result in a unicode string being returned in python, but not in pypy. This resulted in a `TypeError: unicode argument expected, got 'str'` when trying to write to a file. Python behavior: ``` macbook:~ $ python Python 2.7.10 (default, Jul 13 2015, 12:18:59) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.dumps('a') '"a"' >>> json.dumps('a', ensure_ascii=False) '"a"' >>> json.dumps(u'a') '"a"' >>> json.dumps(u'a', ensure_ascii=False) u'"a"' >>> ``` PyPy behavior: ``` macbook:~ $ pypy Python 2.7.10 (850edf14b2c75573720f59e95767335fb1affe55, Oct 30 2015, 00:18:27) [PyPy 4.0.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> import json >>>> json.dumps('a') '"a"' >>>> json.dumps('a', ensure_ascii=False) '"a"' >>>> json.dumps(u'a') '"a"' >>>> json.dumps(u'a', ensure_ascii=False) '"a"' ``` Possibly related to #1627, since it looks quite similar although the behaviors seem to be reversed... From issues-reply at bitbucket.org Fri Nov 20 06:29:33 2015 From: issues-reply at bitbucket.org (kracekumar ramaraju) Date: Fri, 20 Nov 2015 11:29:33 -0000 Subject: [pypy-issue] Issue #2192: greenlet.settrace is missing (pypy/pypy) Message-ID: <20151120112933.12115.12877@celery-worker-102.ash1.bb-inf.net> New issue 2192: greenlet.settrace is missing https://bitbucket.org/pypy/pypy/issues/2192/greenletsettrace-is-missing kracekumar ramaraju: I am working on gevent based websocket server and trying to find which `greenlet/gevent` is blocking by following this [post](http://www.rfk.id.au/blog/entry/detect-gevent-blocking-with-greenlet-settrace/). Unfortunately `pypy` version of greenlet doesn't have function `settrace` in greenlet` module. ```python krace at Kracekumars-MacBook-Pro ~> (gpypy) python Python 2.7.10 (850edf14b2c75573720f59e95767335fb1affe55, Oct 30 2015, 00:18:22) [PyPy 4.0.0 with GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> import greenlet >>>> greenlet.settrace Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'settrace' >>>> greenlet >>>> ``` Similar one from Python `2.7.10` ```python krace at Kracekumars-MacBook-Pro ~/c/ws_playground> (g2710) python Python 2.7.10 (default, Jul 14 2015, 19:46:27) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import greenlet >>> grenlet.settrace Traceback (most recent call last): File "", line 1, in NameError: name 'grenlet' is not defined >>> greenlet.settrace >>> ``` From issues-reply at bitbucket.org Sun Nov 22 14:57:35 2015 From: issues-reply at bitbucket.org (posita) Date: Sun, 22 Nov 2015 19:57:35 -0000 Subject: [pypy-issue] Issue #2193: datetime.timedelta chokes on seconds=future.types.newint(...) (pypy/pypy) Message-ID: <20151122195735.28010.98043@celery-worker-101.ash1.bb-inf.net> New issue 2193: datetime.timedelta chokes on seconds=future.types.newint(...) https://bitbucket.org/pypy/pypy/issues/2193/datetimetimedelta-chokes-on-seconds posita: This came up [here](https://github.com/PythonCharmers/python-future/issues/187). There is a `future`-specific workaround (wrap values in `future`'s `native` function), but isn't very elegant. ```py Python 2.7.10 (f3ad1e1e1d6215e20d34bb65ab85ff9188c9f559, Sep 04 2015, 05:13:03) [PyPy 2.6.1 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> import datetime >>>> datetime.__file__ '/.../lib/pypy/lib_pypy/datetime.pyc' >>>> from builtins import int as _int >>>> i = int(1431216000) >>>> j = long(i) >>>> k = _int(i) >>>> isinstance(i, int) True >>>> isinstance(i, long) False >>>> isinstance(j, int) False >>>> isinstance(j, long) True >>>> isinstance(k, int) False >>>> isinstance(k, long) True >>>> datetime.timedelta(seconds=i) datetime.timedelta(16565) >>>> datetime.timedelta(seconds=j) datetime.timedelta(16565) >>>> datetime.timedelta(seconds=k) Traceback (most recent call last): File "", line 1, in File "/.../lib/pypy/lib_pypy/datetime.py", line 491, in __new__ assert isinstance(s, int) AssertionError ``` The assertion comes from [these two lines](https://bitbucket.org/pypy/pypy/src/2bd0965ba1ae8cd36ccdef2f6cdf8214d0a2442a/lib_pypy/datetime.py?at=default&fileviewer=file-view-default#datetime.py-490:491): ```py s += int(seconds) # can't overflow assert isinstance(s, int) ``` Where `s` is a `newint`, `isinstance(s, int)` will be `False`. A possible workaround in `datetime.py` to accommodate `newint`s might be: ```py s += int(seconds) # can't overflow assert x <= sys.maxint and x >= (-sys.maxint - 1) ``` From issues-reply at bitbucket.org Mon Nov 23 21:39:58 2015 From: issues-reply at bitbucket.org (Ivan Kozik) Date: Tue, 24 Nov 2015 02:39:58 -0000 Subject: [pypy-issue] Issue #2194: pypy does not include any ~/.local/lib/* directory in sys.path (pypy/pypy) Message-ID: <20151124023958.13029.46027@celery-worker-101.ash1.bb-inf.net> New issue 2194: pypy does not include any ~/.local/lib/* directory in sys.path https://bitbucket.org/pypy/pypy/issues/2194/pypy-does-not-include-any-local-lib Ivan Kozik: I installed pypy 4.0.1 from https://launchpad.net/~pypy/+archive/ubuntu/ppa (tested both Ubuntu 14.04 and 15.10) and pypy did not include any `~/.local/lib/*` directory in `sys.path`: ``` # pypy Python 2.7.10 (4.0.1+dfsg-1~ppa1~ubuntu15.04, Nov 20 2015, 19:34:27) [PyPy 4.0.1 with GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> sys.path ['', '/usr/lib/pypy/lib_pypy/__extensions__', '/usr/lib/pypy/lib_pypy', '/usr/lib/pypy/lib-python/2.7', '/usr/lib/pypy/lib-python/2.7/lib-tk', '/usr/lib/pypy/lib-python/2.7/plat-linux2', '/usr/local/lib/pypy2.7/dist-packages', '/usr/lib/pypy/dist-packages'] ``` This is not really what I expected, because I'm used to being able to install modules scoped to a user account, without a virtualenv. Compare with cpython, which includes `$HOME/.local/lib/python2.7/site-packages`. From issues-reply at bitbucket.org Wed Nov 25 06:03:33 2015 From: issues-reply at bitbucket.org (Tobias Pape) Date: Wed, 25 Nov 2015 11:03:33 -0000 Subject: [pypy-issue] Issue #2195: JIT Crash in ExtendedShortPreambleBuilder.add_preamble_op (pypy/pypy) Message-ID: <20151125110333.13009.73367@celery-worker-101.ash1.bb-inf.net> New issue 2195: JIT Crash in ExtendedShortPreambleBuilder.add_preamble_op https://bitbucket.org/pypy/pypy/issues/2195/jit-crash-in Tobias Pape: I get a segfault for [this version of pycket](https://github.com/samth/pycket/tree/3a8dc0745e87b8e5b928420de0abbb52a53e1bb5) with [this benchmark](https://bitbucket.org/krono/lamb-bench/src/9a45c63556b8e19c81add18cde0f232303ef98ff/compare/racket/racket_append.scm?at=default&fileviewer=file-view-default) as soon as the JIT kicks in. Reproduce with: 1. Build [pycket (shapes branch)](https://github.com/samth/pycket/tree/3a8dc0745e87b8e5b928420de0abbb52a53e1bb5) 2. Get [benchmark](https://bitbucket.org/krono/lamb-bench/src/9a45c63556b8e19c81add18cde0f232303ef98ff/compare/racket/racket_append.scm) 3. Get [auxiliary file](https://bitbucket.org/krono/lamb-bench/src/51b8f04d37d3bb0ee69eac4234c44525e6629bef/compare/racket/cons-emulation.rktl) (put in same directory as 2.) 4. run ` ./pycket-c racket_append.scm 2000` (make sure jit kicks in, maybe increase number LLDB traceback et al:. ``` Process 80422 launched: '/Users/tobias/dev/pypy/pycket/pycket-c' (x86_64) Invalid RPython operation (NULL ptr or bad array index) Process 80422 stopped * thread #1: tid = 0xf6a532, 0x00007fff8ef20866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fff8ef20866 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill + 10: -> 0x7fff8ef20866: jae 0x7fff8ef20870 ; __pthread_kill + 20 0x7fff8ef20868: movq %rax, %rdi 0x7fff8ef2086b: jmp 0x7fff8ef1d175 ; cerror_nocancel 0x7fff8ef20870: retq (lldb) bt * thread #1: tid = 0xf6a532, 0x00007fff8ef20866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fff8ef20866 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff8a6bf35c libsystem_pthread.dylib`pthread_kill + 92 frame #2: 0x00007fff88de9b1a libsystem_c.dylib`abort + 125 frame #3: 0x00000001007f98f9 pycket-c`RPyAbort + 41 at support.c:26 frame #4: 0x000000010054a21b pycket-c`pypy_g_ExtendedShortPreambleBuilder_add_preamble_op(l_self_3748=, l_preamble_op_13=) + 523 at rpython_jit_metainterp_optimizeopt_shortpreamble.c:7915 frame #5: 0x0000000100508593 pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 1283 at rpython_jit_metainterp_optimizeopt_optimizer.c:5195 frame #6: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #7: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #8: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #9: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #10: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #11: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #12: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #13: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #14: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #15: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #16: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #17: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #18: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #19: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #20: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #21: 0x00000001004e5093 pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 531 at rpython_jit_metainterp_optimizeopt_info.c:7005 frame #22: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #23: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #24: 0x00000001004e512d pycket-c`pypy_g_AbstractStructPtrInfo__force_elements(l_self_3857=, l_op_737=, l_optforce_21=, l_descr_806=) + 685 at rpython_jit_metainterp_optimizeopt_info.c:7729 frame #25: 0x00000001004e041c pycket-c`pypy_g_AbstractVirtualPtrInfo_force_box(l_self_3745=, l_op_717=, l_optforce_17=) + 2604 at rpython_jit_metainterp_optimizeopt_info.c:616 frame #26: 0x00000001005083de pycket-c`pypy_g_Optimizer_force_box(l_self_3682=, l_op_247=, l_optforce_26=) + 846 at rpython_jit_metainterp_optimizeopt_optimizer.c:4920 frame #27: 0x00000001004ca854 pycket-c`pypy_g_OptEarlyForce_propagate_forward(l_self_3954=, l_op_666=) + 596 at rpython_jit_metainterp_optimizeopt_earlyforce.c:264 frame #28: 0x0000000100517fbe pycket-c`pypy_g_OptPure_optimize_default(l_self_6167=, l_v635423=) + 1198 at rpython_jit_metainterp_optimizeopt_pure.c:3196 frame #29: 0x0000000100568f07 pycket-c`pypy_g_dispatch_optimize___star_0_3(l_self_6298=0x0000000102a9c260, l_op_1129=0x0000000102ac1308) + 183 at rpython_jit_metainterp_optimizeopt_util.c:4827 frame #30: 0x0000000100516409 pycket-c`pypy_g_OptPure_propagate_forward(l_self_3957=, l_op_318=) + 9 at rpython_jit_metainterp_optimizeopt_pure.c:1497 frame #31: 0x0000000100569b04 pycket-c`pypy_g_dispatch_optimize___star_0_4(l_self_6299=, l_op_1131=) + 2180 at rpython_jit_metainterp_optimizeopt_util.c:5773 frame #32: 0x000000010059d0c9 pycket-c`pypy_g_OptString_propagate_forward(l_self_3959=, l_op_319=) + 9 at rpython_jit_metainterp_optimizeopt_vstring.c:4191 frame #33: 0x000000010056742d pycket-c`pypy_g_dispatch_optimize___star_0_2(l_self_3961=, l_op_1126=) + 893 at rpython_jit_metainterp_optimizeopt_util.c:4548 frame #34: 0x000000010056a4f1 pycket-c`pypy_g_dispatch_optimize___star_0_5(l_self_6300=, l_op_1133=) + 689 at rpython_jit_metainterp_optimizeopt_util.c:8080 frame #35: 0x000000010051ee28 pycket-c`pypy_g_OptRewrite_propagate_forward(l_self_3963=, l_op_985=) + 248 at rpython_jit_metainterp_optimizeopt_rewrite.c:290 frame #36: 0x000000010056ca7d pycket-c`pypy_g_dispatch_optimize___star_0_6(l_self_6301=, l_op_1135=0x0000000102ac1308) + 1149 at rpython_jit_metainterp_optimizeopt_util.c:9838 frame #37: 0x00000001004f2069 pycket-c`pypy_g_OptIntBounds_propagate_forward(l_self_3965=, l_op_322=) + 9 at rpython_jit_metainterp_optimizeopt_intbounds.c:18 frame #38: 0x000000010055a41a pycket-c`pypy_g_UnrollOptimizer_jump_to_preamble(l_self_6276=, l_cell_token_0=, l_jump_op_11=, l_info_126=) + 938 at rpython_jit_metainterp_optimizeopt_unroll.c:16125 frame #39: 0x0000000100557b51 pycket-c`pypy_g_UnrollOptimizer_optimize_peeled_loop(l_self_6268=, l_start_label_6=, l_end_jump_1=, l_ops_12=, l_state_34=, l_call_pure_results_10=, l_inline_short_preamble_3=) + 11841 at rpython_jit_metainterp_optimizeopt_unroll.c:5275 frame #40: 0x0000000100479502 pycket-c`pypy_g_UnrolledLoopData_optimize(l_self_3602=, l_jitdriver_sd_151=, l_optimizations_7=, l_unroll_1=) + 1218 at rpython_jit_metainterp_compile.c:25035 frame #41: 0x00000001004bbd8c pycket-c`pypy_g_optimize_trace(l_jitdriver_sd_155=0x000000010095b8e0, l_compile_data_1=, l_memo_27=) + 1276 at rpython_jit_metainterp_optimizeopt___init__.c:220 frame #42: 0x000000010046f2f4 pycket-c`pypy_g_compile_loop(l_metainterp_289=, l_greenkey_146=, l_start_173=, l_inputargs_35=, l_jumpargs_3=, l_full_preamble_needed_0=, l_try_disabling_unroll_1=) + 6004 at rpython_jit_metainterp_compile.c:8868 frame #43: 0x0000000100603d8c pycket-c`pypy_g_MetaInterp_compile_loop(l_self_6851=, l_original_boxes_157=, l_live_arg_boxes_5=, l_start_178=0, l_try_disabling_unroll_2=false, l_exported_state_5=) + 4604 at rpython_jit_metainterp_pyjitpl_1.c:49279 frame #44: 0x00000001005e76e6 pycket-c`pypy_g_MetaInterp_reached_loop_header(l_self_6805=, l_greenboxes_7=, l_redboxes_5=) + 2134 at rpython_jit_metainterp_pyjitpl_1.c:28638 frame #45: 0x00000001005e6405 pycket-c`pypy_g_MIFrame_opimpl_jit_merge_point(l_self_6719=, l_jdindex_8=, l_greenboxes_5=, l_jcposition_1=14, l_redboxes_3=, l_orgpc_16=6) + 1877 at rpython_jit_metainterp_pyjitpl_1.c:5083 frame #46: 0x00000001005bfa55 pycket-c`pypy_g_MIFrame_run_one_step(l_self_6490=) + 197 at rpython_jit_metainterp_pyjitpl.c:28198 frame #47: 0x00000001005bbe45 pycket-c`pypy_g_MetaInterp__interpret(l_self_6472=) + 149 at rpython_jit_metainterp_pyjitpl.c:21537 frame #48: 0x00000001005b88e9 pycket-c`pypy_g_MetaInterp_interpret(l_self_1355=) + 9 at rpython_jit_metainterp_pyjitpl.c:16594 frame #49: 0x00000001005aff01 pycket-c`pypy_g_MetaInterp__compile_and_run_once(l_self_6437=, l_original_boxes_79=) + 2481 at rpython_jit_metainterp_pyjitpl.c:12529 frame #50: 0x00000001005af1f7 pycket-c`pypy_g_compile_and_run_once___rpython_jit_metainterp_ji(l_self_6421=, l_v715145=, l_v715146=, l_v715147=, l_v715148=, l_v715149=) + 1623 at rpython_jit_metainterp_pyjitpl.c:1942 frame #51: 0x000000010065a093 pycket-c`pypy_g_bound_reached__star_5(l_hash_2636=, l_cell_96=, l_stararg0_3789=, l_stararg1_3810=, l_stararg2_3078=, l_stararg3_1172=, l_stararg4_319=0x000000010290c100) + 1075 at rpython_jit_metainterp_warmstate.c:17890 frame #52: 0x00000001006593e5 pycket-c`pypy_g_maybe_compile_and_run__star_5(l_increment_threshold_15=, l_v796680=, l_v796681=, l_v796682=, l_v796683=, l_v796684=) + 581 at rpython_jit_metainterp_warmstate.c:1203 frame #53: 0x00000001000f0216 pycket-c`pypy_g_portal(l_ast_19=, l_ast_3=, l_env_shapes_0=, l_env_362=, l_cont_261=) + 1254 at pycket_interpreter_1.c:21386 frame #54: 0x000000010064a3a4 pycket-c`pypy_g_ll_portal_runner__pycket_AST_ASTPtr_pycket_AST_A(l_stararg0_3774=, l_stararg1_3795=, l_stararg2_3063=, l_stararg3_1157=, l_stararg4_307=) + 532 at rpython_jit_metainterp_warmspot.c:1255 frame #55: 0x00000001000bcf7f pycket-c`pypy_g_interpret_one(l_ast_5=, l_env_5=) + 559 at pycket_interpreter.c:17602 frame #56: 0x00000001000bc615 pycket-c`pypy_g_Module__interpret_mod(l_self_4596=, l_env_340=) + 2501 at pycket_interpreter.c:5235 frame #57: 0x00000001000bbb3c pycket-c`pypy_g_interpret_module(l_self_4592=, l_env_339=) + 252 at pycket_interpreter.c:1099 frame #58: 0x000000010008daf8 pycket-c`pypy_g_actual_entry(l_argv_1=) + 3992 at pycket_entry_point.c:1409 frame #59: 0x000000010008c7e4 pycket-c`pypy_g_entry_point(l_argv_4=) + 36 at pycket_entry_point.c:48 frame #60: 0x00000001007f9533 pycket-c`pypy_main_function(argc=, argv=) + 115 at entrypoint.c:74 frame #61: 0x0000000100001294 pycket-c`start + 52 (lldb) u Ambiguous command 'u'. Possible matches: undisplay up (lldb) up frame #1: 0x00007fff8a6bf35c libsystem_pthread.dylib`pthread_kill + 92 libsystem_pthread.dylib`pthread_kill + 92: -> 0x7fff8a6bf35c: cmpl $-0x1, %eax 0x7fff8a6bf35f: jne 0x7fff8a6bf368 ; pthread_kill + 104 0x7fff8a6bf361: callq 0x7fff8a6c2fe4 ; symbol stub for: __error 0x7fff8a6bf366: movl (%rax), %eax (lldb) frame #2: 0x00007fff88de9b1a libsystem_c.dylib`abort + 125 libsystem_c.dylib`abort + 125: -> 0x7fff88de9b1a: movl $0x2710, %edi 0x7fff88de9b1f: callq 0x7fff88e0e924 ; symbol stub for: usleep$NOCANCEL 0x7fff88de9b24: callq 0x7fff88de9b29 ; __abort libsystem_c.dylib`__abort: 0x7fff88de9b29: pushq %rbp (lldb) frame #3: 0x00000001007f98f9 pycket-c`RPyAbort + 41 at support.c:26 23 RPY_EXTERN 24 void RPyAbort(void) { 25 fprintf(stderr, "Invalid RPython operation (NULL ptr or bad array index)\n"); -> 26 abort(); 27 } (lldb) frame #4: 0x000000010054a21b pycket-c`pypy_g_ExtendedShortPreambleBuilder_add_preamble_op(l_self_3748=, l_preamble_op_13=) + 523 at rpython_jit_metainterp_optimizeopt_shortpreamble.c:7915 7912 block3: 7913 l_v661528 = RPyField(l_self_6251, espb_inst_label_args); 7914 l_v661531 = (struct pypy_object0 *)l_op_1084; -> 7915 l_v661530 = RPyField(l_v661528, l_length); 7916 OP_INT_ADD(l_v661530, 1L, l_v661529); 7917 l_v661548 = RPyField(l_v661528, l_items); 7918 l_v661549 = l_v661548->length; ``` From issues-reply at bitbucket.org Thu Nov 26 15:02:14 2015 From: issues-reply at bitbucket.org (Ronan Lamy) Date: Thu, 26 Nov 2015 20:02:14 -0000 Subject: [pypy-issue] Issue #2196: RPython should support list-resizing setslice operations (pypy/pypy) Message-ID: <20151126200214.24164.92540@celery-worker-101.ash1.bb-inf.net> New issue 2196: RPython should support list-resizing setslice operations https://bitbucket.org/pypy/pypy/issues/2196/rpython-should-support-list-resizing Ronan Lamy: Currently, RPython only supports `list1[a:b] = list2` if `b - a == len(list2)`. It should support it in all cases. This would simplify some interp-level code like https://bitbucket.org/pypy/pypy/src/d4774974048860b281f9d7cdd7723e5da3e62092/pypy/objspace/std/listobject.py?at=default&fileviewer=file-view-default#listobject.py-1473 and avoid confusing the annotator. The main function to change is `rpython.rtyper.rlist.ll_listsetslice`. BTW, this is probably doable by a newcomer without too much trouble. From issues-reply at bitbucket.org Fri Nov 27 16:50:34 2015 From: issues-reply at bitbucket.org (Pete Vine) Date: Fri, 27 Nov 2015 21:50:34 -0000 Subject: [pypy-issue] Issue #2197: sqlite benchmark fails in 4.0.1 (pypy/pypy) Message-ID: <20151127215034.9872.32041@celery-worker-101.ash1.bb-inf.net> New issue 2197: sqlite benchmark fails in 4.0.1 https://bitbucket.org/pypy/pypy/issues/2197/sqlite-benchmark-fails-in-401 Pete Vine: I was about to try comparing the 32-bit backends but got as far as sqlite: ```` ~/pypy-4.0.1-i686_x87/bin/pypy own/sqlitesynth.py -n 5 Traceback (most recent call last): File "own/sqlitesynth.py", line 57, in util.run_benchmark(options, options.num_runs, main) File "/unpacked/pypy-benchmarks-770e56a1296f/unladen_swallow/performance/util.py", line 27, in run_benchmark data = bench_func(num_runs, *args) File "own/sqlitesynth.py", line 41, in main _main() # warmup File "own/sqlitesynth.py", line 25, in _main conn.execute('insert into cos values (?, ?, ?)', [i, math.cos(i), str(i)]) File "/pypy-4.0.1-i686_x87/lib_pypy/_sqlite3.py", line 383, in execute return cur.execute(*args) File "/pypy-4.0.1-i686_x87/lib_pypy/_sqlite3.py", line 700, in wrapper return func(self, *args, **kwargs) File "/pypy-4.0.1-i686_x87/lib_pypy/_sqlite3.py", line 857, in execute return self.__execute(False, sql, [params]) File "/pypy-4.0.1-i686_x87/lib_pypy/_sqlite3.py", line 815, in __execute self.__statement._set_params(params) File "/pypy-4.0.1-i686_x87/lib_pypy/_sqlite3.py", line 1117, in _set_params "probably unsupported type." % i) InterfaceError: Error binding parameter 1 - probably unsupported type. ```` That very same non-SSE2 backend in 2.6.1 has no problem completing the sqlite benchmark - what gives? From issues-reply at bitbucket.org Mon Nov 30 09:46:26 2015 From: issues-reply at bitbucket.org (Carl Friedrich Bolz) Date: Mon, 30 Nov 2015 14:46:26 -0000 Subject: [pypy-issue] Issue #2198: Use new resizing setslice in the Python interpreter (pypy/pypy) Message-ID: <20151130144626.25896.58715@celery-worker-101.ash1.bb-inf.net> New issue 2198: Use new resizing setslice in the Python interpreter https://bitbucket.org/pypy/pypy/issues/2198/use-new-resizing-setslice-in-the-python Carl Friedrich Bolz: Now that list slices can resize (Issue #2196 ), we should refactor this kind of code: https://bitbucket.org/pypy/pypy/src/d4774974048860b281f9d7cdd7723e5da3e62092/pypy/objspace/std/listobject.py?at=default&fileviewer=file-view-default#listobject.py-1473 This is an easy task, suitable for getting started with pypy.