From tracker at bugs.pypy.org  Fri Aug  3 11:10:49 2012
From: tracker at bugs.pypy.org (Yaakov Selkowitz)
Date: Fri, 03 Aug 2012 09:10:49 +0000
Subject: [pypy-issue] [issue1226] ctypes: Cygwin fixes
In-Reply-To: <1343985049.84.0.324573029538.issue1226@bugs.pypy.org>
Message-ID: <1343985049.84.0.324573029538.issue1226@bugs.pypy.org>


New submission from Yaakov Selkowitz <yselkowitz at users.sourceforge.net>:

The attached patch fixes ctypes for Cygwin:
1) with pypy, the pythonapi symbols are in the interpreter itself, not a separate 
libpython.
2) implement ctypes.util.find_library("foo") on Cygwin; we use an identical patch 
for CPython and should eventually land upstream.

----------
messages: 4633
nosy: pypy-issue
priority: bug
status: unread
title: ctypes: Cygwin fixes

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

From tracker at bugs.pypy.org  Fri Aug  3 12:08:00 2012
From: tracker at bugs.pypy.org (Attila Nagy)
Date: Fri, 03 Aug 2012 10:08:00 +0000
Subject: [pypy-issue] [issue1227] LookupError for str.encode() in a multi
	threaded	application
In-Reply-To: <1343988480.95.0.833844865431.issue1227@bugs.pypy.org>
Message-ID: <1343988480.95.0.833844865431.issue1227@bugs.pypy.org>


New submission from Attila Nagy <bra at fsn.hu>:

I have a simple line in a method, called from multiple threads:
'string'.encode('utf8')
This occasionally (so far my observations show that only during the startup of
the program) raises a LookupError:
  File "concorde.py", line 752, in push_msg
    'string'.encode('utf8')
LookupError: unknown encoding: utf8

Is this correct or possible at all? During subsequent invocations, it works fine.
So far I couldn't reproduce this with cpython.
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 16 2012, 19:05:14)
[PyPy 1.9.0] on freebsd9 (amd64)

----------
messages: 4634
nosy: pypy-issue
priority: bug
release: 1.9
status: unread
title: LookupError for str.encode() in a multi threaded application

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

From tracker at bugs.pypy.org  Fri Aug  3 12:22:00 2012
From: tracker at bugs.pypy.org (Mateusz Korniak)
Date: Fri, 03 Aug 2012 10:22:00 +0000
Subject: [pypy-issue] [issue1228] 1.9 build failure on linuxes
	with	/usr/include/ncurses/curses.h
In-Reply-To: <1343989320.79.0.867312541918.issue1228@bugs.pypy.org>
Message-ID: <1343989320.79.0.867312541918.issue1228@bugs.pypy.org>


New submission from Mateusz Korniak <mateusz-lists at ant.gliwice.pl>:

curses test fails when 1.9 build tried on linux system with
/usr/include/ncurses/curses.h. 
Attached patch adds test for /usr/include/ncurses/curses.h.

----------
files: pypy-curses.patch
messages: 4635
nosy: matkor, pypy-issue
priority: feature
release: 1.9
status: unread
title: 1.9 build failure on linuxes with /usr/include/ncurses/curses.h

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

From tracker at bugs.pypy.org  Mon Aug  6 07:16:50 2012
From: tracker at bugs.pypy.org (3TATUK)
Date: Mon, 06 Aug 2012 05:16:50 +0000
Subject: [pypy-issue] [issue1229] PyPy Benchmarking Bias?
In-Reply-To: <1344230210.47.0.994986096895.issue1229@bugs.pypy.org>
Message-ID: <1344230210.47.0.994986096895.issue1229@bugs.pypy.org>


New submission from 3TATUK <ztatik.light at gmail.com>:

I had a suggestion for PyPy: Considering as how part of it's primary goal is
speed... I think the performance benchmarks could use a revamp..  Reason being,
the could potentially be biased towards showing better results over time by
incorporating the use of special 'hacks'.. Just like OPEC companies report
higher outputs than in reality.

I recommend having two versions of each benchmark, both having the same exact
functional output, but one optimized for greatest CPython/PyPy speed, and one
optimized for lowest CPython/PyPy speed, and then either value could be
compared, or an average of the two.

----------
assignedto: fijal
messages: 4636
nosy: 3TATUK, fijal, pypy-issue
priority: wish
release: 2.0
status: in-progress
title: PyPy Benchmarking Bias?

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

From tracker at bugs.pypy.org  Mon Aug  6 12:23:57 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 06 Aug 2012 10:23:57 +0000
Subject: [pypy-issue] [issue1229] PyPy Benchmarking Bias?
In-Reply-To: <1344230210.47.0.994986096895.issue1229@bugs.pypy.org>
Message-ID: <1344248637.97.0.861613324546.issue1229@bugs.pypy.org>


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

This is complete nonsense - benchmarks were never optimized for PyPy. Look at 
their history for details. I suppose the real reason is not that we're less 
sleazy than OPEC, but the fact that there is not that much money involved. 
Closing as invalid, feel free to pop in on IRC for discussions if you want to.

----------
status: in-progress -> invalid

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

From tracker at bugs.pypy.org  Tue Aug  7 07:01:51 2012
From: tracker at bugs.pypy.org (Mariano Guerra)
Date: Tue, 07 Aug 2012 05:01:51 +0000
Subject: [pypy-issue] [issue1230] Pypy ctypes struct initialization and
	assignment bug
In-Reply-To: <1344315711.43.0.245103905188.issue1230@bugs.pypy.org>
Message-ID: <1344315711.43.0.245103905188.issue1230@bugs.pypy.org>


New submission from Mariano Guerra <luismarianoguerra at gmail.com>:

hi,

I'm having problems running my project SassPython under pypy, the problem seems
to be in the ctypes implementation, the two problems I identified is that fields
in a ctypes Structure are initialized differently in python and pypy and
assignment fails on pypy, here is a guide to reproduce the problem:

https://gist.github.com/3281751

attached is the same guide with the code needed to see the problem.

just for completeness here is the traceback when trying to assign to a field in
a subclass of ctypes.Structure that was initialized from a c function call.

Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "sass.py", line 57, in <module>
    ctx.source_string = ""
  File "/home/mariano/src/soft/pypy-1.9/lib_pypy/_ctypes/structure.py",
 line 108, in __set__
    store_reference(obj, key, cobj._objects)
  File "/home/mariano/src/soft/pypy-1.9/lib_pypy/_ctypes/basics.py", li
ne 21, in store_reference
    while '_index' in where.__dict__:
AttributeError: 'NoneType' object has no attribute '__dict__'

----------
files: pypy.rst
messages: 4638
nosy: marianoguerra, pypy-issue
priority: bug
status: unread
title: Pypy ctypes struct initialization and assignment bug

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

From tracker at bugs.pypy.org  Tue Aug  7 10:32:00 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 07 Aug 2012 08:32:00 +0000
Subject: [pypy-issue] [issue1231] test_jit_get_stats fails
In-Reply-To: <1344328320.97.0.656825849202.issue1231@bugs.pypy.org>
Message-ID: <1344328320.97.0.656825849202.issue1231@bugs.pypy.org>


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

jit/backend/x86/test/test_ztranslation.py: test_jit_get_stats has been failing
for a while now.  Marked as xfail because I want to see more green when merging
branches :-)  Please fix.

----------
assignedto: fijal
messages: 4639
nosy: arigo, fijal, pypy-issue
priority: bug
status: unread
title: test_jit_get_stats fails

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

From tracker at bugs.pypy.org  Tue Aug  7 21:26:11 2012
From: tracker at bugs.pypy.org (Pierpaolo Paolucci)
Date: Tue, 07 Aug 2012 19:26:11 +0000
Subject: [pypy-issue] [issue1232] bugs in pypy ctypes
In-Reply-To: <1344367571.37.0.260830564718.issue1232@bugs.pypy.org>
Message-ID: <1344367571.37.0.260830564718.issue1232@bugs.pypy.org>


New submission from Pierpaolo Paolucci <pierpaolo.paolucci at idemnet.it>:

from ctypes import *
class enum(c_uint):
    def __new__(cls, value):
        values = [getattr(cls, x) for x in dir(cls) if x.isupper()]
        if not value in values:
            raise ValueError, 'value <%d> not in %s' % (value, sorted(values))
        return super(enum, cls).__new__(cls)
class t_t(enum):
    (K, M, D, C) = map(int, xrange(4))
class DonaldDuck(Structure):
    _fields_ = [ ('t', t_t), ]
D = DonaldDuck()
print D.t
# this work perfectly on cpython but not on pypy 1.9

----------
files: pypy_ctype_bug.py
messages: 4640
nosy: peeble, pypy-issue
priority: bug
status: unread
title: bugs in pypy ctypes

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

From tracker at bugs.pypy.org  Wed Aug  8 02:52:51 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 08 Aug 2012 00:52:51 +0000
Subject: [pypy-issue] [issue1232] bugs in pypy ctypes
In-Reply-To: <1344367571.37.0.260830564718.issue1232@bugs.pypy.org>
Message-ID: <1344387171.12.0.242115249654.issue1232@bugs.pypy.org>


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

Sometimes ctypes create objects without calling the __new__ method...
Fixed in 76c0dcd40f93, thanks for the report and the test case!

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

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

From tracker at bugs.pypy.org  Wed Aug  8 03:10:09 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 08 Aug 2012 01:10:09 +0000
Subject: [pypy-issue] [issue1230] Pypy ctypes struct initialization and
	assignment bug
In-Reply-To: <1344315711.43.0.245103905188.issue1230@bugs.pypy.org>
Message-ID: <1344388209.47.0.603275568562.issue1230@bugs.pypy.org>


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

Function is declared as:
    struct sass_context* sass_new_context(void);
but:
    _new_context.restype = Context
I think it should be instead:
    _new_context.restype = POINTER(Context)

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

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

From tracker at bugs.pypy.org  Wed Aug  8 03:24:58 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 08 Aug 2012 01:24:58 +0000
Subject: [pypy-issue] [issue1227] LookupError for str.encode() in a multi
	threaded	application
In-Reply-To: <1343988480.95.0.833844865431.issue1227@bugs.pypy.org>
Message-ID: <1344389098.53.0.591150755758.issue1227@bugs.pypy.org>


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

CPython has a similar bug: http://bugs.python.org/issue10923

----------
nosy: +afa -bra
status: unread -> chatting

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

From tracker at bugs.pypy.org  Wed Aug  8 15:11:53 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 08 Aug 2012 13:11:53 +0000
Subject: [pypy-issue] [issue1223] throwing GreenletExit into a running
	greenlet doesn't	kill it
In-Reply-To: <1343064091.98.0.0389921329381.issue1223@bugs.pypy.org>
Message-ID: <1344431513.16.0.525259675916.issue1223@bugs.pypy.org>


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

Fixed in 97b5c7080684.  Thanks!

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

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

From tracker at bugs.pypy.org  Wed Aug  8 15:25:17 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 08 Aug 2012 13:25:17 +0000
Subject: [pypy-issue] [issue1166] Missing constants in kqueue implementation
In-Reply-To: <1339411849.18.0.0489867673086.issue1166@bugs.pypy.org>
Message-ID: <1344432317.09.0.424350465534.issue1166@bugs.pypy.org>


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

The source is in pypy/module/select/interp_kqueue.  The issue is that this code
attempts to support at least OS/X, OpenBSD and FreeBSD; for example
KQ_EV_SYSFLAGS, which you list, is present but commented out in the source.  I
don't know any of these systems and can't test it, but the solution should be
adaptive to what the underlying platform has got (which is easy:
cconfig[symbol_map[symbol]] gives None for symbols not defined).

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

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

From tracker at bugs.pypy.org  Thu Aug  9 22:45:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 09 Aug 2012 20:45:00 +0000
Subject: [pypy-issue] [issue1231] test_jit_get_stats fails
In-Reply-To: <1344328320.97.0.656825849202.issue1231@bugs.pypy.org>
Message-ID: <1344545100.46.0.659429352876.issue1231@bugs.pypy.org>


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

Fixed

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

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

From tracker at bugs.pypy.org  Fri Aug 10 00:05:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 09 Aug 2012 22:05:12 +0000
Subject: [pypy-issue] [issue1228] 1.9 build failure on linuxes
	with	/usr/include/ncurses/curses.h
In-Reply-To: <1343989320.79.0.867312541918.issue1228@bugs.pypy.org>
Message-ID: <1344549912.32.0.552631398626.issue1228@bugs.pypy.org>


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

Checked in 0cf0134d39eb

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

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

From tracker at bugs.pypy.org  Fri Aug 10 13:44:20 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 10 Aug 2012 11:44:20 +0000
Subject: [pypy-issue] [issue1227] LookupError for str.encode() in a multi
	threaded	application
In-Reply-To: <1343988480.95.0.833844865431.issue1227@bugs.pypy.org>
Message-ID: <1344599053.81.0.0185532220315.issue1227@bugs.pypy.org>


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

Mostly unrelated: I see in unicodetype.py special-cases for performance for the
"utf-8" encoding, but not for the "utf8" encoding.  Should we fix that too?  (If
we do, we probably accidentally solve the problem reported here, but the same
problem will continue to exist with other encodings.)

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

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

From tracker at bugs.pypy.org  Sun Aug 12 11:24:53 2012
From: tracker at bugs.pypy.org (Marcus von Appen)
Date: Sun, 12 Aug 2012 09:24:53 +0000
Subject: [pypy-issue] [issue1233] str() types can't be used with ctypes's
	py_object()
In-Reply-To: <1344763493.64.0.519996205744.issue1233@bugs.pypy.org>
Message-ID: <1344763493.64.0.519996205744.issue1233@bugs.pypy.org>


New submission from Marcus von Appen <mva at sysfault.org>:

Passing string objects to e.g. CFUNCTYPE callbacks via ctypes can currently only be
achieved using CPython, since pypy's implementation insists on using weakref'able
types for py_object() capsules.

Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jul 19 2012, 17:26:59)
[PyPy 1.9.0] on freebsd9
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is more stable than debian''
>>>> from ctypes import *
>>>> p = "Hello"
>>>> objp = py_object(p)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/lib/pypy1.9/lib_pypy/_ctypes/primitive.py", line 312, in __init__
    self.value = value
  File "/usr/local/lib/pypy1.9/lib_pypy/_ctypes/primitive.py", line 214, in _setvalue
    num = pyobj_container.add(val)
  File "/usr/local/lib/pypy1.9/lib_pypy/_ctypes/primitive.py", line 56, in add
    self.objs.append(weakref.ref(obj))
TypeError: cannot create weak reference to 'str' object

----------
messages: 4650
nosy: marcusva, pypy-issue
priority: bug
release: 1.9
status: unread
title: str() types can't be used with ctypes's py_object()

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

From tracker at bugs.pypy.org  Mon Aug 13 10:37:52 2012
From: tracker at bugs.pypy.org (Pigmej)
Date: Mon, 13 Aug 2012 08:37:52 +0000
Subject: [pypy-issue] [issue1234] Poor seek set performance (compared to
	cpython 2.7)
In-Reply-To: <1344847072.2.0.452643258492.issue1234@bugs.pypy.org>
Message-ID: <1344847072.2.0.452643258492.issue1234@bugs.pypy.org>


New submission from Pigmej <jedrzej.nowak at codernity.com>:

I attached the script. The script itself doesn't make sense at all but it demonstrates the 
real problem.

Please run strace on that and compare pypy and cpython 2.7 . You should see at the end of it 
following output:

--- cpython 2.7 ---
write(3, "00000000000000000000000000000000"..., 4096) = 4096
write(3, "25252525252525252525252525252525"..., 4096) = 4096
write(3, "45454545464646464646464646464646"..., 4096) = 4096
write(3, "66666666666666666666666666666666"..., 4096) = 4096
write(3, "86868686868686868787878787878787"..., 2616) = 2616
read(3, "", 4096)                       = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "00000000000000000000000000000000"..., 4096) = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, 4096, SEEK_SET)                = 4096
lseek(3, -4006, SEEK_CUR)               = 90
fsync(3)                                = 0
---

--- pypy trunk ---
write(3, "00000000000000000000000000000000"..., 8200) = 8200
write(3, "46464646464646464646464646464646"..., 8200) = 8200
write(3, "87878787878787878787878787878787"..., 2600) = 2600
read(3, "", 8192)                       = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 10, SEEK_SET)                  = 10
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 20, SEEK_SET)                  = 20
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 30, SEEK_SET)                  = 30
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 40, SEEK_SET)                  = 40
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 50, SEEK_SET)                  = 50
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 60, SEEK_SET)                  = 60
read(3, "00000000000000000000000000000000"..., 8192) = 8192
lseek(3, 70, SEEK_SET)                  = 70
read(3, "00000000000000000000000000000011"..., 8192) = 8192
lseek(3, 80, SEEK_SET)                  = 80
read(3, "00000000000000000000111111111111"..., 8192) = 8192
lseek(3, 90, SEEK_SET)                  = 90
fsync(3)                                = 0
---


As you can see cpython optimized those seeks / reads. While pypy did 1:1 what was written in 
original python script.

----------
files: pypy_vs_py27_seek.py
messages: 4651
nosy: pigmej, pypy-issue
priority: performance bug
status: unread
title: Poor seek set performance (compared to cpython 2.7)

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

From tracker at bugs.pypy.org  Wed Aug 15 03:49:50 2012
From: tracker at bugs.pypy.org (Aaron Meurer)
Date: Wed, 15 Aug 2012 01:49:50 +0000
Subject: [pypy-issue] [issue1235] "__len__ should return bool or integer"
	inconsistant with	CPython
In-Reply-To: <1344995390.31.0.592734100483.issue1235@bugs.pypy.org>
Message-ID: <1344995390.31.0.592734100483.issue1235@bugs.pypy.org>


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

CPython:

>>> class One(object):
...     def __int__(self):
...         return 1
... 
>>> class Test(object):
...     def __len__(self):
...         return One()
... 
>>> bool(Test())
True

PyPy (1.9):

>>>> class One(object):
....     def __int__(self):
....         return 1
.... 
>>>> class Test(object):
....     def __len__(self):
....         return One()
.... 
>>>> bool(Test())
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: __len__ should return bool or integer

I'm not sure if __int__ is the necessary thing that the object needs to have 
defined, but clearly PyPy should allow __len__ to return custom objects assuming 
that they have certain methods defined.

----------
messages: 4652
nosy: asmeurer, pypy-issue
priority: bug
status: unread
title: "__len__ should return bool or integer" inconsistant with CPython

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

From tracker at bugs.pypy.org  Wed Aug 15 18:06:31 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 15 Aug 2012 16:06:31 +0000
Subject: [pypy-issue] [issue1235] "__len__ should return bool or integer"
	inconsistant with	CPython
In-Reply-To: <1344995390.31.0.592734100483.issue1235@bugs.pypy.org>
Message-ID: <1345046791.71.0.842094048752.issue1235@bugs.pypy.org>


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

Fixed in 3c783b31f9da.  Thanks!

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

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

From tracker at bugs.pypy.org  Sat Aug 18 18:56:15 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sat, 18 Aug 2012 16:56:15 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>


New submission from bloodmage <zhouyisu at gmail.com>:

Environment:
Windows 7 64bit
Pypy-1.9 (or latest)
eventlet-0.9.15
Flask-0.9
Jinja2-2.6
werkzeug-fe7633c(latest)
mongo-python-driver-880ba27(latest)

I'm running a small benchmark to test pypy performance. Unfortunately it 
crashes, showing me following message:

D:\pypy-1.9\benchmark>..\pypy.exe pypyflaskmongo.py
RPython traceback:
  File "jit_metainterp_compile.c", line 136, in force_now_1
  File "jit_metainterp_compile.c", line 228, in ResumeGuardForcedDescr_save_data
Fatal RPython error: AssertionError

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

----------
files: pypyflaskmongo.py
messages: 4654
nosy: bloodmage, pypy-issue
priority: bug
release: 1.9
status: unread
title: Pypy eventlet crash

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1236>
________________________________________
-------------- next part --------------
import eventlet
eventlet.monkey_patch()
from eventlet import wsgi
from flask import Flask
app=Flask(__name__)
import random
import time
pymongo=eventlet.import_patched('pymongo')
conn=pymongo.Connection(use_greenlets=True)
db=conn.testdatabase

@app.route('/')
def hello():
    rand=random.random()
    db.testcollection.insert({'timestamp':time.time(),'rand':rand})
    conn.end_request()
    return "Hello world! %s"%rand

class StubFile:
    def write(self,a): pass

def hello_world(env, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return ['Hello, World!\r\n']

wsgi.server(eventlet.listen(('',8090)),app.wsgi_app,keepalive=False,log=StubFile())


From tracker at bugs.pypy.org  Sat Aug 18 19:21:38 2012
From: tracker at bugs.pypy.org (viblo)
Date: Sat, 18 Aug 2012 17:21:38 +0000
Subject: [pypy-issue] [issue1237] pypy 2x slower than python on
	ctypes.Structure
In-Reply-To: <1345310498.32.0.773264370774.issue1237@bugs.pypy.org>
Message-ID: <1345310498.32.0.773264370774.issue1237@bugs.pypy.org>


New submission from viblo <pypy at viblo.se>:

The attached code runs about 2x slower on pypy than cpython. It contains (part
of) a 2d Vector class, Vec2d, and small loop that uses it to do some
calculations. Vec2d inherits ctypes.Structure to be usable into a wrapped c
library using ctypes and it is this part that seems to be slow. If I skip
inheriting ctypes.Structure everything is speedy.

The code is part of the pymunk library (http://code.google.com/p/pymunk/) and
while I investigated the performance of pymunk in pypy I found this problem. I
think the attached code showcase a typical use case even if its very minimized
for this report.

----------
files: vec2d_bench.py
messages: 4655
nosy: pypy-issue, viblo
priority: performance bug
release: 1.9
status: unread
title: pypy 2x slower than python on ctypes.Structure

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

From tracker at bugs.pypy.org  Sat Aug 18 19:54:01 2012
From: tracker at bugs.pypy.org (viblo)
Date: Sat, 18 Aug 2012 17:54:01 +0000
Subject: [pypy-issue] [issue1237] pypy 2x slower than python on
	ctypes.Structure
In-Reply-To: <1345310498.32.0.773264370774.issue1237@bugs.pypy.org>
Message-ID: <1345312441.47.0.289431416028.issue1237@bugs.pypy.org>


viblo <pypy at viblo.se> added the comment:

Forgot to add: I tested on pypy-1.9, pypy-c-jit-53293-478bc4f20cb7-win32 and
cpython 2.6 on Windows 7.

Time to complete 100000 iterations
python 2.6: 5.63 sec
pypy-1.9: 11.12 sec
pypy-c-jit-53293-478bc4f20cb7-win32: 11.12 sec

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

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

From tracker at bugs.pypy.org  Sun Aug 19 08:12:39 2012
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Sun, 19 Aug 2012 06:12:39 +0000
Subject: [pypy-issue] [issue1238] "bad write retry" from ssl sockets
In-Reply-To: <1345356759.53.0.254657459085.issue1238@bugs.pypy.org>
Message-ID: <1345356759.53.0.254657459085.issue1238@bugs.pypy.org>


New submission from Ben Darnell <ben at bendarnell.com>:

Writing to an SSL socket in pypy (1.9, tested on mac) sometimes fails with a "bad 
write retry" message, when the same code succeeds in cpython.  I believe this is 
because with pypy's GC, objects may be moved around, so the address of a str 
object may change (if I'm wrong on this point please correct me).  In non-blocking 
mode, openssl requires by default that the same buffer be used for repeated write 
calls.  In cpython this can be done by ensuring that the same string object be 
reused (see e.g 
https://github.com/facebook/tornado/blob/master/tornado/iostream.py#L527), but for 
pypy that doesn't work, so the simplest workaround is to disable this sanity check 
by setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER on the ssl context.  

Related cpython issue: http://bugs.python.org/issue8240

It's difficult to make a minimal test case since the bug depends on both socket 
buffering and garbage collection, but 
https://github.com/facebook/tornado/blob/master/tornado/test/iostream_test.py#L266 
seems to trigger it reliably.

----------
messages: 4658
nosy: bdarnell, pypy-issue
priority: bug
status: unread
title: "bad write retry" from ssl sockets

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

From tracker at bugs.pypy.org  Sun Aug 19 19:22:12 2012
From: tracker at bugs.pypy.org (amjad)
Date: Sun, 19 Aug 2012 17:22:12 +0000
Subject: [pypy-issue] [issue1239] Sandbox pypy fails to import module struct
In-Reply-To: <1345396932.62.0.556422561657.issue1239@bugs.pypy.org>
Message-ID: <1345396932.62.0.556422561657.issue1239@bugs.pypy.org>


New submission from amjad <amjad.masad at gmail.com>:

Observed on both Mac OS X and Linux using PyPy 1.9.1-dev0. 

>>>> import struct
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/bin/lib-python/2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct

----------
messages: 4659
nosy: amasad, pypy-issue
priority: bug
status: unread
superseder: sandbox interactor not trivially usable as a drop-in replacement for python
title: Sandbox pypy fails to import module struct

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

From tracker at bugs.pypy.org  Sun Aug 19 01:23:56 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sat, 18 Aug 2012 23:23:56 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1345332236.6.0.941420785809.issue1236@bugs.pypy.org>


bloodmage <zhouyisu at gmail.com> added the comment:

Different crash message actually in 1.9 version latest nightbuild version.

For latest nightbuild version, message is:

D:\pypy-1.9\benchmark>..\pypy.exe pypyflaskmongo.py
RPython traceback:
  File "jit_metainterp_compile.c", line 136, in force_now_1
  File "jit_metainterp_compile.c", line 200, in 
ResumeGuardForcedDescr_handle_async_forcing
Fatal RPython error: AssertionError

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


Here I uploaded the site-packages directory so that it will be more convenient 
to reproduce this crash. Just visit localhost:8090 for several thousand times.

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

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

From tracker at bugs.pypy.org  Mon Aug 20 10:01:03 2012
From: tracker at bugs.pypy.org (eri)
Date: Mon, 20 Aug 2012 08:01:03 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1345449663.74.0.686016950992.issue1116@bugs.pypy.org>


eri <oddghost at mail.ru> added the comment:

I had found variables named "myfileobj" and "fileobj" in pypy 1.9.
Seems to be this is one variable. Refuctoring  "myfileobj" to "fileobj" i have 
no tracebacks in django.

----------
nosy: +eri

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

From tracker at bugs.pypy.org  Mon Aug 20 14:39:58 2012
From: tracker at bugs.pypy.org (Hong Minhee)
Date: Mon, 20 Aug 2012 12:39:58 +0000
Subject: [pypy-issue] [issue1240] Different evaluation of generation on
	list.extend()	method from CPython
In-Reply-To: <1345466398.44.0.295959271189.issue1240@bugs.pypy.org>
Message-ID: <1345466398.44.0.295959271189.issue1240@bugs.pypy.org>


New submission from Hong Minhee <minhee at dahlia.kr>:

PyPy's list.extend() evaluates whole steps of a given generator at a time while
CPython evaluates each step by step.  Attached a test code as well.

Test result on CPython 2.7.2:

5 0
6 1
7 2
8 3
9 4
10 5
11 6
12 7
13 8
14 9

Test result on PyPy 1.9:

5 0
5 1
5 2
5 3
5 4
5 5
5 6
5 7
5 8
5 9

----------
files: list_extend_generator.py
messages: 4661
nosy: pypy-issue
priority: bug
release: 1.9
status: unread
title: Different evaluation of generation on list.extend() method from CPython

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

From tracker at bugs.pypy.org  Tue Aug 21 17:27:51 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 21 Aug 2012 15:27:51 +0000
Subject: [pypy-issue] [issue1237] pypy 2x slower than python on
	ctypes.Structure
In-Reply-To: <1345310498.32.0.773264370774.issue1237@bugs.pypy.org>
Message-ID: <1345562870.46.0.72641103335.issue1237@bugs.pypy.org>


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

This is kind of expected until we fix ctypes. Can you try using CFFI structure 
instead and see what's the performance?

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

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

From tracker at bugs.pypy.org  Tue Aug 21 21:07:22 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 21 Aug 2012 19:07:22 +0000
Subject: [pypy-issue] [issue1239] Sandbox pypy fails to import module struct
In-Reply-To: <1345396932.62.0.556422561657.issue1239@bugs.pypy.org>
Message-ID: <1345576042.76.0.450645919472.issue1239@bugs.pypy.org>


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

This is a wontfix - the default pypy sandbox comes without a struct module and 
making it work with sandbox might be a bit of an issue. try --withmod-_struct and 
see if it works.

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

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

From tracker at bugs.pypy.org  Tue Aug 21 21:08:41 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 21 Aug 2012 19:08:41 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1345576121.39.0.858304960947.issue1236@bugs.pypy.org>


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

PyPy has known crashers with greenlets. We should do something about it, this is 
probably a duplication of another bug with greenlets. This might be a release 
blocker for 2.0

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

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

From tracker at bugs.pypy.org  Tue Aug 21 21:18:15 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 21 Aug 2012 19:18:15 +0000
Subject: [pypy-issue] [issue1240] PyPy's evaluation of generator on
	list.extend() method	seems different from CPython
In-Reply-To: <1345466398.44.0.295959271189.issue1240@bugs.pypy.org>
Message-ID: <1345576695.62.0.79503823811.issue1240@bugs.pypy.org>


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

This is an implementation detail. You should not rely on this. That said we might 
still change our behavior to mimick cpython more, so I'm not closing it just now.

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

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

From tracker at bugs.pypy.org  Tue Aug 21 23:37:35 2012
From: tracker at bugs.pypy.org (viblo)
Date: Tue, 21 Aug 2012 21:37:35 +0000
Subject: [pypy-issue] [issue1237] pypy 2x slower than python on
	ctypes.Structure
In-Reply-To: <1345310498.32.0.773264370774.issue1237@bugs.pypy.org>
Message-ID: <1345585055.72.0.621178836229.issue1237@bugs.pypy.org>


viblo <pypy at viblo.se> added the comment:

Ok. Guess its just to wait a bit more until pypy is a good choice for pymunk then.


I tried a bit with cffi but Im not completely sure how to do a good comparison
really as I cant just do a  1 to 1 replacement.

Anyway, I did a try converting the attached benchmark (and expanded it a bit so
it measure the python-c bridge) to cffi and got these runtimes

10000 iterations
pypy ctypes:    3.59s
pypy cffi:      0.46s
cpython ctypes: 1.31s

20000 iterations
pypy ctypes:    6.20s (1.7x)
pypy cffi:      0.69s (1.5x)
cpython ctypes: 2.55s (1.9x)

Looking good for pypy and cffi I would say. Extra interesting that its the on
that slows down the least amount (%) by doubling the iterations.

(attached the code I used)

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

From tracker at bugs.pypy.org  Wed Aug 22 18:26:59 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 22 Aug 2012 16:26:59 +0000
Subject: [pypy-issue] [issue1234] Poor seek set performance (compared to
	cpython 2.7)
In-Reply-To: <1344847072.2.0.452643258492.issue1234@bugs.pypy.org>
Message-ID: <1345652819.04.0.747474010984.issue1234@bugs.pypy.org>


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

CPython actually uses fopen() and fread(), and probably does not need a system 
call when fseek() stays inside the in-memory buffer.

Can you try with the io module? Just use io.open() instead of open().

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

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

From tracker at bugs.pypy.org  Thu Aug 23 08:54:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 23 Aug 2012 06:54:02 +0000
Subject: [pypy-issue] [issue1234] Poor seek set performance (compared to
	cpython 2.7)
In-Reply-To: <1344847072.2.0.452643258492.issue1234@bugs.pypy.org>
Message-ID: <1345704842.43.0.610702218824.issue1234@bugs.pypy.org>


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

I tracked down the case and it seems that seek does simply trash the buffer even 
in cases where it does not need to.

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

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

From tracker at bugs.pypy.org  Thu Aug 23 14:12:32 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 23 Aug 2012 12:12:32 +0000
Subject: [pypy-issue] [issue1233] str() types can't be used with ctypes's
	py_object()
In-Reply-To: <1344763493.64.0.519996205744.issue1233@bugs.pypy.org>
Message-ID: <1345723952.21.0.250338709298.issue1233@bugs.pypy.org>


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

ctypes.py_object corresponds to the PyObject* pointer in C, which is not 
supported by pypy.
Which function are you trying to call? Why do you need py_object?

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

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

From tracker at bugs.pypy.org  Thu Aug 23 16:30:26 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Thu, 23 Aug 2012 14:30:26 +0000
Subject: [pypy-issue] [issue1241] [cpyext] PyUnicode_Tailmatch() fails to
	match with high	end bounds
In-Reply-To: <1345732226.32.0.922173740669.issue1241@bugs.pypy.org>
Message-ID: <1345732226.32.0.922173740669.issue1241@bugs.pypy.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

When calling PyUnicode_Tailmatch() with an end bound beyond the length of the
haystack string, the internal implementation incorrectly interprets that as the
length of the string and fails to match. This is because it directly calls
stringendswith(), whereas the Python level .endswith() method first crops the
bounds and only then calls into stringendswith().

I'm sure a similar situation can be constructed for the opposite direction that
calls stringstartswith().

----------
messages: 4670
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] PyUnicode_Tailmatch() fails to match with high end bounds

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

From tracker at bugs.pypy.org  Sat Aug 25 11:37:42 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 25 Aug 2012 09:37:42 +0000
Subject: [pypy-issue] [issue1241] [cpyext] PyUnicode_Tailmatch() fails to
	match with high	end bounds
In-Reply-To: <1345732226.32.0.922173740669.issue1241@bugs.pypy.org>
Message-ID: <1345887462.11.0.581118517436.issue1241@bugs.pypy.org>


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

A failing test would be great.

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

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

From tracker at bugs.pypy.org  Sat Aug 25 12:03:46 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Sat, 25 Aug 2012 10:03:46 +0000
Subject: [pypy-issue] [issue1241] [cpyext] PyUnicode_Tailmatch() fails to
	match with high	end bounds
In-Reply-To: <1345732226.32.0.922173740669.issue1241@bugs.pypy.org>
Message-ID: <1345889026.91.0.00837226047923.issue1241@bugs.pypy.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Here we go:

"""
diff -r 028b65a5a45f pypy/module/cpyext/test/test_unicodeobject.py
--- a/pypy/module/cpyext/test/test_unicodeobject.py     Wed Aug 22 19:57:33 2012
+0200
+++ b/pypy/module/cpyext/test/test_unicodeobject.py     Sat Aug 25 12:02:58 2012
+0200
@@ -496,11 +496,15 @@
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cde"), 2, 4, -1) == 0
# ends at 'd'
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cde"), 1, 6, -1) == 0
# starts at 'b'
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cdf"), 2, 6, -1) == 0
+        assert api.PyUnicode_Tailmatch(w_str, space.wrap("abc"), -10, 6, -1) == 1
+        assert api.PyUnicode_Tailmatch(w_str, space.wrap("abc"), -10, 60, -1) == 1
         # suffix match
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cde"), 1, 5,  1) == 1
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cde"), 3, 5,  1) == 0
# starts at 'd'
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("cde"), 1, 6,  1) == 0
# ends at 'f'
         assert api.PyUnicode_Tailmatch(w_str, space.wrap("bde"), 1, 5,  1) == 0
+        assert api.PyUnicode_Tailmatch(w_str, space.wrap("def"), 1, 99,  1) == 1
+        assert api.PyUnicode_Tailmatch(w_str, space.wrap("def"), -99, 99,  1) == 1
         # type checks
         self.raises(space, api, TypeError,
                     api.PyUnicode_Tailmatch, w_str, space.wrap(3), 2, 10, 1)
"""

CPython (3.3) uses this internally:

"""
#define ADJUST_INDICES(start, end, len)         \
    if (end > len)                              \
        end = len;                              \
    else if (end < 0) {                         \
        end += len;                             \
        if (end < 0)                            \
            end = 0;                            \
    }                                           \
    if (start < 0) {                            \
        start += len;                           \
        if (start < 0)                          \
            start = 0;                          \
    }

[...]
    ADJUST_INDICES(start, end, PyUnicode_GET_LENGTH(self));
"""

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

From tracker at bugs.pypy.org  Sat Aug 25 15:00:40 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Sat, 25 Aug 2012 13:00:40 +0000
Subject: [pypy-issue] [issue1242] lib_pypy/_ctypes/function.py
	accesses	_rawffi.get_last_error in linux
In-Reply-To: <1345899640.51.0.331465536862.issue1242@bugs.pypy.org>
Message-ID: <1345899640.51.0.331465536862.issue1242@bugs.pypy.org>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

When calling a C function of a library declared with
  use_last_error=True
on linux (where get_last_error does not exist), pypy raises whereas cpython just 
ignores the parameter.

(libusb1 is a CDLL instance)

  File "/home/vincent/git/python-libusb1/usb1.py", line 1566, in __init__
    result = libusb1.libusb_init(byref(context_p))
  File "/home/vincent/git/ITI1480A-linux/pypy-1.9/lib_pypy/_ctypes/function.py", 
line 699, in __call__
    result = self._call_funcptr(funcptr, *args)
  File "/home/vincent/git/ITI1480A-linux/pypy-1.9/lib_pypy/_ctypes/function.py", 
line 357, in _call_funcptr
    tmp = _rawffi.get_last_error()
AttributeError: 'module' object has no attribute 'get_last_error'

----------
messages: 4673
nosy: pypy-issue, vpelletier
priority: bug
release: 1.9
status: unread
title: lib_pypy/_ctypes/function.py accesses _rawffi.get_last_error in linux

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

From tracker at bugs.pypy.org  Sat Aug 25 15:19:37 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Sat, 25 Aug 2012 13:19:37 +0000
Subject: [pypy-issue] [issue1243] pypy ctypes rejects None when used to get
	a null-pointer
In-Reply-To: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>
Message-ID: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

pypy1.9:
>>>> import ctypes
>>>> class Foo(ctypes.Structure):
....   _fields_ = (('user_data', ctypes.py_object), )
.... 
>>>> a = Foo()
>>>> a.user_data = None
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/vincent/git/ITI1480A-linux/pypy-1.9/lib_pypy/_ctypes/structure.py", line 105, in __set__
    cobj = fieldtype.from_param(value)
  File "/home/vincent/git/ITI1480A-linux/pypy-1.9/lib_pypy/_ctypes/primitive.py", line 287, in from_param
    return super(SimpleType, self).from_param(value)
  File "/home/vincent/git/ITI1480A-linux/pypy-1.9/lib_pypy/_ctypes/basics.py", line 46, in from_param
    self.__name__, type(value).__name__))
TypeError: expected py_object instance instead of NoneType

cpython 2.7.3:
>>> import ctypes
>>> class Foo(ctypes.Structure):
...   _fields_ = (('user_data', ctypes.py_object), )
... 
>>> a = Foo()
>>> a.user_data = None

----------
messages: 4674
nosy: pypy-issue, vpelletier
priority: bug
status: unread
title: pypy ctypes rejects None when used to get a null-pointer

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

From tracker at bugs.pypy.org  Sat Aug 25 15:51:08 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Sat, 25 Aug 2012 13:51:08 +0000
Subject: [pypy-issue] [issue1243] pypy ctypes rejects None when used to get
	a null-pointer
In-Reply-To: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>
Message-ID: <1345902668.04.0.650561903802.issue1243@bugs.pypy.org>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

It seems this is limited to py_object type.
I worked around it with the following patch (but I don't pass anything besides 
None to this struct member, so it might be stupid).

diff -r 7a75bcc99f30 lib_pypy/_ctypes/primitive.py
--- a/lib_pypy/_ctypes/primitive.py     Fri Aug 24 11:37:23 2012 -0700
+++ b/lib_pypy/_ctypes/primitive.py     Sat Aug 25 15:49:57 2012 +0200
@@ -97,6 +97,7 @@
     'z': from_param_char_p,
     'Z': from_param_char_p,
     'P': from_param_void_p,
+    'O': from_param_void_p,
     }
 
 class SimpleType(_CDataMeta):

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

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

From tracker at bugs.pypy.org  Sat Aug 25 16:02:41 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 25 Aug 2012 14:02:41 +0000
Subject: [pypy-issue] [issue1243] pypy ctypes rejects None when used to get
	a null-pointer
In-Reply-To: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>
Message-ID: <1345903361.52.0.414925549548.issue1243@bugs.pypy.org>


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

'py_object' is mostly unsupported in ctypes.  If you're only going to store a
None there, just use 'c_void_p' instead.

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

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

From tracker at bugs.pypy.org  Sat Aug 25 16:11:09 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Sat, 25 Aug 2012 14:11:09 +0000
Subject: [pypy-issue] [issue1243] pypy ctypes rejects None when used to get
	a null-pointer
In-Reply-To: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>
Message-ID: <1345903869.17.0.979938252093.issue1243@bugs.pypy.org>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

Well, as a user of my own lib, I only store None there.
I know other users actually put python object in this field (under cpython 
AFAIK).

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

From tracker at bugs.pypy.org  Sat Aug 25 16:20:34 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 25 Aug 2012 14:20:34 +0000
Subject: [pypy-issue] [issue1243] pypy ctypes rejects None when used to get
	a null-pointer
In-Reply-To: <1345900777.92.0.527652310522.issue1243@bugs.pypy.org>
Message-ID: <1345904434.8.0.369789488535.issue1243@bugs.pypy.org>


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

It might be a problem, but one we know and don't necessarily feel like fixing:
py_object support.  Closing this issue anyway as a duplicate of
https://bugs.pypy.org/issue1233 .

----------
status: chatting -> duplicate

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

From tracker at bugs.pypy.org  Sun Aug 26 11:48:39 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Sun, 26 Aug 2012 09:48:39 +0000
Subject: [pypy-issue] [issue1242] lib_pypy/_ctypes/function.py
	accesses	_rawffi.get_last_error in linux
In-Reply-To: <1345899640.51.0.331465536862.issue1242@bugs.pypy.org>
Message-ID: <1345974519.64.0.779242050437.issue1242@bugs.pypy.org>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

Fix proposal.
My "optimise for cpython" sense tingle, but would patching the class after 
definition with the appropriate function be acceptable here (I think the two 
bools I add are mutually exclusive in practice) ?

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

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

From tracker at bugs.pypy.org  Sun Aug 26 12:19:36 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 26 Aug 2012 10:19:36 +0000
Subject: [pypy-issue] [issue1137] numpy: "TypeError: 'int32' has no length"
In-Reply-To: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>
Message-ID: <1345976376.77.0.766479908537.issue1137@bugs.pypy.org>


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

This seems to have been merged. Please test.

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

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

From tracker at bugs.pypy.org  Mon Aug 27 19:56:02 2012
From: tracker at bugs.pypy.org (Marcus von Appen)
Date: Mon, 27 Aug 2012 17:56:02 +0000
Subject: [pypy-issue] [issue1233] str() types can't be used with ctypes's
	py_object()
In-Reply-To: <1344763493.64.0.519996205744.issue1233@bugs.pypy.org>
Message-ID: <1346090162.32.0.51155775594.issue1233@bugs.pypy.org>


Marcus von Appen <mva at sysfault.org> added the comment:

The function is a C callback, which passes user data through on receiving 
events.

1) register callback with user data payload via CFUNCTYPE() capsule
2) Some C code executes
3) C code fires event, causing the (Python) callback to be raised
4) Python callback is invoked with the payload that was registered as argument.

Since the user can use an arbitrary payload in the callback, casting the data to 
c_void_p would require a safe conversion for each and every Python object and 
Python type, which - to my knowledge - is not supported by ctypes (at least in 
CPython).

py_object() comes in handy, when dealing with e.g. object()-based class 
instances, lists, dictionaries, ... to be used as user data argument.
Thus, wrapping a base type like str, int, ... into a py_object() would ease 
callback interactions with void* pass-throughs.

You can see such an example at 
http://code.google.com/p/pgreloaded/source/browse/pygame2/sdl/timer.py and 
http://code.google.com/p/pgreloaded/source/browse/pygame2/sdl/log.py

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

From tracker at bugs.pypy.org  Mon Aug 27 21:30:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 27 Aug 2012 19:30:29 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1346095829.22.0.847047381418.issue1116@bugs.pypy.org>


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

I tried to fix _io/interp_iobase.py as described, given that there were no
objection.  I can't really make a test or be sure it's the best solution because
I have no clue about the _io module in the first place :-/  Please complain here
if this doesn't fix the problem.

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

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

From tracker at bugs.pypy.org  Tue Aug 28 00:27:57 2012
From: tracker at bugs.pypy.org (eri)
Date: Mon, 27 Aug 2012 22:27:57 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1346106477.2.0.0488772358341.issue1116@bugs.pypy.org>


eri <oddghost at mail.ru> added the comment:

arigo, take a look of gzip.py, corrected as i discibed pypy passed attached test.

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

From tracker at bugs.pypy.org  Tue Aug 28 10:19:16 2012
From: tracker at bugs.pypy.org (dremon)
Date: Tue, 28 Aug 2012 08:19:16 +0000
Subject: [pypy-issue] [issue1245] Segfault with web.py and pyOpenSSLAdapter
In-Reply-To: <1346141956.16.0.0234783515857.issue1245@bugs.pypy.org>
Message-ID: <1346141956.16.0.0234783515857.issue1245@bugs.pypy.org>


New submission from dremon <dmitry at pankratov.net>:

When running the attached sample application with pypy trunk segfault occurs in
libcrypto.so.1.0.0.

This app uses web.py with pyopenssl adapter.

----------
files: test_httpservice.py
messages: 4685
nosy: dremon, pypy-issue
priority: bug
status: unread
title: Segfault with web.py and pyOpenSSLAdapter

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

From tracker at bugs.pypy.org  Wed Aug 29 20:02:07 2012
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 29 Aug 2012 18:02:07 +0000
Subject: [pypy-issue] [issue1246] pypy-c-jit-x-linux64 nightly tarball size
	jumped
In-Reply-To: <1346263327.85.0.6108374575.issue1246@bugs.pypy.org>
Message-ID: <1346263327.85.0.6108374575.issue1246@bugs.pypy.org>


New submission from bdk <bdkearns at gmail.com>:

The tarball size jumped from ~13M -> ~17M between 8/23 and 8/28. Seems unexpected? 
Other variants didn't have a corresponding jump. Maybe it would be worthwhile to 
have a test that compares final generated size vs min or avg of past x builds?

----------
messages: 4686
nosy: bdk, pypy-issue
priority: bug
status: unread
title: pypy-c-jit-x-linux64 nightly tarball size jumped

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

From tracker at bugs.pypy.org  Wed Aug 29 20:06:00 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 29 Aug 2012 18:06:00 +0000
Subject: [pypy-issue] [issue1246] pypy-c-jit-x-linux64 nightly tarball size
	jumped
In-Reply-To: <1346263327.85.0.6108374575.issue1246@bugs.pypy.org>
Message-ID: <1346263560.61.0.607113555748.issue1246@bugs.pypy.org>


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

Maybe the fact that we updated the machine with a newer version of gcc is enough
of an explanation?  The C code sent to gcc is very unusual, so I wouldn't be too
surprized if gcc optimizes it differently in more recent versions, e.g. causing
large-scale inlining or something.  Still, we'd need to check in more details.

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

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

From tracker at bugs.pypy.org  Thu Aug 30 23:19:53 2012
From: tracker at bugs.pypy.org (Erik Allik)
Date: Thu, 30 Aug 2012 21:19:53 +0000
Subject: [pypy-issue] [issue1247] Indexing into a tuple literal with an
	ellipsis crashes
In-Reply-To: <1346361593.44.0.94844553257.issue1247@bugs.pypy.org>
Message-ID: <1346361593.44.0.94844553257.issue1247@bugs.pypy.org>


New submission from Erik Allik <eallik at gmail.com>:

$ ipython
In [1]: ()[...]
RPython traceback:
  File "interpreter_pycompiler.c", line 1691, in PythonAstCompiler__compile_ast
  File "interpreter_astcompiler_ast_2.c", line 56953, in Module_mutate_over
  File "interpreter_astcompiler_ast.c", line 22049, in 
ASTVisitor__mutate_sequence
  File "interpreter_astcompiler_ast_2.c", line 38903, in Expr_mutate_over
  File "interpreter_astcompiler_optimize.c", line 2557, in 
OptimizingVisitor_visit_Subscript
  File "interpreter_astcompiler_optimize.c", line 225, in AST_as_constant
Fatal RPython error: AssertionError
Abort trap: 6


same on the plain console, except on the plain console, the traceback is badly 
formatted.

storing the tuple in a variable and then indexing works properly:

TypeError: tuple index must be an integer, not Ellipsis

----------
messages: 4688
nosy: eallik, pypy-issue
priority: bug
status: unread
title: Indexing into a tuple literal with an ellipsis crashes

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

From tracker at bugs.pypy.org  Fri Aug 31 12:35:12 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 31 Aug 2012 10:35:12 +0000
Subject: [pypy-issue] [issue1247] Indexing into a tuple literal with an
	ellipsis crashes
In-Reply-To: <1346361593.44.0.94844553257.issue1247@bugs.pypy.org>
Message-ID: <1346409312.14.0.505534920524.issue1247@bugs.pypy.org>


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

Fixed (aba0616c4c1b), thanks!

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

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