From issues-reply at bitbucket.org  Sat Jan  2 20:11:35 2016
From: issues-reply at bitbucket.org (Ben Hoyt)
Date: Sun, 03 Jan 2016 01:11:35 -0000
Subject: [pypy-issue] Issue #2221: PyStructSequence_SET_ITEM() crashes on
 PyPy3 in scandir C module (pypy/pypy)
Message-ID: <20160103011135.18682.1616@celery-worker-101.ash1.bb-inf.net>

New issue 2221: PyStructSequence_SET_ITEM() crashes on PyPy3 in scandir C module
https://bitbucket.org/pypy/pypy/issues/2221/pystructsequence_set_item-crashes-on-pypy3

Ben Hoyt:

I'm the author of the [scandir module](https://github.com/benhoyt/scandir) and I've been trying to get it compiling on PyPy3 (see [this issue](https://github.com/benhoyt/scandir/issues/51)). I did get it compiling, but it crashes on the `DirEntry.stat()` call due to this line of code in _scandir.c:

    PyStructSequence_SET_ITEM(v, 0, PyLong_FromLong((long)st->st_mode));

I believe the reason is that this is a macro that directly sets something in a structure, which PyPy probably doesn't like?

I realize supporting the C API is "alpha level" and probably isn't a top priority for PyPy right now, but just thought I'd make you aware. And if there's an easy fix I could do in _scandir.c, I'd appreciate any pointers there.

I'm running PyPy3 2.4.0 on Linux.



From issues-reply at bitbucket.org  Sat Jan  2 21:23:25 2016
From: issues-reply at bitbucket.org (uncaffeinated)
Date: Sun, 03 Jan 2016 02:23:25 -0000
Subject: [pypy-issue] Issue #2222: Slicing memoryview fails - RuntimeError:
 maximum recursion depth exceeded (pypy/pypy)
Message-ID: <20160103022325.71515.74902@celery-worker-102.ash1.bb-inf.net>

New issue 2222: Slicing memoryview fails - RuntimeError: maximum recursion depth exceeded
https://bitbucket.org/pypy/pypy/issues/2222/slicing-memoryview-fails-runtimeerror

uncaffeinated:

Repeatedly slicing memoryviews causes Pypy to incorrectly throw a runtime error. For example, the following program

b = memoryview('x' * 100000)
while b:
    b = b[1:]

produces "RuntimeError: maximum recursion depth exceeded" even though there is no recursion.



From issues-reply at bitbucket.org  Fri Jan  8 08:12:23 2016
From: issues-reply at bitbucket.org (Jonas Pfannschmidt)
Date: Fri, 08 Jan 2016 13:12:23 -0000
Subject: [pypy-issue] Issue #2223: itertools.islice incompatibility with
 CPython (pypy/pypy)
Message-ID: <20160108131223.2963.97545@celery-worker-101.ash1.bb-inf.net>

New issue 2223: itertools.islice incompatibility with CPython
https://bitbucket.org/pypy/pypy/issues/2223/itertoolsislice-incompatibility-with

Jonas Pfannschmidt:

itertools.islice accepts floats as parameters in CPython but not in pypy.

CPython (Python 2.7):


```
#!python

>>> import itertools
>>> itertools.islice([1,2,3,4,5,6,7,8,9], 1.0, 6.0, 2.0)
<itertools.islice object at 0x7f14cd0d1e10>
```


pypy:


```
#!python

>>>> import itertools
>>>> itertools.islice([1,2,3,4,5,6,7,8,9], 1.0, 6.0, 2.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Indicies for islice() must be None or non-negative integers
```


Please note that the behaviour in CPython for Python 3 is again different:


```
#!python

>>> import itertools
>>> itertools.islice([1,2,3,4,5,6,7,8,9], 1.0, 6.0, 2.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Stop argument for islice() must be None or an integer: 0 <= x <= sys.maxsize.

```






From issues-reply at bitbucket.org  Sun Jan 10 06:35:46 2016
From: issues-reply at bitbucket.org (Rui Pacheco)
Date: Sun, 10 Jan 2016 11:35:46 -0000
Subject: [pypy-issue] Issue #2224: Can't use with pyquery/lxml2 (pypy/pypy)
Message-ID: <20160110113546.18189.2995@celery-worker-101.ash1.bb-inf.net>

New issue 2224: Can't use with pyquery/lxml2
https://bitbucket.org/pypy/pypy/issues/2224/cant-use-with-pyquery-lxml2

Rui Pacheco:

I'm trying to use pyquery with pypy 4.0.1 and I get segfaults. I tried to do step by step debugging and got a more specific error:


```
#!python

pypy(88996,0x7fff770bd000) malloc: *** error for object 0x7faef8d8cf18: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
[1]    88996 abort      py.test -s
```

It was executing the following line:


```
#!python

self.check_element_with_attrs(result.data, 'input#csrf_token', {'type': 'hidden'})
```




From issues-reply at bitbucket.org  Wed Jan 13 17:36:00 2016
From: issues-reply at bitbucket.org (Geoffrey Sneddon)
Date: Wed, 13 Jan 2016 22:36:00 -0000
Subject: [pypy-issue] Issue #2225: PyPy3k settrace/_trace messes up scoping
 (pypy/pypy)
Message-ID: <20160113223600.18489.34790@celery-worker-101.ash1.bb-inf.net>

New issue 2225: PyPy3k settrace/_trace messes up scoping
https://bitbucket.org/pypy/pypy/issues/2225/pypy3k-settrace-_trace-messes-up-scoping

Geoffrey Sneddon:

With the below:

```
#!python

import sys

class Tracer(object):
    def start(self):
        sys.settrace(self._trace)

    def _trace(self, frame, event, arg_unused):
        return self._trace

tracer = Tracer()
tracer.start()

def getExtraClass():
    def hidden():
        pass
    
    class ExtraClass():
        def hidden(self):
            return hidden()

    return ExtraClass

extraClass = getExtraClass()
obj = extraClass()
output = obj.hidden()

```

PyPy3k gives:


```
Traceback (most recent call last):
  File "html5lib/tests/tree_construction.py", line 25, in <module>
    output = obj.hidden()
  File "html5lib/tests/tree_construction.py", line 19, in hidden
    return hidden()
TypeError: hidden() takes exactly 1 argument (0 given)
```

CPython 2.7.11, CPython 3.5.1, and PyPy 4.0.1 all manage to run the above code without problem. Only PyPy3k (2.4.0) fails.



From issues-reply at bitbucket.org  Mon Jan 18 05:23:40 2016
From: issues-reply at bitbucket.org (Ivan Kozik)
Date: Mon, 18 Jan 2016 10:23:40 -0000
Subject: [pypy-issue] Issue #2226: Excessive heap growth with simple program
 (pypy/pypy)
Message-ID: <20160118102340.8198.28789@celery-worker-102.ash1.bb-inf.net>

New issue 2226: Excessive heap growth with simple program
https://bitbucket.org/pypy/pypy/issues/2226/excessive-heap-growth-with-simple-program

Ivan Kozik:

I have a program that reads ~50KB-4MB of data from a subprocess every 12 seconds, and after running it for about a month, the pypy process (pypy 4.0.1 on Ubuntu 15.10) uses ~950MB resident memory, while I expect it to be using much less.

A simplification of that program exhibits the problem in less than a minute:

```
import random

while True:
	contents = " " * random.randint(50000, 4000000)
```

I believe pypy is making an erroneous assumption about the need for heap growth.

fijal told me to file this and that "this looks relatively serious".



From issues-reply at bitbucket.org  Tue Jan 19 03:36:55 2016
From: issues-reply at bitbucket.org (Rossen Georgiev)
Date: Tue, 19 Jan 2016 08:36:55 -0000
Subject: [pypy-issue] Issue #2227: Incorrect conversion from float to int
 (pypy/pypy)
Message-ID: <20160119083655.35877.82400@celery-worker-101.ash1.bb-inf.net>

New issue 2227: Incorrect conversion from float to int
https://bitbucket.org/pypy/pypy/issues/2227/incorrect-conversion-from-float-to-int

Rossen Georgiev:


```
#!bash

$ pypy --version
Python 2.7.10 (5f8302b8bf9f, Nov 18 2015, 14:34:24)
[PyPy 4.0.1 with MSC v.1500 32 bit]
$ pypy -c "from math import log; x = log(91**53) / log(91); print x, int(x)"
53.0 52
```




From issues-reply at bitbucket.org  Tue Jan 19 13:00:05 2016
From: issues-reply at bitbucket.org (timeyyy)
Date: Tue, 19 Jan 2016 18:00:05 -0000
Subject: [pypy-issue] Issue #2228: get-pip.py fails in pypy3 (pypy/pypy)
Message-ID: <20160119180005.49067.81402@celery-worker-102.ash1.bb-inf.net>

New issue 2228: get-pip.py fails in pypy3
https://bitbucket.org/pypy/pypy/issues/2228/get-pippy-fails-in-pypy3

timeyyy:

looks related to Issue #1696

with pypy3-2.4.0-win32, install pip fails.

pypy get-pip.py
Requirement already up-to-date: pip in c:\pypy3-2.4.0-win32\site-packages
Collecting setuptools
  Using cached setuptools-19.4-py2.py3-none-any.whl
Collecting wheel
  Using cached wheel-0.26.0-py2.py3-none-any.whl
Installing collected packages: setuptools, wheel
Exception:
Traceback (most recent call last):
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/basecommand.py", line 211, in main
    status = self.run(options, args)
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/commands/install.py", line 311, in run
    root=options.root_path,
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/req/req_set.py", line 646, in install
    **kwargs
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/req/req_install.py", line 803, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/req/req_install.py", line 998, in move_wheel_files
    isolated=self.isolated,
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/wheel.py", line 465, in move_wheel_files
    generated.extend(maker.make(spec))
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/_vendor/distlib/scripts.py", line 353, in make
    self._make_script(entry, filenames, options=options)
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/_vendor/distlib/scripts.py", line 257, in _make_script
    self._write_script(scriptnames, shebang, script, filenames, ext)
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/_vendor/distlib/scripts.py", line 193, in _write_script
    launcher = self._get_launcher('t')
  File "c:\users\timeyyy\.babun\cygwin\tmp\tmph90pdy\pip.zip\pip/_vendor/distlib/scripts.py", line 332, in _get_launcher
    result = finder(distlib_package).find(name).bytes
AttributeError: 'NoneType' object has no attribute 'bytes'






From issues-reply at bitbucket.org  Wed Jan 20 12:50:57 2016
From: issues-reply at bitbucket.org (Chuancong Gao)
Date: Wed, 20 Jan 2016 17:50:57 -0000
Subject: [pypy-issue] Issue #2229: Encountered RPython error (pypy/pypy)
Message-ID: <20160120175057.31290.42767@celery-worker-102.ash1.bb-inf.net>

New issue 2229: Encountered RPython error
https://bitbucket.org/pypy/pypy/issues/2229/encountered-rpython-error

Chuancong Gao:

I keep encounter this error in latest version of PyPy. However, the code works fine in latest version of CPython. When I change the number of lines read and the number of iterations, the problem is solved. 

Sorry I cannot share the private code. I will see if I can minimize the code to make it public.

RPython traceback:
  File "rpython_jit_metainterp_compile.c", line 23613, in send_loop_to_backend
  File "rpython_jit_backend_x86_assembler.c", line 2272, in Assembler386_assemble_loop
  File "rpython_jit_backend_x86_regalloc.c", line 512, in RegAlloc_prepare_loop
  File "rpython_jit_backend_x86_regalloc.c", line 1268, in RegAlloc__prepare
  File "rpython_jit_backend_llsupport_regalloc.c", line 7033, in compute_vars_longevity
Fatal RPython error: AssertionError



From issues-reply at bitbucket.org  Tue Jan 26 14:03:03 2016
From: issues-reply at bitbucket.org (Saul St. John)
Date: Tue, 26 Jan 2016 19:03:03 -0000
Subject: [pypy-issue] Issue #2230: anonymous structure members can't be
 found (pypy/pypy)
Message-ID: <20160126190303.38229.30810@celery-worker-101.ash1.bb-inf.net>

New issue 2230: anonymous structure members can't be found
https://bitbucket.org/pypy/pypy/issues/2230/anonymous-structure-members-cant-be-found

Saul St. John:

Attached code works on CPython 2.7.10, fails under pypy 4.0.1 with this exception:

Traceback (most recent call last):
  File "/tmp/test.py", line 12, in <module>
    o.x = 1
  File "/home/saul/Downloads/pypy-4.0.1-linux_x86_64-portable/lib_pypy/_ctypes/structure.py", line 122, in __set__
    obj._buffer.__setattr__(self.name, arg)
AttributeError: C Structure has no attribute x




From issues-reply at bitbucket.org  Fri Jan 29 13:04:05 2016
From: issues-reply at bitbucket.org (Silvio Ricardo Cordeiro)
Date: Fri, 29 Jan 2016 18:04:05 -0000
Subject: [pypy-issue] Issue #2231: List comprehensions much faster after
 unrolling (pypy/pypy)
Message-ID: <20160129180405.6420.31421@celery-worker-103.ash1.bb-inf.net>

New issue 2231: List comprehensions much faster after unrolling
https://bitbucket.org/pypy/pypy/issues/2231/list-comprehensions-much-faster-after

Silvio Ricardo Cordeiro:

The following code is much faster after unrolling the list comprehension (commenting out the first my_list line and using the second one instead):

```
#!python
indexes = range(5)
def get(i): return 42

for i in range(100*1000*1000):
    my_list = [get(i) for i in indexes]  # list-compr
    #my_list = [get(0), get(1), get(2), get(3), get(4)]   # unrolled
```

On my local machine:

```
Interpreter         list-compr     unrolled      unrolled-with-append
PyPy 2 (v2.2.1)        7.8s          1.8s               2.9s
PyPy 2 (v4.0.1)        6.2s          1.1s               1.9s
PyPy 3 (v2.4.0)       11.3s          1.8s               2.9s
```

(The table also show results for unrolling using append instead of creating the list in a single statement).

Are there any plans on improving list comprehensions, or is there any limitation I'm not aware of?



From issues-reply at bitbucket.org  Sun Jan 31 07:36:44 2016
From: issues-reply at bitbucket.org (ggg ggg)
Date: Sun, 31 Jan 2016 12:36:44 -0000
Subject: [pypy-issue] Issue #2232: Program will be terminated by Windows if
 i using Global object, import_from_mixin,
 lltype.free at the same time (pypy/pypy)
Message-ID: <20160131123644.6263.77632@celery-worker-103.ash1.bb-inf.net>

New issue 2232: Program will be terminated by Windows if i using Global object, import_from_mixin, lltype.free at the same time
https://bitbucket.org/pypy/pypy/issues/2232/program-will-be-terminated-by-windows-if-i

ggg ggg:

I use RPython to compile the code below(not real code, just demonstration). After executing the exe file, the program will be terminated by Windows.
```
#!python
class Global_Object(object):
    def __init__(self):
        self._default_colors = []
    def add_default_color(self, default_color):
        self._default_colors.append(default_color)
    def destroy(self):
        for default_color in self._default_colors:
            default_color.destroy()

global_object = Global_Object()

class Sdl_Color_Mixin:
    def initialize_sdl_color_mixin(self, r, g, b, a):
        self._sdl_color = lltype.malloc(SDL_Color, flavor='raw')
        rffi.setintfield(self._sdl_color, 'c_r', r)
        rffi.setintfield(self._sdl_color, 'c_g', g)
        rffi.setintfield(self._sdl_color, 'c_b', b)
        rffi.setintfield(self._sdl_color, 'c_a', a)
    def destroy_sdl_color_mixin(self):
        lltype.free(self._sdl_color, flavor='raw') # the program is terminated at this line

class Default_Color(object):
    import_from_mixin(Sdl_Color_Mixin)
    def __init__(self, r, g, b, a=255):
        self.initialize_sdl_color_mixin(r, g, b, a)
        global_object.add_default_color(self)
    def destroy(self):
        self.destroy_sdl_color_mixin()

RED = Default_Color(255, 0, 0)
global_object.destroy()
```
If i don't use import_from_mixin and copy all the code in the Sdl_Color_Mixin to Default_Color like the code below, then everything is fine.
```
#!python
class Global_Object(object):
    def __init__(self):
        self._default_colors = []
    def add_default_color(self, default_color):
        self._default_colors.append(default_color)
    def destroy(self):
        for default_color in self._default_colors:
            default_color.destroy()

global_object = Global_Object()

class Default_Color(object):
    import_from_mixin(Sdl_Color_Mixin)
    def __init__(self, r, g, b, a=255):
        self.initialize_sdl_color_mixin(r, g, b, a)
        global_object.add_default_color(self)
    def destroy(self):
        self.destroy_sdl_color_mixin()
    def initialize_sdl_color_mixin(self, r, g, b, a):
        self._sdl_color = lltype.malloc(SDL_Color, flavor='raw')
        rffi.setintfield(self._sdl_color, 'c_r', r)
        rffi.setintfield(self._sdl_color, 'c_g', g)
        rffi.setintfield(self._sdl_color, 'c_b', b)
        rffi.setintfield(self._sdl_color, 'c_a', a)
    def destroy_sdl_color_mixin(self):
        lltype.free(self._sdl_color, flavor='raw') 

RED = Default_Color(255, 0, 0)
global_object.destroy()
```
This is strange. Since the program is terminated at lltype.free, the problem should be around the pointer, but i am pretty sure that the pointer is valid and i did not delete it twice. If the problem is the wrong usage of pointer, it can not explain why i just move the code from Sdl_Color_Mixin to Default_Color then the program will not be terminated either. The problem occurs only if the target is a global object like RED. If i create a Default_Color object in the main function, the program will not be terminated. I guess the import_from_mixin has some side effect when using on global object.