From tracker at bugs.pypy.org  Sun Dec  2 17:59:08 2012
From: tracker at bugs.pypy.org (Diego Javier Zea)
Date: Sun, 02 Dec 2012 16:59:08 +0000
Subject: [pypy-issue] [issue1344] Pypy slower in recursion than Python2.7,
	Python3.2 and Julia
In-Reply-To: <1354467548.11.0.960351592356.issue1344@bugs.pypy.org>
Message-ID: <1354467548.11.0.960351592356.issue1344@bugs.pypy.org>


New submission from Diego Javier Zea <diego_zea at yahoo.com.ar>:

I run in Pypy the pure python functions of the Julia test [
https://github.com/JuliaLang/julia/blob/master/test/perf/perf.py ]

For this function using recursion:

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

Pypy 1.9 was more slow than Python 2.7 and 3.2 (and than Julia):

	Julia	Pypy	Python2.7	Python3.2
fib	0.072	3.857	1.601	        1.889

[ For see more timings:
http://stackoverflow.com/questions/10775510/julias-python-performance-example-in-pypy
]

Why recursion is so slow in Pypy 1.9 ?

Best wishes

----------
messages: 5050
nosy: diego_zea, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: Pypy slower in recursion than Python2.7, Python3.2 and Julia

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

From tracker at bugs.pypy.org  Sun Dec  2 18:15:07 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 02 Dec 2012 17:15:07 +0000
Subject: [pypy-issue] [issue1344] Pypy slower in recursion than Python2.7,
	Python3.2 and Julia
In-Reply-To: <1354467548.11.0.960351592356.issue1344@bugs.pypy.org>
Message-ID: <1354468507.88.0.047006321326.issue1344@bugs.pypy.org>


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

Can you please try again with the PyPy 2.0 beta or one of the nightly builds.

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

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

From tracker at bugs.pypy.org  Sun Dec  2 18:20:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 02 Dec 2012 17:20:50 +0000
Subject: [pypy-issue] [issue1344] Pypy slower in recursion than Python2.7,
	Python3.2 and Julia
In-Reply-To: <1354467548.11.0.960351592356.issue1344@bugs.pypy.org>
Message-ID: <1354468850.38.0.0541292925213.issue1344@bugs.pypy.org>


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

Hi. This is a situation where the warmup time is very significant (it tries to 
inline all the recursion), but once you warm it up it's actually very fast. 
Increase the number from 5 to 500 and see how it goes. I'm closing this as 
invalid, feel free to open "improve warmup time of recursive calls" as a separate 
ticket.

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

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

From tracker at bugs.pypy.org  Mon Dec  3 02:19:24 2012
From: tracker at bugs.pypy.org (Diego Javier Zea)
Date: Mon, 03 Dec 2012 01:19:24 +0000
Subject: [pypy-issue] [issue1345] Improve warmup time of recursive calls [
	Pypy slow in	recursion ]
In-Reply-To: <1354497564.22.0.422486712884.issue1345@bugs.pypy.org>
Message-ID: <1354497564.22.0.422486712884.issue1345@bugs.pypy.org>


New submission from Diego Javier Zea <diego_zea at yahoo.com.ar>:

I check the timing for this recursive function [ fib(n) ] on Pypy [ 1.9 and 2.0
] and Python [ 2.7 and 3.0 ] and Pypy is slower than python with n < 30. After
this, Pypy 1.9 seems to be a little more faster than 2.0 [ but maybe is not
significantly different ]:

n   Julia	Pypy1.9	Pypy2.0	Python2.7 Python3.2
10  1.145	0.039	0.087	0.015	0.036
20  0.077	47.5	80	2.19	4.060
30  9.26	139	189	207	504
40  1154	19467	21390	26020	39166
50  144305	2796847	2913148	4227585	4168628


The function is from perf.py of Julia git:

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

----------
files: warmup.png
messages: 5053
nosy: diego_zea, pypy-issue
priority: performance bug
release: 2.0
status: unread
title: Improve warmup time of recursive calls [ Pypy slow in recursion ]

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

From tracker at bugs.pypy.org  Mon Dec  3 18:27:52 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 03 Dec 2012 17:27:52 +0000
Subject: [pypy-issue] [issue1345] Improve warmup time of recursive calls [
	Pypy slow in	recursion ]
In-Reply-To: <1354497564.22.0.422486712884.issue1345@bugs.pypy.org>
Message-ID: <1354555672.11.0.0356268638514.issue1345@bugs.pypy.org>


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

Note that you're messing up two issues here. Large fibonaccis are using longs 
and have a completely different hotspot. What you should do to measure small 
numbers would be to compute f(10) about 500 times or so. (increase as necessary) 
and see how that behaves.

It's also worth noting that while super famous, the recursive fibonacci is a 
really bad benchmark. It's also known to particularly suck on PyPy for obscure 
reasons (which don't apply to more complicated recursion in the same extend). 
That said, the warmup time can definitely be improved in general.

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

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

From tracker at bugs.pypy.org  Mon Dec  3 18:51:08 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 03 Dec 2012 17:51:08 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354557068.57.0.471854376085.issue1016@bugs.pypy.org>


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

The branch 'remove-globals-in-jit' should finally fix the issue, or at least
make it less likely to show up.  (It does not make greenlets more generally
JITable though, and doesn't fully fix this issue either, because it's still
possible to force a frame that belongs to another greenlet than we do (although
hard).)  Can anyone check it on OS/X?  A prebuilt OS/X binary to use should show
up in http://buildbot.pypy.org/nightly/remove-globals-in-jit/ .

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

From tracker at bugs.pypy.org  Mon Dec  3 20:23:04 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Mon, 03 Dec 2012 19:23:04 +0000
Subject: [pypy-issue] [issue1091] list(xrange) is slower in PyPy 1.8 than in
	CPython 2.6.5
In-Reply-To: <1331824783.12.0.608099911457.issue1091@bugs.pypy.org>
Message-ID: <1354562584.32.0.507188363101.issue1091@bugs.pypy.org>


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

The length-hint branch was merged to default and is included in the pypy 2.0 
betas. It adds PEP 424 support and also optimizes list creation/extend for 
generic iterables such as xrange.

Last time I checked this list(xrange(10000000)) case is now significantly faster 
than CPython

----------
release:  -> 2.0
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Mon Dec  3 21:47:33 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Mon, 03 Dec 2012 20:47:33 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354567653.86.0.613306692854.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

I tried both the "nightly" and a locally built copy from that branch. I'm getting 
a different error now at least.

{examples} $ PYTHONPATH=.. ./pypy-c-jit-59294-2433a3c3072c-osx64/bin/pypy both.py
RPython traceback:
  File "pypy_jit_metainterp_compile.c", line 21868, in send_loop_to_backend
  File "pypy_jit_backend_x86_assembler.c", line 2924, in 
Assembler386_assemble_loop
  File "pypy_jit_backend_x86_assembler.c", line 6218, in Assembler386__assemble
  File "pypy_jit_backend_x86_regalloc.c", line 2306, in RegAlloc_walk_operations
  File "pypy_jit_backend_x86_regalloc.c", line 46789, in 
RegAlloc_perform_with_guard
  File "pypy_jit_backend_x86_assembler.c", line 59335, in 
Assembler386_genop_guard_call_assembler
  File "pypy_jit_backend_x86_rx86.c", line 6374, in INSN__star_3
Fatal RPython error: AssertionError
zsh: abort      PYTHONPATH=.. ./pypy-c-jit-59294-2433a3c3072c-osx64/bin/pypy 
both.py
{examples} $ PYTHONPATH=.. pypy both.py
RPython traceback:
  File "pypy_jit_metainterp_compile.c", line 21825, in send_loop_to_backend
  File "pypy_jit_backend_x86_assembler.c", line 2932, in 
Assembler386_assemble_loop
  File "pypy_jit_backend_x86_assembler.c", line 6229, in Assembler386__assemble
  File "pypy_jit_backend_x86_regalloc.c", line 2305, in RegAlloc_walk_operations
  File "pypy_jit_backend_x86_regalloc.c", line 46776, in 
RegAlloc_perform_with_guard
  File "pypy_jit_backend_x86_assembler.c", line 59364, in 
Assembler386_genop_guard_call_assembler
  File "pypy_jit_backend_x86_rx86.c", line 6383, in INSN__star_3
Fatal RPython error: AssertionError
zsh: abort      PYTHONPATH=.. pypy both.py

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

From tracker at bugs.pypy.org  Fri Dec  7 01:13:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 07 Dec 2012 00:13:46 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354839226.23.0.0658615305209.issue1016@bugs.pypy.org>


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

Thanks, another bug.  Fixed in 0f15c980ba05.  Another os/x build should appear
shortly in http://buildbot.pypy.org/nightly/remove-globals-in-jit/

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

From tracker at bugs.pypy.org  Fri Dec  7 02:51:18 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Fri, 07 Dec 2012 01:51:18 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354845078.12.0.826694169953.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

I'm not able to build now....
{goal} $ ./pypy-c translate.py -Ojit --output=pypy-c.new                                                                                                                                                                                          
(justin at Justins-MacBook-Pro:)
[platform:msg] Set platform with 'host' cc=None, using cc='gcc'
[translation:info] Translating target as defined by targetpypystandalone
RPython traceback:
  File "pypy_jit_metainterp_compile.c", line 21825, in send_loop_to_backend
  File "pypy_jit_backend_x86_assembler.c", line 2932, in 
Assembler386_assemble_loop
  File "pypy_jit_backend_x86_assembler.c", line 6229, in Assembler386__assemble
  File "pypy_jit_backend_x86_regalloc.c", line 2305, in RegAlloc_walk_operations
  File "pypy_jit_backend_x86_regalloc.c", line 46776, in 
RegAlloc_perform_with_guard
  File "pypy_jit_backend_x86_assembler.c", line 59364, in 
Assembler386_genop_guard_call_assembler
  File "pypy_jit_backend_x86_rx86.c", line 6383, in INSN__star_3
Fatal RPython error: AssertionError

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

From tracker at bugs.pypy.org  Fri Dec  7 02:53:31 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 07 Dec 2012 01:53:31 +0000
Subject: [pypy-issue] [issue1336] binary for debian squeeze 64
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1354845211.54.0.0682353644532.issue1336@bugs.pypy.org>


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

We would love to see a reasonable way on Linux to make binary programs that run
anywhere, short of distributing fully static binaries.  If we linked with
libssl.so.0.9.8, it would fail to work on some other distributions.  We picked
1.0.0 as the way forward.  Sorry, you'll have to install libssl.so.1.0.0 on your
distribution for this to work.  (If you're paranoid about security, then I don't
see how a fully static binary with openssl 1.0.0 included would help...)

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

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

From tracker at bugs.pypy.org  Fri Dec  7 09:51:34 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 07 Dec 2012 08:51:34 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354870294.48.0.278744189085.issue1016@bugs.pypy.org>


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

Well, yes.  You're trying to use the buggy pypy-c to build, so it explodes.  You
need to either use an older pypy-c (or CPython), or just download the build from
http://buildbot.pypy.org/nightly/remove-globals-in-jit/

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

From tracker at bugs.pypy.org  Fri Dec  7 11:48:23 2012
From: tracker at bugs.pypy.org (wilk)
Date: Fri, 07 Dec 2012 10:48:23 +0000
Subject: [pypy-issue] [issue1336] binary for debian squeeze 64
In-Reply-To: <1353689090.59.0.10956462449.issue1336@bugs.pypy.org>
Message-ID: <1354877303.55.0.939748477821.issue1336@bugs.pypy.org>


wilk <wilk at flibuste.net> added the comment:

No problem for me, i build it from trunk. It was just to know.

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

From tracker at bugs.pypy.org  Fri Dec  7 23:44:47 2012
From: tracker at bugs.pypy.org (Justin Patrin)
Date: Fri, 07 Dec 2012 22:44:47 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1354920287.44.0.237197301427.issue1016@bugs.pypy.org>


Justin Patrin <papercrane at reversefold.com> added the comment:

Ah, stupid me.

Using the buildbot version I no longer get an RPython error. I do get a segfault 
after it runs for a while but that's because it's in an infinite loop and is 
probably leaking somewhere. I'd say this bug can finally be closed. :-)

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

From tracker at bugs.pypy.org  Sat Dec  8 14:49:32 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 08 Dec 2012 13:49:32 +0000
Subject: [pypy-issue] [issue1342] Recursion question
In-Reply-To: <1354046548.64.0.959989909311.issue1342@bugs.pypy.org>
Message-ID: <1354974572.12.0.858590806336.issue1342@bugs.pypy.org>


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

Recursion here is shallow enough that it gets reduced to no operations (it gets 
inlined until the bottom). Typically recursion is slower in pypy.

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

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

From tracker at bugs.pypy.org  Sat Dec  8 15:20:16 2012
From: tracker at bugs.pypy.org (ita)
Date: Sat, 08 Dec 2012 14:20:16 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1354976416.23.0.629284124015.issue934@bugs.pypy.org>


ita <tnagy1024 at gmail.com> added the comment:

Pypy 2.0 beta 1 is still having the problem but these nightly builds do not hang
anymore:
pypy-c-jit-59365-f2f4cb496c1c-linux64
pypy-c-nojit-59365-f2f4cb496c1c-linux

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

From tracker at bugs.pypy.org  Sat Dec  8 17:20:05 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 08 Dec 2012 16:20:05 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1354983605.46.0.984399181731.issue934@bugs.pypy.org>


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

Closing then. We'll do another beta soon.

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

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

From tracker at bugs.pypy.org  Sat Dec  8 20:34:53 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 08 Dec 2012 19:34:53 +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: <1354995293.89.0.193990492172.issue1320@bugs.pypy.org>


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

Testing the fixes done in b9699de4f839...

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

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

From tracker at bugs.pypy.org  Sat Dec  8 21:08:19 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 08 Dec 2012 20:08:19 +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: <1354997299.41.0.746915275195.issue1320@bugs.pypy.org>


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

Seems to be fixed.  At least, now it runs quickly into MemoryErrors or "can't
start new thread" errors from the pthread library.

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

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

From tracker at bugs.pypy.org  Mon Dec 10 01:05:59 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 10 Dec 2012 00:05:59 +0000
Subject: [pypy-issue] [issue1324] stm-thread-2: SIGSEGV in pypy_g_bootstrap()
In-Reply-To: <1352900746.04.0.778105672124.issue1324@bugs.pypy.org>
Message-ID: <1355097959.52.0.627329008348.issue1324@bugs.pypy.org>


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

Seems fixed in d2c80171d20e and 895204d1310d, as discussed on IRC.

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

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

From tracker at bugs.pypy.org  Mon Dec 10 02:01:34 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 10 Dec 2012 01:01:34 +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: <1355101294.27.0.81342358531.issue1340@bugs.pypy.org>


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

It's unclear what we can do about it.  We're in an atomic transaction, so we
can't wait until another thread puts an item in the Queue --- from the point of
view of the programmer, no other thread can run concurrently with an atomic block.

What we could imagine would be to abort the whole transaction and wait until the
lock is released before restarting it.  But aborting a transaction cannot be
done if it is also inevitable, e.g. because of a "print" before...

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

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

From tracker at bugs.pypy.org  Tue Dec 11 15:39:50 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 11 Dec 2012 14:39:50 +0000
Subject: [pypy-issue] [issue1326] stm-thread-2: free(): invalid pointer
In-Reply-To: <1352979326.15.0.950497525491.issue1326@bugs.pypy.org>
Message-ID: <1355236790.65.0.697891901821.issue1326@bugs.pypy.org>


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

Seems to have been fixed.

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

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

From tracker at bugs.pypy.org  Tue Dec 11 20:07:27 2012
From: tracker at bugs.pypy.org (Diego Javier Zea)
Date: Tue, 11 Dec 2012 19:07:27 +0000
Subject: [pypy-issue] [issue1346] Bio.AlignIO slower on Pypy than in
	Python2.7 ?
In-Reply-To: <1355252847.91.0.0600200937549.issue1346@bugs.pypy.org>
Message-ID: <1355252847.91.0.0600200937549.issue1346@bugs.pypy.org>


New submission from Diego Javier Zea <diego_zea at yahoo.com.ar>:

time pypy2.0 MI_PDB_partII.py 
[SeqRecord(seq=Seq('------------------------------------------------------...---',
SingleLetterAlphabet()), id='CPXA_PSEPU/175-394', name='CPXA_PSEPU/175-394',
description='CPXA_PSEPU/175-394', dbxrefs=[])]

real	0m6.126s
user	0m6.060s
sys	0m0.048s

time python2.7 MI_PDB_partII.py 
[SeqRecord(seq=Seq('------------------------------------------------------...---',
SingleLetterAlphabet()), id='CPXA_PSEPU/175-394', name='CPXA_PSEPU/175-394',
description='CPXA_PSEPU/175-394', dbxrefs=[])]

real	0m1.373s
user	0m1.292s
sys	0m0.072s


Read a Alignment with Pypy is slower than reading the same Alignment with Python
2.7 :/

----------
files: MI_PDB_partII.py
messages: 5072
nosy: diego_zea, pypy-issue
priority: performance bug
release: 2.0
status: unread
title: Bio.AlignIO slower on Pypy than in Python2.7 ?

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

From tracker at bugs.pypy.org  Thu Dec 13 15:44:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 13 Dec 2012 14:44:00 +0000
Subject: [pypy-issue] [issue1346] Bio.AlignIO slower on Pypy than in
	Python2.7 ?
In-Reply-To: <1355252847.91.0.0600200937549.issue1346@bugs.pypy.org>
Message-ID: <1355409840.71.0.735173140961.issue1346@bugs.pypy.org>


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

Hi Diego.

In order to do anything about it, please add a missing fasta file to this bug 
report.

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

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

From tracker at bugs.pypy.org  Sat Dec 15 08:42:56 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 15 Dec 2012 07:42:56 +0000
Subject: [pypy-issue] [issue1348] numpypy: bug with isfinite() on integer
	array
In-Reply-To: <1355557376.47.0.909537678888.issue1348@bugs.pypy.org>
Message-ID: <1355557376.47.0.909537678888.issue1348@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>>> import numpypy as np
>>>> np.isfinite([1.0, 2, 3])
array([ True,  True,  True], dtype=bool)
>>>> np.isfinite([1, 2, 3])
Segmentation fault (core dumped)

----------
messages: 5075
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with isfinite() on integer array

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

From tracker at bugs.pypy.org  Sat Dec 15 10:18:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 15 Dec 2012 09:18:12 +0000
Subject: [pypy-issue] [issue1348] numpypy: bug with isfinite() on integer
	array
In-Reply-To: <1355557376.47.0.909537678888.issue1348@bugs.pypy.org>
Message-ID: <1355563092.15.0.762544131434.issue1348@bugs.pypy.org>


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

Oops, fixed in 4073ceef4ea7

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

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

From tracker at bugs.pypy.org  Sat Dec 15 14:32:55 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 15 Dec 2012 13:32:55 +0000
Subject: [pypy-issue] [issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX
	|	fcntl.LOCK_NB)
In-Reply-To: <1307775802.38.0.717100903574.issue747@bugs.pypy.org>
Message-ID: <1355578375.48.0.352549499177.issue747@bugs.pypy.org>


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

Fixed in c1024ee7bb9c.  Thanks bdk!

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

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

From tracker at bugs.pypy.org  Sun Dec 16 13:30:24 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 16 Dec 2012 12:30:24 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1355661024.34.0.784299559685.issue1236@bugs.pypy.org>


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

Anyone feels like testing it with pypy 2.0 beta or with the latest nightly build?

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

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

From tracker at bugs.pypy.org  Sun Dec 16 19:08:39 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sun, 16 Dec 2012 18:08:39 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1355681319.43.0.417302410174.issue1236@bugs.pypy.org>


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

Still produces error on:
pypy-c-jit-latest-win32.zip	15M	2012-12-06	
E:\pypy-c-jit-59335-7f02f3e6fbe6-win32>pypy.exe pypyflaskmongo.py
RPython traceback:
  File "pypy_jit_metainterp_compile.c", line 100, in force_now_1
  File "pypy_jit_metainterp_compile.c", line 162, in 
ResumeGuardForcedDescr_handle_async_forcing
Fatal RPython error: AssertionError

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

E:\pypy-c-jit-59335-7f02f3e6fbe6-win32>pypy.exe
Python 2.7.3 (7f02f3e6fbe6, Dec 06 2012, 05:30:31)
[PyPy 2.0.0-beta1 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``well, it's wrong but not so "very
wrong" as it looked''
>>>> ^D
  File "<console>", line 1
    
    ^
SyntaxError: Unknown character
>>>> ^Z


E:\pypy-c-jit-59335-7f02f3e6fbe6-win32>

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

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

From tracker at bugs.pypy.org  Sun Dec 16 19:26:42 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sun, 16 Dec 2012 18:26:42 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1355682402.48.0.547467687206.issue1236@bugs.pypy.org>


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

And also for latest linux64 version:
pypy-c-jit-latest-linux64.tar.bz2	17M	2012-12-16

zys at gpuserver:~/pypytest/pypy-c-jit-59451-9f75b268adc1-linux64/bin$ ./pypy 
pypyflaskmongo.py
RPython traceback:
  File "pypy_jit_metainterp_compile.c", line 97, in force_now_1
  File "pypy_jit_metainterp_compile.c", line 163, in 
ResumeGuardForcedDescr_handle_async_forcing
Fatal RPython error: AssertionError
Aborted (core dumped)
zys at gpuserver:~/pypytest/pypy-c-jit-59451-9f75b268adc1-linux64/bin$ ./pypy
Python 2.7.3 (9f75b268adc1, Dec 16 2012, 02:00:14)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy is Shirt Origami research''
>>>>

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

From tracker at bugs.pypy.org  Sun Dec 16 19:45:06 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Sun, 16 Dec 2012 18:45:06 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>


New submission from Irmen de Jong <irmen at razorvine.net>:

Using Pypy 1.9.0. Importing readline. Using a background thread to get input()
from stdin. It then crashes with:

  File "/usr/local/Cellar/pypy/1.9/lib_pypy/pyrepl/unix_console.py", line 400,
in restore
    signal.signal(signal.SIGWINCH, self.old_sigwinch)
ValueError: signal() must be called from the main thread

Anyone seen this before? What's going on?
When I don't import readline, or do the input() from within the main thread, the
problem disappears.

(I tried to reproduce it in a small test scenario but unfortunately have not
been able to do so yet. Haven't figured out yet what the additional factors are
that trigger this problem. A simple import readline and input() from a new
thread doesn't seem to trigger it, unfortunately)

----------
messages: 5081
nosy: irmen, pypy-issue
priority: bug
release: 1.9
status: unread
title: input+thread+readline = signal crash

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

From tracker at bugs.pypy.org  Sun Dec 16 19:46:19 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Sun, 16 Dec 2012 18:46:19 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355683579.26.0.0654253353446.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

oops, forgot to mention, platform = OS X (10.6.8) and Linux (ubuntu 12.04 lts)

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

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

From tracker at bugs.pypy.org  Sun Dec 16 21:24:21 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 16 Dec 2012 20:24:21 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355689461.5.0.428060383874.issue1349@bugs.pypy.org>


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

This was already fixed it seems.
Could you try with a newer version, or try the patch below:
https://bitbucket.org/pypy/pyrepl/commits/714bcbd37203/

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

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

From tracker at bugs.pypy.org  Sun Dec 16 23:16:24 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Sun, 16 Dec 2012 22:16:24 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355696184.05.0.725633367804.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Thanks for your reply, I tried it with Pypy-2.0.0-beta1. (on OS X) But the problem 
remains.

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

From tracker at bugs.pypy.org  Mon Dec 17 09:59:13 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 17 Dec 2012 08:59:13 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355734753.36.0.956185190525.issue1349@bugs.pypy.org>


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

I could not reproduce the error.  Do you have a sample case?

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

From tracker at bugs.pypy.org  Mon Dec 17 12:46:20 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Mon, 17 Dec 2012 11:46:20 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355744780.36.0.713041129021.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Sorry, not at this time. An attempt to create a minimal test case failed. I
might have to strip down my application to condense it to a sample case, but
that will take some effort. Will see if I can find some time in the coming days.

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

From tracker at bugs.pypy.org  Mon Dec 17 19:41:02 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Mon, 17 Dec 2012 18:41:02 +0000
Subject: [pypy-issue] [issue1350] pypy 2.0 beta crashes with illegal
	instruction on os x	10.6.8
In-Reply-To: <1355769662.9.0.493494609672.issue1350@bugs.pypy.org>
Message-ID: <1355769662.9.0.493494609672.issue1350@bugs.pypy.org>


New submission from Irmen de Jong <irmen at razorvine.net>:

Trying pypy-2.0-beta1 on OS X 10.6.8 (snow leopard) aborts immediately with
Illegal Instruction. Seems to work on OS X 10.8 (mountain lion).

----------
messages: 5087
nosy: irmen, pypy-issue
priority: bug
release: 2.0
status: unread
title: pypy 2.0 beta crashes with illegal instruction on os x 10.6.8

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

From tracker at bugs.pypy.org  Mon Dec 17 20:08:38 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Mon, 17 Dec 2012 19:08:38 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355771318.49.0.869503606197.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

I've looked at the changeset you linked and the second part of the patch (around
line 400) doesn't seem to have landed in 2.0-beta1. The first part has,
strangely enough

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

From tracker at bugs.pypy.org  Mon Dec 17 22:47:19 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Mon, 17 Dec 2012 21:47:19 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355780839.19.0.154042734863.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Ok, I've managed to produce a minimal test program that reproduces the error:


import threading, time
import readline   # without readline, no problems

class AsyncInput(threading.Thread):
    def run(self):
        raw_input("(from thread) Type something else: ")

# this input statement triggers the signal bug in pypy at the input in the thread
# removing it makes the problem go away...
raw_input("(from main) Type something: ")

async = AsyncInput()
async.daemon = True
async.start()
time.sleep(100)

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

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

From tracker at bugs.pypy.org  Tue Dec 18 08:55:31 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 18 Dec 2012 07:55:31 +0000
Subject: [pypy-issue] [issue1350] pypy 2.0 beta crashes with illegal
	instruction on os x	10.6.8
In-Reply-To: <1355769662.9.0.493494609672.issue1350@bugs.pypy.org>
Message-ID: <1355817331.57.0.274927333301.issue1350@bugs.pypy.org>


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

This is a known issue, try the latest nightly. It also has some other fix for the 
OS X.

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

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

From tracker at bugs.pypy.org  Tue Dec 18 12:12:20 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 18 Dec 2012 11:12:20 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355829140.13.0.252200846607.issue1349@bugs.pypy.org>


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

Oh, this happens when input() is called from the main thread, and afterwards from a spawned 
thread.  The patch below seems to fix the issue.
Don't call input() from both threads at the same time, though;  this UnixConsole is 
absolutely not thread-safe anyway.

--- a/lib_pypy/pyrepl/unix_console.py	Sat Dec 15 16:35:08 2012 +0100
+++ b/lib_pypy/pyrepl/unix_console.py	Tue Dec 18 12:08:50 2012 +0100
@@ -398,6 +398,7 @@
 
         if hasattr(self, 'old_sigwinch'):
             signal.signal(signal.SIGWINCH, self.old_sigwinch)
+            del self.old_sigwinch
 
     def __sigwinch(self, signum, frame):
         self.height, self.width = self.getheightwidth()

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

From tracker at bugs.pypy.org  Tue Dec 18 12:52:08 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 18 Dec 2012 11:52:08 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1355831528.9.0.749550560002.issue1236@bugs.pypy.org>


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

Sorry, the branch has not been merged yet.  It is 'remove-globals-in-jit'.

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

From tracker at bugs.pypy.org  Tue Dec 18 14:06:03 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Tue, 18 Dec 2012 13:06:03 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1355835963.2.0.460639985235.issue1236@bugs.pypy.org>


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

Results in a segmentation fault (with core dump)

zys at gpuserver:~/pypytest/pypy-c-jit-59239-3f59cdbc4c52-linux64/bin$ ./pypy 
pypyflaskmongo.py
Segmentation fault (core dumped)

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

From tracker at bugs.pypy.org  Tue Dec 18 20:02:56 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Tue, 18 Dec 2012 19:02:56 +0000
Subject: [pypy-issue] [issue1350] pypy 2.0 beta crashes with illegal
	instruction on os x	10.6.8
In-Reply-To: <1355769662.9.0.493494609672.issue1350@bugs.pypy.org>
Message-ID: <1355857376.53.0.815549136746.issue1350@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Thanks, the latest nightly works.

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

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

From tracker at bugs.pypy.org  Tue Dec 18 20:07:15 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Tue, 18 Dec 2012 19:07:15 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355857635.19.0.0562872692438.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

The latest nightly build still crashes on this issue. 

I'm not calling input() at the same time from different threads, I'm using
synchronization primitives. Thanks for the warning though. Still, even with the
synchronization, the program crashes.

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

From tracker at bugs.pypy.org  Tue Dec 18 20:12:34 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 18 Dec 2012 19:12:34 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355857954.6.0.732715517688.issue1349@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

@irmen: did you try to apply Amaury's patch? He did not commit it, so you should
apply it by yourself and see if it still crashes

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

From tracker at bugs.pypy.org  Tue Dec 18 20:16:01 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Tue, 18 Dec 2012 19:16:01 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355858161.02.0.793789762528.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Sorry, I'm no pypy dev. I'm running whatever prebuilt binary I can download for
my platform.

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

From tracker at bugs.pypy.org  Tue Dec 18 20:24:41 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 18 Dec 2012 19:24:41 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355858681.37.0.308937519254.issue1349@bugs.pypy.org>


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

Fortunately the pyrepl is a pure python module, you should find this file in 
your local installation.

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

From tracker at bugs.pypy.org  Tue Dec 18 20:44:54 2012
From: tracker at bugs.pypy.org (Irmen de Jong)
Date: Tue, 18 Dec 2012 19:44:54 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1355859894.51.0.20440267518.issue1349@bugs.pypy.org>


Irmen de Jong <irmen at razorvine.net> added the comment:

Silly me. I changed the python file as per the patch and yes, the crash is gone.

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

From tracker at bugs.pypy.org  Thu Dec 20 23:04:14 2012
From: tracker at bugs.pypy.org (Kevin Duffy)
Date: Thu, 20 Dec 2012 22:04:14 +0000
Subject: [pypy-issue] [issue1351] ctypes.util._findLib_gcc can't find a
	non-system library
In-Reply-To: <1356041054.91.0.123525333603.issue1351@bugs.pypy.org>
Message-ID: <1356041054.91.0.123525333603.issue1351@bugs.pypy.org>


New submission from Kevin Duffy <duffy151+pypy at gmail.com>:

Using cffi 0.4.2 and PyPy 2.0b1 on linux,

- compile a C library
- Write a python extension for it using cffi where ffi.dlopen(<library>) is used 
(not ffi.verify())
- ship the library and python program in this filesystem configuration:

<prog-root>/lib/c-library.so
<prog-root>/bin/prog.py

- Run like:
LD_LIBRARY_PATH=<prog-root>/lib pypy <prog-root>/bin/prog.py

Results:
- the ffi.dlopen() fails to find the user library

Drilling down on this, ffi.dlopen() will eventually call ctypes.util._findLib_gcc 
(on linux anyway). This attempts to have gcc link with the library in order to 
find it. But this doesn't take into account the LD_LIBRARY_PATH so the link fails. 
If you convert the LD_LIBRARY_PATH env variable in to "-L" args to gcc, 
ffi.dlopen() works.

----------
messages: 5100
nosy: duffy151, pypy-issue
priority: bug
status: unread
title: ctypes.util._findLib_gcc can't find a non-system library

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

From tracker at bugs.pypy.org  Fri Dec 21 23:46:30 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Fri, 21 Dec 2012 22:46:30 +0000
Subject: [pypy-issue] [issue1241] [cpyext] PyUnicode_Tailmatch() fails to
	match with high	end bounds
In-Reply-To: <1345732226.32.0.922173740669.issue1241@bugs.pypy.org>
Message-ID: <1356129990.76.0.989569006455.issue1241@bugs.pypy.org>


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

bump

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

From tracker at bugs.pypy.org  Sat Dec 22 06:27:11 2012
From: tracker at bugs.pypy.org (Enzo Michelangeli)
Date: Sat, 22 Dec 2012 05:27:11 +0000
Subject: [pypy-issue] [issue1352] In numpypy,
	the functions min() and max() are broken
In-Reply-To: <1356154031.12.0.788167355877.issue1352@bugs.pypy.org>
Message-ID: <1356154031.12.0.788167355877.issue1352@bugs.pypy.org>


New submission from Enzo Michelangeli <enzomich at gmail.com>:

See below:

[PyPy 2.0.0-beta1 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``today we're faster than yesterday
(usually)''
>>>> min(100,1)
1
>>>> max(1,100)
100
>>>> from numpypy import *  # Now we import numpypy
>>>> min(100,1)
100                    # <---- WRONG!
>>>> max(1,100)
1                      # <---- WRONG!
# But, inverting the order of the arguments:
>>>> max(100,1)
100
>>>> min(1,100)
1
>>>>

----------
messages: 5102
nosy: enzo, pypy-issue
priority: critical
status: unread
title: In numpypy, the functions min() and max() are broken

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

From tracker at bugs.pypy.org  Sun Dec 23 15:56:31 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 23 Dec 2012 14:56:31 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1356274591.13.0.416595958723.issue1236@bugs.pypy.org>


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

Cannot run "pypy pypyflaskmongo.py" (linux 64-bit, with site-packages.7z):

AutoReconnect: could not connect to localhost:27017: [Errno 111] ECONNREFUSED

Full traceback at http://bpaste.net/show/66137/ .  Can you tell me what I'm
missing?  Thanks!

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

From tracker at bugs.pypy.org  Tue Dec 25 13:24:37 2012
From: tracker at bugs.pypy.org (Ram Rachum)
Date: Tue, 25 Dec 2012 12:24:37 +0000
Subject: [pypy-issue] [issue1353] Weakrefs to builtin types sometimes don't
	work
In-Reply-To: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>
Message-ID: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>


New submission from Ram Rachum <ram at rachum.com>:

See the attached file. When run in Python, it runs fine. When run in Pypy 2.0b, 
an AssertionError is raised.

----------
files: weakref_weirdness.py
messages: 5104
nosy: cool-RR, pypy-issue
priority: bug
release: 2.0
status: unread
title: Weakrefs to builtin types sometimes don't work

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1353>
________________________________________
-------------- next part --------------
import gc
import weakref
w=weakref.ref(list)
gc.collect(); gc.collect(); gc.collect()
assert w() == list

From tracker at bugs.pypy.org  Wed Dec 26 23:15:52 2012
From: tracker at bugs.pypy.org (Sean Gallagher)
Date: Wed, 26 Dec 2012 22:15:52 +0000
Subject: [pypy-issue] [issue1353] Weakrefs to builtin types sometimes don't
	work
In-Reply-To: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>
Message-ID: <1356560152.15.0.0139054325006.issue1353@bugs.pypy.org>


Sean Gallagher <stgallag at gmail.com> added the comment:

It first shows up in revision 58653:66ca6d9f3739 
(https://bitbucket.org/pypy/pypy/commits/66ca6d9f3739c6e1a12521a7dc49de1bbb5f6d7a
)
It seems to have to do with an optimization of __new__ on type objects (in 
pypy/objspace/std/typeobject.py)

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

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

From tracker at bugs.pypy.org  Thu Dec 27 21:56:23 2012
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Thu, 27 Dec 2012 20:56:23 +0000
Subject: [pypy-issue] [issue1354] from_buffer is not supported in ctypes
In-Reply-To: <1356641783.97.0.689108170418.issue1354@bugs.pypy.org>
Message-ID: <1356641783.97.0.689108170418.issue1354@bugs.pypy.org>


New submission from Simon Sapin <simon.sapin at kozea.fr>:

Hi. The following code gives a c_char on CPython but raises on PyPy 2.0.0-beta1:

>>>> import ctypes
>>>> array = bytearray(10)
>>>> ctypes.c_char.from_buffer(array)
AttributeError: type object 'c_char' has no attribute 'from_buffer'

Apparently from_buffer and from_buffer_copy are not implemented yet.

----------
messages: 5106
nosy: SimonSapin, pypy-issue
priority: bug
status: unread
title: from_buffer is not supported in ctypes

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

From tracker at bugs.pypy.org  Fri Dec 28 18:03:30 2012
From: tracker at bugs.pypy.org (Mark Dickinson)
Date: Fri, 28 Dec 2012 17:03:30 +0000
Subject: [pypy-issue] [issue1355] Difference from CPython when extending a
	list with an	iterable that depends on that list.
In-Reply-To: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>
Message-ID: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Taken from http://bugs.python.org/issue16791.

In CPython:

Python 2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "credits", "demo" or "enthought" for more information.
>>> b = [1]
>>> b += (x+1 for x in b if x < 5)
>>> b
[1, 2, 3, 4, 5]

In PyPy (version 1.9 from MacPorts):

Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:15)
[PyPy 1.9.0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``'that's definitely a case of
"uh????"'''
>>>> b = [1]
>>>> b += (x+1 for x in b if x < 5)
>>>> b
[1, 2]

----------
messages: 5107
nosy: mark.dickinson, pypy-issue
priority: bug
release: 1.9
status: unread
title: Difference from CPython when extending a list with an iterable that depends on that list.

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

From tracker at bugs.pypy.org  Fri Dec 28 18:20:28 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 28 Dec 2012 17:20:28 +0000
Subject: [pypy-issue] [issue1355] Difference from CPython when extending a
	list with an	iterable that depends on that list.
In-Reply-To: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>
Message-ID: <1356715228.88.0.739261069861.issue1355@bugs.pypy.org>


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

This occurs because CPython does the equivilant of `list` on the argument to `+=`, 
while PyPy merely attempts to iterate over it. It's not obvious to me why 
CPython's behavior is more correct, or more in line with the documentation. With 
that said it's an obvious compatibility difference, perhaps CPython should be 
changed ;)

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

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

From tracker at bugs.pypy.org  Fri Dec 28 19:10:49 2012
From: tracker at bugs.pypy.org (Mark Dickinson)
Date: Fri, 28 Dec 2012 18:10:49 +0000
Subject: [pypy-issue] [issue1355] Difference from CPython when extending a
	list with an	iterable that depends on that list.
In-Reply-To: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>
Message-ID: <1356718249.67.0.291913081515.issue1355@bugs.pypy.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This occurs because CPython does the equivilant of `list`

Did you mean this the other way around?  It looks to me as though CPython is being 
lazier than PyPy.

> It's not obvious to me why CPython's behavior is more correct.

Agreed that it's not obvious; it might be worth bringing up on the python-dev 
mailing list.

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

From tracker at bugs.pypy.org  Fri Dec 28 19:21:56 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 28 Dec 2012 18:21:56 +0000
Subject: [pypy-issue] [issue1355] Difference from CPython when extending a
	list with an	iterable that depends on that list.
In-Reply-To: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>
Message-ID: <1356718916.59.0.871973927479.issue1355@bugs.pypy.org>


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

Bah, no you're completely right, we're the ones calling list, this should be 
changed (it even looks like it's been changed on `default`). I'm pretty sure there 
are other places where the reverse is true. :/

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

From tracker at bugs.pypy.org  Fri Dec 28 20:59:43 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Fri, 28 Dec 2012 19:59:43 +0000
Subject: [pypy-issue] [issue1355] Difference from CPython when extending a
	list with an	iterable that depends on that list.
In-Reply-To: <1356714210.09.0.696920330543.issue1355@bugs.pypy.org>
Message-ID: <1356724783.0.0.646147496411.issue1355@bugs.pypy.org>


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

This is a duplicate of #1240. It's already been fixed for PyPy 2.0 (as part of the 
length-hint branch work). PyPy 2.0 will also now match CPython's behavior in 
http://bugs.python.org/issue16791

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

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

From tracker at bugs.pypy.org  Sat Dec 29 07:11:08 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sat, 29 Dec 2012 06:11:08 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1356761468.28.0.118885102606.issue1236@bugs.pypy.org>


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

Hi, you need to install a mongodb on local machine. Any version is okay, just
using default settings. It will startup, do some init, and open port 27017 for
incoming connections.

So sorry not receiving mail for last your reply.

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

From tracker at bugs.pypy.org  Sat Dec 29 07:19:34 2012
From: tracker at bugs.pypy.org (bloodmage)
Date: Sat, 29 Dec 2012 06:19:34 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1356761974.67.0.741481177849.issue1236@bugs.pypy.org>


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

A simple way to install mongodb on Ubuntu:

sudo apt-get install mongodb

It should install a stable mongodb and run it as a service.

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

From tracker at bugs.pypy.org  Sat Dec 29 14:25:44 2012
From: tracker at bugs.pypy.org (Sean Gallagher)
Date: Sat, 29 Dec 2012 13:25:44 +0000
Subject: [pypy-issue] [issue1338] Epoll object cannot be closed twice
In-Reply-To: <1353772932.73.0.836119568946.issue1338@bugs.pypy.org>
Message-ID: <1356787544.69.0.608376180255.issue1338@bugs.pypy.org>


Sean Gallagher <stgallag at gmail.com> added the comment:

Fixed in revision 9e389d3

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

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

From tracker at bugs.pypy.org  Sun Dec 30 00:06:41 2012
From: tracker at bugs.pypy.org (Sean Gallagher)
Date: Sat, 29 Dec 2012 23:06:41 +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: <1356822401.44.0.760260376519.issue1314@bugs.pypy.org>


Sean Gallagher <stgallag at gmail.com> added the comment:

Fix with test

----------
nosy: +SeanTater

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

From tracker at bugs.pypy.org  Mon Dec 31 23:16:21 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Mon, 31 Dec 2012 22:16:21 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>


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

import ctypes
ctypes.cast('\x01\x02\x03\x04', ctypes.POINTER(ctypes.c_char))

The actual use-case for this is a (dirty) attempt at reversing byte order 2-by-2 in a stream when 
on a little endian host:
ctypes.cast('\x01\x02\x03\x04', ctypes.POINTER(ctypes.c_ushort))
The idea is to be faster than repeatedly calling struct.unpack('>H', read(2)).

----------
messages: 5116
nosy: pypy-issue, vpelletier
priority: bug
release: 2.0
status: unread
title: Casting a str into a ctype pointer fails

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

From tracker at bugs.pypy.org  Mon Dec 31 23:19:34 2012
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Mon, 31 Dec 2012 22:19:34 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1356992374.5.0.821699666834.issue1356@bugs.pypy.org>


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

Tested on releases: 1.9 and 2.0beta1
Traceback with 2.0beta1:
  Traceback (most recent call last):
    File "<console>", line 1, in <module>
    File "/home/vincent/git/ITI1480A-linux/pypy-2.0-beta1/lib-python/2.7/ctypes/__init__.py", line 510, in cast
      return _cast_addr(obj, obj, typ)
    File "/home/vincent/git/ITI1480A-linux/pypy-2.0-beta1/lib_pypy/_ctypes/pointer.py", line 146, in _cast_addr
      % (type(obj),))

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

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