From issues-reply at bitbucket.org  Thu Dec  1 14:26:14 2016
From: issues-reply at bitbucket.org (rauts)
Date: Thu, 01 Dec 2016 19:26:14 -0000
Subject: [pypy-issue] Issue #2442: pypy2-v5.5.0 sandbox issues Windows
 (pypy/pypy)
Message-ID: <20161201192614.14573.84810@celery-worker-106.ash1.bb-inf.net>

New issue 2442: pypy2-v5.5.0 sandbox issues Windows
https://bitbucket.org/pypy/pypy/issues/2442/pypy2-v550-sandbox-issues-windows

rauts:

Building the executable with
```
C:\pypy\pypy\goal>C:\pypy\pypy.exe C:\pypy\rpython\bin\rpython -O2 --sandbox targetpypystandalone.py
```
works. But runnig it results into 
```
C:\pypy>pypy.exe pypy\sandbox\pypy_interact.py pypy\goal\pypy-c.exe
Not implemented: sandboxing for external function 'GetFullPathNameA'
debug: OperationError:
debug:  operror-type: RuntimeError
debug:  operror-value: None
[Subprocess exit code: 1]
```
Something similar was discussed over two years ago #1876. I'm not sure if I have to use the version from before 2014-10-05 or if there are any other options.




From issues-reply at bitbucket.org  Thu Dec  1 20:21:33 2016
From: issues-reply at bitbucket.org (DemiMarie)
Date: Fri, 02 Dec 2016 01:21:33 -0000
Subject: [pypy-issue] Issue #2443: Hyperblock scheduling (pypy/pypy)
Message-ID: <20161202012133.29381.4471@celery-worker-106.ash1.bb-inf.net>

New issue 2443: Hyperblock scheduling
https://bitbucket.org/pypy/pypy/issues/2443/hyperblock-scheduling

DemiMarie:

PyPy has poor performance on workloads with a large number of unbiased branches, due to poor inter-trace optimizations.

Hyperblock scheduling solves this problem by merging several traces into a single combined trace.  See [LuaJIT's issue 37](https://github.com/LuaJIT/LuaJIT/issues/37) for more information.



From issues-reply at bitbucket.org  Sat Dec  3 18:33:14 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Sat, 03 Dec 2016 23:33:14 -0000
Subject: [pypy-issue] Issue #2444: PyPy/cpyext: Reference counting leak when
 using the buffer protocol (pypy/pypy)
Message-ID: <20161203233314.5231.96781@celery-worker-105.ash1.bb-inf.net>

New issue 2444: PyPy/cpyext: Reference counting leak when using the buffer protocol
https://bitbucket.org/pypy/pypy/issues/2444/pypy-cpyext-reference-counting-leak-when

Wenzel Jakob:

Hi,

I encountered the following issue which became apparent when adding PyPy support to pybind11 and trying to get the test suite to pass.

PyPy currently leaks instances of cpyext types implementing the buffer protocol even when matched calls to ``PyObject_GetBuffer`` and ``PyBuffer_Release`` are used.

To reproduce, do the following:

```
#!bash
$ git clone https://github.com/wjakob/pybind11
$ cd pybind11
$ cat <<EOF > example.cpp 
#include <pybind11/pybind11.h>
#include <iostream>

namespace py = pybind11;

PYBIND11_PLUGIN(example) {
    py::module m("example");

    struct Buffer {
        float f = 42.0;

        Buffer() { std::cout << "Buffer constructed." << std::endl; }
        virtual ~Buffer() { std::cout << "Buffer destructed." << std::endl; }
    };

    py::class_<Buffer>(m, "Buffer", py::buffer_protocol())
       /* Default constructor */
       .def(py::init<>())
       /* Constructor taking an instance satisfying the buffer protocol (buffer will be requested and immediately released) */
       .def("__init__", [](Buffer &buffer, py::buffer b) { new (&buffer) Buffer(); b.request(); })
       /* Callback which provides access to the internal buffer */
       .def_buffer([](Buffer &m) -> py::buffer_info {
            return py::buffer_info(
                &m.f,             /* Pointer to buffer */
                sizeof(float),    /* Size of one scalar */
                "f",              /* Python struct-style format descriptor */
                1,                /* Number of dimensions (scalar) */
                { 1 },            /* Shape */
                { sizeof(float) } /* Strides */
            );
        });

    return m.ptr();
}
EOF
```


Expected behavior (shown here on Python 2.7).
```
#!bash
# Compile module
# (remove the -undefined dynamic_lookup parameter if compiling on linux)
$ g++ example.cpp -o example.so -I include -rdynamic `python2.7-config --cflags` -I include -std=c++11 -shared -undefined dynamic_lookup
# Try it:
$ python2.7
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import example
>>> import numpy as np
>>> np.array(example.Buffer())
Buffer constructed.
Buffer destructed.
array([ 42.], dtype=float32)
```

Observed behavior on PyPy:
```
#!bash
# Compile the module
# (remove the -undefined dynamic_lookup parameter if compiling on linux)
$ g++ example.cpp -o example.pypy-41.so -I include -rdynamic -I <path-to-pypy-include-dir> -I include -std=c++11 -shared -undefined dynamic_lookup
# Try it:
~/pypy/pypy/goal/pypy-c
Python 2.7.12 (98f8c7e783db, Nov 23 2016, 15:31:26)
[PyPy 5.7.0-alpha0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``the new pypy sport is to pass
pypy bugs as cpython bugs''
>>>> import example
>>>> import numpy as np
>>>> np.array(example.Buffer())
Buffer constructed.
array([ 42.], dtype=float32)
>>>> import gc
>>>> gc.collect()
0
>>>> gc.collect()
0
>>>> gc.collect()
0
>>>> # Uh oh, Buffer instance is never getting freed
```

Note that NumPy is not to blame here -- the issue appears to be within PyPy. I added a second constructor in the example, which allows Buffer to be constructed from itself. And again:

```
$ ~/pypy/pypy/goal/pypy-c
Python 2.7.12 (98f8c7e783db, Nov 23 2016, 15:31:26)
[PyPy 5.7.0-alpha0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``NO VCS DISCUSSIONS''
>>>> import example
>>>> example.Buffer(example.Buffer())
Buffer constructed.
Buffer constructed.
<example.Buffer object at 0x000000010dffb050>
>>>> import gc
>>>> gc.collect()
0
>>>> gc.collect()
Buffer destructed.
0
>>>> gc.collect()
0
>>>> # Uh oh, second Buffer instance is never getting freed
```



From issues-reply at bitbucket.org  Sat Dec  3 19:05:14 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Sun, 04 Dec 2016 00:05:14 -0000
Subject: [pypy-issue] Issue #2445: Support pybind11 in conjunction with
 PyPy's cpyext: Multiple inheritance broken (?) (pypy/pypy)
Message-ID: <20161204000514.35350.32413@celery-worker-107.ash1.bb-inf.net>

New issue 2445: Support pybind11 in conjunction with PyPy's cpyext: Multiple inheritance broken (?)
https://bitbucket.org/pypy/pypy/issues/2445/support-pybind11-in-conjunction-with-pypys

Wenzel Jakob:

Hi,

one of the last major stumbling blocks in getting pybind11 to work nicely in conjunction with PyPy is multiple inheritance. It seems that PyPy is quite a bit more restrictive in terms of how bases can occur in a type declaration.

Instructions to reproduce:
```
#!bash

$ git clone -b pypy-mi https://github.com/wjakob/pybind11
$ cd pybind11
$ pypy-c -m pip install pytest # Needed or cmake will complain
$ cmake -DPYTHON_EXECUTABLE:FILEPATH=<path-to-pypy-c> .
$ make -j 4
$ cd tests
$ pypy-c
Python 2.7.12 (98f8c7e783db, Nov 23 2016, 15:31:26)
[PyPy 5.7.0-alpha0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``it was few yaks too late''
>>>> import pybind11_tests
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: Base12: PyType_Ready failed (TypeError: instance layout conflicts in multiple inheritance)!
```

The following (abbreviated) code in the pybind11 test suite (``tests/test_multiple_inheritance.cpp``) is to blame:
```cpp
/// Declare a new-style class Base1 deriving from object
py::class_<Base1>(m, "Base1");

/// Declare a new-style class Base2 deriving from object
py::class_<Base2>(m, "Base2");

/// Declare a new-style class Base12 deriving form Base1 and Base2
py::class_<Base12, Base1, Base2>(m, "Base12"); # Kaboom (instance layout conflicts in multiple inheritance)
```

What this code does is to allocate and set up a heap type data structure and call ``PyType_Ready`` three times in a row. In the third declaration, the ``PyObject*`` associated with the ``Base1`` and ``Base2`` types are provided as a tuple in the ``ht_type.tp_bases`` field. All of this works without problems in Python 2/3. The instance layout is also as simple as it gets. They are the same and basically just contain a pointer to the C++ instance being wrapped.

(Hence, I suspect a cpyext bug or limitation that should probably be addressed.)



From issues-reply at bitbucket.org  Mon Dec  5 17:04:12 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Mon, 05 Dec 2016 22:04:12 -0000
Subject: [pypy-issue] Issue #2446: cpyext: tp_doc field not reflected on
 Python side (pypy/pypy)
Message-ID: <20161205220412.33251.83126@celery-worker-107.ash1.bb-inf.net>

New issue 2446: cpyext: tp_doc field not reflected on Python side
https://bitbucket.org/pypy/pypy/issues/2446/cpyext-tp_doc-field-not-reflected-on

Wenzel Jakob:

Hi,

while porting pybind11 to PyPy, I've noticed that cpyext does not seem to propagate the ``tp_doc`` field to the ``__doc__`` field of a newly created type. This happens even in the case where ``tp_doc`` is properly set before the ``PyType_Ready`` call and never touched afterwards.

My diagnostics for an example type print the following info about the fields just before ``PyType_Ready``:

```
==================================
 ** Before call to PyType_Ready ** 
tp_name = ExamplePythonTypes
tp_base = NULL
tp_bases = NULL
ob_type = <class '__main__.ExamplePythonTypes__Meta'>
tp_flags = 133115
tp_basicsize = 56
tp_weaklistoffset = 32
tp_dictoffset = 0
tp_doc = Example 2 documentation
==================================
==================================
 ** After call to PyType_Ready ** 
tp_name = ExamplePythonTypes
tp_base = <type 'object'>
tp_bases = (<type 'object'>,)
ob_type = <class '__main__.ExamplePythonTypes__Meta'>
tp_flags = 137211
tp_basicsize = 56
tp_weaklistoffset = 32
tp_dictoffset = 0
tp_doc = Example 2 documentation
==================================
```

If I later inspect the docstring on the Python side, I just get an empty string:

```
>>>> pybind11_tests.ExamplePythonTypes.__doc__
>>>>
```
(however, I would have expected to get ``Example 2 documentation``)

I assume that PyPy was supposed to make a copy of that string when ``PyType_Ready`` is called -- but just in case, the C char array also still exists (i.e. pybind11 doesn't delete it).

So I assume this is some kind of a bug.



From issues-reply at bitbucket.org  Fri Dec  9 18:36:00 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Fri, 09 Dec 2016 23:36:00 -0000
Subject: [pypy-issue] Issue #2447: cpyext: _PyObject_GetDictPtr is
 unimplemented (pypy/pypy)
Message-ID: <20161209233600.10014.33400@celery-worker-101.ash1.bb-inf.net>

New issue 2447: cpyext: _PyObject_GetDictPtr is unimplemented
https://bitbucket.org/pypy/pypy/issues/2447/cpyext-_pyobject_getdictptr-is

Wenzel Jakob:

The implementation _PyObject_GetDictPtr currently looks like a placeholder that always returns NULL.

@cpython_api([PyObject], PyObjectP, error=CANNOT_FAIL)
def _PyObject_GetDictPtr(space, op):
    return lltype.nullptr(PyObjectP.TO)

This breaks one of the remaining testcases in pybind11 covering types with a modifiable dictionary.

It would be great if this could be modified to return the pointer at tp_dictoffset for types who have this field set up before PyType_Ready.



From issues-reply at bitbucket.org  Sat Dec 10 08:39:48 2016
From: issues-reply at bitbucket.org (=?utf-8?q?St=C3=A9phane_Henriot?=)
Date: Sat, 10 Dec 2016 13:39:48 -0000
Subject: [pypy-issue] =?utf-8?q?Issue_=232448=3A_Track_CPython_=C2=AB_Repl?=
 =?utf-8?q?ace_and_empty_strings_=C2=BB_issue_decision_=28pypy/pypy=29?=
Message-ID: <20161210133948.31221.76537@celery-worker-107.ash1.bb-inf.net>

New issue 2448: Track CPython ? Replace and empty strings ? issue decision
https://bitbucket.org/pypy/pypy/issues/2448/track-cpython-replace-and-empty-strings

St?phane Henriot:

See http://bugs.python.org/issue28029

The behavior is not the same between CPython and PyPy.
For what it's worth, I believe PyPy is correct, but eh?



From issues-reply at bitbucket.org  Tue Dec 13 17:41:47 2016
From: issues-reply at bitbucket.org (Wenzel Jakob)
Date: Tue, 13 Dec 2016 22:41:47 -0000
Subject: [pypy-issue] Issue #2449: Pypy/cpyext: Missing PyWeakref_Check API
 function (pypy/pypy)
Message-ID: <20161213224147.746.40361@celery-worker-101.ash1.bb-inf.net>

New issue 2449: Pypy/cpyext: Missing PyWeakref_Check API function
https://bitbucket.org/pypy/pypy/issues/2449/pypy-cpyext-missing-pyweakref_check-api

Wenzel Jakob:

Dear PyPy developers,

the cpyext C API contains many *_Check functions, but PyWeakref_Check is missing at the moment. It would be great if this could be added -- I had to use an ugly workaround involving PyRun_String in pybind11 that would be nice to remove.


Thank you,
Wenzel





From issues-reply at bitbucket.org  Fri Dec 16 09:42:42 2016
From: issues-reply at bitbucket.org (thinkwelltwd)
Date: Fri, 16 Dec 2016 14:42:42 -0000
Subject: [pypy-issue] Issue #2450: Can't import psutil on pypy3 (pypy/pypy)
Message-ID: <20161216144242.29381.52649@celery-worker-107.ash1.bb-inf.net>

New issue 2450: Can't import psutil on pypy3
https://bitbucket.org/pypy/pypy/issues/2450/cant-import-psutil-on-pypy3

thinkwelltwd:

Sorry if this issue is duplicated elsewhere. I want to try running my django application on pypy3.5 and I have a dependency on psutil. It installs well enough, but when importing, I get this traceback:

```
#!python

>>>> import psutil
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<builtin>/frozen importlib._bootstrap_external", line 672, in exec_module
  File "<frozen importlib._bootstrap>", line 223, in _call_with_frames_removed
  File "/home/home/pypy3.5/site-packages/psutil/__init__.py", line 78, in <module>
    from . import _pslinux as _psplatform
  File "<builtin>/frozen importlib._bootstrap_external", line 672, in exec_module
  File "<frozen importlib._bootstrap>", line 223, in _call_with_frames_removed
  File "/home/home/pypy3.5/site-packages/psutil/_pslinux.py", line 24, in <module>
    from . import _psutil_linux as cext
  File "<builtin>/frozen importlib._bootstrap_external", line 913, in create_module
  File "<frozen importlib._bootstrap>", line 223, in _call_with_frames_removed
ImportError: /home/user/pypy3.5/site-packages/psutil/_psutil_linux.pypy3-56.so: undefined symbol: PyModule_GetState
```

It's not the end of the world if this doesn't work, but sometime I'd like to be running on pypy3!




From issues-reply at bitbucket.org  Fri Dec 16 10:52:18 2016
From: issues-reply at bitbucket.org (fhriley)
Date: Fri, 16 Dec 2016 15:52:18 -0000
Subject: [pypy-issue] Issue #2451: Can't import _subprocess (pypy/pypy)
Message-ID: <20161216155218.7819.43775@celery-worker-101.ash1.bb-inf.net>

New issue 2451: Can't import _subprocess
https://bitbucket.org/pypy/pypy/issues/2451/cant-import-_subprocess

fhriley:

Running pypy-5.6-linux_x86_64-portable in a virtualenv:

>>>> import _posixsubprocess
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: unable to load extension module '/data/wombat/home/fhr/silkthread/env27-pypy/site-packages/_posixsubprocess.pypy-41.so': /data/wombat/home/fhr/silkthread/env27-pypy/site-packages/_posixsubprocess.pypy-41.so: undefined symbol: _PyImport_ReleaseLock



From issues-reply at bitbucket.org  Sun Dec 18 17:01:25 2016
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sun, 18 Dec 2016 22:01:25 -0000
Subject: [pypy-issue] Issue #2452: zlib with large inputs (more than 31
 bits) (pypy/pypy)
Message-ID: <20161218220125.36356.98935@celery-worker-106.ash1.bb-inf.net>

New issue 2452: zlib with large inputs (more than 31 bits)
https://bitbucket.org/pypy/pypy/issues/2452/zlib-with-large-inputs-more-than-31-bits

Armin Rigo:

In PyPy, the zlib module doesn't handle correctly large inputs (>= 2**31): ``zlib.compress("s"*(2**32))`` produces the same result as ``zlib.compress("")``.  Fix and review all functions.



From issues-reply at bitbucket.org  Mon Dec 19 17:56:04 2016
From: issues-reply at bitbucket.org (eric s)
Date: Mon, 19 Dec 2016 22:56:04 -0000
Subject: [pypy-issue] Issue #2453: PyObject_GetBuffer Regression (pypy/pypy)
Message-ID: <20161219225604.14902.3295@celery-worker-105.ash1.bb-inf.net>

New issue 2453: PyObject_GetBuffer Regression
https://bitbucket.org/pypy/pypy/issues/2453/pyobject_getbuffer-regression

eric s:

There's a regression in PyObject_GetBuffer between 5.3.x and 5.4.x, and still appearing in 5.6.x, noticed in testing on the Pillow project.  The core failure is "TypeError: PyPy does not yet implement the new buffer interface" when passing a string into PyObject_GetBuffer.

The following reproduction is the clearest Pillow code, but due to a lack of catching the error, it continues and later throws a different error. 

Using either Pillow 3.4.2 or current master, the following code succeeds in 5.3 but not in 5.4


```
#!python

from PIL import ImagePath
import array

arr = array.array("f", [0, 1])
p = ImagePath.Path(arr.tostring())

```

The line where this code diverges is in Pillow's _imaging.c, 
```
    if (PyObject_CheckBuffer(buffer)) {
        return PyObject_GetBuffer(buffer, view, PyBUF_SIMPLE);
    }
```
This call succeeds in 5.3 and fails in 5.4, returning a -1. It succeeds in CPython 2.7. 

This is a travis run triggering this bug: https://travis-ci.org/python-pillow/Pillow/jobs/184160459


Pillow is working around this by actually handling the error: https://github.com/python-pillow/Pillow/pull/2294



From issues-reply at bitbucket.org  Thu Dec 22 09:23:19 2016
From: issues-reply at bitbucket.org (Pierre Tardy)
Date: Thu, 22 Dec 2016 14:23:19 -0000
Subject: [pypy-issue] Issue #2454: ResumeDataDirectReader_getvirtual_ptr
 assertion error when profiling (pypy/pypy)
Message-ID: <20161222142319.24196.28636@celery-worker-107.ash1.bb-inf.net>

New issue 2454: ResumeDataDirectReader_getvirtual_ptr assertion error when profiling
https://bitbucket.org/pypy/pypy/issues/2454/resumedatadirectreader_getvirtual_ptr

Pierre Tardy:

Hello,
I am running buildbot_profiler within pypy docker image
The docker image I use is built here:
https://hub.docker.com/r/buildbot/buildbot-master-pypy/builds/baxjrgheh9v2meqwsjywfnb/

It is just a standard library/pypy image with buildbot installed in it, as well as buildbot_profiler:
https://pypi.python.org/pypi/buildbot-profiler/

When I start the profiler everything is fine until I add a bunch of load.
Then pypy crashes with the following traceback.

RPython traceback:
  File "rpython_jit_metainterp_1.c", line 17685, in handle_jitexception_39
  File "rpython_jit_metainterp_4.c", line 1010, in execute_assembler__star_2_24
  File "rpython_jit_metainterp.c", line 2418, in ResumeGuardForcedDescr_handle_fail
  File "rpython_jit_metainterp.c", line 4616, in resume_in_blackhole
  File "rpython_jit_metainterp.c", line 11306, in blackhole_from_resumedata
  File "rpython_jit_metainterp.c", line 38639, in ResumeDataDirectReader_consume_one_section
  File "rpython_jit_codewriter.c", line 351, in enumerate_vars__unique_id
  File "rpython_jit_metainterp_2.c", line 12302, in ResumeDataDirectReader__callback_r
  File "rpython_jit_metainterp.c", line 12778, in ResumeDataDirectReader_getvirtual_ptr
Fatal RPython error: AssertionError
Aborted (core dumped)


The profiler is using the following code to collect stack traces with a classical statistical profiling approach (SIG_TIMER based):
https://github.com/tardyp/buildbot_profiler/blob/master/buildbot_profiler/api.py


I didn't investigate yet posting the bug first. After some feedback I see how I can make an easier to reproduce setup.





From issues-reply at bitbucket.org  Mon Dec 26 18:22:41 2016
From: issues-reply at bitbucket.org (Danny Milosavljevic)
Date: Mon, 26 Dec 2016 23:22:41 -0000
Subject: [pypy-issue] Issue #2455: pypy3.3: building tests: environment
 variables CC etc - not honored (pypy/pypy)
Message-ID: <20161226232241.24599.15837@celery-worker-101.ash1.bb-inf.net>

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

Danny Milosavljevic:

So I've finally successfully built pypy3.3 in Guix. Yay.

However, when I run the tests I get some failures. Turns out some of them are because ./ctypes_configure/cbuild.py and ./lib_pypy/_pypy_testcapi.py call [distutils.ccompiler.]new_compiler directly and nobody calls customize_compiler.

./ctypes_configure/cbuild.py:        compiler = new_compiler(force=1)
./lib_pypy/_pypy_testcapi.py:    from distutils.ccompiler import new_compiler
./lib_pypy/_pypy_testcapi.py:    compiler = new_compiler()

After each of these new_compiler calls one should call distutils.sysconfig.customize_compiler. Otherwise the environment variables are not picked up.

What's more, _pypy_testcapi has a comment that this builds an extension. So why doesn't it build the extension using distutils build_ext ? If it did, all would work normally without having to call funny distutils internals.

What's more, ctypes_configure/cbuild.py has a homegrown compiler_command function which seems to do the same as customize_compiler would do, just with a weird name for the environment variable (PYPY_CC) and with less customizability. The file also contains another CCompiler class (in addition to distutils.CCompiler). Weird... is that left over from when there was no distutils in pypy?



From issues-reply at bitbucket.org  Tue Dec 27 14:38:50 2016
From: issues-reply at bitbucket.org (Daniele Rolando)
Date: Tue, 27 Dec 2016 19:38:50 -0000
Subject: [pypy-issue] Issue #2456: platform.linux_distribution() returns the
 wrong value on ubuntu (pypy/pypy)
Message-ID: <20161227193850.25319.33422@celery-worker-106.ash1.bb-inf.net>

New issue 2456: platform.linux_distribution() returns the wrong value on ubuntu
https://bitbucket.org/pypy/pypy/issues/2456/platformlinux_distribution-returns-the

Daniele Rolando:

```
#!bash

>> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"

>> cat /etc/debian_version
jessie/sid

>> pypy -c "import platform; print platform.linux_distribution()"
('debian', 'jessie/sid', '')

>> python  -c "import platform; print(platform.linux_distribution())"
('Ubuntu', '14.04', 'trusty')
```

The problem is in this loop: [lib-python/2.7/platform.py:323](https://bitbucket.org/pypy/pypy/src/53bc748f8ebb8c098f37bf6e290b3fba1e69926b/lib-python/2.7/platform.py?at=default&fileviewer=file-view-default#platform.py-323)

We get the distribution from the first matching file we encounter in the loop, /etc/debian_version in this case, while we should be reading it from /etc/lsb-release which is more trustworthy.
We should give some priority to these files instead of simply reading the first one.



From issues-reply at bitbucket.org  Thu Dec 29 09:26:37 2016
From: issues-reply at bitbucket.org (Thomas Baruchel)
Date: Thu, 29 Dec 2016 14:26:37 -0000
Subject: [pypy-issue] Issue #2457: Unicode issue in __code__.co_freevars
 with Pypy3 (pypy/pypy)
Message-ID: <20161229142637.12191.93683@celery-worker-101.ash1.bb-inf.net>

New issue 2457: Unicode issue in __code__.co_freevars with Pypy3
https://bitbucket.org/pypy/pypy/issues/2457/unicode-issue-in-__code__co_freevars-with

Thomas Baruchel:

Hi, I noticed a difference between CPython3 and Pypy3 for the following code; not sure if it is a bug or not. Of course, I am not claiming it is good programming, but found it while intentionally playing with  unicode names.

```
#!python
def test():
    ? = 42
    a = lambda n: ?
    return a.__code__.co_freevars
```





From issues-reply at bitbucket.org  Fri Dec 30 05:38:26 2016
From: issues-reply at bitbucket.org (Ryan Liu)
Date: Fri, 30 Dec 2016 10:38:26 -0000
Subject: [pypy-issue] Issue #2458: date overflow in JIT mode (pypy/pypy)
Message-ID: <20161230103826.14732.21817@celery-worker-106.ash1.bb-inf.net>

New issue 2458: date overflow in JIT mode
https://bitbucket.org/pypy/pypy/issues/2458/date-overflow-in-jit-mode

Ryan Liu:

When I run pypy file like this, It throw OverflowError
But It is OK under pypy REPL
```
#!python

from datetime import date, timedelta
dt = date(2016, 12, 28)
dt += timedelta(4)
```
The traceback log is

```
#!python
    self.calender += timedelta(4)
  File "pypy2-5.6.0/lib_pypy/datetime.py", line 918, in __add__
    return self._add_timedelta(other, 1)
  File "pypy2-5.6.0/lib_pypy/datetime.py", line 912, in _add_timedelta
    self._day + other.days * factor)
  File "pypy2-5.6.0/lib_pypy/datetime.py", line 415, in _normalize_date
    raise OverflowError("date value out of range")
OverflowError: date value out of range
```




From issues-reply at bitbucket.org  Sat Dec 31 10:02:53 2016
From: issues-reply at bitbucket.org (Tim Baanen)
Date: Sat, 31 Dec 2016 15:02:53 -0000
Subject: [pypy-issue] Issue #2459: AssertionError in parse_ebnf when nesting
 + and [] (pypy/pypy)
Message-ID: <20161231150253.39327.21844@celery-worker-106.ash1.bb-inf.net>

New issue 2459: AssertionError in parse_ebnf when nesting + and []
https://bitbucket.org/pypy/pypy/issues/2459/assertionerror-in-parse_ebnf-when-nesting

Tim Baanen:

I was using the rlib.parsing module for parsing a simple language, but I ran into an AssertionError which I can't explain (from the documentation, at least). It seems to occur whenever a symbol like `+` or `*` is used inside `[]` brackets. Here is an example file:

```
#!python

from rpython.rlib.parsing.ebnfparse import parse_ebnf
regexes, rules, ToAST = parse_ebnf("""
test: ["foo"+] "bar";
""")
```

When I run this code, both on the default branch and on the `release-pypy2.7-v5.6.0` branch, the following error occurs:

```
test/test_parser.py:10: in <module>
    """)
pypy/rpython/rlib/parsing/ebnfparse.py:57: in parse_ebnf
    s.visit(visitor)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:110: in visit_file
    return node.children[0].visit(self)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:114: in visit_list
    child.visit(self)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:131: in visit_production
    expansions = node.children[2].visit(self)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:146: in visit_body
    expansion = child.visit(self)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:153: in visit_expansion
    expansion = child.visit(self)
pypy/rpython/rlib/parsing/tree.py:86: in visit
    return getattr(visitor, "visit_" + self.symbol)(self)
pypy/rpython/rlib/parsing/ebnfparse.py:161: in visit_enclosed
    assert change == " " or change == newchange
AssertionError
```

Commenting out the assertion that is failing doesn't seem to cause any problems and the resulting parser has the right behavior. My current workaround is to make a new terminal symbol that behaves like `"foo"+` in the example code, which appears to work but is somewhat less readable.

Did I miss something or is this an actual bug in RPython and/or its documentation?