From tracker at bugs.pypy.org  Thu Apr  4 00:43:39 2013
From: tracker at bugs.pypy.org (Carl Meyer)
Date: Wed, 03 Apr 2013 22:43:39 +0000
Subject: [pypy-issue] [issue1272] user and home install schemes broke in pypy
In-Reply-To: <1348949699.1.0.101888055363.issue1272@bugs.pypy.org>
Message-ID: <1365029019.14.0.514170496981.issue1272@bugs.pypy.org>


Carl Meyer <carl at oddbird.net> added the comment:

Conclusions from discussion on IRC today:

1) In the long term, it would be good for PyPy to emulate CPython layout more
closely and eliminate the special PyPy distutils install scheme.

2) In the short term, because virtualenv already hardcodes the PyPy scheme, this
change would break use of PyPy with existing virtualenv releases.

3) It might be possible to make the scheme transition in future without a hard
break if virtualenv first implements
https://github.com/pypa/virtualenv/issues/416, and versions of virtualenv using
get_python_lib gain wide traction.

In the very short term (for the PyPy 2.0 release), the attached patch at least
fixes the "home" and "user" schemes, without making any changes to the default
use of pypy scheme.

This does not yet fix virtualenv issues 302 and 306 (or pip 625), but it does
fix pip issues 624 and 629.

----------
nosy: +carljm -pjenvey
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1272>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 01:29:02 2013
From: tracker at bugs.pypy.org (Carl Meyer)
Date: Wed, 03 Apr 2013 23:29:02 +0000
Subject: [pypy-issue] [issue1272] user and home install schemes broke in pypy
In-Reply-To: <1348949699.1.0.101888055363.issue1272@bugs.pypy.org>
Message-ID: <1365031742.43.0.166356160533.issue1272@bugs.pypy.org>


Carl Meyer <carl at oddbird.net> added the comment:

Improved patch attached. This fixes PyPy's implementation of get_config_vars
instead of working around it in create_home_paths, and un-marks the
home_scheme_installation test as implementation-specific.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1272>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 01:33:51 2013
From: tracker at bugs.pypy.org (Carl Meyer)
Date: Wed, 03 Apr 2013 23:33:51 +0000
Subject: [pypy-issue] [issue1272] user and home install schemes broke in pypy
In-Reply-To: <1348949699.1.0.101888055363.issue1272@bugs.pypy.org>
Message-ID: <1365032031.58.0.0880411974791.issue1272@bugs.pypy.org>


Carl Meyer <carl at oddbird.net> added the comment:

Third version, with a better fix for get_config_vars. Thanks to bdk for review
and suggestions for both second and third versions of the patch.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1272>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 01:47:01 2013
From: tracker at bugs.pypy.org (Carl Meyer)
Date: Wed, 03 Apr 2013 23:47:01 +0000
Subject: [pypy-issue] [issue1272] user and home install schemes broke in pypy
In-Reply-To: <1348949699.1.0.101888055363.issue1272@bugs.pypy.org>
Message-ID: <1365032821.87.0.836450958334.issue1272@bugs.pypy.org>


Carl Meyer <carl at oddbird.net> added the comment:

Closing this, since the title issue (home/user installs broken) is fixed.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1272>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 01:48:59 2013
From: tracker at bugs.pypy.org (Carl Meyer)
Date: Wed, 03 Apr 2013 23:48:59 +0000
Subject: [pypy-issue] [issue1272] user and home install schemes broke in pypy
In-Reply-To: <1348949699.1.0.101888055363.issue1272@bugs.pypy.org>
Message-ID: <1365032939.85.0.82094088844.issue1272@bugs.pypy.org>


Carl Meyer <carl at oddbird.net> added the comment:

Fix is
https://bitbucket.org/pypy/pypy/commits/5b253d1468518921bbe24248feb26b6f54bf30ed

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1272>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 09:44:55 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Thu, 04 Apr 2013 07:44:55 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365061495.61.0.555271930869.issue1434@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

The PyGObject patches are all upstream now.

The attached patch is still needed.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 10:11:17 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 04 Apr 2013 08:11:17 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365063077.36.0.338040971889.issue1434@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Do you have a gdb traceback?
Also, last time I checked it was because pygobject_register_constants() uses a 
type that is not yew PyType_Ready().
I modified gobjectmodule.c and moved the call to pygobject_type_register_types() 
before pygobject_register_constants()

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 10:12:10 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 04 Apr 2013 08:12:10 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365063130.5.0.352758188724.issue1434@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

oops, I did not see it was part of your patch :-/

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 10:19:55 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Thu, 04 Apr 2013 08:19:55 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365063595.32.0.501419496936.issue1434@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

AFAIR tp_new returned a NULL pointer and it didn't crash in cpyext itself.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Thu Apr  4 10:31:23 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 04 Apr 2013 08:31:23 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365064283.78.0.796902118644.issue1434@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Could you attach a gdb traceback?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 19:11:04 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Fri, 05 Apr 2013 17:11:04 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

The following crashes with the jit enabled (linux x64)

while 1: hash(tuple([0] + {"": 0}.keys()))

----------
messages: 5520
nosy: lazka, pypy-issue
priority: critical
status: unread
title: Crash with recent nightly builds

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 22:53:23 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Fri, 05 Apr 2013 20:53:23 +0000
Subject: [pypy-issue] [issue1436] missed optimization on set contains
In-Reply-To: <1365195203.24.0.0908818563878.issue1436@bugs.pypy.org>
Message-ID: <1365195203.24.0.0908818563878.issue1436@bugs.pypy.org>


New submission from Brian Kearns <bdkearns at gmail.com>:

for list, performance looks not that different:
$ ./pypy/goal/pypy-c -m timeit -s "a = 'abc'" "'abc' in ('123', '456', 'abc', 
'def')"
1000000000 loops, best of 3: 0.00107 usec per loop
$ ./pypy/goal/pypy-c -m timeit -s "a = 'abc'" "a in ('123', '456', 'abc', 
'def')"
100000000 loops, best of 3: 0.00292 usec per loop

for set:
$ ./pypy/goal/pypy-c -m timeit -s "a = 'abc'" "'abc' in {'123', '456', 'abc', 
'def'}"
1000000000 loops, best of 3: 0.00107 usec per loop
$ ./pypy/goal/pypy-c -m timeit -s "a = 'abc'" "a in {'123', '456', 'abc', 
'def'}"
10000000 loops, best of 3: 0.025 usec per loop

looks like in the last case an optimization that is applied to list is not 
applied to set?

----------
messages: 5521
nosy: bdk, pypy-issue
priority: performance bug
status: unread
title: missed optimization on set contains

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1436>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 22:57:33 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 05 Apr 2013 20:57:33 +0000
Subject: [pypy-issue] [issue1436] missed optimization on set contains
In-Reply-To: <1365195203.24.0.0908818563878.issue1436@bugs.pypy.org>
Message-ID: <1365195453.96.0.0918558554291.issue1436@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

One (possibly missing optimization), is that with literal sets, instead of 
constructing a new set each time you can just put a frozenset in the bytecode, I 
did this optimization for CPython like 7 million years ago, I don't remember if I 
ever ported it to pypy.

Looking at: dis.dis(lambda x: x in {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}) should make it 
obvious if we do it or not.

----------
nosy: +agaynor
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1436>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 23:00:07 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 05 Apr 2013 21:00:07 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365195607.89.0.00745101344493.issue1435@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Confirmed :-(  Segfaults both on 32 and 64-bit Linux.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 23:02:14 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Fri, 05 Apr 2013 21:02:14 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365195734.48.0.267564373585.issue1435@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

i can reproduce this. also, some additional odd behavior that only occurs in 
interactive mode:

>>>> while 1: [0] + {"": 0}.keys()
[0, '']
[0, '']
[0, '']
Traceback (most recent call last):
  File "<console>", line 1, in <module>
UnboundLocalError: local variable 'x' referenced before assignment

>>>> while 1: tuple([0] + {"": 0}.keys())
(0, '')
(0, '')
(0, '')
Segmentation fault

----------
nosy: +bdk

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 23:03:40 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Fri, 05 Apr 2013 21:03:40 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365195820.52.0.569639594271.issue1435@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

actually can reproduce those simpler cases from a script if 'print' is added

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Fri Apr  5 23:37:03 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 05 Apr 2013 21:37:03 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365197823.39.0.401296240146.issue1435@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Added a simple failing test in ba3fbbd1e5ba.  I'm not fixing it now so feel free :-)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 10:58:27 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 06 Apr 2013 08:58:27 +0000
Subject: [pypy-issue] [issue1436] missed optimization on set contains
In-Reply-To: <1365195203.24.0.0908818563878.issue1436@bugs.pypy.org>
Message-ID: <1365238707.32.0.278056204636.issue1436@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

The difference disappears with --jit off.

In rdict.py, ll_dict_lookup() is unrolled only when jit.isconstant(key).
I haven't looked at the traces, but it's possible that in this case, the operation is a direct 
access to a known index...

This is not done when the key is in a variable, because of course it may change in the timeit 
loop.

Maybe the jit could learn about fastlocals that are unlikely to change, because there is no 
assignment in the loop?

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1436>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 11:47:27 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 06 Apr 2013 09:47:27 +0000
Subject: [pypy-issue] [issue1435] Crash with recent nightly builds
In-Reply-To: <1365181864.06.0.734682582783.issue1435@bugs.pypy.org>
Message-ID: <1365241647.62.0.153000568729.issue1435@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in 2ec1ac5c5ef1.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1435>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 14:16:22 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Sat, 06 Apr 2013 12:16:22 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365250582.71.0.668247600939.issue1434@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

As I said, there is no crash in pypy itself, but in pygobject, because tp_new
returned an unexpected result.

Am I missing something?

Also, I won't spend time on this atm.. just wanted to make it easy for someone
else to pick up where I left off.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 14:37:08 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 06 Apr 2013 12:37:08 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365251828.57.0.791864614313.issue1434@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

A call to tp_new will return NULL in case of a Python exception.
In this case the calling code should handle the error, and probably return 
quickly.
Where is this call to tp_new?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 16:33:18 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Sat, 06 Apr 2013 14:33:18 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365258798.45.0.112912250061.issue1434@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

tp_new call: https://git.gnome.org/browse/pygobject/tree/gi/_gobject/pygenum.c#n39

Ah, ok, thanks. The exception is: "type object 'PyGLibUserDirectory' has no
attribute '__enum_values__'".. probably from pyg_enum_new below.

Could it be that PyInt_Type.tp_new(int_subclass) calls new of the subclass
instead of the PyInt one?

.. I'm not that familiar with the Python C API.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Sat Apr  6 17:43:48 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 06 Apr 2013 15:43:48 +0000
Subject: [pypy-issue] [issue1434] CPyExt errors with PyGObject
In-Reply-To: <1364578043.09.0.242390855942.issue1434@bugs.pypy.org>
Message-ID: <1365263028.85.0.520601135038.issue1434@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

I came to the same conclusion.  This is an old issue with our C API layer: there is only one 
emulation of tp_new for all types provided by PyPy, and it does something like 
subclass.__new__(args).
The solution is to have a distinct tp_new for each type, which makes sense if you think about it.

Here is a tentative patch; it's not finished: more tests are needed, and we should migrate all 
slots emulation in this manner; but I fear that the (translated) code size explodes...

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1434>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 10:02:18 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 07 Apr 2013 08:02:18 +0000
Subject: [pypy-issue] [issue1437] PYTHONCASEOK
In-Reply-To: <1365321738.93.0.97658648.issue1437@bugs.pypy.org>
Message-ID: <1365321738.93.0.97658648.issue1437@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

Implement the PYTHONCASEOK environment variable.

----------
messages: 5537
nosy: arigo, pypy-issue
priority: feature
status: unread
title: PYTHONCASEOK

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1437>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 11:49:04 2013
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 07 Apr 2013 09:49:04 +0000
Subject: [pypy-issue] [issue1438] numpypy assignment to float array failure
In-Reply-To: <1365328144.37.0.0869454419059.issue1438@bugs.pypy.org>
Message-ID: <1365328144.37.0.0869454419059.issue1438@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

assignment fails for float array, int array succeeds
>pypy-c-jit-63106-a271c0002bba-win32\pypy.exe
Python 2.7.3 (a271c0002bba, Apr 06 2013, 22:01:08)
[PyPy 2.0.0-beta2 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''
>>>> import numpypy as np
>>>> a=np.arange(10,dtype=float)
>>>> a[0] = np.array([0.005])
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: expected float, got ndarray object
>>>> a=np.arange(10)
>>>> a[0] = np.array([5])
>>>>

----------
assignedto: mattip
messages: 5538
nosy: mattip, pypy-issue
priority: bug
status: unread
title: numpypy assignment to float array failure

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1438>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 21:19:27 2013
From: tracker at bugs.pypy.org (iElectric)
Date: Sun, 07 Apr 2013 19:19:27 +0000
Subject: [pypy-issue] [issue1439] cfffi warnings when starting pypy
	interpreter (only the	first time)
In-Reply-To: <1365362367.69.0.0509195352457.issue1439@bugs.pypy.org>
Message-ID: <1365362367.69.0.0509195352457.issue1439@bugs.pypy.org>


New submission from iElectric <domen at dev.si>:

When first running pypy-c, following warnings are raised:

Python 2.7.3 (3eef596df459f5cf3f44a21e66b28d4033674567, Apr 07 2013, 16:15:30)
[PyPy 2.0.0-beta2 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Python 2.x est presque mort, vive
Python!''
lib_pypy/__pycache__/_cffi__g85535e98x310af836.c: In function 
?_cffi_const_tparm?:
lib_pypy/__pycache__/_cffi__g85535e98x310af836.c:1046:3: warning: return from 
incompatible pointer type [enabled by default]
lib_pypy/__pycache__/_cffi__g85535e98x310af836.c: In function 
?_cffi_const_acs_map?:
lib_pypy/__pycache__/_cffi__g85535e98x310af836.c:1344:3: warning: return from 
incompatible pointer type [enabled by default]
>>>>

Using: libffi-3.0.13

----------
messages: 5539
nosy: iElectric, pypy-issue
priority: bug
release: 2.0
status: unread
title: cfffi warnings when starting pypy interpreter (only the first time)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1439>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 21:22:14 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 07 Apr 2013 19:22:14 +0000
Subject: [pypy-issue] [issue1439] cfffi warnings when starting pypy
	interpreter (only the	first time)
In-Reply-To: <1365362367.69.0.0509195352457.issue1439@bugs.pypy.org>
Message-ID: <1365362534.85.0.388322921672.issue1439@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Two problems here:

* these are warnings that come from incompatibilities between _curses.py and
your system's C headers for ncurses.h

* the second problem is that "_minimal_curses" was not compiled in, probably
because ncurses/terminfo was not found during the translation.  I guess by now
we should stop translation when the headers are not found, rather than just
disable using them (it used to be a good idea but it's not any more).

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1439>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 21:22:55 2013
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 07 Apr 2013 19:22:55 +0000
Subject: [pypy-issue] [issue1440] "import sqlite3" fails on win32
In-Reply-To: <1365362575.29.0.858977411419.issue1440@bugs.pypy.org>
Message-ID: <1365362575.29.0.858977411419.issue1440@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

import sqlite3 fails in latest win32 beta release

pypy-2.0-beta2\pypy.exe
Python 2.7.3 (3eef596df459, Apr 06 2013, 12:40:10)
[PyPy 2.0.0-beta2 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``in theory there is the Loop, in
practice there are bridges''
>>>> import sqlite3
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib-
python\2.7\sqlite3\__init__.py", line 24, in <module>
    from dbapi2 import *
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib-
python\2.7\sqlite3\dbapi2.py", line 27, in <module>
    from _sqlite3 import *
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib_pypy\_sqlite3.py", line 
262, in <module>
    if _has_load_extension():
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib_pypy\_sqlite3.py", line 
259, in _has_load_extension
    unverified_lib = unverified_ffi.dlopen('sqlite3')
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib_pypy\cffi\api.py", line 
111, in dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "C:\Users\matti\pypy_stuff\pypy-2.0-beta2\lib_pypy\cffi\api.py", line 
364, in _make_ffi_library
    raise OSError("library not found: %r" % (name,))
OSError: library not found: 'sqlite3'
>>>>

But if I comment out the name test in _make_ffi_library in api.py all is good.

    backend = ffi._backend
    try:
        #if '.' not in name and '/' not in name:
        #    raise OSError
        backendlib = backend.load_library(name, flags)
    except OSError:

Why don't we just let backend.load_library do it's thing?

----------
messages: 5541
nosy: mattip, pypy-issue
priority: bug
status: unread
title: "import sqlite3" fails on win32

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1440>
________________________________________

From tracker at bugs.pypy.org  Sun Apr  7 21:34:28 2013
From: tracker at bugs.pypy.org (iElectric)
Date: Sun, 07 Apr 2013 19:34:28 +0000
Subject: [pypy-issue] [issue1439] cfffi warnings when starting pypy
	interpreter (only the	first time)
In-Reply-To: <1365362367.69.0.0509195352457.issue1439@bugs.pypy.org>
Message-ID: <1365363268.4.0.70914960903.issue1439@bugs.pypy.org>


iElectric <domen at dev.si> added the comment:

OK. Indeed, startin 90min at screen for red warnings is not ideal :)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1439>
________________________________________

From tracker at bugs.pypy.org  Mon Apr  8 17:48:46 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 08 Apr 2013 15:48:46 +0000
Subject: [pypy-issue] [issue1440] "import sqlite3" fails on win32
In-Reply-To: <1365362575.29.0.858977411419.issue1440@bugs.pypy.org>
Message-ID: <1365436126.54.0.442494327856.issue1440@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

rather than modifying cffi, how about this fix which first looks for the 
sqlite3.dll next to the executable

diff -r 0126d6664978 lib_pypy/_sqlite3.py
--- a/lib_pypy/_sqlite3.py      Sun Apr 07 15:58:46 2013 +0200
+++ b/lib_pypy/_sqlite3.py      Mon Apr 08 18:46:35 2013 +0300
@@ -256,7 +256,12 @@
     typedef ... sqlite3;
     int sqlite3_enable_load_extension(sqlite3 *db, int onoff);
     """)
-    unverified_lib = unverified_ffi.dlopen('sqlite3')
+    libname = 'sqlite3'
+    if sys.platform == 'win32':
+        _libname = os.path.join(os.path.dirname(sys.executable), libname)
+        if os.path.exists(_libname + '.dll'):
+            libname = _libname
+    unverified_lib = unverified_ffi.dlopen(libname)
     return hasattr(unverified_lib, 'sqlite3_enable_load_extension')

 if _has_load_extension():

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1440>
________________________________________

From tracker at bugs.pypy.org  Mon Apr  8 18:49:50 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 08 Apr 2013 16:49:50 +0000
Subject: [pypy-issue] [issue1440] "import sqlite3" fails on win32
In-Reply-To: <1365362575.29.0.858977411419.issue1440@bugs.pypy.org>
Message-ID: <1365439790.09.0.48821856223.issue1440@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

fixed in changeset 341a34c7d62f

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1440>
________________________________________

From tracker at bugs.pypy.org  Mon Apr  8 20:36:40 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 08 Apr 2013 18:36:40 +0000
Subject: [pypy-issue] [issue1438] numpypy assignment to float array failure
In-Reply-To: <1365328144.37.0.0869454419059.issue1438@bugs.pypy.org>
Message-ID: <1365446200.87.0.678149450292.issue1438@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

fixed in 84ff2854255f by adding __float__ to ndarray

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1438>
________________________________________

From tracker at bugs.pypy.org  Mon Apr  8 20:59:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 08 Apr 2013 18:59:13 +0000
Subject: [pypy-issue] [issue1441] version of sqlite3.dll (and others)
In-Reply-To: <1365447553.59.0.396875761201.issue1441@bugs.pypy.org>
Message-ID: <1365447553.59.0.396875761201.issue1441@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

The nightly builder pick whatever version of sqlite3.dll (and others) that was
installed locally, and package that.  Someone reported in the blog's comments
that it happens to be a very old version.  We need a better way to control that.

----------
messages: 5546
nosy: arigo, pypy-issue
priority: bug
status: unread
title: version of sqlite3.dll (and others)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1441>
________________________________________

From tracker at bugs.pypy.org  Tue Apr  9 14:25:38 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 09 Apr 2013 12:25:38 +0000
Subject: [pypy-issue] [issue1442] reload(sys) closes stdout
In-Reply-To: <1365510338.89.0.697396335594.issue1442@bugs.pypy.org>
Message-ID: <1365510338.89.0.697396335594.issue1442@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

reload(sys) closes stdout on next gc.
The following script fails when output is redirected to a file:

import sys, gc
print "OK"
reload(sys)
gc.collect()
print "KO"


  File "/tmp/foo.py", line 5, in <module>
    print "KO"
IOError: [Errno 9] Bad file descriptor: '<fdopen>'

----------
messages: 5547
nosy: amaury, pypy-issue
priority: bug
status: unread
title: reload(sys) closes stdout

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1442>
________________________________________

From tracker at bugs.pypy.org  Tue Apr  9 14:44:05 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 09 Apr 2013 12:44:05 +0000
Subject: [pypy-issue] [issue1442] reload(sys) closes stdout
In-Reply-To: <1365510338.89.0.697396335594.issue1442@bugs.pypy.org>
Message-ID: <1365511445.87.0.571703872532.issue1442@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

... and segfaults when run with -u:

  pypy-c -u /tmp/foo.py > /tmp/foo.out

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1442>
________________________________________

From tracker at bugs.pypy.org  Tue Apr  9 17:54:48 2013
From: tracker at bugs.pypy.org (Anders Baekgaard)
Date: Tue, 09 Apr 2013 15:54:48 +0000
Subject: [pypy-issue] [issue1443] Problem with build of 2.0 beta2 with
	--shared option
In-Reply-To: <1365522888.56.0.137205121595.issue1443@bugs.pypy.org>
Message-ID: <1365522888.56.0.137205121595.issue1443@bugs.pypy.org>


New submission from Anders Baekgaard <ab at netfors.com>:

Build of 2.0 beta2 with --shared option does not work, see attached log.

Build environment is Ubuntu 12.10 amd64 with all updates installed.

----------
files: builderr.txt
messages: 5549
nosy: andersbaekgaard, pypy-issue
priority: bug
release: 2.0
status: unread
title: Problem with build of 2.0 beta2 with --shared option

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1443>
________________________________________
-------------- next part --------------
ab at ra:~/src/pypy-pypy-4b60269153b5/pypy/goal$ ../../rpython/bin/rpython -Ojit  --shared targetpypystandalone
[platform:msg] Set platform with 'host' cc=None, using cc='gcc'
[translation:info] Translating target as defined by targetpypystandalone
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/gcctest.c -o /tmp/usession-release-2.0-beta2-1/gcctest.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/gcctest.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/gcctest
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/gcctest.c -o /tmp/usession-release-2.0-beta2-1/gcctest.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/gcctest.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/gcctest
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_0.c -o /tmp/usession-release-2.0-beta2-1/platcheck_0.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_0.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_0
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_1.c -o /tmp/usession-release-2.0-beta2-1/platcheck_1.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_1.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_1
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_2.c -o /tmp/usession-release-2.0-beta2-1/platcheck_2.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_2.o -pthread -lintl -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_2
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_3.c -o /tmp/usession-release-2.0-beta2-1/platcheck_3.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_3.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_3
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_4.c -o /tmp/usession-release-2.0-beta2-1/platcheck_4.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_4.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_4
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_5.c -o /tmp/usession-release-2.0-beta2-1/platcheck_5.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_5.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_5
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_6.c -o /tmp/usession-release-2.0-beta2-1/platcheck_6.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_6.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_6
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_7.c -o /tmp/usession-release-2.0-beta2-1/platcheck_7.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_7.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_7
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_8.c -o /tmp/usession-release-2.0-beta2-1/platcheck_8.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_8.o -pthread -lz -lssl -lcrypto -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_8
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_9.c -o /tmp/usession-release-2.0-beta2-1/platcheck_9.o
[platform:WARNING] /tmp/usession-release-2.0-beta2-1/platcheck_9.c: In function ???dump_section_SSLEAY_VERSION???:
[platform:WARNING] /tmp/usession-release-2.0-beta2-1/platcheck_9.c:186:12: warning: initialization discards ???const??? qualifier from pointer target type [enabled by default]
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_9.o -pthread -lz -lssl -lcrypto -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_9
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_10.c -o /tmp/usession-release-2.0-beta2-1/platcheck_10.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_10.o -pthread -lcurses -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_10
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_11.c -o /tmp/usession-release-2.0-beta2-1/platcheck_11.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_11.o -pthread -lexpat -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_11
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_12.c -o /tmp/usession-release-2.0-beta2-1/platcheck_12.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_12.o -pthread -lexpat -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_12
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /tmp/usession-release-2.0-beta2-1/platcheck_13.c -o /tmp/usession-release-2.0-beta2-1/platcheck_13.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/stacklet/stacklet.c -o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/stacklet/stacklet.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_13.o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/stacklet/stacklet.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_13
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_14.c -o /tmp/usession-release-2.0-beta2-1/platcheck_14.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_14.o -pthread -lbz2 -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_14
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_15.c -o /tmp/usession-release-2.0-beta2-1/platcheck_15.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_15.o -pthread -lbz2 -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_15
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_16.c -o /tmp/usession-release-2.0-beta2-1/platcheck_16.o
[platform:WARNING] /tmp/usession-release-2.0-beta2-1/platcheck_16.c: In function ???main???:
[platform:WARNING] /tmp/usession-release-2.0-beta2-1/platcheck_16.c:44:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_16.o -pthread -lbz2 -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_16
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_17.c -o /tmp/usession-release-2.0-beta2-1/platcheck_17.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_17.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_17
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_18.c -o /tmp/usession-release-2.0-beta2-1/platcheck_18.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_19.c -o /tmp/usession-release-2.0-beta2-1/platcheck_19.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_20.c -o /tmp/usession-release-2.0-beta2-1/platcheck_20.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_20.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_20
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_21.c -o /tmp/usession-release-2.0-beta2-1/platcheck_21.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_21.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_21
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_22.c -o /tmp/usession-release-2.0-beta2-1/platcheck_22.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_22.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_22
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_23.c -o /tmp/usession-release-2.0-beta2-1/platcheck_23.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_23.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_23
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_24.c -o /tmp/usession-release-2.0-beta2-1/platcheck_24.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_24.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_24
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_25.c -o /tmp/usession-release-2.0-beta2-1/platcheck_25.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_26.c -o /tmp/usession-release-2.0-beta2-1/platcheck_26.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_26.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_26
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_27.c -o /tmp/usession-release-2.0-beta2-1/platcheck_27.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_27.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_27
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_28.c -o /tmp/usession-release-2.0-beta2-1/platcheck_28.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_28.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_28
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /tmp/usession-release-2.0-beta2-1/platcheck_29.c -o /tmp/usession-release-2.0-beta2-1/platcheck_29.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.c -o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_29.o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.o -pthread -Wl,--export-dynamic,--version-script=/tmp/usession-release-2.0-beta2-1/dynamic-symbols-0 -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_29
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_30.c -o /tmp/usession-release-2.0-beta2-1/platcheck_30.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_30.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_30
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_31.c -o /tmp/usession-release-2.0-beta2-1/platcheck_31.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_31.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_31
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_32.c -o /tmp/usession-release-2.0-beta2-1/platcheck_32.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_32.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_32
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_33.c -o /tmp/usession-release-2.0-beta2-1/platcheck_33.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_33.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_33
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_34.c -o /tmp/usession-release-2.0-beta2-1/platcheck_34.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_34.o -pthread -ldl -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_34
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_35.c -o /tmp/usession-release-2.0-beta2-1/platcheck_35.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_35.o -pthread /usr/lib/x86_64-linux-gnu/libffi.a -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_35
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_36.c -o /tmp/usession-release-2.0-beta2-1/platcheck_36.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_36.o -pthread -lz -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_36
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_37.c -o /tmp/usession-release-2.0-beta2-1/platcheck_37.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_37.o -pthread -lz -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_37
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_38.c -o /tmp/usession-release-2.0-beta2-1/platcheck_38.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_38.o -pthread -lz -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_38
[translation] PyPy config object:
[translation] [objspace]
[translation]     honor__builtins__ = False
[translation]     [opcodes]
[translation]         CALL_METHOD = True
[translation]     [std]
[translation]         builtinshortcut = True
[translation]         getattributeshortcut = True
[translation]         optimized_list_getitem = True
[translation]         withcelldict = True
[translation]         withidentitydict = True
[translation]         withmapdict = True
[translation]         withmethodcache = True
[translation]         withprebuiltchar = True
[translation]         withrangelist = True
[translation]         withspecialisedtuple = True
[translation]         withtypeversion = True
[translation]     [usemodules]
[translation]         __pypy__ = True
[translation]         _ast = True
[translation]         _cffi_backend = True
[translation]         _codecs = True
[translation]         _collections = True
[translation]         _continuation = True
[translation]         _csv = True
[translation]         _ffi = True
[translation]         _hashlib = True
[translation]         _io = True
[translation]         _locale = True
[translation]         _lsprof = True
[translation]         _md5 = True
[translation]         _minimal_curses = True
[translation]         _multibytecodec = True
[translation]         _multiprocessing = True
[translation]         _pickle_support = True
[translation]         _random = True
[translation]         _rawffi = True
[translation]         _sha = True
[translation]         _socket = True
[translation]         _sre = True
[translation]         _ssl = True
[translation]         _testing = True
[translation]         _weakref = True
[translation]         array = True
[translation]         binascii = True
[translation]         bz2 = True
[translation]         cStringIO = True
[translation]         cmath = True
[translation]         cpyext = True
[translation]         crypt = True
[translation]         errno = True
[translation]         fcntl = True
[translation]         gc = True
[translation]         imp = True
[translation]         itertools = True
[translation]         marshal = True
[translation]         math = True
[translation]         micronumpy = True
[translation]         mmap = True
[translation]         operator = True
[translation]         parser = True
[translation]         pwd = True
[translation]         pyexpat = True
[translation]         pypyjit = True
[translation]         rctime = True
[translation]         select = True
[translation]         signal = True
[translation]         struct = True
[translation]         symbol = True
[translation]         termios = True
[translation]         thread = True
[translation]         token = True
[translation]         unicodedata = True
[translation]         zipimport = True
[translation]         zlib = True
Wrote /home/ab/src/pypy-pypy-4b60269153b5/lib_pypy/ctypes_config_cache/_locale_x86_64_.py.
Wrote /home/ab/src/pypy-pypy-4b60269153b5/lib_pypy/ctypes_config_cache/_resource_x86_64_.py.
Wrote /home/ab/src/pypy-pypy-4b60269153b5/lib_pypy/ctypes_config_cache/_syslog_x86_64_.py.
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/gcctest.c -o /tmp/usession-release-2.0-beta2-1/gcctest.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/gcctest.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/gcctest
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_39.c -o /tmp/usession-release-2.0-beta2-1/platcheck_39.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_39.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_39
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_40.c -o /tmp/usession-release-2.0-beta2-1/platcheck_40.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_40.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_40
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -DPy_BUILD_CORE -I/home/ab/src/pypy-pypy-4b60269153b5/pypy/module/cpyext/include -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c -I/tmp/usession-release-2.0-beta2-1 /tmp/usession-release-2.0-beta2-1/platcheck_41.c -o /tmp/usession-release-2.0-beta2-1/platcheck_41.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_41.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_41
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_42.c -o /tmp/usession-release-2.0-beta2-1/platcheck_42.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_42.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_42
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -DPy_BUILD_CORE -I/home/ab/src/pypy-pypy-4b60269153b5/pypy/module/cpyext/include -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c -I/tmp/usession-release-2.0-beta2-1 /tmp/usession-release-2.0-beta2-1/platcheck_43.c -o /tmp/usession-release-2.0-beta2-1/platcheck_43.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_43.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_43
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -DPy_BUILD_CORE -I/home/ab/src/pypy-pypy-4b60269153b5/pypy/module/cpyext/include -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c -I/tmp/usession-release-2.0-beta2-1 /tmp/usession-release-2.0-beta2-1/platcheck_44.c -o /tmp/usession-release-2.0-beta2-1/platcheck_44.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_44.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_44
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_45.c -o /tmp/usession-release-2.0-beta2-1/platcheck_45.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_45.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_45
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /tmp/usession-release-2.0-beta2-1/platcheck_46.c -o /tmp/usession-release-2.0-beta2-1/platcheck_46.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.c -o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_46.o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.o -pthread -Wl,--export-dynamic,--version-script=/tmp/usession-release-2.0-beta2-1/dynamic-symbols-1 -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_46
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -fPIC -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.c -o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.o
[platform:execute] gcc -shared /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/thread.o -pthread -Wl,--export-dynamic,--version-script=/tmp/usession-release-2.0-beta2-1/dynamic-symbols-2 -lrt -o /tmp/usession-release-2.0-beta2-1/shared_cache/externmod.so
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_47.c -o /tmp/usession-release-2.0-beta2-1/platcheck_47.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_47.o -pthread -lrt -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_47
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_48.c -o /tmp/usession-release-2.0-beta2-1/platcheck_48.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_48.o -pthread -lrt -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_48
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_49.c -o /tmp/usession-release-2.0-beta2-1/platcheck_49.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_49.o -pthread -lrt -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_49
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -fPIC -I/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.c -o /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.o
[platform:execute] gcc -shared /home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/c/src/signals.o -pthread -Wl,--export-dynamic,--version-script=/tmp/usession-release-2.0-beta2-1/dynamic-symbols-3 -lrt -o /tmp/usession-release-2.0-beta2-1/shared_cache/externmod_0.so
[translation] translate.py configuration:
[translation] [translate]
[translation]     opt = jit
[translation]     targetspec = targetpypystandalone
[translation] translation configuration:
[translation] [translation]
[translation]     backend = c
[translation]     check_str_without_nul = True
[translation]     continuation = True
[translation]     gc = minimark
[translation]     gcrootfinder = asmgcc
[translation]     gctransformer = framework
[translation]     jit = True
[translation]     list_comprehension_operations = True
[translation]     rweakref = True
[translation]     secondaryentrypoints = cpyext
[translation]     shared = True
[translation]     thread = True
[translation]     type_system = lltype
[translation]     withsmallfuncsets = 5
[translation:info] Annotating&simplifying...
[888] {translation-task
starting annotate
[translation:info] with policy: pypy.tool.ann_override.PyPyAnnotatorPolicy
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_51.c -o /tmp/usession-release-2.0-beta2-1/platcheck_51.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_51.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_51
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_52.c -o /tmp/usession-release-2.0-beta2-1/platcheck_52.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_52.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_52
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_53.c -o /tmp/usession-release-2.0-beta2-1/platcheck_53.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_53.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_53
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_54.c -o /tmp/usession-release-2.0-beta2-1/platcheck_54.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_54.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_54
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_55.c -o /tmp/usession-release-2.0-beta2-1/platcheck_55.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_55.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_55
.+++++++++++++++***********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%########################################################################%%%%%%%*************
+++++++++++++*********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%########################################################################%%%%%%%%%%**********
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###############################################################################%%%%%%%%%%%%%%*******
+++++++++*****************#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#############################################################################%#%%%%%%%%%%%%%%%*****
+++++++****************%%%%###%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###############################################################################%%%%%%#%%%%%%%%%%**
+++++****************%%%%%%###%%%%%%%%%%%%%%%##%%%%%%%%%%%%%%%%%%%%%%#######################################################################################%##%%%%%%%%%%%*
++++***************%%%%%%%%%%%#####%#%%%%%%%################################################################################################################%%%%%%%%%%%%%%%
+++**************%%%%%%%%%%%%%%%%#########################################################################################################################%%%%%%%%%%%%%%%%%
++**************%%%%%%%%%%%%%%%############################################################################################################################%##%%%%%%%%%%%%%
+*************%%%%%%%%%%%%%%%%#############################################################################################################################%#%%%%%%%%%%%%%%
*************%%%%%%%%%%###################################################################################################################################%#%%%%%%%%%%%%%%%
***********%%%%%%#%#####################################################################################################################################%%%%%%%%%%%%%%%%%%%
%*********%%%%%%#######################################################################################################################################%%%%%%%%%%%%%%%%%%%%
%%%%*****%%%%%%#######################################################################################################################################%%%%%%%%%%%%%%%%%%%%%
#######################################################################################################################################################%%%%%%%%%%%%%%%%%%%%
%%%%*****%%%%%%#######################################################################################################################################%%%%%%%%%%%%%%%%%%%%%
%*********%%%%%%#######################################################################################################################################%%%%%%%%%%%%%%%%%%%%
***********%%%%%%#%#####################################################################################################################################%%%%%%%%%%%%%%%%%%%
*************%%%%%%%%%%###################################################################################################################################%#%%%%%%%%%%%%%%%
+*************%%%%%%%%%%%%%%%%#############################################################################################################################%#%%%%%%%%%%%%%%
++**************%%%%%%%%%%%%%%%############################################################################################################################%##%%%%%%%%%%%%%
+++**************%%%%%%%%%%%%%%%%#########################################################################################################################%%%%%%%%%%%%%%%%%
++++***************%%%%%%%%%%%#####%#%%%%%%%################################################################################################################%%%%%%%%%%%%%%%
+++++****************%%%%%%###%%%%%%%%%%%%%%%##%%%%%%%%%%%%%%%%%%%%%%#######################################################################################%##%%%%%%%%%%%*
+++++++****************%%%%###%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#############[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_56.c -o /tmp/usession-release-2.0-beta2-1/platcheck_56.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_56.o -pthread -lrt -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_56
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_57.c -o /tmp/usession-release-2.0-beta2-1/platcheck_57.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_57.o -pthread -lrt -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_57
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_58.c -o /tmp/usession-release-2.0-beta2-1/platcheck_58.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_58.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_58
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_59.c -o /tmp/usession-release-2.0-beta2-1/platcheck_59.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_59.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_59
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-2.0-beta2-1/platcheck_60.c -o /tmp/usession-release-2.0-beta2-1/platcheck_60.o
[platform:execute] gcc /tmp/usession-release-2.0-beta2-1/platcheck_60.o -pthread -lrt -o /tmp/usession-release-2.0-beta2-1/platcheck_60
##################################################################%%%%%%#%%%%%%%%%%**
+++++++++*****************#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#############################################################################%#%%%%%%%%%%%%%%%*****
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###############################################################################%%%%%%%%%%%%%%*******
+++++++++++++*********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%########################################################################%%%%%%%%%%**********

**************************%%%%%%%%%%%%%%%%%%%%%%%%%%%#########################%%%%%%%%%%%%%%%%%*****#%%%######%%%****+++**%%%##%%***#***********+++++......................
*************#%**********%####%%%%%%%%%%%%%%%%%%%%###############################%%%%%%%%%%%%%%%****%%%%%%%%%%%%****++++**********%%%%%%%%%%%******++++....................
************%**%%%%******%%%%%%%%%%%%%%%%%%%%%%%%#################################%%#####%%%%%%%%%#%%************+++++*********%%%%##%%%%%%%%%%%****++++...................
**************%###%%****%#%%%%%%%%%%%%%%%%%%%%%%###################################%%%%%%%#%%#%%%*************++++++++********%%%%%%%########%%%%****+++...................
*******************%##**%%%%%%%%%%%%%%%%%%%%%%%%###################################%%%%%%%%%%%%%%***%%%%******+++++++*********%%%%%%##########%%%%***++**#*................
***********************%%%%%%%##%#%%#%%%%####%%%###################################%%%%%%%%%%%%##%************++++++++*********%%%%%%%######%%#%%****++*%**++..............
******************%%%%%%*%%%%%%%%%%%%%%########%%#################################%%%%%%%%%%%%%%%*************+++++++++**********%%%%%%%%%%%%%%%**%#%##**%%%##**+..........
%%%%%%%%%%*******%%####%%%%%%%%%%%%%%%%#######%%%%##############################%%%%%%%%%%%%%%%%*************++++++++++++************************++++**##*++++.............
%%%%%%%%%%%%%%%***%%%%%***%%%%%%%%%%%%%%%%%%%%%%%%%%%#########################%%%%%%%%%%%%%%%%%**************++++++++++++++++****************+++++****%%%%%*++.............
%%%%#%%%%%%%%%%%%*%********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%##################%%%%%%%%%%%%%%%%%%%%**************++++++++++++++++++++++++++++++++++++++***%%###%**+.............
##############%%%%%***%*****%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************++++++++++++.+++++++++++++++++++......++++*****#*%*.............
############%%%%%%%%%*********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***************++++++++++++.................................+*%%*++*............
############%%%%%%%%************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%****************++++++++++++....................................*#+...............
############%%%%%%%%***************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******************+++++++++++++......................................................
##########%%%%%%%%%*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%********************+++++++++++++........................................................
%%%%#%%%%%%%%%%%%%*************************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**********************++++++++++++++.........................................................
%%%%%%%%%%%%%%%%**********************************%%%%%%%%%%%%%%%%%%%%%***************************+++++++++++++++..........................................................
%%%%%%%%%%%%%***********************************************************************************+++++++++++++++............................................................
*%%%*****************************************************************************************+++++++++++++++++.............................................................
******************************************************************************************++++++++++++++++++...............................................................
****************+*********************************************************************++++++++++++++++++++.................................................................
***********++++++++++*************************************************************++++++++++++++++++++++...................................................................
++++++++++++++++++++++++++***************************************************+++++++++++++++++++++++++.....................................................................
++++++++++++++++++++++++++++++++***************************************+++++++++++++++++++++++++++++.......................................................................
+++++++++++++++++++++++++++++++++++++++++++*****************+++++++++++++++++++++++++++++++++++++..........................................................................
*******************++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++............................................................................
**************************++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++...............................................................................
*****%#***********************+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++..................................................................................

......%#%%*+++*%*%%#%%*#***%%*******++++++++........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**%%%%%%%%%%%%************
.........+....++++++***%%#%%%%%%%****+++++.......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**%####%%%*****************
.................++***%%%#####%%%%****++++...+++++++++++++++++++++++++++++++++++++++++*++++++++++++++++++++++++++++++++++++++++++++++++++++++****%%%#%%%*******************
.................+++**%%%%###%%%%%****++++++++++++++++++++++++++++++++++++++++++++++*%*%++++++++++++++++++++++++++++++++++++++++++++++********#***%##%%********************
..................+++****%%%%%%******+++++++++++++++++++++++++++++++++++++++++++++%%***++++++++++++++++++++++++++++++++++++++++*******************%%%%**********%**********
....................+++++*%#%*#%%%%%#**+++++++++++*++++++++%++++++++++++++++++++++#*+++++++++++++++++++++++++++++++++++++************************%**%%%%****%%#%%%%***%****
......................+++++++**%####%**+++++++*+*+%******+*%%*********++++++++++++++*%%+++++++++++++++++++++++++++++************************************%******%%##%#%%%***
.............................++****%*%##%**+#++*%%*%####%%%#%***%%%%%*******++++****%%%#*%+++++++++++++++++++++**************************************************%%%%#%%%%%
...........................+++++++%++++++++++++++**%%%%%%*%##%%%%%#%%%%%%%****#%%%%%%##%*******************#****************************************************%%%%######%
.........................++++++++++++++++++++++++++******%%%%%########%%%%%%*%%%%######%%**************#*%%****************************************************#%%%%######%
......................++++++++++++++++++++++++++++++****%%%%%##########%%%%%%%%%##%%%%%%%*************%%*******************************************************%%%%%%%%%%%#
....................++++++++++++++++++++++++++++++++*****%%%%%#######%%####%%%%##%%%%%%%*************%**********************************************************%%%%%%%%%%%
.................+++++++++++++++++++++++++++++++++++*****%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%******************************************%%%%%%%%%%%%%%%##
...............++++++++++++++++++++++++++++++++++++++*****#*%%%%%%%%%%%%%%%%%%%#####%%%%#%%%%%%%%%%%####%%%%%%%%%%%%%%%**********%*******************%#%%%%%%%%%#%#%%%#####
............++++++++++++++++++++++++++++++++++++++++++***********%%%%%%%%%%%%%%%###########%%%%%%%%%###%%%%%#%%%%%%%%%%%%%%%%**%%#****************%%%%%%%%%%%##%%##########
..........+++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%%###################%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%#%%*************%%%%%%%%%%%%%%%%%###########
........++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%#%################################%%%%%%##%%%%%%%%%%%%%%%%%%%%#%**##%%%%%%%%%%%%%%%%%%#############
......++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%################################%#%%%%%%%%%%%%%%%%%%%%%%%%#######%#%%%%%#%%%%%%%%##############
....+++++++++++++++++++++++++++++++++++++++++++**************%#%%%%%#%%%%%%#####################################%%%%%%%%%%%%%%%%%####%######%%%%%%%%%##%%%%%###############
.++++++++++++++++++++++++++++++++++++++++++++**************%%%%%%%####%%%%%######################################%%%%%%%#%%%%%%%%%%%%############%%######%%################
++++++++++++++++++++++++++++++++++++++++++++****%*********%%%%%%%%##%%%%###########################################%%%%%%%%######%%%#######################################
++++++++++++++++++++++++++++++++++++++++++******%#%%****%%%%##%####%%%###############################################%%%%%%%###############################################
+++++++++++++++++++++++++++++++++++++++++********%%###%%%%%%%%%%%%%%%%%%###################################################################################################
++++++++++++++++++++++++++++++++++++++++**************%%%%%%%%%%%%%%%%%%%##################################################################################################
+++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%%%%%%###################################################################################################
++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%%%%%##%##################################################################################################
+++++++++++++++++++++++++++++++++++++****************%%%%%%%%%%%%%#%%%%%%%#################################################################################################
++++++++++++++++++++++++++++++++++++****************%%%%%%%%%%%%%%%%%%%%%%%################################################################################################

********%%%%%%%%%################%%%%%%%%%%***********++++++++*******%%%%%%%%#######%#%%%%*****++++++....................................+*%*%%%##%%*+.....................
********%%%%%%%%%#################%%%%%%%%%%******%****+++++++********%%%%#%%%%%%%%%%%%%%******++++++++++++++++++++++++++++++++++++++++%%##%**+*****+++....................
********%%%%%%%%%%#################%%%%%%%%%***********+++++++%*****%%%%%#%%%%%%%%%%%%%*******++++++++++++++++++++++++++++++++++++++++*%*****+++++++++++++++++++++.........
********%%%%%%%%%%%############%%%%%%%%##%%%%%%%%%%%*****++++++**%%#%#####%%%%%%%************+++++++++++++++++++++++++++++++++++++++%%%*+++++++++++++++++++++++++++++++++++
*********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%###%%%%%%****++++***%%%%%%%%%%%**************++++++++++++++++++++++++++++++++++++++++*#%+++++++++++++++++++++++++++++++++++++
***********%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%#%########%%%%*****+++*%%##%%%%%**************++++++++++++++++++++++++++++++++++++++++++++*++++++++++++++++++++++++++++++++++++++
+************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#####%%%%%%##%%%**+*%#%%*******+***++++++++++++++++++%+++*+++++++++++++++++++++++++++++++++*#++%++++++++++++++++++++++++++++++
+++*************%%%%%%%%%%%%%%%%%%%%%*****%%%%%%%%%%%%%%%%%%%#%#%*+++++++++++++++++++++++++++++*+%*+++++++++++++++++++++++++++++++++++++**#**++++++++++++++++++++++++++++++
**++*********%***********%%%********************%*************+**%#%%%**********************++%++++*************************************%%%*+++++++++++++++++++++++++++++++
%%#+*%#%%%**********************************#************++++****#%#%%#%%%%%#*************************************************************%************++++++++++++++++++++
++*%+++++*****************************************++++++++++****%%%#####%%%%%%%*********#*********************************#*********%%%%%%%#%**#%****************++++++++++
+++#+++++++++**********************************++++++++++****%*%#%%########%%%%%%%%%%%%%%%%%%###%********************************%#%%%#####%%%***************************++
++++++++++++++++++*************************+++++++++++********%%%#%########%%%%%%%%%%%%%%%%%##%%%%%%%**%**************************%%#%%###%%%%*************%*%****%********
+++++++++++++++++++++++++++++++++++++++++++++++++++******%*****%%%%%%%%####%%%%%%#%%%%%%%%%%%#%%%%%###%#%%***********************%%%###%%%%%*******************************
..+++++++++++++++++++++++++++++++++++++++++++++++************%%%%%%%%%%%%###%%%%%#%%%%%%#%%%%#%%%%%%%%%%%%%%%%%*%***********%****#%#%#%%%********##*****#%#****************
.....++++++++++++++++++++++++++++++++++++++++++***********%%%%%%%%%%#%%%################%%###%#%%%%%%%%%%%%%%%%%%%%****************%##%%**%######%%###%%*%%****************
........++++++++++++++++++++++++++++++++++++**********#*%%%%%%%%%%#%%%##########################%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**#####%***%%%%%#%%%*******************
.........++++++++++++++++++++++++++++++++*************%%##%%%%%%%%%%%%##############################%%%%%%%#%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%##%%%****************************
......+++++++++++++++++++++++++++++++****************%%%%%%#%%%%%%%####################################%%%%%%%%#%%##%%%%%%#%%%%%%%%%%%%#%###%%%%%%%%%%*********************
....+++++++++++++++++++++++++++%+**%***********%***%#%%###%%%%###########################################%%%%%%%%#%%%%%%%%%%#%%%#%%%%%#######%%%%%%%%%%%%%%%***************
.++++++++++++++++++++++++++++++******%%*****#%#%*%####%%%%%%%%%%%###########################################%%%######%%%%%%%%%%#######%%%#####%%%#%%%%%%%%%%%%%%%*%%%#%%#%*
+++++++++++++++++++++++++++++*********************%%%%%%%%%%%%%%######################################################%%###################%%%%%%%%%%%%%%%%%%%%%%%%%%%*****
++++++++++++++++++++++++++************************%%%%%%%%%%%%%%#############################################################################%#%#%%%%%%%%%%%%%%%%%%%%%%%%%*
++++++++++++++++++++++++*************************%%%%%%%%%%%%%#%#############################################################################%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%
++++++++++++++++++++++***************************%%%%%%%%%%%%%%%##############################################################################%%%%%%%%%%%###%%%%%%%%%%%%%%%
++++++++++++++++++++*****************************%%%%%%%%%%%%%%%%#############################################################################%##%%%%%%%%#%%##%%#%%%%%#%%%%
++++++++++++++%%++***************#**************%%%%%%%%%%#%%%%%%##############################################################################%%%%%%%%%%%%%#%%%##%%%%%%%%%
++++++++++++++++%%*#***##%%******%************%%%%%%#####%%%%%##%%##################################################################################%#%######%%%%%%%%%%%%%%

####%%%%%%%%%%%%%%%%***************++++++++++++++++++++++++++++++*%*+++++++++++++++++++++++++++++.......................+++*******%#%*+++++*++*....+.......................
#%#%%%%%%%%%%%%%%%%***************#++++++++++++++++++++++++**++++++++++++++++++++++++++++++++++++++++++++++++++++++....*+***%%%%##%%%***%+.........................+.......
%#%%%%%%%%%%%%%%%%*****************++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++%+++++++++++++++%%***%%%####%%%**++**.+...................%.++......
%%%%%%%%%%%%%%%%%****#*%*%*********+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++%+++*#%*%+++***%%%%%%%***+++.................................
%%###%%%%%%%%%%*****%*************+++++++++++++++++++++++++*+*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*%%%*****%++++*++++++...................*......
%%%%%%%%%%%%%%*******************+++++++++++++++++++++++%+*%*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++%+++***#%%+%++++++++++++++++*+++.......*..*%%.....
%%%%%%%%%%%%%%%%%***#*%*****%***++++++++++++++++*+++++++++++*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++%%%##%%**+++++++++++++++++*+++++++++....+%++%*+
%%%%########%%%%%%*************++++++++++++++++++++++++++***++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++%#%%%%**++++++++++%++++++%+*++++++++++++++%#***
%%##########%%%%%%***********+++++++++++++++++++++++*+**%##%*++++++++++++++++++++++++++++++++++++++++++++++++++++*%++++*++++++++*#*%*+*+++++++++++++++++********++*%%%%%%%%
%%%%%%%%%%#%%%%%%**********++++++++*++++++++++++++++++++*%**++++++++++++++++%+++++++++++++++++++++++++++++++++++++++++++++++++*+*%%*++++++++++++*****+%#%%%##%%%****%%%%%##
**%%%%%%%%%%%%%**%******++++++++++++++++++++++++++++++*%#%********************************++++++++++++++++++++++++++++++++++++%++++%*++++**%#%#*%##%%%**%%%##%%%%#%#***%%%%
*********%%###%%*****++++++%+++++++++++++***********%***%*****************%%********************#************+++++++++++++++++++++++++++++++++*++***+*+**********+++*******
********%**%%%#%**++++++++++**%*************************%%************#%%%*%********************************************++++++++++++**%+++++++++++++++*++++++++*+++**++++++
*****++++++++++#******************************************%****%#*#%**************************%************%************************%**++++++++++++++++*++++++++++++++**+++
+++++++++++***%%###%%%%**********%*************************%**************************************************************%**#**%%#%%%****+++++++++++++++++++++++++++++++++
++++++********%%%%%%%%%%%%%#%****************************%#******************************************%*%*****%#****************%#%%%%***%********++++++++++++++++++++++++++
++**#*******%%%%%########%%%%%%%*%%%%%%%%%%%%****%***%%###*********%*%*********************************#***********************************************++++++++++++++++++++
******%****%%%%%##########%%%%%%%%%%#%%%%%%%%%%%%%%%%####%%**%#*#***************************************************%%%%%%%%%%%%%%%%*************************++++++++++++++
*####******%%%%%%##########%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%********************************************%#%*%%%%%%%###%%%%#%%%*******************************+++++++++
***********%%%%%%%%%%#####%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%********%********************************%#%%%#########%%%%*%#***%%******************************+++
********%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%#%%%%%%%%%%%**%*******%%*********************%%%%%###%#######%%%%%*****************************************
*****%%%%%%#%%%%%%%%#%%%#############%%%%%%%%%###%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******#**************%******%%%#####%%%%%%%%%#%%%*********%********************************
***%%%%%#%%%%%%%%%%%%%###########################%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%******************%%%%%%%%%%%%%%%%%%%*****%**************************************
*%%%%%%%%%%%%%%%%%%%##################################%%%%%%#%%%%%#%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%*****###%%%%********************************************************
%%%%%%%%%%%%%%%%%%%#######################################%%%%%%%%%%%%%%%#%#%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%**********************************************************
%%%%%%%%%%%%%%%%%############################################%%%%%%%%%%%%%%%%%##%%%%%%%%%%%%%#%%%#%%%%%%%%%%%%%%##%%%%%%***************************************************
%%%%%%%%%%%###%#################################################%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%##%%%%%%%%%%%%*****%%**************************************
%%%%%%%%%%#########################################################%%%%%%%%%%%#%%%%%%#%%%%%%%%%%%#%%%%%%%%%%%#######%%%%%%#%%%%%%%%%*************************#**%**********

**************************%%%%%%%%%
[annrpython:WARNING] <FunctionGraph of (pypy.module.micronumpy.interp_numarray:99)W_NDimArray._prepare_array_index at 0x2be2f670> block at 507 op=0/ no precise annotation supplied for iter(SomePBC(can_be_None=True, const=None, subset_of=None),)                                                                                                     
[annrpython:WARNING] <FunctionGraph of (pypy.module.micronumpy.interp_numarray:99)W_NDimArray._prepare_array_index at 0x2be2f670> block at 507 op=0/ no precise annotation supplied for next(SomeImpossibleValue(),)                                                                                                                                     
**************************%%%%%%%%%%%%%%%%%%%%%%%%%%%#########################%%%%%%%%%%%%%%%%%*****#%%%######%%%****+++**%%%##%%***#***********+++++......................
*************#%**********%####%%%%%%%%%%%%%%%%%%%%###############################%%%%%%%%%%%%%%%****%%%%%%%%%%%%****++++**********%%%%%%%%%%%******++++....................
************%**%%%%******%%%%%%%%%%%%%%%%%%%%%%%%#################################%%#####%%%%%%%%%#%%************+++++*********%%%%##%%%%%%%%%%%****++++...................
**************%###%%****%#%%%%%%%%%%%%%%%%%%%%%%###################################%%%%%%%#%%#%%%*************++++++++********%%%%%%%########%%%%****+++...................
*******************%##**%%%%%%%%%%%%%%%%%%%%%%%%###################################%%%%%%%%%%%%%%***%%%%******+++++++*********%%%%%%##########%%%%***++**#*................
***********************%%%%%%%##%#%%#%%%%####%%%###################################%%%%%%%%%%%%##%************++++++++*********%%%%%%%######%%#%%****++*%**++..............
******************%%%%%%*%%%%%%%%%%%%%%########%%#################################%%%%%%%%%%%%%%%*************+++++++++**********%%%%%%%%%%%%%%%**%#%##**%%%##**+..........
%%%%%%%%%%*******%%####%%%%%%%%%%%%%%%%#######%%%%##############################%%%%%%%%%%%%%%%%*************++++++++++++************************++++**##*++++.............
%%%%%%%%%%%%%%%***%%%%%***%%%%%%%%%%%%%%%%%%%%%%%%%%%#########################%%%%%%%%%%%%%%%%%**************++++++++++++++++****************+++++****%%%%%*++.............
%%%%#%%%%%%%%%%%%*%********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%##################%%%%%%%%%%%%%%%%%%%%**************++++++++++++++++++++++++++++++++++++++***%%###%**+.............
##############%%%%%***%*****%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************++++++++++++.+++++++++++++++++++......++++*****#*%*.............
############%%%%%%%%%*********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%***************++++++++++++.................................+*%%*++*............
############%%%%%%%%************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%****************++++++++++++....................................*#+...............
############%%%%%%%%***************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%******************+++++++++++++......................................................
##########%%%%%%%%%*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%********************+++++++++++++........................................................
%%%%#%%%%%%%%%%%%%*************************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**********************++++++++++++++.........................................................
%%%%%%%%%%%%%%%%**********************************%%%%%%%%%%%%%%%%%%%%%***************************+++++++++++++++..........................................................
%%%%%%%%%%%%%***********************************************************************************+++++++++++++++............................................................
*%%%*****************************************************************************************+++++++++++++++++.............................................................
******************************************************************************************++++++++++++++++++...............................................................
****************+*********************************************************************++++++++++++++++++++.................................................................
***********++++++++++*************************************************************++++++++++++++++++++++...................................................................
++++++++++++++++++++++++++***************************************************+++++++++++++++++++++++++.....................................................................
++++++++++++++++++++++++++++++++***************************************+++++++++++++++++++++++++++++.......................................................................
+++++++++++++++++++++++++++++++++++++++++++*****************+++++++++++++++++++++++++++++++++++++..........................................................................
*******************++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++............................................................................
**************************++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++...............................................................................
*****%#***********************+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++..................................................................................

......%#%%*+++*%*%%#%%*#***%%*******++++++++........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**%%%%%%%%%%%%************
.........+....++++++***%%#%%%%%%%****+++++.......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**%####%%%*****************
.................++***%%%#####%%%%****++++...+++++++++++++++++++++++++++++++++++++++++*++++++++++++++++++++++++++++++++++++++++++++++++++++++****%%%#%%%*******************
.................+++**%%%%###%%%%%****++++++++++++++++++++++++++++++++++++++++++++++*%*%++++++++++++++++++++++++++++++++++++++++++++++********#***%##%%********************
..................+++****%%%%%%******+++++++++++++++++++++++++++++++++++++++++++++%%***++++++++++++++++++++++++++++++++++++++++*******************%%%%**********%**********
....................+++++*%#%*#%%%%%#**+++++++++++*++++++++%++++++++++++++++++++++#*+++++++++++++++++++++++++++++++++++++************************%**%%%%****%%#%%%%***%****
......................+++++++**%####%**+++++++*+*+%******+*%%*********++++++++++++++*%%+++++++++++++++++++++++++++++************************************%******%%##%#%%%***
.............................++****%*%##%**+#++*%%*%####%%%#%***%%%%%*******++++****%%%#*%+++++++++++++++++++++**************************************************%%%%#%%%%%
...........................+++++++%++++++++++++++**%%%%%%*%##%%%%%#%%%%%%%****#%%%%%%##%*******************#****************************************************%%%%######%
.........................++++++++++++++++++++++++++******%%%%%########%%%%%%*%%%%######%%**************#*%%****************************************************#%%%%######%
......................++++++++++++++++++++++++++++++****%%%%%##########%%%%%%%%%##%%%%%%%*************%%*******************************************************%%%%%%%%%%%#
....................++++++++++++++++++++++++++++++++*****%%%%%#######%%####%%%%##%%%%%%%*************%**********************************************************%%%%%%%%%%%
.................+++++++++++++++++++++++++++++++++++*****%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%#%%%%%%%%******************************************%%%%%%%%%%%%%%%##
...............++++++++++++++++++++++++++++++++++++++*****#*%%%%%%%%%%%%%%%%%%%#####%%%%#%%%%%%%%%%%####%%%%%%%%%%%%%%%**********%*******************%#%%%%%%%%%#%#%%%#####
............++++++++++++++++++++++++++++++++++++++++++***********%%%%%%%%%%%%%%%###########%%%%%%%%%###%%%%%#%%%%%%%%%%%%%%%%**%%#****************%%%%%%%%%%%##%%##########
..........+++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%%###################%%%%%%%%#%%%%%%%%%%%%%%%%%%%%%%%#%%*************%%%%%%%%%%%%%%%%%###########
........++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%#%################################%%%%%%##%%%%%%%%%%%%%%%%%%%%#%**##%%%%%%%%%%%%%%%%%%#############
......++++++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%################################%#%%%%%%%%%%%%%%%%%%%%%%%%#######%#%%%%%#%%%%%%%%##############
....+++++++++++++++++++++++++++++++++++++++++++**************%#%%%%%#%%%%%%#####################################%%%%%%%%%%%%%%%%%####%######%%%%%%%%%##%%%%%###############
.++++++++++++++++++++++++++++++++++++++++++++**************%%%%%%%####%%%%%######################################%%%%%%%#%%%%%%%%%%%%############%%######%%################
++++++++++++++++++++++++++++++++++++++++++++****%*********%%%%%%%%##%%%%###########################################%%%%%%%%######%%%#######################################
++++++++++++++++++++++++++++++++++++++++++******%#%%****%%%%##%####%%%###############################################%%%%%%%###############################################
+++++++++++++++++++++++++++++++++++++++++********%%###%%%%%%%%%%%%%%%%%%###################################################################################################
++++++++++++++++++++++++++++++++++++++++**************%%%%%%%%%%%%%%%%%%%##################################################################################################
+++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%%%%%%###################################################################################################
++++++++++++++++++++++++++++++++++++++***************%%%%%%%%%%%%%%%%%##%##################################################################################################
+++++++++++++++++++++++++++++++++++++****************%%%%%%%%%%%%%#%%%%%%%#################################################################################################
++++++++++++++++++++++++++++++++++++****************%%%%%%%%%%%%%%%%%%%%%%%################################################################################################

***[b1e3] translation-task}

[translation:info] RTyping...
[b1e3] {translation-task
starting rtype_lltype
**
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict key
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict value
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict key
[rtyper:WARNING] SomePBC(can_be_None=True, const=None, subset_of=None) can be null, but forcing non-null in dict value
********%%%%%%%%%################%%%%%%%%%%***********++++++++*******%%%%%%
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict key
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict value
********%%%%%%%%%################%%%%%%%%%%***********++++++++*******%%%%%%%%#######%#%%%%*****++++++....................................+*%*%%%##%%*+.....................
********%%%%%%%%%#################%%%%%%%%%%******%****+++++++********%%%%#%%%%%%%%%%%%%%******++++++++++++++++++++++++++++++++++++++++%%##%**+*****+++....................
********%%%%%%%%%%#################%%%%%%%%%***********+++++++%**
[rtyper:WARNING] SomeUnicodeString() can be null, but forcing non-null in dict key
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict value
********%%%%%%%%%%#################%%%%%%%%%***********+++++++%*****%%%%%#%%%%%%%%%%%%%*******++++++++++++++++++++++++++++++++++++++++*%*****+++++++++++++++++++++.........
********%%%%%%%%%%%############%%%%%%%%##%%%%%%%%%%%*****++++++**%%#%#####%%%%%%%************+++++++++++++++++++++++++++++++++++++++%%%*+++++++++++++++++++++++++++++++++++
*********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%###%%%%%%****++++***%%%%%
[rtyper] specializing: 10000 / 198430 blocks   (5%)
*********%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%%###%%%%%%****++++***%%%%%%%%%%%**************++++++++++++++++++++++++++++++++++++++++*#%+++++++++++++++++++++++++++++++++++++
***********%%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%#%########%%%%*****+++*%%##%%%%%**************++++++++++++++++++++++++++++++++++++++++++++*++++++++++++++++++++++++++++++++++++++
+************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###
[rtyper] specializing: 20100 / 200071 blocks   (10%)
+************%%%%%%%%%%%%%%%%%%%%%[f2fd] translation-task}

[Timer] Timings:
[Timer] annotate                       --- 435.1 s
[Timer] rtype_lltype                   --- 167.1 s
[Timer] ==========================================
[Timer] Total:                         --- 602.1 s
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/goal/translate.py", line 317, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/driver.py", line 733, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/tool/taskengine.py", line 114, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/driver.py", line 284, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/translator/driver.py", line 351, in task_rtype_lltype
[translation:ERROR]     rtyper.specialize(dont_simplify_again=True)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 207, in specialize
[translation:ERROR]     self.specialize_more_blocks()
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 250, in specialize_more_blocks
[translation:ERROR]     self.specialize_block(block)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 404, in specialize_block
[translation:ERROR]     self.gottypererror(e, block, hop.spaceop, newops)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 402, in specialize_block
[translation:ERROR]     self.translate_hl_to_ll(hop, varmapping)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 531, in translate_hl_to_ll
[translation:ERROR]     resultvar = hop.dispatch()
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 759, in dispatch
[translation:ERROR]     return translate_meth(self)
[translation:ERROR]    File "<58719-codegen /home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py:601>", line 4, in translate_op_getattr
[translation:ERROR]     return r_arg1.rtype_getattr(hop)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rpbc.py", line 391, in rtype_getattr
[translation:ERROR]     return hop.inputconst(hop.r_result, hop.s_result.const)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/rmodel.py", line 393, in inputconst
[translation:ERROR]     value = reqtype.convert_const(value)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/lltypesystem/rdict.py", line 245, in convert_const
[translation:ERROR]     llkey = r_key.convert_const(dictkey)
[translation:ERROR]    File "/home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/lltypesystem/rstr.py", line 100, in convert_const
[translation:ERROR]     raise TyperError("not a str: %r" % (value,))
[translation:ERROR]  TyperError: not a str: u'KEY_END'
[translation:ERROR] .. (pypy.interpreter.baseobjspace:710)new_interned_w_str
[translation:ERROR] .. block at 52 with 1 exits
[translation:ERROR] .. v1735 = getattr(v1734, ('interned_strings'))
[translation] start debugger...
> /home/ab/src/pypy-pypy-4b60269153b5/rpython/rtyper/lltypesystem/rstr.py(100)convert_const()
-> raise TyperError("not a str: %r" % (value,))
(Pdb+) 

From tracker at bugs.pypy.org  Tue Apr  9 22:04:08 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 09 Apr 2013 20:04:08 +0000
Subject: [pypy-issue] [issue1444] own-win-x86 buildbot crahs causes
	subsequent tests to fail
In-Reply-To: <1365537848.33.0.0686552296719.issue1444@bugs.pypy.org>
Message-ID: <1365537848.33.0.0686552296719.issue1444@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

Looking at the log from http://buildbot.pypy.org/builders/own-win-x86-
32/builds/27/steps/shell_7/logs/stdio I see the text below partway into the 
tests. It seems the jit/backend/test/test_zll_stress.py crashes pypy, and from 
there the test run does not recover. When running offline on my machine I see 
the crash (which opens a dialog box that I need to close), then tests continue 
consecutively with relatively few failures. Any ideas why the output is a bit 
garbled and then test_basic has nothing but failures?

jit/backend/test/calling_convention_test.py F.....
jit/backend/test/test_detect_cpu.py ...
jit/backend/test/test_ll_random.py .
jit/backend/test/test_model.py .
jit/backend/test/test_random.py .
jit/backend/test/test_zll_stress.py ++ starting 
jit/backend/x86/test/test_assembler.py [31 started in total]
__ jit/backend/x86/test/test_assembler.py [31 done in total] __________________
inserting into sys.path: C:\Users\buildbot\pypy_stuff\pypy\own-win-x86-32\build

============================= test session starts ==============================
platform win32 -- Python 2.7.3[pypy-2.0.0-beta] -- pytest-2.2.4.dev2
pytest-2.2.4.dev2 from C:\Users\buildbot\pypy_stuff\pypy\own-win-x86-
32\build\pytest.pyc
collecting ... collected 9 items

jit/backend/x86/test/test_assembler.py .........

=========================== 9 passed in 5.38 seconds ===========================
++ starting jit/backend/x86/test/test_basic.py [32 started in total]
__ jit/backend/x86/test/test_basic.py [32 done in total] ______________________
inserting into sys.path: C:\Users\buildbot\pypy_stuff\pypy\own-win-x86-32\build

============================= test session starts ==============================
platform win32 -- Python 2.7.3[pypy-2.0.0-beta] -- pytest-2.2.4.dev2
pytest-2.2.4.dev2 from C:\Users\buildbot\pypy_stuff\pypy\own-win-x86-
32\build\pytest.pyc
collecting ... collected 171 items

jit/backend/x86/test/test_basic.py 
Fss.....FFFFFFFFFFFFFF.......FFFFFFFFFF.F..F.....F....FFFFFFFFF.F.F.F.FFF.F..FFF
FFFFFFF.F...F.FFFFFFFFFF..FFFFFFFFFFFF.FFFFFFFFFFFF..FFFFFFFFF..sFFFFFFsFFFFFFFF
FFFFF.s....

=================================== FAILURES ===================================

----------
messages: 5550
nosy: mattip, pypy-issue
priority: bug
status: unread
title: own-win-x86 buildbot crahs causes subsequent tests to fail

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1444>
________________________________________

From tracker at bugs.pypy.org  Tue Apr  9 22:26:28 2013
From: tracker at bugs.pypy.org (Florian Apolloner)
Date: Tue, 09 Apr 2013 20:26:28 +0000
Subject: [pypy-issue] [issue1445] Major regression since 2.0 beta
In-Reply-To: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>
Message-ID: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>


New submission from Florian Apolloner <florian at apolloner.eu>:

Alex asked me to open the bug, I am myself not 100% sure it's pypy's fault --
but I am somewhat out of debugging options. Django's testsuite gets a lot of
memory allocation errors under pypy like:

======================================================================
ERROR: test_complex_app (admin_scripts.tests.ManageValidate)
manage.py validate does not raise an ImportError validating a complex app with
nested calls to load_app
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/florian/sources/django.git/tests/admin_scripts/tests.py", line
1073, in test_complex_app
    out, err = self.run_manage(args)
  File "/home/florian/sources/django.git/tests/admin_scripts/tests.py", line
176, in run_manage
    return self.run_test('./manage.py', args, settings_file)
  File "/home/florian/sources/django.git/tests/admin_scripts/tests.py", line
140, in run_test
    universal_newlines=True).communicate()
  File
"/home/florian/sources/pypy-c-jit-63155-972e776a277f-linux64/lib-python/2.7/subprocess.py",
line 679, in __init__
    errread, errwrite)
  File
"/home/florian/sources/pypy-c-jit-63155-972e776a277f-linux64/lib-python/2.7/subprocess.py",
line 1147, in _execute_child
    self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory


This is on a 64 bit machine with 4 Gig of RAM, once in a while even oom_killer
hits it? I am also seeing segfaults on the ci-server, but those appear to be
fixed with the recent nightlies.

----------
messages: 5551
nosy: apollo13, pypy-issue
priority: critical
status: unread
title: Major regression since 2.0 beta

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1445>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 06:09:14 2013
From: tracker at bugs.pypy.org (Ismael)
Date: Wed, 10 Apr 2013 04:09:14 +0000
Subject: [pypy-issue] [issue1070] Cpython 2.7 is faster than Pypy on program
	using Pickle	and Sqlite
In-Reply-To: <1330238255.79.0.201539943332.issue1070@bugs.pypy.org>
Message-ID: <1365566954.39.0.0942902433069.issue1070@bugs.pypy.org>


Ismael <ismaelgfk at gmail.com> added the comment:

PyPy 63035-bf6aa926c0d9 takes 86s. Python 2.7.3 takes 26s. (both best of 3 runs)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1070>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 13:45:44 2013
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 10 Apr 2013 11:45:44 +0000
Subject: [pypy-issue] [issue1446] translate fail on py3k, windows
In-Reply-To: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>
Message-ID: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

About this failure
http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-
32/builds/929/steps/translate/logs/stdio

The only place WSADuplicateSocket is called is in rsocket.dup
The test_rsoocket.test_dup is skipped in windows.

The function WSADuplicateSocket  is being called with
Unsigned, Unsigned, * Struct WSAPROTOCOL_INFO
instead of Unsigned, Unsigned, * Struct WSAData
Thats as far as I got. I can reach it in a debugger, indeed the graph is for 
WSADuplicateSocket, but why is it being called and how did a WSAPROTOCOL_INFO 
get in there

----------
assignedto: pjenvey
messages: 5553
nosy: mattip, pypy-issue
priority: wish
status: unread
title: translate fail on py3k, windows

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1446>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 13:51:08 2013
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 10 Apr 2013 11:51:08 +0000
Subject: [pypy-issue] [issue1446] translate fail on py3k, windows
In-Reply-To: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>
Message-ID: <1365594668.55.0.243186815951.issue1446@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

sorry, the correct test is test_rsocket.test_c_dup and indeed reproduces the 
error, so I will look in to fixing

----------
assignedto: pjenvey -> mattip
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1446>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 13:52:18 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 10 Apr 2013 11:52:18 +0000
Subject: [pypy-issue] [issue1446] translate fail on py3k, windows
In-Reply-To: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>
Message-ID: <1365594738.47.0.280592584763.issue1446@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

But... WSADuplicateSocket needs a WSAPROTOCOL_INFO (I just checked on msdn).
WSAData is used for WSAStartup.

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1446>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 15:28:49 2013
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 10 Apr 2013 13:28:49 +0000
Subject: [pypy-issue] [issue1446] translate fail on py3k, windows
In-Reply-To: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>
Message-ID: <1365600529.76.0.93308370086.issue1446@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

indeed, _rsocket_rffi correctly has 
WSADuplicateSocket = external('WSADuplicateSocket', 
                             [socketfd_type, rwin32.DWORD,
                              lltype.Ptr(WSAPROTOCOL_INFO)],
                              rffi.INT)
and rsocket.py has
    def dup(fd):
        with lltype.scoped_alloc(_c.WSAData, zero=True) as info:
            if _c.WSADuplicateSocket(fd, rwin32.GetCurrentProcessId(), info):
                 ...

That should be easy to fix then. Thanks!

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1446>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 10 17:50:57 2013
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 10 Apr 2013 15:50:57 +0000
Subject: [pypy-issue] [issue1446] translate fail on py3k, windows
In-Reply-To: <1365594344.01.0.665214658785.issue1446@bugs.pypy.org>
Message-ID: <1365609057.7.0.0404151365903.issue1446@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

Fixed on default, changeset 1b764ce510d6, using ...A versions of WSA functions

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1446>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 11 02:27:45 2013
From: tracker at bugs.pypy.org (Aaron Meurer)
Date: Thu, 11 Apr 2013 00:27:45 +0000
Subject: [pypy-issue] [issue1447] SymPy tests use too much memory
In-Reply-To: <1365640065.75.0.999483427337.issue1447@bugs.pypy.org>
Message-ID: <1365640065.75.0.999483427337.issue1447@bugs.pypy.org>


New submission from Aaron Meurer <asmeurer at gmail.com>:

(The corresponding SymPy issue is https://code.google.com/p/sympy/issues/detail?
id=3668)

The SymPy test suite (i.e., clone http://github.com/sympy/sympy and run `bin/test` 
with PyPy) uses way too much memory with PyPy. On my Mac, the virtual memory goes 
up to several GB before the tests are finished, according to Activity Monitory. On 
an old Linux laptop with no memory, the tests barely start before they exit with 
MemoryError.

I cut the tests short after about 1GB was used according to Activity Monitor 
(right after the core tests were finished), and ran a gc dump on the process. The 
result is at https://gist.github.com/asmeurer/5359631.

----------
messages: 5558
nosy: asmeurer, pypy-issue
priority: performance bug
status: unread
title: SymPy tests use too much memory

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1447>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 11 07:37:09 2013
From: tracker at bugs.pypy.org (James Lan)
Date: Thu, 11 Apr 2013 05:37:09 +0000
Subject: [pypy-issue] [issue1448] pytest on default does not support
	multi-inherited classes
In-Reply-To: <1365658629.35.0.880645955713.issue1448@bugs.pypy.org>
Message-ID: <1365658629.35.0.880645955713.issue1448@bugs.pypy.org>


New submission from James Lan <jameslan at gmail.com>:

On default branch, pytest is 2.2.4.dev2, which does not support multi-inherited 
classes, so that test cases for both jvm and cli backend can not run.

On pytest-update branch, pytest is 2.3.5dev6, fixed this issue. Please merge it 
back to default.

BTW, will it be better to use a released version of pytest instead of dev?

----------
messages: 5559
nosy: jameslan, pypy-issue
priority: critical
status: unread
title: pytest on default does not support multi-inherited classes

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1448>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 11 08:11:53 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 11 Apr 2013 06:11:53 +0000
Subject: [pypy-issue] [issue1448] pytest on default does not support
	multi-inherited classes
In-Reply-To: <1365658629.35.0.880645955713.issue1448@bugs.pypy.org>
Message-ID: <1365660713.78.0.0498836720374.issue1448@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Do you have a precise example? Which tests are failing?

----------
nosy: +amaury
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1448>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 11 08:23:18 2013
From: tracker at bugs.pypy.org (James Lan)
Date: Thu, 11 Apr 2013 06:23:18 +0000
Subject: [pypy-issue] [issue1448] pytest on default does not support
	multi-inherited classes
In-Reply-To: <1365658629.35.0.880645955713.issue1448@bugs.pypy.org>
Message-ID: <1365661398.97.0.642957620569.issue1448@bugs.pypy.org>


James Lan <jameslan at gmail.com> added the comment:

pypy pypy/test_all.py --collectonly rpython/translator/jvm/test/test_constant.py

on default, it finds 0 test cases,
while on pytest-update, it finds 18 cases.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1448>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 00:44:22 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 11 Apr 2013 22:44:22 +0000
Subject: [pypy-issue] [issue1449] round_up_for_allocation from llarena is
	not inlined
In-Reply-To: <1365720262.57.0.933676145763.issue1449@bugs.pypy.org>
Message-ID: <1365720262.57.0.933676145763.issue1449@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

Seems that round_up_for_allocation is not inlined for reasons unknown. It ends up 
a bit everywhere in the C source (and gcc can't inline it either because of 
cross-file access). Might be a performance problem.

----------
messages: 5562
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: round_up_for_allocation from llarena is not inlined

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1449>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 13:20:53 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Apr 2013 11:20:53 +0000
Subject: [pypy-issue] [issue1445] Major regression since 2.0 beta
In-Reply-To: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>
Message-ID: <1365765653.22.0.253726726315.issue1445@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Try, as root:

echo 1 > /proc/sys/vm/overcommit_memory

or maybe 2, this should fix it

another issue is why pypy eats so much RAM, but well. Another question

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1445>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 14:36:56 2013
From: tracker at bugs.pypy.org (Geoffrey Sneddon)
Date: Fri, 12 Apr 2013 12:36:56 +0000
Subject: [pypy-issue] [issue1450] MemoryError (from JIT?) when built with
	GCC 4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>


New submission from Geoffrey Sneddon <geoffers at gmail.com>:

Given 2.0b2 patched with 4943ac67b80 and 33015de (so that it builds at all with 
4.8), MemoryErrors are hit frequently.

`virtualenv -p pypy env` produces a MemoryError (virtualenv 1.9.1).

Trying with shadowstack, a virtualenv can be created. However, attempting to 
self-host still fails (~instantly, <1s). arigato suggested trying with JIT off, 
and this appears to be building fine (though is still going, will report back).

----------
messages: 5564
nosy: gsnedders, pypy-issue
priority: bug
release: 2.0
status: unread
title: MemoryError (from JIT?) when built with GCC 4.8

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 16:02:08 2013
From: tracker at bugs.pypy.org (Geoffrey Sneddon)
Date: Fri, 12 Apr 2013 14:02:08 +0000
Subject: [pypy-issue] [issue1450] MemoryError (from JIT?) when built with
	GCC 4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1365775328.16.0.00782063831159.issue1450@bugs.pypy.org>


Geoffrey Sneddon <geoffers at gmail.com> added the comment:

So trying to self-host with JIT off gave:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/translator/goal/translate.py", line 317, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/translator/driver.py", line 733, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip
())
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/translator/tool/taskengine.py", line 114, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/translator/driver.py", line 284, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/translator/driver.py", line 351, in task_rtype_lltype
[translation:ERROR]     rtyper.specialize(dont_simplify_again=True)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 207, in specialize
[translation:ERROR]     self.specialize_more_blocks()
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 250, in specialize_more_blocks
[translation:ERROR]     self.specialize_block(block)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 404, in specialize_block
[translation:ERROR]     self.gottypererror(e, block, hop.spaceop, newops)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 402, in specialize_block
[translation:ERROR]     self.translate_hl_to_ll(hop, varmapping)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 531, in translate_hl_to_ll
[translation:ERROR]     resultvar = hop.dispatch()
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rtyper.py", line 759, in dispatch
[translation:ERROR]     return translate_meth(self)
[translation:ERROR]    File "<58720-codegen /home/gsnedders/Downloads/AUR/pypy/
src/pypy-pypy-4b60269153b5/rpython/rtyper/rtyper.py:601>", line 4, in 
translate_op_getattr
[translation:ERROR]     return r_arg1.rtype_getattr(hop)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rpbc.py", line 391, in rtype_getattr
[translation:ERROR]     return hop.inputconst(hop.r_result, hop.s_result.const)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/rmodel.py", line 393, in inputconst
[translation:ERROR]     value = reqtype.convert_const(value)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/lltypesystem/rdict.py", line 245, in 
convert_const
[translation:ERROR]     llkey = r_key.convert_const(dictkey)
[translation:ERROR]    File "/home/gsnedders/Downloads/AUR/pypy/src/pypy-
pypy-4b60269153b5/rpython/rtyper/lltypesystem/rstr.py", line 100, in 
convert_const
[translation:ERROR]     raise TyperError("not a str: %r" % (value,))
[translation:ERROR]  TyperError: not a str: u'KEY_END'
[translation:ERROR] .. (pypy.interpreter.baseobjspace:710)new_interned_w_str
[translation:ERROR] .. block at 3 with 2 exits(last_exception)
[translation:ERROR] .. v2753 = getattr(self_104, ('interned_strings'))

So that doesn't appear to work either?

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 16:13:22 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 12 Apr 2013 14:13:22 +0000
Subject: [pypy-issue] [issue1450] MemoryError (from JIT?) when built with
	GCC 4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1365776002.89.0.0869368200613.issue1450@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

What is this "KEY_END"? I found this name in curses/has_key.py.
Does pypy freeze the curses module?
And how does it become a unicode string?

https://bugs.pypy.org/issue1450 has the same error.

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 12 21:48:41 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Apr 2013 19:48:41 +0000
Subject: [pypy-issue] [issue1450] MemoryError (from JIT?) when built with
	GCC 4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1365796121.35.0.478324834443.issue1450@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

It's already fixed (the u'KEY_END'), just update your pypy

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 13 16:04:10 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 13 Apr 2013 14:04:10 +0000
Subject: [pypy-issue] [issue1451] Strange error message in numpypy
In-Reply-To: <1365861850.43.0.055954570643.issue1451@bugs.pypy.org>
Message-ID: <1365861850.43.0.055954570643.issue1451@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

>>> numpypy.dtype((1,2))
TypeError: data type <W_SpecialisedTupleObject_ii object at 0x7fb226388240> not 
understood

It's probably a good idea to use space.repr() instead of the interp-level %r 
formatting.

----------
messages: 5568
nosy: amaury, pypy-issue
priority: bug
status: unread
title: Strange error message in numpypy

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1451>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 13 20:39:57 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 13 Apr 2013 18:39:57 +0000
Subject: [pypy-issue] [issue1449] round_up_for_allocation from llarena is
	not inlined
In-Reply-To: <1365720262.57.0.933676145763.issue1449@bugs.pypy.org>
Message-ID: <1365878397.57.0.775116946071.issue1449@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

That one seems to be fixed

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1449>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 13 23:01:03 2013
From: tracker at bugs.pypy.org (Geoffrey Sneddon)
Date: Sat, 13 Apr 2013 21:01:03 +0000
Subject: [pypy-issue] [issue1450] MemoryError from JIT when built with GCC
	4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1365886863.83.0.685534696888.issue1450@bugs.pypy.org>


Geoffrey Sneddon <geoffers at gmail.com> added the comment:

Trying something up to date it does indeed build with JIT disabled, so would 
appear to purely be a JIT bug.

----------
title: MemoryError (from JIT?) when built with GCC 4.8 -> MemoryError from JIT when built with GCC 4.8

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 14 07:01:45 2013
From: tracker at bugs.pypy.org (Donald Stufft)
Date: Sun, 14 Apr 2013 05:01:45 +0000
Subject: [pypy-issue] [issue1452] No __name__ attribute on CFFI exposed
	functions
In-Reply-To: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>
Message-ID: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>


New submission from Donald Stufft <donald.stufft at gmail.com>:

Functions exposed via CFFI do not have a __name__ attribute (and possibly
others?) this means that if you attempt to use functools.wraps on a CFFI exposed
function you'll get an exception:

    AttributeError: cdata 'int(*)(unsigned char *, unsigned char *, unsigned
long long, unsigned char *, unsigned char *)' has no attribute '__name__'

This does however work fine in CPython (2.x and 3.x).

----------
messages: 5571
nosy: dstufft, pypy-issue
priority: bug
release: 2.0
status: unread
title: No __name__ attribute on CFFI exposed functions

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1452>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 14 07:08:45 2013
From: tracker at bugs.pypy.org (Donald Stufft)
Date: Sun, 14 Apr 2013 05:08:45 +0000
Subject: [pypy-issue] [issue1452] No __name__ attribute on CFFI exposed
	functions
In-Reply-To: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>
Message-ID: <1365916125.44.0.375957267661.issue1452@bugs.pypy.org>


Donald Stufft <donald.stufft at gmail.com> added the comment:

Just in case anyone else runs into this issue before it's fixed, here's how I
worked around it:
https://github.com/dstufft/pynacl/commit/c9bd64c3198692867c127d0278c5a13d7cbc7a23

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1452>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 14 07:13:15 2013
From: tracker at bugs.pypy.org (Donald Stufft)
Date: Sun, 14 Apr 2013 05:13:15 +0000
Subject: [pypy-issue] [issue1452] No __name__ attribute on CFFI exposed
	functions
In-Reply-To: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>
Message-ID: <1365916395.65.0.937654878623.issue1452@bugs.pypy.org>


Donald Stufft <donald.stufft at gmail.com> added the comment:

Just in case anyone else runs into this issue before it's fixed, here's how I
worked around it:
https://github.com/dstufft/pynacl/commit/c79bb96d5f86edb6554d945f17c46e527b336259

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1452>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 14 15:48:03 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Apr 2013 13:48:03 +0000
Subject: [pypy-issue] [issue1070] Cpython 2.7 is faster than Pypy on program
	using Pickle	and Sqlite
In-Reply-To: <1330238255.79.0.201539943332.issue1070@bugs.pypy.org>
Message-ID: <1365947283.32.0.723108426664.issue1070@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

I think it's annoying but known.  Both cPickle and sqlite are written in pure
Python, so we can't hope to beat CPython, where they are written in C.  The best
we can hope is to get close to CPython performance.

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1070>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 14 22:45:58 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Apr 2013 20:45:58 +0000
Subject: [pypy-issue] [issue1452] No __name__ attribute on CFFI exposed
	functions
In-Reply-To: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>
Message-ID: <1365972358.04.0.178099780597.issue1452@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Ah bah.  No, it doesn't work completely in CPython either; it only works with
functions gotten directly from verify().  It wouldn't work with functions from
dlopen() or callbacks or just any other cdata that happens to be callable.

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1452>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 01:36:15 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Sun, 14 Apr 2013 23:36:15 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>


New submission from Brian Kearns <bdkearns at gmail.com>:

this script segfaults in about one second on pypy 2.0b2 and latest nightly pypy-
c-jit-63352-c547e2d2e237-linux64

these versions are fairly unusable

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

import _sqlite3
import thread
import time

def f():
    con = _sqlite3.connect(':memory:')
    while 1:
        con.execute("select 42")

thread.start_new_thread(f, ())
thread.start_new_thread(f, ())

while 1:
    time.sleep(1)

----------
messages: 5576
nosy: bdk, pypy-issue
priority: critical
status: unread
title: segfault with simple script on 2.0b2+

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 01:58:24 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Sun, 14 Apr 2013 23:58:24 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1365983904.44.0.82640137069.issue1453@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

or, alternatively, if you prefer (happens to give nonsense rather than a 
segfault):

import os
import thread
import time

def f():
    while 1:
        os.getlogin()

thread.start_new_thread(f, ())
thread.start_new_thread(f, ())

while 1:
    time.sleep(1)

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 12:40:06 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 15 Apr 2013 10:40:06 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366022406.48.0.634349708066.issue1453@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Cool for a small thing. I know what's going on, fighting that.

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 17:07:45 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 15 Apr 2013 15:07:45 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366038465.9.0.918271255787.issue1453@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Fixed in a9073815e95a and a few other ones

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 19:16:35 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 15 Apr 2013 17:16:35 +0000
Subject: [pypy-issue] [issue1452] No __name__ attribute on CFFI exposed
	functions
In-Reply-To: <1365915705.27.0.795940594086.issue1452@bugs.pypy.org>
Message-ID: <1366046195.57.0.529730672569.issue1452@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in 237b4e412bd5.

----------
priority: bug -> wish
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1452>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 19:17:08 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Mon, 15 Apr 2013 17:17:08 +0000
Subject: [pypy-issue] [issue1454] ctypes: __int__ not called for ctype
	subclass
In-Reply-To: <1366046228.36.0.641821360614.issue1454@bugs.pypy.org>
Message-ID: <1366046228.36.0.641821360614.issue1454@bugs.pypy.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

>>>> from ctypes import c_uint
>>>> class Foo(c_uint):
....     def __int__(self):
....         return 42
.... 
>>>> int(Foo())
CPython:
42
PyPy:
ValueError: invalid literal for int() with base 10: ''

maybe related:

int(c_uint()) also fails with the same error

----------
messages: 5581
nosy: lazka, pypy-issue
priority: bug
status: unread
title: ctypes: __int__ not called for ctype subclass

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1454>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 19:20:19 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 15 Apr 2013 17:20:19 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366046419.21.0.846683492479.issue1453@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

When running the os.getlogin() example repeatedly, it failed once: the
os.getlogin() appeared to raise OSError: [Errno 2] No such file or directory.

----------
nosy: +arigo
status: resolved -> testing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 15 20:57:02 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Mon, 15 Apr 2013 18:57:02 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366052222.83.0.395296640246.issue1453@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

also, even after the 'fix', both the sqlite and getlogin versions still raise 
bogus exceptions fairly quickly. if you don't see them, increase num threads. 
running under cpython, both scripts run fine 'indefinitely' without exception.

$ ~/pypy-c-jit-63380-237b4e412bd5-linux64/bin/pypy testt.py
>From thread 139872532240128 started by <function f at 0x00007f369dd004d0>:
Traceback (most recent call last):
  File "testt.py", line 8, in f
    con.execute("select 42")
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 579, in execute
    return cur.execute(*args)
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 887, in wrapper
    return func(self, *args, **kwargs)
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 1033, in execute
    return self.__execute(False, sql, [params])
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 982, in __execute
    self.__statement = self.__connection._statement_cache.get(sql)
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 401, in get
    stat = Statement(self.connection, sql)
  File "/home/ubuntu/pypy-c-jit-63380-237b4e412bd5-
linux64/lib_pypy/_sqlite3.py", line 1192, in __init__
    raise self.__con._get_exception(ret)
ProgrammingError: unknown error

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 00:00:22 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 15 Apr 2013 22:00:22 +0000
Subject: [pypy-issue] [issue1454] ctypes: __int__ not called for ctype
	subclass
In-Reply-To: <1366046228.36.0.641821360614.issue1454@bugs.pypy.org>
Message-ID: <1366063222.65.0.849388488582.issue1454@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

It's somehow related to the __buffer__ method:

class Foo(object):
    def __int__(self):
        return 42
    def __buffer__(self):
        return buffer("12.34")

int(Foo())
Fails with ValueError: invalid literal for int() with base 10: '12.34'

...in CPython, string and buffers are processed after __int__; pypy should do the same.

tag:easy

----------
nosy: +amaury
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1454>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 01:54:54 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Mon, 15 Apr 2013 23:54:54 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366070094.66.0.0456374954305.issue1453@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

so now, with pypy-c-jit-63387-8da09b1dbb90-linux64, this script never reaches 
'done', and segfaults on pressing ctrl-c

import os
import thread

def f():
    while 1:
        os.getlogin()

for i in range(5):
    thread.start_new_thread(f, ())

print 'done'

----------
status: testing -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 02:36:28 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Tue, 16 Apr 2013 00:36:28 +0000
Subject: [pypy-issue] [issue1455] fixes "no _curses or _minimal_curses" on
	netbsd
In-Reply-To: <1366072588.53.0.0350151984696.issue1455@bugs.pypy.org>
Message-ID: <1366072588.53.0.0350151984696.issue1455@bugs.pypy.org>


New submission from YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp>:

this patch fixes "no _curses or _minimal_curses" error i got when
building pypy with pypy on netbsd.

on netbsd, "import _curses" doesn't work because:

- unlike rpython/translator/platform, it doesn't pass enough flags to
  a compiler.  eg. LOCALBASE stuff.
- on typical installation (pkgsrc), ncurses.h is available as ncurses/ncurses.h
- ncurses configuration mismatch? (i'm not sure)
  eg. chtype is int, not long.

and cffi.verify ends up raising VerifycationError.

----------
messages: 5586
nosy: pypy-issue, yamt
priority: bug
status: unread
title: fixes "no _curses or _minimal_curses" on netbsd

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1455>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 02:37:32 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Tue, 16 Apr 2013 00:37:32 +0000
Subject: [pypy-issue] [issue1455] fixes "no _curses or _minimal_curses" on
	netbsd
In-Reply-To: <1366072588.53.0.0350151984696.issue1455@bugs.pypy.org>
Message-ID: <1366072652.67.0.0721501232118.issue1455@bugs.pypy.org>


YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp> added the comment:

a patch.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1455>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 22:10:06 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 16 Apr 2013 20:10:06 +0000
Subject: [pypy-issue] [issue1456] thread checkinterval and its pypy
	modifications don't	work well
In-Reply-To: <1366143006.94.0.213494673794.issue1456@bugs.pypy.org>
Message-ID: <1366143006.94.0.213494673794.issue1456@bugs.pypy.org>


New submission from Brian Kearns <bdkearns at gmail.com>:

between pypy default checkinterval of 10000 * 100 = 1M and the jit adapted tick 
counter that can decrease to 1, threads can end up not releasing the gil for a 
long time. this script takes forever to run/start additional threads on pypy on 
linux64. on osx, behavior seems different and more like cpython, for whatever 
reason (maybe another bug?)

import os
import thread
import sys

def f():
    while 1:
        os.getlogin()

for i in range(5):
    print i
    thread.start_new_thread(f, ())

print 'done'

----------
messages: 5588
nosy: bdk, pypy-issue
priority: performance bug
status: unread
title: thread checkinterval and its pypy modifications don't work well

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1456>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 16 22:20:32 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 16 Apr 2013 20:20:32 +0000
Subject: [pypy-issue] [issue1456] thread checkinterval and its pypy
	modifications don't	work well
In-Reply-To: <1366143006.94.0.213494673794.issue1456@bugs.pypy.org>
Message-ID: <1366143632.17.0.774877670729.issue1456@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

also note this script only demonstrates with a latest nightly that doesn't release 
the GIL in getlogin, may want to replace with another tight loop with small num 
opcodes but lengthy time to exhibit.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1456>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 17 11:21:52 2013
From: tracker at bugs.pypy.org (Alexander)
Date: Wed, 17 Apr 2013 09:21:52 +0000
Subject: [pypy-issue] [issue1457] multiprocessing sample hangs
In-Reply-To: <1366190512.48.0.159793532971.issue1457@bugs.pypy.org>
Message-ID: <1366190512.48.0.159793532971.issue1457@bugs.pypy.org>


New submission from Alexander <alexander_k2004 at ukr.net>:

I've tested multiprocessing sample from (http://bugs.python.org/issue5000) both in 
CPython and PyPy and found. That CPython executes well in 40-50 seconds on my 
PC(Windows 7, 8 cores) the same sample looks hanging in PyPy (it only consumes) 
memory without any result. I've been waiting for 2-3 mins without result.
Thanks in advance

----------
files: test.py
messages: 5590
nosy: AlexKUA, pypy-issue
priority: bug
status: unread
title: multiprocessing sample hangs

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1457>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 13:41:27 2013
From: tracker at bugs.pypy.org (Yaroslav Fedevych)
Date: Thu, 18 Apr 2013 11:41:27 +0000
Subject: [pypy-issue] [issue1458] Translation of a PyPy checkout with an
	older PyPy	checkout fails
In-Reply-To: <1366285287.31.0.637429750128.issue1458@bugs.pypy.org>
Message-ID: <1366285287.31.0.637429750128.issue1458@bugs.pypy.org>


New submission from Yaroslav Fedevych <jaroslaw.fedewicz at gmail.com>:

As of recent year (maybe more), translating a newer pypy checkout with a pypy
built from a less recent checkout fails for me quite reliably with the following
traceback:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/translator/goal/translate.py", line 317, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/driver.py",
line 733, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/translator/tool/taskengine.py", line 114, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/driver.py",
line 284, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/driver.py",
line 464, in task_database_c
[translation:ERROR]     database = cbuilder.build_database()
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/c/genc.py",
line 175, in build_database
[translation:ERROR]     db.complete()
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/translator/c/database.py", line 302, in complete
[translation:ERROR]     nodedef.setup()
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/c/node.py",
line 111, in setup
[translation:ERROR]     self.gcinfo  # force it to be computed
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/c/node.py",
line 33, in __get__
[translation:ERROR]     return self.fget(obj)
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/c/node.py",
line 124, in computegcinfo
[translation:ERROR]     self.db.gcpolicy.struct_setup(self, rtti)
[translation:ERROR]    File "/home/jafd/src/pypy/rpython/translator/c/gc.py",
line 318, in struct_setup
[translation:ERROR]     fptrs = gctransf.special_funcptr_for_type(TYPE)
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/memory/gctransform/framework.py", line 520, in
special_funcptr_for_type
[translation:ERROR]     return self.layoutbuilder.special_funcptr_for_type(TYPE)
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/memory/gctypelayout.py", line 384, in
special_funcptr_for_type
[translation:ERROR]     fptr1, is_lightweight =
self.make_finalizer_funcptr_for_type(TYPE)
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/memory/gctransform/framework.py", line 1239, in
make_finalizer_funcptr_for_type
[translation:ERROR]     [llmemory.Address], lltype.Void)
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/memory/gctransform/transform.py", line 277, in
annotate_finalizer
[translation:ERROR]     fptr = self.annotate_helper(ll_finalizer, ll_args,
ll_result)
[translation:ERROR]    File
"/home/jafd/src/pypy/rpython/memory/gctransform/transform.py", line 261, in
annotate_helper
[translation:ERROR]     assert not self.finished_helpers
[translation:ERROR]  AssertionError

The TYPE equals to
GcStruct pypy.module._ffi.interp_struct.W__StructInstance { super, inst_rawmem,
inst_structdescr, inst_autofree }

ll_finalizer is in pypy/rpython/memory/gctransform/framework.py

Also note that CPython does not ever raise this exception.

Also, I was able to reliably build pypy with a pypy built with a pypy
(...loop...) built with CPython. That is, I wasn't able to produce this when
pypy was translated with an identical version of itself. This reproduces fairly
well, though, when pypy binary is a few commits away from the source it tries to
build.

----------
messages: 5591
nosy: jafd, pypy-issue
priority: bug
status: unread
title: Translation of a PyPy checkout with an older PyPy checkout fails

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1458>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 13:44:19 2013
From: tracker at bugs.pypy.org (Yaroslav Fedevych)
Date: Thu, 18 Apr 2013 11:44:19 +0000
Subject: [pypy-issue] [issue1458] Translation of a PyPy checkout with an
	older PyPy	checkout fails
In-Reply-To: <1366285287.31.0.637429750128.issue1458@bugs.pypy.org>
Message-ID: <1366285459.16.0.704272293998.issue1458@bugs.pypy.org>


Yaroslav Fedevych <jaroslaw.fedewicz at gmail.com> added the comment:

The above traceback is produced by trying to translate today's (as of Apr 18
2013) checkout with a binary built from sources as of April 3, if it ever helps.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1458>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 13:46:53 2013
From: tracker at bugs.pypy.org (Yaroslav Fedevych)
Date: Thu, 18 Apr 2013 11:46:53 +0000
Subject: [pypy-issue] [issue1458] Translation of a PyPy checkout with an
	older PyPy	checkout fails
In-Reply-To: <1366285287.31.0.637429750128.issue1458@bugs.pypy.org>
Message-ID: <1366285613.9.0.65369739407.issue1458@bugs.pypy.org>


Yaroslav Fedevych <jaroslaw.fedewicz at gmail.com> added the comment:

Also, the more exact location of ll_finalizer is framework.py:1235, which reads

        def ll_finalizer(addr):
            v = llmemory.cast_adr_to_ptr(addr, DESTR_ARG)
            ll_call_destructor(destrptr, v, typename)

Hope this helps.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1458>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 17:02:25 2013
From: tracker at bugs.pypy.org (michaelso)
Date: Thu, 18 Apr 2013 15:02:25 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>


New submission from michaelso <pypy at michaelso.com>:

typedef struct message_s{

	short payload_len;

	char sender_addr[4];
	char src_addr[4];

	short id;

} message_s;

msg = ffi.new("struct message_s *")

for i in range (30000):
	msg.sender_asid = 258

CPython is ok. But Pypy crash with segmentation fault 11

Any thought?

It only crash on "short" but not other

----------
messages: 5594
nosy: michaelso, pypy-issue
priority: bug
release: 2.0
status: unread
title: Pypy 2.0 beta 2 with cffi segmentation fault 11

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 17:15:06 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 18 Apr 2013 15:15:06 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366298106.51.0.181899006899.issue1459@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

There was a typo, here is the full script.
It does not crash with "--jit off".


import cffi
ffi = cffi.FFI()
ffi.cdef("""
struct message_s {
    short payload_len;
    char sender_addr[4];
    char src_addr[4];
    short id;
};
""")
msg = ffi.new("struct message_s *")
for i in range(30000):
    msg.id = 258

----------
nosy: +amaury
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 18:22:49 2013
From: tracker at bugs.pypy.org (michaelso)
Date: Thu, 18 Apr 2013 16:22:49 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366302169.01.0.33635283904.issue1459@bugs.pypy.org>


michaelso <pypy at michaelso.com> added the comment:

thanks a lot! but why it need "--jit off"? and will it affect performance?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 18:23:29 2013
From: tracker at bugs.pypy.org (michaelso)
Date: Thu, 18 Apr 2013 16:23:29 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366302209.74.0.713223363522.issue1459@bugs.pypy.org>


michaelso <pypy at michaelso.com> added the comment:

tested. the performance is not good... just like without pypy

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 18:26:36 2013
From: tracker at bugs.pypy.org (michaelso)
Date: Thu, 18 Apr 2013 16:26:36 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366302396.22.0.114354961068.issue1459@bugs.pypy.org>


michaelso <pypy at michaelso.com> added the comment:

tested. the performance is not good... its worse than CPython now...

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 18:36:28 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 18 Apr 2013 16:36:28 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366302988.12.0.264842998416.issue1459@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

We don't suggest running with --jit off, it's just so we know the bug is probably 
in the JIT.

----------
nosy: +agaynor

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 18:45:28 2013
From: tracker at bugs.pypy.org (michaelso)
Date: Thu, 18 Apr 2013 16:45:28 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366303528.02.0.521202258087.issue1459@bugs.pypy.org>


michaelso <pypy at michaelso.com> added the comment:

i see. thanks a lot!! i think this would be investigate and fix? :)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 18 22:35:28 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Apr 2013 20:35:28 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366317328.8.0.365522783519.issue1459@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

yes, this is an important problem. it'll get fixed for either beta 3 or 2.0 
final, depending how easy it is

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 19 14:04:23 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 19 Apr 2013 12:04:23 +0000
Subject: [pypy-issue] [issue1450] MemoryError from JIT when built with GCC
	4.8
In-Reply-To: <1365770216.81.0.356259231621.issue1450@bugs.pypy.org>
Message-ID: <1366373063.39.0.202136397473.issue1450@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This one has been fixed

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1450>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 00:30:22 2013
From: tracker at bugs.pypy.org (Matthew Schinckel)
Date: Fri, 19 Apr 2013 22:30:22 +0000
Subject: [pypy-issue] [issue1460] json loads with object_pair_hook
In-Reply-To: <1366410622.97.0.0728262094102.issue1460@bugs.pypy.org>
Message-ID: <1366410622.97.0.0728262094102.issue1460@bugs.pypy.org>


New submission from Matthew Schinckel <matt at schinckel.net>:

There is a subtle difference in pypy's handling of json.loads, with respect to 
object_pairs_hook, when an empty object is parsed.

Code speaks loud:

Python 2.7.2:

$python
Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> from collections import OrderedDict
>>> 
>>> json.loads('{}')
{}
>>> json.loads('{}', object_pairs_hook=OrderedDict)
OrderedDict()
>>> json.loads('{"foo":2}', object_pairs_hook=OrderedDict)
OrderedDict([(u'foo', 2)])



PyPy 1.9.0

$ pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``snow, snow''
>>>> import json
>>>> from collections import OrderedDict
>>>> 
>>>> json.loads('{}')
{}
>>>> json.loads('{}', object_pairs_hook=OrderedDict)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/Cellar/pypy/1.9/lib-python/2.7/json/__init__.py", line 339, in 
loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/local/Cellar/pypy/1.9/lib-python/2.7/json/decoder.py", line 369, in 
decode
    raise ValueError(errmsg("Extra data", s, end, len(s)))
ValueError: Extra data: line 1 column 1 - line 1 column 2 (char 1 - 2)
>>>> json.loads('{"foo":2}', object_pairs_hook=OrderedDict)
OrderedDict([(u'foo', 2)])
>>>>

----------
messages: 5603
nosy: pypy-issue, schinckel
priority: bug
release: 1.9
status: unread
title: json loads with object_pair_hook

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1460>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 00:31:32 2013
From: tracker at bugs.pypy.org (Matthew Schinckel)
Date: Fri, 19 Apr 2013 22:31:32 +0000
Subject: [pypy-issue] [issue1460] json loads with object_pair_hook
In-Reply-To: <1366410622.97.0.0728262094102.issue1460@bugs.pypy.org>
Message-ID: <1366410692.43.0.383550781073.issue1460@bugs.pypy.org>


Matthew Schinckel <matt at schinckel.net> added the comment:

This happens any time there is an empty object in the structure:

>>> json.loads('{"foo":{}}')

also raises the exception.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1460>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 02:29:42 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Sat, 20 Apr 2013 00:29:42 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>


New submission from Philip Jenvey <pjenvey at underboss.org>:

Windows hangs on this test_descr test:

def test_recursive_call(self):
    # Testing recursive __call__() by setting to instance of class...
    class A(object):
        pass

    A.__call__ = A()
    try:
        A()()
    except RuntimeError:
        pass
    else:
        self.fail("Recursion limit should have been reached for __call__()")

It's only a problem w/ new style classes, old style classes trigger the 
RuntimeError

posix handles it all just fine

----------
messages: 5605
nosy: pypy-issue
priority: bug
release: 1.9
status: unread
title: new style class recursive __call__ doesn't trigger a RuntimeError on windows

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 11:26:14 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 20 Apr 2013 09:26:14 +0000
Subject: [pypy-issue] [issue1459] Pypy 2.0 beta 2 with cffi segmentation
	fault 11
In-Reply-To: <1366297345.94.0.910736290961.issue1459@bugs.pypy.org>
Message-ID: <1366449974.05.0.456899221527.issue1459@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This one is fixed

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1459>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 11:29:10 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 20 Apr 2013 09:29:10 +0000
Subject: [pypy-issue] [issue1447] SymPy tests use too much memory
In-Reply-To: <1365640065.75.0.999483427337.issue1447@bugs.pypy.org>
Message-ID: <1366450150.81.0.309369143211.issue1447@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This is mostly warmup and JIT structures. We definitely should do something about 
it, but there is no "simple solution" for now. Warmup and JIT memory usage are on 
our mid-term goal list.

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1447>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 16:53:03 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 20 Apr 2013 14:53:03 +0000
Subject: [pypy-issue] [issue1460] json loads with object_pair_hook
In-Reply-To: <1366410622.97.0.0728262094102.issue1460@bugs.pypy.org>
Message-ID: <1366469583.87.0.5081609309.issue1460@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Fixed in 6794e06515db, thanks for reporting this!

----------
nosy: +agaynor
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1460>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 17:09:03 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 20 Apr 2013 15:09:03 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366470543.24.0.752787457765.issue1453@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

It seems that 40390dcf161a ("in-progress") is actually enough to fix the
segfault.  At least I no longer get it, apparently.

The remaining issue is because the JIT compiles a tiny loop, so it thinks it
will run very fast and sets a very high limit on the loop counter before
releasing the GIL -- by default, up to one million.  Apparently, one million
calls to os.getlogin() takes forever.  To fix this we could use a different
approach like checking the timestamp instead (we already have a ResOp for that,
for profiling).

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 17:24:58 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 20 Apr 2013 15:24:58 +0000
Subject: [pypy-issue] [issue1457] multiprocessing sample hangs
In-Reply-To: <1366190512.48.0.159793532971.issue1457@bugs.pypy.org>
Message-ID: <1366471498.14.0.670987711368.issue1457@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Just wait a bit longer.  This is an extreme case of long arithmetic, where
CPython has (I believe) a special implementation for "x * x" where x is a large
object of type "long", which we are missing.  It's in other words completely
unrelated to multiprocessing.  If I tweak the example until it looks more like a
real load (see test2.py), the numbers are in favour of PyPy again.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1457>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 17:27:16 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 20 Apr 2013 15:27:16 +0000
Subject: [pypy-issue] [issue1445] Major regression since 2.0 beta
In-Reply-To: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>
Message-ID: <1366471636.09.0.197355271524.issue1445@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

One clear cause of MemoryError is GCC 4.8, which we fixed it after beta2.  Did
you use GCC 4.8 to compile it?

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1445>
________________________________________

From tracker at bugs.pypy.org  Sat Apr 20 17:28:36 2013
From: tracker at bugs.pypy.org (Florian Apolloner)
Date: Sat, 20 Apr 2013 15:28:36 +0000
Subject: [pypy-issue] [issue1445] Major regression since 2.0 beta
In-Reply-To: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>
Message-ID: <1366471716.02.0.996712962212.issue1445@bugs.pypy.org>


Florian Apolloner <florian at apolloner.eu> added the comment:

Dunno, I was using your nightlies, so whatever you did use I used?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1445>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 21 12:43:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 21 Apr 2013 10:43:13 +0000
Subject: [pypy-issue] [issue1445] Major regression since 2.0 beta
In-Reply-To: <1365539188.91.0.246145124206.issue1445@bugs.pypy.org>
Message-ID: <1366540993.45.0.742207079028.issue1445@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Then the problem is different...

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1445>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 21 12:45:16 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 21 Apr 2013 10:45:16 +0000
Subject: [pypy-issue] [issue1462] Run several "translate.py" in parallel
In-Reply-To: <1366541116.38.0.86482066251.issue1462@bugs.pypy.org>
Message-ID: <1366541116.38.0.86482066251.issue1462@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

When we run two "translate.py" in parallel from the same source code, we hit
some race conditions.  The same may be true when running tests.  We should
review and fix them...

----------
messages: 5614
nosy: arigo, pypy-issue
priority: bug
status: unread
title: Run several "translate.py" in parallel

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1462>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 21 23:09:54 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 21 Apr 2013 21:09:54 +0000
Subject: [pypy-issue] [issue1453] segfault with simple script on 2.0b2+
In-Reply-To: <1365982575.93.0.634233065521.issue1453@bugs.pypy.org>
Message-ID: <1366578594.07.0.863843120332.issue1453@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Just FYI the resop only works reliably if you run on one CPU core (we pin under 
profiling), but maybe it's "good enough", because at worst we'll skip one or so, 
if written carefully.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1453>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 22 16:23:08 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 22 Apr 2013 14:23:08 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1366640588.52.0.701953969039.issue846@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Reopening: nltk seems to have still remaining cases of subclassing 'basestring',
according to
http://code.google.com/p/nltk/source/browse/trunk/nltk/nltk/sourcedstring.py#282

Should we just patch it in PyPy?  We should make sure we have a test doing the
same, which is:

class S(basestring):
  def __new__(cls):
    return "foo"

----------
status: wontfix -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue846>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 22 22:18:11 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 22 Apr 2013 20:18:11 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1366661891.27.0.868059097325.issue1188@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Ah, another idea for -O support: we could also support it from the same .pyc
files simply by having "assert xyz" compile a conditional jump first.  The jump
would skip the whole assert statement when running in -O mode, and do nothing
when running in normal mode.  This would have a very minor impact on performance
(and no impact on the JITted code).

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1188>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 23 00:05:33 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Mon, 22 Apr 2013 22:05:33 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366668333.35.0.0343555070199.issue1461@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

I've made test_recursive_call skip on windows for now, and also py3k's 
test_class.testSFBug532646 too

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 23 05:16:05 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Tue, 23 Apr 2013 03:16:05 +0000
Subject: [pypy-issue] [issue1455] fixes "no _curses or _minimal_curses" on
	netbsd
In-Reply-To: <1366072588.53.0.0350151984696.issue1455@bugs.pypy.org>
Message-ID: <1366686965.23.0.440328439324.issue1455@bugs.pypy.org>


YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp> added the comment:

can anyone apply this patch, or point out problems in the patch so that i can fix?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1455>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 23 09:24:46 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 23 Apr 2013 07:24:46 +0000
Subject: [pypy-issue] [issue1455] fixes "no _curses or _minimal_curses" on
	netbsd
In-Reply-To: <1366072588.53.0.0350151984696.issue1455@bugs.pypy.org>
Message-ID: <1366701886.34.0.00471135690746.issue1455@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

"Resolved", thanks.  With quotes because this is actually hiding the various
problems you noticed.

----------
nosy: +arigo
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1455>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 23 09:34:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 23 Apr 2013 07:34:13 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366702453.33.0.519547887343.issue1461@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

The reason is in rpython/translator/c/src/stack.h: you need a macro
PYPY_INHIBIT_TAIL_CALL().  Without it, the C code compiles too many tail calls.
 This test is precisely checking a particular path that does only tail calls at
the C levels.  An optimizing compiler replaces them all with jumps, and then
runs the seemingly infinite number of nested C calls in a finite amount of C stack.

There are probably portable ways to write the macro.

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From fijall at gmail.com  Tue Apr 23 14:48:13 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 23 Apr 2013 14:48:13 +0200
Subject: [pypy-issue] [issue1461] new style class recursive __call__
 doesn't trigger a RuntimeError on windows
In-Reply-To: <1366702453.33.0.519547887343.issue1461@bugs.pypy.org>
References: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
	<1366702453.33.0.519547887343.issue1461@bugs.pypy.org>
Message-ID: <CAK5idxSDoCB-bVFERaJiq6k9w6xXg3g43QgC5oETzB4v1T2-Eg@mail.gmail.com>

On Tue, Apr 23, 2013 at 9:34 AM, Armin Rigo <tracker at bugs.pypy.org> wrote:
>
> Armin Rigo <armin.rigo at gmail.com> added the comment:
>
> The reason is in rpython/translator/c/src/stack.h: you need a macro
> PYPY_INHIBIT_TAIL_CALL().  Without it, the C code compiles too many tail calls.
>  This test is precisely checking a particular path that does only tail calls at
> the C levels.  An optimizing compiler replaces them all with jumps, and then
> runs the seemingly infinite number of nested C calls in a finite amount of C stack.
>
> There are probably portable ways to write the macro.
>
> ----------
> nosy: +arigo
>

To be honest, is it actually a bad thing?

From tracker at bugs.pypy.org  Tue Apr 23 16:59:47 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 23 Apr 2013 14:59:47 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1366729187.95.0.455387806879.issue846@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Well, it's again, a stupid issue. Make it subclass object (if __new__ is 
returning something else anyway)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue846>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 04:29:56 2013
From: tracker at bugs.pypy.org (Kenneth Reitz)
Date: Wed, 24 Apr 2013 02:29:56 +0000
Subject: [pypy-issue] [issue1464] PYTHONUNBUFFERED
In-Reply-To: <1366770596.43.0.161870583099.issue1464@bugs.pypy.org>
Message-ID: <1366770596.43.0.161870583099.issue1464@bugs.pypy.org>


New submission from Kenneth Reitz <me at kennethreitz.com>:

It would appear as though PyPy doesn't support CPython's environment variable 
configuration PYTHONUNBUFFERED for making stdin/out/err unbuffered.

More info:

- http://docs.python.org/2/using/cmdline.html#envvar-PYTHONUNBUFFERED
- http://docs.python.org/2/using/cmdline.html#cmdoption-u

----------
messages: 5624
nosy: kennethreitz, pypy-issue
priority: bug
status: unread
title: PYTHONUNBUFFERED

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1464>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 08:56:22 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Wed, 24 Apr 2013 06:56:22 +0000
Subject: [pypy-issue] [issue1464] PYTHONUNBUFFERED
In-Reply-To: <1366770596.43.0.161870583099.issue1464@bugs.pypy.org>
Message-ID: <1366786582.71.0.983187439466.issue1464@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Recognition of the env variable was recently added for 2.0, in 79f1404df7ae

----------
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1464>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 10:37:10 2013
From: tracker at bugs.pypy.org (ming)
Date: Wed, 24 Apr 2013 08:37:10 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366792630.34.0.267894772535.issue1465@bugs.pypy.org>
Message-ID: <1366792630.34.0.267894772535.issue1465@bugs.pypy.org>


New submission from ming <humings at gmail.com>:

I was using cffi callback to call my python function from my c library; it works 
fine when they are all in one thread, but it crashes when my c library create a 
new thread and do the "callback" in new thread.

----------
files: test.py
messages: 5626
nosy: huming, pypy-issue
priority: critical
status: unread
title: cffi callback crashes in multithread environment

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 10:39:28 2013
From: tracker at bugs.pypy.org (ming)
Date: Wed, 24 Apr 2013 08:39:28 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366792630.34.0.267894772535.issue1465@bugs.pypy.org>
Message-ID: <1366792768.82.0.505327214973.issue1465@bugs.pypy.org>


ming <humings at gmail.com> added the comment:

I was using cffi callback to call my python function from my c library; it works 
fine when they are all in one thread, but it crashes when my c library create a 
new thread and do the "callback" in new thread.

The error sometime is "Segmentfalut 11", sometimes is "bus error"

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 10:52:35 2013
From: tracker at bugs.pypy.org (ming)
Date: Wed, 24 Apr 2013 08:52:35 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366792630.34.0.267894772535.issue1465@bugs.pypy.org>
Message-ID: <1366793555.85.0.909952192887.issue1465@bugs.pypy.org>


ming <humings at gmail.com> added the comment:

Use this code; and compile the C code into a dynamic library. (If you have 
Sconstruct installed, just type "scons")
My environment is MacOSX 10.8.3

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 11:33:18 2013
From: tracker at bugs.pypy.org (ming)
Date: Wed, 24 Apr 2013 09:33:18 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366792630.34.0.267894772535.issue1465@bugs.pypy.org>
Message-ID: <1366795998.56.0.711394809422.issue1465@bugs.pypy.org>


ming <humings at gmail.com> added the comment:

Pypy version: pypy-2.0-beta2

CPython works fine in my test program.

----------
release:  -> 2.0

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 11:43:59 2013
From: tracker at bugs.pypy.org (ming)
Date: Wed, 24 Apr 2013 09:43:59 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366792768.82.0.505327214973.issue1465@bugs.pypy.org>
Message-ID: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org>


ming <humings at gmail.com> added the comment:

I was using cffi callback to call my python function from my c library; it works 
fine when they are all in one thread, but it crashes when my c library create a 
new thread and do the "callback" in new thread.

The error sometime is "Segmentfalut 11", sometimes is "bus error"

Pypy version: pypy-2.0-beta2

CPython works fine in my test program.

You can see the code crashes Pypy in the attached file. The C code is like this:

#include <stdio.h>
int (*global_thread_callback)();

#include <pthread.h>


void *another_thread(void *arg)
{
	printf("this is another thread\n");
	global_thread_callback();
	return NULL;
}
void register_thread_callback(int (*func)())
{
	global_thread_callback = func;
	pthread_t tid;

	pthread_create(&tid, NULL, another_thread, NULL);
}


The Python code is like this:

from cffi import FFI
ffi = FFI()
ffi.cdef("""
	void register_thread_callback(int (*func)());
	""")

lib = ffi.dlopen("libtest.dylib")

# crashes here
def test_thread_callback():
	print 'thread call back OK'
	return 0

thread_func = ffi.callback("int()", test_thread_callback)

lib.register_thread_callback(thread_func)

while True:
	pass

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 12:29:59 2013
From: tracker at bugs.pypy.org (dktc)
Date: Wed, 24 Apr 2013 10:29:59 +0000
Subject: [pypy-issue] [issue1336] libssl version requirements
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1366799399.08.0.628259224581.issue1336@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

I am getting the same error trying to run PyPy 2.0b2 binary on Centos 5.8 x64

Additionally I am also having trouble building PyPy 2.0b2 on Centos 5.8. This problem apparently traces to some 
strange libssl errors that fail the build. Here is the end of error log -

[translation:ERROR] 	/usr/lib64/libssl.a(kssl.o): In function `kssl_krb5_free_data_contents':
[translation:ERROR] 	(.text+0x203): undefined reference to `krb5_free_data_contents'
[translation:ERROR] 	collect2: ld returned 1 exit status
[translation:ERROR] 	make: *** [pypy-c] Error 1

To compile with x64 SSL I did modify ropenssl.py to swap /lib/ directories for /lib64/. This fixed the initial SSL 
compatibility error message in the logs but the final make fails with the above message...

Could we clarify once and for all whether version 1.0.0 of openssl is required and 0.9.8 definitely won't work even if 
I build from source? Right now this is not apparent anywhere in the documentation.

Would you recommend trying to install libssl.so.1.0.0 or could it be possible to make source build work with 0.9.8?

----------
release:  -> 2.0
status: wontfix -> chatting
title: binary for debian squeeze 64 -> libssl version requirements

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1336>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 19:48:14 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Apr 2013 17:48:14 +0000
Subject: [pypy-issue] [issue1336] libssl version requirements
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1366825694.74.0.92037890135.issue1336@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Hi

Source should work with any version, but it seems you're trying to run the 
binary. Clarification in documentation will be good I guess.

The error makes no sense to me, other than your openssl install is broken (or 
it's impossible to build on centos with statically linking libssl or something)

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1336>
________________________________________

From tracker at bugs.pypy.org  Wed Apr 24 20:41:30 2013
From: tracker at bugs.pypy.org (dktc)
Date: Wed, 24 Apr 2013 18:41:30 +0000
Subject: [pypy-issue] [issue1336] OpenSSL / Kerberos linking trouble
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1366828890.67.0.482136128828.issue1336@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

I do suspect that something is wrong with my openssl or with how pypy build tries to statically link it...

However I am not sure where to even start looking for a fix to this... I've tried googling this error message and 
found similar errors (having to do with similar OpenSSL calls to Kerberos) pop up when compiling various other 
types of software. Unfortunately I have not seen any ready solution anywhere.

Here is a sampling of a few resources / examples (non PyPy) -
http://root.cern.ch/phpBB3/viewtopic.php?p=8630
http://www.ozzu.com/unix-linux-forum/libssl-kssl-error-t73551.html
http://forums.fedoraforum.org/showthread.php?t=83904
http://www.mail-archive.com/openssl-dev at openssl.org/msg15342.html
https://lists.soe.ucsc.edu/pipermail/genome/2010-September/023465.html

Do you have any suggestions on what to try / where to look to fix this?

----------
title: libssl version requirements -> OpenSSL / Kerberos linking trouble

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1336>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 08:17:04 2013
From: tracker at bugs.pypy.org (kfj)
Date: Thu, 25 Apr 2013 06:17:04 +0000
Subject: [pypy-issue] [issue1466] for slices,
	__array__interface['data'][0] yields adress of base object's data
In-Reply-To: <1366870624.4.0.139778689303.issue1466@bugs.pypy.org>
Message-ID: <1366870624.4.0.139778689303.issue1466@bugs.pypy.org>


New submission from kfj <_kfj at yahoo.com>:

Here's what I observed:

$ pypy
Python 2.7.3 (aa7b56060ddd, Apr 22 2013, 22:03:12)
[PyPy 2.0.0-beta2 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.2 released -
http://pypy.org/''
>>>> import numpypy as np
>>>> a=np.zeros(10)
>>>> a.__array_interface__['data'][0]
-1220095968
>>>> a[2:].__array_interface__['data'][0]
-1220095968                                 <<<<<<<< same value

$ python
Python 2.7.3 (default, Apr 10 2013, 05:46:21)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a=np.zeros(10)
>>> a.__array_interface__['data'][0]
162282152
>>> a[2:].__array_interface__['data'][0]
162282168                                  <<<<<<<<<<< different value

----------
nosy: +kfj
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1466>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 10:29:42 2013
From: tracker at bugs.pypy.org (schlamar)
Date: Thu, 25 Apr 2013 08:29:42 +0000
Subject: [pypy-issue] [issue1467] Curses doesn't raise ImportError on Windows
In-Reply-To: <1366878582.74.0.258403304325.issue1467@bugs.pypy.org>
Message-ID: <1366878582.74.0.258403304325.issue1467@bugs.pypy.org>


New submission from schlamar <marc.schlaich at gmail.com>:

Some libraries try to import curses and use it if available (e.g. Tornado).

However, this approach shows some undesirable behavior on Windows:

>>>> try:
....   import curses
.... except ImportError:
....   pass
....
_cffi__g85535e98x310af836.c
c:\pypy-2.0-beta2\lib_pypy\__pycache__\_cffi__g85535e98x310af836.c(26) : fatal error C1083: Datei (Include) kann 
nicht ge?ffnet werden: "ncurses.h": No such file or directory
Traceback (most recent call last):
  File "<console>", line 2, in <module>
  File "c:\pypy-2.0-beta2\lib-python\2.7\curses\__init__.py", line 15, in <module>
    from _curses import *
  File "c:\pypy-2.0-beta2\lib_pypy\_curses.py", line 319, in <module>
    """, libraries=['ncurses', 'panel'])
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\api.py", line 311, in verify
    lib = self.verifier.load_library()
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\verifier.py", line 68, in load_library
    self.compile_module()
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\verifier.py", line 56, in compile_module
    self._compile_module()
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\verifier.py", line 142, in _compile_module
    outputfilename = ffiplatform.compile(tmpdir, self.get_extension())
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\ffiplatform.py", line 25, in compile
    outputfilename = _build(tmpdir, ext)
  File "c:\pypy-2.0-beta2\lib_pypy\cffi\ffiplatform.py", line 50, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: CompileError: command 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe' 
failed with exit status 2
>>>>

----------
messages: 5635
nosy: pypy-issue, schlamar
priority: bug
release: 2.0
status: unread
title: Curses doesn't raise ImportError on Windows

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1467>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 10:32:11 2013
From: tracker at bugs.pypy.org (schlamar)
Date: Thu, 25 Apr 2013 08:32:11 +0000
Subject: [pypy-issue] [issue1467] Curses doesn't raise ImportError on Windows
In-Reply-To: <1366878582.74.0.258403304325.issue1467@bugs.pypy.org>
Message-ID: <1366878731.28.0.155051582436.issue1467@bugs.pypy.org>


schlamar <marc.schlaich at gmail.com> added the comment:

Expected behavior would be (from CPython 2.7):

>>> import curses
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\curses\__init__.py", line 15, in <module>
    from _curses import *
ImportError: No module named _curses

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1467>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 12:25:36 2013
From: tracker at bugs.pypy.org (dktc)
Date: Thu, 25 Apr 2013 10:25:36 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>


New submission from dktc <dkruglyak+pypy at gmail.com>:

I just compiled a new PyPy 2.0b2 and fired off an API web service hosted in a Spawning container (https://github.com/rtyler/Spawning/), which in turn relies on eventlet.

Some API clients (but not others) are generating a weird HTTP 400 error. I googled the error messages and found a blog post (http://unchainyourbrain.com/running-
openstack-nova-with-pypy) talking about incompatibilities of PyPy and greenlet and suggesting a couple of patches. Applying these patches did not solve or change the 
error:

(32414) accepted ('127.0.0.1', 50726)
myserverdomain.net - - [25/Apr/2013 05:03:06] code 400, message Bad HTTP/0.9 request type ('/myuri')
myserverdomain.net - - [25/Apr/2013 05:03:06] " /myuri HTTP/1.1" 400 -
Traceback (most recent call last):
  File "/opt/pypy-2.0-beta2/site-packages/eventlet/greenpool.py", line 80, in _spawn_n_impl
    func(*args, **kwargs)
  File "/opt/pypy-2.0-beta2/site-packages/eventlet/wsgi.py", line 575, in process_request
    proto = self.protocol(socket, address, self)
  File "/root/pypy/pypy-pypy-4b60269153b5/lib-python/2.7/SocketServer.py", line 640, in __init__
    self.finish()
  File "/opt/pypy-2.0-beta2/site-packages/eventlet/wsgi.py", line 509, in finish
    BaseHTTPServer.BaseHTTPRequestHandler.finish(self)
  File "/root/pypy/pypy-pypy-4b60269153b5/lib-python/2.7/SocketServer.py", line 694, in finish
    self.wfile.close()
  File "/root/pypy/pypy-pypy-4b60269153b5/lib-python/2.7/socket.py", line 327, in close
    self._sock._decref_socketios()
  File "/opt/pypy-2.0-beta2/site-packages/eventlet/greenio.py", line 157, in __getattr__
    attr = getattr(self.fd, name)
AttributeError: '_socket.socket' object has no attribute '_decref_socketios'

I am really at a loss where to go from here. Is it possible to patch eventlet to work with PyPy and avoid this error?

----------
messages: 5637
nosy: pypy-issue
priority: critical
release: 2.0
status: unread
title: PyPy eventlet trouble with _decref_socketios

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 12:56:53 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 25 Apr 2013 10:56:53 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1366887413.81.0.448391142117.issue1468@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Well, it means that eventlet tries to call internal APIs on socket objects, which 
are different on pypy sockets. In particular, pypy's sockets are not refcounted. 
I wonder what happens if this is not called at all?

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 15:56:06 2013
From: tracker at bugs.pypy.org (mattip)
Date: Thu, 25 Apr 2013 13:56:06 +0000
Subject: [pypy-issue] [issue1451] Strange error message in numpypy
In-Reply-To: <1365861850.43.0.055954570643.issue1451@bugs.pypy.org>
Message-ID: <1366898166.97.0.30148154302.issue1451@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

fixed in changeset 30d046a from April 15, testing actual string broke -A 
compatability with upstream numpy so test only first part of exception

----------
nosy: +mattip
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1451>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 18:49:54 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 25 Apr 2013 16:49:54 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1366908594.17.0.658317316167.issue1468@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

_decref_socketios is also a method of python3 sockets, because python3 does not 
want to rely on reference counting to close sockets.
Is there a version of eventlet for python 3? We could use it to adapt eventlet 
for pypy.

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 21:19:45 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Thu, 25 Apr 2013 19:19:45 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366917585.51.0.524802813683.issue1461@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

#ifdef __GNUC__
#  define PYPY_INHIBIT_TAIL_CALL()   asm("/* inhibit_tail_call */")

So is this macro a hint to GCC? If so, is this documented anywhere? (google 
returns nothing for inhibit_tail_call, or am I missing something?)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From tracker at bugs.pypy.org  Thu Apr 25 21:20:26 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Thu, 25 Apr 2013 19:20:26 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366917626.7.0.0827810622845.issue1461@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Also now skipping json_tests.test_recursion test_highly_nested_objects_encoding 
(somehow it's only an issue on the py3 branch)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 26 02:27:25 2013
From: tracker at bugs.pypy.org (dktc)
Date: Fri, 26 Apr 2013 00:27:25 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1366936045.63.0.376198347859.issue1468@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

I do not believe eventlet supports python3 yet, I just did a quick search: http://py3ksupport.appspot.com/pypi/eventlet

On the other note I found that my original error was caused by client's malformed HTTP request and eventlet incompatibility only 
arose out of the exception handling chain. But this bug / incompatibility still remains here...

----------
priority: critical -> bug

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 26 11:47:11 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 26 Apr 2013 09:47:11 +0000
Subject: [pypy-issue] [issue1461] new style class recursive __call__ doesn't
	trigger a	RuntimeError on windows
In-Reply-To: <1366417782.81.0.535548814892.issue1461@bugs.pypy.org>
Message-ID: <1366969631.56.0.513793080051.issue1461@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

It's "we know on GCC, having an asm() somewhere prevents tail call from 
happening" kind of macro. Maybe it works on VS too

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1461>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 26 12:42:52 2013
From: tracker at bugs.pypy.org (Tyler Wade)
Date: Fri, 26 Apr 2013 10:42:52 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1366972972.5.0.142925546976.issue1188@bugs.pypy.org>


Tyler Wade <wayedt at gmail.com> added the comment:

I've attached a patch for -OO support.  A few comments/concerns:

 - I wasn't sure what the best way to figure out when -OO was set. I ended up 
using sys.flags, which has the side effect that the first few modules imported 
won't have their docstrings stripped.
 - The way I changed the sys.flags value in pyinteractive.py is kind of dumb. Is 
there/what is a better way to do this?
 - Docstrings won't be removed from code run via eval or exec.  I don't know how 
desirable that is, but I can add it if need be.

----------
nosy: +waedt

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1188>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 26 14:43:59 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 26 Apr 2013 12:43:59 +0000
Subject: [pypy-issue] [issue1336] OpenSSL / Kerberos linking trouble
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1366980239.76.0.00493530568041.issue1336@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Try playing with removing static linking (see a chain of ifs in 
rpython/rlib/ropenssl.py), or replacing it with '-lssl' instead of putting the 
filename or so. I have no clue

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1336>
________________________________________

From tracker at bugs.pypy.org  Fri Apr 26 18:51:26 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 26 Apr 2013 16:51:26 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1366995086.32.0.594194764318.issue1468@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Do you have a sample script to reproduce the issue?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 28 02:31:05 2013
From: tracker at bugs.pypy.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Apr 2013 00:31:05 +0000
Subject: [pypy-issue] [issue1469] Missing declarations of PyObject_Malloc(),
	PyObject_Realloc() and PyObject_Free()
In-Reply-To: <1367109065.29.0.901437579559.issue1469@bugs.pypy.org>
Message-ID: <1367109065.29.0.901437579559.issue1469@bugs.pypy.org>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Declarations of PyObject_Malloc(), PyObject_Realloc() and PyObject_Free() are
missing in installed headers, which can cause problems during compilation of
extension modules, which use these functions.
Compilation failure occurs with -Werror=implicit-function-declaration flag.

----------
messages: 5648
nosy: Arfrever, pypy-issue
priority: bug
status: unread
title: Missing declarations of PyObject_Malloc(), PyObject_Realloc() and PyObject_Free()

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1469>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 28 17:49:58 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 28 Apr 2013 15:49:58 +0000
Subject: [pypy-issue] [issue1470] Implement python3 sys.setswitchinterval()
In-Reply-To: <1367164198.61.0.86586358164.issue1470@bugs.pypy.org>
Message-ID: <1367164198.61.0.86586358164.issue1470@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

CPython 3.2 deprecated sys.setcheckinterval() which counts bytecodes, and has now sys.setswitchinterval() 
which is a duration in seconds (stored as microseconds).

The implementation is in Python/ceval_gil.h: a waiting thread calls take_gil(), which calls 
pthread_cond_timedwait. If this times out, it requests the running thread to drop the GIL.
[likewise, an incoming signal asks the running thread to exit the eval loop at the first occasion]

This method is believed to be more fair towards other threads, with the current method the thread that 
releases the GIL is often the first one to acquire it again.

----------
messages: 5649
nosy: amaury, pypy-issue
priority: feature
status: unread
title: Implement python3 sys.setswitchinterval()

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1470>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 28 20:48:02 2013
From: tracker at bugs.pypy.org (Tyler Wade)
Date: Sun, 28 Apr 2013 18:48:02 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1367174882.51.0.798069458964.issue1188@bugs.pypy.org>


Tyler Wade <wayedt at gmail.com> added the comment:

Attached is an updated patch that implements both the -O and -OO flags. As 
suggested on IRC, I implemented assert skipping by adding a new opcode 
JUMP_IF_NOT_DEBUG

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1188>
________________________________________

From tracker at bugs.pypy.org  Sun Apr 28 21:56:54 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 28 Apr 2013 19:56:54 +0000
Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread
	environment
In-Reply-To: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org>
Message-ID: <1367179014.05.0.258573207893.issue1465@bugs.pypy.org>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

A self-contained script below.
It does not crash when the thread was created from Python code
(with
    thread.start_new_thread(lib.another_thread, (ffi.NULL,))
)



from cffi import FFI
ffi = FFI()
ffi.cdef("""
void register_thread_callback(int (*func)());
""")
lib = ffi.verify("""
#include <stdio.h>
#include <pthread.h>

int (*global_thread_callback)();
void *another_thread(void *arg)
{
    printf("this is another thread\\n");
    global_thread_callback();
    return NULL;
}
void register_thread_callback(int (*func)())
{
    global_thread_callback = func;
    pthread_t tid;

    pthread_create(&tid, NULL, another_thread, NULL);
}
""")

@ffi.callback("int()")
def thread_callback():
    print 'thread call back OK'
    return 0
lib.register_thread_callback(thread_callback)
while True:
    pass

----------
nosy: +amaury

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1465>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 29 09:19:39 2013
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Apr 2013 07:19:39 +0000
Subject: [pypy-issue] [issue1336] OpenSSL / Kerberos linking trouble
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1367219979.15.0.985172595501.issue1336@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

For the time being I'm punting on this as I've been able to make do without SSL support.

The whole reason I tried to build with SSL is because the latest PIP (v 1.3.x) requires it. I just downgraded to PIP v1.2.1 to create 
a workable install...

It would be helpful to have clearer instructions / howtos for trying out different options in ropenssl.py as suggested below. It takes 
hours to build PyPy and then some time to test it.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1336>
________________________________________

From tracker at bugs.pypy.org  Mon Apr 29 09:20:18 2013
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Apr 2013 07:20:18 +0000
Subject: [pypy-issue] [issue1468] PyPy eventlet trouble with
	_decref_socketios
In-Reply-To: <1366885536.44.0.498230363361.issue1468@bugs.pypy.org>
Message-ID: <1367220018.82.0.401076981085.issue1468@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

No sample (simple) script unfortunately - the issue pops up as part of a larger system.

In my case I've determined I see this exception only if the request already failed. After I fixed the underlying problems these issues 
went away and I'm content to leave it like this for now.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1468>
________________________________________

From tracker at bugs.pypy.org  Tue Apr 30 22:41:27 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 30 Apr 2013 20:41:27 +0000
Subject: [pypy-issue] [issue1471] Re-enable strategies on py3k
In-Reply-To: <1367354487.89.0.178259207003.issue1471@bugs.pypy.org>
Message-ID: <1367354487.89.0.178259207003.issue1471@bugs.pypy.org>


New submission from Philip Jenvey <pjenvey at underboss.org>:

Most of list/set/dict etc strategies were disabled on py3k as they became pretty 
broken w/ the big bytes/unicode switch. We also lacked an rpython unicode type 
strategy at the time, but we have that now

These need to be re-enabled before the final release, obviously for the sake of 
performance

Many of the strategy tests were disabled in 2db1e0a806e2, but there are also 
some others. I believe they are all py3k_skip's

----------
assignedto: pjenvey
messages: 5654
nosy: pypy-issue
priority: performance bug
status: unread
title: Re-enable strategies on py3k

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1471>
________________________________________