From tracker at bugs.pypy.org  Thu Nov  1 00:33:34 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Wed, 31 Oct 2012 23:33:34 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351726414.02.0.640432724086.issue1309@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

The attached patch includes the following changes:
1. Define BYTEORDER in rbigint - used to determine if endianswap is needed
2. Fix frombytes, update to support endianswap. Still lacking support for signed input.
3. Implement tobytes, supporting endianswap. Lacks support for signed output.
4. Add descr_to_bytes wrapper, which carefully ignores the nbytes argument, wrap call to frombytes in try block, and properly raise ValueError on incorrect use of byteorder argument.
5. Delete _x_mul redefinition.
6. Extend rbigint unittest to test potentially problematic input, as well as endianswap

Todo:
1. Handle the nbytes argument. CPython throws an OverflowError if we exceed nbytes on to_bytes().
2. Handle signed input/output. When this is done, pickling of longs in py3k will be up and running. (It can pickle/unpickle locally, but it's unaware that it's actually working with unsigned values, despite requesting 
otherwise). For frombytes, this is something along the lines of:
   if firstbyte: # We're dealing with the first byte
      sign = -1 if c >> 7 else 1
      c &= 0x7F

for tobytes, something along the lines of:
   # Prior to entering the loop
   accum = 1 if sign == -1 else 0
   accumbits += 1

... or something like that.
3. Cleanup. This is the first time I have messed around with PyPy, and I have guessed my way to how most things work. I might be doing something really stupid somewhere, and there might be a coding convention I failed 
to comply to...

Notes for cleanup:
1. I was going to conditionally define an append function - depending on byteswap . in tobytes, but while 2 identical if's look stupid, it just seemed like quite the overkill.
2. the accum |= c << accumbits results in the requirement of c being widened to the LONGTYPE, as c can end up being shifted SHIFT-1 to the left, exceding the limit of a r_uint. Using something along the lines of accum 
= (accum << 8) | c would save the LONGTYPE, but I couldn't quite get 'er working that way... Heheh.
3. frombytes/tobytes take a string for little/big endian. It would probably be easier to handle that conversion up higher, while to/frombytes simply took bool or something.

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

From tracker at bugs.pypy.org  Thu Nov  1 04:15:39 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Thu, 01 Nov 2012 03:15:39 +0000
Subject: [pypy-issue] [issue1119] Py_GetArgcArgv not exposed
In-Reply-To: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>
Message-ID: <1351739739.16.0.856736022547.issue1119@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

Ran into this also.

The argv clobbering done by many of these libraries is kind of ghetto in the 
first place. While Linux-specific, exposing prctl(2) would be nice for 
PR_{GET,SET}_NAME.

Is there any precedent for pypy exposing new functionality that isn't present in 
upstream cpython? IIRC, upstream punting on exposing prcrtl.

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

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

From tracker at bugs.pypy.org  Thu Nov  1 04:17:59 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Thu, 01 Nov 2012 03:17:59 +0000
Subject: [pypy-issue] [issue1284] segfault with pypy 1.9, pyopenssl 0.13
In-Reply-To: <1349898700.08.0.761989216783.issue1284@bugs.pypy.org>
Message-ID: <1351739879.17.0.797607595341.issue1284@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

This appears to be resolved in a recent nightly. Should this be closed?

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

From tracker at bugs.pypy.org  Thu Nov  1 05:52:07 2012
From: tracker at bugs.pypy.org (dktc)
Date: Thu, 01 Nov 2012 04:52:07 +0000
Subject: [pypy-issue] [issue1119] Py_GetArgcArgv not exposed
In-Reply-To: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>
Message-ID: <1351745527.36.0.105974081237.issue1119@bugs.pypy.org>


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

I got the same problem on PyPy 1.9. Does anyone have any thoughts on how to solve this?

>>>> import procname
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ImportError: unable to load extension module '/opt/pypy-1.9/site-packages/procname.pypy-19.so': 
/opt/pypy-1.9/site-packages/procname.pypy-19.so: undefined symbol: Py_GetArgcArgv
>>>>

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

From tracker at bugs.pypy.org  Thu Nov  1 15:44:13 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Thu, 01 Nov 2012 14:44:13 +0000
Subject: [pypy-issue] [issue1119] Py_GetArgcArgv not exposed
In-Reply-To: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>
Message-ID: <1351781053.13.0.470835447987.issue1119@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

dktc: pypy doesn't implement the Py_GetArgcArgv private API that cpython does.

I imagine it would be pretty easy to add to pypy (basically just stash the 
argc/argc during main() and return it later), but I don't know pypy internals 
and it's more likely a policy issue if pypy is interested in implementing 
private cpython API calls.

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

From tracker at bugs.pypy.org  Thu Nov  1 17:12:47 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 01 Nov 2012 16:12:47 +0000
Subject: [pypy-issue] [issue1284] segfault with pypy 1.9, pyopenssl 0.13
In-Reply-To: <1349898700.08.0.761989216783.issue1284@bugs.pypy.org>
Message-ID: <1351786367.34.0.404825463237.issue1284@bugs.pypy.org>


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

If it's fixed then yes. I'm closing, reopen if it's not.

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

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

From tracker at bugs.pypy.org  Thu Nov  1 21:05:24 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Thu, 01 Nov 2012 20:05:24 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351800324.05.0.831189017409.issue1309@bugs.pypy.org>


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

Here's a few very minor changes. other than that it looks good so far. I suppose 
you might even want an append function to help in handling the nbytes/overflow

----------
nosy: +pjenvey

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

From tracker at bugs.pypy.org  Fri Nov  2 10:52:50 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 02 Nov 2012 09:52:50 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1351849970.18.0.67530166227.issue920@bugs.pypy.org>


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

I don't understand what was "resolved" or is "not a bug" about this issue.  As
far as I can tell, it's really a bug (as in we behave differently than CPython)
and we did nothing about it so far.

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

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

From tracker at bugs.pypy.org  Fri Nov  2 11:42:38 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 02 Nov 2012 10:42:38 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1351852958.5.0.459330983978.issue920@bugs.pypy.org>


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

Minimal test and fix in c048b7d88060 and de9dbd9479cd.

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

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

From tracker at bugs.pypy.org  Fri Nov  2 12:39:27 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Fri, 02 Nov 2012 11:39:27 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351856367.78.0.549073999935.issue1309@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

pjenvey: Thanks for the feedback! Had a DO'H moment or 2 after seeing your 
patch... ;)

However, using space.wrap() instead of manually constructing a new 
W_StringObject threw some complaints about non-ASCII characters, so I went back 
to StringObject temporarily (but should probably do a proper allocation into 
space)

Is there a way to make the wrapper accept non-ascii bytestring, or is the manual 
allocation the solution?

I have sign support running in interpreted mode - I have a few translation 
issues to solve, but it'll be done today. I think. (flowing errors)

(I shed a few tears as to how much more complicated my tobytes function 
became... :'( )

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

From tracker at bugs.pypy.org  Fri Nov  2 22:57:39 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 02 Nov 2012 21:57:39 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351893459.15.0.287996709817.issue1309@bugs.pypy.org>


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

joushou: space.wrap() will convert a RPython (bytes) string into a 
W_UnicodeObject. You should use space.wrapbytes() instead.
And please rename the variable "bigint": it's not a bigint, but a bytes string.

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Fri Nov  2 23:32:26 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Fri, 02 Nov 2012 22:32:26 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351895546.17.0.97984689688.issue1309@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

I have tested the following patch with some very large random positve and 
negative numbers, as well as byte strings that I knew caused me problems 
previously - I'm capable of pickling on pypy3k and unpickle on cpy3k, and of 
course also the other way around.

tobytes became a little more complicated than I had wished for, and will probably 
be subject to cleaning later (by me, when it makes me itch hard enough. ;) )

----------
status: in-progress -> testing

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

From tracker at bugs.pypy.org  Sat Nov  3 01:11:45 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Sat, 03 Nov 2012 00:11:45 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351901505.48.0.0787074385365.issue1309@bugs.pypy.org>


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

applied in 74d461f1edfd, and I added a few more test_rbigint tests in 
cc896f4fb846. Thanks!, can't wait to see how this affects the stdlib tests on the 
next buildbot run

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

From tracker at bugs.pypy.org  Sat Nov  3 01:46:23 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Sat, 03 Nov 2012 00:46:23 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351903583.65.0.951884283615.issue1309@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

I have attached a slight tweak to longtype.py, which defaults signed to False. 
This is required for compatibility with cpython, as well as with things like 
random.py, which doesn't set signed.

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

From tracker at bugs.pypy.org  Sat Nov  3 16:06:35 2012
From: tracker at bugs.pypy.org (Tristan Seligmann)
Date: Sat, 03 Nov 2012 15:06:35 +0000
Subject: [pypy-issue] [issue1313] IntegrityError: PRIMARY KEY must be unique
In-Reply-To: <1351955195.78.0.872370514516.issue1313@bugs.pypy.org>
Message-ID: <1351955195.78.0.872370514516.issue1313@bugs.pypy.org>


New submission from Tristan Seligmann <mithrandi at mithrandi.net>:

sqlite3 module seems to be broken; I'm attaching a test case.

----------
messages: 4961
nosy: mithrandi, pypy-issue
priority: bug
status: unread
title: IntegrityError: PRIMARY KEY must be unique

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

From tracker at bugs.pypy.org  Sat Nov  3 18:14:58 2012
From: tracker at bugs.pypy.org (Fabimaru)
Date: Sat, 03 Nov 2012 17:14:58 +0000
Subject: [pypy-issue] [issue1314] expat parser should read file by chunks
In-Reply-To: <1351962898.59.0.456401197968.issue1314@bugs.pypy.org>
Message-ID: <1351962898.59.0.456401197968.issue1314@bugs.pypy.org>


New submission from Fabimaru <fabsk at free.fr>:

In the module xml.parsers.expat, when calling the method "ParseFile", the method
"Read" of the source is called with no parameter, so it read the whole file in
one call. It could use a lot of memory if the source is huge, or fail to process
an endless source.

PythonC (2.7 and 3.3) reads 2048 bytes at a time.

http://hg.python.org/cpython/file/c6237edff631/Modules/pyexpat.c#l854

----------
messages: 4962
nosy: Fabimaru, pypy-issue
priority: bug
release: 1.9
status: unread
title: expat parser should read file by chunks

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

From tracker at bugs.pypy.org  Sat Nov  3 19:41:55 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Sat, 03 Nov 2012 18:41:55 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351968115.59.0.374588398041.issue1309@bugs.pypy.org>


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

I fixed this in 2d96b0512485 as well as adding some more tests

----------
status: testing -> resolved

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

From tracker at bugs.pypy.org  Sun Nov  4 17:05:06 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 04 Nov 2012 16:05:06 +0000
Subject: [pypy-issue] [issue1313] IntegrityError: PRIMARY KEY must be unique
In-Reply-To: <1351955195.78.0.872370514516.issue1313@bugs.pypy.org>
Message-ID: <1352045106.52.0.500671282328.issue1313@bugs.pypy.org>


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

When cursor is an insert statement, list(cursor) would execute it twice :-(
Fixed in afc480fa7162, thanks for the report and the test case!

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

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

From tracker at bugs.pypy.org  Sun Nov  4 17:12:24 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 04 Nov 2012 16:12:24 +0000
Subject: [pypy-issue] [issue1314] expat parser should read file by chunks
In-Reply-To: <1351962898.59.0.456401197968.issue1314@bugs.pypy.org>
Message-ID: <1352045544.33.0.428826478805.issue1314@bugs.pypy.org>


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

tag: easy

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

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

From tracker at bugs.pypy.org  Tue Nov  6 10:10:56 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Nov 2012 09:10:56 +0000
Subject: [pypy-issue] [issue1288] CPython executes code significantly faster
In-Reply-To: <1350143013.15.0.0415390287387.issue1288@bugs.pypy.org>
Message-ID: <1352193056.4.0.778586303466.issue1288@bugs.pypy.org>


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

I ran your script in a loop: 10'000 times instead of just once, the part between
"function_found = False" and the end.  I measured about 1.0 second with pypy 1.9
and 3.7 seconds with python 2.7.  So it's again a matter of warm-up time.

----------
status: chatting -> invalid

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

From tracker at bugs.pypy.org  Tue Nov  6 19:25:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 06 Nov 2012 18:25:02 +0000
Subject: [pypy-issue] [issue1315] exec should change it's globals dict to
	CellDict
In-Reply-To: <1352226302.09.0.146503617709.issue1315@bugs.pypy.org>
Message-ID: <1352226302.09.0.146503617709.issue1315@bugs.pypy.org>


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

it would be very handy if whatever is passed to exec as globals upgrades it's 
implementation to CellDict

----------
messages: 4967
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: exec should change it's globals dict to CellDict

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

From tracker at bugs.pypy.org  Wed Nov  7 11:54:53 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 07 Nov 2012 10:54:53 +0000
Subject: [pypy-issue] [issue1316] fix the namedtuple slowness
In-Reply-To: <1352285693.77.0.17840508792.issue1316@bugs.pypy.org>
Message-ID: <1352285693.77.0.17840508792.issue1316@bugs.pypy.org>


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

Additionally to 1315 this is a program where we would liek to prove 0 is a 
constant:


def wrapper(num):
    def func(x):
        return x[num]
    return func

x = wrapper(0)

def f():
    t = (1, 2, 3)
    for _ in range(10000000):
        x(t)

f()

----------
messages: 4968
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: fix the namedtuple slowness

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

From tracker at bugs.pypy.org  Wed Nov  7 18:57:57 2012
From: tracker at bugs.pypy.org (Al Korgun)
Date: Wed, 07 Nov 2012 17:57:57 +0000
Subject: [pypy-issue] [issue1317] os.popen & operator "with"
In-Reply-To: <1352311077.88.0.191024702386.issue1317@bugs.pypy.org>
Message-ID: <1352311077.88.0.191024702386.issue1317@bugs.pypy.org>


New submission from Al Korgun <alkorgun at gmail.com>:

>>>> import os
>>>> with os.popen("blah-blah") as pipe:
....   print pipe
....
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: '_wrap_close' object is not a context manager (no __enter__/__ex
it__ method)

- this is really necessary feature.

----------
messages: 4969
nosy: pypy-issue
priority: feature
release: 1.9
status: unread
title: os.popen & operator "with"

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

From tracker at bugs.pypy.org  Wed Nov  7 19:33:51 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 07 Nov 2012 18:33:51 +0000
Subject: [pypy-issue] [issue1317] os.popen & operator "with"
In-Reply-To: <1352311077.88.0.191024702386.issue1317@bugs.pypy.org>
Message-ID: <1352313231.46.0.48145205664.issue1317@bugs.pypy.org>


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

A workaround is to use "contextlib.closing":

>>>> import os, contextlib
>>>> with contextlib.closing(os.popen("blah-blah")) as pipe:
....     print pipe

It's probably a win32-only issue; fix should go to module/posix/app_posix.py.
tag:easy

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

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

From tracker at bugs.pypy.org  Wed Nov  7 21:56:01 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Wed, 07 Nov 2012 20:56:01 +0000
Subject: [pypy-issue] [issue1317] os.popen & operator "with"
In-Reply-To: <1352311077.88.0.191024702386.issue1317@bugs.pypy.org>
Message-ID: <1352321761.29.0.500709834971.issue1317@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

implemented in 6dd69be8f6a5, waiting for success of the buildbot

----------
nosy: +ronny

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

From tracker at bugs.pypy.org  Fri Nov  9 16:32:44 2012
From: tracker at bugs.pypy.org (Yuriy)
Date: Fri, 09 Nov 2012 15:32:44 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>


New submission from Yuriy <yuriym at toroki.com>:

When I try to sniff stp packets using Scapy, I get an 'Invalid argument' error.

Steps:

ttt at ttt:~/Downloads/scapy/scapy-2.1.0$ sudo pypy
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Nov 08 2012, 17:01:35)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``"[it] just shows again that
rpython is obscure" (cfbolz)''
>>>> import scapy.all as scapy
WARNING: No route found for IPv6 destination :: (no default route?)
>>>> scapy.sniff(iface="eth1", filter="stp", prn=lambda x: x.display)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "scapy/sendrecv.py", line 550, in sniff
    s = L2socket(type=ETH_P_ALL, *arg, **karg)
  File "scapy/arch/linux.py", line 460, in __init__
    attach_filter(self.ins, filter)
  File "scapy/arch/linux.py", line 132, in attach_filter
    s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpfh)
  File "<string>", line 1, in setsockopt
error: [Errno 22] Invalid argument

However it works with Python

----------
messages: 4972
nosy: pypy-issue, ymarkevy
priority: bug
status: unread
title: Scapy.sniff returns an error

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

From tracker at bugs.pypy.org  Fri Nov  9 17:07:07 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 09 Nov 2012 16:07:07 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352477227.49.0.715741930597.issue1318@bugs.pypy.org>


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

>From scapy/arch/linux.py::
    # XXX. Argl! We need to give the kernel a pointer on the BPF,
    # python object header seems to be 20 bytes. 36 bytes for x86 64bits arch.
    if scapy.arch.X86_64:
        bpfh = struct.pack("HL", nb, id(bpf)+36)
    else:
        bpfh = struct.pack("HI", nb, id(bpf)+20) 
    s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpfh)

This kind of code won't work at all with PyPy: the object layout is very different, id(bpf) is not 
the address of the object, and PyPy moves objects anyway.
I don't know why the code is written like this - setsockopt() accepts a string.
Would the following work?
   # (remove all the bpfh stuff)
   s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpf)

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

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

From tracker at bugs.pypy.org  Fri Nov  9 17:18:37 2012
From: tracker at bugs.pypy.org (Yuriy)
Date: Fri, 09 Nov 2012 16:18:37 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352477917.17.0.46134483374.issue1318@bugs.pypy.org>


Yuriy <yuriym at toroki.com> added the comment:

I'd try but received new error:

>>>> scapy.sniff(iface="eth1", filter="stp", prn=lambda x: x.display)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "scapy/sendrecv.py", line 550, in sniff
    s = L2socket(type=ETH_P_ALL, *arg, **karg)
  File "scapy/arch/linux.py", line 460, in __init__
    if iface is None:
  File "scapy/arch/linux.py", line 131, in attach_filter
    mreq = struct.pack("IHH8s", get_if_index(iff), PACKET_MR_PROMISC, 0, "")
ValueError: cannot convert negative integer to unsigned

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

From tracker at bugs.pypy.org  Fri Nov  9 18:42:43 2012
From: tracker at bugs.pypy.org (Yuriy)
Date: Fri, 09 Nov 2012 17:42:43 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352482963.03.0.490135840018.issue1318@bugs.pypy.org>


Yuriy <yuriym at toroki.com> added the comment:

I'd tried but received new error:

>>>> scapy.sniff(iface="eth1", filter="stp", prn=lambda x: x.display)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "scapy/sendrecv.py", line 550, in sniff
    s = L2socket(type=ETH_P_ALL, *arg, **karg)
  File "scapy/arch/linux.py", line 460, in __init__
    if iface is None:
  File "scapy/arch/linux.py", line 131, in attach_filter
    mreq = struct.pack("IHH8s", get_if_index(iff), PACKET_MR_PROMISC, 0, "")
ValueError: cannot convert negative integer to unsigned

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

From tracker at bugs.pypy.org  Fri Nov  9 19:21:09 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 09 Nov 2012 18:21:09 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352485269.0.0.00619149221133.issue1318@bugs.pypy.org>


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

The traceback you show does not correspond to what's executed.  Try deleting all .pyc files.

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

From tracker at bugs.pypy.org  Mon Nov 12 02:58:55 2012
From: tracker at bugs.pypy.org (Adam Sherwin)
Date: Mon, 12 Nov 2012 01:58:55 +0000
Subject: [pypy-issue] [issue1319] PyPy 1000x slower than CPython for
	set.difference_update
In-Reply-To: <1352685535.13.0.315074669122.issue1319@bugs.pypy.org>
Message-ID: <1352685535.13.0.315074669122.issue1319@bugs.pypy.org>


New submission from Adam Sherwin <absherwin at gmail.com>:

Here's a small example that illustrates the problem:

aset=set(range(100000))
evens=[x for x in aset if not x%2]
for i in evens: aset.difference_update(set([i]))

This ran in 84ms in CPython 2.7.2 and 115s in PyPy 1.9.0.

Let me know if I can provide any more information or otherwise be helpful in 
resolving this.

----------
messages: 4977
nosy: absherwin, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: PyPy 1000x slower than CPython for set.difference_update

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

From tracker at bugs.pypy.org  Mon Nov 12 03:44:12 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 12 Nov 2012 02:44:12 +0000
Subject: [pypy-issue] [issue1319] PyPy 1000x slower than CPython for
	set.difference_update
In-Reply-To: <1352685535.13.0.315074669122.issue1319@bugs.pypy.org>
Message-ID: <1352688252.68.0.634906175633.issue1319@bugs.pypy.org>


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

I'm not sure if this is the cause of the slowdown, but as far as I can tell 
difference_update allocates a new set object internally, even though that's not 
necessary.

In retrospect I'm 99% sure that's the cause :(

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

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

From tracker at bugs.pypy.org  Mon Nov 12 20:15:08 2012
From: tracker at bugs.pypy.org (Remi)
Date: Mon, 12 Nov 2012 19:15:08 +0000
Subject: [pypy-issue] [issue1320] stm-thread-2: assertion failed when
	starting huge amount	of threads
In-Reply-To: <1352747708.34.0.794028002303.issue1320@bugs.pypy.org>
Message-ID: <1352747708.34.0.794028002303.issue1320@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Here is the small example:
------------------------------
from threading import Thread
def parallel():
    t1 = Thread(target=parallel)
    t2 = Thread(target=parallel)
    t1.start()
    t2.start()
    t1.join()
    t2.join()
parallel()
------------------------------
Output after ~500 threads started:
pypy-stm: /home/remi/programming/pypy/pypy/translator/stm/src_stm/et.c:375: 
AbortTransaction: Assertion `!is_inevitable(d)' failed.
Aborted (core dumped)
------------------------------
The problem seems to come from starting thread 1 and 2 at the same time. If we 
only start 1 thread, the program happily runs out of memory with >1000 threads.

----------
messages: 4979
nosy: Remi, pypy-issue
priority: bug
status: unread
title: stm-thread-2: assertion failed when starting huge amount of threads

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

From tracker at bugs.pypy.org  Mon Nov 12 20:34:35 2012
From: tracker at bugs.pypy.org (Remi)
Date: Mon, 12 Nov 2012 19:34:35 +0000
Subject: [pypy-issue] [issue1321] stm-thread-2: print within atomic deadlocks
In-Reply-To: <1352748875.05.0.210423680192.issue1321@bugs.pypy.org>
Message-ID: <1352748875.05.0.210423680192.issue1321@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Small example:
----------------------------
import transaction
def bla(i):
    while True:
        print "hi from", i
transaction.set_num_threads(4)
transaction.add(bla, 1)
transaction.add(bla, 2)
transaction.add(bla, 3)
transaction.add(bla, 4)
transaction.run()
----------------------------
Output: Deadlocks or:
error: deadlock: an atomic transaction tries to acquire a lock that is already 
acquired.  See pypy/doc/stm.rst.
----------------------------
Since the output of 2 transactions is sometimes interleaved, this probably 
happens because we do not become inevitable properly when printing to stdout.

----------
messages: 4980
nosy: Remi, pypy-issue
priority: bug
status: unread
title: stm-thread-2: print within atomic deadlocks

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

From tracker at bugs.pypy.org  Mon Nov 12 23:02:50 2012
From: tracker at bugs.pypy.org (Paul)
Date: Mon, 12 Nov 2012 22:02:50 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>


New submission from Paul <poalman at gmail.com>:

After I install pyOpenSSL (I've tried 0.11, 0.13 from easy_install and from the setup.py) both importing twisted reactor and txaws S3Client both give segmentation 
faults, however importing SSL/crypto from OpenSSL dooesn't.

I can get to the point with these commands:

tar xvfj pypy-1.9-linux64.tar.bz2
cd setuptools-0.6c11
pypy setup.py install
cd ..
pypy -m easy_install twisted
pypy -m easy_install txaws

Then installing OpenSSL seems to cause the issue:

[root at ip-00-00-00-00 ec2-user]# pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``When your hammer is C++,
everything begins to look like a thumb.''
>>>> from txaws.s3.client import S3Client
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/ec2-user/pypy-1.9/site-packages/txAWS-0.2.3-py2.7.egg/txaws/s3/client.py", line 21, in <module>
    from txaws.client.base import BaseClient, BaseQuery, error_wrapper
  File "/home/ec2-user/pypy-1.9/site-packages/txAWS-0.2.3-py2.7.egg/txaws/client/base.py", line 6, in <module>
    from twisted.internet.ssl import ClientContextFactory
  File "/home/ec2-user/pypy-1.9/site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/ssl.py", line 23, in <module>
    from OpenSSL import SSL
ImportError: No module named OpenSSL
>>>> from twisted.internet import reactor
>>>> 
>>>> 
[root at ip-00-00-00-00 ec2-user]# pypy -m easy_install pyOpenSSL
Searching for pyOpenSSL
Reading http://pypi.python.org/simple/pyOpenSSL/
Reading http://pyopenssl.sourceforge.net/
Reading http://launchpad.net/pyopenssl
Best match: pyOpenSSL 0.13
Downloading http://pypi.python.org/packages/source/p/pyOpenSSL/pyOpenSSL-0.13.tar.gz#md5=767bca18a71178ca353dff9e10941929
Processing pyOpenSSL-0.13.tar.gz
Running pyOpenSSL-0.13/setup.py -q bdist_egg --dist-dir /tmp/easy_install-EqJI7O/pyOpenSSL-0.13/egg-dist-tmp-iAmAfi
warning: no previously-included files matching '*.pyc' found anywhere in distribution
Adding pyOpenSSL 0.13 to easy-install.pth file

Installed /home/ec2-user/pypy-1.9/site-packages/pyOpenSSL-0.13-py2.7-linux-x86_64.egg
Processing dependencies for pyOpenSSL
Finished processing dependencies for pyOpenSSL

[root at ip-00-00-00-00 ec2-user]# pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy and CPython: they are mortal
enemies intent on killing each other''
>>>> from twisted.internet import reactor
Segmentation fault

[root at ip-00-00-00-00 ec2-user]# pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``I want a green triangular yellow
pony''
>>>> from txaws.s3.client import S3Client
Segmentation fault

[root at ip-00-00-00-00 ec2-user]# pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
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''
>>>> from OpenSSL import SSL
>>>> from OpenSSL import crypto
>>>> 


If you need any more system information I'd be happy to give it!

----------
messages: 4981
nosy: gp89, pypy-issue
priority: bug
release: 1.9
status: unread
title: installing pyOpenSSL causes importing twisted reactor and txaws S3Client to seg fault

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

From tracker at bugs.pypy.org  Tue Nov 13 08:46:14 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 13 Nov 2012 07:46:14 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352792774.29.0.467713729173.issue1322@bugs.pypy.org>


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

PyPy 1.9 does not work with pyopenssl. Try installing a newer PyPy (we're about 
to release 2.0 beta 1 though). Reopen if it fails with never pypy

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

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

From tracker at bugs.pypy.org  Tue Nov 13 10:22:52 2012
From: tracker at bugs.pypy.org (Yuriy)
Date: Tue, 13 Nov 2012 09:22:52 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352798572.16.0.351071105833.issue1318@bugs.pypy.org>


Yuriy <yuriym at toroki.com> added the comment:

I'd removed all .pyc files but received the same error:

File "scapy/arch/linux.py", line 132, in attach_filter
    s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpfh)
  File "<string>", line 1, in setsockopt
error: [Errno 22] Invalid argument

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

From tracker at bugs.pypy.org  Tue Nov 13 10:23:11 2012
From: tracker at bugs.pypy.org (Yuriy)
Date: Tue, 13 Nov 2012 09:23:11 +0000
Subject: [pypy-issue] [issue1318] Scapy.sniff returns an error
In-Reply-To: <1352475164.85.0.554690691633.issue1318@bugs.pypy.org>
Message-ID: <1352798591.44.0.497688952642.issue1318@bugs.pypy.org>


Yuriy <yuriym at toroki.com> added the comment:

I'd removed all .pyc files but received the same error:

File "scapy/arch/linux.py", line 132, in attach_filter
    s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpf)
  File "<string>", line 1, in setsockopt
error: [Errno 22] Invalid argument

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

From tracker at bugs.pypy.org  Tue Nov 13 12:01:14 2012
From: tracker at bugs.pypy.org (Paul)
Date: Tue, 13 Nov 2012 11:01:14 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352804474.85.0.671578319761.issue1322@bugs.pypy.org>


Paul <poalman at gmail.com> added the comment:

Ah ok I didn't know that.

Why in that case can I import reactor from twisted before installing pyopenssl, 
but it seg faults afterwards?

It's likely I don't fully understand what's happening, but it seems strange to 
me that when I import OpenSSL it's fine but when txaws S3Client does it seg 
faults and even more weirdly twisted reactor seg faults even though it doesn't 
touch OpenSSL.

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

From tracker at bugs.pypy.org  Tue Nov 13 12:49:05 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 13 Nov 2012 11:49:05 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352807345.38.0.163823557683.issue1322@bugs.pypy.org>


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

segfaults generally can happen at any time. I'm sure someone touches something 
simply. I wouldn't sweat over trying to predict the exact cause.

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

From tracker at bugs.pypy.org  Tue Nov 13 12:50:41 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 13 Nov 2012 11:50:41 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352807441.26.0.821246747403.issue1322@bugs.pypy.org>


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

Probably because twisted itself conditionally imports OpenSSL. When OpenSSL is 
absent, no ssl code is executed, but when OpenSSL is installed, twisted tries to 
use it, and segfaults.

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Tue Nov 13 16:28:19 2012
From: tracker at bugs.pypy.org (Paul)
Date: Tue, 13 Nov 2012 15:28:19 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352820499.43.0.741582378323.issue1322@bugs.pypy.org>


Paul <poalman at gmail.com> added the comment:

fijal where can I get a newer version than 1.9?

----------
status: invalid -> unread

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

From tracker at bugs.pypy.org  Tue Nov 13 16:36:24 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 13 Nov 2012 15:36:24 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352820984.95.0.85169603835.issue1322@bugs.pypy.org>


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

http://buildbot.pypy.org/nightly/trunk/, http://baroquesoftware.com/nightlies/ 
compile it from source or wait for 2.0 beta. Note that it's all nicely 
documented.

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

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

From tracker at bugs.pypy.org  Tue Nov 13 18:58:30 2012
From: tracker at bugs.pypy.org (Paul)
Date: Tue, 13 Nov 2012 17:58:30 +0000
Subject: [pypy-issue] [issue1322] installing pyOpenSSL causes importing
	twisted reactor and	txaws S3Client to seg fault
In-Reply-To: <1352757770.76.0.627865420192.issue1322@bugs.pypy.org>
Message-ID: <1352829510.93.0.31466166731.issue1322@bugs.pypy.org>


Paul <poalman at gmail.com> added the comment:

I can confirm that this is working on the latest build (Python 2.7.3 
(6e0b9834843b, Nov 13 2012, 13:00:43) [PyPy 1.9.1-dev0 with GCC 4.7.1] on linux2)

Thanks!

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

From tracker at bugs.pypy.org  Tue Nov 13 20:39:13 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Tue, 13 Nov 2012 19:39:13 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>


New submission from Kenny Levinsen <kennylevinsen at gmail.com>:

The attached code should wait 1 second (through the call to sleep), and does so 
when run by CPython. In PyPy on OS X (10.8.2), however, it hangs.

Commenting in the print line at the beginning of the sleep function makes it 
work, which makes things very confusing.

----------
messages: 4991
nosy: joushou, pypy-issue
priority: bug
status: unread
title: subprocess.call, threading.Thread and OS X does not complete

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

From tracker at bugs.pypy.org  Tue Nov 13 20:39:49 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Tue, 13 Nov 2012 19:39:49 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1352835589.75.0.230557780293.issue1323@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

This additional test returns only 1 out of the 10 threads.

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

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

From tracker at bugs.pypy.org  Tue Nov 13 20:40:29 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Tue, 13 Nov 2012 19:40:29 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1352835629.97.0.408466489487.issue1323@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

Apparently the orignal simple test didn't make it here, so I'm reuploading it.

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

From tracker at bugs.pypy.org  Tue Nov 13 21:53:35 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Tue, 13 Nov 2012 20:53:35 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1352840015.41.0.483421222973.issue1323@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

I have traced it to os.fork() and threads, instead of subprocess.call()/Popen.

I have attached a simple example that - in CPython - prints "Child" 30 times.
In PyPy, however, it only works every 5th run or so, and I have never seen it 
print "Child" more than twice, despite forking 30 processes.
It works fine if you call the test function directly, instead of using Thread()

The funny thing is, that after a while, you'll be unable to fork. Why? PyPy's 
os.fork() DOES fork. It just doesn't appear to do anything beyond that - the 
processes just hangs there... And for 30 forks per run, you'll have a lot of 
processes very fast. :)

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

From tracker at bugs.pypy.org  Wed Nov 14 14:45:46 2012
From: tracker at bugs.pypy.org (Remi)
Date: Wed, 14 Nov 2012 13:45:46 +0000
Subject: [pypy-issue] [issue1324] stm-thread-2: SIGSEGV pypy_g_bootstrap()
In-Reply-To: <1352900746.04.0.778105672124.issue1324@bugs.pypy.org>
Message-ID: <1352900746.04.0.778105672124.issue1324@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Running the test_quicksort_segv.py sometimes shows the Assertion Failure from 
issue1320 but most of the time it receives SIGSEGV.

The SEGV happens in Bootstrapper.bootstrap() where in the finally-clause we call 
thread.gc_thread_die() which frees the shadow-stack. Unfortunately, at that time 
we already have a KeyError exception which will be ReRaised after the 
gc_thread_die() and it looks like ReRaising needs the shadow-stack.

The KeyError comes from the call to space.threadlocals.leave_thread(space) which 
calls thread_is_stopping(). In there, the "del local.dicts[ec]" seems to raise 
the KeyError.

That is as far as I got and I am struggling to see why that happens :)

----------
files: segv.zip
messages: 4995
nosy: Remi, pypy-issue
priority: bug
status: unread
title: stm-thread-2: SIGSEGV pypy_g_bootstrap()

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

From tracker at bugs.pypy.org  Wed Nov 14 16:43:08 2012
From: tracker at bugs.pypy.org (Alex)
Date: Wed, 14 Nov 2012 15:43:08 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>


New submission from Alex <antoniadis.alexandros.87 at gmail.com>:

Greetings,

I recently faced a pretty weird problem when I tried to run a trivial python script that opened 
nested connection to a sqlite database.
The script is the following:

---
import sqlite3

DATABASE_LOCATION = './dummy.db'

def another_sql_connection():
    with sqlite3.connect(DATABASE_LOCATION) as con:
        pass

def an_sql_connection():
    with sqlite3.connect(DATABASE_LOCATION) as con:
        cur = con.cursor()
        sql_match_query = "select * from dummy_table;"

        cur.execute(sql_match_query);
        for row in cur.fetchall():
            another_sql_connection()
            print row

an_sql_connection()

---

Assuming that there is a database (sqlite) named dummy.db at the same directory with the python 
script I run which contains a table called dummy_table with 500 rows. In my example the table 
has only one field called id which is an integer.

The error I get is the following:
...
(250,)
(251,)
(252,)
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "example.py", line 19, in <module>
  File "example.py", line 16, in an_sql_connection
  File "example.py", line 6, in another_sql_connection
  File "/Users/alex/Desktop/pypy-1.9/lib_pypy/_sqlite3.py", line 279, in connect
  File "/Users/alex/Desktop/pypy-1.9/lib_pypy/_sqlite3.py", line 311, in __init_


So after 252 successful connections this strange error occurred.
Note that this error happens only on Mac OSX, I've tested it on Linux and it works as expected 
and that when I run the script with python on Mac OSX it also works fine.

So, I think that something strange happens on the pypy version (1.9) for Mac OSX (at least for 
the sqlite module).

If you want me to provide you some more details about the systems I've tested the code let me 
know.

Regards,
Alex

----------
messages: 4996
nosy: alex.a, pypy-issue
priority: bug
status: unread
title: pypy + sqlite3 problem on Mac OSX

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

From tracker at bugs.pypy.org  Wed Nov 14 17:29:59 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 14 Nov 2012 16:29:59 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352910599.47.0.576142412067.issue1325@bugs.pypy.org>


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

You stripped the intersting error message, just after the traceback. But it's certainly the line 'raise 
OperationalError("Could not open database")'

I noticed that our Connection object has no __del__, so the connections are probably not closed. The "with" 
statement will only commit/rollback the transaction, not close it.

Does a "con.close()" fix the issue?

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

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

From tracker at bugs.pypy.org  Wed Nov 14 17:38:18 2012
From: tracker at bugs.pypy.org (Alex)
Date: Wed, 14 Nov 2012 16:38:18 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352911098.72.0.728854132358.issue1325@bugs.pypy.org>


Alex <antoniadis.alexandros.87 at gmail.com> added the comment:

Ah you are right about the error. It was :
OperationalError: Could not open database
Sorry for missing that.

Closing the connection as you suggested fixed the problem.

Thank you!

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

From tracker at bugs.pypy.org  Wed Nov 14 17:45:36 2012
From: tracker at bugs.pypy.org (Alex)
Date: Wed, 14 Nov 2012 16:45:36 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352911536.92.0.388461510165.issue1325@bugs.pypy.org>


Alex <antoniadis.alexandros.87 at gmail.com> added the comment:

Sorry for the double posting but why this error does not occur also in the Linux 
version? As I can tell the _sqlite3.py is the same for both the Mac OSX and the 
Linux version hence the Connection object does not have __del__ also in the Linux 
version.

Alex

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

From tracker at bugs.pypy.org  Wed Nov 14 17:49:33 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 14 Nov 2012 16:49:33 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352911773.96.0.0788355362535.issue1325@bugs.pypy.org>


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

The systems probably have different limits to the number of open connections.
Or to the number of files opened by a single process...

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

From tracker at bugs.pypy.org  Wed Nov 14 17:58:47 2012
From: tracker at bugs.pypy.org (Alex)
Date: Wed, 14 Nov 2012 16:58:47 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352912327.91.0.208201694797.issue1325@bugs.pypy.org>


Alex <antoniadis.alexandros.87 at gmail.com> added the comment:

Again you are right!
I've tested on Linux with much more rows in the table and the same error occurs a 
bit later at the row 1019.

Thank you very much for immediate response

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

From tracker at bugs.pypy.org  Wed Nov 14 17:59:21 2012
From: tracker at bugs.pypy.org (Alex)
Date: Wed, 14 Nov 2012 16:59:21 +0000
Subject: [pypy-issue] [issue1325] pypy + sqlite3 problem on Mac OSX
In-Reply-To: <1352907788.82.0.816519768908.issue1325@bugs.pypy.org>
Message-ID: <1352912361.35.0.143801328076.issue1325@bugs.pypy.org>


Alex <antoniadis.alexandros.87 at gmail.com> added the comment:

Again you are right!
I've tested on Linux with much more rows in the table and the same error occurs a 
bit later at the row 1019.

Thank you very much for your immediate response

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

From tracker at bugs.pypy.org  Thu Nov 15 12:35:26 2012
From: tracker at bugs.pypy.org (Remi)
Date: Thu, 15 Nov 2012 11:35:26 +0000
Subject: [pypy-issue] [issue1326] stm-thread-2: free(): invalid pointer
In-Reply-To: <1352979326.15.0.950497525491.issue1326@bugs.pypy.org>
Message-ID: <1352979326.15.0.950497525491.issue1326@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Running the example from the zip shows the following stack trace. Parsing smaller json files 
works correctly:

*** glibc detected *** ./pypy-stm: free(): invalid pointer: 0x0000000003c68ef2 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fdd4b745b96]
./pypy-stm(pypy_g_StmGCTLS_mass_free_old_local+0x60)[0x13cefb0]
./pypy-stm(pypy_g_StmGCTLS_local_collection+0x418)[0x13cf6c8]
./pypy-stm(pypy_g_StmGCTLS_stop_transaction+0x25)[0x13cf885]
./pypy-stm(pypy_g__stm_callback+0xdf)[0x167eecf]
./pypy-stm(stm_perform_transaction+0xbf)[0xa6478f]
./pypy-stm(pypy_g_PyFrame__dispatch_stm_breaking_transaction+0x100)[0xed5dd0]
./pypy-stm(pypy_g_PyFrame_execute_frame+0x458)[0xb868c8]
./pypy-stm(pypy_g_PyFrame_run+0x14)[0xb86c54]
./pypy-stm(pypy_g_call_function__star_2+0x2b5)[0xaeca65]
./pypy-stm(pypy_g_entry_point+0x10b3)[0xe85213]
./pypy-stm(pypy_main_function+0x28)[0xa64b08]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fdd4b6e876d]
./pypy-stm[0xa619e1]
======= Memory map: ========
00400000-01a9b000 r-xp 00000000 08:05 8662178                            /home/remi/programming/
pypy/pypy/translator/goal/pypy-stm
01c9b000-01c9c000 r--p 0169b000 08:05 8662178                            /home/remi/programming/
pypy/pypy/translator/goal/pypy-stm
01c9c000-0292e000 rw-p 0169c000 08:05 8662178                            /home/remi/programming/
pypy/pypy/translator/goal/pypy-stm
0292e000-02939000 rw-p 00000000 00:00 0 
03bc2000-03f68000 rw-p 00000000 00:00 0                                  [heap]
7fdd46e39000-7fdd47c12000 rw-p 00000000 00:00 0 
7fdd48f90000-7fdd493d6000 r--p 00000000 08:05 3147170                    /usr/lib/locale/locale-
archive
7fdd494b0000-7fdd494c5000 r-xp 00000000 08:05 6422717                    /lib/x86_64-linux-gnu/
libgcc_s.so.1
7fdd494c5000-7fdd496c4000 ---p 00015000 08:05 6422717                    /lib/x86_64-linux-gnu/
libgcc_s.so.1
7fdd496c4000-7fdd496c5000 r--p 00014000 08:05 6422717                    /lib/x86_64-linux-gnu/
libgcc_s.so.1
7fdd496c5000-7fdd496c6000 rw-p 00015000 08:05 6422717                    /lib/x86_64-linux-gnu/
libgcc_s.so.1
7fdd496c6000-7fdd4b6c7000 rw-p 00000000 00:00 0 
7fdd4b6c7000-7fdd4b87c000 r-xp 00000000 08:05 6423935                    /lib/x86_64-linux-gnu/
libc-2.15.so
7fdd4b87c000-7fdd4ba7b000 ---p 001b5000 08:05 6423935                    /lib/x86_64-linux-gnu/
libc-2.15.so
7fdd4ba7b000-7fdd4ba7f000 r--p 001b4000 08:05 6423935                    /lib/x86_64-linux-gnu/
libc-2.15.so
7fdd4ba7f000-7fdd4ba81000 rw-p 001b8000 08:05 6423935                    /lib/x86_64-linux-gnu/
libc-2.15.so
7fdd4ba81000-7fdd4ba86000 rw-p 00000000 00:00 0 
7fdd4ba86000-7fdd4ba9e000 r-xp 00000000 08:05 6423944                    /lib/x86_64-linux-gnu/
libpthread-2.15.so
7fdd4ba9e000-7fdd4bc9d000 ---p 00018000 08:05 6423944                    /lib/x86_64-linux-gnu/
libpthread-2.15.so
7fdd4bc9d000-7fdd4bc9e000 r--p 00017000 08:05 6423944                    /lib/x86_64-linux-gnu/
libpthread-2.15.so
7fdd4bc9e000-7fdd4bc9f000 rw-p 00018000 08:05 6423944                    /lib/x86_64-linux-gnu/
libpthread-2.15.so
7fdd4bc9f000-7fdd4bca3000 rw-p 00000000 00:00 0 
7fdd4bca3000-7fdd4bcc7000 r-xp 00000000 08:05 6423770                    /lib/x86_64-linux-gnu/
libtinfo.so.5.9
7fdd4bcc7000-7fdd4bec6000 ---p 00024000 08:05 6423770                    /lib/x86_64-linux-gnu/
libtinfo.so.5.9
7fdd4bec6000-7fdd4beca000 r--p 00023000 08:05 6423770                    /lib/x86_64-linux-gnu/
libtinfo.so.5.9
7fdd4beca000-7fdd4becb000 rw-p 00027000 08:05 6423770                    /lib/x86_64-linux-gnu/
libtinfo.so.5.9
7fdd4becb000-7fdd4bed4000 r-xp 00000000 08:05 6423952                    /lib/x86_64-linux-gnu/
libcrypt-2.15.so
7fdd4bed4000-7fdd4c0d4000 ---p 00009000 08:05 6423952                    /lib/x86_64-linux-gnu/
libcrypt-2.15.so
7fdd4c0d4000-7fdd4c0d5000 r--p 00009000 08:05 6423952                    /lib/x86_64-linux-gnu/
libcrypt-2.15.so
7fdd4c0d5000-7fdd4c0d6000 rw-p 0000a000 08:05 6423952                    /lib/x86_64-linux-gnu/
libcrypt-2.15.so
7fdd4c0d6000-7fdd4c104000 rw-p 00000000 00:00 0 
7fdd4c104000-7fdd4c10b000 r-xp 00000000 08:05 3152373                    /usr/lib/x86_64-linux-
gnu/libffi.so.6.0.0
7fdd4c10b000-7fdd4c30a000 ---p 00007000 08:05 3152373                    /usr/lib/x86_64-linux-
gnu/libffi.so.6.0.0
7fdd4c30a000-7fdd4c30b000 r--p 00006000 08:05 3152373                    /usr/lib/x86_64-linux-
gnu/libffi.so.6.0.0
7fdd4c30b000-7fdd4c30c000 rw-p 00007000 08:05 3152373                    /usr/lib/x86_64-linux-
gnu/libffi.so.6.0.0
7fdd4c30c000-7fdd4c30e000 r-xp 00000000 08:05 6424226                    /lib/x86_64-linux-gnu/
libutil-2.15.so
7fdd4c30e000-7fdd4c50d000 ---p 00002000 08:05 6424226                    /lib/x86_64-linux-gnu/
libutil-2.15.so
7fdd4c50d000-7fdd4c50e000 r--p 00001000 08:05 6424226                    /lib/x86_64-linux-gnu/
libutil-2.15.so
7fdd4c50e000-7fdd4c50f000 rw-p 00002000 08:05 6424226                    /lib/x86_64-linux-gnu/
libutil-2.15.so
7fdd4c50f000-7fdd4c51e000 r-xp 00000000 08:05 6423679                    /lib/x86_64-linux-gnu/
libbz2.so.1.0.4
7fdd4c51e000-7fdd4c71d000 ---p 0000f000 08:05 6423679                    /lib/x86_64-linux-gnu/
libbz2.so.1.0.4
7fdd4c71d000-7fdd4c71e000 r--p 0000e000 08:05 6423679                    /lib/x86_64-linux-gnu/
libbz2.so.1.0.4
7fdd4c71e000-7fdd4c71f000 rw-p 0000f000 08:05 6423679                    /lib/x86_64-linux-gnu/
libbz2.so.1.0.4
7fdd4c71f000-7fdd4c726000 r-xp 00000000 08:05 6423946                    /lib/x86_64-linux-gnu/
librt-2.15.so
7fdd4c726000-7fdd4c925000 ---p 00007000 08:05 6423946                    /lib/x86_64-linux-gnu/
librt-2.15.so
7fdd4c925000-7fdd4c926000 r--p 00006000 08:05 6423946                    /lib/x86_64-linux-gnu/
librt-2.15.so
7fdd4c926000-7fdd4c927000 rw-p 00007000 08:05 6423946                    /lib/x86_64-linux-gnu/
librt-2.15.so
7fdd4c927000-7fdd4c94d000 r-xp 00000000 08:05 6422700                    /lib/x86_64-linux-gnu/
libexpat.so.1.6.0
7fdd4c94d000-7fdd4cb4d000 ---p 00026000 08:05 6422700                    /lib/x86_64-linux-gnu/
libexpat.so.1.6.0
7fdd4cb4d000-7fdd4cb4f000 r--p 00026000 08:05 6422700                    /lib/x86_64-linux-gnu/
libexpat.so.1.6.0
7fdd4cb4f000-7fdd4cb50000 rw-p 00028000 08:05 6422700                    /lib/x86_64-linux-gnu/
libexpat.so.1.6.0
7fdd4cb50000-7fdd4ccee000 r-xp 00000000 08:05 6422902                    /lib/x86_64-linux-gnu/
libcrypto.so.1.0.0
7fdd4ccee000-7fdd4ceed000 ---p 0019e000 08:05 6422902                    /lib/x86_64-linux-gnu/
libcrypto.so.1.0.0
7fdd4ceed000-7fdd4cf08000 r--p 0019d000 08:05 6422902                    /lib/x86_64-linux-gnu/
libcrypto.so.1.0.0
7fdd4cf08000-7fdd4cf13000 rw-p 001b8000 08:05 6422902                    /lib/x86_64-linux-gnu/
libcrypto.so.1.0.0
7fdd4cf13000-7fdd4cf17000 rw-p 00000000 00:00 0 
7fdd4cf17000-7fdd4cf69000 r-xp 00000000 08:05 6422880                    /lib/x86_64-linux-gnu/
libssl.so.1.0.0
7fdd4cf69000-7fdd4d169000 ---p 00052000 08:05 6422880                    /lib/x86_64-linux-gnu/
libssl.so.1.0.0
7fdd4d169000-7fdd4d16c000 r--p 00052000 08:05 6422880                    /lib/x86_64-linux-gnu/
libssl.so.1.0.0
7fdd4d16c000-7fdd4d172000 rw-p 00055000 08:05 6422880                    /lib/x86_64-linux-gnu/
libssl.so.1.0.0
7fdd4d172000-7fdd4d173000 rw-p 00000000 00:00 0 
7fdd4d173000-7fdd4d189000 r-xp 00000000 08:05 6422678                    /lib/x86_64-linux-gnu/
libz.so.1.2.7
7fdd4d189000-7fdd4d388000 ---p 00016000 08:05 6422678                    /lib/x86_64-linux-gnu/
libz.so.1.2.7
7fdd4d388000-7fdd4d389000 r--p 00015000 08:05 6422678                    /lib/x86_64-linux-gnu/
libz.so.1.2.7
7fdd4d389000-7fdd4d38a000 rw-p 00016000 08:05 6422678                    /lib/x86_64-linux-gnu/
libz.so.1.2.7
7fdd4d38a000-7fdd4d38c000 r-xp 00000000 08:05 6422869                    /lib/x86_64-linux-gnu/
libdl-2.15.so
7fdd4d38c000-7fdd4d58c000 ---p 00002000 08:05 6422869                    /lib/x86_64-linux-gnu/
libdl-2.15.so
7fdd4d58c000-7fdd4d58d000 r--p 00002000 08:05 6422869                    /lib/x86_64-linux-gnu/
libdl-2.15.so
7fdd4d58d000-7fdd4d58e000 rw-p 00003000 08:05 6422869                    /lib/x86_64-linux-gnu/
libdl-2.15.so
7fdd4d58e000-7fdd4d689000 r-xp 00000000 08:05 6423950                    /lib/x86_64-linux-gnu/
libm-2.15.so
7fdd4d689000-7fdd4d888000 ---p 000fb000 08:05 6423950                    /lib/x86_64-linux-gnu/
libm-2.15.so
7fdd4d888000-7fdd4d889000 r--p 000fa000 08:05 6423950                    /lib/x86_64-linux-gnu/
libm-2.15.so
7fdd4d889000-7fdd4d88a000 rw-p 000fb000 08:05 6423950                    /lib/x86_64-linux-gnu/
libm-2.15.so
7fdd4d88a000-7fdd4d8ac000 r-xp 00000000 08:05 6424210                    /lib/x86_64-linux-gnu/
ld-2.15.so
7fdd4d901000-7fdd4da7b000 rw-p 00000000 00:00 0 
7fdd4daa9000-7fdd4daac000 rw-p 00000000 00:00 0 
7fdd4daac000-7fdd4daad000 r--p 00022000 08:05 6424210                    /lib/x86_64-linux-gnu/
ld-2.15.so
7fdd4daad000-7fdd4daaf000 rw-p 00023000 08:05 6424210                    /lib/x86_64-linux-gnu/
ld-2.15.so
7fff2dee2000-7fff2df03000 rw-p 00000000 00:00 0                          [stack]
7fff2df3a000-7fff2df3b000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

----------
files: goal.zip
messages: 5003
nosy: Remi, pypy-issue
priority: bug
status: unread
title: stm-thread-2: free(): invalid pointer

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

From tracker at bugs.pypy.org  Thu Nov 15 13:30:33 2012
From: tracker at bugs.pypy.org (Remi)
Date: Thu, 15 Nov 2012 12:30:33 +0000
Subject: [pypy-issue] [issue1326] stm-thread-2: free(): invalid pointer
In-Reply-To: <1352979326.15.0.950497525491.issue1326@bugs.pypy.org>
Message-ID: <1352982633.74.0.195548630419.issue1326@bugs.pypy.org>


Remi <remi.meier at gmail.com> added the comment:

Increasing the nursery_size seems to help (temporarily).

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

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

From tracker at bugs.pypy.org  Thu Nov 15 23:43:13 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Thu, 15 Nov 2012 22:43:13 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1353019392.96.0.199751681224.issue1323@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

In the following code:

def fork(space):
    run_fork_hooks('before', space)

    try:
        pid = os.fork()
        if pid == 0:
            print "Wee, a child was born!"
    except OSError, e:
        try:
            run_fork_hooks('parent', space)
        except:
            # Don't clobber the OSError if the fork failed
            pass
        raise wrap_oserror(space, e)

    if pid == 0:
        print "Begin child hooks"
        run_fork_hooks('child', space)
        print "Child hooks completed"
    else:
        run_fork_hooks('parent', space)
        print "Parent hooks completed"

    return space.wrap(pid)

Prints the following when forking from a thread:
Wee, a child was!
Parent hooks completed

Whereas, without threads, it prints:
Parent hooks completed
Wee, a child was born!
Begin child hooks
Child hooks completed

... The result: I'm having fun with the generated C, trying to get what's going 
on...

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

From tracker at bugs.pypy.org  Fri Nov 16 16:48:29 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 16 Nov 2012 15:48:29 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1353080909.85.0.139422038479.issue1323@bugs.pypy.org>


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

FYI there are failures in tests - http://buildbot.pypy.org/summary/longrepr?
testname=AppTestFork.%28%29.test_forked_can_thread&builder=pypy-c-jit-macosx-x86-
64&build=863&mod=module.thread.test.test_fork so it's a "known issue"

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

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

From tracker at bugs.pypy.org  Fri Nov 16 19:18:09 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 16 Nov 2012 18:18:09 +0000
Subject: [pypy-issue] [issue1327] "x in deque" slow
In-Reply-To: <1353089889.71.0.963350944607.issue1327@bugs.pypy.org>
Message-ID: <1353089889.71.0.963350944607.issue1327@bugs.pypy.org>


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

The performance of "x in mydeque" is seriously worse than on CPython: about 5x.
 Investigate why.

----------
messages: 5007
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: "x in deque" slow

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

From tracker at bugs.pypy.org  Fri Nov 16 20:08:16 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 16 Nov 2012 19:08:16 +0000
Subject: [pypy-issue] [issue1319] PyPy 1000x slower than CPython for
	set.difference_update
In-Reply-To: <1352685535.13.0.315074669122.issue1319@bugs.pypy.org>
Message-ID: <1353092896.11.0.822991722079.issue1319@bugs.pypy.org>


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

Fixed in 1813d473c76d.

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

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

From tracker at bugs.pypy.org  Sun Nov 18 13:36:31 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 18 Nov 2012 12:36:31 +0000
Subject: [pypy-issue] [issue1119] Py_GetArgcArgv not exposed
In-Reply-To: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>
Message-ID: <1353242191.76.0.550108786062.issue1119@bugs.pypy.org>


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

How about rewriting this small module using CFFI?  It would be a nice and easy
exercise, at least is all you want is call prctl().

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

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

From tracker at bugs.pypy.org  Sun Nov 18 23:17:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 18 Nov 2012 22:17:46 +0000
Subject: [pypy-issue] [issue1328] cProfile: slow on built-in function calls
In-Reply-To: <1353277066.05.0.0979170791847.issue1328@bugs.pypy.org>
Message-ID: <1353277066.05.0.0979170791847.issue1328@bugs.pypy.org>


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

The cProfile recording overhead with the JIT is low when counting function
calls, but very high when counting calls to built-in functions.  Jitviewer shows
that it takes a lot of residual calls around a single call to a built-in
function.  It seems to me that we did not put enough efforts in optimizing this.
 A trivial example shows an overhead of about 500x:

def f(n):
    lst = []
    for i in xrange(n):
        lst.append(i)     # built-in call
        lst.pop()         # built-in call

----------
messages: 5010
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: cProfile: slow on built-in function calls

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

From tracker at bugs.pypy.org  Mon Nov 19 13:56:44 2012
From: tracker at bugs.pypy.org (Remi)
Date: Mon, 19 Nov 2012 12:56:44 +0000
Subject: [pypy-issue] [issue1329] stm-thread-2: Many small transactions issue
In-Reply-To: <1353329804.41.0.127925031959.issue1329@bugs.pypy.org>
Message-ID: <1353329804.41.0.127925031959.issue1329@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Here is an artificial example which shows the worst-case behaviour of the current 
STM implementation:

-----------------------------
def may_turn_inevitable():
    f = float("0") # turn inevitable
    return f

def caller():
    for i in range(1000):
        may_turn_inevitable()
caller()
-----------------------------

In may_turn_inevitable() we have an operation which (currently) causes the 
transaction to turn inevitable. This again causes a transaction break as soon as 
possible. Hence, we break out of the normal dispatch() loop and call 
stm_perform_transaction() (which commits the transaction, starts a new one and 
calls us again).
In a normal transaction, we now execute the "return f" which will raise ExitFrame 
and cause us to return from the callback, commit and end the current call to 
stm_perform_transaction() and therefore start a new inevitable transaction again. 
This one will also commit as soon as possible (before we call may_turn_inevitable
() again).

In the end we alternate between very short normal and inevitable transactions.

A real world example where this can be observed is in 
json.scanner.py_make_scanner._scan_once (parse_float).

----------
messages: 5011
nosy: Remi, pypy-issue
priority: performance bug
status: unread
title: stm-thread-2: Many small transactions issue

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

From tracker at bugs.pypy.org  Mon Nov 19 21:32:25 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Mon, 19 Nov 2012 20:32:25 +0000
Subject: [pypy-issue] [issue1327] "x in deque" slow
In-Reply-To: <1353089889.71.0.963350944607.issue1327@bugs.pypy.org>
Message-ID: <1353357145.17.0.664540972812.issue1327@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

I attached a micro benchmark that indeed shows a 5x slowdown compared to CPython 2.7.

In a branch here https://bitbucket.org/kostialopuhin/pypy/compare/deque-
in..pypy/pypy:default I implemented contains directly on deque, and it performs about 
the same on this benchmark as CPython. For comparason, deque implemented in pure 
python, that also implements __contains__ directly is 5x faster than CPython.

On irc Armin Rigo suggested that s jit driver in space.contains might help to solve 
the problem without hand-written contains, so here I just post numbers for 
comparason:

$ time pypy deque_in_bench.py 
real	0m6.131s
user	0m6.112s
sys	0m0.017s

$ time python deque_in_bench.py 
real	0m1.467s
user	0m1.372s
sys	0m0.036s

$ time ~/programming/pypy/pypy/translator/goal/pypy-c-deque-in  deque_in_bench.py 

real	0m1.397s
user	0m1.323s
sys	0m0.034s

----------
nosy: +kostia.lopuhin
status: unread -> chatting

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

From tracker at bugs.pypy.org  Thu Nov 22 11:50:06 2012
From: tracker at bugs.pypy.org (Eric)
Date: Thu, 22 Nov 2012 10:50:06 +0000
Subject: [pypy-issue] [issue1330] fib(47) vs fib(48)
In-Reply-To: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>
Message-ID: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>


New submission from Eric <eric.saintetienne at gmail.com>:

Consider the recursive fibonacci alrgorithm (see code attached) on a 32bit Linux 
machine: fib(47) is much slower than fib(48) (two to three times slower)

This affects pypy 1.9 as well as 1.8

It's worth noting that fib(N) has to be held in a 'long' for N >= 47 and can be 
held in an 'int' otherwise, as illustrated bellow:

fib(45)=1134903170
fib(46)=1836311903
fib(47)=2971215073  > sys.maxint
fib(48)=4807526976  > sys.maxint
fib(49)=7778742049  > sys.maxint

----------
files: fib.py
messages: 5013
nosy: gembrot, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: fib(47) vs fib(48)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1330>
________________________________________
-------------- next part --------------
N=47

def fib(n):
    if n < 2:
        return n
    return fib(n-1) + fib(n-2)

print "fib(%d)=%d" % (N, fib(N))

# eof

From tracker at bugs.pypy.org  Thu Nov 22 14:52:32 2012
From: tracker at bugs.pypy.org (Eric)
Date: Thu, 22 Nov 2012 13:52:32 +0000
Subject: [pypy-issue] [issue1330] fib(47) vs fib(48)
In-Reply-To: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>
Message-ID: <1353592352.48.0.20680320119.issue1330@bugs.pypy.org>


Eric <eric.saintetienne at gmail.com> added the comment:

Also it's not a JIT issue as psyco is consistent (as expected fib(47) is faster 
than fib(48) when using psyco)

Time measurements:

-- fib(48) --

psyco: fib(48)=4807526976
real    3m28.131s
user    3m27.945s
sys     0m0.008s

pypy: fib(48)=4807526976
real    5m19.042s
user    5m18.468s
sys     0m0.296s

-- fib(47) --

psyco: fib(47)=2971215073
real    2m12.313s
user    2m12.188s
sys     0m0.004s

pypy: fib(47)=2971215073
real    12m9.047s
user    12m7.657s
sys     0m0.776s

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

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

From tracker at bugs.pypy.org  Thu Nov 22 15:19:39 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 22 Nov 2012 14:19:39 +0000
Subject: [pypy-issue] [issue1330] fib(47) vs fib(48)
In-Reply-To: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>
Message-ID: <1353593979.88.0.871196471309.issue1330@bugs.pypy.org>


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

Can you try with the brand new pypy-2.0-beta1?
It has interesting improvements for the "long" type.

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Thu Nov 22 15:38:59 2012
From: tracker at bugs.pypy.org (Eric)
Date: Thu, 22 Nov 2012 14:38:59 +0000
Subject: [pypy-issue] [issue1330] fib(47) vs fib(48)
In-Reply-To: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>
Message-ID: <1353595139.28.0.0122716762257.issue1330@bugs.pypy.org>


Eric <eric.saintetienne at gmail.com> added the comment:

Same behavior using 2.0 beta1 (linux 32 bits)

-- fib(47) --

pypy: fib(47)=2971215073
real    12m51.098s
user    12m44.912s
sys     0m5.480s

-- fib(48) --

pypy: fib(48)=4807526976
real    5m56.552s
user    5m52.858s
sys     0m3.352s

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

From tracker at bugs.pypy.org  Thu Nov 22 17:04:22 2012
From: tracker at bugs.pypy.org (Miki Tebeka)
Date: Thu, 22 Nov 2012 16:04:22 +0000
Subject: [pypy-issue] [issue1331] Core dump when running "pypy -m
	test.regrtest"
In-Reply-To: <1353600262.39.0.278485388975.issue1331@bugs.pypy.org>
Message-ID: <1353600262.39.0.278485388975.issue1331@bugs.pypy.org>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

This is on pypy 2.0 beta 1, Ubuntu 12.10 64bit. The error is:

test_capi
RPython traceback:
  File "pypy_module_cpyext_object.c", line 3273, in _PyObject_New
  File "pypy_module_cpyext_object.c", line 4173, in _PyObject_NewVar
  File "pypy_module_cpyext_pyobject.c", line 148, in from_ref
Fatal RPython error: AssertionError
Aborted (core dumped)

----------
messages: 5017
nosy: pypy-issue, tebeka
priority: critical
release: 2.0
status: unread
title: Core dump when running "pypy -m test.regrtest"

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

From tracker at bugs.pypy.org  Thu Nov 22 17:27:07 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 22 Nov 2012 16:27:07 +0000
Subject: [pypy-issue] [issue1331] Core dump when running "pypy -m
	test.regrtest"
In-Reply-To: <1353600262.39.0.278485388975.issue1331@bugs.pypy.org>
Message-ID: <1353601627.99.0.939650785803.issue1331@bugs.pypy.org>


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

That's because in _testcapimodule.c, the type "memoryviewtester" is not correctly initialized.
I added to the init_testcapi function:
    PyType_Ready(&_MemoryViewTester_Type);
and the test still fails... but a bit later, and "normally" this time.

This file is a verbatim copy from CPython. You can find it in the lib_pypy directory.

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

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

From tracker at bugs.pypy.org  Fri Nov 23 01:58:21 2012
From: tracker at bugs.pypy.org (Johannes Raggam)
Date: Fri, 23 Nov 2012 00:58:21 +0000
Subject: [pypy-issue] [issue1332] using odict as dict implementation?
In-Reply-To: <1353632301.92.0.371158808775.issue1332@bugs.pypy.org>
Message-ID: <1353632301.92.0.371158808775.issue1332@bugs.pypy.org>


New submission from Johannes Raggam <tdot at g24.at>:

On the performance section of the website, I've read:

"""
Building very large dicts: At present, this is an issue with our GCs. Building
large lists works much better; the random order of dictionary elements is what
hurts performance right now.
"""
http://pypy.org/performance.html

I've thought? Why not drop the concept of unordered dicts and use and ordered
dict implementation like this one:

https://github.com/bluedynamics/odict

it complies to the dictionary API and does not use normal python dicts.
look at it's implementation here:

https://github.com/bluedynamics/odict/blob/master/src/odict/pyodict.py


there is also an ordered dictionary implementation in python itself, but odict
is better.



http://pypy.org/performance.html

----------
messages: 5019
nosy: pypy-issue, thet
priority: feature
release: 2.0
status: unread
title: using odict as dict implementation?

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

From tracker at bugs.pypy.org  Fri Nov 23 04:58:45 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 23 Nov 2012 03:58:45 +0000
Subject: [pypy-issue] [issue1332] using odict as dict implementation?
In-Reply-To: <1353632301.92.0.371158808775.issue1332@bugs.pypy.org>
Message-ID: <1353643125.9.0.609961708061.issue1332@bugs.pypy.org>


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

This would not solve the problem. Though odict has an order, it's done by keeping 
a linkedlist running through elements, and not by keeping the objects in order in 
memory.

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

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

From tracker at bugs.pypy.org  Fri Nov 23 12:37:23 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Fri, 23 Nov 2012 11:37:23 +0000
Subject: [pypy-issue] [issue1333] OS X compatibility
In-Reply-To: <1353670642.94.0.699248033826.issue1333@bugs.pypy.org>
Message-ID: <1353670642.94.0.699248033826.issue1333@bugs.pypy.org>


New submission from Kenny Levinsen <kennylevinsen at gmail.com>:

OS X builds do not provide any compatibility by default, causing builds 
translated on newer versions on OS X to lack any backwards compatibility.

The following diff provides compatibility down to 10.6 (change 10.6 with the 
version of choice):

diff -r fcb6b056f00e pypy/translator/platform/darwin.py
--- a/pypy/translator/platform/darwin.py        Thu Nov 22 13:52:20 2012 +0100
+++ b/pypy/translator/platform/darwin.py        Fri Nov 23 12:32:44 2012 +0100
@@ -61,8 +61,8 @@
 
 class Darwin_i386(Darwin):
     name = "darwin_i386"
-    link_flags = ('-arch', 'i386')
-    cflags = ('-arch', 'i386', '-O3', '-fomit-frame-pointer')
+    link_flags = ('-arch', 'i386', '-mmacosx-version-min=10.6')
+    cflags = ('-arch', 'i386', '-O3', '-fomit-frame-pointer', '-mmacosx-
version-min=10.6')
 
 class Darwin_PowerPC(Darwin):#xxx fixme, mwp
     name = "darwin_powerpc"
@@ -71,5 +71,5 @@
 
 class Darwin_x86_64(Darwin):
     name = "darwin_x86_64"
-    link_flags = ('-arch', 'x86_64')
-    cflags = ('-arch', 'x86_64', '-O3', '-fomit-frame-pointer')
+    link_flags = ('-arch', 'x86_64', '-mmacosx-version-min=10.6')
+    cflags = ('-arch', 'x86_64', '-O3', '-fomit-frame-pointer', '-mmacosx-
version-min=10.6')

----------
messages: 5021
nosy: joushou, pypy-issue
priority: bug
status: unread
title: OS X compatibility

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

From tracker at bugs.pypy.org  Fri Nov 23 12:52:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Nov 2012 11:52:29 +0000
Subject: [pypy-issue] [issue1333] OS X compatibility
In-Reply-To: <1353670642.94.0.699248033826.issue1333@bugs.pypy.org>
Message-ID: <1353671549.31.0.531952121347.issue1333@bugs.pypy.org>


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

discussed on irc: 10.5 seems like a good value.

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

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

From tracker at bugs.pypy.org  Fri Nov 23 13:43:44 2012
From: tracker at bugs.pypy.org (wilk)
Date: Fri, 23 Nov 2012 12:43:44 +0000
Subject: [pypy-issue] [issue1334] download binary
	pypy-2.0-beta1-linux64-libc2.13.tar.bz2	corrupted
In-Reply-To: <1353674624.25.0.525551395081.issue1334@bugs.pypy.org>
Message-ID: <1353674624.25.0.525551395081.issue1334@bugs.pypy.org>


New submission from wilk <wilk at flibuste.net>:

$ bunzip2 pypy-2.0-beta1-linux64-libc2.13.tar.bz2 

bunzip2: Compressed file ends unexpectedly;
	perhaps it is corrupted?

----------
messages: 5023
nosy: pypy-issue, wilk
priority: critical
status: unread
title: download binary pypy-2.0-beta1-linux64-libc2.13.tar.bz2 corrupted

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

From tracker at bugs.pypy.org  Fri Nov 23 14:14:33 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Nov 2012 13:14:33 +0000
Subject: [pypy-issue] [issue1334] download binary
	pypy-2.0-beta1-linux64-libc2.13.tar.bz2	corrupted
In-Reply-To: <1353674624.25.0.525551395081.issue1334@bugs.pypy.org>
Message-ID: <1353676473.81.0.975606549141.issue1334@bugs.pypy.org>


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

Fixed by fijal re-uploading it, thank you!

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

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

From tracker at bugs.pypy.org  Fri Nov 23 15:09:17 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Nov 2012 14:09:17 +0000
Subject: [pypy-issue] [issue1332] using odict as dict implementation?
In-Reply-To: <1353632301.92.0.371158808775.issue1332@bugs.pypy.org>
Message-ID: <1353679757.11.0.499919627039.issue1332@bugs.pypy.org>


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

Moreover, looking at the implementation of odict, it seems to be based on normal
Python dicts.

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

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

From tracker at bugs.pypy.org  Fri Nov 23 15:24:38 2012
From: tracker at bugs.pypy.org (Max Lavrenov)
Date: Fri, 23 Nov 2012 14:24:38 +0000
Subject: [pypy-issue] [issue1335] problem with twisted in current pypy master
In-Reply-To: <1353680678.81.0.39259552476.issue1335@bugs.pypy.org>
Message-ID: <1353680678.81.0.39259552476.issue1335@bugs.pypy.org>


New submission from Max Lavrenov <max.lavrenov at gmail.com>:

I had got this error while installed twisted.? 

I just built pypy from master, made virtual enviroment and pip install twisted.


Traceback (most recent call last):

? File "app_main.py", line 51, in run_toplevel
? File "app_main.py", line 547, in run_it
? File "<string>", line 1, in <module>
? File "/home/e-max/.virtualenvs/pypy/build/twisted/setup.py", line 82, in 
<module> 
      main(sys.argv[1:])
? File "/home/e-max/.virtualenvs/pypy/build/twisted/setup.py", line 77, in main 
      setup(**setup_args)
? File "./twisted/python/dist.py", line 58, in setup
??? return core.setup(**get_setup_args(**kw))
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/core.py", line 152, 
in setup
??? dist.run_commands()
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 953, 
in run_commands
??? self.run_command(cmd)
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 972, 
in run_command
??? cmd_obj.run()
? File "/home/e-max/.virtualenvs/pypy/site-packages/setuptools-0.6c11-
py2.7.egg/setuptools/command/install.py", 
line 56, in run
??? return _install.run(self)
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/command/install.py", 
line 584, in run
??? self.run_command(cmd_name)
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/cmd.py", line 326, 
in run_command
??? self.distribution.run_command(command)
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 972, 
in run_command
??? cmd_obj.run()
? File "/home/e-max/.virtualenvs/pypy/site-packages/setuptools-0.6c11-
py2.7.egg/setuptools/command/install_lib.py", 
line 24, in run
??? self.byte_compile(outfiles)
? File "/home/e-max/workspace/pypy/lib-
python/2.7/distutils/command/install_lib.py", line 138, in byte_compile
??? dry_run=self.dry_run)
? File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/util.py", line 559, 
in byte_compile
??? compile(file, cfile, dfile)
? File "/home/e-max/workspace/pypy/lib-python/2.7/py_compile.py", line 126, in 
compile
??? marshal.dump(codeobject, fc)

UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in position 
0: surrogates not allowed


When i ran it with pdb i could see that in marshal.dump(codeobject, fc)

codeobject was "<code object <module>, file '/home/e-
max/.virtualenvs/pypy2/site-
packages/twisted/words/test/test_jabberxmppstringprep.py', line 4>"

and fc was "<open file '/home/e-max/.virtualenvs/pypy2/site-
packages/twisted/words/test/test_jabberxmppstringprep.pyc', mode 'wb' at 
0x0000000005fce3c8>


I try it on Linux x64

----------
messages: 5026
nosy: e-max, pypy-issue
priority: bug
release: 2.0
status: unread
title: problem with twisted in current pypy master

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

From tracker at bugs.pypy.org  Fri Nov 23 16:20:59 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Fri, 23 Nov 2012 15:20:59 +0000
Subject: [pypy-issue] [issue1335] problem with twisted in current pypy master
In-Reply-To: <1353680678.81.0.39259552476.issue1335@bugs.pypy.org>
Message-ID: <1353684059.77.0.961570004342.issue1335@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

Huh, yep, that's the same file that I saw that pop up originally in issue 1285. I 
recall that afa's commit had fixed the issue for me, but maybe it regressed 
somehow.

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

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

From tracker at bugs.pypy.org  Fri Nov 23 17:05:42 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 23 Nov 2012 16:05:42 +0000
Subject: [pypy-issue] [issue1335] problem with twisted in current pypy master
In-Reply-To: <1353680678.81.0.39259552476.issue1335@bugs.pypy.org>
Message-ID: <1353686742.93.0.0124251549272.issue1335@bugs.pypy.org>


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

I just tried with a recent build, and it works.
Can you double-check the version of pypy you built?
(the one displayed when you start /home/e-max/workspace/pypy/bin/python)

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Fri Nov 23 17:44:50 2012
From: tracker at bugs.pypy.org (wilk)
Date: Fri, 23 Nov 2012 16:44:50 +0000
Subject: [pypy-issue] [issue1336] binary for debian squeeze 64
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>


New submission from wilk <wilk at flibuste.net>:

The current build of pypy 2.0 beta1 x64 cannot be run on debian squeeze because
of libssl 1.0

$ ./pypy 
./pypy: error while loading shared libraries: libssl.so.1.0.0: cannot open
shared object file: No such file or directory

pypy 1.9 was OK.

Could be fine to can test it with binary. Thanks !

----------
messages: 5030
nosy: pypy-issue, wilk
priority: wish
status: unread
title: binary for debian squeeze 64

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

From tracker at bugs.pypy.org  Sat Nov 24 12:25:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 24 Nov 2012 11:25:29 +0000
Subject: [pypy-issue] [issue1257] Memory leak when using web.py
In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org>
Message-ID: <1353756329.59.0.704345869946.issue1257@bugs.pypy.org>


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

It looks like it's not a bug or a leak, but just a very very slow JIT start-up.
 By running the process for long enough, RAM usage grows slowly from ~30MB to
89MB ("Resident size", Linux32), and at the same time the speed improves slowly
by a total factor of roughly 3x.  It takes maybe 10 minutes(!) to reach the
maximum RAM usage and top speed.  Afterwards, the memory usage doesn't grow past
89MB, even if I run it for one hour.

The extra ~60MB is taken by JIT code and associated data structures.  I don't
exactly know why it is so big in this case.  But note also that its size should
not depend on the quantity of real data that a real web server is handling, so
60MB is not that bad.

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

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

From tracker at bugs.pypy.org  Sat Nov 24 17:02:12 2012
From: tracker at bugs.pypy.org (Pavel)
Date: Sat, 24 Nov 2012 16:02:12 +0000
Subject: [pypy-issue] [issue1338] Epoll object cannot be closed twice
In-Reply-To: <1353772932.73.0.836119568946.issue1338@bugs.pypy.org>
Message-ID: <1353772932.73.0.836119568946.issue1338@bugs.pypy.org>


New submission from Pavel <asl.pavel at gmail.com>:

When you try to close epoll object twice error is raised, wich is different from 
python2.7(3.3).

>>>> from select import epoll
>>>> p = epoll ()
>>>> p.close ()
>>>> p.close ()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError: I/O operation on closed epoll fd

----------
messages: 5033
nosy: pypy-issue
priority: bug
release: 2.0
status: unread
title: Epoll object cannot be closed twice

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

From tracker at bugs.pypy.org  Sun Nov 25 09:22:53 2012
From: tracker at bugs.pypy.org (dremon)
Date: Sun, 25 Nov 2012 08:22:53 +0000
Subject: [pypy-issue] [issue1257] Memory leak when using web.py
In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org>
Message-ID: <1353831773.63.0.751448979988.issue1257@bugs.pypy.org>


dremon <dmitry at pankratov.net> added the comment:

Could you please try it with ssl enabled? (requires pyopenssl and server pem
certificate).

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

From tracker at bugs.pypy.org  Sun Nov 25 12:04:23 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 25 Nov 2012 11:04:23 +0000
Subject: [pypy-issue] [issue1339] Auto-generate documentation for pypyjit
	and __pypy__	module
In-Reply-To: <1353841463.37.0.150854114285.issue1339@bugs.pypy.org>
Message-ID: <1353841463.37.0.150854114285.issue1339@bugs.pypy.org>


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

This is an easy task.

Would be cool if pypyjit and __pypy__ documentation is automatically generated 
from docstrings into sphinx.

----------
messages: 5035
nosy: fijal, pypy-issue
priority: wish
status: unread
title: Auto-generate documentation for pypyjit and __pypy__ module

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

From tracker at bugs.pypy.org  Sun Nov 25 12:18:07 2012
From: tracker at bugs.pypy.org (dremon)
Date: Sun, 25 Nov 2012 11:18:07 +0000
Subject: [pypy-issue] [issue1257] Memory leak when using web.py
In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org>
Message-ID: <1353842287.49.0.991572663263.issue1257@bugs.pypy.org>


dremon <dmitry at pankratov.net> added the comment:

Within 2-3 minutes it went up to 600Mb resident memory on my system when ssl is
enabled.

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

From tracker at bugs.pypy.org  Sun Nov 25 16:21:20 2012
From: tracker at bugs.pypy.org (Remi)
Date: Sun, 25 Nov 2012 15:21:20 +0000
Subject: [pypy-issue] [issue1340] stm-thread-2: Double acquire of lock when
	atomic
In-Reply-To: <1353856880.38.0.195191521377.issue1340@bugs.pypy.org>
Message-ID: <1353856880.38.0.195191521377.issue1340@bugs.pypy.org>


New submission from Remi <remi.meier at gmail.com>:

Example:
------------------------
import Queue
from thread import atomic
q = Queue.Queue()
with atomic:
    q.get()
------------------------
Output:
error: deadlock: an atomic transaction tries to acquire a lock that is already 
acquired.  See pypy/doc/stm.rst.
------------------------
Reason:
Queue() depends on Condition() which implements wait() by acquiring an already acquired 
lock. Other example:
------------------------
import thread
from thread import atomic
q = thread.allocate_lock()
with atomic:
    l.acquire()
    l.acquire()
------------------------

----------
messages: 5037
nosy: Remi, pypy-issue
priority: bug
status: unread
title: stm-thread-2: Double acquire of lock when atomic

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

From tracker at bugs.pypy.org  Sun Nov 25 21:38:01 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 25 Nov 2012 20:38:01 +0000
Subject: [pypy-issue] [issue1338] Epoll object cannot be closed twice
In-Reply-To: <1353772932.73.0.836119568946.issue1338@bugs.pypy.org>
Message-ID: <1353875881.61.0.942751570012.issue1338@bugs.pypy.org>


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

tag:easy

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

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

From tracker at bugs.pypy.org  Sun Nov 25 22:01:08 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 25 Nov 2012 21:01:08 +0000
Subject: [pypy-issue] [issue1257] Memory leak when using web.py
In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org>
Message-ID: <1353877268.35.0.562165150654.issue1257@bugs.pypy.org>


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

It would be nice to have another test, if possible with synchronous code.
Note that OpenSSL is a C extension module...

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Sun Nov 25 22:23:51 2012
From: tracker at bugs.pypy.org (dremon)
Date: Sun, 25 Nov 2012 21:23:51 +0000
Subject: [pypy-issue] [issue1257] Memory leak when using web.py
In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org>
Message-ID: <1353878631.66.0.928734812766.issue1257@bugs.pypy.org>


dremon <dmitry at pankratov.net> added the comment:

I have attached a synchronous test which uses built-in python ssl module. The
issue still remains.
(also attaching the server.pem file).

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

From tracker at bugs.pypy.org  Mon Nov 26 20:58:21 2012
From: tracker at bugs.pypy.org (Steve Clift)
Date: Mon, 26 Nov 2012 19:58:21 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1353959901.94.0.569802173683.issue1297@bugs.pypy.org>


Steve Clift <Steve.Clift at L-3Com.com> added the comment:

Appears to be fixed in 2.0-beta-1. Thanks.

I had problems testing with the overnight builds because they linked against
more recent libraries than I had in any of my Linux systems. What do you build on?

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

From tracker at bugs.pypy.org  Tue Nov 27 03:09:15 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Tue, 27 Nov 2012 02:09:15 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>


New submission from Jon Oberheide <jonojono at umich.edu>:

pypy 2.0 beta:

Fatal error in cpyext, CPython compatibility layer, calling PyEval_SaveThread
Eit
<SystemError object at 0x2f198c8>
RPython traceback:
  File "implement_9.c", line 2196, in descr_typecheck_descr_get__bases__
  File "pypy_objspace_std_specialisedtupleobject.c", line 137, in 
makespecialisedtuple
Segmentation fault

hits consistently when doing mass INSERTs using mysql-python 1.2.4c1.

----------
messages: 5042
nosy: jonojono, pypy-issue
priority: bug
status: unread
title: fatal cpyext error with PyEval_SaveThread

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

From tracker at bugs.pypy.org  Tue Nov 27 03:20:59 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Tue, 27 Nov 2012 02:20:59 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1353982859.81.0.785774989572.issue1341@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

also saw the following:

<SystemError object at 0x2f198c8>
RPython traceback:
  File "pypy_jit_metainterp_warmspot.c", line 1331, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_jit_metainterp_blackhole.c", line 43008, in resume_in_blackhole

not sure if they're at all related

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

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

From tracker at bugs.pypy.org  Tue Nov 27 03:23:46 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Tue, 27 Nov 2012 02:23:46 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1353983026.98.0.905891565555.issue1341@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

yet another:

<SystemError object at 0x2f198c8>
RPython traceback:
  File "pypy_interpreter_pyopcode.c", line 9968, in 
dispatch_bytecode__AccessDirect_None
  File "implement.c", line 50470, in __mm_nonzero_0_fail

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

From tracker at bugs.pypy.org  Tue Nov 27 13:37:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 27 Nov 2012 12:37:40 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1354019860.28.0.221089676538.issue1297@bugs.pypy.org>


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

I'm closing the issue then. We now have 2 linux 64 builds (also nightlies) for 
different versions of libc (2.13 and 2.15), one of them should work for you.

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

From tracker at bugs.pypy.org  Tue Nov 27 21:02:28 2012
From: tracker at bugs.pypy.org (Senyai)
Date: Tue, 27 Nov 2012 20:02:28 +0000
Subject: [pypy-issue] [issue1342] Recursion question
In-Reply-To: <1354046548.64.0.959989909311.issue1342@bugs.pypy.org>
Message-ID: <1354046548.64.0.959989909311.issue1342@bugs.pypy.org>


New submission from Senyai <senyai at gmail.com>:

Hello.

I wonder why recursion is so fast compared to linear approach.

----------
files: recursion_question.py
messages: 5046
nosy: pypy-issue, senyai
priority: wish
status: unread
title: Recursion question

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1342>
________________________________________
-------------- next part --------------
import timeit

val = 9450847
_base = 62

def rec(n, ret):
    a, b = divmod(n, _base)
    ret.append(b)
    if a:
        return rec(a, ret)
    ret.reverse()
    return ret

def lin(n):
    ret = []
    while n:
        n, b = divmod(n, _base)
        ret.append(b)
    ret.reverse()
    return ret

for i in xrange(3):
    print "l", timeit.Timer('lin(val)', 'from __main__ import lin, val').timeit(number=1000000)
    print "r", timeit.Timer('rec(val, [])', 'from __main__ import rec, val').timeit(number=1000000)

From tracker at bugs.pypy.org  Wed Nov 28 23:45:46 2012
From: tracker at bugs.pypy.org (Daniel Roberts)
Date: Wed, 28 Nov 2012 22:45:46 +0000
Subject: [pypy-issue] [issue1328] cProfile: slow on built-in function calls
In-Reply-To: <1353277066.05.0.0979170791847.issue1328@bugs.pypy.org>
Message-ID: <1354142746.44.0.153679157127.issue1328@bugs.pypy.org>


Daniel Roberts <Ademan555 at gmail.com> added the comment:

This looks fixed as of 
https://bitbucket.org/pypy/pypy/src/7c881e2648065a2b25155d9cbda18534ecd
eb2ec/pypy/module/_lsprof/interp_lsprof.py?at=default

Performance hit for me is down to 3-4x from 15-20x so I'm happy with 
current performance.

----------
status: unread -> testing

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

From tracker at bugs.pypy.org  Thu Nov 29 01:07:23 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 29 Nov 2012 00:07:23 +0000
Subject: [pypy-issue] [issue1323] subprocess.call,
	threading.Thread and OS X does not complete
In-Reply-To: <1352835553.52.0.869443140345.issue1323@bugs.pypy.org>
Message-ID: <1354147643.1.0.668489707422.issue1323@bugs.pypy.org>


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

Fixed, I think.  joushou, can you confirm it on the next nightly build?  If it
works, mark the bug as "resolved".

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

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

From tracker at bugs.pypy.org  Thu Nov 29 14:38:34 2012
From: tracker at bugs.pypy.org (Gustavo Carneiro)
Date: Thu, 29 Nov 2012 13:38:34 +0000
Subject: [pypy-issue] [issue1343] datetime constructors are slow
In-Reply-To: <1354196314.23.0.545969896857.issue1343@bugs.pypy.org>
Message-ID: <1354196314.23.0.545969896857.issue1343@bugs.pypy.org>


New submission from Gustavo Carneiro <gjcarneiro at gmail.com>:

With pypy 2.0 beta1, I find that datetime.utcnow is much slower in PyPy than CPython.

--------
import timeit
print timeit.Timer("datetime.datetime.utcnow()", "import datetime").timeit(10000000)
--------
$ python /tmp/test.py 
3.894135952
$ pypy /tmp/test.py 
10.3476600647

----------
messages: 5049
nosy: gjc, pypy-issue
priority: performance bug
release: 2.0
status: unread
title: datetime constructors are slow

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