From tracker at bugs.pypy.org  Thu May  1 13:43:23 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 01 May 2014 11:43:23 +0000
Subject: [pypy-issue] [issue1328] unbreak cProfile jitting
In-Reply-To: <1353277066.05.0.0979170791847.issue1328@bugs.pypy.org>
Message-ID: <1398944603.08.0.174392713226.issue1328@bugs.pypy.org>


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

Seems to be resolved after some checkings ending in 75f2886305e0.

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

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

From tracker at bugs.pypy.org  Fri May  2 08:13:12 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Fri, 02 May 2014 06:13:12 +0000
Subject: [pypy-issue] [issue1430] gethostbyname_ex should use thread-safe
	functions rather	than locks
In-Reply-To: <1363953443.4.0.713767024147.issue1430@bugs.pypy.org>
Message-ID: <1399011192.89.0.523444662392.issue1430@bugs.pypy.org>


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

corruption fixed with merge of issue1430 branch in commit 9fe91ecfce83

leaving this open at a lower priority as we probably want to use the thread-safe 
versions of gethostxxx instead of using locks, when possible.

----------
priority: critical -> performance bug
release: 2.0 -> 
title: Memory corruption on socket.gethostbyname_ex -> gethostbyname_ex should use thread-safe functions rather than locks

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

From tracker at bugs.pypy.org  Sun May  4 16:37:32 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Sun, 04 May 2014 14:37:32 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>


New submission from Stefano Rivera <pypy at rivera.za.net>:

It's been broken for a while (possibly the whole 2.x series), because there
isn't a buildbot build for it. But no bug filed.

Here's the failure with current HEAD (988f37762851)

[translation:info] Error:
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/translator/goal/translate.py", line 316, in main
[translation:info]     drv.proceed(goals)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/translator/driver.py", line 531, in proceed
[translation:info]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/translator/tool/taskengine.py", line 114, in
_execute
[translation:info]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/translator/driver.py", line 276, in _do
[translation:info]     res = func()
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/translator/driver.py", line 359, in
task_pyjitpl_lltype
[translation:info]     backend_name=self.config.translation.jit_backend,
inline=True)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/jit/metainterp/warmspot.py", line 50, in apply_jit
[translation:info]     warmrunnerdesc.finish()
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/jit/metainterp/warmspot.py", line 243, in finish
[translation:info]     self.annhelper.finish()
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/rtyper/annlowlevel.py", line 223, in finish
[translation:info]     self.finish_rtype()
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/rtyper/annlowlevel.py", line 273, in finish_rtype
[translation:info]     rtyper.specialize_more_blocks()
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rtyper.py",
line 223, in specialize_more_blocks
[translation:info]     self.specialize_block(block)
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rtyper.py",
line 341, in specialize_block
[translation:info]     self.translate_hl_to_ll(hop, varmapping)
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rtyper.py",
line 470, in translate_hl_to_ll
[translation:info]     resultvar = hop.dispatch()
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rtyper.py",
line 699, in dispatch
[translation:info]     return translate_meth(self)
[translation:info]    File "<59406-codegen
/home/stefanor/hg/pypy/rpython/rtyper/rtyper.py:540>", line 4, in
translate_op_call_args
[translation:info]     return r_arg1.rtype_call_args(hop)
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rpbc.py", line
715, in rtype_call_args
[translation:info]     return self.redispatch_call(hop, call_args=True)
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rpbc.py", line
742, in redispatch_call
[translation:info]     hop.llops, hop)
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rclass.py",
line 467, in rtype_new_instance
[translation:info]     return rinstance.new_instance(llops, classcallhop)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/rtyper/lltypesystem/rclass.py", line 534, in
new_instance
[translation:info]     r.convert_desc_or_const(value))
[translation:info]    File "/home/stefanor/hg/pypy/rpython/rtyper/rmodel.py",
line 116, in convert_desc_or_const
[translation:info]     return self.convert_const(desc_or_const.value)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/rtyper/lltypesystem/rpbc.py", line 181, in
convert_const
[translation:info]     funcdesc = self.rtyper.annotator.bookkeeper.getdesc(value)
[translation:info]    File
"/home/stefanor/hg/pypy/rpython/annotator/bookkeeper.py", line 393, in getdesc
[translation:info]     raise Exception("%s: %r" % (msg, pyobj))
[translation:ERROR] Exception: unexpected prebuilt constant: <staticmethod
object at 0x1110e7c0>
[translation] start debugger...

----------
messages: 6827
nosy: pypy-issue, stefanor
priority: bug
status: unread
title: --jit-backend=x86-without-sse2 is broken

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

From tracker at bugs.pypy.org  Mon May  5 09:33:50 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 07:33:50 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399275230.3.0.455772207846.issue1751@bugs.pypy.org>


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

Should we fix this or delete the option "--jit-backend=x86-without-sse2"? 
Without a buildbot we're bound to regularly reintroduce failures.  Is there
really a use case left?  Non-SSE2 CPUs are at least ten years old by now.

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

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

From tracker at bugs.pypy.org  Mon May  5 11:46:45 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 09:46:45 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399283205.54.0.831055468246.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

I would quite like this to work (and could host a buildbot if necessary).
Debian's i386 port targets the 486 architecture, so I'm violating policy, and
risking issues like https://bugs.debian.org/737018 by requiring SSE2 (and CMOV).

That said, I've only had one report of a user trying to use PyPy without SSE2,
so there probably aren't that many affected users.

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

From tracker at bugs.pypy.org  Mon May  5 12:23:41 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 10:23:41 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399285421.02.0.678021698713.issue1751@bugs.pypy.org>


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

It's unclear that we want to suffer having to think about non-SSE2 32-bit
machines now, when we have more or less moved toward optimizing code for 64-bit
first anyway.  Would it be good enough if pypy complained clearly when we start
it on a non-SSE2 machine?

Also note the command line on x86 Linux, which can be put in installation scripts:

if grep -q -w sse2 /proc/cpuinfo ; then echo "we have sse2"; fi

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

From tracker at bugs.pypy.org  Mon May  5 12:40:39 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 10:40:39 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399286439.19.0.742732392489.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

> Would it be good enough if pypy complained clearly when we start it on a
non-SSE2 machine?

I seem to remember you doing something to do that, a couple of years ago. hg log
turns up e2ced9ddf804. I seem to remember it working, but it doesn't any more.

Anyway, my problem is that the PyPy package uses PyPy to byte-compile on
installation, and clean up byte-compiled files on uninstallation. So, displaying
an error doesn't really help anything. I've worked around that by making pypy
fail to install on i386 Debian, and not fail to uninstall.

http://anonscm.debian.org/gitweb/?p=collab-maint/pypy.git;a=commitdiff;h=39248e94efd1b95cd2f6421086ad79e0c72dd885

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

From tracker at bugs.pypy.org  Mon May  5 12:49:51 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 10:49:51 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399286991.25.0.641388206221.issue1751@bugs.pypy.org>


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

Indeed, it is supposed to work.  However, it's hard to test.  Maybe it's due to
a random piece of code that runs before the check and that uses SSE2
instructions.  We should in theory take care that every piece of C code that
executes before the check was compiled specially without enabling SSE2...

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

From tracker at bugs.pypy.org  Mon May  5 12:53:47 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 10:53:47 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399287227.32.0.865054267235.issue1751@bugs.pypy.org>


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

Random attempt to avoid SIGILL on very very old x86 machines: 3484aaa1e858

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

From tracker at bugs.pypy.org  Mon May  5 12:55:23 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 10:55:23 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399287323.3.0.590209670062.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

One can test with qemu-system-i386 -cpu pentium2

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

From tracker at bugs.pypy.org  Mon May  5 13:08:27 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 11:08:27 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399288107.0.0.247280830989.issue1751@bugs.pypy.org>


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

Can you point to a page that explains exactly how?  What to install, how to run
without opening a new X window, etc...  Ideally I'd like to add a test that runs
on x86-32 buildbots that have qemu installed, checking that starting the
just-compiled pypy on a pentium2 cpu gives the nice error message rather than a
SIGILL.  I don't know how to do that with qemu, but I'm sure it's not complicated.

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

From tracker at bugs.pypy.org  Mon May  5 14:00:16 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 12:00:16 +0000
Subject: [pypy-issue] [issue1747] PyPy getting gradually slower on Richards
	Benchmark with	every iteration
In-Reply-To: <1398782202.95.0.61548974058.issue1747@bugs.pypy.org>
Message-ID: <1399291216.9.0.390783454445.issue1747@bugs.pypy.org>


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

This is actually a problem in the richards benchmark itself, which doesn't
correctly reset the state between each iteration.  Fixed in c1d1f4dd5f5f.  I
only changed rpython/translator/goal/richards.py, which is not (I believe) the
one run on the nightly benchmarks; the latter should not be modified.

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

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

From tracker at bugs.pypy.org  Mon May  5 14:47:59 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 12:47:59 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399294079.0.0.0270971510195.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Because it's dynamically linked, there's no way to run the binary directly with
qemu. You need to copy the binary into a VM, and run it there.

https://wiki.debian.org/QEMU#Usage

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

From tracker at bugs.pypy.org  Mon May  5 15:03:39 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 13:03:39 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399295019.07.0.988252476971.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

BTW, I built 3484aaa1e858, and it still dies on SIGILL before saying anything.

Program received signal SIGILL, Illegal instruction.
0x08c97d9b in pypy_g_IncrementalMiniMarkGC_allocate_nursery ()

(gdb) bt
#0  0x08c97d9b in pypy_g_IncrementalMiniMarkGC_allocate_nursery ()
#1  0x08c99ca8 in pypy_g_IncrementalMiniMarkGC_setup ()
#2  0x08ca2720 in pypy_g_frameworkgc_setup ()
#3  0x08057438 in RPython_StartupCode ()
#4  0x08e8c7cc in pypy_main_function ()
#5  0x0805733b in main ()

(gdb) disas
Dump of assembler code for function pypy_g_IncrementalMiniMarkGC_allocate_nursery:
   0x08c97d40 <+0>:     push   %edi
   0x08c97d41 <+1>:     push   %esi
   0x08c97d42 <+2>:     push   %ebx
   0x08c97d43 <+3>:     sub    $0x10,%esp
   0x08c97d46 <+6>:     mov    0x20(%esp),%ebx
   0x08c97d4a <+10>:    movl   $0x8f49259,(%esp)
   0x08c97d51 <+17>:    call   0x8e8d180 <pypy_debug_start>
   0x08c97d56 <+22>:    testb  $0x1,0x9e48a50
   0x08c97d5d <+29>:    mov    0xe4(%ebx),%edi
   0x08c97d63 <+35>:    jne    0x8c97e70
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+304>
   0x08c97d69 <+41>:    add    $0x10800,%edi
   0x08c97d6f <+47>:    mov    %edi,(%esp)
   0x08c97d72 <+50>:    call   0x8055cd0 <malloc at plt>
   0x08c97d79 <+57>:    test   %eax,%eax
   0x08c97d7b <+59>:    je     0x8c97e28
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+232>
   0x08c97d81 <+65>:    mov    %edi,0x8(%esp)
   0x08c97d85 <+69>:    movl   $0x0,0x4(%esp)
   0x08c97d8d <+77>:    mov    %eax,(%esp)
   0x08c97d90 <+80>:    call   0x8055a80 <memset at plt>
   0x08c97d95 <+85>:    mov    0xe4(%ebx),%eax
=> 0x08c97d9b <+91>:    movsd  0x24(%ebx),%xmm1
   0x08c97da0 <+96>:    mov    %esi,0xd0(%ebx)
   0x08c97da6 <+102>:   xorpd  %xmm2,%xmm2
   0x08c97daa <+106>:   mov    %esi,0xd8(%ebx)
   0x08c97db0 <+112>:   add    %eax,%esi
   0x08c97db2 <+114>:   cvtsi2sd %eax,%xmm0
   0x08c97db6 <+118>:   mulsd  0xc(%ebx),%xmm0
   0x08c97dbb <+123>:   mov    %esi,0xec(%ebx)
   0x08c97dc1 <+129>:   maxsd  %xmm0,%xmm1
   0x08c97dc5 <+133>:   movapd %xmm1,%xmm0
   0x08c97dc9 <+137>:   movsd  %xmm1,0x24(%ebx)
   0x08c97dce <+142>:   mov    %esi,0xe0(%ebx)
   0x08c97dd4 <+148>:   mulsd  0x4(%ebx),%xmm1
   0x08c97dd9 <+153>:   ucomisd %xmm1,%xmm2
   0x08c97ddd <+157>:   ja     0x8c97ea0
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+352>
   0x08c97de3 <+163>:   movapd %xmm2,%xmm1
   0x08c97de7 <+167>:   maxsd  %xmm1,%xmm0
   0x08c97deb <+171>:   movapd %xmm0,%xmm1
   0x08c97def <+175>:   movsd  0x1c(%ebx),%xmm0
   0x08c97df4 <+180>:   ucomisd %xmm2,%xmm0
   0x08c97df8 <+184>:   jbe    0x8c97eb0
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+368>
   0x08c97dfe <+190>:   minsd  %xmm1,%xmm0
   0x08c97e02 <+194>:   movsd  %xmm0,0x2c(%ebx)
   0x08c97e07 <+199>:   movsd  %xmm0,0x34(%ebx)
   0x08c97e0c <+204>:   mov    %eax,0xb0(%ebx)
   0x08c97e12 <+210>:   movl   $0x8f49259,0x20(%esp)
   0x08c97e1a <+218>:   add    $0x10,%esp
   0x08c97e1d <+221>:   pop    %ebx
   0x08c97e1e <+222>:   pop    %esi
   0x08c97e1f <+223>:   pop    %edi
   0x08c97e20 <+224>:   jmp    0x8e8d370 <pypy_debug_stop>
   0x08c97e25 <+229>:   lea    0x0(%esi),%esi
   0x08c97e28 <+232>:   movl   $0x941bf44,0x4(%esp)
   0x08c97e30 <+240>:   movl   $0x941af9c,(%esp)
   0x08c97e37 <+247>:   call   0x8e78a50 <pypy_g_RPyRaiseException>
   0x08c97e3c <+252>:   mov    0x9f09f04,%eax
   0x08c97e41 <+257>:   movl   $0x9e1e88c,0x9f0b700(,%eax,8)
   0x08c97e4c <+268>:   movl   $0x0,0x9f0b704(,%eax,8)
   0x08c97e57 <+279>:   add    $0x1,%eax
   0x08c97e5a <+282>:   and    $0x7f,%eax
   0x08c97e5d <+285>:   mov    %eax,0x9f09f04
   0x08c97e62 <+290>:   add    $0x10,%esp
   0x08c97e65 <+293>:   pop    %ebx
   0x08c97e66 <+294>:   pop    %esi
   0x08c97e67 <+295>:   pop    %edi
   0x08c97e68 <+296>:   ret
   0x08c97e69 <+297>:   lea    0x0(%esi,%eiz,1),%esi
   0x08c97e70 <+304>:   call   0x8e8cf30 <pypy_debug_ensure_opened>
   0x08c97e75 <+309>:   mov    0x9f09eb0,%eax
   0x08c97e7a <+314>:   mov    %edi,0x8(%esp)
   0x08c97e7e <+318>:   movl   $0x8f4926d,0x4(%esp)
   0x08c97e86 <+326>:   mov    %eax,(%esp)
   0x08c97e89 <+329>:   call   0x8056740 <fprintf at plt>
   0x08c97e8e <+334>:   mov    0xe4(%ebx),%edi
   0x08c97e94 <+340>:   jmp    0x8c97d69
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+41>
   0x08c97e99 <+345>:   lea    0x0(%esi,%eiz,1),%esi
   0x08c97ea0 <+352>:   addsd  %xmm2,%xmm1
   0x08c97ea4 <+356>:   jmp    0x8c97de7
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+167>
   0x08c97ea9 <+361>:   lea    0x0(%esi,%eiz,1),%esi
   0x08c97eb0 <+368>:   movapd %xmm1,%xmm0
   0x08c97eb4 <+372>:   jmp    0x8c97e02
<pypy_g_IncrementalMiniMarkGC_allocate_nursery+194>
End of assembler dump.

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

From tracker at bugs.pypy.org  Mon May  5 15:10:40 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 13:10:40 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399295440.28.0.449471703244.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

> Because it's dynamically linked, there's no way to run the binary directly with
qemu.

I'm talking crap. qemu-user-static, of course.

On an i386 machine / chroot:

$ qemu-i386-static -cpu pentium2 ./pypy-c
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction

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

From tracker at bugs.pypy.org  Mon May  5 15:11:52 2014
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Mon, 05 May 2014 13:11:52 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399295512.3.0.320444946484.issue1751@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Or qemu-user (qemu-i386), even. One only needs -static when going cross-arch.

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

From tracker at bugs.pypy.org  Mon May  5 17:06:36 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 May 2014 15:06:36 +0000
Subject: [pypy-issue] [issue1751] --jit-backend=x86-without-sse2 is broken
In-Reply-To: <1399214252.26.0.714704432898.issue1751@bugs.pypy.org>
Message-ID: <1399302396.95.0.259941382674.issue1751@bugs.pypy.org>


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

Fixed in 1034226b87f2.  This time I really checked.  It's still a mess to have a
test for it because installing qemu inside our old 32-bit chroot does not work
out of the box...

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

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

From tracker at bugs.pypy.org  Tue May  6 04:24:27 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 06 May 2014 02:24:27 +0000
Subject: [pypy-issue] [issue955] move struct.Struct to interplevel
In-Reply-To: <1323214290.38.0.724171286137.issue955@bugs.pypy.org>
Message-ID: <1399343067.16.0.687617066257.issue955@bugs.pypy.org>


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

Some of these issues were fixed a while ago, rest should be fixed with commits 
0928de0 through d93da94.

----------
nosy: +bdk
status: unread -> testing

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

From tracker at bugs.pypy.org  Tue May  6 10:23:07 2014
From: tracker at bugs.pypy.org (Pepijn de Vos)
Date: Tue, 06 May 2014 08:23:07 +0000
Subject: [pypy-issue] [issue1752] bz2.BZ2File extremely slow
In-Reply-To: <1399364587.34.0.461784115916.issue1752@bugs.pypy.org>
Message-ID: <1399364587.34.0.461784115916.issue1752@bugs.pypy.org>


New submission from Pepijn de Vos <pepijndevos at gmail.com>:

Using bz2.BZ2File is extremely slow compared to a custom implementation based on
bz2.BZ2Decompressor or either solutiion on CPython.

The 3 speedy solutions finish this big bz2 file in 6 seconds, the BZ2File on
PyPy just never finishes within a reasonable time.

I ran a profiler, which showed nothing at all.

----------
files: bz2test.py
messages: 6843
nosy: pepijndevos, pypy-issue
priority: performance bug
status: unread
title: bz2.BZ2File extremely slow

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

From tracker at bugs.pypy.org  Tue May  6 10:29:41 2014
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Tue, 06 May 2014 08:29:41 +0000
Subject: [pypy-issue] [issue1753] depressing performance on a
	cross-correlation benchmark
In-Reply-To: <1399364981.64.0.236554857829.issue1753@bugs.pypy.org>
Message-ID: <1399364981.64.0.236554857829.issue1753@bugs.pypy.org>


New submission from Yury V. Zaytsev <yury at shurup.com>:

I've posted this on pypy-dev@, but my mail didn't make it, so as mattip
suggested I'm re-posting it to the bug tracker:

Yesterday, I was able to make my simple cross-correlation script to work
with PyPy / NumPy at all with the valuable help of bdk, however, I ended
up being quite disappointed about the performance.

I stripped out everything I could and ended up with something like this:

Python 3:

$ time python corrbench.py 
0
1
2

real 0m2.225s
user 0m1.980s
sys 0m0.240s

PyPy from hg / NumPy from hg (3581f7a906c9+):

$ time python corrbench.py
0
1
2

real 1m2.928s
user 1m2.460s
sys 0m0.270s

What this script does, it basically generates two time series of ~5 000
elements and bins them into 3 000 000 buckets, which it then multiples
element-wise and sums up the result. I expected a huge performance
boost, of course :-)

I think I'll be running this with plain Python for now, but I hope
that's a valuable benchmark for you guys!

----------
messages: 6844
nosy: pypy-issue, zaytsev
priority: performance bug
status: unread
title: depressing performance on a cross-correlation benchmark

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

From tracker at bugs.pypy.org  Tue May  6 17:55:48 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 06 May 2014 15:55:48 +0000
Subject: [pypy-issue] [issue1739] file append mode
In-Reply-To: <1397893496.82.0.118636748648.issue1739@bugs.pypy.org>
Message-ID: <1399391748.02.0.761869863063.issue1739@bugs.pypy.org>


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

Tests were added in bc7d31eac294 and d63b49940eff.

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

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

From tracker at bugs.pypy.org  Tue May  6 18:27:46 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 06 May 2014 16:27:46 +0000
Subject: [pypy-issue] [issue955] inefficiency of struct.pack_into
In-Reply-To: <1323214290.38.0.724171286137.issue955@bugs.pypy.org>
Message-ID: <1399393666.72.0.506037609431.issue955@bugs.pypy.org>


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

Actually, there are is a remaining inefficiency in pack_into: PackFormatIterator 
always packs into a string and then copies into the buffer. It should be possible 
to pack into the buffer directly. Seems solving this requires modification of both 
pypy/module/struct and rpython/rlib/rstruct.

----------
status: testing -> chatting
title: move struct.Struct to interplevel -> inefficiency of struct.pack_into

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

From tracker at bugs.pypy.org  Tue May  6 18:33:14 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 06 May 2014 16:33:14 +0000
Subject: [pypy-issue] [issue1754] buffer.getslice from raw mem doesn't avoid
	string copy
In-Reply-To: <1399393994.28.0.621361397804.issue1754@bugs.pypy.org>
Message-ID: <1399393994.28.0.621361397804.issue1754@bugs.pypy.org>


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

The buffer object returned by objects using raw memory storage like array, mmap, 
etc uses charpsize2str for getslice if step == 1. This means places that use 
buf.getslice (hoping to avoid a string copy) end up with traces like this:

newstr(n)
call(copy_raw_to_string)
strgetitem(x+0)
strgetitem(x+1)
...

Ideally we should use getarrayitem_raw(x+#). If instead of using buf.getslice we 
use an unrolled loop of buf.getitem, traces do use getarrayitem_raw. So, 
something should be done about either the buffer API or JIT optimization to 
ensure common paths are optimal.

----------
messages: 6847
nosy: bdk, pypy-issue
priority: performance bug
status: unread
title: buffer.getslice from raw mem doesn't avoid string copy

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

From tracker at bugs.pypy.org  Tue May  6 21:09:13 2014
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 06 May 2014 19:09:13 +0000
Subject: [pypy-issue] [issue1753] depressing performance on a
	cross-correlation benchmark
In-Reply-To: <1399364981.64.0.236554857829.issue1753@bugs.pypy.org>
Message-ID: <1399403353.53.0.676732173116.issue1753@bugs.pypy.org>


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

There are two parts to the benchmark, the histogram function is ~30 times slower
than cpython numpy, and the xcorr function ~4 times slower.

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

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

From tracker at bugs.pypy.org  Tue May  6 23:10:50 2014
From: tracker at bugs.pypy.org (Kevin Modzelewski)
Date: Tue, 06 May 2014 21:10:50 +0000
Subject: [pypy-issue] [issue1755] sys.exc_clear() then re-"raise" raises at
	the wrong scope
In-Reply-To: <1399410650.36.0.465412727915.issue1755@bugs.pypy.org>
Message-ID: <1399410650.36.0.465412727915.issue1755@bugs.pypy.org>


New submission from Kevin Modzelewski <kmod at dropbox.com>:

Doesn't seem very important but I thought I'd report it:



import sys

try:
    raise Exception()
except:
    pass
sys.exc_clear()

try:
    raise
except TypeError:
    # Should print this line:
    print "success"



The "raise" statement throws a TypeError as expected; in PyPy, though, this 
TypeError won't trigger the except-clause that follows it, and instead 
immediately propagates to the next frame up.  This only happens if there was a 
previously-thrown exception in this frame that then got cleared with 
sys.exc_clear().

----------
messages: 6849
nosy: kmod, pypy-issue
priority: bug
status: unread
title: sys.exc_clear() then re-"raise" raises at the wrong scope

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

From tracker at bugs.pypy.org  Tue May  6 23:18:13 2014
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 06 May 2014 21:18:13 +0000
Subject: [pypy-issue] [issue1755] sys.exc_clear() then re-"raise" raises at
	the wrong scope
In-Reply-To: <1399410650.36.0.465412727915.issue1755@bugs.pypy.org>
Message-ID: <1399411093.58.0.765475313533.issue1755@bugs.pypy.org>


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

This appears to be fixed on default, I assume you were testing on the last 
release?

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

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

From tracker at bugs.pypy.org  Wed May  7 02:52:22 2014
From: tracker at bugs.pypy.org (houqp)
Date: Wed, 07 May 2014 00:52:22 +0000
Subject: [pypy-issue] [issue1756] inconsistent with CPython when writing to
	a truncated file
In-Reply-To: <1399423942.89.0.687154651998.issue1756@bugs.pypy.org>
Message-ID: <1399423942.89.0.687154651998.issue1756@bugs.pypy.org>


New submission from houqp <dave2008713+pypy.tracker at gmail.com>:

Hi PyPy dev,

I run into following inconsistent behaviour between CPython and PyPy.

This is what I got from pypy:

```
>>>> f = open('/tmp/foo', 'a+')
>>>> f.write('123')
>>>> f.truncate(0)
>>>> f.write('1')
>>>> f.close()
>>>> open('/tmp/foo', 'r').read()
'\x00\x00\x00\x001'
```

While in Python 2.6, 2.7, I got '1' instead.

----------
messages: 6851
nosy: dave2008, pypy-issue
priority: bug
status: unread
title: inconsistent with CPython when writing to a truncated file

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

From tracker at bugs.pypy.org  Wed May  7 02:57:36 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Wed, 07 May 2014 00:57:36 +0000
Subject: [pypy-issue] [issue1756] inconsistent with CPython when writing to
	a truncated file
In-Reply-To: <1399423942.89.0.687154651998.issue1756@bugs.pypy.org>
Message-ID: <1399424256.72.0.161391067169.issue1756@bugs.pypy.org>


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

You failed to include what version of PyPy you are using, a useful piece of info 
for bug reports... In any case, this was fixed a while ago, try a nightly.

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

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

From tracker at bugs.pypy.org  Wed May  7 03:00:42 2014
From: tracker at bugs.pypy.org (houqp)
Date: Wed, 07 May 2014 01:00:42 +0000
Subject: [pypy-issue] [issue1756] inconsistent with CPython when writing to
	a truncated file
In-Reply-To: <1399423942.89.0.687154651998.issue1756@bugs.pypy.org>
Message-ID: <1399424442.17.0.140113185956.issue1756@bugs.pypy.org>


houqp <dave2008713+pypy.tracker at gmail.com> added the comment:

Sorry, forgot to add that info. I tested under 2.2.1. Will try nightly now.

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

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

From tracker at bugs.pypy.org  Wed May  7 03:04:06 2014
From: tracker at bugs.pypy.org (houqp)
Date: Wed, 07 May 2014 01:04:06 +0000
Subject: [pypy-issue] [issue1756] inconsistent with CPython when writing to
	a truncated file
In-Reply-To: <1399423942.89.0.687154651998.issue1756@bugs.pypy.org>
Message-ID: <1399424646.79.0.439644924161.issue1756@bugs.pypy.org>


houqp <dave2008713+pypy.tracker at gmail.com> added the comment:

OK, confirmed that it has been fixed in 2.3.0-alpha0. Thank you :)

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

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

From tracker at bugs.pypy.org  Thu May  8 16:38:05 2014
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 08 May 2014 14:38:05 +0000
Subject: [pypy-issue] [issue662] sysconfig.get_config_vars() has no value
	for CC
In-Reply-To: <1299432839.34.0.219138682981.issue662@>
Message-ID: <1399559885.96.0.987078247947.issue662@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

indeed, the top-level sysconfig.get_config_vars() still does not return a value
for CC, so that still needs to be fixed.

----------
nosy: +cfbolz
status: testing -> chatting
title: [PATCH] functional distutils for installing C extensions -> sysconfig.get_config_vars() has no value for CC

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

From tracker at bugs.pypy.org  Thu May  8 16:43:21 2014
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 08 May 2014 14:43:21 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1399560201.61.0.384818281855.issue1534@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

smbus-cffi is listed here: https://bitbucket.org/pypy/compatibility/wiki/Home

closing the issue

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

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

From tracker at bugs.pypy.org  Thu May  8 16:44:09 2014
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 08 May 2014 14:44:09 +0000
Subject: [pypy-issue] [issue1128] add the possibility to search on the
	release field on	roundup
In-Reply-To: <1334341487.64.0.694725686163.issue1128@bugs.pypy.org>
Message-ID: <1399560249.65.0.363478791272.issue1128@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

closing as wontfix, we'll move to a different tracker soon anyway.

----------
nosy: +cfbolz -antocuni
status: testing -> wontfix

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

From tracker at bugs.pypy.org  Thu May  8 17:39:42 2014
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Thu, 08 May 2014 15:39:42 +0000
Subject: [pypy-issue] [issue1757] test_ioctl_signed_unsigned_code_param
	fails on OS/X
In-Reply-To: <1399563582.19.0.614514060744.issue1757@bugs.pypy.org>
Message-ID: <1399563582.19.0.614514060744.issue1757@bugs.pypy.org>


New submission from kostia.lopuhin <kostia.lopuhin at gmail.com>:

The following test from lib-python tests fails on pypy (2.1, 2.2.1, 2.3.x rc) on OS/X 
and passes under CPython (it is skipped on the buildbot)

lib-python/2.7/test/test_ioctl.py

test_ioctl (__main__.IoctlTests) ... ok
test_ioctl_mutate (__main__.IoctlTests) ... ok
test_ioctl_mutate_1024 (__main__.IoctlTests) ... ok
test_ioctl_mutate_2048 (__main__.IoctlTests) ... ok
test_ioctl_signed_unsigned_code_param (__main__.IoctlTests) ... ERROR

======================================================================
ERROR: test_ioctl_signed_unsigned_code_param (__main__.IoctlTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/kostia/programming/pypy/lib-python/2.7/test/test_ioctl.py", line 83, 
in test_ioctl_signed_unsigned_code_param
    new_winsz = fcntl.ioctl(mfd, set_winsz_opcode_pos, our_winsz)
IOError: [Errno 25] Inappropriate ioctl for device

----------------------------------------------------------------------
Ran 5 tests in 0.007s

FAILED (errors=1)
Traceback (most recent call last):
  File "app_main.py", line 72, in run_toplevel
  File "/Users/kostia/programming/pypy/lib-python/2.7/test/test_ioctl.py", line 93, 
in <module>
    test_main()
  File "/Users/kostia/programming/pypy/lib-python/2.7/test/test_ioctl.py", line 90, 
in test_main
    run_unittest(IoctlTests)
  File "/Users/kostia/opt/pypy-2.0/lib-python/2.7/test/test_support.py", line 1144, 
in run_unittest
    _run_suite(suite)
  File "/Users/kostia/opt/pypy-2.0/lib-python/2.7/test/test_support.py", line 1098, 
in _run_suite
    raise TestFailed(err)
TestFailed: Traceback (most recent call last):
  File "/Users/kostia/programming/pypy/lib-python/2.7/test/test_ioctl.py", line 83, 
in test_ioctl_signed_unsigned_code_param
    new_winsz = fcntl.ioctl(mfd, set_winsz_opcode_pos, our_winsz)
IOError: [Errno 25] Inappropriate ioctl for device

It does not affect me, just noticed while running all lib-python tests

----------
messages: 6858
nosy: kostia.lopuhin, pypy-issue
priority: bug
release: 2.3
status: unread
title: test_ioctl_signed_unsigned_code_param fails on OS/X

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

From tracker at bugs.pypy.org  Thu May  8 18:31:30 2014
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Thu, 08 May 2014 16:31:30 +0000
Subject: [pypy-issue] [issue1757] test_ioctl_signed_unsigned_code_param
	fails on OS/X
In-Reply-To: <1399563582.19.0.614514060744.issue1757@bugs.pypy.org>
Message-ID: <1399566690.22.0.503340895295.issue1757@bugs.pypy.org>


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

fixed in d03659ab55ea

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

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

From tracker at bugs.pypy.org  Fri May  9 11:20:20 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:20:20 +0000
Subject: [pypy-issue] [issue1248] please build with older GNU libc on
	Linux/amd64
In-Reply-To: <1346476259.72.0.54490436525.issue1248@bugs.pypy.org>
Message-ID: <1399627220.06.0.820300258344.issue1248@bugs.pypy.org>


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

done by squeaky's builds, should we build one like this nightly?

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Fri May  9 11:22:23 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:22:23 +0000
Subject: [pypy-issue] [issue1515] buildbot failure: tk
In-Reply-To: <1371370234.0.0.866803698299.issue1515@bugs.pypy.org>
Message-ID: <1399627343.54.0.517768415339.issue1515@bugs.pypy.org>


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

is this still relevant?

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Fri May  9 11:27:13 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:27:13 +0000
Subject: [pypy-issue] [issue1723] test runner filling temp directory with
	_testcapi modules
In-Reply-To: <1395909505.08.0.09145133023.issue1723@bugs.pypy.org>
Message-ID: <1399627633.81.0.627891137173.issue1723@bugs.pypy.org>


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

need to set TMPDIR both on 'translation' (so we can save the last X build 
directories, maybe even zip and upload them?) and 'test' steps of buildbots, then 
add a step to clean TMPDIR once testing is complete

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

From tracker at bugs.pypy.org  Fri May  9 11:31:32 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:31:32 +0000
Subject: [pypy-issue] [issue644] Add option parser to package.py
In-Reply-To: <1298596167.56.0.337983976343.issue644@>
Message-ID: <1399627892.41.0.146113498111.issue644@bugs.pypy.org>


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

in transision, maybe we could do somethin like
1 - update buildbot step to test package.py version with
    package.py --version
    detect failure and go back to old behaviour
2 - update package.py
3 - update buildbot to use new interface

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Fri May  9 11:34:51 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:34:51 +0000
Subject: [pypy-issue] [issue1254] meta-bug for post-stdlib-2.7.3 win32
	breakage
In-Reply-To: <1347093369.93.0.363725480893.issue1254@bugs.pypy.org>
Message-ID: <1399628091.0.0.288984719249.issue1254@bugs.pypy.org>


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

windows builds now complete, own tests too.

----------
status: in-progress -> resolved

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

From tracker at bugs.pypy.org  Fri May  9 11:37:12 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:37:12 +0000
Subject: [pypy-issue] [issue1758] bbot2 hook does not recognize git
In-Reply-To: <1399628232.47.0.80959615154.issue1758@bugs.pypy.org>
Message-ID: <1399628232.47.0.80959615154.issue1758@bugs.pypy.org>


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

we can register repositories to be monitored by the build master, and commits to 
those repos are reported to mailing lists and IRC. Since the hook does not speak 
git, it cannot monitor bitbucket/pypy/numpy.git

----------
messages: 6865
nosy: mattip, pypy-issue
priority: feature
status: unread
title: bbot2 hook does not recognize git

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

From tracker at bugs.pypy.org  Fri May  9 11:38:23 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 09:38:23 +0000
Subject: [pypy-issue] [issue1759] buildbot meta-tasks
In-Reply-To: <1399628303.61.0.249759112785.issue1759@bugs.pypy.org>
Message-ID: <1399628303.61.0.249759112785.issue1759@bugs.pypy.org>


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

A collection of proposals to fix in the next iteration of buildbot improvements
Please vote for the ones you like
https://bugs.pypy.org/issue1723
test runner filling temp directory with _testcapi modules
Votes: +1

https://bugs.pypy.org/issue644
Add option parser to package.py
Votes: +1

https://bugs.pypy.org/issue1758
bbot2 hook does not recognize git
Votes: +1


https://bugs.pypy.org/issue1015 
Add build to run the benchmarks with python 2.7 tip
Votes: 0 

https://bugs.pypy.org/issue1310
OpenIndiana (Solaris derivative) buildbot available
Votes: -1

----------
messages: 6866
nosy: mattip, pypy-issue
priority: feature
status: chatting
title: buildbot meta-tasks

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

From tracker at bugs.pypy.org  Fri May  9 13:25:32 2014
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 09 May 2014 11:25:32 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1399634732.74.0.45434892784.issue1259@bugs.pypy.org>


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

Is there a reason to keep the __file__ attribute at all?

Then help(sys) would need to print, like cpython
>>> help(sys)
Help on built-in module sys:

NAME
    sys

FILE
    (built-in)

MODULE DOCS
    http://docs.python.org/library/sys
...

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Fri May  9 16:22:15 2014
From: tracker at bugs.pypy.org (David Griffin)
Date: Fri, 09 May 2014 14:22:15 +0000
Subject: [pypy-issue] [issue1736] Multiple Pyglet bugs
In-Reply-To: <1397562770.79.0.312926037693.issue1736@bugs.pypy.org>
Message-ID: <1399645335.73.0.318109886276.issue1736@bugs.pypy.org>


David Griffin <habilain at gmail.com> added the comment:

Adding a note to confirm that these problems all still exist with PyPy 2.3

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

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

From tracker at bugs.pypy.org  Fri May  9 18:39:41 2014
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Fri, 09 May 2014 16:39:41 +0000
Subject: [pypy-issue] [issue1723] test runner filling temp directory with
	_testcapi modules
In-Reply-To: <1395909505.08.0.09145133023.issue1723@bugs.pypy.org>
Message-ID: <1399653581.87.0.595348559101.issue1723@bugs.pypy.org>


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

mattip, any idea why py3k 32 bit runs into an issue of the _testcapi so 
apparently clashing w/ the 64 bit one, whereas default does not? Or maybe 
something else is going on

http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy-c-
app-level-linux-x86-32&build=2614&mod=lib-python.3.test.test___all__

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

From tracker at bugs.pypy.org  Fri May  9 21:45:20 2014
From: tracker at bugs.pypy.org (Kevin Duffy)
Date: Fri, 09 May 2014 19:45:20 +0000
Subject: [pypy-issue] [issue1760] Darwin platform doesn't use CFLAGS/LDFLAGS
In-Reply-To: <1399664720.2.0.702384259527.issue1760@bugs.pypy.org>
Message-ID: <1399664720.2.0.702384259527.issue1760@bugs.pypy.org>


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

In 2.3, rpython/translator/platform/darwin.py, the cflags and ldflags variables don't 
take into 
account the environmental CFLAGS/LDFLAGS vars. The linux platform does though:
   link_flags = tuple(
                 ['-pthread',]
                 + os.environ.get('LDFLAGS', '').split())
    extra_libs = ('-lrt',)
    cflags = tuple(
             ['-O3', '-pthread', '-fomit-frame-pointer',
              '-Wall', '-Wno-unused']
             + os.environ.get('CFLAGS', '').split())

This should also be done for darwin so custom cflags and libraries can be used when 
building our 
own pypy.

----------
messages: 6870
nosy: duffy151, pypy-issue
priority: bug
release: 2.3
status: unread
title: Darwin platform doesn't use CFLAGS/LDFLAGS

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

From tracker at bugs.pypy.org  Fri May  9 22:19:13 2014
From: tracker at bugs.pypy.org (Kevin Turner)
Date: Fri, 09 May 2014 20:19:13 +0000
Subject: [pypy-issue] [issue1761] bad link to whats-new in release-2.3.0 docs
In-Reply-To: <1399666753.1.0.161711416092.issue1761@bugs.pypy.org>
Message-ID: <1399666753.1.0.161711416092.issue1761@bugs.pypy.org>


New submission from Kevin Turner <kevinperson at topicbox.com>:

http://doc.pypy.org/en/latest/release-2.3.0.html#bugfixes contains an href 
attribute with a leading ":", the browser interprets it as a relative link and 
tries to load 
http://doc.pypy.org/en/latest/:http://doc.pypy.org/en/latest/whatsnew-2.3.0.html

----------
messages: 6871
nosy: keturn, pypy-issue
priority: bug
release: 2.3
status: unread
title: bad link to whats-new in release-2.3.0 docs

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

From tracker at bugs.pypy.org  Fri May  9 22:21:29 2014
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 09 May 2014 20:21:29 +0000
Subject: [pypy-issue] [issue1761] bad link to whats-new in release-2.3.0 docs
In-Reply-To: <1399666753.1.0.161711416092.issue1761@bugs.pypy.org>
Message-ID: <1399666889.88.0.243888020779.issue1761@bugs.pypy.org>


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

269e37a5f339 contains teh fix for this. Thanks for reporting it!

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

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

From tracker at bugs.pypy.org  Sat May 10 06:04:17 2014
From: tracker at bugs.pypy.org (ita)
Date: Sat, 10 May 2014 04:04:17 +0000
Subject: [pypy-issue] [issue1762] Pypy 2.3 encoding validation
In-Reply-To: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>
Message-ID: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>


New submission from ita <tnagy1024 at gmail.com>:

Pypy 2.3 cannot execute valid iso8859-1 files anymore:

Traceback (most recent call last):
  File "app_main.py", line 75, in run_toplevel
TypeError: compile() expected string without null bytes

Pypy 2.2.1 and earlier versions have no such problem for executing the file,
this is a regression.

----------
files: waf-1.8.0-pre1
messages: 6873
nosy: ita, pypy-issue
priority: bug
release: 2.3
status: unread
title: Pypy 2.3 encoding validation

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

From tracker at bugs.pypy.org  Sat May 10 06:15:10 2014
From: tracker at bugs.pypy.org (ita)
Date: Sat, 10 May 2014 04:15:10 +0000
Subject: [pypy-issue] [issue1762] Pypy 2.3 encoding validation
In-Reply-To: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>
Message-ID: <1399695310.43.0.433713912649.issue1762@bugs.pypy.org>


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

(cPython and jython do not reject null bytes either)

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

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

From tracker at bugs.pypy.org  Sat May 10 17:39:55 2014
From: tracker at bugs.pypy.org (Yichao Yu)
Date: Sat, 10 May 2014 15:39:55 +0000
Subject: [pypy-issue] [issue1763] Not using proper c++ compilers/linker
	while compiling c++	code.
In-Reply-To: <1399736395.13.0.564056072111.issue1763@bugs.pypy.org>
Message-ID: <1399736395.13.0.564056072111.issue1763@bugs.pypy.org>


New submission from Yichao Yu <yyc1992 at gmail.com>:

See https://github.com/pyopencl/pyopencl/issues/35

When compiling cpp code, pypy uses the c compiler (`cc` in this case) to link
the binary and therefore is not linked to appropriate c++ runtime libraries. It
also seems that it is passing a c/obj-c only compiler option (`-Wimplicit`) when
compiling c++ code as well, resulting in some compiler warnings.

----------
messages: 6875
nosy: pypy-issue, yuyichao
priority: bug
status: unread
title: Not using proper c++ compilers/linker while compiling c++ code.

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

From tracker at bugs.pypy.org  Sat May 10 21:21:22 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 May 2014 19:21:22 +0000
Subject: [pypy-issue] [issue1762] Pypy 2.3 encoding validation
In-Reply-To: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>
Message-ID: <1399749682.63.0.398594316463.issue1762@bugs.pypy.org>


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

Note that a similar issue was closed as invalid about comment lines that contain
null bytes, which CPython handles highly inconsistently.

This issue here is arguably more important, although I'm unsure how including
binary data in a .py file with a specific encoding is supposed to work.  I guess
it works just because, by chance, the iso8859-1 encoding accepts any character
sequence.  If you replaced "iso8859-1" with, say, "utf8", then the example gives
a SyntaxError on CPython and all versions of PyPy.

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

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

From tracker at bugs.pypy.org  Sat May 10 21:39:55 2014
From: tracker at bugs.pypy.org (ita)
Date: Sat, 10 May 2014 19:39:55 +0000
Subject: [pypy-issue] [issue1762] Pypy 2.3 encoding validation
In-Reply-To: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>
Message-ID: <1399750795.85.0.498261568825.issue1762@bugs.pypy.org>


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

Which issue are you talking about exactly? This one?
http://bugs.python.org/issue20115

The script does not run on Pypy 2.3 but it runs on Python 2.7.

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

From tracker at bugs.pypy.org  Sat May 10 21:48:35 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 May 2014 19:48:35 +0000
Subject: [pypy-issue] [issue1762] Pypy 2.3 encoding validation
In-Reply-To: <1399694657.47.0.854349663128.issue1762@bugs.pypy.org>
Message-ID: <1399751315.54.0.247791868231.issue1762@bugs.pypy.org>


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

Yes, that's it.

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

From tracker at bugs.pypy.org  Sun May 11 21:43:05 2014
From: tracker at bugs.pypy.org (Sven-Hendrik Haase)
Date: Sun, 11 May 2014 19:43:05 +0000
Subject: [pypy-issue] [issue1764] pypy 2.3 doesn't translate with gcc 4.9 on
	x86_64
In-Reply-To: <1399837385.35.0.941749529105.issue1764@bugs.pypy.org>
Message-ID: <1399837385.35.0.941749529105.issue1764@bugs.pypy.org>


New submission from Sven-Hendrik Haase <sh at lutzhaase.com>:

Upon trying to translate pypy 2.3 with gcc 4.9 I get this:

[translation:ERROR]     Traceback (most recent call last):
[translation:ERROR]       File "app_main.py", line 72, in run_toplevel
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/trackgcroot.py", line 2074, 
in 
<module>
[translation:ERROR]         tracker.process(f, g, filename=fn)
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/trackgcroot.py", line 1967, 
in 
process
[translation:ERROR]         tracker = parser.process_function(lines, filename)
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/trackgcroot.py", line 1482, 
in 
process_function
[translation:ERROR]         table = tracker.computegcmaptable(self.verbose)
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/trackgcroot.py", line 59, in 
computegcmaptable
[translation:ERROR]         self.findframesize()
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/trackgcroot.py", line 295, in 
findframesize
[translation:ERROR]         insn1.framesize = size_at_insn1
[translation:ERROR]       File 
"/home/svenstaro/src/pypy/rpython/translator/c/gcc/../../../../rpython/translato
r
/c/gcc/instruction.py", line 259, in __setattr__
[translation:ERROR]         "unrecognized function prologue - "
[translation:ERROR]     AssertionError: unrecognized function prologue - only 
supports push %ebp; movl %esp, %ebp
[translation:ERROR]     make: *** [getargs.gcmap] Error 1
[translation:ERROR]     make: *** Waiting for unfinished jobs....
[translation:ERROR]     """)
[translation] start debugger...
> 
/home/svenstaro/src/pypy/rpython/translator/platform/__init__.py(151)_handle_err
o
r()
-> raise CompilationError(stdout, stderr)

It works on i686, though I didn't test its function on i686, only that is 
translates.

----------
messages: 6879
nosy: pypy-issue, svenstaro
priority: critical
release: 2.3
status: unread
title: pypy 2.3 doesn't translate with gcc 4.9 on x86_64

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

From tracker at bugs.pypy.org  Sun May 11 23:08:48 2014
From: tracker at bugs.pypy.org (Ram Rachum)
Date: Sun, 11 May 2014 21:08:48 +0000
Subject: [pypy-issue] [issue1765] __len__ can't return big numbers
In-Reply-To: <1399842528.01.0.0851946414849.issue1765@bugs.pypy.org>
Message-ID: <1399842528.01.0.0851946414849.issue1765@bugs.pypy.org>


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

I have just opened the same issue on CPython, and it was closed as a limitation 
of the implementation: http://bugs.python.org/issue21444?
@ok_message=msg%20217957%20created%0Aissue%2021444%20created&@template=item

Maybe Pypy-dev would like to implement this.

I want to use big numbers for an object's length, but currently Pypy doesn't 
support this: 

    Python 2.7.6 (394146e9bb67, May 08 2014, 18:18:57)
    [PyPy 2.3.0 with MSC v.1500 32 bit] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>>> class A(object):
    ....     def __len__(self):
    ....         return 10 ** 100
    ....
    >>>> a = A()
    >>>> len(a)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: long int too large to convert to int

Same thing happened on Pypy3:

    Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:44)
    [PyPy 2.1.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: ``it's beautiful: very 
rectangular
    and yellow''
    >>>> class A(object):
    ....     def __len__(self):
    ....         return 10 ** 100
    ....
    >>>> a = A()
    >>>> len(a)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: long int too large to convert to int

----------
messages: 6880
nosy: cool-RR, pypy-issue
priority: feature
status: unread
title: __len__ can't return big numbers

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

From tracker at bugs.pypy.org  Mon May 12 10:12:32 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 12 May 2014 08:12:32 +0000
Subject: [pypy-issue] [issue1765] __len__ can't return big numbers
In-Reply-To: <1399842528.01.0.0851946414849.issue1765@bugs.pypy.org>
Message-ID: <1399882352.32.0.024213662767.issue1765@bugs.pypy.org>


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

In general we're unlikely to make efforts to support use cases that CPython
doesn't, but if you want to submit a patch or a pull request, it might be
accepted.  Search and fix all space.len(), and likely keep space.len_w() raising
OverflowError.  This will however mean that in half the cases we support
arbitrary long numbers, and in the other half you get OverflowError anyway...

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

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

From tracker at bugs.pypy.org  Mon May 12 13:28:27 2014
From: tracker at bugs.pypy.org (Rich Wareham)
Date: Mon, 12 May 2014 11:28:27 +0000
Subject: [pypy-issue] [issue1766] numpy.load fails because numpy.frombuffer
	is None
In-Reply-To: <1399894107.51.0.805120030121.issue1766@bugs.pypy.org>
Message-ID: <1399894107.51.0.805120030121.issue1766@bugs.pypy.org>


New submission from Rich Wareham <rich.bugs.pypy at richwareham.com>:

Using PyPy 2.3 installed via pyenv, np.load fails when trying to read data because it makes use of np.frombuffer 
which is None.

Setting np.frombuffer equal to np.fromstring is a workaround.

Numpy instaled via pip install git+https://bitbucket.org/pypy/numpy.git.

Output of python --version:

$ python --version                                   
Python 2.7.6 (394146e9bb67, May 08 2014, 17:08:54)   
[PyPy 2.3.0 with GCC 4.6.3]                          

IPython log:

# IPython log file

get_ipython().magic(u'pinfo %save')
get_ipython().magic(u'quickref')
get_ipython().magic(u'pinfo %logstart')
import numpy as np
np.load('tests/lena.npz').keys()
#[Out]# ['lena']
np.load('tests/lena.npz')['lena']
repr(np.frombuffer)
#[Out]# 'None'
np.frombuffer = np.fromstring
np.load('tests/lena.npz')['lena']
#[Out]# array([[ 0.63529414,  0.63529414,  0.63529414, ...,  0.66666669,
#[Out]#          0.60784316,  0.50196081],
#[Out]#        [ 0.63529414,  0.63529414,  0.63529414, ...,  0.66666669,
#[Out]#          0.60784316,  0.50196081],
#[Out]#        [ 0.63529414,  0.63529414,  0.63529414, ...,  0.66666669,
#[Out]#          0.60784316,  0.50196081],
#[Out]#        ..., 
#[Out]#        [ 0.16862746,  0.16862746,  0.19607843, ...,  0.40784314,
#[Out]#          0.39215687,  0.38431373],
#[Out]#        [ 0.17254902,  0.17254902,  0.21568628, ...,  0.40784314,
#[Out]#          0.41176471,  0.42352942],
#[Out]#        [ 0.17254902,  0.17254902,  0.21568628, ...,  0.40784314,
#[Out]#          0.41176471,  0.42352942]], dtype=float32)
get_ipython().magic(u'logstop')

Exception and traceback:

---------------------------------------------------------------------------                        
TypeError                                 Traceback (most recent call last)                        
<ipython-input-5-95e5d6d28212> in <module>()                                                       
----> 1 np.load('tests/lena.npz')['lena']                                                          

/users/rjw57/projects/dtcwt/venv-pypy/site-packages/numpy/lib/npyio.pyc in __getitem__(self, key)  
    248             if magic == format.MAGIC_PREFIX:                                               
    249                 bytes = self.zip.open(key)                                                 
--> 250                 return format.read_array(bytes)                                            
    251             else:                                                                          
    252                 return self.zip.read(key)                                                  

/users/rjw57/projects/dtcwt/venv-pypy/site-packages/numpy/lib/format.pyc in read_array(fp)         
    466                 data = _read_bytes(fp, read_size, "array data")                            
    467                 array[i:i+read_count] = numpy.frombuffer(data, dtype=dtype,                
--> 468                                                          count=read_count)                 
    469                                                                                            
    470         if fortran_order:                                                                  

TypeError: 'NoneType' object is not callable

----------
messages: 6882
nosy: pypy-issue, rjw57
priority: bug
status: unread
title: numpy.load fails because numpy.frombuffer is None

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

From tracker at bugs.pypy.org  Mon May 12 13:48:46 2014
From: tracker at bugs.pypy.org (Grom PE)
Date: Mon, 12 May 2014 11:48:46 +0000
Subject: [pypy-issue] [issue1523] read() stuck at the end of HTTPS stream
In-Reply-To: <1372704577.14.0.951785051161.issue1523@bugs.pypy.org>
Message-ID: <1399895326.74.0.319167150662.issue1523@bugs.pypy.org>


Grom PE <i at grompe.org.ru> added the comment:

Minimal test program provided works on PyPy 2.3.0 / Windows 7.

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

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

From tracker at bugs.pypy.org  Mon May 12 15:38:27 2014
From: tracker at bugs.pypy.org (Hubert Hesse)
Date: Mon, 12 May 2014 13:38:27 +0000
Subject: [pypy-issue] [issue1767] stm - KeyError in JIT's bridge optimization
In-Reply-To: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>
Message-ID: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>


New submission from Hubert Hesse <hubert.hesse at student.hpi.uni-potsdam.de>:

Hello,
we are building an stm-enabled lang-smalltalk (see bitbucket's stmgc-c7 branch
in lang-smalltalk) with the pypy commit 4169f1423e3d (on pypy's stmgc-c7 branch). 

We have encountered a KeyError in the bridge optimization of the JIT in several
parts of the code. We assume a common root cause.

First, we encountered this error:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
##################RPython traceback:
  File "spyvm_interpreter.c", line 22899, in Interpreter_c_loop_stm
  File "rpython_jit_metainterp_warmstate.c", line 499, in
maybe_compile_and_run__star_4
  File "rpython_jit_metainterp_warmstate.c", line 830, in execute_assembler__star_1
  File "rpython_jit_metainterp_compile.c", line 11956, in
ResumeGuardDescr_handle_fail
  File "rpython_jit_metainterp_compile.c", line 12646, in
ResumeGuardDescr__trace_and_compile_from_bridge
  File "rpython_jit_metainterp_pyjitpl.c", line 55090, in
MetaInterp_handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 55606, in
MetaInterp__handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 1475, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 2516, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 3686, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 26298, in
MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl.c", line 38787, in
MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl.c", line 48282, in MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 7021, in compile_retrace
  File "rpython_jit_metainterp_optimizeopt___init__.c", line 196, in optimize_trace
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 11521, in
UnrollOptimizer_close_loop
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 13907, in
UnrollOptimizer__import_op
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 14971, in
UnrollOptimizer_import_box
  File "rpython_rtyper_lltypesystem_rdict.c", line 23396, in
ll_dict_getitem__dicttablePtr_objectPtr_2
~~~ Crash in JIT! <KeyError object at 0x61c02e0>

then we applied the following changes:
--- a/rpython/jit/metainterp/optimizeopt/unroll.py      Wed May 07 14:33:16 2014
+0200
+++ b/rpython/jit/metainterp/optimizeopt/unroll.py      Mon May 12 13:43:43 2014
+0200
@@ -481,6 +481,8 @@
         if box in self.boxes_created_this_iteration:
             return
 
+        if not self.short_boxes.has_producer(box):
+            return
         short_op = self.short_boxes.producer(box)
         newresult = self.add_op_to_short(short_op)

Next we saw another error through the bridge optimization:
###########################RPython traceback:
  File "spyvm_interpreter.c", line 22892, in Interpreter_c_loop_stm
  File "rpython_jit_metainterp_warmstate.c", line 499, in
maybe_compile_and_run__star_4
  File "rpython_jit_metainterp_warmstate.c", line 830, in execute_assembler__star_1
  File "rpython_jit_metainterp_compile.c", line 11951, in
ResumeGuardDescr_handle_fail
  File "rpython_jit_metainterp_compile.c", line 12641, in
ResumeGuardDescr__trace_and_compile_from_bridge
  File "rpython_jit_metainterp_pyjitpl.c", line 55085, in
MetaInterp_handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 55601, in
MetaInterp__handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 1475, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 2517, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 3687, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 26295, in
MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl.c", line 38783, in
MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl.c", line 48008, in MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 3247, in compile_loop
  File "rpython_jit_metainterp_inliner.c", line 1004, in Inliner_inline_op
  File "rpython_jit_metainterp_inliner.c", line 1821, in Inliner_inline_snapshot
  File "rpython_jit_metainterp_inliner.c", line 1733, in Inliner_inline_snapshot
  File "rpython_rtyper_lltypesystem_rdict.c", line 23438, in
ll_dict_getitem__dicttablePtr_objectPtr_2
~~~ Crash in JIT! <KeyError object at 0x61c02e0>

After this we disabled the inliner:
@@ -154,5 +155,4 @@
         part.operations = [part.operations[-1]] + \
-                          [inliner.inline_op(h_ops[i]) for i in range(start,
len(h_ops))] + \
                           [ResOperation(rop.JUMP, [inliner.inline_arg(a) for a
in jumpargs],
                                         None, descr=jitcell_token)]
         target_token = part.operations[0].getdescr()

... we encountered a similar error in the compile loop:
###########################RPython traceback:
  File "spyvm_interpreter.c", line 3638, in portal
  File "rpython_jit_metainterp_warmstate.c", line 619, in
maybe_compile_and_run__star_4
  File "rpython_jit_metainterp_warmstate.c", line 1004, in bound_reached__star_4
  File "rpython_jit_metainterp_pyjitpl.c", line 532, in
compile_and_run_once___rpython_jit_metainterp_ji
  File "rpython_jit_metainterp_pyjitpl.c", line 1004, in
MetaInterp__compile_and_run_once
  File "rpython_jit_metainterp_pyjitpl.c", line 1475, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 2516, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 3687, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 26293, in
MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl.c", line 38781, in
MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl.c", line 48005, in MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 3255, in compile_loop
  File "rpython_rtyper_lltypesystem_rdict.c", line 23476, in
ll_dict_getitem__dicttablePtr_objectPtr_2
~~~ Crash in JIT! <KeyError object at 0x61c02e0>

----------
messages: 6884
nosy: hubx, pypy-issue
priority: bug
status: unread
title: stm - KeyError in JIT's bridge optimization

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

From tracker at bugs.pypy.org  Mon May 12 16:05:57 2014
From: tracker at bugs.pypy.org (Hubert Hesse)
Date: Mon, 12 May 2014 14:05:57 +0000
Subject: [pypy-issue] [issue1767] stm - KeyError in JIT's bridge optimization
In-Reply-To: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>
Message-ID: <1399903557.99.0.067048172589.issue1767@bugs.pypy.org>


Hubert Hesse <hubert.hesse at student.hpi.uni-potsdam.de> added the comment:

Note: Its correctly running without JIT

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

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

From tracker at bugs.pypy.org  Mon May 12 20:01:35 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 12 May 2014 18:01:35 +0000
Subject: [pypy-issue] [issue1764] pypy 2.3 doesn't translate with gcc 4.9 on
	x86_64
In-Reply-To: <1399837385.35.0.941749529105.issue1764@bugs.pypy.org>
Message-ID: <1399917695.93.0.785124593987.issue1764@bugs.pypy.org>


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

Fixed in cae86999e6c8

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

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

From tracker at bugs.pypy.org  Tue May 13 08:26:30 2014
From: tracker at bugs.pypy.org (Jana Sasout)
Date: Tue, 13 May 2014 06:26:30 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1399962390.59.0.371366748505.issue833@bugs.pypy.org>


Jana Sasout <jana at saout.de> added the comment:

I just wanted to write a small patch to sneek in setgroups, but then noticed 
that it's already there.

Unfortunately it still says "AttributeError: 'module' object has no attribute 
'setgroups'".

So, I suspect there is an issue with the conditional "@registering_if(os, 
'setgroups')", because accessing setgroups with ctypes / cffi just works fine.  
If someone recognizes this as an obvious oversight, can someone sneak the fix 
into 2.3.1? ;)

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

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

From tracker at bugs.pypy.org  Tue May 13 09:37:21 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 13 May 2014 07:37:21 +0000
Subject: [pypy-issue] [issue1767] stm - KeyError in JIT's bridge optimization
In-Reply-To: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>
Message-ID: <1399966641.62.0.296099853962.issue1767@bugs.pypy.org>


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

Can you provide step-by-step instructions about how to reproduce?

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

From tracker at bugs.pypy.org  Tue May 13 09:42:29 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 13 May 2014 07:42:29 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1399966949.47.0.803638459097.issue833@bugs.pypy.org>


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

"os.setgroups" works without AttributeError for me on PyPy 2.3 (Linux64).  Can
you give more precisely your OS/platform, and from where you downloaded the PyPy
you installed?  We know that there are possible issues with that depending on
how it is translated.

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

From tracker at bugs.pypy.org  Tue May 13 09:49:34 2014
From: tracker at bugs.pypy.org (Jana Sasout)
Date: Tue, 13 May 2014 07:49:34 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1399967374.36.0.301393968973.issue833@bugs.pypy.org>


Jana Sasout <jana at saout.de> added the comment:

I compiled it myself on an uptodate version of Gentoo x86-64.

I, however, used the existing install of PyPy for translation, which didn't know 
about about os.setgroups either.  Was this my mistake? (otherwise, I'll find out 
in an hour or so)

If this was my mistake - sorry for the bother.

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

From tracker at bugs.pypy.org  Tue May 13 09:57:42 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 13 May 2014 07:57:42 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1399967862.76.0.498922363181.issue833@bugs.pypy.org>


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

Yes, that's the problem.  Any PyPy translated using an older PyPy will only
contain whatever os-module functions were already available in this older PyPy.
 This is rather buggy, but there is little incentive to fix it for the future,
now that all functions are there...

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

From tracker at bugs.pypy.org  Tue May 13 19:48:53 2014
From: tracker at bugs.pypy.org (Hubert Hesse)
Date: Tue, 13 May 2014 17:48:53 +0000
Subject: [pypy-issue] [issue1767] stm - KeyError in JIT's bridge optimization
In-Reply-To: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>
Message-ID: <1400003333.17.0.00634064079951.issue1767@bugs.pypy.org>


Hubert Hesse <hubert.hesse at student.hpi.uni-potsdam.de> added the comment:

Hi arigo,

I try to that as comprehensible & short as possible. See README on
https://bitbucket.org/pypy/lang-smalltalk/overview for more detail
If you have checked out all repos on the same hierarchy you can use the version
with the correct variables in place below

1. getting source to revision

hg clone https://bitbucket.org/pypy/rsdl
hg clone https://bitbucket.org/pypy/pypy -r 4169f1423e3d # as recommended in IRC
hg clone https://bitbucket.org/pypy/lang-smalltalk -r 014f5e42251f # latest work
with stmgc-c7

2. setting environment variables 

export PYTHONPATH=${PYTHONPATH}:[path to rsdl repository]/rsdl

export PYTHONPATH=${PYTHONPATH}:./rsdl #for me
export SDL_VIDEODRIVER=dummy
export CC=clang #with patches from here
https://bitbucket.org/pypy/stmgc/src/d164a5bcad5e7615b4362b6a1a49d51e2e06de0c/c7/llvmfix/?at=default



3. Build the VM, this may take a while with JIT enabled, that will fail when
executed

[path to pypy repository]/rpython/bin/rpython -O jit [path to lang-smalltalk
repository]/targetimageloadingsmalltalk.py
 
./pypy/rpython/bin/rpython -Ojit --gc=stmgc
lang-smalltalk/targetimageloadingsmalltalk.py


4. execute rsqueak vm

./rsqueakvm-64 lang-smalltalk/images/Squeak4.5-12568.image # will produce the
stack traces below
#######################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################RPython
traceback:
  File "spyvm_interpreter.c", line 22928, in Interpreter_c_loop_stm
  File "rpython_jit_metainterp_warmstate.c", line 497, in
maybe_compile_and_run__star_4
  File "rpython_jit_metainterp_warmstate.c", line 828, in execute_assembler__star_1
  File "rpython_jit_metainterp_compile.c", line 11932, in
ResumeGuardDescr_handle_fail
  File "rpython_jit_metainterp_compile.c", line 12622, in
ResumeGuardDescr__trace_and_compile_from_bridge
  File "rpython_jit_metainterp_pyjitpl.c", line 55086, in
MetaInterp_handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 55602, in
MetaInterp__handle_guard_failure
  File "rpython_jit_metainterp_pyjitpl.c", line 1474, in MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 2515, in MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 3685, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 26297, in
MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl.c", line 38783, in
MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl.c", line 48008, in MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 3248, in compile_loop
  File "rpython_jit_metainterp_inliner.c", line 972, in Inliner_inline_op
  File "rpython_jit_metainterp_inliner.c", line 1820, in Inliner_inline_snapshot
  File "rpython_jit_metainterp_inliner.c", line 1732, in Inliner_inline_snapshot
  File "rpython_rtyper_lltypesystem_rdict.c", line 23425, in
ll_dict_getitem__dicttablePtr_objectPtr_2
~~~ Crash in JIT! <KeyError object at 0x61c02e0>


whereas a VM without JIT runs without those errors.

./pypy/rpython/bin/rpython --gc=stmgc lang-smalltalk/targetimageloadingsmalltalk.py

./rsqueakvm-64 lang-smalltalk/images/Squeak4.5-12568.image # will work

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

From tracker at bugs.pypy.org  Wed May 14 00:51:55 2014
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 13 May 2014 22:51:55 +0000
Subject: [pypy-issue] [issue725] Bug in zipimporting in nested packages
In-Reply-To: <1305720180.28.0.132370010701.issue725@bugs.pypy.org>
Message-ID: <1400021515.9.0.650280311897.issue725@bugs.pypy.org>


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

It seems fixed, and I couldn't find an appropriate failing test on latest win32 
buildbots

pypy-c-jit-71467-67067c56ae1a-win32\pypy
Python 2.7.6 (67067c56ae1a, May 11 2014, 22:01:49)
[PyPy 2.4.0-alpha0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``all software improvements happen
by a bit''
>>>> import sys
>>>> sys.path.append(r'<path>\Downloads\0.zip')
>>>> import my_package
>>>> my_package
<module 'my_package' from '<path>\\Downloads\\0.zip\\my_package\\__init__.py'>

----------
nosy: +mattip
status: chatting -> testing

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

From tracker at bugs.pypy.org  Wed May 14 09:19:36 2014
From: tracker at bugs.pypy.org (Hugo)
Date: Wed, 14 May 2014 07:19:36 +0000
Subject: [pypy-issue] [issue1768] Intermittent segfaults with Coverage.py
In-Reply-To: <1400051976.7.0.275994670268.issue1768@bugs.pypy.org>
Message-ID: <1400051976.7.0.275994670268.issue1768@bugs.pypy.org>


New submission from Hugo <hugovk+pypy at gmail.com>:

Pillow (the 'friendly' PIL fork) is tested on all Python versions available on Travis CI: Python 
2.6, 2.7, 3.2, 3.3, 3.4 and PyPy.

Since adding coverage using Coverage.py, we've been seeing intermittent segfaults on the PyPy 
build. Sometimes all tests will pass, sometimes one will fail, sometimes many will fail. You 
often get a different result re-running the same build.

For example: https://travis-ci.org/python-imaging/Pillow/jobs/25064994

```
running test_file_psd ...
=== error 35584
Segmentation fault
running test_file_tar ...
=== error 35584
Segmentation fault
running test_file_tiff ...
=== error 35584
Segmentation fault
```

A build with coverage enabled fails intermittently:
https://travis-ci.org/hugovk/Pillow/builds/25073481

A build with coverage removed passes:
https://travis-ci.org/hugovk/Pillow/builds/25073451

I re-ran it a few times with similar results.

Also, recording coverage makes the PyPy build job much slower, about x5.8 slower. Coverage 
doesn't affect the Python 2.x or 3.x times much.

Covered build total: 28m38s
Non-covered build total: 21m22s
-
Covered PyPy job: 10m39s
Non-covered PyPy job: 3m50s
-
Covered Python 2.x and 3.x jobs (five jobs): 17m59s
Non-covered Python 2.x and 3.x jobs (five jobs): 17m32s
-
Covered selftest.py: 7.624s
Non-covered selftest.py: 2.860s
-
Covered Tests/run.py: 7m29.489s
Non-covered Tests/run.py: 1m17.394s

Travis CI says it's using PyPy 2.2.1:

```
python --version
Python 2.7.3 (87aa9de10f9c, Nov 24 2013, 18:48:13)
[PyPy 2.2.1 with GCC 4.6.3]
```

(Here's the issue at Pillow: https://github.com/python-imaging/Pillow/issues/640)

----------
messages: 6894
nosy: hugovk, pypy-issue
priority: bug
release: 2.2
status: unread
title: Intermittent segfaults with Coverage.py

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

From tracker at bugs.pypy.org  Wed May 14 17:37:40 2014
From: tracker at bugs.pypy.org (bug)
Date: Wed, 14 May 2014 15:37:40 +0000
Subject: [pypy-issue] [issue1769] Memory leak
In-Reply-To: <1400081860.27.0.72256210249.issue1769@bugs.pypy.org>
Message-ID: <1400081860.27.0.72256210249.issue1769@bugs.pypy.org>


New submission from bug <ddvmssr+2pxkfw at sharklasers.com>:

This code leaks memory on PyPy 2.3 but not CPython
http://pastebin.com/zwdPgi2n

----------
messages: 6895
nosy: bug, pypy-issue
priority: bug
status: unread
title: Memory leak

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

From tracker at bugs.pypy.org  Wed May 14 18:12:41 2014
From: tracker at bugs.pypy.org (bug)
Date: Wed, 14 May 2014 16:12:41 +0000
Subject: [pypy-issue] [issue1769] Memory leak
In-Reply-To: <1400081860.27.0.72256210249.issue1769@bugs.pypy.org>
Message-ID: <1400083961.9.0.986296323792.issue1769@bugs.pypy.org>


bug <ddvmssr+2pxkfw at sharklasers.com> added the comment:

cfbolz: j=5,10,15 I get 645432 1407060 2019392 using /usr/bin/time --format="%M 
as recommended by cfbolz on IRC. With j=30 my mouse cursor gets laggy and I have 
to Control+C.

I think I am using a nightly build since 2.3.

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

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

From tracker at bugs.pypy.org  Wed May 14 18:13:14 2014
From: tracker at bugs.pypy.org (bug)
Date: Wed, 14 May 2014 16:13:14 +0000
Subject: [pypy-issue] [issue1769] Memory leak
In-Reply-To: <1400081860.27.0.72256210249.issue1769@bugs.pypy.org>
Message-ID: <1400083994.74.0.639078591199.issue1769@bugs.pypy.org>


bug <ddvmssr+2pxkfw at sharklasers.com> added the comment:

class Trie:
    def __init__(ss):
        ss.prefixes = [False]*100
   
    def add(ss, i, depth):
        prefixes = ss.prefixes[:]
        if depth:
            t = ss.prefixes[i%100]
            if not t:
                t = Trie()
            prefixes[i%100] = t.add(i//100, depth-1)
        else:
            prefixes[i%100] = True
       
        n = Trie()
        n.prefixes = prefixes
        return n
 
 
#higher j uses more memory even after print('done')
#the old memory should be freed at t = Trie()
for j in range(10):
    t = Trie()
    for i in range(10**5):
        t = t.add(i, 3)
 
print('done')
while t:
    continue

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

From tracker at bugs.pypy.org  Wed May 14 18:59:58 2014
From: tracker at bugs.pypy.org (bug)
Date: Wed, 14 May 2014 16:59:58 +0000
Subject: [pypy-issue] [issue1769] Memory leak
In-Reply-To: <1400081860.27.0.72256210249.issue1769@bugs.pypy.org>
Message-ID: <1400086798.49.0.300484830098.issue1769@bugs.pypy.org>


bug <ddvmssr+2pxkfw at sharklasers.com> added the comment:

LarstiQ identified that, if gc.collect() is added before the line t = Trie(), 
memory use doesn't blow up. Seems to be a collection-timing issue rather than an 
actual memory leak. Also not everyone seems affected.

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

From tracker at bugs.pypy.org  Wed May 14 21:48:37 2014
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Wed, 14 May 2014 19:48:37 +0000
Subject: [pypy-issue] [issue1768] Intermittent segfaults with Coverage.py
In-Reply-To: <1400051976.7.0.275994670268.issue1768@bugs.pypy.org>
Message-ID: <1400096917.08.0.519579356178.issue1768@bugs.pypy.org>


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

Some issues were fixed in pypy 2.3, we also had some intermittent segfaults with 
2.2.1 but not with 2.3

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

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

From tracker at bugs.pypy.org  Wed May 14 22:20:02 2014
From: tracker at bugs.pypy.org (Hugo)
Date: Wed, 14 May 2014 20:20:02 +0000
Subject: [pypy-issue] [issue1768] Intermittent segfaults with Coverage.py
In-Reply-To: <1400051976.7.0.275994670268.issue1768@bugs.pypy.org>
Message-ID: <1400098802.38.0.864733440024.issue1768@bugs.pypy.org>


Hugo <hugovk+pypy at gmail.com> added the comment:

That's good to hear.

Travis say: "We provide the most recent stable release of PyPy via PyPy Team's Releases 
PPA."
http://docs.travis-ci.com/user/languages/python/#PyPy-Support

https://launchpad.net/~pypy/+archive/ppa has 2.2.1 but not yet 2.3. (I see 2.3 was only 
just released last week.) Any idea when 2.3 will be there?

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

From tracker at bugs.pypy.org  Thu May 15 10:28:06 2014
From: tracker at bugs.pypy.org (Hubert Hesse)
Date: Thu, 15 May 2014 08:28:06 +0000
Subject: [pypy-issue] [issue1767] stm - KeyError in JIT's bridge optimization
In-Reply-To: <1399901907.96.0.652636607529.issue1767@bugs.pypy.org>
Message-ID: <1400142486.35.0.322607636655.issue1767@bugs.pypy.org>


Hubert Hesse <hubert.hesse at student.hpi.uni-potsdam.de> added the comment:

<codeZeilen> arigato: Regarding the KeyError issue, we (hubx, mswart, conne)
will be around during the whole day and working on it :)
<codeZeilen> arigato: If there's anything we can provide you with, just let us
know. We're happy to help.

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

From tracker at bugs.pypy.org  Thu May 15 15:11:10 2014
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 15 May 2014 13:11:10 +0000
Subject: [pypy-issue] [issue1770] Massive performance regression in fastavro
	with PyPy >=	1.9
In-Reply-To: <1400112872.7.0.362185330188.issue1770@bugs.pypy.org>
Message-ID: <1400159470.51.0.377068135938.issue1770@bugs.pypy.org>


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

Massive slowdown in the fastavro library between PyPy 1.8 and 1.9.  (This
message is here to send a mail to the mailing list; the original one is too big
with its attached file.)

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

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