From issues-reply at bitbucket.org  Mon Feb  2 01:15:42 2015
From: issues-reply at bitbucket.org (Alex Gaynor)
Date: Mon, 02 Feb 2015 00:15:42 -0000
Subject: [pypy-issue] Issue #1968: Bump greenlet version (pypy/pypy)
Message-ID: <20150202001542.874.75959@app13.ash-private.bitbucket.org>

New issue 1968: Bump greenlet version
https://bitbucket.org/pypy/pypy/issue/1968/bump-greenlet-version

Alex Gaynor:

Currently our greenlet claims to be 0.4.0, the latest version is 0.4.5; we should figure out what changed, and bump to the latest version.



From issues-reply at bitbucket.org  Tue Feb  3 10:12:38 2015
From: issues-reply at bitbucket.org (Ruochen Huang)
Date: Tue, 03 Feb 2015 09:12:38 -0000
Subject: [pypy-issue] Issue #1969: JIT crash when executing some benchmarks
 in Pyrlang (pypy/pypy)
Message-ID: <20150203091238.12977.71389@app08.ash-private.bitbucket.org>

New issue 1969: JIT crash when executing some benchmarks in Pyrlang
https://bitbucket.org/pypy/pypy/issue/1969/jit-crash-when-executing-some-benchmarks

Ruochen Huang:

When running some benchmarks in my project Pyrlang, I have encountered a runtime error said JIT crash when I run my interpreter binary file generated by RPython. 
The trace seems like:
RPython traceback:
  File "pyrlang_interpreter_interp.c", line 3215, in portal
  File "rpython_jit_metainterp_warmstate.c", line 286, in maybe_compile_and_run__star_7
  File "rpython_jit_metainterp_warmstate.c", line 1107, in execute_assembler__star_5
  File "rpython_jit_metainterp_compile.c", line 23562, in ResumeGuardDescr_handle_fail
  File "rpython_jit_metainterp_compile.c", line 24755, in ResumeGuardDescr__trace_and_compile_from_bridge
  File "rpython_jit_metainterp_pyjitpl_1.c", line 4955, in MetaInterp_handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl_1.c", line 5998, in MetaInterp__handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 4054, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 5916, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 6990, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 26198, in MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl.c", line 41179, in MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl.c", line 55018, in MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 6663, in compile_loop
  File "rpython_jit_metainterp_inliner.c", line 1901, in Inliner_inline_op
  File "rpython_jit_metainterp_inliner.c", line 3146, in Inliner_inline_snapshot
  File "rpython_rtyper_lltypesystem_rdict.c", line 26013, in ll_dict_getitem__dicttablePtr_objectPtr_3
~~~ Crash in JIT! <KeyError object at 0x10028fd88>
Abort trap: 6

To reproduce the crash, you can clone my repo at https://hrc706 at bitbucket.org/hrc706/pyrlang.git,
type
   rpython -Ojit targettest.py 
to compile, and run the benchmark by
   ./targettest-c -r 13 test_beam/fact.beam fact 20000
or
   ./targettest-c -r 19 test_beam/fact.beam fact 20000
The -r means the reduction count of the dispatch loop, it will decrease during the dispatch loop, and when it becomes 0, the dispatch loop will be suspended. The code for dispatch loop is in interpreter/interp.py, Process::execute.
I have also observed that the JIT only crashes when -r is 13 or 19 in this benchmark with argument of 20000, in other value of -r the crash will not occur.




From issues-reply at bitbucket.org  Tue Feb  3 21:51:24 2015
From: issues-reply at bitbucket.org (Anthony Sottile)
Date: Tue, 03 Feb 2015 20:51:24 -0000
Subject: [pypy-issue] Issue #1970: PyObject_IsInstance(dictionary variable,
 collections.Mapping) is False? (pypy/pypy)
Message-ID: <20150203205124.22754.56920@app14.ash-private.bitbucket.org>

New issue 1970: PyObject_IsInstance(dictionary variable, collections.Mapping) is False?
https://bitbucket.org/pypy/pypy/issue/1970/pyobject_isinstance-dictionary-variable

Anthony Sottile:

however `isinstance(dict_variable, collections.Mapping)` returns `True`

```
$ pypy --version
Python 2.7.8 (f5dcc2477b97, Sep 18 2014, 11:33:30)
[PyPy 2.4.0 with GCC 4.6.3]
```

```
    PyObject* collections_mod = PyImport_ImportModule("collections");
    PyObject* mapping_t = PyObject_GetAttrString(collections_mod, "Mapping");
    if (PyObject_IsInstance(value, mapping_t)) {
        printf("is a mapping\n");
    } else {
        printf("is not a mapping\n");
    }
```






From issues-reply at bitbucket.org  Thu Feb  5 16:18:34 2015
From: issues-reply at bitbucket.org (Edd Barrett)
Date: Thu, 05 Feb 2015 15:18:34 -0000
Subject: [pypy-issue] Issue #1971: PyPy-2.5 does not install into virtualenv
 if shared library is built. (pypy/pypy)
Message-ID: <20150205151834.24515.30316@app04.ash-private.bitbucket.org>

New issue 1971: PyPy-2.5 does not install into virtualenv if shared library is built.
https://bitbucket.org/pypy/pypy/issue/1971/pypy-25-does-not-install-into-virtualenv

Edd Barrett:

As discussed on irc:

```
Creating a virtualenv on an earlier pypy:
 
$ virtualenv --python=/opt/pypy/pypy-c  /tmp/pypyve_older
Running virtualenv with interpreter /opt/pypy/pypy-c
New pypy executable in /tmp/pypyve_older/bin/pypy-c
Also creating executable in /tmp/pypyve_older/bin/pypy
Installing distribute.............................................................................................................................................................................................done.
Installing pip...............done.
 
And on pypy-2.5:
 
$ virtualenv --python=/home/vext01/research/pyhyp_experiments/work/pypy-2.5.0-src/pypy/goal/pypy /tmp/pypyve
Running virtualenv with interpreter /home/vext01/research/pyhyp_experiments/work/pypy-2.5.0-src/pypy/goal/pypy
New pypy executable in /tmp/pypyve/bin/pypy
/tmp/pypyve/bin/pypy: error while loading shared libraries: libpypy.so: cannot open shared object file: No such file or directory
ERROR: The executable /tmp/pypyve/bin/pypy is not functioning
ERROR: It thinks sys.prefix is u'/home/vext01/research/pyhyp_experiments' (should be u'/tmp/pypyve')
ERROR: virtualenv is not compatible with this system or executable
```

OS is linux.

Have also tried with the newest virtualenv -- same outcome.



From issues-reply at bitbucket.org  Fri Feb  6 03:16:00 2015
From: issues-reply at bitbucket.org (Maximilian Hils)
Date: Fri, 06 Feb 2015 02:16:00 -0000
Subject: [pypy-issue] Issue #1972: Regression in 2.5.0,
	Cookie module (pypy/pypy)
Message-ID: <20150206021600.11090.43397@app03.ash-private.bitbucket.org>

New issue 1972: Regression in 2.5.0, Cookie module
https://bitbucket.org/pypy/pypy/issue/1972/regression-in-250-cookie-module

Maximilian Hils:

After Travis upgraded to PyPy 2.5.0 today, we hit a regression within our mitmproxy testsuite ([original build](https://travis-ci.org/mitmproxy/mitmproxy/builds/49685299)).

I traced it down from mitmproxy to the stdlib. PyPy 2.4.0 behaves like CPython, 2.5.0 doesn't.

```
> pypy
Python 2.7.8 (f5dcc2477b97, Sep 18 2014, 14:30:11)
[PyPy 2.4.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>> import Cookie
>>>> d = 'SSID=mooo, FOO=bar; Domain=.google.com; Path=/; Expires=Wed, 13-Jan-2021 22:23:01 GMT; Secure; '
>>>> c = Cookie.SimpleCookie(d)
>>>> c.values()[0]
<Morsel: FOO='bar'>
```

```
> pypy
Python 2.7.8 (10f1b29a2bd2, Feb 03 2015, 00:56:13)
[PyPy 2.5.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>> import Cookie
>>>> d = 'SSID=mooo, FOO=bar; Domain=.google.com; Path=/; Expires=Wed, 13-Jan-2021 22:23:01 GMT; Secure; '
>>>> c = Cookie.SimpleCookie(d)
>>>> c.values()[0]
<Morsel: SSID='mooo,'>
```



From issues-reply at bitbucket.org  Sun Feb  8 05:18:04 2015
From: issues-reply at bitbucket.org (mike fc)
Date: Sun, 08 Feb 2015 04:18:04 -0000
Subject: [pypy-issue] Issue #1973: numpy crossproduct fails (pypy/pypy)
Message-ID: <20150208041804.13929.53009@app10.ash-private.bitbucket.org>

New issue 1973: numpy crossproduct fails
https://bitbucket.org/pypy/pypy/issue/1973/numpy-crossproduct-fails

mike fc:

There's an issue with the np.cross() function with pypy - it fails with an IndexError

e.g.  np.cross(np.array([1,2,3]), np.array([4,5,6]))

Using latest pypy nightly, along with pypy-numpy latest checkout.

```
#!python

Python 2.7.8 (07ae676d67c6, Feb 07 2015, 23:01:22)
[PyPy 2.5.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy as np
/Users/mike/python/pypy-latest/site-packages/numpy/linalg/_umath_linalg.py:79: UserWarning: npy_clear_floatstatus, npy_set_floatstatus_invalid not found
  warn('npy_clear_floatstatus, npy_set_floatstatus_invalid not found')

>>>> np.cross(np.array([1,2,3]), np.array([4,5,6]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mike/python/pypy-latest/site-packages/numpy/core/numeric.py", line 1530, in cross
    shape = broadcast(a[..., 0], b[..., 0]).shape
IndexError: invalid index
```




From issues-reply at bitbucket.org  Mon Feb  9 15:48:35 2015
From: issues-reply at bitbucket.org (David MacIver)
Date: Mon, 09 Feb 2015 14:48:35 -0000
Subject: [pypy-issue] Issue #1974: Different behaviour for collections of
 nans from CPython (pypy/pypy)
Message-ID: <20150209144835.9496.15826@app03.ash-private.bitbucket.org>

New issue 1974: Different behaviour for collections of nans from CPython
https://bitbucket.org/pypy/pypy/issue/1974/different-behaviour-for-collections-of

David MacIver:

All of the following asserts pass in cpython (I've tried on 2.7, 3.3 and 3.4) but some of them fail on pypy (I've tried on pypy-2.5.0 and pypy3-2.4.0). 

```
#!python

n1 = float('nan')
n2 = float('nan')
x = [n1]
assert n1 in x
assert n2 not in x
assert x.index(n1) == 0
try:
    x.index(n2)
    assert False
except ValueError:
    pass
```

Basically, it seems like in cpython collection methods have a shortcut that treats x and y as equal if x is y even if not x == y.

The behaviour for sets is also different. For set like collections CPython treats reference equal nans as equal but other nans as distinct. 


```
#!python

n1 = float('nan')
n2 = float('nan')
n3 = float('nan')
x = {n1, n2}
assert len(x) == 2
assert n1 in x
assert n2 in x
assert n3 not in x

t = {n1}

assert t == t
assert t == {n1}
assert t != {n2}

```




From issues-reply at bitbucket.org  Tue Feb 10 18:27:20 2015
From: issues-reply at bitbucket.org (cryzed)
Date: Tue, 10 Feb 2015 17:27:20 -0000
Subject: [pypy-issue] Issue #1975: Pydub module very slow compared to
 CPython implementation (pypy/pypy)
Message-ID: <20150210172720.5248.52911@app08.ash-private.bitbucket.org>

New issue 1975: Pydub module very slow compared to CPython implementation
https://bitbucket.org/pypy/pypy/issue/1975/pydub-module-very-slow-compared-to-cpython

cryzed:

The Pydub module is 5~ times (PyPy 2) and up to 17~ times (PyPy 3) slower compared to the CPython 3 implementation when using the Pydub module. Absolute values were 3.5~ seconds for CPython, 18~ seconds for PyPy 2 and 58~ seconds for PyPy 3. Here is a sample test case:


```
#!python

import sys
import time

import pydub

PATHS = [
    'path_to_audio1.wav',
    'path_to_audio2.wav',
    'path_to_audio3.wav'
]


def main(duration):
    segments = tuple(pydub.AudioSegment.from_file(path) for path in PATHS)

    # Create a silent audio segment to easily overlay the other segments
    composition = pydub.AudioSegment.silent(duration)

    for segment in segments:
        position = 0
        length = len(segment)

        while position < duration:
            composition = composition.overlay(segment, position)
            position += length

    composition.export('output.wav', format='wav')


if __name__ == '__main__':
    start = time.time()
    main(int(sys.argv[1]))
    print(time.time() - start)
```

I use 20 short (~20 seconds) *.ogg audio files for the PATHS and pass in a duration of 60000 milliseconds. Using this script and CPython 3 and PyPy 3 the values were 6~ seconds for CPython 3 and 166 seconds for PyPy 3.



From issues-reply at bitbucket.org  Tue Feb 10 20:01:28 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Tue, 10 Feb 2015 19:01:28 -0000
Subject: [pypy-issue] Issue #1976: lib_pypy/_sqlite3.py: better support for
 FreeBSD (pypy/pypy)
Message-ID: <20150210190128.22410.68596@app02.ash-private.bitbucket.org>

New issue 1976: lib_pypy/_sqlite3.py: better support for FreeBSD
https://bitbucket.org/pypy/pypy/issue/1976/lib_pypy-_sqlite3py-better-support-for

David Naylor:

On FreeBSD the user may redefine the location of /usr/local (aka $LOCALBASE).  This patch adds support for this.  



From issues-reply at bitbucket.org  Tue Feb 10 20:02:51 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Tue, 10 Feb 2015 19:02:51 -0000
Subject: [pypy-issue] Issue #1977: lib_pypy/gdbm.py: support FreeBSD
	(pypy/pypy)
Message-ID: <20150210190251.7843.12862@app13.ash-private.bitbucket.org>

New issue 1977: lib_pypy/gdbm.py: support FreeBSD
https://bitbucket.org/pypy/pypy/issue/1977/lib_pypy-gdbmpy-support-freebsd

David Naylor:

On FreeBSD 3rd party libraries are installed under /usr/local.  This patch teaches gdbm.py where to find gdbm.h and libgdbm.so on FreeBSD



From issues-reply at bitbucket.org  Wed Feb 11 10:24:38 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Wed, 11 Feb 2015 09:24:38 -0000
Subject: [pypy-issue] Issue #1978: readline: tab should insert 4 spaces when
 at start of line (pypy/pypy)
Message-ID: <20150211092438.14465.72879@app03.ash-private.bitbucket.org>

New issue 1978: readline: tab should insert 4 spaces when at start of line
https://bitbucket.org/pypy/pypy/issue/1978/readline-tab-should-insert-4-spaces-when

Armin Rigo:

In the interactive prompt:

```
#!python

>>>> if 1:
.... <press tab here>
```

Pressing tab here should just insert 4 spaces.  It makes no sense to display all 500 possible "completions" of the empty word, and using tab to indent is a very common feature of any editor with a Python mode.



From issues-reply at bitbucket.org  Wed Feb 11 17:30:59 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Wed, 11 Feb 2015 16:30:59 -0000
Subject: [pypy-issue] Issue #1979: PyPy --no-shared cannot load any C
 extension module (pypy/pypy)
Message-ID: <20150211163059.10343.77006@app12.ash-private.bitbucket.org>

New issue 1979: PyPy --no-shared cannot load any C extension module
https://bitbucket.org/pypy/pypy/issue/1979/pypy-no-shared-cannot-load-any-c-extension

Armin Rigo:

In a modern PyPy translated with --no-shared, C extension modules cannot be loaded, because the "pypy" executable doesn't export the PyPyXxx symbols.



From issues-reply at bitbucket.org  Wed Feb 11 23:21:14 2015
From: issues-reply at bitbucket.org (mattip)
Date: Wed, 11 Feb 2015 22:21:14 -0000
Subject: [pypy-issue] Issue #1980: None in a rffi.llexternal call become /*
 nothing */ after translation (pypy/pypy)
Message-ID: <20150211222114.5929.62507@app14.ash-private.bitbucket.org>

New issue 1980: None in a rffi.llexternal call become /* nothing */ after translation
https://bitbucket.org/pypy/pypy/issue/1980/none-in-a-rffillexternal-call-become

mattip:

Using a None in a RPython rffi.llexternal function call results in ```/*nothing*/``` when translated.

Can we get either an error earlier in the translation process or a NULL emitted in code, rather than a crash of c-compilation?
```ztranslation``` passed in this case

[Here](https://gist.github.com/mattip/93f22744ad9384f48596) is an example of a complete translated function, from stdlib-2.7.9 pypy/module/_ssl/interp_win32.py






From issues-reply at bitbucket.org  Wed Feb 11 23:21:51 2015
From: issues-reply at bitbucket.org (Ivan Voras)
Date: Wed, 11 Feb 2015 22:21:51 -0000
Subject: [pypy-issue] Issue #1981: Socket timeouts with the bitcoin-python
 library (pypy/pypy)
Message-ID: <20150211222151.22022.51201@app07.ash-private.bitbucket.org>

New issue 1981: Socket timeouts with the bitcoin-python library
https://bitbucket.org/pypy/pypy/issue/1981/socket-timeouts-with-the-bitcoin-python

Ivan Voras:

The bitcoin-python library is a relatively thin wrapper over the bitcoind JSON RPC API. However, after performing some operations, it simply hangs / timeouts on random operations when used with pypy (of course, it works on CPython). The library is pure Python and available here: http://laanwj.github.io/bitcoin-python/ (it's normally installable via pip, etc.).

The following simple script demonstrates the problem:

```
from time import time
import bitcoinrpc

conn = bitcoinrpc.connect_to_local()

t1 = time()
for x in range(1000):
#    print x
    tx = conn.getrawtransaction('a79ffa13308ffc5ff5d157f2f86187d48bdff44e09071b808e5ce6eda7468571', 1)
t2 = time()
print tx
print t2 - t1
```

When run on CPython, it will complete without problems. When run under PyPy, it will hang after about 30 iterations.

Unfortunately, running the above code will require that a bitcoin client (qt or cli) is running on the local machine and has RPC enabled, as well as a full database index...




From issues-reply at bitbucket.org  Fri Feb 13 09:24:02 2015
From: issues-reply at bitbucket.org (Ben Longbons)
Date: Fri, 13 Feb 2015 08:24:02 -0000
Subject: [pypy-issue] Issue #1982: ctypes.Structure subclasses munge
 `_names` attribute (pypy/pypy)
Message-ID: <20150213082402.19238.55948@app03.ash-private.bitbucket.org>

New issue 1982: ctypes.Structure subclasses munge `_names` attribute
https://bitbucket.org/pypy/pypy/issue/1982/ctypesstructure-subclasses-munge-_names

Ben Longbons:

The below code will print `{}` in python 2.7, 3.2, and 3.4, but `['foo', 'bar']` in pypy 2.4.0 (in python2 or python3 mode).

If there is a reason to introduce new names, they should follow the ctypes `_sunder_` method.

(yeah, yeah, I should use `cffi`)

```
#!python
import ctypes

class Stuff(ctypes.Structure):
    __slots__ = ()
    _fields_ = [('foo', ctypes.c_int), ('bar', ctypes.c_int)]
    _names = {}

print(Stuff._names)
```




From issues-reply at bitbucket.org  Fri Feb 13 12:19:46 2015
From: issues-reply at bitbucket.org (Edd Barrett)
Date: Fri, 13 Feb 2015 11:19:46 -0000
Subject: [pypy-issue] Issue #1983: JIT crash on PyPy bridge. (pypy/pypy)
Message-ID: <20150213111946.16258.68992@app14.ash-private.bitbucket.org>

New issue 1983: JIT crash on PyPy bridge.
https://bitbucket.org/pypy/pypy/issue/1983/jit-crash-on-pypy-bridge

Edd Barrett:

Discussed with Armin on IRC, this looks like an RPython bug. We are using the 'hippy_bridge' branch of our PyPy fork (in sync with changes with PyPy-2.5.0) and the HippyVM 'pypy_bridge' branch as of today.

Our PyPy fork is here:
https://bitbucket.org/softdevteam/pypy-hippy-bridge

Sorry the test case is not very good.

```
$  /home/vext01/research/pyhyp_experiments/work/pyhyp/hippyvm/pyhyp /tmp/a.php
RPython traceback:
  File "rpython_jit_metainterp_pyjitpl_1.c", line 64176, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl_2.c", line 64796, in handler_getarrayitem_vable_r_1
  File "rpython_jit_metainterp_pyjitpl_3.c", line 55472, in MIFrame__opimpl_getarrayitem_vable
  File "rpython_jit_metainterp_pyjitpl_4.c", line 32219, in MIFrame__nonstandard_virtualizable
  File "rpython_jit_metainterp_pyjitpl_4.c", line 27757, in MetaInterp_replace_box
Fatal RPython error: AssertionError
Aborted


/tmp/a.php:
<?php{
function f_outer($n) {
        $inc = 2;

 $inner = embed_py_func("def inner(x): return x + inc");;

        $tot = 0;
        for ($i = 0; $i < $n; $i++) {
                $tot = $inner($tot);
        }

        $expect = 2 * $n;
        assert($tot == $expect);

}

function run_iter($n) {
        f_outer($n);
}

run_iter(1200);

}?>




$ ~/pyve/testing/bin/python hippy/main.py /tmp/a.php
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-hippy_bridge-202/platcheck_0.c -
o /tmp/usession-hippy_bridge-202/platcheck_0.o
[platform:execute] gcc /tmp/usession-hippy_bridge-202/platcheck_0.o -pthread -lintl -lrt -o /tmp/usession-hippy_bridge-202/p
latcheck_0
/home/vext01/research/pyhyp_experiments/work/pyhyp/hippyvm/hippy/sourceparser.py:2121: ParserGeneratorWarning: Token 'H_NEW_
LINE' is unused
  parser = pg.build()
/home/vext01/research/pyhyp_experiments/work/pyhyp/hippyvm/hippy/sourceparser.py:2121: ParserGeneratorWarning: Token 'H_TABU
LATURE' is unused
...
[platform:execute] gcc -shared /tmp/usession-hippy_bridge-202/rpython/translator/c/src/signals.o -pthread -lrt -o /tmp/usession-hippy_bridge-202/shared_cache/externmod.so
(process finishes ok)



rpython/jit/metainterp/pyjitpl.py:

    def replace_box(self, oldbox, newbox):                                      
        assert isinstance(oldbox, Box)                 <---?
        for frame in self.framestack:                                           
            frame.replace_active_box_in_frame(oldbox, newbox)                   
        boxes = self.virtualref_boxes                                           
        for i in range(len(boxes)):                                             
            if boxes[i] is oldbox:                                              
                boxes[i] = newbox                                               
        if (self.jitdriver_sd.virtualizable_info is not None or                 
            self.jitdriver_sd.greenfield_info is not None):                     
            boxes = self.virtualizable_boxes                                    
            for i in range(len(boxes)):                                         
                if boxes[i] is oldbox:                                          
                    boxes[i] = newbox                                           
        self.heapcache.replace_box(oldbox, newbox)
```                       



From issues-reply at bitbucket.org  Sun Feb 15 00:21:27 2015
From: issues-reply at bitbucket.org (Jakub Stasiak)
Date: Sat, 14 Feb 2015 23:21:27 -0000
Subject: [pypy-issue] Issue #1984: Continulet switch results in a segfault
	(pypy/pypy)
Message-ID: <20150214232127.27782.36687@app06.ash-private.bitbucket.org>

New issue 1984: Continulet switch results in a segfault
https://bitbucket.org/pypy/pypy/issue/1984/continulet-switch-results-in-a-segfault

Jakub Stasiak:

This is a piece of code that crashes PyPy 2.4.0, 2.5.0 and version built from the latest source code (I didn't write it like this, this is a test case I managed to isolate starting with something larger). It segfaults every time I run it on OS X 10.9.5 (homebrew build and my own builds) and Ubuntu 14.04 (official Linux x64 packages).


```
#!python

from _continuation import continulet

c1 = continulet.__new__(continulet)
c2 = continulet(lambda g: None)

continulet.switch(c1, to=c2)
continulet.switch(c1, to=c2)
```


lldb session (OS X, using pyinteractive, latest source code):

```
* thread #1: tid = 0x782cc, 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1f)
    frame #0: 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24
externmod_0.dylib`stacklet_switch + 24:
-> 0x1031fd9d8:  movq   0x20(%r14), %rbx
   0x1031fd9dc:  leaq   (%rsp), %rax
   0x1031fd9e0:  cmpq   %rax, 0x8(%rbx)
   0x1031fd9e4:  ja     0x1031fd9ef               ; stacklet_switch + 47

(lldb) disassemble
externmod_0.dylib`stacklet_switch:
   0x1031fd9c0:  pushq  %r14
   0x1031fd9c2:  pushq  %rbx
   0x1031fd9c3:  pushq  %rax
   0x1031fd9c4:  movq   %rdi, %r14
   0x1031fd9c7:  leaq   0x38e(%rip), %rdi         ; "Got target %p\n\n"
   0x1031fd9ce:  xorl   %eax, %eax
   0x1031fd9d0:  movq   %r14, %rsi
   0x1031fd9d3:  callq  0x1031fdd18               ; symbol stub for: printf
-> 0x1031fd9d8:  movq   0x20(%r14), %rbx
   0x1031fd9dc:  leaq   (%rsp), %rax
   0x1031fd9e0:  cmpq   %rax, 0x8(%rbx)
   0x1031fd9e4:  ja     0x1031fd9ef               ; stacklet_switch + 47
   0x1031fd9e6:  leaq   0x1(%rsp), %rax
   0x1031fd9eb:  movq   %rax, 0x8(%rbx)
   0x1031fd9ef:  movq   %r14, 0x20(%rbx)
   0x1031fd9f3:  leaq   0x26(%rip), %rdi          ; g_save_state
   0x1031fd9fa:  leaq   0x11f(%rip), %rsi         ; g_restore_state
   0x1031fda01:  movq   %rbx, %rdx
   0x1031fda04:  callq  *0x62e(%rip)              ; _stacklet_switchstack
   0x1031fda0a:  movq   0x18(%rbx), %rax
   0x1031fda0e:  addq   $0x8, %rsp
   0x1031fda12:  popq   %rbx
   0x1031fda13:  popq   %r14
   0x1031fda15:  retq   
   0x1031fda16:  nopw   %cs:(%rax,%rax)

(lldb) register read
General Purpose Registers:
       rax = 0x000000000000001f
       rbx = 0x00007fff5fbfac10
       rcx = 0xd8001e3171326a64
       rdx = 0x00007fff71227638  __sFX + 248
       rdi = 0x0000040000000503
       rsi = 0x0000050000000500
       rbp = 0x00007fff5fbfab00
       rsp = 0x00007fff5fbfaae0
        r8 = 0x0000000000000040
        r9 = 0x00007fff5fbfa900
       r10 = 0x00000001031fdd0a  externmod_0.dylib`symbol stub for: free + 4
       r11 = 0x0000000000000246
       r12 = 0x00007fff5fbfaa50
       r13 = 0x0000000000000001
       r14 = 0xffffffffffffffff
       r15 = 0x00007fff7122e420  libsystem_c.dylib`__stack_chk_guard
       rip = 0x00000001031fd9d8  externmod_0.dylib`stacklet_switch + 24
    rflags = 0x0000000000010206
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

(lldb) thread backtrace
* thread #1: tid = 0x782cc, 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1f)
  * frame #0: 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24
    frame #1: 0x000000010310c7ef _ctypes.so`ffi_call_unix64 + 79
    frame #2: 0x000000010310d00b _ctypes.so`ffi_call + 815
    frame #3: 0x00000001031085a3 _ctypes.so`_ctypes_callproc + 643
    frame #4: 0x0000000103102aee _ctypes.so`PyCFuncPtr_call + 1092
    frame #5: 0x000000010000f0ea Python`PyObject_Call + 99
    frame #6: 0x000000010008b97b Python`PyEval_EvalFrameEx + 10701
    frame #7: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409
    frame #8: 0x000000010008f59d Python`fast_function + 117
    frame #9: 0x000000010008c400 Python`PyEval_EvalFrameEx + 13394
    frame #10: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409
    frame #11: 0x000000010002d1ae Python`function_call + 350
    frame #12: 0x000000010000f0ea Python`PyObject_Call + 99
    frame #13: 0x000000010008b97b Python`PyEval_EvalFrameEx + 10701
    frame #14: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409
    frame #15: 0x000000010002d1ae Python`function_call + 350
    frame #16: 0x000000010000f0ea Python`PyObject_Call + 99
    frame #17: 0x0000000100019ed7 Python`instancemethod_call + 174
    frame #18: 0x000000010000f0ea Python`PyObject_Call + 99
    frame #19: 0x000000010005580f Python`slot_tp_call + 61
    frame #20: 0x000000010000f0ea Python`PyObject_Call + 99
    (...)

``` 

I'm not familiar with the codebase but I did some digging, here's what I found out so far (starting from the newest frame):

*  ``stacklet_switch`` is called with ``target == 0xffffffffffffffff`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856cb/rpython/translator/c/src/stacklet/stacklet.c?at=default#cl-299)
* Opaque pointer with that value comes from /in my case, I imagine it can vary/ ``StackletGcRootFinder .switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856cb/rpython/rlib/_stacklet_n_a.py?at=default#cl-18)
* That's passed there by ``StackletThread.switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856cb/rpython/rlib/rstacklet.py?at=default#cl-37)
* Passed there by ``W_Continulet.switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856cb/pypy/module/_continuation/interp_continuation.py?at=default#cl-84) and this is in turn because ``w_to`` contains ``<* <C object None (opaque) at 0xffffffffffffffff>>``


For all intents and purposes release build debug session looks the same, the only notable exception is with the release version ``switch`` is called with target pointer equal to 0x0000000000000000 rather than 0xffffffffffffffff.



From issues-reply at bitbucket.org  Sun Feb 15 19:39:21 2015
From: issues-reply at bitbucket.org (Alex Gaynor)
Date: Sun, 15 Feb 2015 18:39:21 -0000
Subject: [pypy-issue] Issue #1985: PyPy default doesn't compile on OS X
	(pypy/pypy)
Message-ID: <20150215183921.6367.36811@app01.ash-private.bitbucket.org>

New issue 1985: PyPy default doesn't compile on OS X
https://bitbucket.org/pypy/pypy/issue/1985/pypy-default-doesnt-compile-on-os-x

Alex Gaynor:

This is because the OpenSSL included, 0.9.8, does not define `SSL_OP_NO_COMPRESSION`. PyPy should expose this symbol only if it's defined.



From issues-reply at bitbucket.org  Thu Feb 19 16:55:43 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Thu, 19 Feb 2015 15:55:43 -0000
Subject: [pypy-issue] Issue #1986: More improvements for pyrepl (pypy/pypy)
Message-ID: <20150219155543.16017.40401@app08.ash-private.bitbucket.org>

New issue 1986: More improvements for pyrepl
https://bitbucket.org/pypy/pypy/issue/1986/more-improvements-for-pyrepl

Armin Rigo:

A follow-up for issue #1978, based on feedback at http://bugs.python.org/issue23441. Improve the pyrepl prompt of PyPy by using the following two simple behaviors that are common in text editors:

* "backspace" should dedent by removing sometimes more than 1 space at once

* "enter" should automatically indent the new line as much as the previous one



From issues-reply at bitbucket.org  Thu Feb 19 21:09:17 2015
From: issues-reply at bitbucket.org (=?utf-8?q?Jakub_G=C5=82azik?=)
Date: Thu, 19 Feb 2015 20:09:17 -0000
Subject: [pypy-issue] Issue #1987: Performance degradation on PyPy 2.5.0 vs
 2.4.0 (pypy/pypy)
Message-ID: <20150219200917.28012.86928@app11.ash-private.bitbucket.org>

New issue 1987: Performance degradation on PyPy 2.5.0 vs 2.4.0
https://bitbucket.org/pypy/pypy/issue/1987/performance-degradation-on-pypy-250-vs-240

Jakub G?azik:

We are observing around 10% higher CPU usage on PyPy 2.5 vs 2.4

The workload is a HTTP loadbalancer process serving around 700 API requests per second.

![Zrzut ekranu 2015-02-19 o 21.01.38.png](https://bitbucket.org/repo/R7AbB/images/2512960297-Zrzut%20ekranu%202015-02-19%20o%2021.01.38.png)

The graph presents three instances of a loadbalancer, each participating in a round robin fasion (behind AWS ELB). The top one is running PyPy 2.5, bottom two are on PyPy 2.4.
Sorry for lack of real legend in this graph.

The code that is being run: https://github.com/futuresimple/mantrid





From issues-reply at bitbucket.org  Sun Feb 22 12:36:21 2015
From: issues-reply at bitbucket.org (Christoph Reiter)
Date: Sun, 22 Feb 2015 11:36:21 -0000
Subject: [pypy-issue] Issue #1988: pypy3: large read will make future
 os.system calls fail (pypy/pypy)
Message-ID: <20150222113621.24874.89157@app09.ash-private.bitbucket.org>

New issue 1988: pypy3: large read will make future os.system calls fail
https://bitbucket.org/pypy/pypy/issue/1988/pypy3-large-read-will-make-future-ossystem

Christoph Reiter:

```
import os
open("/dev/null", "rb").read(4294967295)
print(os.system("true"))
```

prints -1 instead of 0



From issues-reply at bitbucket.org  Mon Feb 23 10:59:31 2015
From: issues-reply at bitbucket.org (mike fc)
Date: Mon, 23 Feb 2015 09:59:31 -0000
Subject: [pypy-issue] Issue #1989: array.array creation 5x slower than
	CPython (pypy/pypy)
Message-ID: <20150223095931.11339.80129@app10.ash-private.bitbucket.org>

New issue 1989: array.array creation 5x slower than CPython
https://bitbucket.org/pypy/pypy/issue/1989/arrayarray-creation-5x-slower-than-cpython

mike fc:

Creating array.array objects from a buffer seems 5x slower than CPython.

* pypy2 = 3.44s
* pypy3 = 3.42s
* CPython3.4.2 = 0.66
* CPython2.7.9 = 0.69

Using recent nightly for pypy2 and latest release for pypy3 on OSX.
```
#!python

#!/usr/bin/env python
from __future__ import print_function
from datetime import datetime
import array

buf = b"hello there" * 100000
print(len(buf))

start = datetime.now()
for i in range(10000):
    p = array.array('B', buf)
delta = datetime.now() - start
print("T:", delta)
```




From issues-reply at bitbucket.org  Mon Feb 23 19:15:37 2015
From: issues-reply at bitbucket.org (Carl Friedrich Bolz)
Date: Mon, 23 Feb 2015 18:15:37 -0000
Subject: [pypy-issue] Issue #1990: patch_jump_for_descr assertion failure
	(pypy/pypy)
Message-ID: <20150223181537.24670.57382@app08.ash-private.bitbucket.org>

New issue 1990: patch_jump_for_descr assertion failure
https://bitbucket.org/pypy/pypy/issue/1990/patch_jump_for_descr-assertion-failure

Carl Friedrich Bolz:

Assertion failure in ``patch_jump_for_descr``:


```
RPython traceback:
  File "rpython_jit_metainterp_compile.c", line 17761, in send_bridge_to_backend
  File "rpython_jit_backend_x86_assembler.c", line 62107, in Assembler386_assemble_bridge
  File "rpython_jit_backend_x86_assembler.c", line 62778, in Assembler386_patch_jump_for_descr
Fatal RPython error: AssertionError
```

It's this assert:


```
#!python

    def patch_jump_for_descr(self, faildescr, adr_new_target):
        adr_jump_offset = faildescr.adr_jump_offset
        assert adr_jump_offset != 0
```

Way to reproduce:
* clone and build pycket https://github.com/samth/pycket
* clone the benchmarks: https://github.com/krono/pycket-bench/
* go to pycket-bench/Crossbenchmarks and run pycket-c racket/dynamic-nothing.rkt




From issues-reply at bitbucket.org  Tue Feb 24 23:56:34 2015
From: issues-reply at bitbucket.org (morphello)
Date: Tue, 24 Feb 2015 22:56:34 -0000
Subject: [pypy-issue] Issue #1991: reload (sys) error (pypy/pypy)
Message-ID: <20150224225634.29247.31249@app08.ash-private.bitbucket.org>

New issue 1991: reload (sys) error
https://bitbucket.org/pypy/pypy/issue/1991/reload-sys-error

morphello:

Hi, please excuse my lack of knowledge. I've been running SickBeard through PyPy 2.5.0 on Windows 8.1 x64, and it runs flawlessly sans for its ability to restart. Thanks to a helpful member of the forum who is more knowledgeable than I, we've identified that PyPy isn't returning the executable on a reload.

Here is a link to the thread where we discuss the issue.

https://sickrage.tv/forums/forum/help-support/general-support/18501-sickrage-can-t-restart-itself-under-pypy-2-5-0-windows

The program attempts to restart itself, and instead of calling pypy.exe calls py.py.

This works correctly under python 2.7.9

PyPy 2.5.0:


```
#!python

pypy.exe
Python 2.7.8 (10f1b29a2bd2, Feb 03 2015, 00:56:13)
[PyPy 2.5.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.executable
'c:\\Pypy25\\pypy.exe'
>>>> reload(sys)
<module 'sys' (built-in)>
>>>> sys.executable
'py.py'
```
Python 2.7.9:


```
#!python

python.exe
Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.executable
'c:\\Python27\\python.exe'
>>> reload(sys)
<module 'sys' (built-in)>
>>> sys.executable
'c:\\Python27\\python.exe'
```

Thank you in advance.



From issues-reply at bitbucket.org  Wed Feb 25 18:51:21 2015
From: issues-reply at bitbucket.org (Matthias Zimmermann)
Date: Wed, 25 Feb 2015 17:51:21 -0000
Subject: [pypy-issue] Issue #1992: sandboxing for external function 'time'
	(pypy/pypy)
Message-ID: <20150225175121.30723.97559@app05.ash-private.bitbucket.org>

New issue 1992: sandboxing for external function 'time'
https://bitbucket.org/pypy/pypy/issue/1992/sandboxing-for-external-function-time

Matthias Zimmermann:

I compiled PyPy 2.5 with 
```
#!bash

pypy ../../rpython/bin/rpython -O2 --sandbox targetpypystandalone --withmod-time
```
When I run the sandbox and want to **import time** the error message "*Not Implemented: sandboxing for external function 'time'*" occurs.

In PyPy 2.3.1 import time works.



From issues-reply at bitbucket.org  Sat Feb 28 11:59:22 2015
From: issues-reply at bitbucket.org (mike fc)
Date: Sat, 28 Feb 2015 10:59:22 -0000
Subject: [pypy-issue] Issue #1993: Slow string-to-byte encoding (pypy/pypy)
Message-ID: <20150228105922.16274.84369@app09.ash-private.bitbucket.org>

New issue 1993: Slow string-to-byte encoding
https://bitbucket.org/pypy/pypy/issue/1993/slow-string-to-byte-encoding

mike fc:

Depending on versions being compared, pypy is 20x slower than CPython at string to byte encoding.
Using a pypy2 recent nightly and latest release pypy3 on OSX.


```
#!python

python      bytearray     buf.encode
python2.7.9    6.55          6.15
python3.4.2    0.55          0.19
pypy2         12.65         12.38
pypy3         10.7           5.99    
```



```
#!python
#!/usr/bin/env python
from __future__ import print_function
import time

buf = "hello there" * 220000
print(len(buf))

start = time.time()
for i in range(1000):
    p = bytearray(buf, 'ascii')
delta = time.time() - start
print("bytearray:", delta)

start = time.time()
for i in range(1000):
    p = buf.encode('ascii')
delta = time.time() - start
print("buf.encode:", delta)
```