From issues-reply at bitbucket.org  Thu Mar  1 11:23:57 2018
From: issues-reply at bitbucket.org (Antonio Cuni)
Date: Thu, 01 Mar 2018 16:23:57 +0000 (UTC)
Subject: [pypy-issue] Issue #2768: eventlet.monkey_patch breaks
 threading.Event.wait (pypy/pypy)
Message-ID: <20180301162357.22708.77998@celery-worker-105.ash1.bb-inf.net>

New issue 2768: eventlet.monkey_patch breaks threading.Event.wait
https://bitbucket.org/pypy/pypy/issues/2768/eventletmonkey_patch-breaks

Antonio Cuni:

This code:
```python
from eventlet import monkey_patch
monkey_patch()
from threading import Event
ev = Event()
ev.wait(timeout=10)
```

results in this traceback:
```
Traceback (most recent call last):
  File "eventbug.py", line 5, in <module>
    ev.wait(timeout=10)
  File "/extra/pypy-release/pypy2-v5.10.0-linux64/lib-python/2.7/threading.py", line 610, in wait
    self.__cond.wait(timeout)
  File "/extra/pypy-release/pypy2-v5.10.0-linux64/lib-python/2.7/threading.py", line 347, in wait
    gotit = waiter._py3k_acquire(True, timeout)
AttributeError: 'Semaphore' object has no attribute '_py3k_acquire'
```

The call to `_py3k_acquire` was added by commit 8d88f18, but I'm not sure to understand what was the real underlying reason to do so: @arigo , do you remember?

We should either:
1. fix our code so that it doesn't break if `_py3k_acquire` is not present
2. fix it in eventlet and make a PR, hoping they accept it



From issues-reply at bitbucket.org  Fri Mar  2 13:31:36 2018
From: issues-reply at bitbucket.org (Jason Madden)
Date: Fri, 02 Mar 2018 18:31:36 +0000 (UTC)
Subject: [pypy-issue] Issue #2769: SystemError: unexpected internal
 exception (please report a bug): <BytecodeCorruption... (pypy/pypy)
Message-ID: <20180302183135.20131.43391@celery-worker-106.ash1.bb-inf.net>

New issue 2769: SystemError: unexpected internal exception (please report a bug): <BytecodeCorruption...
https://bitbucket.org/pypy/pypy/issues/2769/systemerror-unexpected-internal-exception

Jason Madden:

Running PyPy2   on Travis CI, at least two gevent builds in a row failed with this error:
```
RPython traceback:
    File "pypy_interpreter_1.c", line 34924, in execute_frame
    File "rpython_jit_metainterp.c", line 26150, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
    File "pypy_module_pypyjit.c", line 183, in portal_28
    File "pypy_interpreter_2.c", line 37639, in handle_bytecode__AccessDirect_None
    File "pypy_interpreter_2.c", line 50304, in dispatch_bytecode__AccessDirect_None
    File "pypy_interpreter_2.c", line 54171, in MISSING_OPCODE__AccessDirect_None
  Traceback (most recent call last):
    File "/home/travis/build/gevent/gevent/src/gevent/greenlet.py", line 730, in run
      result = self._run(*self.args, **self.kwargs)
    File "/home/travis/build/gevent/gevent/src/gevent/baseserver.py", line 26, in _handle_and_close_when_done
      return handle(*args_tuple)
    File "/home/travis/build/gevent/gevent/src/gevent/server.py", line 191, in wrap_socket_and_handle
      return self.handle(ssl_socket, address)
    File "/home/travis/build/gevent/gevent/src/gevent/pywsgi.py", line 1506, in handle
      handler.handle()
    File "/home/travis/build/gevent/gevent/src/gevent/pywsgi.py", line 456, in handle
      result = self.handle_one_request()
    File "/home/travis/build/gevent/gevent/src/gevent/pywsgi.py", line 639, in handle_one_request
      self.requestline = self.read_requestline()
    File "/home/travis/build/gevent/gevent/src/gevent/pywsgi.py", line 587, in read_requestline
      line = self.rfile.readline(MAX_REQUEST_LINE)
    File "/home/travis/.runtimes/versions/pypy5100/lib-python/2.7/socket.py", line 547, in readline
      data = self._sock.recv(self._rbufsize)
    File "/home/travis/build/gevent/gevent/src/gevent/_sslgte279.py", line 458, in recv
      return self.read(buflen)
    File "/home/travis/build/gevent/gevent/src/gevent/_sslgte279.py", line 318, in read
      self._wait(self._read_event, timeout_exc=_SSLErrorReadTimeout)
    File "/home/travis/build/gevent/gevent/src/gevent/_socket2.py", line 196, in _wait
      self.hub.wait(watcher)
    File "/home/travis/build/gevent/gevent/src/gevent/hub.py", line 615, in wait
      watcher.start(waiter.switch, unique)
    File "/home/travis/build/gevent/gevent/src/gevent/libuv/watcher.py", line 332, in start
      watcher._io_start()
    File "/home/travis/build/gevent/gevent/src/gevent/libuv/watcher.py", line 376, in _io_start
      self.start(self._io_callback, pass_events=True)
    File "/home/travis/build/gevent/gevent/src/gevent/_ffi/watcher.py", line 487, in start
      def start(self, callback, *args, **kwargs):
  SystemError: unexpected internal exception (please report a bug): <BytecodeCorruption object at 0x146598288970>; internal traceback was dumped to stderr
  Fri Mar  2 16:36:31 2018 <Greenlet "Greenlet-0" at 0x1465914fb220L: _handle_and_close_when_done(<bound method WSGIServer.wrap_socket_and_handle of, <bound method WSGIServer.do_close of <WSGIServer a, (<socket at 0x14658ff95130L fileno=[Errno 9] Bad f)> failed with SystemError
  
  EFatal Python error: Aborted
  
  Stack (most recent call first, approximate line numbers):
    File "/home/travis/build/gevent/gevent/src/gevent/libuv/loop.py", line 389 in run
    File "/home/travis/build/gevent/gevent/src/gevent/hub.py", line 658 in run
    File "/home/travis/.runtimes/versions/pypy5100/lib_pypy/greenlet.py", line 183 in _greenlet_start
    File "<builtin>/?", line 2 in start
```
(Log https://travis-ci.org/gevent/gevent/jobs/348324982#L838)

Based on the position reported in the log, I took a guess at the test that might be causing the issue and disabled it and everything ran successfully from then on. That test was src/greentest/test__pywsgi.py:TestInputRaw.test_32bit_overflow (which specifically takes PyPy into account). That's the first test in that class to run, and all the other tests following it ran successfully. I don't think that test does any network IO or even switches greenlets, even though the reported error involves both. I don't know if it's possible we were still tearing down the server infrastructure from the last test class?

Here's the code I disabled:
```python
    def test_32bit_overflow(self):
        # https://github.com/gevent/gevent/issues/289
        # Should not raise an OverflowError on Python 2
        data = b'asdf\nghij\n'
        long_data = b'a' * (pywsgi.MAX_REQUEST_LINE + 10)
        long_data += b'\n'
        data = data + long_data
        partial_data = b'qjk\n' # Note terminating \n
        n = 25 * 1000000000
        if hasattr(n, 'bit_length'):
            self.assertEqual(n.bit_length(), 35)
        if not PY3 and not PYPY:
            # Make sure we have the impl we think we do
            self.assertRaises(OverflowError, StringIO(data).readline, n)
        # self.make_input returns a gevent.pywsgi.Input object wrapped around a cStringIO.StringIO object
        i = self.make_input(data, content_length=n)
        # No size hint, but we have too large a content_length to fit
        self.assertEqual(i.readline(), b'asdf\n')
        # Large size hint
        self.assertEqual(i.readline(n), b'ghij\n')
        self.assertEqual(i.readline(n), long_data)

        # Now again with the real content length, assuring we can't read past it
        i = self.make_input(data + partial_data, content_length=len(data) + 1)
        self.assertEqual(i.readline(), b'asdf\n')
        self.assertEqual(i.readline(n), b'ghij\n')
        self.assertEqual(i.readline(n), long_data)
        # Now we've reached content_length so we shouldn't be able to
        # read anymore except the one byte remaining
        self.assertEqual(i.readline(n), b'q')
```

I couldn't reproduce this locally on macOS or my ubuntu VM, and it popped up suddenly after what should be an unrelated change.

(gevent issue at https://github.com/gevent/gevent/issues/1130; closing in favor of this)



From issues-reply at bitbucket.org  Sat Mar  3 12:32:49 2018
From: issues-reply at bitbucket.org (lesshaste)
Date: Sat, 03 Mar 2018 17:32:49 +0000 (UTC)
Subject: [pypy-issue] Issue #2770: python 3 code slower with pypy3
 (pypy/pypy)
Message-ID: <20180303173249.21068.5042@celery-worker-109.ash1.bb-inf.net>

New issue 2770: python 3 code slower with pypy3
https://bitbucket.org/pypy/pypy/issues/2770/python-3-code-slower-with-pypy3

lesshaste:

The following code was written by someone called Dennis.

from functools import lru_cache

@lru_cache(maxsize = None)
def haf(matrix):
        n = len(matrix)
        if n == 2: return matrix[0][1]
        h = 0
        for j in range(1, n):
                if matrix[0][j] == 0: continue
                copy = list(matrix)
                del copy[:j+1:j]
                copy = list(zip(*copy))
                del copy[:j+1:j]
                h += matrix[0][j] * haf(tuple(copy))
        return h


If you feed into it the following input (for example):

[[0, -1, 0, 0, -1, 1, 1, -1, 1, -1, -1, 1, 1, 0, 1, 1, 1, 0, 1, -1, -1, 0, 0, -1, -1, 0], [-1, 1, 1, 1, -1, 1, -1, 0, 1, -1, 0, 0, -1, 0, 1, 1, 1, 0, 0, -1, 0, 0, -1, -1, -1, 0], [0, 1, 1, -1, 0, 0, 1, 0, 0, -1, 1, 0, -1, 1, -1, 0, 0, 0, -1, 0, 1, 0, 1, 1, 1, -1], [0, 1, -1, 0, -1, 0, 0, 1, 0, 0, -1, 1, 1, -1, -1, -1, 0, 1, -1, 1, -1, 0, 1, 0, 0, -1], [-1, -1, 0, -1, 1, 0, 1, 0, -1, 1, 1, -1, 0, -1, 0, 1, 1, -1, 0, -1, 1, 0, -1, 1, 1, -1], [1, 1, 0, 0, 0, 0, 0, -1, 1, 0, 0, 1, 0, -1, -1, -1, -1, 0, 0, -1, -1, 1, 1, 0, 1, 0], [1, -1, 1, 0, 1, 0, 0, 1, -1, -1, -1, 1, -1, -1, 0, -1, 1, 0, -1, 0, -1, -1, 0, -1, 0, -1], [-1, 0, 0, 1, 0, -1, 1, 0, 1, 0, 0, -1, -1, -1, 1, 0, 0, 1, -1, 1, 1, 0, -1, 0, -1, 1], [1, 1, 0, 0, -1, 1, -1, 1, 0, 0, -1, -1, -1, -1, 1, 1, 1, 1, -1, 1, -1, 1, -1, 1, 1, -1], [-1, -1, -1, 0, 1, 0, -1, 0, 0, 1, -1, 0, 1, 0, 0, 0, -1, -1, 0, -1, 1, 0, -1, -1, -1, 0], [-1, 0, 1, -1, 1, 0, -1, 0, -1, -1, 0, 1, 1, 0, 1, 0, 0, -1, -1, 1, 0, -1, 1, 1, 0, 0], [1, 0, 0, 1, -1, 1, 1, -1, -1, 0, 1, -1, 1, 0, -1, -1, 1, 1, 1, 0, 1, -1, -1, 0, -1, 1], [1, -1, -1, 1, 0, 0, -1, -1, -1, 1, 1, 1, 1, -1, -1, 1, 1, -1, 0, 0, -1, 0, 0, -1, 1, -1], [0, 0, 1, -1, -1, -1, -1, -1, -1, 0, 0, 0, -1, 1, -1, 0, 1, -1, 0, 0, 1, -1, -1, 1, 1, 1], [1, 1, -1, -1, 0, -1, 0, 1, 1, 0, 1, -1, -1, -1, -1, 1, 1, -1, 0, 1, 1, 0, 0, -1, 0, 1], [1, 1, 0, -1, 1, -1, -1, 0, 1, 0, 0, -1, 1, 0, 1, 1, 0, 1, -1, 1, 1, 1, -1, 1, 1, -1], [1, 1, 0, 0, 1, -1, 1, 0, 1, -1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, -1, 0, 1, 0, 1, 0], [0, 0, 0, 1, -1, 0, 0, 1, 1, -1, -1, 1, -1, -1, -1, 1, 0, 0, -1, -1, 0, 0, 1, 1, 1, 0], [1, 0, -1, -1, 0, 0, -1, -1, -1, 0, -1, 1, 0, 0, 0, -1, 1, -1, -1, 1, 0, 1, -1, 0, -1, -1], [-1, -1, 0, 1, -1, -1, 0, 1, 1, -1, 1, 0, 0, 0, 1, 1, 0, -1, 1, 1, -1, -1, -1, -1, 0, 1], [-1, 0, 1, -1, 1, -1, -1, 1, -1, 1, 0, 1, -1, 1, 1, 1, -1, 0, 0, -1, 1, 1, 1, 1, 0, 0], [0, 0, 0, 0, 0, 1, -1, 0, 1, 0, -1, -1, 0, -1, 0, 1, 0, 0, 1, -1, 1, -1, -1, 1, 1, 1], [0, -1, 1, 1, -1, 1, 0, -1, -1, -1, 1, -1, 0, -1, 0, -1, 1, 1, -1, -1, 1, -1, 0, -1, 0, 0], [-1, -1, 1, 0, 1, 0, -1, 0, 1, -1, 1, 0, -1, 1, -1, 1, 0, 1, 0, -1, 1, 1, -1, 0, 0, -1], [-1, -1, 1, 0, 1, 1, 0, -1, 1, -1, 0, -1, 1, 1, 0, 1, 1, 1, -1, 0, 0, 1, 0, 0, 1, -1], [0, 0, -1, -1, -1, 0, -1, 1, -1, 0, 0, 1, -1, 1, 1, -1, 0, 0, -1, 1, 0, 1, 0, -1, -1, 1]]

it takes about 10 seconds on python3 and about 14 seconds using pypy3.5-5.10.1-linux_x86_64-portable



From issues-reply at bitbucket.org  Sat Mar  3 17:58:27 2018
From: issues-reply at bitbucket.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sat, 03 Mar 2018 22:58:27 +0000 (UTC)
Subject: [pypy-issue] Issue #2771: Minimal support for __slots__ (pypy/pypy)
Message-ID: <20180303225826.23084.28630@celery-worker-105.ash1.bb-inf.net>

New issue 2771: Minimal support for __slots__
https://bitbucket.org/pypy/pypy/issues/2771/minimal-support-for-__slots__

Hrvoje Nik?i?:

While experimenting with PyPy on our company code base, I found that ignoring `__slots__` is a source of incompatibility with CPython. I understand why `__slots__` declarations are currently ignored - their primary use to save memory is simply unnecessary in PyPy. However, doing so leads to unnecessary behavior difference compared to CPython. Consider a class such as:

```
class Point:
    __slots__ = 'x', 'y'
```

Here declaring `__slots__` is not only about memory savings; the intention is for the class to raise an `AttributeError` if someone assigns to `z` by mistake. Also, cclasses without dict are not foreign to PyPy. For example:

```
>>>> object().foo = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'object' object has no attribute 'foo'
>>>> [].foo = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'list' object has no attribute 'foo'
```

To allow creation of such classes from Python, I propose "supporting" `__slots__` as follows:

* a class that has `__slots__` gets flagged with a `NO_WRITE_TO_DICT` flag (unless `__slots__` contains `__dict__`)
* `object.__setattr__` refuses writing to `__dict__` of such classes
* each slot named in `__slots__` gets a class-level property whose `__set__` writes to the dict
* the actual dict is not returned by accessing `__dict__` on the instance.

For example:

```
p = Point()
p.x = 10  # allowed
p.y = 10  # allowed
p.z = 10  # forbidden, raises AttributeError
p.__dict__  # raises AttributeError, the dict is hidden
```



From issues-reply at bitbucket.org  Mon Mar  5 03:28:20 2018
From: issues-reply at bitbucket.org (garming-sam)
Date: Mon, 05 Mar 2018 08:28:20 +0000 (UTC)
Subject: [pypy-issue] Issue #2772: Theano working nominally within pypy
 (pypy/pypy)
Message-ID: <20180305082820.10502.3040@celery-worker-106.ash1.bb-inf.net>

New issue 2772: Theano working nominally within pypy
https://bitbucket.org/pypy/pypy/issues/2772/theano-working-nominally-within-pypy

garming-sam:

In trying to find a decent ML library to work on pypy, I figured out some hacks to get Theano working (at least superficially with runtime compiled cpyext modules). 

There seems to be a few problems that need to be resolved before it would work out of the box:

1. A single usage of the ctypes.pythonapi.PyCapsule_Type

2. A single usage of sys.getrefcount (to check that there isn't leaks)

3. Missing build information to runtime load the compiled .so python module
- The correct binary .so filename looks to be able to be constructed using distutils.sysconfig.get_config_var("SO") (or EXT_SUFFIX in python3)
- Expects libpython.so (or equivalent) in the distutils.sysconfig.get_config_var("LIBDIR") location which does not exist
- distutils.sysconfig.get_config_var("LDLIBRARY") does not resolve in pypy currently -- but should in theory point to libpypy-c

If this was to be fixed correctly, there's a few questions that I would expect would be needed to be resolved:
1. Which method is best to runtime determine if the code is running under pypy?
2. Is distutils.sysconfig.get_config_var("LDLIBRARY") meant to return libpypy-c?
3. Is libpypy-c supposed to reside in LIBDIR?

In doing some similar testing around this area, I also noticed that there are some config variables that exist in sysconfig that do not exist in distutils.sysconfig (or vice versa) like INCLUDEDIR which make it difficult to build cpython modules that can work against pypy.

The hacks I've done (for a specific version of pypy2) are in a branch here:
https://github.com/GSam/Theano/tree/pypy-hack



From issues-reply at bitbucket.org  Thu Mar  8 05:06:36 2018
From: issues-reply at bitbucket.org (Khushbu Parakh)
Date: Thu, 08 Mar 2018 10:06:36 +0000 (UTC)
Subject: [pypy-issue] Issue #2773: 404 pypy download page Homebrew
 (pypy/pypy)
Message-ID: <20180308100634.27018.99244@celery-worker-109.ash1.bb-inf.net>

New issue 2773: 404 pypy download page Homebrew
https://bitbucket.org/pypy/pypy/issues/2773/404-pypy-download-page-homebrew

Khushbu Parakh:

http://pypy.org/download.html
Under Linux binaries and common distributions
Homebrew is redirecting to 404. 
with link as:
**https://github.com/Homebrew/legacy-homebrew/blob/master/Library/Formula/pypy.rb**

Need to update the link.



From issues-reply at bitbucket.org  Tue Mar 20 13:51:10 2018
From: issues-reply at bitbucket.org (Andrew Stepanov)
Date: Tue, 20 Mar 2018 17:51:10 +0000 (UTC)
Subject: [pypy-issue] Issue #2774: cpyext: pybind11: 'instancemethod' has no
 attribute '__name__' (pypy/pypy)
Message-ID: <20180320175110.3667.57822@celery-worker-110.ash1.bb-inf.net>

New issue 2774: cpyext: pybind11: 'instancemethod' has no attribute '__name__'
https://bitbucket.org/pypy/pypy/issues/2774/cpyext-pybind11-instancemethod-has-no

Andrew Stepanov:

When I try to use this simple [pybind11](https://github.com/pybind/pybind11) binding code (which by the way compiles just fine under pypy3-v5.10.1):

```
#!cpp

#include <pybind11/pybind11.h>

class A {
 public:
  int field;
};

namespace py = pybind11;

PYBIND11_MODULE(simple, m) {
  py::class_<A>(m, "A")
      .def(py::init<>())
      .def_readwrite("field", &A::field);
}
```
I get
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: AttributeError: 'instancemethod' object has no attribute '__name__'
```

As it turns out, `InstanceMethod` indeed doesn't have `__name__` attribute (along with `__module__` and `__doc__` which pybind11 uses, see [pypy/module/cpyext/classobject.py:34](https://bitbucket.org/pypy/pypy/src/d12c359516b2ee430bd53958b2bc6bf3373b5557/pypy/module/cpyext/classobject.py?at=py3.5&fileviewer=file-view-default#classobject.py-34))

```
InstanceMethod.typedef = TypeDef("instancemethod",
    __new__ = interp2app(InstanceMethod.descr_new),
    __call__ = interp2app(InstanceMethod.descr_call,
                          descrmismatch='__call__'),
    __get__ = interp2app(InstanceMethod.descr_get),
    __repr__ = interp2app(InstanceMethod.descr_repr,
                          descrmismatch='__repr__'),
    __func__= interp_attrproperty_w('w_function', cls=InstanceMethod),
)
```

When I implement them straightforwardly using `self.w_function` attributes

```
class InstanceMethod(W_Root):
    ...

    def fget_name(self, space):
        return space.getattr(self.w_function, space.newtext("__name__"))

    def fget_module(self, space):
        return space.getattr(self.w_function, space.newtext("__module__"))

    def fget_docstring(self, space):
        return space.getattr(self.w_function, space.newtext("__doc__"))

    ...

InstanceMethod.typedef = TypeDef("instancemethod",
    ...
    __name__= GetSetProperty(InstanceMethod.fget_name, cls=InstanceMethod),
    __module__= GetSetProperty(InstanceMethod.fget_module, cls=InstanceMethod),
    __doc__= GetSetProperty(InstanceMethod.fget_docstring, cls=InstanceMethod), 
)
```

everything works fine and example pybind11 module above can be imported with no problems.

In fact, with this modifications all but the 2 tests (`test_multiple_inheritance.py`, `test_eval.py`) in pybind11 test suite pass, which makes the pybind11 library useful in practice (from my own experience: big binding library used in our private project compiles and passes all of our tests)



From issues-reply at bitbucket.org  Tue Mar 20 18:36:22 2018
From: issues-reply at bitbucket.org (mattip)
Date: Tue, 20 Mar 2018 22:36:22 +0000 (UTC)
Subject: [pypy-issue] Issue #2775: crash when building numpy (pypy/pypy)
Message-ID: <20180320223621.35775.86086@celery-worker-109.ash1.bb-inf.net>

New issue 2775: crash when building numpy
https://bitbucket.org/pypy/pypy/issues/2775/crash-when-building-numpy

mattip:

Since build ``93883-89245c285fa0`` building numpy produces the following assert error:
```
    RPython traceback:
      File "rpython_jit_metainterp_4.c", line 40838, in MIFrame_run_one_step
      File "rpython_jit_metainterp_6.c", line 55508, in handler_getfield_gc_r_greenfield_1
      File "rpython_jit_metainterp_7.c", line 52040, in MIFrame__opimpl_getfield_gc_greenfield_any
      File "rpython_jit_metainterp_8.c", line 42545, in MIFrame__nonstandard_virtualizable
      File "rpython_jit_metainterp_9.c", line 48872, in MIFrame_emit_force_virtualizable
    Fatal RPython error: AssertionError

```
version ``93876-2ec2d28bba33`` does not fail. To replicate, on a fresh build or a ``tar.gz`` download:

```
pypy -mensurepip
pypy -mpip install cython numpy

It seems the commit in 57349ce40416 somehow reliably triggers the JIT assert
```



From issues-reply at bitbucket.org  Sat Mar 24 15:21:37 2018
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sat, 24 Mar 2018 19:21:37 +0000 (UTC)
Subject: [pypy-issue] Issue #2776: pip crashes if MALLOC_CHECK_ is set
 (pypy/pypy)
Message-ID: <20180324192137.24260.70375@celery-worker-108.ash1.bb-inf.net>

New issue 2776: pip crashes if MALLOC_CHECK_ is set
https://bitbucket.org/pypy/pypy/issues/2776/pip-crashes-if-malloc_check_-is-set

Christoph Reiter:

```
MALLOC_CHECK_=3 pypy -m pip
*** Error in `python': free(): invalid pointer: 0x0000000000f9a890 ***
Aborted (core dumped)
```



From issues-reply at bitbucket.org  Sat Mar 24 18:27:37 2018
From: issues-reply at bitbucket.org (Andrew Stepanov)
Date: Sat, 24 Mar 2018 22:27:37 +0000 (UTC)
Subject: [pypy-issue] Issue #2777: re: incorrect behaviour for long patterns
 that are used repeatedly (possible JIT bug?) (pypy/pypy)
Message-ID: <20180324222737.24496.6494@celery-worker-106.ash1.bb-inf.net>

New issue 2777: re: incorrect behaviour for long patterns that are used repeatedly (possible JIT bug?)
https://bitbucket.org/pypy/pypy/issues/2777/re-incorrect-behaviour-for-long-patterns

Andrew Stepanov:

I've observed that `re` module gives incorrect results for very long patterns that are used repeatedly (possible JIT bug?)

The following code produces an error on both pypy2 & pypy3 (latest version from mercurial) although it passes on CPython3.5
```
import re
pattern = ".a" * 2500
text = "a" * 6000
match = re.compile(pattern).match
for idx in range(len(text) - len(pattern) + 1):
    substr = text[idx:idx+len(pattern)]
    if match(substr) is None:
        raise RuntimeError("This shouldn't have happened at {}".format(idx))
```

```
Traceback (most recent call last):
  File "pypy_re_bug.py", line 9, in <module>
    raise RuntimeError("This shouldn't have happened at {}".format(idx))
RuntimeError: This shouldn't have happened at 632
```
This also happens for other long patterns (I tried `pattern = "." * 5000`, `pattern = "a" * 5000` and random strings from `{".", "a"}` alphabet of lengths >= 5000)

The exact number of iterations before the error occurs can vary slightly, e.g. if I move `match = re.compile(pattern).match` inside the loop, I get exception at iteration 668 on pypy3 and 643 on pypy2.

The code works fine for shorter patterns.



From issues-reply at bitbucket.org  Wed Mar 28 16:19:00 2018
From: issues-reply at bitbucket.org (adamf663)
Date: Wed, 28 Mar 2018 20:19:00 +0000 (UTC)
Subject: [pypy-issue] Issue #2778: Need python3 build instructions
 (pypy/pypy)
Message-ID: <20180328201859.30059.95181@celery-worker-107.ash1.bb-inf.net>

New issue 2778: Need python3 build instructions
https://bitbucket.org/pypy/pypy/issues/2778/need-python3-build-instructions

adamf663:

What are the instructions for building from source for python 3?
The instructions in the README.rst file, and at readthedocs use rpython.
Unfortunately, rpython has python 2 code  but running it for some reason uses python3 on the python2 code and predictably fails.
I've verified that 'python' and 'python2' bring up the python 2 interpreter.



From issues-reply at bitbucket.org  Thu Mar 29 17:25:56 2018
From: issues-reply at bitbucket.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Thu, 29 Mar 2018 21:25:56 +0000 (UTC)
Subject: [pypy-issue] Issue #2779: Performance loss with deeply nested
 generators (pypy/pypy)
Message-ID: <20180329212555.34177.77550@celery-worker-107.ash1.bb-inf.net>

New issue 2779: Performance loss with deeply nested generators
https://bitbucket.org/pypy/pypy/issues/2779/performance-loss-with-deeply-nested

Hrvoje Nik?i?:

PyPy (5.10.1) is significantly slower than CPython (3.6.3) on the attached benchmark.

The script profiles traversing generators nested with `yield from` at various depths, which also comes up when suspending and resuming recursive or nested `async` functions. I was curious whether PyPy optimizes `yield from` delegation as mentioned [in the original PEP](https://www.python.org/dev/peps/pep-0380/#optimisations) and later in a [message by Guido](https://groups.google.com/forum/#!msg/python-tulip/bmphRrryuFk/BNEOOOuR1j4J). It seems that CPython [dropped](https://bugs.python.org/issue14230) the optimization due to an issue with tracebacks.

It looks like PyPy doesn't implement the optimization either - but that is not the topic of this issue. I noticed a sharp slowdown in PyPy at the nesting depth of around 80. At that point the performance suddenly drops to levels significantly slower than CPython. For example, on my machine, with depth == 100:


```
$ python3 benchnestedyield.py 100
0.061139583587646484
0.06133460998535156
0.06076836585998535
0.06116318702697754
0.061196327209472656

$ pypy3 benchnestedyield.py  100
0.30632662773132324
0.31490111351013184
0.29983067512512207
0.31607627868652344
0.31775617599487305

$ pypy3 --jit off benchnestedyield.py  100
0.16022372245788574
0.1604137420654297
0.16206026077270508
0.161407470703125
0.16135311126708984
```

With depth == 50, the numbers look like something I'd expect when comparing PyPy and CPython:

```
$ python3 benchnestedyield.py 50
0.029144287109375
0.029152870178222656
0.02940988540649414
0.02889084815979004
0.028936386108398438

$ pypy3 benchnestedyield.py  50
0.12029409408569336
0.005949974060058594
0.005345821380615234
0.005307197570800781
0.005133867263793945

$ pypy3 --jit off benchnestedyield.py 50
0.08134770393371582
0.08192563056945801
0.08233189582824707
0.08091974258422852
0.08127617835998535
```

This is probably not a big issue in practice, but I wanted to report it in case it's an anomaly someone cares to investigate.