From issues-reply at bitbucket.org  Tue Sep  1 15:25:18 2015
From: issues-reply at bitbucket.org (squeaky)
Date: Tue, 01 Sep 2015 13:25:18 -0000
Subject: [pypy-issue] Issue #2131: package.py builds cffi bindings using
 invoking CPython instead of packaged PyPy (pypy/pypy)
Message-ID: <20150901132518.27947.16719@app10.ash-private.bitbucket.org>

New issue 2131: package.py builds cffi bindings using invoking CPython instead of packaged PyPy
https://bitbucket.org/pypy/pypy/issues/2131/packagepy-builds-cffi-bindings-using

squeaky:

package.py tries to build the cffi bindings for the second time when invoked using CPython despite the bindings were arleady generated as part of translation. Previously (2.6.0) it would just work. Maybe package.py shouldn't try to do it at all now, o try to see if there were built and skip, or build them using the PyPy interpreter that is being packaged, not the invoker.

```
* _audioop_build.py
 _audioop_cffi.c:2:20: fatal error: Python.h: No such file or directory
 #include <Python.h>
                    ^
compilation terminated.
Traceback (most recent call last):
  File "_audioop_build.py", line 621, in <module>
    ffi.compile()
  File "/src/pypy/lib_pypy/cffi/api.py", line 583, in compile
    source_extension=source_extension, **kwds)
  File "/src/pypy/lib_pypy/cffi/recompiler.py", line 1239, in recompile
    outputfilename = ffiplatform.compile('.', ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 38, in compile
    outputfilename = _build(tmpdir, ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 65, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'cc' failed with exit status 1

* _curses_build.py
 _curses_cffi.c:2:20: fatal error: Python.h: No such file or directory
 #include <Python.h>
                    ^
compilation terminated.
Traceback (most recent call last):
  File "_curses_build.py", line 323, in <module>
    ffi.compile()
  File "/src/pypy/lib_pypy/cffi/api.py", line 583, in compile
    source_extension=source_extension, **kwds)
  File "/src/pypy/lib_pypy/cffi/recompiler.py", line 1239, in recompile
    outputfilename = ffiplatform.compile('.', ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 38, in compile
    outputfilename = _build(tmpdir, ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 65, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'cc' failed with exit status 1

* _gdbm_build.py
 _gdbm_cffi.c:2:20: fatal error: Python.h: No such file or directory
 #include <Python.h>
                    ^
compilation terminated.
Traceback (most recent call last):
  File "_gdbm_build.py", line 65, in <module>
    ffi.compile()
  File "/src/pypy/lib_pypy/cffi/api.py", line 583, in compile
    source_extension=source_extension, **kwds)
  File "/src/pypy/lib_pypy/cffi/recompiler.py", line 1239, in recompile
    outputfilename = ffiplatform.compile('.', ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 38, in compile
    outputfilename = _build(tmpdir, ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 65, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'cc' failed with exit status 1

* _pwdgrp_build.py
 _pwdgrp_cffi.c:2:20: fatal error: Python.h: No such file or directory
 #include <Python.h>
                    ^
compilation terminated.
Traceback (most recent call last):
  File "_pwdgrp_build.py", line 53, in <module>
    ffi.compile()
  File "/src/pypy/lib_pypy/cffi/api.py", line 583, in compile
    source_extension=source_extension, **kwds)
  File "/src/pypy/lib_pypy/cffi/recompiler.py", line 1239, in recompile
    outputfilename = ffiplatform.compile('.', ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 38, in compile
    outputfilename = _build(tmpdir, ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 65, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'cc' failed with exit status 1

* _sqlite3_build.py
 _sqlite3_cffi.c:2:20: fatal error: Python.h: No such file or directory
 #include <Python.h>
                    ^
compilation terminated.
Traceback (most recent call last):
  File "_sqlite3_build.py", line 265, in <module>
    _ffi.compile()
  File "/src/pypy/lib_pypy/cffi/api.py", line 583, in compile
    source_extension=source_extension, **kwds)
  File "/src/pypy/lib_pypy/cffi/recompiler.py", line 1239, in recompile
    outputfilename = ffiplatform.compile('.', ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 38, in compile
    outputfilename = _build(tmpdir, ext)
  File "/src/pypy/lib_pypy/cffi/ffiplatform.py", line 65, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'cc' failed with exit status 1
```




From issues-reply at bitbucket.org  Wed Sep  2 07:32:14 2015
From: issues-reply at bitbucket.org (zip xing)
Date: Wed, 02 Sep 2015 05:32:14 -0000
Subject: [pypy-issue] Issue #2132: pypy 2.61 crash (pypy/pypy)
Message-ID: <20150902053214.7171.27161@app07.ash-private.bitbucket.org>

New issue 2132: pypy 2.61 crash
https://bitbucket.org/pypy/pypy/issues/2132/pypy-261-crash

zip xing:

RPython traceback:
  File "pypy_goal_targetpypystandalone.c", line 2825, in entry_point
  File "pypy_interpreter_pyframe.c", line 4484, in rpyvmprof_f_pypy_rrr
  File "rpython_jit_metainterp_warmspot.c", line 4354, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_7
  File "pypy_interpreter_pyopcode.c", line 3580, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 7267, in dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 32581, in call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 4484, in rpyvmprof_f_pypy_rrr
  File "rpython_jit_metainterp_warmspot.c", line 4354, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_7
  File "pypy_interpreter_pyopcode.c", line 3580, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 7305, in dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 32581, in call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 4484, in rpyvmprof_f_pypy_rrr
  File "rpython_jit_metainterp_warmspot.c", line 4354, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_7
  File "pypy_interpreter_pyopcode.c", line 3580, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 7354, in dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 32581, in call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 4484, in rpyvmprof_f_pypy_rrr
  File "rpython_jit_metainterp_warmspot.c", line 4354, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_7
  File "pypy_interpreter_pyopcode.c", line 3580, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 8474, in dispatch_bytecode__AccessDirect_None
  ...
Fatal RPython error: ParseStringError



From issues-reply at bitbucket.org  Fri Sep  4 09:23:50 2015
From: issues-reply at bitbucket.org (=?utf-8?b?6ZKwIOmYtA==?=)
Date: Fri, 04 Sep 2015 07:23:50 -0000
Subject: [pypy-issue] Issue #2133: PyPy: curses.tigetstr() raises ctype
 TypeError after imported unicode_literals (pypy/pypy)
Message-ID: <20150904072350.26383.54810@app09.ash-private.bitbucket.org>

New issue 2133: PyPy: curses.tigetstr() raises ctype TypeError after imported unicode_literals
https://bitbucket.org/pypy/pypy/issues/2133/pypy-cursestigetstr-raises-ctype-typeerror

? ?:

Exactly the same issue as in #1997 and #2016 occur after doing `from __future__ import unicode_literals` in pypy2. Maybe same kind of fixes can be done as in d071706



From issues-reply at bitbucket.org  Wed Sep  9 10:09:24 2015
From: issues-reply at bitbucket.org (Edd Barrett)
Date: Wed, 09 Sep 2015 08:09:24 -0000
Subject: [pypy-issue] Issue #2134: Building cffi shared objects picks up
 system libpypy-c (pypy/pypy)
Message-ID: <20150909080924.20486.61988@app12.ash-private.bitbucket.org>

New issue 2134: Building cffi shared objects picks up system libpypy-c
https://bitbucket.org/pypy/pypy/issues/2134/building-cffi-shared-objects-picks-up

Edd Barrett:

Noticed the following warnings when building PyPy:

```
starting build_cffi_imports                                                                                                                         [27/1833]
* _audioop_build.py
 Traceback (most recent call last):
  File "<builtin>/app_main.py", line 75, in run_toplevel
  File "_audioop_build.py", line 3, in <module>
    ffi = FFI()
  File "/home/edd/research/pypy.pypy/lib_pypy/cffi/api.py", line 59, in __init__
    "version mismatch, %s != %s" % (backend.__version__, __version__)
AssertionError: version mismatch, 1.1.0 != 1.3.0

* _curses_build.py
 Traceback (most recent call last):
  File "<builtin>/app_main.py", line 75, in run_toplevel
  File "_curses_build.py", line 3, in <module>
    ffi = FFI()
  File "/home/edd/research/pypy.pypy/lib_pypy/cffi/api.py", line 59, in __init__
    "version mismatch, %s != %s" % (backend.__version__, __version__)
AssertionError: version mismatch, 1.1.0 != 1.3.0

...

/home/edd/research/pypy.pypy/pypy-c successfully built, but errors while building the above modules will be ignored
```

The problem is, the build is picking up the system libpypy-c installed by the OS package manager. Confirmed by forcing a library path:

```
$ ./pypy-c ./lib_pypy/_tkinter/tklib_build.py
Traceback (most recent call last):
  File "<builtin>/app_main.py", line 75, in run_toplevel
  File "./lib_pypy/_tkinter/tklib_build.py", line 32, in <module>
    config_ffi = FFI()
  File "/home/edd/research/pypy.pypy/lib_pypy/cffi/api.py", line 59, in __init__
    "version mismatch, %s != %s" % (backend.__version__, __version__)
AssertionError: version mismatch, 1.1.0 != 1.3.0
$ export LD_LIBRARY_PATH=`pwd`
$ ./pypy-c ./lib_pypy/_tkinter/tklib_build.py
_tkinter/tklib_cffi.c: In function '_cffi_checkfld__Tcl_Obj':
_tkinter/tklib_cffi.c:3971: warning: initialization from incompatible pointer type
_tkinter/tklib_cffi.c: In function '_cffi_checkfld__Tcl_ObjType':
_tkinter/tklib_cffi.c:3981: warning: initialization from incompatible pointer type
$ 
```

Cheers



From issues-reply at bitbucket.org  Wed Sep  9 15:10:15 2015
From: issues-reply at bitbucket.org (Vincent Michel)
Date: Wed, 09 Sep 2015 13:10:15 -0000
Subject: [pypy-issue] Issue #2135: itertools.islice performance issue
	(pypy/pypy)
Message-ID: <20150909131015.7740.46151@app10.ash-private.bitbucket.org>

New issue 2135: itertools.islice performance issue
https://bitbucket.org/pypy/pypy/issues/2135/itertoolsislice-performance-issue

Vincent Michel:

The RPython version of [itertools.slice](https://docs.python.org/2/library/itertools.html#itertools.islice) is about 6 times slower than the pure python version.

Example with a function to get the last 9 digits of the Nth term in the Fibonacci sequence:

```
#!python
from itertools import islice

def fib(a=1, b=1, m=10**9):
    while True:
        yield b
        a, b = b, (a + b) % m

def f1(n):
    return next(islice(fib(), n, None))

def f2(n):
    return next(x for i, x in enumerate(fib()) if i==n)

assert f1(100) == f2(100)
```

Timing tests (f1 uses islice and f2 uses enumerate):


```
#!shell
$ ./pypy -V
Python 2.7.10 (f3ad1e1e1d62, Aug 28 2015, 10:45:29)
[PyPy 2.6.1 with GCC 4.8.4]
$ ./pypy -m timeit -s "import test_islice" -n 10 'test_islice.f1(1000000)'
10 loops, best of 3: 112 msec per loop
$ ./pypy -m timeit -s "import test_islice" -n 10 'test_islice.f2(1000000)'
10 loops, best of 3: 17 msec per loop
```

Same tests with CPython:


```
#!shell
$ python -V
Python 2.7.6
$ python -m timeit -s "import test_islice" -n 10 'test_islice.f1(1000000)'
10 loops, best of 3: 82.3 msec per loop
$ python -m timeit -s "import test_islice" -n 10 'test_islice.f2(1000000)'
10 loops, best of 3: 117 msec per loop
```

I also tried with other pure python implementations of islice:

[From the official documentation](https://docs.python.org/2/library/itertools.html#itertools.islice)
```
#!python
def islice(iterable, *args):
    s = slice(*args)
    it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1))
    nexti = next(it)
    for i, element in enumerate(iterable):
        if i == nexti:
            yield element
            nexti = next(it)
```

[From older version of PyPy](https://github.com/MichaelBlume/pypy/blob/master/lib_pypy/itertools.py)
```
#!python
class islice(object):

    def __init__(self, iterable, *args):
        s = slice(*args)
        self.start, self.stop, self.step = s.start or 0, s.stop, s.step
        if not isinstance(self.start, (int, long)):
           raise ValueError("Start argument must be an integer")
        if self.stop is not None and not isinstance(self.stop, (int,long)):
           raise ValueError("Stop argument must be an integer or None")
        if self.step is None:
            self.step = 1
        if self.start<0 or (self.stop is not None and self.stop<0
           ) or self.step<=0:
            raise ValueError, "indices for islice() must be positive"
        self.it = iter(iterable)
        self.donext = None
        self.cnt = 0

    def __iter__(self):
        return self

    def next(self): 
        if self.donext is None:
            try:
                self.donext = self.it.next
            except AttributeError:
                raise TypeError
        nextindex = self.start
        if self.stop is not None and nextindex >= self.stop:
            raise StopIteration
        while self.cnt <= nextindex:
            nextitem = self.donext()
            self.cnt += 1
        self.start += self.step 
        return nextitem
```

And they both run as fast as f2 (pure python using enumerate).

 



From issues-reply at bitbucket.org  Sat Sep 12 21:34:51 2015
From: issues-reply at bitbucket.org (Anders Kaseorg)
Date: Sat, 12 Sep 2015 19:34:51 -0000
Subject: [pypy-issue] Issue #2136: obj[None:None] slice behavior differs
 from CPython (pypy/pypy)
Message-ID: <20150912193451.604.13026@app07.ash-private.bitbucket.org>

New issue 2136: obj[None:None] slice behavior differs from CPython
https://bitbucket.org/pypy/pypy/issues/2136/obj-none-none-slice-behavior-differs-from

Anders Kaseorg:

```
#!python
class A:
    def __getitem__(self, slice):
        print '__getitem__(%r)' % slice

A()[:]
# CPython 2.7.10 and PyPy 2.6.0: __getitem__(slice(0, 9223372036854775807, None))

A()[None:None]
# CPython 2.7.10: __getitem__(slice(None, None, None))
# PyPy 2.6.0: __getitem__(slice(0, 9223372036854775807, None))

class B(object):
    def __getitem__(self, slice):
        print '__getitem__(%r)' % slice

B()[:]
# CPython 2.7.10 and PyPy 2.6.0: __getitem__(slice(None, None, None))

B()[None:None]
# CPython 2.7.10 and PyPy 2.6.0: __getitem__(slice(None, None, None))

class C:
    def __getslice__(self, lower, upper):
        print '__getslice__(%r, %r)' % (lower, upper)

    def __getitem__(self, slice):
        print '__getitem__(%r)' % slice

C()[:]
# CPython 2.7.10 and PyPy 2.6.0: __getslice__(0, 9223372036854775807)

C()[None:None]
# CPython 2.7.10: __getitem__(slice(None, None, None))
# PyPy 2.6.0: __getslice__(0, 9223372036854775807)

class D(object):
    def __getslice__(self, lower, upper):
        print '__getslice__(%r, %r)' % (lower, upper)

    def __getitem__(self, slice):
        print '__getitem__(%r)' % slice

D()[:]
# CPython 2.7.10 and PyPy 2.6.0: __getslice__(0, 9223372036854775807)

D()[None:None]
# CPython 2.7.10: __getitem__(slice(None, None, None))
# PyPy 2.6.0: __getslice__(0, 9223372036854775807)
```

Similarly for `__setitem__`/`__setslice__` and `__delitem__`/`__delslice__`.



From issues-reply at bitbucket.org  Sat Sep 12 22:35:39 2015
From: issues-reply at bitbucket.org (Anders Kaseorg)
Date: Sat, 12 Sep 2015 20:35:39 -0000
Subject: [pypy-issue] Issue #2137: Infinite recursion with __coerce__
	(pypy/pypy)
Message-ID: <20150912203539.25046.91295@app05.ash-private.bitbucket.org>

New issue 2137: Infinite recursion with __coerce__
https://bitbucket.org/pypy/pypy/issues/2137/infinite-recursion-with-__coerce__

Anders Kaseorg:

This leads to infinite recursion (`RuntimeError: maximum recursion depth exceeded`) in PyPy 2.6.0 but not CPython 2.7.10:

```
#!python
class C:
    def __coerce__(self, other):
        print 'coerce'
        return C(), C()
    def __add__(self, other):
        return C()

C() + C()
```

CPython only calls `__coerce__` once.



From issues-reply at bitbucket.org  Sun Sep 13 10:39:27 2015
From: issues-reply at bitbucket.org (Ofir Shwartz)
Date: Sun, 13 Sep 2015 08:39:27 -0000
Subject: [pypy-issue] Issue #2138: Command line Pypy cannot locate a
 non-English characters folder for import causeing ImportError (pypy/pypy)
Message-ID: <20150913083927.17704.62007@app09.ash-private.bitbucket.org>

New issue 2138: Command line Pypy cannot locate a non-English characters folder for import causeing ImportError
https://bitbucket.org/pypy/pypy/issues/2138/command-line-pypy-cannot-locate-a-non

Ofir Shwartz:

Hello,
My project is built of several files, which I'm importing from the main file using:
*from xxx import **
The project is located in a sub-folder where some non-English characters exists in its path.

The problem is from command line:
When running from the command line:
***pypy projectname.py***
 gets an ImportError, while:
***python projectname.py***
runs correctly. 
Pypy probably cannot locate a path that includes non-English characters.

When running from **within** the pypy environment (using "import projectname") things are ok.
Attached a screenshot of everything I described; the non-English letters are Hebrew, but I guess that it's not unique to that language.

![PypyBug.png](https://bitbucket.org/repo/R7AbB/images/4135589261-PypyBug.png)





From issues-reply at bitbucket.org  Wed Sep 16 13:19:15 2015
From: issues-reply at bitbucket.org (CTPaHHuK-HEbA)
Date: Wed, 16 Sep 2015 11:19:15 -0000
Subject: [pypy-issue] Issue #2139: Fatal RPython error:
 ResumeDataVirtualAdder_finish (pypy/pypy)
Message-ID: <20150916111915.15831.77300@app08.ash-private.bitbucket.org>

New issue 2139: Fatal RPython error: ResumeDataVirtualAdder_finish
https://bitbucket.org/pypy/pypy/issues/2139/fatal-rpython-error

CTPaHHuK-HEbA:

After 2.6.1 often crash pypy, never before 2.6.0
Regularityof could not be detected. Test: it may be all well and may be falling.
Unittest, big array, print.

Windows 7
Python 2.7.10 (f3ad1e1e1d62, Aug 28 2015, 14:18:32)
[PyPy 2.6.1 with MSC v.1500 32 bit] on win32
```
#!python

RPython traceback:
  File "rpython_jit_metainterp_optimizeopt_optimizer.c", line 9296, in Optimizer_store_final_boxes_in_guard
  File "rpython_jit_metainterp_resume.c", line 9052, in ResumeDataVirtualAdder_finish
Fatal RPython error: AssertionError
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```



From issues-reply at bitbucket.org  Tue Sep 22 08:38:56 2015
From: issues-reply at bitbucket.org (William Leslie)
Date: Tue, 22 Sep 2015 06:38:56 -0000
Subject: [pypy-issue] Issue #2140: Documentation: broken link from the FAQ
	(pypy/pypy)
Message-ID: <20150922063856.15416.4737@app03.ash-private.bitbucket.org>

New issue 2140: Documentation: broken link from the FAQ
https://bitbucket.org/pypy/pypy/issues/2140/documentation-broken-link-from-the-faq

William Leslie:

In this section of the FAQ:

http://pypy.readthedocs.org/en/latest/faq.html#module-xyz-does-not-work-with-pypy-importerror

the link regarding virtualenv is broken.



From issues-reply at bitbucket.org  Tue Sep 22 09:39:07 2015
From: issues-reply at bitbucket.org (BB Z)
Date: Tue, 22 Sep 2015 07:39:07 -0000
Subject: [pypy-issue] Issue #2141: pypy 2.6.1 crash on windows (pypy/pypy)
Message-ID: <20150922073907.29165.33043@app05.ash-private.bitbucket.org>

New issue 2141: pypy 2.6.1 crash on windows
https://bitbucket.org/pypy/pypy/issues/2141/pypy-261-crash-on-windows

BB Z:

This script will cause pypy 2.6.1 crash on windows (using PyPy 2.6.1 with MSC v.1500 32 bit):


```
#!python

import threading

def run():
    while True:
        x = 1
        print x

ts = []
for i in xrange(100):
    ts.append(threading.Thread(target=run))

for t in ts:
    t.start()

```


If I turn --jit off, it does not crash.

And here is jit logfile https://bitbucket.org/snippets/zbb42/Xo5d4

;)



From issues-reply at bitbucket.org  Tue Sep 22 17:21:48 2015
From: issues-reply at bitbucket.org (Marco Neumann)
Date: Tue, 22 Sep 2015 15:21:48 -0000
Subject: [pypy-issue] Issue #2142: cpyext-driven crash when using cython -
 NotImplementedError when using __sub__ (pypy/pypy)
Message-ID: <20150922152148.2916.77066@app01.ash-private.bitbucket.org>

New issue 2142: cpyext-driven crash when using cython - NotImplementedError when using __sub__
https://bitbucket.org/pypy/pypy/issues/2142/cpyext-driven-crash-when-using-cython

Marco Neumann:

## Environment ##
foo.pyx:
```
#!python

cdef class C:
    def __cinit__(self):
        pass

    def __sub__(self, o):
        return 0
```

test.py:
```
#!python

import foo
a = foo.C()
b = foo.C()
a - b
```

cython --version:
```
#!

Cython version 0.23.2
```

pypy --version:
```
#!

Python 2.7.10 (f3ad1e1e1d62, Sep 07 2015, 21:46:51)
[PyPy 2.6.1 with GCC 5.2.0]
```

gcc --version:
```
#!

gcc (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

## Steps to reproduce ##
```
#!

cython foo.pyx
gcc -shared -IPATH/TO/YOUR/PYPY/INCLUDE -fPIC foo.c -o foo.pypy-26.so
pypy test.py
```

## Result ##
```
#!

RPython traceback:
  File "pypy_interpreter_gateway.c", line 812, in BuiltinCodePassThroughArguments1_funcrun_obj
  File "pypy_module_cpyext_slotdefs.c", line 2661, in wrap_binaryfunc_l_11
Fatal RPython error: NotImplementedError
fish: ?pypy test.py? terminated by signal SIGABRT (Abort)
```

## References ##
This bug mentioned here: https://groups.google.com/forum/#!topic/cython-users/Nm56Ow-toQw



From issues-reply at bitbucket.org  Tue Sep 22 19:13:43 2015
From: issues-reply at bitbucket.org (=?utf-8?q?Arkaitz_M=C3=BAgica_Islas?=)
Date: Tue, 22 Sep 2015 17:13:43 -0000
Subject: [pypy-issue] Issue #2143: xhtml2pdf segfault (pypy/pypy)
Message-ID: <20150922171343.13150.69727@app07.ash-private.bitbucket.org>

New issue 2143: xhtml2pdf segfault
https://bitbucket.org/pypy/pypy/issues/2143/xhtml2pdf-segfault

Arkaitz M?gica Islas:

I'm trying to run my webapp, that uses xhtml2pdf, using pypy.

Python 2.7.10 (f3ad1e1e1d6215e20d34bb65ab85ff9188c9f559, Aug 31 2015, 22:23:31)
[PyPy 2.6.1 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin


No handlers could be found for logger "xhtml2pdf"
Fatal error in cpyext, CPython compatibility layer, calling PySequence_GetItem
Either report a bug or consider not using this particular extension
<OpErrFmt object at 0x10c2aa060>
RPython traceback:
  File "pypy_module_cpyext_api_1.c", line 45303, in PyPySequence_GetItem
  File "pypy_module_cpyext_pyobject.c", line 1302, in BaseCpyTypedescr_realize
  File "pypy_objspace_std_objspace.c", line 4397, in allocate_instance__W_ObjectObject
  File "pypy_objspace_std_typeobject.c", line 4245, in W_TypeObject_check_user_subclass
Segmentation fault: 11



From issues-reply at bitbucket.org  Thu Sep 24 20:00:17 2015
From: issues-reply at bitbucket.org (mattip)
Date: Thu, 24 Sep 2015 18:00:17 -0000
Subject: [pypy-issue] Issue #2144: pypy win32 leaks memory (pypy/pypy)
Message-ID: <20150924180017.24929.91215@app08.ash-private.bitbucket.org>

New issue 2144: pypy win32 leaks memory
https://bitbucket.org/pypy/pypy/issues/2144/pypy-win32-leaks-memory

mattip:

In addition to the memory leaks in own multiprocessing tests, like [this one](http://buildbot.pypy.org/summary/longrepr?testname=AppTestBufferTooShort.%28%29.test_exception&builder=own-win-x86-32&build=686&mod=module._multiprocessing.test.test_connection)

setting ``PYPY_ALLOC=1`` and running pypy -c "exit()" prints:

    bin\pypy.exe
    Python 2.7.10 (2e8414e8d696, Sep 23 2015, 19:34:32)
    [PyPy 2.7.0-alpha0 with MSC v.1500 32 bit] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``PyPy development: the art of
    waiting''
    >>>> exit()
    mem.c: 14 mallocs left (most recent first):
    020FBBE0  pypy_g__ll_dict_resize_to__DICTPtr_Signed
    01D41938  pypy_g_IncrementalMiniMarkGC_major_collection_step
    01D41908  pypy_g_IncrementalMiniMarkGC_major_collection_step
    01D73BB0  pypy_g_IncrementalMiniMarkGC_minor_collection
    01D418A8  pypy_g_IncrementalMiniMarkGC_setup
    01D41848  pypy_g_ll_newdict_size__Struct_DICTLlT_Signed
    01D41818  pypy_g_IncrementalMiniMarkGC_setup
    01D417E8  pypy_g_IncrementalMiniMarkGC_setup
    01EA1C20  pypy_g_IncrementalMiniMarkGC_setup
    01EA1BF0  pypy_g_IncrementalMiniMarkGC_setup
    01EA1BB8  pypy_g_IncrementalMiniMarkGC_setup
    01EA1B88  pypy_g_IncrementalMiniMarkGC_setup
    01EA1B58  pypy_g_IncrementalMiniMarkGC_setup
    01EA2FC0  pypy_g_IncrementalMiniMarkGC_setup




From issues-reply at bitbucket.org  Fri Sep 25 14:01:10 2015
From: issues-reply at bitbucket.org (Vaibhav Sood)
Date: Fri, 25 Sep 2015 12:01:10 -0000
Subject: [pypy-issue] Issue #2145: lib-python/2.7/test/test_long.py fails on
 ppc-updated-backend branch (pypy/pypy)
Message-ID: <20150925120110.20872.34936@app02.ash-private.bitbucket.org>

New issue 2145: lib-python/2.7/test/test_long.py fails on ppc-updated-backend branch
https://bitbucket.org/pypy/pypy/issues/2145/lib-python-27-test-test_longpy-fails-on

Vaibhav Sood:

Hi,

I tried running lib-python/2.7/test/test_long.py on the 'ppc-updated-backend' branch and it fails with the following error:

FAIL: test_mixed_compares (test.test_long.LongTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/test/vaibhav/pypy/lib-python/2.7/test/test_long.py", line 864, in test_mixed_compares
    eq(Rcmp, xycmp, Frm("%r %r %d %d", x, y, Rcmp, xycmp))
AssertionError: 9223372036854775807 9.223372036854776e+18 -1 0

----------------------------------------------------------------------

I tried investigating the issue, the error seems to be due to floating point comparison between a float and a long not being handled correctly in pypy on ppc

On a x86 machine: 

vaibhav at vaibhav-VirtualBox:~/work-code/pypy$ pypy
Python 2.7.3 (2.2.1+dfsg-1ubuntu0.2, Dec 02 2014, 23:00:55)
[PyPy 2.2.1 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``in PyPy being only moderately
magic is a good thing <cfbolz>''
>>>> import sys
>>>> from decimal import Decimal
>>>> Decimal(sys.maxint), Decimal(float(sys.maxint))
(Decimal('9223372036854775807'), Decimal('9223372036854775808'))
>>>> sys.maxint == float(sys.maxint)
False
>>>> 


On a ppc64le machine:

test at pts00449-vm9:~/vaibhav/pypy$ pypy
Python 2.7.6 (2.3.1+dfsg-1, Jun 10 2014, 17:11:35)
[PyPy 2.3.1 with GCC 4.9.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> from decimal import Decimal
>>>> Decimal(sys.maxint), Decimal(float(sys.maxint))
(Decimal('9223372036854775807'), Decimal('9223372036854775808'))
>>>> sys.maxint == float(sys.maxint)
True
>>>>

So on a PowerPC the overflow caused by float(sys.maxint) is not handled correctly



From issues-reply at bitbucket.org  Fri Sep 25 22:29:05 2015
From: issues-reply at bitbucket.org (kmod)
Date: Fri, 25 Sep 2015 20:29:05 -0000
Subject: [pypy-issue] Issue #2146: WeakKeyDictionary has some bugs
	(pypy/pypy)
Message-ID: <20150925202905.11012.61343@app14.ash-private.bitbucket.org>

New issue 2146: WeakKeyDictionary has some bugs
https://bitbucket.org/pypy/pypy/issues/2146/weakkeydictionary-has-some-bugs

kmod:

It looks like PyPy uses the CPython implementation of WeakKeyDictionary and WeakValueDictionary, but that implementation relies on quick destruction.  It looks like PyPy (2.6.0) has a fix for the WeakValueDictionary case, but WeakKeyDictionary has the same issue (the callback can be postponed to the point that it removes the wrong entry from the dict).

Here's Pyston's solution (and corresponding test), which I think should work for PyPy but I haven't tested it:
https://github.com/dropbox/pyston/commit/28dc1184d7b2178df4e9bc00ae2e1eaffea575f9