From issues-reply at bitbucket.org  Fri Nov  4 07:05:33 2016
From: issues-reply at bitbucket.org (Danny Milosavljevic)
Date: Fri, 04 Nov 2016 11:05:33 -0000
Subject: [pypy-issue] Issue #2427: pypy3.3: building extensions: environment
 variables CC etc - not honored (pypy/pypy)
Message-ID: <20161104110533.35258.5104@celery-worker-106.ash1.bb-inf.net>

New issue 2427: pypy3.3: building extensions: environment variables CC  etc - not honored
https://bitbucket.org/pypy/pypy/issues/2427/pypy33-building-extensions-environment

Danny Milosavljevic:

I'm trying to package pypy3.3 for the Guix distribution.

In the course of that I found that pypy3.3-v5.2.0-alpha1-src/lib-python/3/distutils/sysconfig_pypy.py doesn't honor the compiler environment variables ("CC" etc) like sysconfig_cpython.py does. Is that on purpose? If not, find attached a patch which makes it honor the variables (I have tested it and it works).

Responsible: cfbolz

From issues-reply at bitbucket.org  Sat Nov  5 06:10:37 2016
From: issues-reply at bitbucket.org (Daniil Yarancev)
Date: Sat, 05 Nov 2016 10:10:37 -0000
Subject: [pypy-issue] Issue #2428: platform.uname() fails on Windows
 (pypy/pypy)
Message-ID: <20161105101037.35520.6786@celery-worker-107.ash1.bb-inf.net>

New issue 2428: platform.uname() fails on Windows
https://bitbucket.org/pypy/pypy/issues/2428/platformuname-fails-on-windows

Daniil Yarancev:

Using latest nigthly build of PyPy for Win32.
This code fails:


```
#!python

import platform
print(platform.uname())
```
With this error:

```
#!python
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\PyPy\lib-python\2.7\platform.py", line 1159, in uname
    release,version,csd,ptype = win32_ver()
  File "C:\PyPy\lib-python\2.7\platform.py", line 635, in win32_ver
    maj, min, build = _get_real_winver(*winver[:3])
  File "C:\PyPy\lib-python\2.7\platform.py", line 600, in _get_real_winver
    actual_len = kernel32.GetModuleFileNameW(HANDLE(kernel32._handle),
  File "C:\PyPy\lib_pypy\_ctypes\primitive.py", line 319, in __init__
    self.value = value
  File "C:\PyPy\lib_pypy\_ctypes\primitive.py", line 188, in _setvalue
    self._buffer[0] = value
TypeError: unsupported operand type for long(): '_rawffi.alt.WinDLL'
```
With PyPy v5.4.1 everything works fine





From issues-reply at bitbucket.org  Sat Nov  5 15:09:11 2016
From: issues-reply at bitbucket.org (Tristan Seligmann)
Date: Sat, 05 Nov 2016 19:09:11 -0000
Subject: [pypy-issue] Issue #2429: cPickle issue with revdb (pypy/pypy)
Message-ID: <20161105190911.2724.16295@celery-worker-105.ash1.bb-inf.net>

New issue 2429: cPickle issue with revdb
https://bitbucket.org/pypy/pypy/issues/2429/cpickle-issue-with-revdb

Tristan Seligmann:

Minimal reproduction:
```
import cPickle
import pickle

class Cls(object):
    def __init__(self):
        self.plugins = []

obj = {'key': Cls()}
pickle.dumps(obj) # This works
cPickle.dumps(obj) # This does not
```
produces the following traceback:
```
Traceback (most recent call last):
  File "picklebug.py", line 10, in <module>
    cPickle.dumps(obj) # This does not
  File "/home/mithrandi/code/pypy/lib_pypy/cPickle.py", line 124, in dumps
    Pickler(file, protocol).dump(obj)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 224, in dump
    self.save(obj)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 653, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 667, in _batch_setitems
    save(v)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 401, in save_reduce
    save(args)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 562, in save_tuple
    save(element)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 812, in save_global
    self.memoize(obj)
  File "/home/mithrandi/code/pypy/lib_pypy/cPickle.py", line 112, in memoize
    return PythonPickler.memoize(self, obj)
  File "/home/mithrandi/code/pypy/lib-python/2.7/pickle.py", line 244, in memoize
    assert id(obj) not in self.memo
AssertionError
```
My pypy-revdb was built from a740348ea339 on the reverse-debugger branch; regular pypy 5.4.1 doesn't seem to have the same bug.



From issues-reply at bitbucket.org  Mon Nov  7 20:36:29 2016
From: issues-reply at bitbucket.org (Whitney Young)
Date: Tue, 08 Nov 2016 01:36:29 -0000
Subject: [pypy-issue] Issue #2430: Use of print via embedded code crashes
 python (pypy/pypy)
Message-ID: <20161108013629.28786.14005@celery-worker-107.ash1.bb-inf.net>

New issue 2430: Use of print via embedded code crashes python
https://bitbucket.org/pypy/pypy/issues/2430/use-of-print-via-embedded-code-crashes

Whitney Young:

I have issues trying to use `print` both when [embedding PyPy via CFFI](http://cffi.readthedocs.io/en/latest/embedding.html) and when using the [legacy embedding approach](http://doc.pypy.org/en/latest/embedding.html).

**CFFI**

I've taken the vanilla [embedding code](http://cffi.readthedocs.io/en/latest/embedding.html#usage) and modified it slightly to try to trace the error:

```c
/* file plugin.h */
typedef struct { int x, y; } point_t;
extern int do_stuff(point_t *);
```

```python
# file plugin_build.py
import cffi
ffibuilder = cffi.FFI()

with open('plugin.h') as f:
    ffibuilder.embedding_api(f.read())

ffibuilder.set_source("my_plugin", '''
    #include "plugin.h"
''')

ffibuilder.embedding_init_code(r"""
    from my_plugin import ffi

    @ffi.def_extern()
    def do_stuff(p):
        import sys
        with open("/tmp/out", "a") as f:
            f.write("running embedded\n")
            sys.stderr.write(b"stderr works\n")
            sys.stdout.write(b"stdout works\n")
            try:
                print("print is broken\n")
            except Exception as e:
                f.write("exception\n")
                f.write(repr(e) + " " + str(e) + "\n")
                sys.stderr.write(bytes(repr(e) + "\n", encoding="utf8"))

        print("adding %d and %d" % (p.x, p.y))
        return p.x + p.y
""")

ffibuilder.compile(target="plugin-1.5.*", verbose=True)
```

Compilation of this is like so for me:

```
$ python plugin.py
python: /home/wyoung/.linuxbrew/lib/libssl.so.1.0.0: no version information available (required by /home/wyoung/dev/api/env/bin/libpypy-c.so)
python: /home/wyoung/.linuxbrew/lib/libssl.so.1.0.0: no version information available (required by /home/wyoung/dev/api/env/bin/libpypy-c.so)
python: /home/wyoung/.linuxbrew/lib/libcrypto.so.1.0.0: no version information available (required by /home/wyoung/dev/api/env/bin/libpypy-c.so)
generating ./my_plugin.c
running build_ext
building 'my_plugin' extension
cc -O2 -fPIC -Wimplicit -I/home/wyoung/dev/api/env/include -c my_plugin.c -o ./my_plugin.o
my_plugin.c:825:5: warning: initialization from incompatible pointer type [enabled by default]
     _CFFI_PYTHON_STARTUP_FUNC,
     ^
my_plugin.c:825:5: warning: (near initialization for ?_cffi_pypy_init.func?) [enabled by default]
cc -shared ./my_plugin.o -L/home/wyoung/dev/api/env/bin -L/home/wyoung/dev/api/env/pypy/goal -lpypy-c -o ./plugin-1.5.so
```

I have a small driver program, `test.c` that I'm using to load this:

```c
#define _GNU_SOURCE
#include "plugin.h"
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main() {
    void *handle;

    handle = dlopen("/home/wyoung/.pythons/pypy3-v5.5.0-linux64/bin/libpypy-c.so", RTLD_NOW | RTLD_GLOBAL);
    if (!handle) {
        printf("cant find libpypy\n");
        exit(1);

    }

    handle = dlopen("/home/wyoung/dev/api/plugin-1.5.so", RTLD_NOW | RTLD_GLOBAL);
    if (!handle) {
        printf("could not load plugin :(\n");
    }

    point_t the_point;
    the_point.x = 12;
    the_point.y = 14;

    int (*stuff)(point_t *) = dlsym(handle, "do_stuff");

    int res = stuff(&the_point);

    printf("res is %d through function at %p\n", res, stuff);

    return 0;
}
```

When compiled & run:

```
$ gcc test.c -o test -ldl && LD_LIBRARY_PATH="/home/wyoung/.pythons/pypy3-v5.5.0-linux64/bin:$LD_LIBRARY_PATH" ./test
stderr works
stdout works
TypeError('must be bytes or buffer, not str',)
res is 0 through 0x7f4d9ef7dcc0
```

**Legacy Approach**

I get the same error as [described on this uWSGI issue](https://github.com/unbit/uwsgi/issues/869#issue-61051504):

```
debug: OperationError:
debug:  operror-type: AttributeError
debug:  operror-value: 'module' object has no attribute 'stdout'
```

I would imagine this is related to the above issue.



From issues-reply at bitbucket.org  Thu Nov 10 20:51:11 2016
From: issues-reply at bitbucket.org (Josh Friend)
Date: Fri, 11 Nov 2016 01:51:11 -0000
Subject: [pypy-issue] Issue #2431: Is there a pypy3.3-5.5.0 release?
 (pypy/pypy)
Message-ID: <20161111015111.22049.38841@celery-worker-108.ash1.bb-inf.net>

New issue 2431: Is there a pypy3.3-5.5.0 release?
https://bitbucket.org/pypy/pypy/issues/2431/is-there-a-pypy33-550-release

Josh Friend:

The [downloads page](http://pypy.org/download.html) only has 5.5.0-alpha.

However, there is a blog post from october [announcing the release of 5.5.0](https://morepypy.blogspot.com/2016/10/pypy3-550-released.html)

There is also a [`release-pypy3.3-5.5.0` tag](https://bitbucket.org/pypy/pypy/src/ea9979b550eeae87924dc4bef06070e8f8d0e22f/?at=release-pypy3.3-5.5.0).

Did someone forget to create and upload zips of the release?




From issues-reply at bitbucket.org  Mon Nov 14 16:43:45 2016
From: issues-reply at bitbucket.org (Irmen de Jong)
Date: Mon, 14 Nov 2016 21:43:45 -0000
Subject: [pypy-issue] Issue #2432: problems with pypy on osx,
 dyld: symbol not found _clock_gettime (pypy/pypy)
Message-ID: <20161114214345.32732.55206@celery-worker-107.ash1.bb-inf.net>

New issue 2432: problems with pypy on osx, dyld: symbol not found _clock_gettime
https://bitbucket.org/pypy/pypy/issues/2432/problems-with-pypy-on-osx-dyld-symbol-not

Irmen de Jong:

I'm using homebrew on OSX 10.11.6 El capitan. Tonight I used it to upgrade to pypy 5.6.0 but this is now causing dynamic linking symbol issues.
I think it is caused by the fact that they offer a compiled pypy version that was created using the version 8 compiler tools on OSX 10.12 Sierra and I'm running it on the previous OSX version. Some googling results in dozens of projects having dyld symbol issues related to this, for instance https://github.com/civetweb/civetweb/issues/349 
I was wondering if this is something that homebrew should fix? Or is it something that should be fixed in pypy itself?

The exact error I'm getting:

```
#!python

phobos:~ irmen$ pypy
Python 2.7.12 (aff251e543859ce4508159dd9f1a82a2f553de00, Nov 13 2016, 01:57:35)
[PyPy 5.6.0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> import time
>>>> time.clock()
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /usr/local/Cellar/pypy/5.6.0/libexec/lib/libpypy-c.dylib
  Expected in: flat namespace

dyld: Symbol not found: _clock_gettime
  Referenced from: /usr/local/Cellar/pypy/5.6.0/libexec/lib/libpypy-c.dylib
  Expected in: flat namespace

Trace/BPT trap: 5
phobos:~ irmen$
```




From issues-reply at bitbucket.org  Fri Nov 18 18:44:28 2016
From: issues-reply at bitbucket.org (Ralf Gommers)
Date: Fri, 18 Nov 2016 23:44:28 -0000
Subject: [pypy-issue] Issue #2433: Numpy segfault with PyPy 5.6.0 on OS X
 (pypy/pypy)
Message-ID: <20161118234428.30387.615@celery-worker-107.ash1.bb-inf.net>

New issue 2433: Numpy segfault with PyPy 5.6.0 on OS X
https://bitbucket.org/pypy/pypy/issues/2433/numpy-segfault-with-pypy-560-on-os-x

Ralf Gommers:

This is with current numpy master on OS X 10.12.1. OS X binary from pypy.org: https://bitbucket.org/pypy/pypy/downloads/pypy2-v5.6.0-osx64.tar.bz2

Installed numpy with ``./pypy-xxx/bin/pip install cython git+https://github.com/numpy/numpy.git``.

    $ ./pypy
    Python 2.7.12 (aff251e54385, Nov 09 2016, 17:25:49)
    [PyPy 5.6.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>> import numpy as np
    >>>> np.test()
    Running unit tests for numpy
    NumPy version 1.13.0.dev0+ec02bdc
    NumPy relaxed strides checking option: True
    NumPy is installed in /Users/rgommers/Downloads/pypy2-v5.6.0-osx64/site-packages/numpy
    Python version 2.7.12 (aff251e54385, Nov 09 2016, 17:25:49)[PyPy 5.6.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
    nose version 1.3.7
    .................................S.......................................................E........................................................................................S.............................................................RPython traceback:
      File "pypy_interpreter.c", line 43348, in BuiltinCodePassThroughArguments1_funcrun_obj
      File "pypy_module_cpyext_4.c", line 16627, in generic_cpy_call__StdObjSpaceConst_funcPtr_SomeI_17
    Fatal RPython error: AssertionError
    Abort trap: 6

Compilers are the default Clang and Gfortran from Homebrew:

    $ clang --version
    Apple LLVM version 8.0.0 (clang-800.0.42.1)
    Target: x86_64-apple-darwin16.1.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

    $ gfortran --version
    gfortran: warning: couldn't understand kern.osversion '16.1.0
    GNU Fortran (Homebrew gcc 4.9.1) 4.9.1




From issues-reply at bitbucket.org  Tue Nov 22 11:39:21 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Tue, 22 Nov 2016 16:39:21 -0000
Subject: [pypy-issue] Issue #2434: Support pybind11 in conjunction with
 PyPy's cpyext: issue with heap types (pypy/pypy)
Message-ID: <20161122163921.23004.93010@celery-worker-106.ash1.bb-inf.net>

New issue 2434: Support pybind11 in conjunction with PyPy's cpyext: issue with heap types
https://bitbucket.org/pypy/pypy/issues/2434/support-pybind11-in-conjunction-with-pypys

Wenzel Jakob:

Hi,

I'm the maintainer of [pybind11](https://github.com/pybind/pybind11), which is a modern library for creating bindings to C++ code (similar in spirit to Boost.Python). Hearing of the cpyext improvements in the latest release, I tried to see if pybind11 would work with the supported CPython API in PyPy. This would be huge, since it immediately make many projects available in PyPy.

The good news: I just had to make a few minor changes to get a few simple examples to compile. This is all in the WIP branch in pybind11 here: https://github.com/pybind/pybind11/pull/521

The bad news: I'm running into fundamental issues involving creation of types.

To reproduce:
```
$ git clone https://github.com/wjakob/pybind11
$ cd pybind11
$ cat > test.cpp <<EOF
#include <pybind11/pybind11.h>

namespace py = pybind11;

PYBIND11_PLUGIN(test) {
    py::module m("test");
    
    struct Test { };
    py::class_<Test>(m, "Test");

    return m.ptr();
}
EOF
$ g++ test.cpp -g3 -std=c++11 -I <path-to-pypy-include> -I include -undefined dynamic_lookup -shared -rdynamic -o test.so
```

Loading the module from PyPy leads to the following error:

```bash
$ pypy
Python 2.7.12 (aff251e543859ce4508159dd9f1a82a2f553de00, Nov 13 2016, 01:57:41)
[PyPy 5.6.0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> import cpyext
>>>> pyext.load_module('test.so', 'test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: global name 'pyext' is not defined
>>>> cpyext.load_module('test.so', 'test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: TypeError: can't set attributes on type object 'Test'
```

The error message is thrown when pybind11 basically calls (via CPython API)

```python
setattr(Test, '__module__', 'test')
```

Digging into the PyPy source code reveals the following source of this error message:

```python
def setdictvalue(self, space, name, w_value):
    if not self.is_heaptype():
        raise oefmt(space.w_TypeError,
                    "can't set attributes on type object '%N'", self)
```

So PyPy believes that ``Test`` is not a heap type. Which is confusing, because ``cpyext`` believes it is.

The CPython API calls boil down to:

```cpp
PyHeapTypeObject *type = ((PyHeapTypeObject*) PyType_Type.tp_alloc(&PyType_Type, 0)
type->ht_type.tp_flags |= Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE | Py_TPFLAGS_HEAPTYPE;

.. fill out remaining type fields like name, docs, ...

PyType_Ready(&type->ht_type);
PyObject_SetAttrString(type->ht_type, "__module__", ...); // BOOM, this fails
```

Interestingly, the type instance returned by ``tp_alloc`` *already* has the heap type flag set, and it is still set after the ``PyType_Ready`` call. I can only assume that PyPy has its own heap type flag that somehow isn't synchronized with the types created by cpyext.



From issues-reply at bitbucket.org  Tue Nov 22 20:21:41 2016
From: issues-reply at bitbucket.org (Mark Heppner)
Date: Wed, 23 Nov 2016 01:21:41 -0000
Subject: [pypy-issue] Issue #2435: Difference between PyPy and CPython when
 converting a subclass of dict to kwargs (pypy/pypy)
Message-ID: <20161123012141.34137.72948@celery-worker-106.ash1.bb-inf.net>

New issue 2435: Difference between PyPy and CPython when converting a subclass of dict to kwargs
https://bitbucket.org/pypy/pypy/issues/2435/difference-between-pypy-and-cpython-when

Mark Heppner:

In Django, there is a data structure called a [`MultiValueDict`](https://github.com/django/django/blob/1.10.3/django/utils/datastructures.py#L48) that subclasses off of `dict`. When converting it to kwargs, it behaves differently than CPython. I submitted a [ticket to Django](https://code.djangoproject.com/ticket/27521) that was closed pretty quickly.

An example using a [`QueryDict`](https://github.com/django/django/blob/1.10.3/django/http/request.py#L355):

```python
from django.conf import settings
settings.configure()
from django.http.request import QueryDict
q = QueryDict('foo=bar&foo=baz')

def test(**kwargs):
    print(kwargs)

test(**q)
```

In CPython, this returns `{u'foo': [u'bar', u'baz']}`, but in PyPy `{u'foo': u'baz'}` is returned. This only happens on conversion from the subclassed `dict` to kwargs.

I'm not sure if this is a bug or if the docs already [explain this behavior](http://doc.pypy.org/en/latest/cpython_differences.html#mutating-classes-of-objects-which-are-already-used-as-dictionary-keys).



From issues-reply at bitbucket.org  Wed Nov 23 19:30:06 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Thu, 24 Nov 2016 00:30:06 -0000
Subject: [pypy-issue] Issue #2436: Support pybind11 in conjunction with
 PyPy's cpyext: Crash in PyDict_Next (pypy/pypy)
Message-ID: <20161124003006.20929.46532@celery-worker-105.ash1.bb-inf.net>

New issue 2436: Support pybind11 in conjunction with PyPy's cpyext: Crash in PyDict_Next
https://bitbucket.org/pypy/pypy/issues/2436/support-pybind11-in-conjunction-with-pypys

Wenzel Jakob:

Hi,

following the fix in Issue #2434, I was able to get basic types & methods to export properly in [pybind11](https://github.com/pybind/pybind11). Also, the entire test suite compiles now (it segfaults when actually running it, but still..). Yay! :)

Looking into the test suite crashes, it turns out that the culprit is a call to ``PyDict_Next()`` to traverse the contents of a newly created type. Pybind11 uses this function to iterate over the dictionary of a type when binding C++ enumerations in Python (to do some basic postprocessing of the enumeration entries).

The CPython API calls boil down to this:

```cpp
PyObject *dict = ((PyTypeObject *) ... /* Pointer to newly created type */)->tp_dict;
PyObject *key, *value;
ssize_t pos = 0;

while (PyDict_Next(dict, &pos, &key, &value)) {
    /* Do something -- Never gets here because PyDict_Next crashes */
}
```

This works fine in Python 2.7 and 3.x but crashes in PyPy.

What's weird is that ``dict`` is a perfectly good dictionary even in PyPy. I can for instance turn it into a string and print it before the ``PyDict_Next()`` call, getting

```python
{'__init__': <unbound method pybind11_tests.EMode.__init__>, '__new__': <builtin_function_or_method object at 0x0000000104754250>, '__dict__': <getset_descriptor object at 0x00000001019724d8>, '__weakref__': <getset_descriptor object at 0x000000010191b068>, '__doc__': None, '__module__': 'pybind11_tests', '__repr__': <unbound method pybind11_tests.EMode.__repr__>, '__int__': <unbound method pybind11_tests.EMode.__int__>, '__eq__': <unbound method pybind11_tests.EMode.__eq__>, '__ne__': <unbound method pybind11_tests.EMode.__ne__>, '__hash__': <unbound method pybind11_tests.EMode.__hash__>, '__getstate__': <unbound method pybind11_tests.EMode.__getstate__>, '__setstate__': <unbound method pybind11_tests.EMode.__setstate__>, 'EFirstMode': EMode.EFirstMode, 'ESecondMode': EMode.ESecondMode}
```

but ``PyDict_Next()`` still crashes. 

LLDB reports the following backtrace:

```
  * frame #0: 0x0000000000000000
    frame #1: 0x000000010062c0a4 libpypy-c.dylib`pypy_g_PyDict_Next + 244
    frame #2: 0x00000001005f479b libpypy-c.dylib`pypy_g_wrapper_second_level__star_4_4 + 347
    frame #3: 0x0000000105d8b0e0 pybind11_tests.pypy-41.so`pybind11::enum_<MyEnum>::export_values(this=0x00007fff5fbfe580) + 80 at pybind11.h:1260
```

which is bizarre. If I read that correctly, PyPy seems to have done a jump to NULL.

How to reproduce on your end:

```
$ git clone https://github.com/wjakob/pybind11
$ cd pybind11
$ cmake -DPYTHON_EXECUTABLE:FILEPATH=<path-to-pypy>
$ make
$ pypy -m pip install pytest
$ pypy -m pytest
$
```

Thank you,
Wenzel



From issues-reply at bitbucket.org  Wed Nov 23 19:37:55 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Thu, 24 Nov 2016 00:37:55 -0000
Subject: [pypy-issue] Issue #2437: cpyext: support PyModule_GetName
 (pypy/pypy)
Message-ID: <20161124003755.30938.62214@celery-worker-106.ash1.bb-inf.net>

New issue 2437: cpyext: support PyModule_GetName
https://bitbucket.org/pypy/pypy/issues/2437/cpyext-support-pymodule_getname

Wenzel Jakob:

The cpyext implementation of PyModule_GetName throws an unsupported operation exception. This one should be simple to do -- afaik it just returns ``__name__``.



From issues-reply at bitbucket.org  Sat Nov 26 16:02:59 2016
From: issues-reply at bitbucket.org (Daniil Yarancev)
Date: Sat, 26 Nov 2016 21:02:59 -0000
Subject: [pypy-issue] Issue #2438: Crash with pyglet on Windows (only with
 JIT) (pypy/pypy)
Message-ID: <20161126210259.20239.4127@celery-worker-105.ash1.bb-inf.net>

New issue 2438: Crash with pyglet on Windows (only with JIT)
https://bitbucket.org/pypy/pypy/issues/2438/crash-with-pyglet-on-windows-only-with-jit

Daniil Yarancev:

Trying to run https://github.com/fogleman/Minecraft on Windows with pypy, using pyglet.

Without JIT (--jit off) everything works, but game is loading very slowly (you need to wait like 2-4 minutes have a possibility to move mouse, but further everything works OK).

With JIT it start, you can move the mouse, BUT if you move on another block (if you will look at the ground, you will see block selection), PyPy crashes.

Steps to reproduce:

1) Install pyglet
```
#!bash

pypy -m pip install pyglet
```


2) Download fogleman's Minecraft (written using pyglet)
```
#!bash

git clone https://github.com/fogleman/Minecraft
cd Minecraft
```

3) Run it
```
#!bash

pypy main.py
```




From issues-reply at bitbucket.org  Sun Nov 27 11:09:04 2016
From: issues-reply at bitbucket.org (Maciej Fijalkowski)
Date: Sun, 27 Nov 2016 16:09:04 -0000
Subject: [pypy-issue] Issue #2439: Pypy3.5 - pip install aiohttp fails
 (pypy/pypy)
Message-ID: <20161127160904.8662.49287@celery-worker-107.ash1.bb-inf.net>

New issue 2439: Pypy3.5 - pip install aiohttp fails
https://bitbucket.org/pypy/pypy/issues/2439/pypy35-pip-install-aiohttp-fails

Maciej Fijalkowski:

With:

AttributeError: '_ssl._SSLSocket' object has no attribute 'server_hostname'



From issues-reply at bitbucket.org  Mon Nov 28 09:24:10 2016
From: issues-reply at bitbucket.org (Richard Plangger)
Date: Mon, 28 Nov 2016 14:24:10 -0000
Subject: [pypy-issue] Issue #2440: extension_suffixes() without cpyext
 (pypy/pypy)
Message-ID: <20161128142410.38349.27339@celery-worker-108.ash1.bb-inf.net>

New issue 2440: extension_suffixes() without cpyext
https://bitbucket.org/pypy/pypy/issues/2440/extension_suffixes-without-cpyext

Richard Plangger:

The condtion in the file `pypy/module/imp/interp_imp.py:~10` prevents pypy/tools/build_cffi_imports.py to succeed if pypy was compiled without cpyext module.

>From my understanding it should be fine to just remove the condition and always include the result of `importing.get_so_extension(space)`.



From issues-reply at bitbucket.org  Tue Nov 29 16:12:39 2016
From: issues-reply at bitbucket.org (byllyfish)
Date: Tue, 29 Nov 2016 21:12:39 -0000
Subject: [pypy-issue] Issue #2441: Unicode surrogate codepoints in string
 literals combined when using unittest module (pypy/pypy)
Message-ID: <20161129211239.5825.99251@celery-worker-108.ash1.bb-inf.net>

New issue 2441: Unicode surrogate codepoints in string literals combined when using unittest module
https://bitbucket.org/pypy/pypy/issues/2441/unicode-surrogate-codepoints-in-string

byllyfish:

When running unit tests under PyPy3, I sometimes see unicode literals containing surrogate pairs combined into a single non-BMP character.

Here is `test_surrogate.py`:

```python
import unittest

class TestSurrogate(unittest.TestCase):
    def test_surrogate(self):
        s = '\ud800\udc00'
        if len(s) != 2:
            raise ValueError(s.encode('raw-unicode-escape'))
```

The first time I run it, it works fine.

```bash
$ ~/pypy3-v5.5.0-osx64/bin/pypy3 -m unittest test_surrogate
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
```

When I run the test a second time, it fails. The surrogate pair has been replaced.

```bash
$ ~/pypy3-v5.5.0-osx64/bin/pypy3 -m unittest test_surrogate
E
======================================================================
ERROR: test_surrogate (test_surrogate.TestSurrogate)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test_surrogate.py", line 7, in test_surrogate
    raise ValueError(s.encode('raw-unicode-escape'))
ValueError: b'\\U00010000'

----------------------------------------------------------------------
Ran 1 test in 0.010s

FAILED (errors=1)
```

The failures continue until I touch the file. After that, the test will succeed the first time, then fail subsequently. If I touch the file and run pypy3 with -B (don't write .py[co] files on import), all the test runs succeed.
 
N.B. The problem does NOT occur under normal conditions. I've only seen it using unittest.

```
# This small program always works fine!
s = '\ud800\udc00'
if len(s) != 2:
    raise ValueError(s.encode('raw-unicode-escape'))
```

I am running on Mac OS X 10.11.6.  Please let me know if you can reproduce this.

```
$ ~/pypy3-v5.5.0-osx64/bin/pypy3 --version
Python 3.3.5 (619c0d5af0e5, Oct 08 2016, 22:08:19)
[PyPy 5.5.0-alpha0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
```