From issues-reply at bitbucket.org  Sat Nov  1 01:14:48 2014
From: issues-reply at bitbucket.org (Corey Farwell)
Date: Sat, 01 Nov 2014 00:14:48 -0000
Subject: [pypy-issue] Issue #1915: SSL getpeercert(binary_form=True) not
 returning binary (pypy/pypy)
Message-ID: <20141101001448.6571.42003@app11.ash-private.bitbucket.org>

New issue 1915: SSL getpeercert(binary_form=True) not returning binary
https://bitbucket.org/pypy/pypy/issue/1915/ssl-getpeercert-binary_form-true-not

Corey Farwell:

Disclaimer: I don't know much about sockets/SSL, so I don't really know what I'm doing

Running into a build issue [here](https://travis-ci.org/shazow/urllib3/builds/39609537) with [urllib3](https://github.com/shazow/urllib3)

As an example, running

```
nosetests -s test.with_dummyserver.test_https:TestHTTPS.test_verify_none_and_good_fingerprint
```

With Python 3.2.5 (cpython), the test passes

With 

```
Python 3.2.5 (b2091e973da69152b3f928bfaabd5d2347e6df46, Oct 22 2014, 02:19:03)
[PyPy 2.4.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)]
```

the test fails. [This line in particular](https://github.com/shazow/urllib3/blob/master/urllib3/connection.py#L240) is problematic. `self.sock.getpeercert(binary_form=True)` is returning a string even though it shouldn't





From issues-reply at bitbucket.org  Sat Nov  1 12:29:04 2014
From: issues-reply at bitbucket.org (Stian Andreassen)
Date: Sat, 01 Nov 2014 11:29:04 -0000
Subject: [pypy-issue] Issue #1916: py3.3 - RuntimeError: Unrecognized error
 from liblzma: 7 (pypy/pypy)
Message-ID: <20141101112904.21036.22067@app08.ash-private.bitbucket.org>

New issue 1916: py3.3 - RuntimeError: Unrecognized error from liblzma: 7
https://bitbucket.org/pypy/pypy/issue/1916/py33-runtimeerror-unrecognized-error-from

Stian Andreassen:

Trying to run bootstrap in py3.3 (head). This runs fine in pypy default. But gives this under py3.3


```
#!python

pypy3.3 bootstrap.py
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.49.tar.gz
Extracting in /tmp/tmppf6ir5
Traceback (most recent call last):
  File "bootstrap.py", line 154, in <module>
    raise ImportError
ImportError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "bootstrap.py", line 166, in <module>
    ez['use_setuptools'](**setup_args)
  File "<string>", line 162, in use_setuptools
  File "<string>", line 132, in _do_download
  File "<string>", line 104, in _build_egg
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 1573, in open
    return func(name, "r", fileobj, **kwargs)
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 1702, in xzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 1621, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 1495, in __init__
    self.firstmember = self.next()
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 2275, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/home/stian/pypy/lib-python/3/tarfile.py", line 1108, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/home/stian/pypy/lib-python/3/lzma.py", line 293, in read
    return self._read_block(size)
  File "/home/stian/pypy/lib-python/3/lzma.py", line 256, in _read_block
    while n > 0 and self._fill_buffer():
  File "/home/stian/pypy/lib-python/3/lzma.py", line 238, in _fill_buffer
    self._buffer = self._decompressor.decompress(rawblock)
RuntimeError: Unrecognized error from liblzma: 7

...

Because it works fine with non-lzma implementation, I'd say it's a bug.



From issues-reply at bitbucket.org  Sat Nov  1 19:32:09 2014
From: issues-reply at bitbucket.org (Konstantin Lopuhin)
Date: Sat, 01 Nov 2014 18:32:09 -0000
Subject: [pypy-issue] Issue #1917: PyPy STM segfault (pypy/pypy)
Message-ID: <20141101183209.11758.85065@app08.ash-private.bitbucket.org>

New issue 1917: PyPy STM segfault
https://bitbucket.org/pypy/pypy/issue/1917/pypy-stm-segfault

Konstantin Lopuhin:

How to reproduce:

```
#!bash

hg clone ssh://hg at bitbucket.org/kostialopuhin/tornado-stm-bench
cd tornado-stm-bench
hg up a038bf99de71
virtualenv env -p pypy-c-r74011-stm-jit
source env/bin/activate
pip install -r requirements.txt
./astar.py 4
```
This will start a server on localhost:8888.
And then to get a crash, run in another terminal

```
./bench_astar.py
```

astar.py is a benchmark that simulates a simple multiplayer game, running under tornado with stm enabled, where players modify and move around a common map.

I have an Amazon AMI with this already set up, or I can just start it at any time.



From issues-reply at bitbucket.org  Sat Nov  1 19:37:38 2014
From: issues-reply at bitbucket.org (Konstantin Lopuhin)
Date: Sat, 01 Nov 2014 18:37:38 -0000
Subject: [pypy-issue] Issue #1918: Invalid entries in PyPy STM log
	(pypy/pypy)
Message-ID: <20141101183738.19652.58128@app13.ash-private.bitbucket.org>

New issue 1918: Invalid entries in PyPy STM log
https://bitbucket.org/pypy/pypy/issue/1918/invalid-entries-in-pypy-stm-log

Konstantin Lopuhin:

How to reproduce (similar setup to #1917):

```
hg clone ssh://hg at bitbucket.org/kostialopuhin/tornado-stm-bench
cd tornado-stm-bench
hg up a038bf99de71
virtualenv env -p pypy-c-r74011-stm-jit
source env/bin/activate
pip install -r requirements.txt
PYPYSTM=stm.log ./primes.py 4
```

This will start a server on localhost:8888, then in another terminal (assuming you have siege installed):

```
./bench_primes.sh 10
```

And then, when trying to read stm.log

```
print_stm_log.py stm.log
$ print_stm_log.py stm.log
Traceback (most recent call last):
  File "app_main.py", line 75, in run_toplevel
  File "/usr/local/bin/print_stm_log.py", line 194, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/usr/local/bin/print_stm_log.py", line 190, in main
    dump(parse_log(argv[0]))
  File "/usr/local/bin/print_stm_log.py", line 69, in parse_log
    raise ValueError("the file %r appears corrupted")
ValueError: the file %r appears corrupted
```

Although only a tiny fraction of log entries are corrupted.



From issues-reply at bitbucket.org  Sat Nov  1 20:13:21 2014
From: issues-reply at bitbucket.org (Philip Jenvey)
Date: Sat, 01 Nov 2014 19:13:21 -0000
Subject: [pypy-issue] Issue #1919: Problematic strings returned from os.read
	(pypy/pypy)
Message-ID: <20141101191321.28567.81833@app09.ash-private.bitbucket.org>

New issue 1919: Problematic strings returned from os.read
https://bitbucket.org/pypy/pypy/issue/1919/problematic-strings-returned-from-osread

Philip Jenvey:

Here's a nasty one. The attached script fails on recent pypys (result in d should be True).

tannit can reproduce it w/ a recent pypy2 no-jit build:

http://buildbot.pypy.org/nightly/trunk/pypy-c-nojit-74318-ffce4c795283-linux64.tar.bz2

(it may take no more than a few tries before it prints a bogus result of "False\nTrue")

AFAICT the rpython level string's hash code seems bogus. The bad string's from an os.read w/ count 1 specified resulting in a string of length 1.

I haven't tracked down to when this began happening but I recall it beginning to exhibit itself on PyPy3 at least a couple weeks ago in the most unrelated way (backspace in pyrepl began raising an exception). Doesn't happen in 2.4.0 release (pypy2 & pypy3)

I suspect the pinning/zeroing changes aren't clearing out the initial hash code but that's just a guess, so far I can't see how that would even happen



From issues-reply at bitbucket.org  Mon Nov  3 03:46:12 2014
From: issues-reply at bitbucket.org (Andrew Dunham)
Date: Mon, 03 Nov 2014 02:46:12 -0000
Subject: [pypy-issue] Issue #1920: grp.getgrnam() incorrectly throws a
 TypeError when given a unicode string (pypy/pypy)
Message-ID: <20141103024612.7362.35100@app06.ash-private.bitbucket.org>

New issue 1920: grp.getgrnam() incorrectly throws a TypeError when given a unicode string
https://bitbucket.org/pypy/pypy/issue/1920/grpgetgrnam-incorrectly-throws-a-typeerror

Andrew Dunham:

As the title says :-)  I tried this on CPython 2.7.8, and the behaviour is not present:


```
Python 2.7.8 (default, Sep 24 2014, 18:26:21) 
[GCC 4.9.1 20140903 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam('root')
grp.struct_group(gr_name='root', gr_passwd='x', gr_gid=0, gr_mem=['root'])
>>> grp.getgrnam(u'root')
grp.struct_group(gr_name='root', gr_passwd='x', gr_gid=0, gr_mem=['root'])
```

Behaviour on PyPy 2.4.0:

```
Python 2.7.8 (c6ad44ecf5d8, Oct 16 2014, 02:14:27)
[PyPy 2.4.0 with GCC 4.9.1 20140903 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam('root')
(gr_name='root', gr_passwd='x', gr_gid=0, gr_mem=['root'])
>>> grp.getgrnam(u'root')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/pypy/lib_pypy/grp.py", line 70, in getgrnam
    raise TypeError("expected string")
TypeError: expected string
```

Among other things, this breaks using [Ansible](http://www.ansible.com/home) with PyPy.



From issues-reply at bitbucket.org  Tue Nov  4 11:42:31 2014
From: issues-reply at bitbucket.org (Carl Friedrich Bolz)
Date: Tue, 04 Nov 2014 10:42:31 -0000
Subject: [pypy-issue] Issue #1921: Problematic introduction of promote in
 presence of int switches (pypy/pypy)
Message-ID: <20141104104231.1808.20638@app11.ash-private.bitbucket.org>

New issue 1921: Problematic introduction of promote in presence of int switches
https://bitbucket.org/pypy/pypy/issue/1921/problematic-introduction-of-promote-in

Carl Friedrich Bolz:

The following code lead to very confusing behaviour on Pycket recently:

```
#!python

from rpython.rtyper.raisingops import int_floordiv_ovf

...
        if y == 0:
            raise SchemeException("zero_divisor")
        try:
            res = int_floordiv_ovf(x, y) # misnomer, should be int_truncdiv or so
        except OverflowError:
            return self.arith_quotient(values.W_Bignum(rbigint.fromint(other.value)))

```

(we were intentionally using int_floordiv_ovf, to get the C integer division behaviour). What happened was that int_floordiv_ovf was inlined. That function starts with ``if y == -1: ...``. The two conditions on y were turned into a switch, which lead to the JIT introducing a promote just before it. This is clearly nonsense.

How do we solve this? do the if-to-switch conversion before inlining? require an explicit promote before switches where that is safe (probably breaks some existing code)?



From issues-reply at bitbucket.org  Sat Nov  8 13:17:54 2014
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 08 Nov 2014 12:17:54 -0000
Subject: [pypy-issue] Issue #1922: Future-proofing virtualenv (pypy/pypy)
Message-ID: <20141108121754.2520.78117@app08.ash-private.bitbucket.org>

New issue 1922: Future-proofing virtualenv
https://bitbucket.org/pypy/pypy/issue/1922/future-proofing-virtualenv

Armin Rigo:

Virtualenv is broken again now that we generate a separate `libpypy-c.so` file, because it doesn't copy this separate file.  Looking at the source code of virtualenv, I notice too that the list of `.dll` files to copy on Windows is hard-coded.  I would instead try to find a more future-proof way to solve it.

One such way would be to write extra logic in the `pypy` or `pypy.exe` executable: it would not be linked with `libpypy-c.so`, but locate it dynamically, if possible from the original path.  This original path happens to be written to `../lib-python/2.7/orig-prefix.txt` by virtualenv.  Alternatively, it could notice that `libpypy-c.so` is not found in the current directory, and copy it (or hard-link it) the first time from the path written in `orig-prefix.txt`.  The same can be done on Windows for the other DLLs it depends on.

Does it sound like a good idea, or just nonsense?



From issues-reply at bitbucket.org  Tue Nov 11 12:54:21 2014
From: issues-reply at bitbucket.org (Stian Andreassen)
Date: Tue, 11 Nov 2014 11:54:21 -0000
Subject: [pypy-issue] Issue #1923: py3.3 branch - timeit fails,
 time.perf_counter missing. (pypy/pypy)
Message-ID: <20141111115421.5208.21814@app01.ash-private.bitbucket.org>

New issue 1923: py3.3 branch - timeit fails, time.perf_counter missing.
https://bitbucket.org/pypy/pypy/issue/1923/py33-branch-timeit-fails-timeperf_counter

Stian Andreassen:


```
#!python

pypy3.3 -m timeit
Traceback (most recent call last):
  File "/home/stian/pypy/lib-python/3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/stian/pypy/lib-python/3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/stian/pypy/lib-python/3/timeit.py", line 70, in <module>
    default_timer = time.perf_counter
AttributeError: 'module' object has no attribute 'perf_counter'

```
Work in latest released pypy and pypy3, but broken in latest build of py3.3. This is due to time.perf_counter missing.



From issues-reply at bitbucket.org  Tue Nov 11 19:03:29 2014
From: issues-reply at bitbucket.org (Vladimir Smirnov)
Date: Tue, 11 Nov 2014 18:03:29 -0000
Subject: [pypy-issue] Issue #1924: Sometimes CFFI fails to initialize
 structure properly, when running under pypy2.7-2.4.0 (pypy/pypy)
Message-ID: <20141111180329.18149.10070@app04.ash-private.bitbucket.org>

New issue 1924: Sometimes CFFI fails to initialize structure properly, when running under pypy2.7-2.4.0
https://bitbucket.org/pypy/pypy/issue/1924/sometimes-cffi-fails-to-initialize

Vladimir Smirnov:

With a lot of help from LarstiQ from #pypy I've created sort of minimal test case for this issue.

Cause this code snippet works ok with pyhon 2.7, it seems to be something like a regression.

In attachment you'll find a code that works on python2.7 but fails on pypy2.7-2.4.0 (from ubuntu's ppa, if it matters).

Issue in CFFI bugzilla: https://bitbucket.org/cffi/cffi/issue/167/ffinew-with-initialization-sometimes-do
More information about use case in cairo-cffi bugzilla: https://github.com/SimonSapin/cairocffi/issues/46



From issues-reply at bitbucket.org  Wed Nov 12 16:08:10 2014
From: issues-reply at bitbucket.org (Yichao Yu)
Date: Wed, 12 Nov 2014 15:08:10 -0000
Subject: [pypy-issue] Issue #1925: VERY slow string concatenation (pypy/pypy)
Message-ID: <20141112150810.3868.33988@app13.ash-private.bitbucket.org>

New issue 1925: VERY slow string concatenation
https://bitbucket.org/pypy/pypy/issue/1925/very-slow-string-concatenation

Yichao Yu:

The following script (admittedly not the best way to build long string) runs ~30-100 times slower on pypy than cpython2/3.

```python
a = ''
for i in range(10000):
    a += 'a'
```

PyPy version: a772923edb32 (latest as of last week) on my laptop.

```
% python -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'"
1000 loops, best of 3: 1.07 msec per loop
```

```
% python2 -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'"
1000 loops, best of 3: 678 usec per loop
```

```
% pypy -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'"
10 loops, best of 3: 29.6 msec per loop
```

PyPy 2.4.0 on a linode vps is even worse

```
% python -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'" 
1000 loops, best of 3: 1.55 msec per loop
```

```
% python2 -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'"
1000 loops, best of 3: 978 usec per loop
```

```
% pypy -m timeit -s 'a = ""' -- "for i in range(10000): a += 'a'"
10 loops, best of 3: 94.6 msec per loop
```

The time might not be accurate since the script does not run for very long (~1s) but the significant slow down remains when repeating this multiple time and with more iteration in the loop.




From issues-reply at bitbucket.org  Fri Nov 14 07:56:14 2014
From: issues-reply at bitbucket.org (Konstantin Lopuhin)
Date: Fri, 14 Nov 2014 06:56:14 -0000
Subject: [pypy-issue] Issue #1926: PyPy STM segfault with short transactions
	(pypy/pypy)
Message-ID: <20141114065614.6332.56021@app06.ash-private.bitbucket.org>

New issue 1926: PyPy STM segfault with short transactions
https://bitbucket.org/pypy/pypy/issue/1926/pypy-stm-segfault-with-short-transactions

Konstantin Lopuhin:

Steps to reproduce are the same as in #1918:

```
hg clone ssh://hg at bitbucket.org/kostialopuhin/tornado-stm-bench
cd tornado-stm-bench
hg up a038bf99de71
virtualenv env -p pypy-c-r74378-74379-stm-jit
source env/bin/activate
pip install -r requirements.txt
./primes.py 4
```
the only difference is that now to run benchmark do

```
siege -c 20 -t 20s http://localhost:8888/500
```

the difference is that here transactions are much shorter (primes up to 500 instead of 10000). This is not 100% reliable way to get a segfault, but I get it more often than not.

I can try with a newer build



From issues-reply at bitbucket.org  Mon Nov 17 17:30:22 2014
From: issues-reply at bitbucket.org (vikko)
Date: Mon, 17 Nov 2014 16:30:22 -0000
Subject: [pypy-issue] Issue #1927: string comparison failing in pypy in
 if-statement with is keyword (pypy/pypy)
Message-ID: <20141117163022.21835.64160@app13.ash-private.bitbucket.org>

New issue 1927: string comparison failing in pypy in if-statement with is keyword
https://bitbucket.org/pypy/pypy/issue/1927/string-comparison-failing-in-pypy-in-if

vikko:

following code outputs "somethings wrong" with pypy, "it's all good is outputted with python 2.7"


```
#!python

def testf(param):
    if param is "exponential":
        print "it's all good"
    else:
        print "somethings wrong"

testf("exponential")

```

Version:
Python 2.7.6 (32f35069a16d819b58c1b6efb17c44e3e53397b2, Nov 03 2014, 13:35:47)
[PyPy 2.3.1]




From issues-reply at bitbucket.org  Thu Nov 20 06:36:51 2014
From: issues-reply at bitbucket.org (Graham Dumpleton)
Date: Thu, 20 Nov 2014 05:36:51 -0000
Subject: [pypy-issue] Issue #1928: Incorrect name lookup occurring in class
 defined inside of a function. (pypy/pypy)
Message-ID: <20141120053651.11680.40271@app13.ash-private.bitbucket.org>

New issue 1928: Incorrect name lookup occurring in class defined inside of a function.
https://bitbucket.org/pypy/pypy/issue/1928/incorrect-name-lookup-occurring-in-class

Graham Dumpleton:

Sorry, but I can't really supply a direct runnable test case that is going to trigger the bug, as the problem only manifests at some point after the JIT kicks in in some way. As such, it only triggers when run as part of a larger test suite we run under tox. At least that it relates to the JIT kicking in is all I can think of as to why when run in isolation there is no problem.

Anyway, the test program is shown below. I can't pair it back any further as when I start taking more out, even under our larger test suite it starts working okay, so is the minimal I can get such that still creates the problem. It needs pytest and wrapt to be installed.


```
#!python

import pytest
from wrapt import transient_function_wrapper

def override_application_name(name):
    class Application(object):
        @property
        def name(self):
            print('locals()', locals())
            print('type(name)', type(name))
            print('repr(name)', repr(name))
            print('type(Application.name)', type(Application.name))
            print('repr(Application.name)', repr(Application.name))
            return name

    @transient_function_wrapper(__name__, 'function_1')
    def _override_application_name(wrapped, instance, args, kwargs):
        def _bind_params(application, *args, **kwargs):
            return application, args, kwargs

        application, _args, _kwargs = _bind_params(*args, **kwargs)

        application = Application()

        return wrapped(application, *_args, **_kwargs)

    return _override_application_name

def function_1(obj):
    return obj

class Application(object):
    name = 'yyy'

@pytest.mark.parametrize(('a',), [(1,)])
def test_bug_many_3(a):
    @override_application_name('xxx')
    def test_bug():
        obj = function_1(Application())
        print('type(obj)', type(obj))
        print('obj.name', obj.name)
        assert isinstance(obj.name, str)
    test_bug()
```

So when run standalone using pypy 2.4.0, 2.2.1 and 1.9.0 this test works fine. But when run as part of a larger test suite under tox it fails.

The output we get is:

```
test_pypy_bug.py::test_bug_many_3[1] FAILED

======================================= FAILURES =======================================
__________________________________ test_bug_many_3[1] __________________________________

a = 1

    @pytest.mark.parametrize(('a',), [(1,)])
    def test_bug_many_3(a):
        @override_application_name('xxx')
        def test_bug():
            obj = function_1(Application())
            print('type(obj)', type(obj))
            print('obj.name', obj.name)
            assert isinstance(obj.name, str)
>       test_bug()

test_pypy_bug.py:42:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.tox/pypy-without-extensions/site-packages/wrapt/wrappers.py:517: in __call__
    args, kwargs)
.tox/pypy-without-extensions/site-packages/wrapt/wrappers.py:800: in _execute
    return wrapped(*args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    @override_application_name('xxx')
    def test_bug():
        obj = function_1(Application())
        print('type(obj)', type(obj))
        print('obj.name', obj.name)
>       assert isinstance(obj.name, str)
E       assert isinstance(<property object at 0x000000010a232410>, str)
E        +  where <property object at 0x000000010a232410> = <test_pypy_bug.Application object at 0x000000010a207de0>.name

test_pypy_bug.py:41: AssertionError
--------------------------------- Captured stdout call ---------------------------------
('type(obj)', <class 'test_pypy_bug.Application'>)
('locals()', {'Application': <class 'test_pypy_bug.Application'>, 'self': <test_pypy_bug.Application object at 0x000000010a207de0>, 'name': <property object at 0x000000010a232410>})
('type(name)', <type 'property'>)
('repr(name)', '<property object at 0x000000010a232410>')
('type(Application.name)', <type 'property'>)
('repr(Application.name)', '<property object at 0x000000010a232410>')
('obj.name', <property object at 0x000000010a232410>)
('locals()', {'Application': <class 'test_pypy_bug.Application'>, 'self': <test_pypy_bug.Application object at 0x000000010a207de0>, 'name': <property object at 0x000000010a232410>})
('type(name)', <type 'property'>)
('repr(name)', '<property object at 0x000000010a232410>')
('type(Application.name)', <type 'property'>)
('repr(Application.name)', '<property object at 0x000000010a232410>')
============================== 1 failed in 19.40 seconds ===============================
ERROR: InvocationError: '/Users/graham/Work/python_agent/tests/agent_features/.tox/pypy-without-extensions/bin/py.test -v test_pypy_bug.py'
_______________________________________ summary ________________________________________
ERROR:   pypy-without-extensions: commands failed
```

For this code, when looking up the 'name' attribute from inside of the 'name' property method of the Application class which is nested inside of a function, it should be finding the 'name' argument of override_application_name(). 

As I said, this works fine as standalone test, but in larger test suite, the behaviour changes, and rather than return the 'name' argument of the outer function, it is using the 'name' property method. This is regardless of the fact that 'self' was not used and so it should not have been doing that.

I have added debug in so even if you can't manage to get it to trigger by filling the test file with lots of other code which is run first and so enables the JIT, that you can see that the lookup is wrong and so work from that.

The obvious workaround for this is not to use 'name' as the name of the outer function argument at the same time as calling the property method 'name'. So changing the outer argument to 'app_name' and making the return statement use that as well, then all works fine. Issue is only when the names for argument and property method are the same.



From issues-reply at bitbucket.org  Thu Nov 20 19:38:53 2014
From: issues-reply at bitbucket.org (Christopher Johnson)
Date: Thu, 20 Nov 2014 18:38:53 -0000
Subject: [pypy-issue] Issue #1929: tkinter broken for threaded Python on
 both pypy2 and pypy3 (pypy/pypy)
Message-ID: <20141120183853.4176.86085@app10.ash-private.bitbucket.org>

New issue 1929: tkinter broken for threaded Python on both pypy2 and pypy3
https://bitbucket.org/pypy/pypy/issue/1929/tkinter-broken-for-threaded-python-on-both

Christopher Johnson:

I have a very large multi-threaded Python 3 and Tkinter project that I want to move to PyPy 3.

While moving my code over, I discovered that PyPy is broken in supporting threads.

So I made a small test program that demonstrates the bug. Here is the output displayed when running the program:

$ pypy3 tkintertest.py
Exception in thread secondary:
Traceback (most recent call last):
  File "/Users/christopher/bin/pypy3-2.4.0-osx64/lib-python/3/threading.py", line 740, in _bootstrap_inner
    self.run()
  File "/Users/christopher/bin/pypy3-2.4.0-osx64/lib-python/3/threading.py", line 693, in run
    self._target(*self._args, **self._kwargs)
  File "tkintertest.py", line 11, in secondary
    canvas.create_text(100, 50, text="Secondary thread")
  File "/Users/christopher/bin/pypy3-2.4.0-osx64/lib-python/3/tkinter/__init__.py", line 2256, in create_text
    return self._create('text', args, kw)
  File "/Users/christopher/bin/pypy3-2.4.0-osx64/lib-python/3/tkinter/__init__.py", line 2232, in _create
    *(args + self._options(cnf, kw))))
  File "/Users/christopher/bin/pypy3-2.4.0-osx64/lib_pypy/_tkinter/app.py", line 286, in call
    raise NotImplementedError("Call from another thread")
NotImplementedError: Call from another thread

I cannot run my project on PyPy unless this gets fixed, and I cannot code around it, so I wish you all luck in working on this issue! 

By the way, I tried running my test on PyPy 2 (with the Tkinter module name changed to capital T) and it failed with the same identical output. So PyPy 2 also need to be fixed.

I am running this on OS X 10.9.5 Mavericks. With the following displayed when I run PyPy interactively:
Python 3.2.5 (b2091e973da6, Oct 19 2014, 18:30:58)
[PyPy 2.4.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.51)] on darwin

--Christopher



From issues-reply at bitbucket.org  Thu Nov 20 19:48:56 2014
From: issues-reply at bitbucket.org (Christopher Johnson)
Date: Thu, 20 Nov 2014 18:48:56 -0000
Subject: [pypy-issue] Issue #1930: magic __class__ variable not defined in
 PyPy 3 (pypy/pypy)
Message-ID: <20141120184856.29787.20445@app12.ash-private.bitbucket.org>

New issue 1930: magic __class__ variable not defined in PyPy 3
https://bitbucket.org/pypy/pypy/issue/1930/magic-__class__-variable-not-defined-in

Christopher Johnson:

In Python 3, the magic __class__ variable is supposed to be defined inside methods to refer to the class object where the methods are defined (NOT NECESSARILY the class of self).

PyPy3 does not yet implement this feature, which makes it out of sync with CPython 3.

Here is the output while running my test:

$ python2.7 pypy_class_bug.py
Traceback (most recent call last):
  File "pypy_class_bug.py", line 9, in <module>
    Derived().printBase() # on CPython prints "Base"
  File "pypy_class_bug.py", line 4, in printBase
    print(__class__.__name__)
NameError: global name '__class__' is not defined
$ python3.2 pypy_class_bug.py
Base
$ pypy2 pypy_class_bug.py
Traceback (most recent call last):
  File "app_main.py", line 75, in run_toplevel
  File "pypy_class_bug.py", line 9, in <module>
    Derived().printBase() # on CPython prints "Base"
  File "pypy_class_bug.py", line 4, in printBase
    print(__class__.__name__)
NameError: global name '__class__' is not defined
$ pypy3 pypy_class_bug.py
Traceback (most recent call last):
  File "pypy_class_bug.py", line 9, in <module>
    Derived().printBase() # on CPython prints "Base"
  File "pypy_class_bug.py", line 4, in printBase
    print(__class__.__name__)
NameError: global name '__class__' is not defined




From issues-reply at bitbucket.org  Thu Nov 20 21:57:22 2014
From: issues-reply at bitbucket.org (Philip Nguyen)
Date: Thu, 20 Nov 2014 20:57:22 -0000
Subject: [pypy-issue] Issue #1931: slower factorial compared to CPython
	(pypy/pypy)
Message-ID: <20141120205722.23990.42067@app08.ash-private.bitbucket.org>

New issue 1931: slower factorial compared to CPython
https://bitbucket.org/pypy/pypy/issue/1931/slower-factorial-compared-to-cpython

Philip Nguyen:

The following program runs slower with PyPy than CPython on my computer:


```
#!python

import time

def prod(n):
    p = 1
    for i in range(1, n + 1):
        p *= i
    return p

start = time.time()
prod(100000)
end = time.time()
print "prod: %s" % (end - start)
```

`PyPy 2.3.1` takes **3.5s**, while `CPython 2.7.8` takes **2.8s**. This is `Ubuntu 14.10 64bit` on `Core i7 3667U`.



From issues-reply at bitbucket.org  Fri Nov 21 21:04:48 2014
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Fri, 21 Nov 2014 20:04:48 -0000
Subject: [pypy-issue] Issue #1932: Invalid assembler if libpypy-c.so was
 dlopen()ed (pypy/pypy)
Message-ID: <20141121200448.4182.84993@app14.ash-private.bitbucket.org>

New issue 1932: Invalid assembler if libpypy-c.so was dlopen()ed
https://bitbucket.org/pypy/pypy/issue/1932/invalid-assembler-if-libpypy-cso-was

Armin Rigo:

If libpypy-c.so was loaded with ``dlopen()`` instead of by the dynamic linker when the program starts, then x86/assembler.py will produce wrong code (or crash in an assertion error) in ``threadlocalref_get()``.  This is because the handling of thread-local variables is rather messy on Linux.

One easy workaround is to load your main program with ``LD_PRELOAD=...libpypy-c.so``.  Obviously, it would be a better idea to find a proper fix.



From issues-reply at bitbucket.org  Thu Nov 27 08:02:10 2014
From: issues-reply at bitbucket.org (Andrey Churin)
Date: Thu, 27 Nov 2014 07:02:10 -0000
Subject: [pypy-issue] Issue #1933: BareBoneArrayDefNode.access_expr_varindex,
 incorrect string formatting (pypy/pypy)
Message-ID: <20141127070210.10513.78666@app08.ash-private.bitbucket.org>

New issue 1933: BareBoneArrayDefNode.access_expr_varindex, incorrect string formatting
https://bitbucket.org/pypy/pypy/issue/1933/barebonearraydefnodeaccess_expr_varindex

Andrey Churin:

rpython/translator/c/node.py (line 345 - 347)

```
#!python
class BareBoneArrayDefNode(NodeWithDependencies):
    ...
    def access_expr(self, baseexpr, index):
        return '%s[%d]' % (baseexpr, index)
    access_expr_varindex = access_expr
    ...
```
here only number is allowed, but index can be a string (for access_expr_varindex)



From issues-reply at bitbucket.org  Thu Nov 27 21:49:21 2014
From: issues-reply at bitbucket.org (Gerrat Rickert)
Date: Thu, 27 Nov 2014 20:49:21 -0000
Subject: [pypy-issue] Issue #1934: Different Error message in pypy 2.4 vs
 CPython 2.7.8 when multiplying list by float using '*' (pypy/pypy)
Message-ID: <20141127204921.3539.37349@app08.ash-private.bitbucket.org>

New issue 1934: Different Error message in pypy 2.4 vs CPython 2.7.8 when multiplying list by float using '*'
https://bitbucket.org/pypy/pypy/issue/1934/different-error-message-in-pypy-24-vs

Gerrat Rickert:

The error type is the same, but the message is different.  I'm not sure if pypy is supposed to return the same error message or not, so my apologies for the noise if not.

in CPython 2.7.8:
>>> [3]*(3.0//2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't multiply sequence by non-int of type 'float'
>>>

in pypy 2.4:
>>>> [3]*(3.0//2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'list' and 'float'




From issues-reply at bitbucket.org  Fri Nov 28 20:09:38 2014
From: issues-reply at bitbucket.org (Brett Cannon)
Date: Fri, 28 Nov 2014 19:09:38 -0000
Subject: [pypy-issue] Issue #1935: logilab.common 0.63.1 triggers a fatal
 RPython error of KeyError (pypy/pypy)
Message-ID: <20141128190938.18070.66472@app02.ash-private.bitbucket.org>

New issue 1935: logilab.common 0.63.1 triggers a fatal RPython error of KeyError
https://bitbucket.org/pypy/pypy/issue/1935/logilabcommon-0631-triggers-a-fatal

Brett Cannon:

When trying to byte-compile logilab.common 0.63.1, I keep triggering a fatal RPython error of KeyError: https://travis-ci.org/brettcannon/caniusepython3/jobs/42421116 . Under CPython 3.2 this error doesn't occur.