From issues-reply at bitbucket.org Mon Apr 1 03:15:18 2019 From: issues-reply at bitbucket.org (Armin Rigo) Date: Mon, 01 Apr 2019 07:15:18 +0000 (UTC) Subject: [pypy-issue] Issue #2988: Windows: can't find _sqlite3_cffi.pypy-41.pyd although it is here (pypy/pypy) Message-ID: <20190401071518.28044.99444@celery-worker-112.ash1.bb-inf.net> New issue 2988: Windows: can't find _sqlite3_cffi.pypy-41.pyd although it is here https://bitbucket.org/pypy/pypy/issues/2988/windows-cant-find-_sqlite3_cffipypy-41pyd Armin Rigo: A user reports getting this message on Windows (6.0.0 worked fine, 7.0.0 and 7.1.0 fail): 'C:\pypy2\lib_pypy\_sqlite3_cffi.pypy-41.pyd': The specified module could not be found This occurs as soon as he tries to ``import sqlite3``. More information from him: I've tested it on two different Win10 PCs (32bit PyPy on 64bit Win10) and both exhibit the same behaviour. I've got the answer: With PyPy version >= 7.0.0 you have to add PyPy's root folder to PATH in Environment Variables, that wasn't required with versions <= 6.0.0 This is not the answer, though, because for me on a very similar setting it just works fine, without setting any PATH. If we could reproduce this it would be great. From issues-reply at bitbucket.org Tue Apr 2 16:16:07 2019 From: issues-reply at bitbucket.org (dtracers) Date: Tue, 02 Apr 2019 20:16:07 +0000 (UTC) Subject: [pypy-issue] Issue #2989: Pandas currently fails to install on pypy3 (pypy/pypy) Message-ID: <20190402201607.11826.20690@app-137.ash1.bb-inf.net> New issue 2989: Pandas currently fails to install on pypy3 https://bitbucket.org/pypy/pypy/issues/2989/pandas-currently-fails-to-install-on-pypy3 dtracers: I read that pandas was supported on pypy at least a year ago. is there a way to find which version of pandas and which version of pypy3 are compatible with each other? Broken download on website: http://packages.pypy.org/##pandas From issues-reply at bitbucket.org Tue Apr 2 22:57:38 2019 From: issues-reply at bitbucket.org (Ryan Hileman) Date: Wed, 03 Apr 2019 02:57:38 +0000 (UTC) Subject: [pypy-issue] Issue #2990: test_async_def is failing on py3.6 but test seems incorrect (pypy/pypy) Message-ID: <20190403025738.28519.49975@celery-worker-108.ash1.bb-inf.net> New issue 2990: test_async_def is failing on py3.6 but test seems incorrect https://bitbucket.org/pypy/pypy/issues/2990/test_async_def-is-failing-on-py36-but-test Ryan Hileman: https://bitbucket.org/pypy/pypy/src/py3.6/pypy/interpreter/astcompiler/test/test_symtable.py?at=py3.6&fileviewer=file-view-default#test_symtable.py-454:459 I can't reproduce this test on CPython 3.6, so I think the test is incorrect on py3.6 and there's no CO_GENERATOR flag on functions with await anymore? From issues-reply at bitbucket.org Wed Apr 3 10:06:46 2019 From: issues-reply at bitbucket.org (Dingyuan Wang) Date: Wed, 03 Apr 2019 14:06:46 +0000 (UTC) Subject: [pypy-issue] Issue #2991: str.maketrans returns UTF-8 code points instead of Unicode code points (pypy/pypy) Message-ID: <20190403140646.35946.76281@app-137.ash1.bb-inf.net> New issue 2991: str.maketrans returns UTF-8 code points instead of Unicode code points https://bitbucket.org/pypy/pypy/issues/2991/strmaketrans-returns-utf-8-code-points Dingyuan Wang: The cpython 3.x and pypy 7.x before the utf-8 changes returns: ``` >>>> str.maketrans('?', '?') {21834: 38463} ``` The new pypy3.6 7.2 (4547d8edb215) returns: ``` >>>> str.maketrans('?', '?') {229: 233, 149: 152, 138: 191} ``` From issues-reply at bitbucket.org Wed Apr 3 20:31:43 2019 From: issues-reply at bitbucket.org (Jean-Marc Legrand) Date: Thu, 04 Apr 2019 00:31:43 +0000 (UTC) Subject: [pypy-issue] Issue #2992: Cross compile pypy3 7.1 for BeagleBone Black or BeagleBone Black Wireless (pypy/pypy) Message-ID: <20190404003143.34817.16361@celery-worker-109.ash1.bb-inf.net> New issue 2992: Cross compile pypy3 7.1 for BeagleBone Black or BeagleBone Black Wireless https://bitbucket.org/pypy/pypy/issues/2992/cross-compile-pypy3-71-for-beaglebone Jean-Marc Legrand: I would like to python on a product that will be based on AM3358 (same processor as the BeagleBone Black platform). My BeagleBone Black is running a Debian Stretch distribution and I would like to compare the performances on my Django application when I use CPython 3.5 or pypy3. I have found some instructions explaining how to Cross compile for ARM. But this document is referring to scatchbox2 which is not supported anymore on Debian Strech. I am planning to create a Yocto recipe for pypy3 if I obtain good performance increments by using pypy3 compared to CPython 3.5. Can you update the pypy3 7.1 documentation to indicate how to cross build pypy3 on Debian Strech for ARMHF architecture? From issues-reply at bitbucket.org Wed Apr 3 22:15:43 2019 From: issues-reply at bitbucket.org (Rython) Date: Thu, 04 Apr 2019 02:15:43 +0000 (UTC) Subject: [pypy-issue] Issue #2993: Cross compile for ARM failed on translation (pypy/pypy) Message-ID: <20190404021543.37041.67060@celery-worker-110.ash1.bb-inf.net> New issue 2993: Cross compile for ARM failed on translation https://bitbucket.org/pypy/pypy/issues/2993/cross-compile-for-arm-failed-on Rython: I followed the instructions in [Cross-translating for ARM](https://rpython.readthedocs.io/en/latest/arm.html#cross-translating-for-arm) and wants to build for ARM in Ubuntu 14.04 (32-bit) on VMWare. ```shell [platform:execute] sb2 -t ARM gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -Wno-address /tmp/usession-release-pypy2.7-v7.1.0-6/platcheck_114.c -o /tmp/usession-release-pypy2.7-v7.1.0-6/platcheck_114.o [translation:info] Error: File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/goal/translate.py", line 284, in main default_goal='compile') File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/driver.py", line 569, in from_targetspec spec = target(driver, args) File "targetpypystandalone.py", line 338, in target return self.get_entry_point(config) File "targetpypystandalone.py", line 375, in get_entry_point self.space = make_objspace(config) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/tool/option.py", line 35, in make_objspace return Space(config) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/interpreter/baseobjspace.py", line 463, in __init__ self.initialize() File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/objspace/std/objspace.py", line 110, in initialize self.make_builtins() File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/interpreter/baseobjspace.py", line 662, in make_builtins self.install_mixedmodule(mixedname, installed_builtin_modules) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/interpreter/baseobjspace.py", line 693, in install_mixedmodule modname = self.setbuiltinmodule(mixedname) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/interpreter/baseobjspace.py", line 538, in setbuiltinmodule mod = Module(self, self.newtext(name)) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/interpreter/mixedmodule.py", line 25, in __init__ self.__class__.buildloaders() File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/module/fcntl/__init__.py", line 17, in buildloaders from pypy.module.fcntl import interp_fcntl File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/pypy/module/fcntl/interp_fcntl.py", line 41, in for k, v in platform.configure(CConfig).items(): File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/rtyper/tool/rffi_platform.py", line 215, in configure for name, result in zip(entries, results): File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/rtyper/tool/rffi_platform.py", line 240, in configure_entries writer.path, eci, ignore_errors=ignore_errors)) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/rtyper/tool/rffi_platform.py", line 743, in run_example_code output = build_executable_cache(files, eci, ignore_errors=ignore_errors) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/tool/gcc_cache.py", line 28, in build_executable_cache result = platform.execute(platform.compile(c_files, eci)) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/__init__.py", line 57, in compile ofiles = self._compile_o_files(cfiles, eci, standalone) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/__init__.py", line 79, in _compile_o_files ofiles.append(self._compile_c_file(self.cc, cfile, compile_args)) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/posix.py", line 42, in _compile_c_file cwd=str(cfile.dirpath())) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/arm.py", line 47, in _execute_c_compiler self._handle_error(returncode, stderr, stdout, outname) File "/home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/__init__.py", line 155, in _handle_error raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: CompilationError(out=""" In file included from /usr/include/fcntl.h:34:0, from /tmp/usession-release-pypy2.7-v7.1.0-6/platcheck_114.c:84: /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:36:5: error: unknown type name ?__off64_t? /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:37:5: error: unknown type name ?__off64_t? /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:39:5: error: unknown type name ?__pid_t? /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:47:5: error: unknown type name ?__off64_t? /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:48:5: error: unknown type name ?__off64_t? /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include/bits/fcntl.h:49:5: error: unknown type name ?__pid_t? """) [translation] start debugger... > /home/alex4814/Downloads/pypy2.7-v7.1.0-src/rpython/translator/platform/__init__.py(155)_handle_error() -> raise CompilationError(stdout, stderr) ``` How to fix this? From issues-reply at bitbucket.org Sun Apr 7 03:23:08 2019 From: issues-reply at bitbucket.org (S. Moon) Date: Sun, 07 Apr 2019 07:23:08 +0000 (UTC) Subject: [pypy-issue] Issue #2994: multiarray import fails - Symbol not found: _aheapsort_bool on macOS (pypy/pypy) Message-ID: <20190407072308.6260.47822@app-137.ash1.bb-inf.net> New issue 2994: multiarray import fails - Symbol not found: _aheapsort_bool on macOS https://bitbucket.org/pypy/pypy/issues/2994/multiarray-import-fails-symbol-not-found S. Moon: macOS Version: 10.13.6 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.7.0 (numpy package was installed through pip, and not built from source) Steps to repro: 1. Install numpy on a fresh pypy3.5 / 3.6 installation (Affects at least version PyPy3.6 v7.1.0-beta and PyPy3.5 v7.0.0, and also the latest 3.6 nightly - pypy-c-jit-96343-de061d87e39c-osx64) 2. `import numpy` Logs: Traceback (most recent call last): File "/Users/user/Downloads/pypy3.6-v7.1.0-osx64/site-packages/numpy/core/__init__.py", line 40, in from . import multiarray File "/Users/user/Downloads/pypy3.6-v7.1.0-osx64/site-packages/numpy/core/multiarray.py", line 12, in from . import overrides File "/Users/user/Downloads/pypy3.6-v7.1.0-osx64/site-packages/numpy/core/overrides.py", line 6, in from numpy.core._multiarray_umath import ( ImportError: dlopen(/Users/user/Downloads/pypy3.6-v7.1.0-osx64/site-packages/numpy/core/_multiarray_umath.pypy3-71-darwin.so, 6): Symbol not found: _aheapsort_bool Referenced from: /Users/user/Downloads/pypy3.6-v7.1.0-osx64/site-packages/numpy/core/_multiarray_umath.pypy3-71-darwin.so Expected in: dynamic lookup This does not repro on Linux builds of the same pypy versions. From issues-reply at bitbucket.org Thu Apr 11 01:49:44 2019 From: issues-reply at bitbucket.org (Anthony Sottile) Date: Thu, 11 Apr 2019 05:49:44 +0000 (UTC) Subject: [pypy-issue] Issue #2995: unpacking + py35+ *splat: SyntaxError: can't use starred expression here (pypy/pypy) Message-ID: <20190411054943.1239.54880@celery-worker-112.ash1.bb-inf.net> New issue 2995: unpacking + py35+ *splat: SyntaxError: can't use starred expression here https://bitbucket.org/pypy/pypy/issues/2995/unpacking-py35-splat-syntaxerror-cant-use Anthony Sottile: Here's sample code which works correctly in cpython 3.5+ ```python def f(*args): if len(args) == 1: x, y = (0, *args) elif len(args) == 2: x, y = args else: raise TypeError('{} {!r}'.format(len(args), args)) print(x, y) f(1) f(1, 2) f(1, 2, 3) ``` Here's the expected output in python3.5: ```console $ python3.5 t2.py 0 1 1 2 Traceback (most recent call last): File "t2.py", line 13, in f(1, 2, 3) File "t2.py", line 7, in f raise TypeError('{} {!r}'.format(len(args), args)) TypeError: 3 (1, 2, 3) ``` pypy3.5 (and pypy3.6) reject this code with a `SyntaxError`: ```console $ ./pypy3.6-v7.1.0-linux64/bin/pypy3 --version Python 3.6.1 (de061d87e39c, Mar 24 2019, 22:18:07) [PyPy 7.1.0-beta0 with GCC 6.2.0 20160901] $ pypy3 --version Python 3.5.3 (fdd60ed87e94, Apr 24 2018, 06:10:04) [PyPy 6.0.0 with GCC 6.2.0 20160901] $ ./pypy3.6-v7.1.0-linux64/bin/pypy3 t2.py File "t2.py", line 3 x, y = (0, *args) ^ SyntaxError: can't use starred expression here $ pypy3 t2.py File "t2.py", line 3 x, y = (0, *args) ^ SyntaxError: can't use starred expression here ``` Here's a much smaller reproduction: ```python x = (1,) a, b = (*x, 2) ``` From issues-reply at bitbucket.org Thu Apr 11 14:49:16 2019 From: issues-reply at bitbucket.org (=?utf-8?b?zpHPgc65z4PPhM6/z4TOrc67zrfPgiDOnM65zrrPgc+Mz4DOv8+FzrvOv8+C?=) Date: Thu, 11 Apr 2019 18:49:16 +0000 (UTC) Subject: [pypy-issue] Issue #2996: Decorating methods makes **kwargs pass duplicate arguments (pypy/pypy) Message-ID: <20190411184916.9329.68972@celery-worker-112.ash1.bb-inf.net> New issue 2996: Decorating methods makes **kwargs pass duplicate arguments https://bitbucket.org/pypy/pypy/issues/2996/decorating-methods-makes-kwargs-pass ??????????? ???????????: I think demonstrating the bug with some code would do better job than if I tried to explain it with words. The code works on CPython 3.6 - 3.8, but on PyPy 3.5.3 it throws TypeError. From issues-reply at bitbucket.org Fri Apr 12 13:00:15 2019 From: issues-reply at bitbucket.org (Antonio Cuni) Date: Fri, 12 Apr 2019 17:00:15 +0000 (UTC) Subject: [pypy-issue] Issue #2997: ''.join(somestring) is buggy in presence of non-ascii characters (pypy/pypy) Message-ID: <20190412170015.24072.92415@celery-worker-108.ash1.bb-inf.net> New issue 2997: ''.join(somestring) is buggy in presence of non-ascii characters https://bitbucket.org/pypy/pypy/issues/2997/join-somestring-is-buggy-in-presence-of Antonio Cuni: The following snippet prints a weird result on the latest pypy3 (nightly): ``` #-*- encoding: utf-8 -*- def dump(s): print(" len():", len(s)) print(" repr():", repr(s)) print(" chars:", [ord(ch) for ch in s]) x = "a = '?'" y = ''.join(x) print("x == y: ", x == y) print("x:") dump(x) print() print("y: ") dump(y) ``` ``` $ ./pypy3 foo.py x == y: True x: len(): 7 repr(): "a = '?'" chars: [97, 32, 61, 32, 39, 224, 39] y: len(): 8 repr(): "a = '?'" chars: [97, 32, 61, 32, 39, 224, 39, 208] `` Note that `x==y` even if they differ in length, and note that y has an extra char (208) which is not printed by repr(). 208 seems to be non-deterministic, so I suppose it is caused by an off-by-one error which causes someone to read past the string. This is the ultimate cause of the `\u0000` reported by issue #2983 From issues-reply at bitbucket.org Sun Apr 14 02:53:57 2019 From: issues-reply at bitbucket.org (Taha Jahangir) Date: Sun, 14 Apr 2019 06:53:57 +0000 (UTC) Subject: [pypy-issue] Issue #2998: str.maketrans wrongly complains about length of unicode arguments (pypy/pypy) Message-ID: <20190414065357.23906.35586@celery-worker-111.ash1.bb-inf.net> New issue 2998: str.maketrans wrongly complains about length of unicode arguments https://bitbucket.org/pypy/pypy/issues/2998/strmaketrans-wrongly-complains-about Taha Jahangir: This code works correctly in `7.0.0-alpha0`, but raises an error in `7.1.0-beta0`. ``` trans = str.maketrans('0123456789', '??????????') ValueError: the first two maketrans arguments must have equal length ``` Buggy Environment: ```Python 3.6.1 (de061d87e39c7df4e436974096d7982c676a859d, Apr 01 2019, 15:02:06) [PyPy 7.1.0-beta0 with GCC 8.2.1 20181127] t``` Working Environment: ```Python 3.6.1 (dab365a46514, Feb 05 2019, 16:36:40) [PyPy 7.0.0-alpha0 with GCC 6.2.0 20160901] ``` From issues-reply at bitbucket.org Mon Apr 15 16:46:10 2019 From: issues-reply at bitbucket.org (mattip) Date: Mon, 15 Apr 2019 20:46:10 +0000 (UTC) Subject: [pypy-issue] Issue #2999: implement a PEP 528 windows console (io._WindowsConsoleIO) (pypy/pypy) Message-ID: <20190415204610.33942.87399@celery-worker-111.ash1.bb-inf.net> New issue 2999: implement a PEP 528 windows console (io._WindowsConsoleIO) https://bitbucket.org/pypy/pypy/issues/2999/implement-a-pep-528-windows-console mattip: CPython implemented a special io class to handle utf8 unicode in an interactive terminal for Python3.6. It was accompanied by PEP 528 https://www.python.org/dev/peps/pep-0528/. PyPy does not have this. It is causing the [extra_tests step](http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/4550/steps/shell_12/logs/stdio) on the buildbots to fail From issues-reply at bitbucket.org Tue Apr 16 10:22:39 2019 From: issues-reply at bitbucket.org (=?utf-8?q?Anton_=C3=84lgmyr?=) Date: Tue, 16 Apr 2019 14:22:39 +0000 (UTC) Subject: [pypy-issue] Issue #3000: `-O` command line flag doesn't work on pypy3 (pypy/pypy) Message-ID: <20190416142239.39786.69022@celery-worker-110.ash1.bb-inf.net> New issue 3000: `-O` command line flag doesn't work on pypy3 https://bitbucket.org/pypy/pypy/issues/3000/o-command-line-flag-doesnt-work-on-pypy3 Anton ?lgmyr: The `-O` does not disable asserts in pypy3. Tested with `PyPy 7.1.0` on a linux machine, also confirmed on a windows machine. To reproduce,create a file containing `assert False`. Run using `pypy -O` and `pypy3 -O`. From issues-reply at bitbucket.org Wed Apr 17 08:01:55 2019 From: issues-reply at bitbucket.org (abara_kedavra) Date: Wed, 17 Apr 2019 12:01:55 +0000 (UTC) Subject: [pypy-issue] Issue #3001: codecs.decode() unexpected interpreter error (pypy/pypy) Message-ID: <20190417120155.39761.60199@app-137.ash1.bb-inf.net> New issue 3001: codecs.decode() unexpected interpreter error https://bitbucket.org/pypy/pypy/issues/3001/codecsdecode-unexpected-interpreter-error abara_kedavra: import codecs bytes = codecs.decode(string, "hex") "TypeError: 'hex' decoder returned 'bytes' instead of 'str'; use codecs.decode() to decode to arbitrary types" But it must return bytes, and I expect bytes (?!) This is not a type error. Can someone explain why this is happening? There is no such problem with CPython. (+ Ubuntu 18.04 / PyCharm) From issues-reply at bitbucket.org Wed Apr 17 23:45:25 2019 From: issues-reply at bitbucket.org (Nathaniel Smith) Date: Thu, 18 Apr 2019 03:45:25 +0000 (UTC) Subject: [pypy-issue] Issue #3002: Some way to run "enough" gc for test suites that need to make sure destructors have run (pypy/pypy) Message-ID: <20190418034525.13464.38820@celery-worker-109.ash1.bb-inf.net> New issue 3002: Some way to run "enough" gc for test suites that need to make sure destructors have run https://bitbucket.org/pypy/pypy/issues/3002/some-way-to-run-enough-gc-for-test-suites Nathaniel Smith: It turns out that sometimes in test suites you need to pump the garbage collector manually. For example, to test a `__del__` method, you might create an object, drop the reference to it, and then do some kind of check that whatever the `__del__` method was supposed to do has actually happened. In CPython, you can usually just call `gc.collect` once and you're good. But in pypy this requires calling `gc.collect` multiple times. (No-one's sure exactly how many. I guess in principle pypy might require arbitrarily many calls to match CPython's behavior, if there's a long chain of non-cyclic garbage with destructors?) A number of projects have hit this and had to implement workarounds. For example: * https://github.com/numpy/numpy/pull/12594#discussion_r276077803 * https://github.com/python-trio/trio/blob/5aab6b56eb53bb0ce3b3002a239f8c6db36c4ff7/trio/_core/tests/tutil.py#L40-L51 It would be nice if there were a better solution than calling `gc.collect()` repeatedly until you stop getting test failures, and if each project didn't have to figure this out from scratch. It would be even nicer if `gc.collect()` just did this, so that people wouldn't have to implement workarounds when porting to pypy :-). But if you need to make it something slightly different, that's OK too. Extra points for making it compatible with CPython, like using the `gc.collect(generation=...)` argument or something. From issues-reply at bitbucket.org Thu Apr 18 02:15:40 2019 From: issues-reply at bitbucket.org (Andrew Lawrence) Date: Thu, 18 Apr 2019 06:15:40 +0000 (UTC) Subject: [pypy-issue] Issue #3003: Unable to launch pdb from subprocess reader thread (pypy/pypy) Message-ID: <20190418061540.1837.20886@app-137.ash1.bb-inf.net> New issue 3003: Unable to launch pdb from subprocess reader thread https://bitbucket.org/pypy/pypy/issues/3003/unable-to-launch-pdb-from-subprocess Andrew Lawrence: While attempting to debug SpawnCmdLineTest.test_basic_script I placed a call to pdb inside the readerthread in subprocess.py def _readerthread(self, fh, buffer): import pdb; pdb.set_trace() buffer.append(fh.read()) fh.close() When running the test both reader threads used to communicate with the subprocess raised the following exception: Exception in thread Thread-2: Traceback (most recent call last): File "C:\pypy\lib-python\3\threading.py", line 916, in _bootstrap_inner self.run() File "C:\pypy\lib-python\3\threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "C:\pypy\lib-python\3\subprocess.py", line 1083, in _readerthread buffer.append(fh.read()) File "C:\pypy\lib-python\3\bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "C:\pypy\lib-python\3\bdb.py", line 66, in dispatch_line self.user_line(frame) File "C:\pypy\lib-python\3\pdb.py", line 261, in user_line self.interaction(frame, None) File "C:\pypy\lib-python\3\pdb.py", line 344, in interaction signal.signal(signal.SIGINT, Pdb._previous_sigint_handler) File "C:\pypy\lib-python\3\signal.py", line 47, in signal handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler)) ValueError: signal only works in main thread or with __pypy__.thread.enable_sign als() From issues-reply at bitbucket.org Thu Apr 18 11:52:34 2019 From: issues-reply at bitbucket.org (Oleg Mihaylov) Date: Thu, 18 Apr 2019 15:52:34 +0000 (UTC) Subject: [pypy-issue] Issue #3004: Fatal RPython error: NotImplementedError while running sanic app with uvloop (pypy/pypy) Message-ID: <20190418155234.13397.17947@celery-worker-112.ash1.bb-inf.net> New issue 3004: Fatal RPython error: NotImplementedError while running sanic app with uvloop https://bitbucket.org/pypy/pypy/issues/3004/fatal-rpython-error-notimplementederror Oleg Mihaylov: Without uvloop everything is fine, but with it: ``` cpyext: missing slot wrapper tp_as_buffer.c_bf_getreadbuffer RPython traceback: File "pypy_interpreter.c", line 37862, in BuiltinCode_funcrun_obj File "pypy_module_cpyext_6.c", line 11965, in wrap_del_call Fatal RPython error: NotImplementedError Aborted (core dumped) ``` ``` Python 3.6.1 (784b254d6699, Apr 14 2019, 10:22:42) [PyPy 7.1.1-beta0 with GCC 6.2.0 20160901] on linux ``` From issues-reply at bitbucket.org Thu Apr 18 16:01:53 2019 From: issues-reply at bitbucket.org (Simp fally) Date: Thu, 18 Apr 2019 20:01:53 +0000 (UTC) Subject: [pypy-issue] Issue #3005: Instances from a class returned by a function getting slower and slower (pypy/pypy) Message-ID: <20190418200153.28379.64508@celery-worker-110.ash1.bb-inf.net> New issue 3005: Instances from a class returned by a function getting slower and slower https://bitbucket.org/pypy/pypy/issues/3005/instances-from-a-class-returned-by-a Simp fally: pypy3 v6.0.0 linux64 / python3 3.5.3 / debian 9.0 The code attached explains the problem in 15lines better than I could with word (see terrible title). On my laptop, here are the results : python3 test_ai.py : Using factory's class : 1 took 1.2839s 2 took 1.2842s 3 took 1.2922s 4 took 1.2745s 5 took 1.2786s 6 took 1.2802s 7 took 1.3013s 8 took 1.3907s 9 took 1.3533s Using simple class : 1 took 1.2037s 2 took 1.2108s 3 took 1.2229s 4 took 1.2286s 5 took 1.2041s 6 took 1.2028s 7 took 1.2059s 8 took 1.2153s 9 took 1.2038s Everything is normal here. pypy3 test_ai.py : Using factory's class : 1 took 0.0088s 2 took 0.0092s 3 took 0.0739s 4 took 0.0891s 5 took 0.1015s 6 took 0.1285s 7 took 0.1302s 8 took 0.1465s 9 took 0.1648s Using simple class : 1 took 0.0089s 2 took 0.0077s 3 took 0.0078s 4 took 0.0077s 5 took 0.0078s 6 took 0.0076s 7 took 0.0078s 8 took 0.0078s 9 took 0.0076s Here the factory class' instances are slower and slower (with no signs of stopping, even gets slower than python3 at some point), while the normal class behave perfectly normal. pypy3 -jit off test_ai.py : Using factory's class : 1 took 2.8622s 2 took 2.8545s 3 took 2.8629s 4 took 2.8517s 5 took 2.8687s 6 took 2.8776s 7 took 2.8641s 8 took 2.8607s 9 took 2.8625s Using simple class : 1 took 2.9355s 2 took 2.9193s 3 took 2.9442s 4 took 2.9261s 5 took 3.1136s 6 took 3.2729s 7 took 3.3295s 8 took 3.2764s 9 took 3.2918s Slower than python3 but at least it's stable. This bug has effected a larger project of mine and I managed to find the minimal code for it. It's easy to work around it but it means throwing away class factories. From issues-reply at bitbucket.org Sat Apr 20 04:42:53 2019 From: issues-reply at bitbucket.org (vados) Date: Sat, 20 Apr 2019 08:42:53 +0000 (UTC) Subject: [pypy-issue] Issue #3006: codecs.decode failure: 'hex' decoder returned 'bytes' instead of 'str' (pypy/pypy) Message-ID: <20190420084252.9905.36342@celery-worker-112.ash1.bb-inf.net> New issue 3006: codecs.decode failure: 'hex' decoder returned 'bytes' instead of 'str' https://bitbucket.org/pypy/pypy/issues/3006/codecsdecode-failure-hex-decoder-returned vados: PyPy: ```python Python 3.6.1 (de061d87e39c7df4e436974096d7982c676a859d, Mar 26 2019, 16:19:11) [PyPy 7.1.0-beta0 with GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``PyPy is a tool to keep otherwise dangerous minds safely occupied.'' >>>> import codecs; codecs.decode("707974686f6e2d666f72756d2e696f", "hex") Traceback (most recent call last): File "", line 1, in TypeError: 'hex' decoder returned 'bytes' instead of 'str'; use codecs.decode() to decode to arbitrary types ``` In Python: ```python Python 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import codecs; codecs.decode("707974686f6e2d666f72756d2e696f", "hex") b'python-forum.io' ``` This was discovered deep [in some code that powers ethereum for python](https://github.com/ethereum/eth-utils/blob/master/eth_utils/hexadecimal.py#L17) From issues-reply at bitbucket.org Mon Apr 22 17:34:00 2019 From: issues-reply at bitbucket.org (=?utf-8?b?R8O2cnJlIE3DtnJyZQ==?=) Date: Mon, 22 Apr 2019 21:34:00 +0000 (UTC) Subject: [pypy-issue] Issue #3007: PyPy3 on windows does not print with '\r' (pypy/pypy) Message-ID: <20190422213400.26181.57661@celery-worker-108.ash1.bb-inf.net> New issue 3007: PyPy3 on windows does not print with '\r' https://bitbucket.org/pypy/pypy/issues/3007/pypy3-on-windows-does-not-print-with-r G?rre M?rre: Noticed that PyPy3 is missing the '\r' when using print(). Tested to be missing on PyPy3 6.0.0. and PyPy3 7.1.1-beta0. Both PyPy2, CPython 2 and CPython 3 all prints with '\r'. From paugier at bitbucket.org Sun Apr 28 06:54:28 2019 From: paugier at bitbucket.org (paugier at bitbucket.org) Date: Sun, 28 Apr 2019 10:54:28 +0000 (UTC) Subject: [pypy-issue] Issue #3008: ImportError numpy with Pypy3.6 7.1.1 (pypy/pypy) Message-ID: <20190428105428.10247.74997@celery-worker-112.ash1.bb-inf.net> New issue 3008: ImportError numpy with Pypy3.6 7.1.1 https://bitbucket.org/pypy/pypy/issues/3008/importerror-numpy-with-pypy36-711 Pierre Augier: With numpy-1.16.3 installed with pip: ``` pypy3 --version Python 3.6.1 (784b254d669919c872a505b807db8462b6140973, Apr 16 2019, 18:18:28) [PyPy 7.1.1-beta0 with GCC 8.2.0] pypy3 -c "import numpy" Traceback (most recent call last): File "/home/pierre/.pyenv/versions/pypy3.6-7.1.1/site-packages/numpy/core/__init__.py", line 40, in from . import multiarray File "/home/pierre/.pyenv/versions/pypy3.6-7.1.1/site-packages/numpy/core/multiarray.py", line 12, in from . import overrides File "/home/pierre/.pyenv/versions/pypy3.6-7.1.1/site-packages/numpy/core/overrides.py", line 6, in from numpy.core._multiarray_umath import ( ImportError: /home/pierre/.pyenv/versions/pypy3.6-7.1.1/site-packages/numpy/core/_multiarray_umath.pypy3-71-x86_64-linux-gnu.so: undefined symbol: PyStructSequence_InitType2 ``` From asottile at bitbucket.org Sun Apr 28 20:00:58 2019 From: asottile at bitbucket.org (asottile at bitbucket.org) Date: Mon, 29 Apr 2019 00:00:58 +0000 (UTC) Subject: [pypy-issue] Issue #3009: Py_GETENV missing in cpyext (pypy/pypy) Message-ID: <20190429000057.25129.2568@celery-worker-112.ash1.bb-inf.net> New issue 3009: Py_GETENV missing in cpyext https://bitbucket.org/pypy/pypy/issues/3009/py_getenv-missing-in-cpyext Anthony Sottile: In cpython it is defined in `pydebug.h`: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/pydebug.h#L31-L34 Here's the macro in its entirety: #define Py_GETENV(s) (Py_IgnoreEnvironmentFlag ? NULL : getenv(s)) I'm working around this as follows: https://github.com/asottile/future-breakpoint/blob/c2d2a2d106895837ffd8e30be2578bf755b1b5af/_future_breakpoint.c#L13-L16 ```c /* pypy does not have a Py_GETENV */ #ifndef Py_GETENV #define Py_GETENV(s) (Py_IgnoreEnvironmentFlag ? NULL : getenv(s)) #endif ``` From cjw296 at bitbucket.org Tue Apr 30 03:38:35 2019 From: cjw296 at bitbucket.org (cjw296 at bitbucket.org) Date: Tue, 30 Apr 2019 07:38:35 +0000 (UTC) Subject: [pypy-issue] Issue #3010: help with failing test on mock backport under pypy3 (pypy/pypy) Message-ID: <20190430073834.27743.43600@celery-worker-110.ash1.bb-inf.net> New issue 3010: help with failing test on mock backport under pypy3 https://bitbucket.org/pypy/pypy/issues/3010/help-with-failing-test-on-mock-backport Chris Withers: I?ve just finished backporting outstanding patches to the rolling mock backport. Unfortunately, this has caused a test to start failing on pypy3: [https://travis-ci.org/testing-cabal/mock/jobs/526308383](https://travis-ci.org/testing-cabal/mock/jobs/526308383) Would anyone be able to help getting that to pass or give any feedback on what might be going wrong? Many thanks for any help! From mattip at bitbucket.org Tue Apr 30 09:52:38 2019 From: mattip at bitbucket.org (mattip at bitbucket.org) Date: Tue, 30 Apr 2019 13:52:38 +0000 (UTC) Subject: [pypy-issue] Issue #3011: cpyext slow when calling Py_BuildValue("ii", 2048, 2049) (pypy/pypy) Message-ID: <20190430135238.2266.17996@app-137.ash1.bb-inf.net> New issue 3011: cpyext slow when calling Py_BuildValue("ii", 2048, 2049) https://bitbucket.org/pypy/pypy/issues/3011/cpyext-slow-when-calling-py_buildvalue-ii mattip: As can be seen in @antocuni 's \[benchmark repo\]\([https://github.com/antocuni/cpyext-benchmarks](https://github.com/antocuni/cpyext-benchmarks)\), the `simple.allocate_tuple` benchmark is much slower than CPython | benchmark | cpython 2.7.11 | cpython 3.6.3 | pypy2 v7.1 | pypy3.6 v7.1.1 | | --- | --- | --- | --- | --- | | simple.noargs | 0.35 secs | 0.41 secs | 0.17 secs | 0.21 secs | | simple.onearg\(None\) | 0.38 secs | 0.43 secs | 0.18 secs | 0.22 secs | | simple.onearg\(i\) | 0.37 secs | 0.43 secs | 0.23 secs | 1.47 secs | | simple.varargs | 0.54 secs | 0.58 secs | 0.40 secs | 0.53 secs | | simple.allocate\_int | 0.38 secs | 0.51 secs | 1.08 secs | 1.09 secs | | simple.allocate\_tuple | 0.64 secs | 0.90 secs | 5.63 secs | 7.19 secs | `Py_BuildValue` is a very common c-api call. In cpyext the call goes to `do_mktuple` in modsupport.c, which calls `v = PyTupleNew(n)`, then fills the tuple with n calls to `obj = do_mkvalue; PyTuple_SET_ITEM(v, obj, i);`Any ideas how we could make this faster?