From issues-reply at bitbucket.org  Sun Apr  1 04:51:40 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sun, 01 Apr 2018 08:51:40 +0000 (UTC)
Subject: [pypy-issue] Issue #2780: signal.default_int_handler differences
 (pypy/pypy)
Message-ID: <20180401085140.31216.7965@celery-worker-106.ash1.bb-inf.net>

New issue 2780: signal.default_int_handler differences
https://bitbucket.org/pypy/pypy/issues/2780/signaldefault_int_handler-differences

Christoph Reiter:

Afaics it's not documented so feel free to close.

CPython:
```
#!python

>>> signal.default_int_handler()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt
>>> 

```

PyPy:
```
#!python

>>>> signal.default_int_handler()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: default_int_handler() takes exactly 2 arguments (0 given)
>>>> 

```



From issues-reply at bitbucket.org  Sun Apr  1 14:23:40 2018
From: issues-reply at bitbucket.org (pv)
Date: Sun, 01 Apr 2018 18:23:40 +0000 (UTC)
Subject: [pypy-issue] Issue #2781: memory leak in pypy default branch as of
 20180401 (pypy/pypy)
Message-ID: <20180401182339.26478.81997@celery-worker-109.ash1.bb-inf.net>

New issue 2781: memory leak in pypy default branch as of 20180401
https://bitbucket.org/pypy/pypy/issues/2781/memory-leak-in-pypy-default-branch-as-of

pv:

The following seems to leak memory on current pypy default branch (045483a22d66):
```
# pypy -mensurepip
# pypy -mpip install numpy==1.14.2
# pypy runthis.py
# -> memory usage increases, without upper bound
import numpy as np
x = np.zeros([1])
while True:
    x - x
```
The memory usage seems to grow without upper bound. This does not occur on pypy-5.10.0, for which the memory usage stays constant. The issue is also visible in current py3.5 branch.



From issues-reply at bitbucket.org  Mon Apr  2 08:23:13 2018
From: issues-reply at bitbucket.org (Andrew Stepanov)
Date: Mon, 02 Apr 2018 12:23:13 +0000 (UTC)
Subject: [pypy-issue] Issue #2782: extending bytearray is x30 slower than
 CPython (pypy/pypy)
Message-ID: <20180402122313.14936.87572@celery-worker-109.ash1.bb-inf.net>

New issue 2782: extending bytearray is x30 slower than CPython
https://bitbucket.org/pypy/pypy/issues/2782/extending-bytearray-is-x30-slower-than

Andrew Stepanov:

The following code runs x30 slower on PyPy v5.10.1 (both 2 and 3) vs CPython
```python
b = b"\x01\x02" * 2500
x = bytearray()
for i in range(1000000):
    x.extend(b)
```
On my machine, it takes 0.55 sec to finish under CPython and 14.300 sec to finish under PyPy.



From issues-reply at bitbucket.org  Tue Apr  3 03:24:27 2018
From: issues-reply at bitbucket.org (B S)
Date: Tue, 03 Apr 2018 07:24:27 +0000 (UTC)
Subject: [pypy-issue] Issue #2783: socket.recvfrom raise UnicodeDecodeError
 in Ubuntu 14.04 (pypy/pypy)
Message-ID: <20180403072427.2745.53300@celery-worker-106.ash1.bb-inf.net>

New issue 2783: socket.recvfrom raise UnicodeDecodeError in Ubuntu 14.04
https://bitbucket.org/pypy/pypy/issues/2783/socketrecvfrom-raise-unicodedecodeerror-in

B S:

pypy3: pypy3-v5.10.1-linux64.tar.bz2
scapy: 2.4.0

```
Python 3.5.3 (3f6eaa010fce, Jan 11 2018, 04:44:35)
[PyPy 5.10.1 with GCC 6.2.0 20160901] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> from scapy.all import *
>>>> sniff()
???? 65535 <class 'int'>
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/pypy3/site-packages/scapy/sendrecv.py", line 767, in sniff
    p = s.recv()
  File "/usr/local/pypy3/site-packages/scapy/arch/linux.py", line 601, in recv
    r = self.ins.recvfrom(x)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xee in position 0: invalid continuation byte
>>>>
```

I test sniff packet in `Windows 10 64bit`, `macOS 10.12.6` with pypy3, all works fine, but this issue occurs in `Ubuntu 16.04` and `Ubuntu 14.04`.

Its seem there are some coding issue in `rsocket`.



From issues-reply at bitbucket.org  Tue Apr  3 03:55:27 2018
From: issues-reply at bitbucket.org (Carl Friedrich Bolz-Tereick)
Date: Tue, 03 Apr 2018 07:55:27 +0000 (UTC)
Subject: [pypy-issue] Issue #2784: re is much slower on PyPy2 than on PyPy3
 (pypy/pypy)
Message-ID: <20180403075526.880.30365@celery-worker-108.ash1.bb-inf.net>

New issue 2784: re is much slower on PyPy2 than on PyPy3
https://bitbucket.org/pypy/pypy/issues/2784/re-is-much-slower-on-pypy2-than-on-pypy3

Carl Friedrich Bolz-Tereick:

On the benchmark bm_regex_v8.py which measures re performance, PyPy2 is much slower than Pypy3, see here: https://hackernoon.com/which-is-the-fastest-version-of-python-2ae7c61a6b2b



From issues-reply at bitbucket.org  Tue Apr  3 14:00:04 2018
From: issues-reply at bitbucket.org (Maciej Fijalkowski)
Date: Tue, 03 Apr 2018 18:00:04 +0000 (UTC)
Subject: [pypy-issue] Issue #2785: PyPy3 slowdown when .pyc files are
 present (pypy/pypy)
Message-ID: <20180403180004.23262.57852@celery-worker-109.ash1.bb-inf.net>

New issue 2785: PyPy3 slowdown when .pyc files are present
https://bitbucket.org/pypy/pypy/issues/2785/pypy3-slowdown-when-pyc-files-are-present

Maciej Fijalkowski:

Instructions here: https://gist.github.com/1st1/57d979e1e58948a7e523754a3d02a57d



From issues-reply at bitbucket.org  Wed Apr  4 17:14:20 2018
From: issues-reply at bitbucket.org (Joshua Oreman)
Date: Wed, 04 Apr 2018 21:14:20 +0000 (UTC)
Subject: [pypy-issue] Issue #2786: pypy3 interpreter segfault somewhere
 around async/gc/finalization (pypy/pypy)
Message-ID: <20180404211419.1901.76179@celery-worker-109.ash1.bb-inf.net>

New issue 2786: pypy3 interpreter segfault somewhere around async/gc/finalization
https://bitbucket.org/pypy/pypy/issues/2786/pypy3-interpreter-segfault-somewhere

Joshua Oreman:

The async_generator package provides pure-Python async generators with semantics as similar as possible to the native ones in CPython 3.6, with the goal of supporting PyPy and CPython 3.5. It's located at https://github.com/python-trio/async_generator.

I'm working on adding support to async_generator for PEP 525 finalization hooks, and ran into a PyPy interpreter crash. I've merged all the dependencies into one file without any CPython-specifics, and it still reliably reproduces the crash, with or without `--jit off`; it's attached below. (The full change from which this was extracted is https://github.com/python-trio/async_generator/pull/14; it's not merged into async_generator yet.)

I'm using OS X 10.13.3, with pypy3 installed using Homebrew:
```
$ pypy3 asyncgenissue.py
mock_sleep
mock_sleep
Segmentation fault: 11

$ pypy3
Python 3.5.3 (3f6eaa010fce78cc7973bdc1dfdb95970f08fed2, Jan 13 2018, 18:14:01)
[PyPy 5.10.1 with GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
>>> print("\n".join("{}: {}".format(*elem) for elem in __import__("sys").pypy_translation_info.items()))
objspace.usemodules.__builtin__: False
[lots of other objspace.usemodules.something: True]
objspace.usemodules.micronumpy: False
objspace.allworkingmodules: True
objspace.extmodules: None
objspace.translationmodules: False
objspace.soabi: None
objspace.honor__builtins__: False
objspace.disable_call_speedhacks: False
objspace.disable_entrypoints: False
objspace.fstrings: True
objspace.hash: siphash24
objspace.std.withtproxy: True
objspace.std.withprebuiltint: False
objspace.std.prebuiltintfrom: -5
objspace.std.prebuiltintto: 100
objspace.std.withsmalllong: False
objspace.std.withspecialisedtuple: True
objspace.std.withliststrategies: True
objspace.std.withmethodcachecounter: False
objspace.std.methodcachesizeexp: 11
objspace.std.intshortcut: True
objspace.std.optimized_list_getitem: True
objspace.std.newshortcut: False
translating: True
translation.continuation: True
translation.type_system: lltype
translation.backend: c
translation.shared: True
translation.log: True
translation.gc: incminimark
translation.gctransformer: framework
translation.gcremovetypeptr: True
translation.gcrootfinder: shadowstack
translation.thread: True
translation.sandbox: False
translation.rweakref: True
translation.jit: True
translation.jit_backend: auto
translation.jit_profiler: off
translation.jit_opencoder_model: normal
translation.check_str_without_nul: True
translation.verbose: True
translation.cc: clang
translation.profopt: False
translation.profoptargs: None
translation.instrument: False
translation.countmallocs: False
translation.fork_before: None
translation.dont_write_c_files: False
translation.instrumentctl: None
translation.output: None
translation.secondaryentrypoints: cpyext,main
translation.dump_static_data_info: False
translation.no__thread: True
translation.make_jobs: 3
translation.list_comprehension_operations: True
translation.withsmallfuncsets: 5
translation.taggedpointers: False
translation.keepgoing: False
translation.lldebug: False
translation.lldebug0: False
translation.lto: False
translation.icon: pypy.ico
translation.libname: None
translation.backendopt.inline: True
translation.backendopt.inline_threshold: 32.4
translation.backendopt.inline_heuristic: rpython.translator.backendopt.inline.inlining_heuristic
translation.backendopt.print_statistics: False
translation.backendopt.merge_if_blocks: True
translation.backendopt.mallocs: True
translation.backendopt.constfold: True
translation.backendopt.profile_based_inline: None
translation.backendopt.profile_based_inline_threshold: 32.4
translation.backendopt.profile_based_inline_heuristic: rpython.translator.backendopt.inline.inlining_heuristic
translation.backendopt.clever_malloc_removal: False
translation.backendopt.clever_malloc_removal_threshold: 32.4
translation.backendopt.clever_malloc_removal_heuristic: rpython.translator.backendopt.inline.inlining_heuristic
translation.backendopt.remove_asserts: False
translation.backendopt.really_remove_asserts: False
translation.backendopt.stack_optimization: True
translation.backendopt.storesink: True
translation.backendopt.replace_we_are_jitted: False
translation.backendopt.none: None
translation.platform: host
```

I gave about an hour's effort to trying to get a debug version of pypy translated, and gave up when I got `[translation:ERROR] Exception: 'no_collect' function can trigger collection: <function _siphash24 at 0x000000010b2afcb8>`.



From issues-reply at bitbucket.org  Thu Apr  5 03:44:05 2018
From: issues-reply at bitbucket.org (Guillaume Valadon)
Date: Thu, 05 Apr 2018 07:44:05 +0000 (UTC)
Subject: [pypy-issue] Issue #2787: pypy3 sockname error (pypy/pypy)
Message-ID: <20180405074405.7668.51978@celery-worker-110.ash1.bb-inf.net>

New issue 2787: pypy3 sockname error
https://bitbucket.org/pypy/pypy/issues/2787/pypy3-sockname-error

Guillaume Valadon:

I found an error with socket.sockname() while using pypy3 with Scapy. 

Here is how to reproduce it:
```
#!shell

$ pypy3 --version
Python 3.5.3 (3f6eaa010fce78cc7973bdc1dfdb95970f08fed2, Feb 12 2018, 22:20:44)
[PyPy 5.10.1 with GCC 7.3.0]

$ cat test_pypy3.py 
import socket
ETH_P_ALL = 3
ins = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(ETH_P_ALL))
ins.bind(("eno1", ETH_P_ALL))
print(ins.getsockname())
ins.close()

$ sudo pypy3 test_pypy3.py
[sudo] password for guedou: 
Traceback (most recent call last):
  File "test_pypy3.py", line 5, in <module>
    print(ins.getsockname())
UnicodeDecodeError: 'utf8' codec can't decode byte 0xdc in position 0: invalid continuation byte
```
The same code works fine with Python 2.7, 3.6 and pypy.



From issues-reply at bitbucket.org  Thu Apr  5 13:29:19 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Thu, 05 Apr 2018 17:29:19 +0000 (UTC)
Subject: [pypy-issue] Issue #2788: cpyext: writing readonly attribute raises
 TypeError instead of AttributeError (pypy/pypy)
Message-ID: <20180405172918.29096.37150@celery-worker-106.ash1.bb-inf.net>

New issue 2788: cpyext: writing readonly attribute raises TypeError instead of AttributeError
https://bitbucket.org/pypy/pypy/issues/2788/cpyext-writing-readonly-attribute-raises

Christoph Reiter:

An attribute defined through tp_getset with a PyGetSetDef struct where the attribute entry has a NULL setter leads to the following differences:

CPython:

```
#!python
Traceback (most recent call last):   File "a.py", line 3, in <module> 
GObject.TYPE_STRING.name = "foo" AttributeError: attribute 'name' of 'gobject.GType' objects is not writable
```

PyPy:
```
#!python
Traceback (most recent call last):
  File "a.py", line 3, in <module>
    GObject.TYPE_STRING.name = "foo"
TypeError: readonly attribute
```



From issues-reply at bitbucket.org  Thu Apr  5 17:56:12 2018
From: issues-reply at bitbucket.org (pv)
Date: Thu, 05 Apr 2018 21:56:12 +0000 (UTC)
Subject: [pypy-issue] Issue #2789: Crash (cpyext?) in pypy3 (as of
 2018-04-05) at numpy object array dealloc (pypy/pypy)
Message-ID: <20180405215612.35849.60316@celery-worker-109.ash1.bb-inf.net>

New issue 2789: Crash (cpyext?) in pypy3 (as of 2018-04-05) at numpy object array dealloc
https://bitbucket.org/pypy/pypy/issues/2789/crash-cpyext-in-pypy3-as-of-2018-04-05-at

pv:

The following code crashes in pypy3 (bcbefe2f5e14, py3.5 branch as of 2018-04-05):
https://github.com/pv/crash-pypy-1/tree/3e47f83de863ab21dc2dac412963982104638032
using `pip install numpy==1.14.2`.

pypy3-5.10.1 doesn't crash.

gdb says
```
$ gdb --args pypy3 crash.py
...
/home/pauli/prj/scipy/scipy/tmp/pypy3bug/idl.py:281: UserWarning: Not able to verify number of bytes from header
  warnings.warn("Not able to verify number of bytes from header")
0 [55 66]
1 [55 66]
2 [55 66]
3 [55 66]
4 [55 66]
5 [55 66]

Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  0x00007ffff3e54168 in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007ffff3e56f00 in _int_malloc () from /lib64/libc.so.6
#2  0x00007ffff3e587e3 in malloc () from /lib64/libc.so.6
#3  0x00007fffe479f00a in PyArray_IterNew (obj=0x1c3b430) at numpy/core/src/multiarray/iterators.c:290
#4  0x00007fffe483403e in PyArray_XDECREF (mp=0x1c3b430) at numpy/core/src/multiarray/refcount.c:168
#5  0x00007fffe46d81ec in array_dealloc (self=0x1c3b430) at numpy/core/src/multiarray/arrayobject.c:514
#6  0x00007ffff6429bfd in _PyPy_tuple_dealloc () from /usr/local/stow/pypy3+20180405/lib/pypy3+20180405/bin/libpypy3-c.so
#7  0x00007ffff5b35d8a in pypy_g.rawrefcount_perform () from /usr/local/stow/pypy3+20180405/lib/pypy3+20180405/bin/libpypy3-c.so
...
```
That part of Numpy code is trying to DECREF items contained in an object array, but not clear if the issue is actually at that point.

(Didn't manage to reduce this so far to a simpler testcase, sorry, just extracted from scipy test suite. Interestingly, numpy test suite doesn't crash.)



From issues-reply at bitbucket.org  Fri Apr  6 11:53:52 2018
From: issues-reply at bitbucket.org (Ziqi Liu)
Date: Fri, 06 Apr 2018 15:53:52 +0000 (UTC)
Subject: [pypy-issue] Issue #2790: pypy3 reading big file very slow
 (pypy/pypy)
Message-ID: <20180406155351.25573.92027@celery-worker-106.ash1.bb-inf.net>

New issue 2790: pypy3 reading big file very slow
https://bitbucket.org/pypy/pypy/issues/2790/pypy3-reading-big-file-very-slow

Ziqi Liu:

I'm trying to use pypy3 to improve the efficiency of my code. The basic flow is reading a very big file and do some processing and output.

pypy3 do improve the speed of the processing part, but very very slow in reading big file, much more slower than normal python3.....I suppose pypy3 doesn't compile it correctly, maybe I need to add some args to improve the reading file efficiency?

I read the file with built-in open function
```
with open(inF1, 'r') as f:
    gtf = [line.split('\t') for line in f]
```



From issues-reply at bitbucket.org  Fri Apr  6 12:41:58 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Fri, 06 Apr 2018 16:41:58 +0000 (UTC)
Subject: [pypy-issue] Issue #2791: PyPy3: use W_IntObject instead of
 W_LongObject whenever possible (pypy/pypy)
Message-ID: <20180406164158.15611.86625@celery-worker-106.ash1.bb-inf.net>

New issue 2791: PyPy3: use W_IntObject instead of W_LongObject whenever possible
https://bitbucket.org/pypy/pypy/issues/2791/pypy3-use-w_intobject-instead-of

Ronan Lamy:

In pypy3, we have 2 implementations for app-level int objects: W_IntObject and W_LongObject. The former is similar to Python  2 ints and JITs nicely, the latter wraps `rpython.rlib.rbigint` and is much slower.

Issue #2785 fixed one case where using W_LongObject instead of W_IntObject caused a major user-visible slowdown, but there are many more places where we create W_LongObject indiscriminately. It would probably make sense to always try to convert to W_IntObject. We should at least make `space.newlong == space.newlong_from_rarith_int == space.newint`.



From issues-reply at bitbucket.org  Sat Apr  7 06:13:37 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sat, 07 Apr 2018 10:13:37 +0000 (UTC)
Subject: [pypy-issue] Issue #2792: _PyTuple_Resize crashes (regression in
 master) (pypy/pypy)
Message-ID: <20180407101336.39683.50414@celery-worker-108.ash1.bb-inf.net>

New issue 2792: _PyTuple_Resize crashes (regression in master)
https://bitbucket.org/pypy/pypy/issues/2792/_pytuple_resize-crashes-regression-in

Christoph Reiter:

This seems to crash with current master, but works with 5.10:

```
#!C
PyObject *foo = PyTuple_New(1);
_PyTuple_Resize (foo, 1);
```



From issues-reply at bitbucket.org  Sat Apr  7 16:13:16 2018
From: issues-reply at bitbucket.org (pv)
Date: Sat, 07 Apr 2018 20:13:16 +0000 (UTC)
Subject: [pypy-issue] Issue #2793: cpyext class subclasses lose attributes
 (pypy/pypy)
Message-ID: <20180407201316.12461.4676@celery-worker-105.ash1.bb-inf.net>

New issue 2793: cpyext class subclasses lose attributes
https://bitbucket.org/pypy/pypy/issues/2793/cpyext-class-subclasses-lose-attributes

pv:

On pypy3 (bcbefe2f5e14, 2018-04-05) the following code fails
```
import numpy as np
from numpy.testing import assert_allclose

x = np.matrix(np.random.rand(12, 12))

for j in range(20000):
    assert_allclose(x, x)
```
with
```
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File ".../env/site-packages/numpy/testing/nose_tools/utils.py", line 1396, in assert_allclose
    verbose=verbose, header=header, equal_nan=equal_nan)
  File ".../env/site-packages/numpy/testing/nose_tools/utils.py", line 769, in assert_array_compare
    reduced = val.ravel()
  File ".../env/site-packages/numpy/matrixlib/defmatrix.py", line 1020, in ravel
    return N.ndarray.ravel(self, order=order)
  File ".../env/site-packages/numpy/matrixlib/defmatrix.py", line 260, in __array_finalize__
    if (isinstance(obj, matrix) and obj._getitem): return
AttributeError: 'matrix' object has no attribute '_getitem'
```
The `matrix` class seem to lose some of its attributes, apparently when the jit kicks in.

(I guess this was a known bug, but I didn't see an open issue for it.)



From issues-reply at bitbucket.org  Sun Apr  8 10:02:17 2018
From: issues-reply at bitbucket.org (=?utf-8?b?0JrQsNGA0LjQvNC+0LIg0JTQtdC90LjRgQ==?=)
Date: Sun, 08 Apr 2018 14:02:17 +0000 (UTC)
Subject: [pypy-issue] Issue #2794: PIP: ssl module in Python is not
 available (pypy/pypy)
Message-ID: <20180408140217.36671.45480@celery-worker-109.ash1.bb-inf.net>

New issue 2794: PIP: ssl module in Python is not available
https://bitbucket.org/pypy/pypy/issues/2794/pip-ssl-module-in-python-is-not-available

??????? ?????:

Hi) I Have a problev with installing packages from PIP. What did i do:

* I download pypy from pypy.org: Linux x86-64 binary (64bit, tar.bz2 built on Ubuntu 12.04 - 16.04)
* Extract package to my `/opt/pypy3` folder
* Create simlink from `/opt/pypy3/bin/pypy3` to `/usr/local/bin/pypy3`
* Create virtualenv `virtualenv -p pypy3 pypy`, Also, i tried `virtualenv -p /opt/pypy3/bin/pypy3`
* Activate virtualenv `source /pypy/bin/activate`

When i fried to install packages from PIP, i take error:

```
$ pip install -r requirements.txt
pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Collecting Django==1.11.11 (from -r requirements.txt (line 1))
  Could not fetch URL https://pypi.python.org/simple/django/: There was a problem confirming the ssl certificate: Can't connect to HTTPS URL because the SSL module is not available. - skipping
  Could not find a version that satisfies the requirement Django==1.11.11 (from -r requirements.txt (line 1)) (fromversions: )
No matching distribution found for Django==1.11.11 (from -r requirements.txt (line 1))
```

Also, i tried `pip install Django`. What i'm missed?



From issues-reply at bitbucket.org  Sun Apr  8 14:27:36 2018
From: issues-reply at bitbucket.org (Garland Huang)
Date: Sun, 08 Apr 2018 18:27:36 +0000 (UTC)
Subject: [pypy-issue] Issue #2795: Installing numpy and pandas for PyPy3.5
 v5.10.1 (pypy/pypy)
Message-ID: <20180408182736.40526.18298@celery-worker-106.ash1.bb-inf.net>

New issue 2795: Installing numpy and pandas for PyPy3.5 v5.10.1
https://bitbucket.org/pypy/pypy/issues/2795/installing-numpy-and-pandas-for-pypy35

Garland Huang:

Hi all,

I'm trying to port my code to pypy and I'm experiencing issues with installing numpy and pandas.

For numpy I'm following https://pypy.org/download.html#installing and have tried all the options but they all fail. In particular when I run:

./pypy-xxx/bin/pip install cython numpy

I get the error:

Command "/usr/local/bin/pypy3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-m_dwzb9u/numpy/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-xpvk_cea-record/install-record.txt --single-version-externally-managed --compile" failed with error code -9 in /tmp/pip-build-m_dwzb9u/numpy/

Similarly, when I try to install pandas with:

./pypy-xxx/bin/pip install cython pandas

I get the error:

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-efuao0xv/pandas/

I've tried some of the regular fixes such as updating setuptools  but it hasn't resolved the issues and I'm still unable to install any of the modules. Any help would be great. Thanks.



From issues-reply at bitbucket.org  Mon Apr  9 09:44:12 2018
From: issues-reply at bitbucket.org (Maik Riechert)
Date: Mon, 09 Apr 2018 13:44:12 +0000 (UTC)
Subject: [pypy-issue] Issue #2796: socket.inet_pton missing on Windows
 (pypy/pypy)
Message-ID: <20180409134411.39714.29954@celery-worker-106.ash1.bb-inf.net>

New issue 2796: socket.inet_pton missing on Windows
https://bitbucket.org/pypy/pypy/issues/2796/socketinet_pton-missing-on-windows

Maik Riechert:

AttributeError: module 'socket' has no attribute 'inet_pton'

CPython has this function since 3.4.



From issues-reply at bitbucket.org  Wed Apr 11 19:12:28 2018
From: issues-reply at bitbucket.org (pv)
Date: Wed, 11 Apr 2018 23:12:28 +0000 (UTC)
Subject: [pypy-issue] Issue #2797: cpyext: cython-0.28.1 output fails on
 pypy (pypy/pypy)
Message-ID: <20180411231227.4643.49506@celery-worker-108.ash1.bb-inf.net>

New issue 2797: cpyext: cython-0.28.1 output fails on pypy
https://bitbucket.org/pypy/pypy/issues/2797/cpyext-cython-0281-output-fails-on-pypy

pv:

The following Cython program fails with Cython-0.28.1 + pypy 3.5 @ 2018-04-11 (e6d85e030f12):
```
def doit(bytes options):
    x = set()
    x.update(options.split())
    if b"Qz" in x:
        x.remove(b"Qz")

doit(b"Qbb Qc Qz Q12")
```
as
```
$ cython3 bad.pyx
$ gcc -I/usr/local/lib/pypy+20180411/include -shared -fPIC -o bad.pypy3-61-x86_64-linux-gnu.so bad.c
$ pypy3 -c 'import bad'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "bad.pyx", line 8, in init bad
    doit(b"Qbb Qc Qz Q12")
  File "bad.pyx", line 6, in bad.doit
    x.remove(b"Qz")
KeyError: b'Qz'
```
Not sure yet if it's cpyext or Cython issue.

Fails also on pypy3-5.10.1 and pypy2-5.10.0.



From issues-reply at bitbucket.org  Mon Apr 16 15:22:01 2018
From: issues-reply at bitbucket.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 16 Apr 2018 19:22:01 +0000 (UTC)
Subject: [pypy-issue] Issue #2798: Creating a global-variable PyObject in a
 C++ extension crashes while dlopening (pypy/pypy)
Message-ID: <20180416192200.9616.55211@celery-worker-107.ash1.bb-inf.net>

New issue 2798: Creating a global-variable PyObject in a C++ extension crashes while dlopening
https://bitbucket.org/pypy/pypy/issues/2798/creating-a-global-variable-pyobject-in-a-c

Hrvoje Nik?i?:

The attached module crashes when compiled and imported from pypy 5.10.0.

The crash is apparently triggered by global variable initialization:

```
#!c++

// global variable - crash goes away without it
PyObject *global = PyInt_FromLong(42);
```

This kind of global initialization is frequently used in our in-house CPython C++ extensions[1]. It is safe for dynamically loaded extensions because by the time the shared object gets dlopen-ed, Python has been initialized and the GIL acquired. In PyPy 5.10.0 it consistently crashes before executing the module initialization function.

Is this a bug in cpyext, or is the above pattern forbidden? Is there a workaround to make it work?

[1]
The example is, of course, simplified - in actual code, the object would be a RAII wrapper object whose constructor invokes PyInt_FromLong. It is used in many different extensions and cannot be easily replaced with, say, a function that lazily constructs and returns an object.



From issues-reply at bitbucket.org  Thu Apr 19 04:53:58 2018
From: issues-reply at bitbucket.org (chris harrod)
Date: Thu, 19 Apr 2018 08:53:58 +0000 (UTC)
Subject: [pypy-issue] Issue #2799: pypy3 pymongo SSL Handshake failed
 (pypy/pypy)
Message-ID: <20180419085357.7032.33829@celery-worker-109.ash1.bb-inf.net>

New issue 2799: pypy3 pymongo SSL Handshake failed
https://bitbucket.org/pypy/pypy/issues/2799/pypy3-pymongo-ssl-handshake-failed

chris harrod:

when i try to connect to a remote MongoDB on atlas I received a warning the that ssl.enum_certificates() are not implemented, then the code crashed because the SSL handshake failed. 

Is there a work around to get this the work?

Thank you



From issues-reply at bitbucket.org  Fri Apr 20 19:16:09 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Fri, 20 Apr 2018 23:16:09 +0000 (UTC)
Subject: [pypy-issue] Issue #2800: Python 3.6: implement _ssl.SSLSession
 (pypy/pypy)
Message-ID: <20180420231609.37967.53379@celery-worker-107.ash1.bb-inf.net>

New issue 2800: Python 3.6: implement _ssl.SSLSession
https://bitbucket.org/pypy/pypy/issues/2800/python-36-implement-_sslsslsession

Ronan Lamy:

d3ea363 disabled importing it from _ssl to make ssl importable again, but this needs to be actually implemented. Cf. https://docs.python.org/3.6/library/ssl.html#ssl-session



From issues-reply at bitbucket.org  Fri Apr 20 20:08:03 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Sat, 21 Apr 2018 00:08:03 +0000 (UTC)
Subject: [pypy-issue] Issue #2801: Consolidate contribution guides
 (pypy/pypy)
Message-ID: <20180421000803.20566.32268@celery-worker-105.ash1.bb-inf.net>

New issue 2801: Consolidate contribution guides
https://bitbucket.org/pypy/pypy/issues/2801/consolidate-contribution-guides

Ronan Lamy:

We have (at least) 3 different "getting started" documents that cover mostly the same ground. We should refactor them into one, or two with clearly separate purposes.

http://pypy.readthedocs.io/en/latest/getting-started-dev.html
http://pypy.readthedocs.io/en/latest/how-to-contribute.html
http://pypy.readthedocs.io/en/latest/you-want-to-help.html



From issues-reply at bitbucket.org  Fri Apr 20 20:15:44 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Sat, 21 Apr 2018 00:15:44 +0000 (UTC)
Subject: [pypy-issue] Issue #2802: Move app-level tests from
 pypy/module/test_lib_pypy/ to extra_tests/ (pypy/pypy)
Message-ID: <20180421001543.26967.32271@celery-worker-106.ash1.bb-inf.net>

New issue 2802: Move app-level tests from pypy/module/test_lib_pypy/ to extra_tests/
https://bitbucket.org/pypy/pypy/issues/2802/move-app-level-tests-from-pypy-module

Ronan Lamy:

App-level tests located in `pypy/module/test_lib_pypy/` cannot run on the pypy3 branches. They need to be moved (also on the `default` branch, for consistency) to `extra_tests/`. Since they never ran on pypy3, some of them will need to be fixed.



From issues-reply at bitbucket.org  Sat Apr 21 12:34:18 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Sat, 21 Apr 2018 16:34:18 +0000 (UTC)
Subject: [pypy-issue] Issue #2803: zipimporter.__new__ should use unicode
 internally (pypy/pypy)
Message-ID: <20180421163417.34754.37995@celery-worker-109.ash1.bb-inf.net>

New issue 2803: zipimporter.__new__ should use unicode internally
https://bitbucket.org/pypy/pypy/issues/2803/zipimporter__new__-should-use-unicode

Ronan Lamy:

For compatibility with CPython, zipimporter.__new__ should use fsdecode on its argument instead of fsencode, and handle the filename as a unicode string internally.



From issues-reply at bitbucket.org  Sat Apr 21 16:26:17 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sat, 21 Apr 2018 20:26:17 +0000 (UTC)
Subject: [pypy-issue] Issue #2804: extended slice assignment differences
 (pypy/pypy)
Message-ID: <20180421202617.26552.41999@celery-worker-105.ash1.bb-inf.net>

New issue 2804: extended slice assignment differences
https://bitbucket.org/pypy/pypy/issues/2804/extended-slice-assignment-differences

Christoph Reiter:

```
a = []
a[::-1] = [42]
print(a)
```

CPython:
```
ValueError: attempt to assign sequence of size 1 to extended slice of size 0
```

PyPy: no error, it adds 42 to the list.



From issues-reply at bitbucket.org  Sat Apr 21 18:17:18 2018
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Sat, 21 Apr 2018 22:17:18 +0000 (UTC)
Subject: [pypy-issue] Issue #2805: AsyncActions can only .fire() once
 (pypy/pypy)
Message-ID: <20180421221717.28350.86242@celery-worker-110.ash1.bb-inf.net>

New issue 2805: AsyncActions can only .fire() once
https://bitbucket.org/pypy/pypy/issues/2805/asyncactions-can-only-fire-once

Ronan Lamy:

After a88536ae8554, an AsyncAction cannot be fired again until the fired_actions queue (`AbstractActionFlag._fired_actions_first`/`AbstractActionFlag._fired_actions_last`) is cleared.

However, when running `pytest pandas/tests/frame/test_to_csv.py -k chunking` with a pypy3 nightly, it appears that PyObjDeallocAction does exactly that, causing the assert in AbstractActionFlag._fired_actions_append() to fail.



From issues-reply at bitbucket.org  Sun Apr 22 13:03:58 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sun, 22 Apr 2018 17:03:58 +0000 (UTC)
Subject: [pypy-issue] Issue #2806: Calling tp_init does not call __init__
 (pypy/pypy)
Message-ID: <20180422170358.10498.57365@celery-worker-109.ash1.bb-inf.net>

New issue 2806: Calling tp_init does not call __init__
https://bitbucket.org/pypy/pypy/issues/2806/calling-tp_init-does-not-call-__init__

Christoph Reiter:

Minimal example extension: https://gist.github.com/lazka/871913fb1442d214e9f4d77d3ff7396c

>From what I see doing a `PyObject_CallMethod (obj, "__init__", NULL);` works just as well, so I'll use that instead.



From issues-reply at bitbucket.org  Sun Apr 22 18:41:16 2018
From: issues-reply at bitbucket.org (Roman Yurchak)
Date: Sun, 22 Apr 2018 22:41:16 +0000 (UTC)
Subject: [pypy-issue] Issue #2807: array.array fails to import in Cython
 (pypy/pypy)
Message-ID: <20180422224115.40130.98630@celery-worker-106.ash1.bb-inf.net>

New issue 2807: array.array fails to import in Cython
https://bitbucket.org/pypy/pypy/issues/2807/arrayarray-fails-to-import-in-cython

Roman Yurchak:

The following Cython example,

**example_array.pyx**
```py
import array
from cpython cimport array
```
that can be build with,
```
cythonize -a -i example_array.pyx
```
fails to import with PyPy 3.5.3 - 5.10.1 with the following traceback,
```
python -c 'import example_array' 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "array.pxd", line 58, in init example_array
ValueError: array.array has the wrong size, try recompiling. Expected 24, got 72
```

this was reported in the Cython project in https://github.com/cython/cython/issues/1818

It is also an issue that came up when building scikit-learn with PyPy https://github.com/scikit-learn/scikit-learn/pull/11010

cc @rlamy



From issues-reply at bitbucket.org  Wed Apr 25 09:05:27 2018
From: issues-reply at bitbucket.org (pv)
Date: Wed, 25 Apr 2018 13:05:27 +0000 (UTC)
Subject: [pypy-issue] Issue #2808: crypt() not defined in unistd.h breaks
 build on Fedora 28 (pypy/pypy)
Message-ID: <20180425130527.35600.17908@celery-worker-110.ash1.bb-inf.net>

New issue 2808: crypt() not defined in unistd.h breaks build on Fedora 28
https://bitbucket.org/pypy/pypy/issues/2808/crypt-not-defined-in-unistdh-breaks-build

pv:

Apparently Fedora (and probably also other systems) are using libxcrypt instead of glibc crypt(). This breaks pypy's crypt module build (translation fails with c compilation error), since crypt() is defined in crypt.h and no longer in unistd.h.

https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

Not sure how pypy handles system-specific includes, probably just adding `includes=["crypt.h"]` is not the right thing on all systems.



From issues-reply at bitbucket.org  Wed Apr 25 12:14:16 2018
From: issues-reply at bitbucket.org (Yusuke Tsutsumi)
Date: Wed, 25 Apr 2018 16:14:16 +0000 (UTC)
Subject: [pypy-issue] Issue #2809: Unable to install libraries with c
 modules with custom rpath on certain OS (e.g. Arch) (pypy/pypy)
Message-ID: <20180425161416.5560.74722@celery-worker-105.ash1.bb-inf.net>

New issue 2809: Unable to install libraries with c modules with custom rpath on certain OS (e.g. Arch)
https://bitbucket.org/pypy/pypy/issues/2809/unable-to-install-libraries-with-c-modules

Yusuke Tsutsumi:

# Steps To Reproduce #

1. create a virtualenv for pypy (bin/virtualenv-pypy)
2. run:
```
$ pip install pyzmq --global-option="build_ext" --global-option="--rpath=./Lib"
```

The output will probably look like:


```
#!python

    creating build/lib.linux-x86_64-3.5/zmq/backend/cffi
    cc -pthread -shared -Wunused-parameter -L/home/tsutsumi/Downloads/pypy3/env/lib -Wl,-rpath,/home/tsutsumi/Downloads/pypy3/env/lib build/temp.linux-x86_64-3.5/zmq/backend/cffi/__pycache__/_cffi_ext.o -R./Lib -lzmq -o build/lib.linux-x86_64-3.5/zmq/backend/cffi/_cffi_ext.pypy3-510-x86_64-linux-gnu.so
    cc: error: unrecognized command line option ?-R?
    error: command 'cc' failed with exit status 1
    
    ----------------------------------------
Command "/home/tsutsumi/Downloads/pypy3/env/bin/pypy -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-ncfdiwxd/pyzmq/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" build_ext --rpath=./Lib install --record /tmp/pip-record-ky03ulyu/install-record.txt --single-version-externally-managed --compile --install-headers /home/tsutsumi/Downloads/pypy3/env/include/site/python3.5/pyzmq" failed with error code 1 in /tmp/pip-install-ncfdiwxd/pyzmq/
```

# Investigation / Details #

The --rpath parameter passed into the setup.py specifies additional parameters to be passed into GCC. Those parameters are chosen by the unixcompiler.py module (which seems to be the same for both pypy and cpython):

https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py

Which is choosing the erroneous flags -R in lieu of -Wl for gcc.

It looks like this isn't encountered during cpython, as a result of gcc being noted as the compiler, and that forces the correct values:

https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L226

Running the sysconfig.get_config_var for CC gives nothing on pypy3:

```
$ pypy3 -c "import sysconfig; print(sysconfig.get_config_var('CC'))"
None
```

Digging a bit deeper, it looks like these variables are autopopulated by consuming the Makefile used to compile Python. In pypy3, this file does not exist.

The function responsible for populating the CC config var:

https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L411

The function reading the makefile, and creating the subsequent file that is consumed to construct the config var needed to resolve to the right cc variable:

https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L348

It seems like the solution could be providing a faux-makefile, or potentially patching or creating the final build file from which the variables are consumed.

I'm happy to do some work in the area and send a PR, just not sure what the best direction would be to resolve this.



From issues-reply at bitbucket.org  Thu Apr 26 07:19:54 2018
From: issues-reply at bitbucket.org (Omer Ben-Amram)
Date: Thu, 26 Apr 2018 11:19:54 +0000 (UTC)
Subject: [pypy-issue] Issue #2810: Embedding PyPy + cpyext API calls
 (pypy/pypy)
Message-ID: <20180426111953.1716.35980@celery-worker-109.ash1.bb-inf.net>

New issue 2810: Embedding PyPy + cpyext API calls
https://bitbucket.org/pypy/pypy/issues/2810/embedding-pypy-cpyext-api-calls

Omer Ben-Amram:

Hi guys,

I've been fiddling around with adding pypy support for the rust [PyO3](https://github.com/PyO3/pyo3).

I've been quite successful with the original intent of generating PyPy compatible rust extensions! (wrapped as cpython modules) (the modifications are at - [my fork](https://github.com/omerbenamram/pyo3/tree/feature/add-build-pypy-support)) by correctly linking to libpypy, changing the exported names and re implementing some missing macros in rust.

However, the other direction (rust code that embeds pypy) - which would try to call cpyext functions directly from rust works for cpython (since PyO3 handles all cpython initialization correctly), but crashes with PyPy.

I'm linking my rust library against a debug version of libpypy (5.10, haven't downloaded 6 yet) I've tried several combinations of calls to `rpython_startup_code`, `pypy_setup_home` (as referenced [here](http://doc.pypy.org/en/latest/embedding.html)), all of them yielded the following results:

So something like this works (will exit without crashing):
![Screen Shot 2018-04-26 at 13.57.59.png](https://bitbucket.org/repo/R7AbB/images/1079889783-Screen%20Shot%202018-04-26%20at%2013.57.59.png)

But importing via regular API would crash, interestingly after printing the zen:
![Screen Shot 2018-04-26 at 14.00.51.png](https://bitbucket.org/repo/R7AbB/images/3631796291-Screen%20Shot%202018-04-26%20at%2014.00.51.png)
![Screen Shot 2018-04-26 at 14.02.22.png](https://bitbucket.org/repo/R7AbB/images/626902820-Screen%20Shot%202018-04-26%20at%2014.02.22.png)

Interestingly, using an API that doesn't allocate anything, such as `PyBool_FromLong` results in a more verbose crash.
![Screen Shot 2018-04-26 at 14.04.20.png](https://bitbucket.org/repo/R7AbB/images/2586941973-Screen%20Shot%202018-04-26%20at%2014.04.20.png)

I'm suspicious that there is some ref counting/GIL management issue that is causing the crashes.

Am I missing something here? would it be possible to use the embedding API to call cpyext emulated functions from rust? 

A minimal code sample to reproduce the situation can be found [here](https://github.com/omerbenamram/pypy_ffi_playground/tree/pypy-embedding-crash)

Thanks!

Omer



From issues-reply at bitbucket.org  Thu Apr 26 14:04:07 2018
From: issues-reply at bitbucket.org (Dominyk Tiller)
Date: Thu, 26 Apr 2018 18:04:07 +0000 (UTC)
Subject: [pypy-issue] Issue #2811: ropenssl.py incorrectly assumes presence
 of comp.h (pypy/pypy)
Message-ID: <20180426180407.17312.10277@celery-worker-106.ash1.bb-inf.net>

New issue 2811: ropenssl.py incorrectly assumes presence of comp.h
https://bitbucket.org/pypy/pypy/issues/2811/ropensslpy-incorrectly-assumes-presence-of

Dominyk Tiller:

There's an erroneous assumption in `ropenssl.py` that the OpenSSL header `comp.h` will always be available, and consequently when that header isn't available the build can fail:

```
 File "/private/tmp/pypy-20180426-89170-ltfanb/pypy2-v6.0.0-src/rpython/rtyper/tool/rffi_platform.py", line 844, in configure_external_library
    raise last_error
[translation:ERROR] CompilationError: CompilationError(err="""
	/private/tmp/pypy-20180426-89170-ltfanb/pypy2-v6.0.0-src/usession-release-pypy2.7-v6.0.0-0/platcheck_77.c:87:10: fatal error: 'openssl/comp.h' file not found
	#include <openssl/comp.h>
	         ^~~~~~~~~~~~~~~~
	1 error generated.
	""")
```

Whilst it is *usually* available, it is perfectly legitimate to build openssl with `no-comp` passed during compile, which apparently disables installing that header entirely. Homebrew, the macOS package manager, has recently switched its OpenSSL formula to build with `no-comp`, which has revealed this issue.

Normally in C you could wrap the header inclusion in something like `#ifndef OPENSSL_NO_COMP` but I'm not sure how to achieve that in Python.



From issues-reply at bitbucket.org  Fri Apr 27 03:35:06 2018
From: issues-reply at bitbucket.org (Stefane Fermigier)
Date: Fri, 27 Apr 2018 07:35:06 +0000 (UTC)
Subject: [pypy-issue] Issue #2812: json.loads fails on bytes (pypy/pypy)
Message-ID: <20180427073506.22016.36544@celery-worker-105.ash1.bb-inf.net>

New issue 2812: json.loads fails on bytes
https://bitbucket.org/pypy/pypy/issues/2812/jsonloads-fails-on-bytes

Stefane Fermigier:

```
? cat jsontest.py
import json
print(json.loads("1"))
print(json.loads(b"1"))
? python jsontest.py
1
1
? python3 jsontest.py
1
1
? pypy jsontest.py
1
1
? pypy3 jsontest.py
1
Traceback (most recent call last):
  File "jsontest.py", line 3, in <module>
    print(json.loads(b"1"))
  File "/usr/local/Cellar/pypy3/6.0.0/libexec/lib-python/3/json/__init__.py", line 318, in loads
    s.__class__.__name__))
TypeError: the JSON object must be str, not 'bytes'

```



From issues-reply at bitbucket.org  Fri Apr 27 07:39:06 2018
From: issues-reply at bitbucket.org (=?utf-8?b?5YiY56mG5riF?=)
Date: Fri, 27 Apr 2018 11:39:06 +0000 (UTC)
Subject: [pypy-issue] Issue #2813: seems bug in ctypes (pypy/pypy)
Message-ID: <20180427113905.40893.83346@celery-worker-109.ash1.bb-inf.net>

New issue 2813: seems bug in ctypes
https://bitbucket.org/pypy/pypy/issues/2813/seems-bug-in-ctypes

???:

```
#!python
from ctypes import *
class Context(Structure):
    pass

PtrTypeOfContext = POINTER(Context)

LIB = cdll.LoadLibrary("./test.so")
LIB.test.restype = Context
LIB.test.argtypes = []

Context._fields_ = [
        ("a", c_char_p),
        ("b", c_char_p),
        ("c", c_char_p),
        ("d", c_char_p),
    ]
c = Context()
v = LIB.test(c)
print (v.a)
print (v.b)
print (v.c)
print (v.d)
```

this code can be run in CPython, but in pypy, it will raise `SystemError: not supported by libffi`

and If I comment line 5, pypy will be good



From issues-reply at bitbucket.org  Sun Apr 29 13:44:51 2018
From: issues-reply at bitbucket.org (Omer Katz)
Date: Sun, 29 Apr 2018 17:44:51 +0000 (UTC)
Subject: [pypy-issue] Issue #2814: _pypyjson should use SIMD when available
 to skip whitespace characters faster (pypy/pypy)
Message-ID: <20180429174450.8756.16229@celery-worker-110.ash1.bb-inf.net>

New issue 2814: _pypyjson should use SIMD when available to skip whitespace characters faster
https://bitbucket.org/pypy/pypy/issues/2814/_pypyjson-should-use-simd-when-available

Omer Katz:

RapidJSON has implemented whitespace skipping using a variety of SIMD interstices.
For [SSE 4.2](https://github.com/Tencent/rapidjson/blob/master/include/rapidjson/reader.h#L281),  [SSE 2](https://github.com/Tencent/rapidjson/blob/master/include/rapidjson/reader.h#L332) and [NEON for ARM](https://github.com/Tencent/rapidjson/blob/master/include/rapidjson/reader.h#L417).
We can port these functions to C pretty easily and the license of RapidJSON is MIT so that's allowed.
The challenge is to detect if the user running PyPy has support for such instructions.