From issues-reply at bitbucket.org  Mon Aug  6 16:25:39 2018
From: issues-reply at bitbucket.org (Kristoffer Sahlin)
Date: Mon, 06 Aug 2018 20:25:39 +0000 (UTC)
Subject: [pypy-issue] Issue #2864: multiprocessing makes dyld: lazy symbol
 binding failed (pypy/pypy)
Message-ID: <20180806202539.33012.99068@celery-worker-111.ash1.bb-inf.net>

New issue 2864: multiprocessing makes dyld: lazy symbol binding failed
https://bitbucket.org/pypy/pypy/issues/2864/multiprocessing-makes-dyld-lazy-symbol

Kristoffer Sahlin:

Do I have an old version, or what's the best way to fix this?

```
$ ~/prefix/bin/pypy2-v6.0.0-osx64/bin/pypy
Python 2.7.13 (ab0b9caf307d, Apr 24 2018, 18:05:02)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> from multiprocessing import Pool
>>>> pool = Pool(processes=4)
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /Users/kxs624/prefix/bin/pypy2-v6.0.0-osx64/bin//libpypy-c.dylib
  Expected in: flat namespace

dyld: Symbol not found: _clock_gettime
  Referenced from: /Users/kxs624/prefix/bin/pypy2-v6.0.0-osx64/bin//libpypy-c.dylib
  Expected in: flat namespace

Trace/BPT trap: 5
```



From issues-reply at bitbucket.org  Mon Aug  6 22:11:52 2018
From: issues-reply at bitbucket.org (Avram Lubkin)
Date: Tue, 07 Aug 2018 02:11:52 +0000 (UTC)
Subject: [pypy-issue] Issue #2865: types.MemberDescriptorType has wrong type
 (pypy/pypy)
Message-ID: <20180807021152.32415.76238@celery-worker-105.ash1.bb-inf.net>

New issue 2865: types.MemberDescriptorType has wrong type
https://bitbucket.org/pypy/pypy/issues/2865/typesmemberdescriptortype-has-wrong-type

Avram Lubkin:

Affects 2.7 and 3.x

```
#!python
>>>> import types
>>>>
>>>> class C:
....     __slots__ = ('ivar',)
....     
>>>> type(C.__dict__['ivar'])
<class 'member_descriptor'>
>>>>
>>>> types.MemberDescriptorType
<class 'getset_descriptor'>
```

This is due to the implementation. In CPython types is defined like this, which seems to be the same code in pypy.

```
#!python

def _f(): pass
FunctionType = type(_f)

MemberDescriptorType = type(FunctionType.__globals__)
```
It would be better to check a slot member's type instead. Not sure where is the right place to fix it, but I wanted to report it before I implemented a workaround.



From issues-reply at bitbucket.org  Wed Aug  8 21:26:14 2018
From: issues-reply at bitbucket.org (squeaky)
Date: Thu, 09 Aug 2018 01:26:14 +0000 (UTC)
Subject: [pypy-issue] Issue #2866: [3.6] wrong exception while callinstr str
 on str (pypy/pypy)
Message-ID: <20180809012613.20953.12553@celery-worker-108.ash1.bb-inf.net>

New issue 2866: [3.6] wrong exception while callinstr str on str
https://bitbucket.org/pypy/pypy/issues/2866/36-wrong-exception-while-callinstr-str-on

squeaky:

CPython 3.6

```
>>> str('text', 'text')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: decoding str is not supported
>>> 
```

PyPy nightly 3.6
```
>>>> str('text', 'text')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
LookupError: unknown encoding: text
>>>> 
```



From issues-reply at bitbucket.org  Wed Aug  8 21:30:35 2018
From: issues-reply at bitbucket.org (squeaky)
Date: Thu, 09 Aug 2018 01:30:35 +0000 (UTC)
Subject: [pypy-issue] Issue #2867: [3.6] The nightly contains
 lib_pypy/grp.py from PyPy2 (pypy/pypy)
Message-ID: <20180809013034.36479.45436@celery-worker-105.ash1.bb-inf.net>

New issue 2867: [3.6] The nightly contains lib_pypy/grp.py from PyPy2
https://bitbucket.org/pypy/pypy/issues/2867/36-the-nightly-contains-lib_pypy-grppy

squeaky:

Try importing it and it will explode as it's PyPy2 version, it's probably there because of a bad merge or something.



From issues-reply at bitbucket.org  Sat Aug 11 13:16:22 2018
From: issues-reply at bitbucket.org (Ben Darnell)
Date: Sat, 11 Aug 2018 17:16:22 +0000 (UTC)
Subject: [pypy-issue] Issue #2868: Segfault with `*args` type annotation in
 inner function (pypy/pypy)
Message-ID: <20180811171622.12476.52736@celery-worker-105.ash1.bb-inf.net>

New issue 2868: Segfault with `*args` type annotation in inner function
https://bitbucket.org/pypy/pypy/issues/2868/segfault-with-args-type-annotation-in

Ben Darnell:

Running the following code in pypy3 (6.0.0 on mac, similar crashes have been seen on older versions of pypy3 running on linux) will segfault:

```
def f1():
    def f2(*args: int):
        pass

f1()
```

```
$ pypy3 --version
Python 3.5.3 (fdd60ed87e941677e8ea11acf9f1819466521bf2, Jul 30 2018, 08:59:51)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]
$ pypy3 -X faulthandler /tmp/test.py
Fatal Python error: Segmentation fault

Stack (most recent call first, approximate line numbers):
  File "/tmp/test.py", line 1 in f1
  File "/tmp/test.py", line 1 in <module>
  File "<builtin>/app_main.py", line 541 in exec_
  File "<builtin>/app_main.py", line 769 in execfile
  File "<builtin>/app_main.py", line 84 in run_toplevel
  File "<builtin>/app_main.py", line 545 in run_command_line
  File "<builtin>/app_main.py", line 840 in entry_point
Segmentation fault: 11
```

This example was reduced from a source file defining a decorator. The bug appears to require a type annotation on a `*args` or `**kwargs` parameter (not an ordinary parameter) in a function defined within the local scope of another function (top level functions and class methods are not affected).



From issues-reply at bitbucket.org  Tue Aug 14 03:03:46 2018
From: issues-reply at bitbucket.org (Geun Tack Lim)
Date: Tue, 14 Aug 2018 07:03:46 +0000 (UTC)
Subject: [pypy-issue] Issue #2869: Celery Memory growing forever (pypy/pypy)
Message-ID: <20180814070346.33419.80527@celery-worker-107.ash1.bb-inf.net>

New issue 2869: Celery Memory growing forever
https://bitbucket.org/pypy/pypy/issues/2869/celery-memory-growing-forever

Geun Tack Lim:

Currently, I'm trying to run the celery using pypy.

I saw some improvement after JIT warm up almost 2x

However, when I run celery==3.1.25 with pypy6.0 memory keeps growing, finally get out of memory ( our instance has 8gb ram ).  

Any clue on this issue?



From issues-reply at bitbucket.org  Thu Aug 16 01:43:08 2018
From: issues-reply at bitbucket.org (Ryuta Suzuki)
Date: Thu, 16 Aug 2018 05:43:08 +0000 (UTC)
Subject: [pypy-issue] Issue #2870: os.listdir(...) on deep path on windows
 fails with errno 123 (pypy/pypy)
Message-ID: <20180816054308.21752.66424@celery-worker-106.ash1.bb-inf.net>

New issue 2870: os.listdir(...) on deep path on windows fails with errno 123
https://bitbucket.org/pypy/pypy/issues/2870/oslistdir-on-deep-path-on-windows-fails

Ryuta Suzuki:

Traceback (most recent call last):
  File "./test_list_long_path.py", line 7, in <module>
    names = os.listdir(path)
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: \\?\C:\msys64\home\cd4mcq\packages\graal\graal\truffle\mxbuild\src\com.oracle.truffle.nfi.test\src_gen\com

This bug is fixed in CPython: https://bugs.python.org/issue32539



From issues-reply at bitbucket.org  Fri Aug 17 11:01:20 2018
From: issues-reply at bitbucket.org (jab)
Date: Fri, 17 Aug 2018 15:01:20 +0000 (UTC)
Subject: [pypy-issue] Issue #2871: doc.pypy.org is down (pypy/pypy)
Message-ID: <20180817150120.20176.57601@celery-worker-109.ash1.bb-inf.net>

New issue 2871: doc.pypy.org is down
https://bitbucket.org/pypy/pypy/issues/2871/docpypyorg-is-down

jab:

Quoting https://downforeveryoneorjustme.com/doc.pypy.org on 2018-08-17 at 15:00 UTC:

> It's not just you! doc.pypy.org looks down from here.



From issues-reply at bitbucket.org  Sun Aug 19 08:14:21 2018
From: issues-reply at bitbucket.org (Ned Batchelder)
Date: Sun, 19 Aug 2018 12:14:21 +0000 (UTC)
Subject: [pypy-issue] Issue #2872: Default isolation mode is different on
 pypy? (pypy/pypy)
Message-ID: <20180819121421.8076.31543@celery-worker-106.ash1.bb-inf.net>

New issue 2872: Default isolation mode is different on pypy?
https://bitbucket.org/pypy/pypy/issues/2872/default-isolation-mode-is-different-on

Ned Batchelder:

multisql.py:
```
import sqlite3
import sys

print(sys.version)
print(sqlite3.sqlite_version)

con = sqlite3.connect("the.db")
with con:
    con.execute("pragma journal_mode=off")
    con.execute("create table foo (bar text)")
    con.execute("insert into foo (bar) values (?)", ("hello",))
    con.execute("insert into foo (bar) values (?)", ("goodbye",))

con = sqlite3.connect("the.db")
with con:
    print(list(con.execute("select * from foo")))
```
Running it on CPython 3.6:
```
$ .tox/py36/bin/python /tmp/multisql.py
3.6.6 (default, Jun 28 2018, 07:43:54)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]
3.19.3
[('hello',), ('goodbye',)]
```
Running it on PyPy 6.0.0:
```
$ .tox/pypy/bin/python /tmp/multisql.py
2.7.13 (ab0b9caf307d, Apr 24 2018, 18:05:02)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)]
3.19.3
Traceback (most recent call last):
  File "/tmp/multisql.py", line 12, in <module>
    con.execute("insert into foo (bar) values (?)", ("goodbye",))
  File "/usr/local/pythonz/pythons/PyPy-v6.0.0/lib_pypy/_sqlite3.py", line 487, in __exit__
    self.commit()
  File "/usr/local/pythonz/pythons/PyPy-v6.0.0/lib_pypy/_sqlite3.py", line 456, in commit
    raise self._get_exception(ret)
OperationalError: cannot commit transaction - SQL statements in progress
```

I can't find a difference detectable from the sqlite3 module that would explain the difference.



From issues-reply at bitbucket.org  Tue Aug 21 01:13:10 2018
From: issues-reply at bitbucket.org (Andreas Kloeckner)
Date: Tue, 21 Aug 2018 05:13:10 +0000 (UTC)
Subject: [pypy-issue] Issue #2873: micronumpy buffer interface: Logic for
 BUF_ANY_CONTIGUOUS is incorrect (pypy/pypy)
Message-ID: <20180821051307.13976.81115@celery-worker-105.ash1.bb-inf.net>

New issue 2873: micronumpy buffer interface: Logic for BUF_ANY_CONTIGUOUS is incorrect
https://bitbucket.org/pypy/pypy/issues/2873/micronumpy-buffer-interface-logic-for

Andreas Kloeckner:

I believe that this check:

https://bitbucket.org/pypy/pypy/src/dafacc40cdc480567d20997469467433f44fb346/pypy/module/micronumpy/concrete.py?at=default&fileviewer=file-view-default#concrete.py-390

should read
```python
        if ((flags & space.BUF_ANY_CONTIGUOUS) == space.BUF_ANY_CONTIGUOUS and
                not (self.flags & NPY.ARRAY_F_CONTIGUOUS or
                     self.flags & NPY.ARRAY_C_CONTIGUOUS)):
```
instead of
```python
        if ((flags & space.BUF_ANY_CONTIGUOUS) == space.BUF_ANY_CONTIGUOUS and
                not (self.flags & NPY.ARRAY_F_CONTIGUOUS and
                     self.flags & NPY.ARRAY_C_CONTIGUOUS)):
```



From issues-reply at bitbucket.org  Tue Aug 21 23:20:35 2018
From: issues-reply at bitbucket.org (HexDecimal)
Date: Wed, 22 Aug 2018 03:20:35 +0000 (UTC)
Subject: [pypy-issue] Issue #2874: numpy.frombuffer(ffi.buffer(x)) fails
 with the official numpy module. (pypy/pypy)
Message-ID: <20180822032035.37203.30029@celery-worker-109.ash1.bb-inf.net>

New issue 2874: numpy.frombuffer(ffi.buffer(x)) fails with the official numpy module.
https://bitbucket.org/pypy/pypy/issues/2874/numpyfrombuffer-ffibuffer-x-fails-with-the

HexDecimal:

This is valid CPython code, it also works on PyPy with the pypy/numpy fork:
```python
import cffi, numpy
ffi = cffi.FFI()
c_array = ffi.new('int[4]')
buf = ffi.buffer(c_array)
np_array = numpy.frombuffer(buf, numpy.intc)
print(np_array)
```
But when run on PyPy with the official numpy module you'll get this error:
```
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    np_array = numpy.frombuffer(buf, numpy.intc)
AttributeError: '_cffi_backend.buffer' object has no attribute '__buffer__'
```
I can work around the error on PyPy3 by wrapping `buf` in a `memoryview` but that breaks Python2.



From issues-reply at bitbucket.org  Wed Aug 22 10:01:51 2018
From: issues-reply at bitbucket.org (Brian Bruggeman)
Date: Wed, 22 Aug 2018 14:01:51 +0000 (UTC)
Subject: [pypy-issue] Issue #2875: Pypy3 venv module doesn't produce a venv
 properly (pypy/pypy)
Message-ID: <20180822140151.10843.60193@celery-worker-107.ash1.bb-inf.net>

New issue 2875: Pypy3 venv module doesn't produce a venv properly
https://bitbucket.org/pypy/pypy/issues/2875/pypy3-venv-module-doesnt-produce-a-venv

Brian Bruggeman:

I am running macos 10.13.6. I used `homebrew` to install `pypy` and `pypy3`.

When running `pypy3 -m venv $SOME_PATH`, I actually generate a `pypy` environment instead of a `pypy3` environment.


```
lrwxr-xr-x   1 brianbruggeman  staff    19B Aug 21 15:33 pypy -> /usr/local/bin/pypy
lrwxr-xr-x   1 brianbruggeman  staff    47B Aug 21 15:34 pypy3 -> /usr/local/Cellar/pypy3/6.0.0/libexec/bin/pypy3
lrwxr-xr-x   1 brianbruggeman  staff     4B Aug 21 15:33 python -> pypy
lrwxr-xr-x   1 brianbruggeman  staff     4B Aug 21 15:33 python3 -> pypy
```


I think pypy should point to pypy3's path, and pypy3 should point to pypy.



From issues-reply at bitbucket.org  Sat Aug 25 20:51:35 2018
From: issues-reply at bitbucket.org (Nathaniel Smith)
Date: Sun, 26 Aug 2018 00:51:35 +0000 (UTC)
Subject: [pypy-issue] Issue #2876: select.PIPE_BUF is missing on pypy3
 (pypy/pypy)
Message-ID: <20180826005135.28186.7268@celery-worker-109.ash1.bb-inf.net>

New issue 2876: select.PIPE_BUF is missing on pypy3
https://bitbucket.org/pypy/pypy/issues/2876/selectpipe_buf-is-missing-on-pypy3

Nathaniel Smith:

It should re-export the C constant `PIPE_BUF`, which comes from... not sure, `<unistd.h>` or something.

CPython added this in 3.2: https://docs.python.org/3/library/select.html#select.PIPE_BUF

But it's missing in pypy3 release and nightly: https://travis-ci.org/python-trio/trio/builds/420634711

CPython also added it in 2.7: https://docs.python.org/2/library/select.html#select.select.PIPE_BUF

I haven't checked if pypy2 also needs a fix.



From issues-reply at bitbucket.org  Wed Aug 29 19:34:08 2018
From: issues-reply at bitbucket.org (Sheng Zou)
Date: Wed, 29 Aug 2018 23:34:08 +0000 (UTC)
Subject: [pypy-issue] Issue #2877: Nested ctypes array instance does not
 support indexing operation properly (pypy/pypy)
Message-ID: <20180829233408.4786.53159@celery-worker-105.ash1.bb-inf.net>

New issue 2877: Nested ctypes array instance does not support indexing operation properly
https://bitbucket.org/pypy/pypy/issues/2877/nested-ctypes-array-instance-does-not

Sheng Zou:

Setup code snippet:

from ctypes import *

class HostRxDataBuffer(Array):
    _length_ = 100
    _type_ = c_char

class HostRxDataBufferArray(Array):
    _length_ = 8
    _type_ = HostRxDataBuffer


Result in PyPy:

/Users/local/Downloads/pypy2-v6.0.0-osx64/bin/pypy
Python 2.7.13 (ab0b9caf307d, Apr 24 2018, 18:05:02)
[PyPy 6.0.0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin

>>>> x = HostRxDataBuffer()
>>>> x[0]
'\x00'

This is correct. However the following does not make sense:

>>>> y = HostRxDataBufferArray()
>>>> y[0]
''

This is incorrect. y[0] should be an instance of HostRxDataBuffer

Compared to result in CPython:

python
Python 2.7.10 (default, Oct  6 2017, 22:29:07)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin

>>> x = HostRxDataBuffer()
>>> x[0]
'\x00'

The result is identical to PyPy.

>>> y = HostRxDataBufferArray()
>>> y[0]
<__main__.HostRxDataBuffer object at 0x1010db7a0>

The result is different from PyPy and the result from CPython makes perfect sense.



From issues-reply at bitbucket.org  Thu Aug 30 04:11:09 2018
From: issues-reply at bitbucket.org (Sheng Zou)
Date: Thu, 30 Aug 2018 08:11:09 +0000 (UTC)
Subject: [pypy-issue] Issue #2878: ctypes array instance does not support
 assignment operation of its element created by method "from_buffer"
 (pypy/pypy)
Message-ID: <20180830081109.18929.57616@celery-worker-110.ash1.bb-inf.net>

New issue 2878: ctypes array instance does not support assignment operation of its element created by method "from_buffer"
https://bitbucket.org/pypy/pypy/issues/2878/ctypes-array-instance-does-not-support

Sheng Zou:

Code snippet:

```
#!python

>>>> from ctypes import *
>>>> class SomeArray(Array):
....     _type_ = c_uint16
....     _size_ = 32
>>>> x = SomeArray()
>>>> x[0] = 1 # This is OK
>>>> x[0] = c_uint16(1) # This is OK
>>>> x[0] = c_uint16.from_buffer(bytearray("\x01\x00")) # Not OK, see error below
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/local/Downloads/pypy-c-jit-95034-d2dd59afa85c-osx64/lib_pypy/_ctypes/array.py", line 211, in __setitem__
    if ensure_objects(cobj) is not None:
  File "/Users/local/Downloads/pypy-c-jit-95034-d2dd59afa85c-osx64/lib_pypy/_ctypes/basics.py", line 15, in ensure_objects
    return ensure()
  File "/Users/local/Downloads/pypy-c-jit-95034-d2dd59afa85c-osx64/lib_pypy/_ctypes/primitive.py", line 396, in _ensure_objects
    assert self._objects is None
AssertionError
```

PyPy version: pypy-c-jit-95034-d2dd59afa85c-osx64/bin/pypy



From issues-reply at bitbucket.org  Thu Aug 30 15:23:31 2018
From: issues-reply at bitbucket.org (Sheng Zou)
Date: Thu, 30 Aug 2018 19:23:31 +0000 (UTC)
Subject: [pypy-issue] Issue #2879: ctypes structure with custom __init__
 which takes argument does not support construction by "from_buffer_copy"
 (pypy/pypy)
Message-ID: <20180830192331.10036.87448@celery-worker-110.ash1.bb-inf.net>

New issue 2879: ctypes structure with custom __init__  which takes argument does not support construction by "from_buffer_copy"
https://bitbucket.org/pypy/pypy/issues/2879/ctypes-structure-with-custom-__init__

Sheng Zou:

This is another case where ctypes lib in CPython and PyPy give different result.

Code snippet run in PyPy:

/Users/local/Downloads/pypy-c-jit-95034-d2dd59afa85c-osx64/bin/pypy

Python 2.7.13 (d2dd59afa85c, Aug 29 2018, 22:00:26)

[PyPy 6.1.0-alpha0 with GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)] on darwin


```
#!python

>>>> from ctypes import *
>>>> class CustomStructure(Structure):
....
....     _fields_ = [("a", c_uint16)]
....
....     def __init__(self, flag):
....         if flag is True:
....             self.a = 128
....         else:
....             self.a = 0
....
>>>> x = CustomStructure(True) # This is OK, both in PyPy and CPython
>>>> x = CustomStructure() # This is NOT OK, both in PyPy and CPython
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes exactly 2 arguments (1 given)
>>>> x = CustomStructure.from_buffer_copy(bytearray("\x01\x00")) # This is OK in CPython but NOT OK in PyPy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/local/Downloads/pypy-c-jit-95034-d2dd59afa85c-osx64/lib_pypy/_ctypes/basics.py", line 123, in from_buffer_copy
    result = self()
TypeError: __init__() takes exactly 2 arguments (1 given)
```



From issues-reply at bitbucket.org  Fri Aug 31 13:30:31 2018
From: issues-reply at bitbucket.org (Bram Cohen)
Date: Fri, 31 Aug 2018 17:30:31 +0000 (UTC)
Subject: [pypy-issue] Issue #2880: Pasting into MacOS shell doesn't indent
 correctly (pypy/pypy)
Message-ID: <20180831173030.1437.65759@celery-worker-107.ash1.bb-inf.net>

New issue 2880: Pasting into MacOS shell doesn't indent correctly
https://bitbucket.org/pypy/pypy/issues/2880/pasting-into-macos-shell-doesnt-indent

Bram Cohen:

The auto-indent in the MacOS shell, while it's the correct behavior for interactive entering of code, is broken for cut and paste. What happens when you try to paste in a whole function is that the auto-indent for later lines kicks in, then the indentation getting pasted gets added as well, resulting in a syntax error.

The appropriate solution is to make auto-indent not happen in the middle of pastes.