From issues-reply at bitbucket.org Wed Jan 1 10:18:59 2020 From: issues-reply at bitbucket.org (Peter Bell) Date: Wed, 01 Jan 2020 15:18:59 +0000 (UTC) Subject: [pypy-issue] Issue #3140: distutils: install_headers doesn't give the package its own folder by default (pypy/pypy) Message-ID: <20200101151859.21836.29027@celery-worker-109.ash1.bb-inf.net> New issue 3140: distutils: install_headers doesn't give the package its own folder by default https://bitbucket.org/pypy/pypy/issues/3140/distutils-install_headers-doesnt-give-the Peter Bell: Running `pypy3 -m pip install pybind11` from a `conda` environment results in the headers being installed directly into `$CONDA_PREFIX/include`. Whereas for a CPython distribution, it would install to something like `$CONDA_PREFIX/include/python3.6m/pybind11`. With `pypy`'s defaults, this breaks the include paths for extensions. Also, since every library?s headers are dumped into the same folder, you end up with name collisions and files being overwritten. The defaults seem to all be configured in `distutils/command/install.py` , with the `'pypy'` scheme being the only broken one: [https://bitbucket.org/pypy/pypy/src/73c04f01d5224a7c236d9f84e841483ec05f202a/lib-python/3/distutils/command/install.py#lines-46](https://bitbucket.org/pypy/pypy/src/73c04f01d5224a7c236d9f84e841483ec05f202a/lib-python/3/distutils/command/install.py#lines-46) From issues-reply at bitbucket.org Thu Jan 2 15:46:04 2020 From: issues-reply at bitbucket.org (Pierre Augier) Date: Thu, 02 Jan 2020 20:46:04 +0000 (UTC) Subject: [pypy-issue] Issue #3141: Compilation scipy fails with pypy3.6-7.3.0 (pypy/pypy) Message-ID: <20200102204603.14877.60670@celery-worker-112.ash1.bb-inf.net> New issue 3141: Compilation scipy fails with pypy3.6-7.3.0 https://bitbucket.org/pypy/pypy/issues/3141/compilation-scipy-fails-with-pypy36-730 Pierre Augier: Trying to install scipy with `pip install scipy`, I get ? ``` In file included from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/pytypes.h:12:0, from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/cast.h:13, from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/attr.h:13, from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/pybind11.h:44, from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/eval.h:14, from /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/Python.h:119, from _configtest.c:1: /home/pierre/.pyenv/versions/pypy3.6-7.3.0/include/detail/common.h:134:10: fatal error: cstddef: No such file or directory #include ^~~~~~~~~ compilation terminated. ``` However, the file /usr/include/c\+\+/7/cstddef exists. I installed pypy3.6-7.3.0 with pyenv. ? From issues-reply at bitbucket.org Sun Jan 5 15:56:46 2020 From: issues-reply at bitbucket.org (Pierre Augier) Date: Sun, 05 Jan 2020 20:56:46 +0000 (UTC) Subject: [pypy-issue] Issue #3142: Performance with simple numpy arrays (pypy/pypy) Message-ID: <20200105205646.36045.97791@celery-worker-110.ash1.bb-inf.net> New issue 3142: Performance with simple numpy arrays https://bitbucket.org/pypy/pypy/issues/3142/performance-with-simple-numpy-arrays Pierre Augier: I?m having a look at how much Python is bad with callbacks of tiny functions $[https://github.com/paugier/bench\_integrate\_callback](https://github.com/paugier/bench_integrate_callback)$. I was motivated by a benchmark from Julia people showing than Julia is much faster than Scipy for ODEs integration with tiny callback functions $[https://github.com/JuliaDiffEq/SciPyDiffEq.jl](https://github.com/JuliaDiffEq/SciPyDiffEq.jl)$. I thought that PyPy could be good to accelerate \`scipy.integrate.solve\_ivp\` since the code of solve\_ivp $[https://github.com/scipy/scipy/tree/master/scipy/integrate/\_ivp](https://github.com/scipy/scipy/tree/master/scipy/integrate/_ivp)$ is mostly ?simple? Python using ?simple? Numpy. However, it?s much slower with PyPy. I isolated a very simple case with a callback to check what happens. With a pure Python version $[https://github.com/paugier/bench\_integrate\_callback/blob/master/purepython\_callback.py](https://github.com/paugier/bench_integrate_callback/blob/master/purepython_callback.py)$, PyPy is 30 times faster than CPython! However, with a versions for which the time values are stored in a Numpy array $[https://github.com/paugier/bench\_integrate\_callback/blob/master/numpy\_callback.py](https://github.com/paugier/bench_integrate_callback/blob/master/numpy_callback.py)$, PyPy is 54 times slower than for the version for which the time values are stored in a list $therefore nearly 2 times slower than CPython$. The only difference between the 2 scripts is \`times = dt \* np.arange$1e5$\` instead of \`times = \[dt \* it for it in range$int\(1e5$\)\]\`. Of course, most of the elapsed time is not spent in this line but in the loop. It?s sad that PyPy can?t accelerate Python code using simple Numpy. I realized that it is not something new, but still I?d like to ask if there is any chance that PyPy could be improved in that respect. ? From issues-reply at bitbucket.org Tue Jan 7 08:45:33 2020 From: issues-reply at bitbucket.org (mattip) Date: Tue, 07 Jan 2020 13:45:33 +0000 (UTC) Subject: [pypy-issue] Issue #3143: spitfire benchmark consumes too much memory (pypy/pypy) Message-ID: <20200107134532.19662.19825@celery-worker-108.ash1.bb-inf.net> New issue 3143: spitfire benchmark consumes too much memory https://bitbucket.org/pypy/pypy/issues/3143/spitfire-benchmark-consumes-too-much mattip: The spitfire benchmark from the benchmarks repo uses more than 13 GB of memory on PyPy2 $with jit off$ where on CPython it does not seem to consume even 1GB. I recently updated the code to the [latest master](https://github.com/youtube/spitfire/pull/82) $well, after adapting to python3$ which did not change anything. From issues-reply at bitbucket.org Tue Jan 7 11:34:13 2020 From: issues-reply at bitbucket.org (Anthony Sottile) Date: Tue, 07 Jan 2020 16:34:13 +0000 (UTC) Subject: [pypy-issue] Issue #3144: pypy3.6 7.3.0 curses get_wch: ffi.error: undefined type name wint_t[1] (pypy/pypy) Message-ID: <20200107163412.4827.36961@celery-worker-111.ash1.bb-inf.net> New issue 3144: pypy3.6 7.3.0 curses get_wch: ffi.error: undefined type name wint_t[1] https://bitbucket.org/pypy/pypy/issues/3144/pypy36-730-curses-get_wch-ffierror Anthony Sottile: Still reproduces on the latest nightly ? seems to be a regression $I was able to call this function previously, it just misbehaved$ ? ``` $ ./pypy-c-jit-98442-def680385695-linux64/bin/pypy3 ../t.py Traceback (most recent call last): File "../t.py", line 6, in curses.wrapper(c_main) File "/home/asottile/workspace/babi/x/pypy-c-jit-98442-def680385695-linux64/lib-python/3/curses/__init__.py", line 94, in wrapper return func(stdscr, *args, **kwds) File "../t.py", line 4, in c_main stdscr.get_wch() File "/home/asottile/workspace/babi/x/pypy-c-jit-98442-def680385695-linux64/lib_pypy/_curses.py", line 407, in get_wch wch = ffi.new("wint_t[1]") ffi.error: undefined type name wint_t[1] ^ ``` ? ```python import curses def c_main(stdscr): stdscr.get_wch() curses.wrapper(c_main) ``` In case it matters, here is my curses versions: ``` $ dpkg -l | grep libncurses ii libncurses5:amd64 6.1-1ubuntu1.18.04 amd64 shared libraries for terminal handling ii libncursesw5:amd64 6.1-1ubuntu1.18.04 amd64 shared libraries for terminal handling (wide character support) ii libncursesw5-dev:amd64 6.1-1ubuntu1.18.04 amd64 developer's libraries for ncursesw ``` ? From issues-reply at bitbucket.org Tue Jan 7 20:47:14 2020 From: issues-reply at bitbucket.org (Tim Rojek) Date: Wed, 08 Jan 2020 01:47:14 +0000 (UTC) Subject: [pypy-issue] Issue #3145: PyPy and the GPL (pypy/pypy) Message-ID: <20200108014713.32455.29733@app-161.ash1.bb-inf.net> New issue 3145: PyPy and the GPL https://bitbucket.org/pypy/pypy/issues/3145/pypy-and-the-gpl Tim Rojek: Our team has a python application we distribute and are considering switching it to PyPy. So far so good, everything works and its faster! Legal is concerned about the use of GPL code in PyPy from the gdbm module. Julia had the same problem and introduced a USE\_GPL\_LIBS build option, perhaps something similar with PyPy can be done? Are gdbm.py and \_gdbm\_build.py the only GPL files in the prebuilt binary packages from [pypy.org](http://pypy.org)? If that?s all, I expect we could just delete those files. Build options are always good though! From issues-reply at bitbucket.org Wed Jan 8 04:22:51 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Wed, 08 Jan 2020 09:22:51 +0000 (UTC) Subject: [pypy-issue] Issue #3146: pypy3/pypy2 segmentation fault on 7.2.0+ (pypy/pypy) Message-ID: <20200108092251.3046.47404@celery-worker-110.ash1.bb-inf.net> New issue 3146: pypy3/pypy2 segmentation fault on 7.2.0+ https://bitbucket.org/pypy/pypy/issues/3146/pypy3-pypy2-segmentation-fault-on-720 Bernat Gabor: Cross-post from [https://github.com/pytest-dev/pytest/issues/6419](https://github.com/pytest-dev/pytest/issues/6419) See [https://dev.azure.com/pypa/virtualenv/\_build/results?buildId=17086&view=logs&j=b3e1d5b3-7205-5c20-0fbb-9ec4d3f8233f&t=05115d0d-a86f-52ed-4bab-d268832b14e4](https://dev.azure.com/pypa/virtualenv/_build/results?buildId=17086&view=logs&j=b3e1d5b3-7205-5c20-0fbb-9ec4d3f8233f&t=05115d0d-a86f-52ed-4bab-d268832b14e4) ```bash platform linux -- Python 3.6.9[pypy-7.2.0-final], pytest-5.3.2, py-1.8.1, pluggy-0.13.1 -- /home/vsts/work/1/s/.tox/pypy3/bin/python cachedir: .tox/pypy3/.pytest_cache rootdir: /home/vsts/work/1/s, inifile: setup.cfg plugins: xonsh-0.9.13.dev1, mock-1.13.0 collecting ... Fatal Python error: Segmentation fault Stack (most recent call first, approximate line numbers): File "/home/vsts/work/1/s/.tox/pypy3/site-packages/virtualenv/interpreters/discovery/py_info.py", line 214 in _load_for_exe File "/home/vsts/work/1/s/.tox/pypy3/site-packages/virtualenv/interpreters/discovery/py_info.py", line 199 in from_exe File "/home/vsts/work/1/s/.tox/pypy3/site-packages/virtualenv/interpreters/discovery/py_info.py", line 150 in find_exe_based_of File "/home/vsts/work/1/s/.tox/pypy3/site-packages/virtualenv/interpreters/discovery/py_info.py", line 137 in system_executable File "/home/vsts/work/1/s/tests/unit/interpreters/create/test_creator.py", line 1 in File "/home/vsts/work/1/s/.tox/pypy3/site-packages/_pytest/assertion/rewrite.py", line 105 in exec_module File ??? File ??? File ??? File ??? File ??? ``` Any ideas how can we identify the issue here? Note the issue does not happen with pypy 7.1.0 so is related ot some change on here. From issues-reply at bitbucket.org Wed Jan 8 13:44:21 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Wed, 08 Jan 2020 18:44:21 +0000 (UTC) Subject: [pypy-issue] Issue #3147: venv non ascii support - Windows (pypy/pypy) Message-ID: <20200108184421.27253.4062@app-147.ash1.bb-inf.net> New issue 3147: venv non ascii support - Windows https://bitbucket.org/pypy/pypy/issues/3147/venv-non-ascii-support-windows Bernat Gabor: Seems to create a venv into a path that has non ascii char $`?` is mcsb encode-able so valid in file paths even when one does not use utf-8 filepaths$ name in just does not work: ``` PS C:\Users\traveler\git\virtualenv> pypy3.exe -m venv 'env?' --without-pip Error: [WinError 183] Cannot create a file when that file already exists: 'C:\\Users\\traveler\\git\\virtualenv\\env?\\Scripts' ``` Furthermore, if one creates and moves into a folder containing a such character the venv site-package is no longer added to sys.path $the error is silently ignored$: ? ``` PS C:\Users\traveler\git\virtualenv> pypy3.exe -m venv env --without-pip PS C:\Users\traveler\git\virtualenv> mkdir env/site-packages PS C:\Users\traveler\git\virtualenv> ./env/Scripts/pypy3.exe -c 'import sys; print(\"\n\".join(sys.path))' C:\pypy\pypy3.6-v7.3.0-win32\lib_pypy\__extensions__ C:\pypy\pypy3.6-v7.3.0-win32\lib_pypy C:\pypy\pypy3.6-v7.3.0-win32\lib-python\3 C:\pypy\pypy3.6-v7.3.0-win32\lib-python\3\lib-tk C:\Users\traveler\git\virtualenv\env\site-packages PS C:\Users\traveler\git\virtualenv> mv env env? PS C:\Users\traveler\git\virtualenv> ./env?/Scripts/pypy3.exe -c 'import sys; print(\"\n\".join(sys.path))' C:\pypy\pypy3.6-v7.3.0-win32\lib_pypy\__extensions__ C:\pypy\pypy3.6-v7.3.0-win32\lib_pypy C:\pypy\pypy3.6-v7.3.0-win32\lib-python\3 C:\pypy\pypy3.6-v7.3.0-win32\lib-python\3\lib-tk C:\pypy\pypy3.6-v7.3.0-win32\site-packages ``` ? From issues-reply at bitbucket.org Thu Jan 9 04:46:58 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Thu, 09 Jan 2020 09:46:58 +0000 (UTC) Subject: [pypy-issue] Issue #3148: environment variable flag to disable JIT (pypy/pypy) Message-ID: <20200109094657.18689.86282@app-137.ash1.bb-inf.net> New issue 3148: environment variable flag to disable JIT https://bitbucket.org/pypy/pypy/issues/3148/environment-variable-flag-to-disable-jit Bernat Gabor: _PyPy can be a lot slower for short-lived interpreter runs than CPython. In such cases disabling the JIT might help a bit. This is now possible via --jit off, however, this does not scale well if you don?t know if your target python is either CPython or PyPy. Adding an environment flag to turn off the JIT might allow one to work around this issue._ ? PS. Initially proposed in a discussion with @**Ronan Lamy** From issues-reply at bitbucket.org Fri Jan 10 05:35:40 2020 From: issues-reply at bitbucket.org (Thomas Grainger) Date: Fri, 10 Jan 2020 10:35:40 +0000 (UTC) Subject: [pypy-issue] Issue #3149: [compatability] excpeptions using a metaclass that defines __instancecheck__ and __subclasscheck__ doesn't work in pypy (pypy/pypy) Message-ID: <20200110103540.33552.61949@celery-worker-110.ash1.bb-inf.net> New issue 3149: [compatability] excpeptions using a metaclass that defines __instancecheck__ and __subclasscheck__ doesn't work in pypy https://bitbucket.org/pypy/pypy/issues/3149/compatability-excpeptions-using-a Thomas Grainger: repro here: [https://github.com/giampaolo/psutil/issues/1659](https://github.com/giampaolo/psutil/issues/1659) ``` import errno from psutil._compat import ChildProcessError class MyPretendChildProcessError(EnvironmentError): errno = errno.ECHILD try: raise MyPretendChildProcessError except ChildProcessError: pass ``` ? From issues-reply at bitbucket.org Sun Jan 12 12:16:27 2020 From: issues-reply at bitbucket.org (Steam Account) Date: Sun, 12 Jan 2020 17:16:27 +0000 (UTC) Subject: [pypy-issue] Issue #3150: Can pickle generators in 2.7 but not on 3.6 (pypy/pypy) Message-ID: <20200112171627.38530.33499@celery-worker-111.ash1.bb-inf.net> New issue 3150: Can pickle generators in 2.7 but not on 3.6 https://bitbucket.org/pypy/pypy/issues/3150/can-pickle-generators-in-27-but-not-on-36 Steam Account: I have tried the latest release for 3.6 as well as the one for 2.7 running on Windows. I attached the output of what happens with 3.6 version and what happens with 2.7 ? I create a very simple generator and pickle it on 2.7 without problems. On 3.6 I try the same but I get an error: AttributeError: module 'builtins' has no attribute 'generator' among other tracebacks, all included in the output below. From issues-reply at bitbucket.org Mon Jan 13 22:57:34 2020 From: issues-reply at bitbucket.org (Jan Vesely) Date: Tue, 14 Jan 2020 03:57:34 +0000 (UTC) Subject: [pypy-issue] Issue #3151: [PATCH] Makefile: Use detected runinterp for initial memory check (pypy/pypy) Message-ID: <20200114035734.35820.94928@app-147.ash1.bb-inf.net> New issue 3151: [PATCH] Makefile: Use detected runinterp for initial memory check https://bitbucket.org/pypy/pypy/issues/3151/patch-makefile-use-detected-runinterp-for Jan Vesely: `python` might be different from the selected interpreter sorry, couldn?t open PR. ``` diff -r 928110c124ae -r 1b64005e256a Makefile --- a/Makefile Fri Jan 10 18:19:55 2020 +0000 +++ b/Makefile Thu Jan 09 19:14:03 2020 -0500 @@ -2,7 +2,6 @@ all: pypy-c cffi_imports PYPY_EXECUTABLE := $(shell which pypy) -URAM := $(shell python -c "import sys; print 4.5 if sys.maxint>1<<32 else 2.5") ifeq ($(PYPY_EXECUTABLE),) RUNINTERP = python @@ -10,6 +9,8 @@ RUNINTERP = $(PYPY_EXECUTABLE) endif +URAM := $(shell $(RUNINTERP) -c "import sys; print 4.5 if sys.maxint>1<<32 else 2.5") + .PHONY: pypy-c cffi_imports pypy-c: ``` ? From issues-reply at bitbucket.org Wed Jan 15 00:31:38 2020 From: issues-reply at bitbucket.org (shining go) Date: Wed, 15 Jan 2020 05:31:38 +0000 (UTC) Subject: [pypy-issue] Issue #3152: test (pypy/pypy) Message-ID: <20200115053137.31425.81044@celery-worker-108.ash1.bb-inf.net> New issue 3152: test https://bitbucket.org/pypy/pypy/issues/3152/test shining go: just for search the status From issues-reply at bitbucket.org Thu Jan 16 06:18:00 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Thu, 16 Jan 2020 11:18:00 +0000 (UTC) Subject: [pypy-issue] Issue #3153: pypy3 performance regression (pypy/pypy) Message-ID: <20200116111800.31700.10314@celery-worker-110.ash1.bb-inf.net> New issue 3153: pypy3 performance regression https://bitbucket.org/pypy/pypy/issues/3153/pypy3-performance-regression Bernat Gabor: Here is a concrete example: [https://github.com/pypa/virtualenv/blob/rewrite/tasks/make\_zipapp.py](https://github.com/pypa/virtualenv/blob/rewrite/tasks/make_zipapp.py) This script runs within: * CPython 3.8 - 63.82s * pypy3 - 447.57s * pypy2 - 99.13s on ? Benchmarks from [https://dev.azure.com/pypa/virtualenv/\_build/results?buildId=17548](https://dev.azure.com/pypa/virtualenv/_build/results?buildId=17548). I'd hope pypy3 to be on par at least with pypy2 here. ? ? From issues-reply at bitbucket.org Thu Jan 16 07:20:54 2020 From: issues-reply at bitbucket.org (Andrew Robinson) Date: Thu, 16 Jan 2020 12:20:54 +0000 (UTC) Subject: [pypy-issue] Issue #3154: Multiprocessing leaking file descriptors (pypy/pypy) Message-ID: <20200116122053.22523.58703@app-161.ash1.bb-inf.net> New issue 3154: Multiprocessing leaking file descriptors https://bitbucket.org/pypy/pypy/issues/3154/multiprocessing-leaking-file-descriptors Andrew Robinson: Have migrated a multiprocessing project from PyPy 6.0 $2.7$ to PyPy 7.3 $3.6$ and have identified an issue with multiprocessing leaking descriptors. I believe this may also relate to the issue reported as #3060. I have identified this issue as repeatable on both Ubuntu 18.04.2 and CentOS 7.0. Simple code to reproduce issue $Taken from #3111 which is raised a different issue, but current issue is reproduced with the same code sample$: ``` import multiprocessing def process_chunk(chunk_index): return ([],[],[]) def main(): i = 0 with multiprocessing.Pool(5, maxtasksperchild=1) as p: for sub_headers, sub_results, sub_scores in p.imap_unordered(process_chunk, range(5000)): print(i) i += 1 if __name__ == '__main__': main() ``` If saving the above as ?test.py? the descriptor leak can be verified by running ?/path/to/pypy3 test.py? then taking the PID from ps and doing an ?ls -l /proc/PID/fd? and comparing to the same when running native Python Ie. Running ?/path/to/python3 test.py? taking PID and ?ls -l /proc/PID/fd?. Under native Python3 the descriptor list remains constant at 9 pipe entries. Under PyPy the file descriptor list keeps growing until ulimit is reached and it will throw an exception as ?OSError: \[Errno 24\] Too many open files?. In my case ulimit is set to 1024. Traceback below: ? ``` Exception in thread Thread-1: Traceback (most recent call last): File "/opt/callation/pypy3/lib-python/3/threading.py", line 916, in _bootstrap_inner self.run() File "/opt/callation/pypy3/lib-python/3/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/opt/callation/pypy3/lib-python/3/multiprocessing/pool.py", line 405, in _handle_workers pool._maintain_pool() File "/opt/callation/pypy3/lib-python/3/multiprocessing/pool.py", line 246, in _maintain_pool self._repopulate_pool() File "/opt/callation/pypy3/lib-python/3/multiprocessing/pool.py", line 239, in _repopulate_pool w.start() File "/opt/callation/pypy3/lib-python/3/multiprocessing/process.py", line 105, in start self._popen = self._Popen(self) File "/opt/callation/pypy3/lib-python/3/multiprocessing/context.py", line 277, in _Popen return Popen(process_obj) File "/opt/callation/pypy3/lib-python/3/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/opt/callation/pypy3/lib-python/3/multiprocessing/popen_fork.py", line 65, in _launch parent_r, child_w = os.pipe() OSError: [Errno 24] Too many open files ``` ? From issues-reply at bitbucket.org Fri Jan 17 15:20:48 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Fri, 17 Jan 2020 20:20:48 +0000 (UTC) Subject: [pypy-issue] Issue #3155: pypy3 on Windows uses non Windows install path (pypy/pypy) Message-ID: <20200117202048.11927.39282@app-147.ash1.bb-inf.net> New issue 3155: pypy3 on Windows uses non Windows install path https://bitbucket.org/pypy/pypy/issues/3155/pypy3-on-windows-uses-non-windows-install Bernat Gabor: The destination folder to install pip packages is delegated by pip to distutils, more specifically to distutils install command $[https://github.com/pypa/pip/blob/master/src/pip/\_internal/locations.py#L95-L129](https://github.com/pypa/pip/blob/master/src/pip/_internal/locations.py#L95-L129)$. The distutils install command performs a lookup to determine the schemes to use, this happens here $[https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/distutils/command/install.py#lines-464:466](https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/distutils/command/install.py#lines-464:466)$ and is unconditionally set to pypy. The pypy schema is defined under [https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/distutils/command/install.py#lines-46:52](https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/distutils/command/install.py#lines-46:52). The problem is the following line: ` 'scripts': '$base/bin',` On all platforms the script folder is bin. The venv module though sets the script folder to Scripts, here $[https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/venv/\_\_init\_\_.py#lines-131](https://bitbucket.org/pypy/pypy/src/release-pypy3.6-v7.3.0/lib-python/3/venv/__init__.py#lines-131)$. The combination of these two causes pypy3 virtual environments to have their python executables on Windows using the Script folder, while pip installing all-new executable to the bin folder. Is this duality intended? From issues-reply at bitbucket.org Sat Jan 18 17:01:50 2020 From: issues-reply at bitbucket.org (Robert Borys) Date: Sat, 18 Jan 2020 22:01:50 +0000 (UTC) Subject: [pypy-issue] Issue #3156: Exception when creating SSLContext (pypy/pypy) Message-ID: <20200118220150.14315.99125@app-161.ash1.bb-inf.net> New issue 3156: Exception when creating SSLContext https://bitbucket.org/pypy/pypy/issues/3156/exception-when-creating-sslcontext Robert Borys: I?m getting the following exception when calling ssl.SSLContext ? ``` c:\prog\pypy36\pypy3.exe my_file.py RPython traceback: File "pypy_interpreter.c", line 44890, in BuiltinCode2_fastcall_2 File "implement_4.c", line 45668, in fastfunc_descr_getattribute_2_1 File "pypy_module__cffi_backend.c", line 23310, in W_LibObject__get_attr File "pypy_module__cffi_backend_1.c", line 5824, in W_LibObject__build_attr File "pypy_module__cffi_backend_1.c", line 33180, in W_LibObject__build_cpython_func File "pypy_module__cffi_backend_1.c", line 42652, in W_RawFuncType_prepare_nostruct_fnptr File "pypy_module__cffi_backend_1.c", line 18993, in W_RawFuncType__unpack File "pypy_module__cffi_backend_1.c", line 30181, in realize_c_type File "pypy_module__cffi_backend_1.c", line 31910, in realize_c_type_or_func File "pypy_module__cffi_backend_1.c", line 42405, in __exit____star_3_1 RPython traceback: File "pypy_interpreter.c", line 44890, in BuiltinCode2_fastcall_2 File "implement_4.c", line 45668, in fastfunc_descr_getattribute_2_1 File "pypy_module__cffi_backend.c", line 23310, in W_LibObject__get_attr File "pypy_module__cffi_backend_1.c", line 5824, in W_LibObject__build_attr File "pypy_module__cffi_backend_1.c", line 33154, in W_LibObject__build_cpython_func File "pypy_module__cffi_backend_1.c", line 31910, in realize_c_type_or_func File "pypy_module__cffi_backend_1.c", line 42405, in __exit____star_3_1 Traceback (most recent call last): File "my_file.py", line 121, in my_function() File "my_file.py", line 43, in another_function ssl_context = ssl.SSLContext() File "c:\prog\pypy36\lib-python\3\ssl.py", line 391, in __new__ self = _SSLContext.__new__(cls, protocol) File "c:\prog\pypy36\lib_pypy\_cffi_ssl\_stdssl\__init__.py", line 933, in __new__ self.verify_mode = CERT_NONE File "c:\prog\pypy36\lib-python\3\ssl.py", line 485, in verify_mode super(SSLContext, SSLContext).verify_mode.__set__(self, value) File "c:\prog\pypy36\lib_pypy\_cffi_ssl\_stdssl\__init__.py", line 1024, in verify_mode verify_cb = lib.SSL_CTX_get_verify_callback(self.ctx) SystemError: unexpected internal exception (please report a bug): ; internal traceback was dumped to stderr ``` ? From issues-reply at bitbucket.org Mon Jan 20 14:11:03 2020 From: issues-reply at bitbucket.org (Geoffrey Sneddon) Date: Mon, 20 Jan 2020 19:11:03 +0000 (UTC) Subject: [pypy-issue] Issue #3157: SIGSEGV when running web-platform-tests tests (pypy/pypy) Message-ID: <20200120191103.13956.16088@app-161.ash1.bb-inf.net> New issue 3157: SIGSEGV when running web-platform-tests tests https://bitbucket.org/pypy/pypy/issues/3157/sigsegv-when-running-web-platform-tests Geoffrey Sneddon: ``` git clone https://github.com/web-platform-tests/wpt.git cd wpt/tools tox -e pypy ``` and then it exists with SEGSEGV $PyPy 7.3.0, wpt b3bb7d0$ From issues-reply at bitbucket.org Mon Jan 20 22:18:54 2020 From: issues-reply at bitbucket.org (Jaktrep von Schnitzelmeyer) Date: Tue, 21 Jan 2020 03:18:54 +0000 (UTC) Subject: [pypy-issue] Issue #3158: Installing scipy fails with "ImportError: [...] undefined symbol: cblas_sgemm" on PyPy 3.6 on Arch Linux (pypy/pypy) Message-ID: <20200121031854.33100.28727@celery-worker-109.ash1.bb-inf.net> New issue 3158: Installing scipy fails with "ImportError: [...] undefined symbol: cblas_sgemm" on PyPy 3.6 on Arch Linux https://bitbucket.org/pypy/pypy/issues/3158/installing-scipy-fails-with-importerror Jaktrep von Schnitzelmeyer: The error is appended below. I have ensured that I have cblas, openblas, lapack and lapacke installed on my system which, as I understand, should be everything I could reasonably need to have preinstalled to not get such an error. ``` ERROR: Command errored out with exit status 1: command: /usr/bin/pypy3 /home/fixgoats/.local/lib/pypy3.6/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmppnybtv8m cwd: /tmp/pip-install-ebnht1r3/scipy Complete output (44 lines): setup.py:420: UserWarning: Unrecognized setuptools command ('dist_info --egg-base /tmp/pip-modern-metadata-6ico2pqe'), proceeding with generating Cython sources and expanding templates ' '.join(sys.argv[1:]))) Traceback (most recent call last): File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/core/__init__.py", line 16, in from . import multiarray ImportError: /tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/core/multiarray.pypy36-pp73-x86_64-linux-gnu.so: undefined symbol: cblas_sgemm During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/fixgoats/.local/lib/pypy3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in main() File "/home/fixgoats/.local/lib/pypy3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main json_out['return_val'] = hook(**hook_input['kwargs']) File "/home/fixgoats/.local/lib/pypy3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 110, in prepare_metadata_for_build_wheel return hook(metadata_directory, config_settings) File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/setuptools/build_meta.py", line 156, in prepare_metadata_for_build_wheel self.run_setup() File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/setuptools/build_meta.py", line 243, in run_setup self).run_setup(setup_script=setup_script) File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/setuptools/build_meta.py", line 142, in run_setup exec(compile(code, __file__, 'exec'), locals()) File "setup.py", line 540, in setup_package() File "setup.py", line 516, in setup_package from numpy.distutils.core import setup File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/__init__.py", line 142, in from . import add_newdocs File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/core/__init__.py", line 26, in raise ImportError(msg) ImportError: Importing the multiarray numpy extension module failed. Most likely you are trying to import a failed build of numpy. If you're working with a numpy git repo, try `git clean -xdf` (removes all files not under version control). Otherwise reinstall numpy. Original error was: /tmp/pip-build-env-b0vqctdk/overlay/site-packages/numpy/core/multiarray.pypy36-pp73-x86_64-linux-gnu.so: undefined symbol: cblas_sgemm ---------------------------------------- ERROR: Command errored out with exit status 1: /usr/bin/pypy3 /home/fixgoats/.local/lib/pypy3.6/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmppnybtv8m Check the logs for full command output. ``` ? From cfbolz at gmx.de Wed Jan 22 02:45:09 2020 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 22 Jan 2020 08:45:09 +0100 Subject: [pypy-issue] Issue #3094: sys.setrecursionlimit(int(10e8)) results in MemoryError since 7.2 release. (pypy/pypy) In-Reply-To: <20191016071227.36497.71987@app-147.ash1.bb-inf.net> References: <20191016071227.36497.71987@app-147.ash1.bb-inf.net> Message-ID: Hi Chris! I agree that raising a MemoryError is a debatable way to report the problem, but in general it is not safe to call setrecursionlimit with an arbitrarily high value, as that can lead to segfaults. This is definitely also true on CPython. The documentation says: 'The highest possible limit is platform-dependent. A user may need to set the limit higher when they have a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash.' What are you trying to achieve? Why is a very deep recursion limit necessary here, and why can't you pick a more realistic number? Cheers, Carl Friedrich From issues-reply at bitbucket.org Fri Jan 24 17:23:43 2020 From: issues-reply at bitbucket.org (Bernat Gabor) Date: Fri, 24 Jan 2020 22:23:43 +0000 (UTC) Subject: [pypy-issue] Issue #3159: pypy3.6-7.3.0 venv fails with --copies on Linux (pypy/pypy) Message-ID: <20200124222343.6101.94121@celery-worker-110.ash1.bb-inf.net> New issue 3159: pypy3.6-7.3.0 venv fails with --copies on Linux https://bitbucket.org/pypy/pypy/issues/3159/pypy36-730-venv-fails-with-copies-on-linux Bernat Gabor: ``` pypy3 -m venv --without-pip --copies env2 Error: [Errno 21] Is a directory: '/home/parallels/.pyenv/versions/pypy3.6-7.3.0/bin/../lib/tk' parallels at parallels-Parallels-Virtual-Platform:~/git/virtualenv$ pypy3 --version Python 3.6.9 (1608da62bfc7, Dec 23 2019, 10:50:04) [PyPy 7.3.0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] ``` Confirmed does not fail with pypy3.6 < 7.3.0 From issues-reply at bitbucket.org Tue Jan 28 15:11:30 2020 From: issues-reply at bitbucket.org (Seth Troisi) Date: Tue, 28 Jan 2020 20:11:30 +0000 (UTC) Subject: [pypy-issue] Issue #3160: structseq.h missing from Python.h (pypy/pypy) Message-ID: <20200128201129.12027.14885@app-137.ash1.bb-inf.net> New issue 3160: structseq.h missing from Python.h https://bitbucket.org/pypy/pypy/issues/3160/structseqh-missing-from-pythonh Seth Troisi: In 2010 cpython added `#include "structseq.h"` into `Python.h` see [this commit](https://github.com/python/cpython/commit/71c23d447322307572fbe0ca68b61fad97e10021). I diffed pypy/module/cpyext/include/Python.h? and ?cpython/Include/Python.h? and they most matched. I don?t fully understanding the relation between PyPy and cpython and I apologize if this is a silly question, but should PyPy also move the include into Python.h? From issues-reply at bitbucket.org Wed Jan 29 09:04:12 2020 From: issues-reply at bitbucket.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=) Date: Wed, 29 Jan 2020 14:04:12 +0000 (UTC) Subject: [pypy-issue] Issue #3161: set is missing __r*__ (rand, ror...) methods (pypy/pypy) Message-ID: <20200129140411.17102.93565@celery-worker-110.ash1.bb-inf.net> New issue 3161: set is missing __r*__ (rand, ror...) methods https://bitbucket.org/pypy/pypy/issues/3161/set-is-missing-__r-__-rand-ror-methods Micha? G?rny: While attempting to import [snakeoil](https://github.com/pkgcore/snakeoil) with PyPy3, I?ve been getting errors such as the following: ``` ________________________________________________ ERROR collecting tests/module/test_containers.py _________________________________________________ tests/module/test_containers.py:5: in from snakeoil import containers .tox/pypy3/site-packages/snakeoil/containers.py:41: in class SetMixin(object): .tox/pypy3/site-packages/snakeoil/containers.py:59: in SetMixin @steal_docs(set) .tox/pypy3/site-packages/snakeoil/klass.py:598: in inner obj = getattr(target, target_name) E AttributeError: type object 'set' has no attribute '__rand__' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ``` FWICS, the missing methods for `set` objects include `__rand__`, `__ror__`, `__rxor__`, `__rsub__`, `__radd__`. From issues-reply at bitbucket.org Wed Jan 29 12:27:27 2020 From: issues-reply at bitbucket.org (Antonio Cuni) Date: Wed, 29 Jan 2020 17:27:27 +0000 (UTC) Subject: [pypy-issue] Issue #3162: GreenletExit not thrown when a greenlet is garbage-collected (pypy/pypy) Message-ID: <20200129172727.16550.31051@celery-worker-109.ash1.bb-inf.net> New issue 3162: GreenletExit not thrown when a greenlet is garbage-collected https://bitbucket.org/pypy/pypy/issues/3162/greenletexit-not-thrown-when-a-greenlet-is Antonio Cuni: ```python import greenlet import gc class A(object): def __del__(self): print 'A.__del__' def g1(): try: print 'g1: begin' a = A() print 'g1: switching' MAIN.switch() except greenlet.GreenletExit: print 'g1: GreenletExit' finally: print 'g1: finally' def main(): global MAIN MAIN = greenlet.getcurrent() greenlet.greenlet(g1).switch() gc.collect() main() ``` These are the results on CPython and PyPy; `A.__del__` is used just to show that the greenlet is actually garbage collected. ``` $ python green.py g1: begin g1: switching g1: GreenletExit g1: finally A.__del__ $ pypy green.py g1: begin g1: switching A.__del__ ``` ? The following patch seems to be enough to fix the problem; however, since it?s a good practice to be very careful when dealing with greenlets and continuelets, I?d like some feeback before committing it: ```diff diff --git a/lib_pypy/greenlet.py b/lib_pypy/greenlet.py --- a/lib_pypy/greenlet.py +++ b/lib_pypy/greenlet.py @@ -47,6 +47,9 @@ if parent is not None: self.parent = parent + def __del__(self): + self.throw() + def switch(self, *args, **kwds): "Switch execution to this greenlet, optionally passing the values " "given as argument(s). Returns the value passed when switching back." ``` ? From issues-reply at bitbucket.org Fri Jan 31 05:42:00 2020 From: issues-reply at bitbucket.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 31 Jan 2020 10:42:00 +0000 (UTC) Subject: [pypy-issue] Issue #3163: error: vmprof_common.o: multiple definition of '_PyThreadState_Current' (gcc 10 -fno-common) (pypy/pypy) Message-ID: <20200131104200.37461.61006@celery-worker-109.ash1.bb-inf.net> New issue 3163: error: vmprof_common.o: multiple definition of '_PyThreadState_Current' (gcc 10 -fno-common) https://bitbucket.org/pypy/pypy/issues/3163/error-vmprof_commono-multiple-definition Miro Hron?ok: Hello, in Fedora, we have recently updated to gcc 10. It now [defaults](https://gcc.gnu.org/gcc-10/porting_to.html#common) to?`-fno-common`. When we attempt to build pypy3.6 7.3.0, we have the following error: ``` error: vmprof_common.o: multiple definition of '_PyThreadState_Current' ``` Full logs attached $root.log contains information about versions of other packages$. This happens only on i686 and x86\_64. We can temporarily build pypy with -fcommon, so this does not really block us, I juts thought reporting here is a good idea. From issues-reply at bitbucket.org Fri Jan 31 17:20:29 2020 From: issues-reply at bitbucket.org (Armin Rigo) Date: Fri, 31 Jan 2020 22:20:29 +0000 (UTC) Subject: [pypy-issue] Issue #3164: unicodedata missing DerivedNormalizationProps-.tx (pypy/pypy) Message-ID: <20200131222029.3707.27488@app-137.ash1.bb-inf.net> New issue 3164: unicodedata missing DerivedNormalizationProps-.tx https://bitbucket.org/pypy/pypy/issues/3164/unicodedata-missing Armin Rigo: