From arigo at tunes.org  Tue Sep  1 08:29:21 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 1 Sep 2015 08:29:21 +0200
Subject: [pypy-dev] Dependencies in noon-standard locations
In-Reply-To: <CANc-5Uy34FKvn8cC+nfwf75Udhy4d8grsPpvdSCMj0N+pCgtsg@mail.gmail.com>
References: <CANc-5Uy34FKvn8cC+nfwf75Udhy4d8grsPpvdSCMj0N+pCgtsg@mail.gmail.com>
Message-ID: <CAMSv6X2DgJQMuWN-nSObiAyNcNc+=pd4sQoUvKdFnQrZn6_U-A@mail.gmail.com>

Hi Skip,

On Mon, Aug 31, 2015 at 10:09 PM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
> I'm using OpenSuSE 12.2, which I doubt will work with any of the PyPy
> binaries. Would love to be proved incorrect though.

Additionally, you can use the portable Linux binaries provided by
Squeaky.  See "Linux binaries and common distributions" on
http://pypy.org/download.html.


A bient?t,

Armin

From arigo at tunes.org  Tue Sep  1 13:28:33 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 1 Sep 2015 13:28:33 +0200
Subject: [pypy-dev] use as benchmark pypy vs python if you please
In-Reply-To: <CAGGBzXJ0KWSYR_mZj1gjeTCpfiD24ELPHV+freG6tO9vqPE=fA@mail.gmail.com>
References: <CAGGBzXJ0KWSYR_mZj1gjeTCpfiD24ELPHV+freG6tO9vqPE=fA@mail.gmail.com>
Message-ID: <CAMSv6X3Xjx1KTt50MQDAnb0kfxEBUaMzT91eU6WK3Yj2=hqNDw@mail.gmail.com>

Hi Dima,

On Mon, Aug 4, 2014 at 5:04 PM, Dima Tisnek <dimaqq at gmail.com> wrote:
> Attached is n-queens solver (pardon my naive algorithm), it runs:
> python 2.7.6: 17s
> pypy 2.4.0 alpha: 23s
> same nojit: 32s
>
> I've tried similar-looking algorithm for another problem before, and has
> similar results -- somehow pypy was slower.
>
> feel free to investigate / tweak or even use on speed.pypy.org

So, it took us more than one year, but now I finally figured it out.
The reason it is slower in PyPy is because sets recompute the items'
hash much more often than in CPython.  I fixed it in the branch
'keys_with_hash' (which is just too late for pypy 2.6.1).  Some
microbenchmarks are 2x or 3x faster now.

In your code, it shows up as the _diff() function, which returns "a -
b" where a and b are sets of complicated objects.  Actually, there are
always disjoint sets, so the original code might be a bit buggy :-)
But the _diff() operation is now twice faster.  I get the following
times on your nq.py example:

    python 2.7.3: 15.5s
    pypy 2.6.1 in keys_with_hash: 10.9s
    same with '--jit off': 20.3s


A bient?t,

Armin.

From skip.montanaro at gmail.com  Tue Sep  1 15:45:46 2015
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Tue, 1 Sep 2015 08:45:46 -0500
Subject: [pypy-dev] Dependencies in noon-standard locations
In-Reply-To: <CAK5idxTbiRJOjC09wq+Gi0S4dnPuuGVecb61HM6UeHANnXF+TA@mail.gmail.com>
References: <CANc-5Uy34FKvn8cC+nfwf75Udhy4d8grsPpvdSCMj0N+pCgtsg@mail.gmail.com>
 <CAK5idxS5Lpts_TqxxF_rr9oCEAp36DYf9CeK1M3j2dLFVWQjdQ@mail.gmail.com>
 <CANc-5Uydf28zg+SmXbLw-1vEp5uMfkrO1sYXHwd6aur52ijyyw@mail.gmail.com>
 <CAK5idxTbiRJOjC09wq+Gi0S4dnPuuGVecb61HM6UeHANnXF+TA@mail.gmail.com>
Message-ID: <CANc-5UzbTLaqRuoDtOuSR5KojQ9XO8xdz6F=Qef_zWFxJYwYkw@mail.gmail.com>

*sigh* I'm an idiot. That's what I get for trying to rush before headed out
the office door.

My apologies...

Skip


On Mon, Aug 31, 2015 at 4:04 PM, Maciej Fijalkowski <fijall at gmail.com>
wrote:

> welll...... as you can see the C flag got passed through, so either
> you have a typo or something is off. You can see what sort of gcc
> invocation was there, so execute it and figure out why it's not
> working
>
> On Mon, Aug 31, 2015 at 10:47 PM, Skip Montanaro
> <skip.montanaro at gmail.com> wrote:
> >
> > On Mon, Aug 31, 2015 at 3:16 PM, Maciej Fijalkowski <fijall at gmail.com>
> > wrote:
> >>
> >> pypy should respect LDFLAGS and CFLAGS (but indeed not CPPFLAGS)
> >
> >
> > Thanks. I gave that a try, but got the same error:
> >
> > blade% pwd
> > /home/skipm/3rdParty/pypy-2.6.1-src/pypy/goal
> > blade% LDFLAGS='-L /opt/TWWfsw/libexpat20/lib' CFLAGS='-I
> > /opt/TWWfsw/libexpat20/Include' python ../../rpython/bin/rpython -Ojit
> > targetpypystandalone
> > ... lots of output elided ...
> > [platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall
> > -Wno-unused -I /opt/TWWfsw/libexpat20/Include
> > /tmp/usession-release-2.6.1-2/platcheck_54.c -o
> > /tmp/usession-release-2.6.1-2/platcheck_54.o
> > ...
> > [translation:ERROR] CompilationError: CompilationError(err="""
> > [translation:ERROR] /tmp/usession-release-2.6.1-2/platcheck_54.c:79:19:
> > error: expat.h: No such file or directory
> > [translation:ERROR] """)
> >
> >
> > Skip
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150901/ec17fd92/attachment.html>

From naylor.b.david at gmail.com  Tue Sep  1 23:45:03 2015
From: naylor.b.david at gmail.com (David Naylor)
Date: Tue, 01 Sep 2015 23:45:03 +0200
Subject: [pypy-dev] 2.6.1 and freebsd-9
In-Reply-To: <9800207.igzAqY9dSP@dragon.local>
References: <55D8BEA8.2070907@gmail.com> <9800207.igzAqY9dSP@dragon.local>
Message-ID: <2447988.5DYum3Ue09@dragon.local>

On Monday, 24 August 2015 23:07:20 David Naylor wrote:
> On Saturday, 22 August 2015 21:25:44 Matti Picus wrote:
> > I would like to add the freebsd-9-x86-64 binary tgz to our released
> > downloads. We still have a number of failing tests showing up on
> > http://buildbot.pypy.org/summary?category=freebsd64
> > among them many
> > DLOpenError: "opening 'libm.so' with ctypes.CDLL() works, but not with
> > c_dlopen()??"
> > and the more worrying SIGSEGV in
> > http://buildbot.pypy.org/summary/longrepr?testname=unmodified&builder=pypy
> > -c -jit-freebsd-9-x86-64&build=655&mod=lib-python.2.7.test.test_io
> > 
> > Could someone proficient in freebsd suggest what is going on?
> As for the SIGSEGV (it does not occur on python):
> # gdb `which pypy` pypy.core
> gdb) bt
> #0  0x00000008006548a7 in ?? ()
> #1  0x0000000000000001 in ?? ()
> #2  0x00000008020b9cd3 in pypy_thread_attach () from
> /usr/local/pypy-2.6/bin//libpypy-c.so
> #3  0x00000008020c2ea0 in pypy_thread_attach () from
> /usr/local/pypy-2.6/bin//libpypy-c.so
> #4  0x07f4e08f801b663a in ?? ()
> #5  0x0000000000000000 in ?? ()
> 
> I will need to translate an unstripped pypy to debug further.

Running pypy with `--jit off` avoids the SIGSEGV.  FreeBSD does sometimes 
require the sem(4) kernel module to be loaded to provide POSIX semaphores 
however I can still reproduce the SIGSEGV with sem(4) loaded (although it
appears to be less reliably reproduced).  

Also, when running the pypy/modules/_multiprocessing tests PyPy is SIGSEGV 
(and this time so is cPython).  In these tests the SIGSEGV happens in 
sem_close(3) from libc.so.  

#0  0x00000008048ae38a in sem_close () from /lib/libc.so.7
#1  0x0000000805ce4738 in ffi_call_unix64 () from /usr/local/lib/libffi.so.6
#2  0x0000000805ce3fd9 in ffi_call () from /usr/local/lib/libffi.so.6
<snip/>

The full dump is below from test_io (I think the SIGSEGV happens in thread 2):

[New Thread 807f91c00 (LWP 100844/<unknown>)]
[New Thread 807f91000 (LWP 100841/<unknown>)]
[New Thread 806c06400 (LWP 100747/<unknown>)]
(gdb) thr 1
[Switching to thread 1 (Thread 807f91c00 (LWP 100844/<unknown>))]#0  0x00000008048bef18 in _umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x00000008048bef18 in _umtx_op () from /lib/libc.so.7
#1  0x00000008048ae604 in sem_timedwait () from /lib/libc.so.7
#2  0x0000000802f0757c in RPyThreadAcquireLockTimed ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#3  0x000000080065472c in ?? ()
#4  0x0000000806e0e738 in ?? ()
#5  0x0000000000000018 in ?? ()
#6  0x00000008037322a8 in pypy_g_pypy_interpreter_signature_Signature_10 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#7  0x0000000000000002 in ?? ()
#8  0x0000000000000001 in ?? ()
#9  0x0000000000000002 in ?? ()
#10 0x0000000000000041 in ?? ()
#11 0x000000080853d460 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0x0000000802116ae0 in pypy_g_funccall_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#14 0x07f5e6c47cb71fd8 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb) thr 2
[Switching to thread 2 (Thread 807f91000 (LWP 100841/<unknown>))]#0  0x000000080065429c in ?? ()
(gdb) bt
#0  0x000000080065429c in ?? ()
#1  0x0000000000000001 in ?? ()
#2  0x0000000000000018 in ?? ()
#3  0x00000008037322a8 in pypy_g_pypy_interpreter_signature_Signature_10 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#4  0x0000000000000002 in ?? ()
#5  0x0000000000000001 in ?? ()
#6  0x0000000000000002 in ?? ()
#7  0x0000000000000041 in ?? ()
#8  0x000000080853d460 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000802116ae0 in pypy_g_funccall_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#11 0x07f5e6c47cb71fd8 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb) thr 3
[Switching to thread 3 (Thread 806c06400 (LWP 100747/<unknown>))]#0  0x00000008048bef18 in _umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x00000008048bef18 in _umtx_op () from /lib/libc.so.7
#1  0x00000008048ae604 in sem_timedwait () from /lib/libc.so.7
#2  0x0000000802f0756d in RPyThreadAcquireLockTimed ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#3  0x0000000801f9270b in pypy_g_ccall_RPyThreadAcquireLockTimed__struct_RPyOpaqu ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#4  0x0000000802de533f in pypy_g_Lock_acquire_timed ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#5  0x00000008026ec090 in pypy_g_acquire_timed ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#6  0x0000000801ea24d1 in pypy_g_fastfunc_descr_lock_py3k_acquire_3 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#7  0x0000000802119ae7 in pypy_g_BuiltinCode3_fastcall_3 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#8  0x0000000802116b06 in pypy_g_funccall_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#9  0x0000000802734fe1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#10 0x00000008021411a4 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#11 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#12 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#13 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#14 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#15 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#16 0x0000000802734fe1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#17 0x00000008021411a4 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#18 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#19 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#20 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#21 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#22 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#23 0x0000000802734fe1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#24 0x00000008021411a4 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#25 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#26 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#27 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#28 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#29 0x0000000802120d2e in pypy_g_GeneratorIterator__send_ex ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#30 0x000000080211a0d2 in pypy_g_BuiltinCode1_fastcall_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#31 0x0000000802116abf in pypy_g_funccall_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#32 0x0000000802734fe1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#33 0x00000008021411a4 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#34 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#35 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#36 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#37 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
---Type <return> to continue, or q <return> to quit---
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#38 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#39 0x00000008020dfdef in pypy_g_call_function__star_3 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#40 0x0000000802150442 in pypy_g_WITH_CLEANUP__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#41 0x0000000802140488 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#42 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#43 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#44 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#45 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#46 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#47 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#48 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#49 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#50 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#51 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#52 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#53 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#54 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#55 0x000000080210e39c in pypy_g_Method_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#56 0x000000080270cd1b in pypy_g_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#57 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#58 0x0000000802140fef in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#59 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#60 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#61 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#62 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#63 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#64 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#65 0x000000080210e334 in pypy_g_Function_call_obj_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#66 0x00000008020f2de2 in pypy_g_call_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#67 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#68 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#69 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#70 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#71 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#72 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#73 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
---Type <return> to continue, or q <return> to quit---
#74 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#75 0x000000080210e39c in pypy_g_Method_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#76 0x000000080270cd1b in pypy_g_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#77 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#78 0x0000000802140fef in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#79 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#80 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#81 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#82 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#83 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#84 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#85 0x000000080210e334 in pypy_g_Function_call_obj_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#86 0x00000008020f2de2 in pypy_g_call_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#87 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#88 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#89 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#90 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#91 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#92 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#93 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#94 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#95 0x000000080210e39c in pypy_g_Method_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#96 0x000000080270cd1b in pypy_g_call_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#97 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#98 0x0000000802140fef in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#99 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#100 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#101 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#102 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#103 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#104 0x0000000801d9de02 in pypy_g_dispatcher_4 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#105 0x000000080210e334 in pypy_g_Function_call_obj_args ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#106 0x00000008020f2de2 in pypy_g_call_valuestack__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#107 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#108 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#109 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#110 0x00000008026ca6fc in pypy_g_portal_5 ()
---Type <return> to continue, or q <return> to quit---
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#111 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#112 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#113 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#114 0x0000000802734fe1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#115 0x00000008021411a4 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#116 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#117 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#118 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#119 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#120 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#121 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#122 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#123 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#124 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#125 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#126 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#127 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#128 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#129 0x0000000802140f03 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#130 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#131 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#132 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#133 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#134 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#135 0x0000000802147606 in pypy_g_CALL_FUNCTION__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#136 0x0000000802140d62 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#137 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#138 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#139 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#140 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#141 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#142 0x0000000802148cdb in pypy_g_EXEC_STMT__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#143 0x000000080214051c in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#144 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#145 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#146 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
---Type <return> to continue, or q <return> to quit---
#147 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#148 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#149 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#150 0x0000000802140fef in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#151 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#152 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#153 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#154 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#155 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#156 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#157 0x0000000802140f03 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#158 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#159 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#160 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#161 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#162 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#163 0x0000000802147da0 in pypy_g_call_function__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#164 0x0000000802140f70 in pypy_g_dispatch_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#165 0x000000080213e9cb in pypy_g_handle_bytecode__AccessDirect_None ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#166 0x00000008026ca6fc in pypy_g_portal_5 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#167 0x0000000802bb439b in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#168 0x000000080213231b in pypy_g_PyFrame_execute_frame ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#169 0x0000000802131a29 in pypy_g_PyFrame_run ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#170 0x00000008020dd6c5 in pypy_g_call_function__star_2 ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#171 0x000000080201ba4d in pypy_g_entry_point ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#172 0x0000000802f10733 in pypy_main_function ()
   from /usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-f3ad1e1e1d62/pypy/goal//libpypy-c.so
#173 0x00000000004006cf in _start ()
#174 0x0000000800620000 in ?? ()
#175 0x0000000000000000 in ?? ()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150901/3077d093/attachment-0001.sig>

From opensource at ronnypfannschmidt.de  Wed Sep  2 21:15:57 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 2 Sep 2015 21:15:57 +0200
Subject: [pypy-dev] [informative] quick git repo experimentation - results
 wrt repository size
Message-ID: <55E74AED.8060604@ronnypfannschmidt.de>

Hello,

i finished experimenting with converting the pypy repo to git using the
gitifyhg git remote

the basic result being

heisenbug ~/P/p/pypy-git> du -sh .git/{hg,objects}
742M    .git/hg
134M    .git/objects


which is quite a reduction
i did not yet investigate eventually missing metadata and the details
about branch history

the number of active branches seems to fit

heisenbug ~/P/p/pypy-git> git branch -a|wc -l
203

and

heisenbug ~/P/p/pypy> hg branches|wc -l
201


the 2 additial branches in git are due to remote tracking and head
tracking which is not necessary/possible in mercurial.

-- Ronny



From walderchristian at gmail.com  Thu Sep  3 02:58:52 2015
From: walderchristian at gmail.com (Christian Walder)
Date: Thu, 3 Sep 2015 10:58:52 +1000
Subject: [pypy-dev] segmentation fault 11 on OS X
Message-ID: <CAOwaaSgbYTbq3UzZi6XsRjQJm7SZrQB+tF4-aPjtD7=3fT=Fxg@mail.gmail.com>

Hello,

I'm running into a segmentation fault on pypy.

Is the attached OS X crash report useful for diagnosing the problem?

I haven't succeeded in making a minimal example of this issue, as it occurs
in the middle of a complex program, and the same program even runs
correctly when processing a smaller amount of data.

I'm using the latest nightly build but the same thing happens if I compile
the latest pypy from git.

Thanks again for pypy.

best,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150903/f7c6a7a3/attachment-0001.html>
-------------- next part --------------

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100001000 [    4K] r-x/rwx SM=COW  /Users/USER/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libpypy-c.dylib               	0x0000000100d35800 pypy_g_OptRewrite_optimize_GUARD_VALUE + 1280
1   libpypy-c.dylib               	0x0000000100d55626 pypy_g_dispatch_optimize___star_0_6 + 2870
2   libpypy-c.dylib               	0x0000000100d33b60 pypy_g_OptRewrite_propagate_forward + 256
3   libpypy-c.dylib               	0x0000000100d035d1 pypy_g_OptIntBounds_optimize_GUARD_TRUE + 145
4   libpypy-c.dylib               	0x0000000100d5619d pypy_g_dispatch_optimize___star_0_7 + 1069
5   libpypy-c.dylib               	0x0000000100d03536 pypy_g_OptIntBounds_propagate_forward + 6
6   libpypy-c.dylib               	0x0000000100d4f57c pypy_g_UnrollOptimizer__inline_short_preamble + 748
7   libpypy-c.dylib               	0x0000000100d49c58 pypy_g_UnrollOptimizer_jump_to_already_compiled_trace + 6824
8   libpypy-c.dylib               	0x0000000100d42e14 pypy_g_UnrollOptimizer_propagate_all_forward + 3316
9   libpypy-c.dylib               	0x0000000100cf60d6 pypy_g_optimize_trace + 390
10  libpypy-c.dylib               	0x0000000100ccfbe3 pypy_g_compile_trace + 1811
11  libpypy-c.dylib               	0x0000000100e0bfb1 pypy_g_MetaInterp_compile_trace + 1265
12  libpypy-c.dylib               	0x0000000100dd5e96 pypy_g_MetaInterp_reached_loop_header + 1478
13  libpypy-c.dylib               	0x0000000100dd4d5a pypy_g_MIFrame_opimpl_jit_merge_point + 970
14  libpypy-c.dylib               	0x0000000100d99378 pypy_g_handler_jit_merge_point_1 + 968
15  libpypy-c.dylib               	0x0000000100d8d808 pypy_g_MIFrame_run_one_step + 72
16  libpypy-c.dylib               	0x0000000100d87aa7 pypy_g_MetaInterp_interpret + 55
17  libpypy-c.dylib               	0x0000000100e36ef5 pypy_g_MetaInterp__handle_guard_failure + 597
18  libpypy-c.dylib               	0x0000000100e36558 pypy_g_MetaInterp_handle_guard_failure + 712
19  libpypy-c.dylib               	0x0000000100cd9a20 pypy_g_ResumeGuardDescr__trace_and_compile_from_bridge + 512
20  libpypy-c.dylib               	0x0000000100cd92de pypy_g_ResumeGuardDescr_handle_fail + 174
21  libpypy-c.dylib               	0x0000000100eb2b18 pypy_g_execute_assembler__star_2_2 + 456
22  libpypy-c.dylib               	0x0000000100eb21a8 pypy_g_maybe_compile_and_run__star_5_1 + 984
23  libpypy-c.dylib               	0x0000000100e63eaa pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 58
24  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
25  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
26  libpypy-c.dylib               	0x00000001003d6096 pypy_g_CALL_FUNCTION__AccessDirect_None + 118
27  libpypy-c.dylib               	0x00000001003ce1ab pypy_g_dispatch_bytecode__AccessDirect_None + 6923
28  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
29  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
30  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
31  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
32  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
33  libpypy-c.dylib               	0x00000001009e231b pypy_g_CALL_METHOD__AccessDirect_star_1 + 251
34  libpypy-c.dylib               	0x00000001003ce5dd pypy_g_dispatch_bytecode__AccessDirect_None + 7997
35  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
36  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
37  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
38  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
39  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
40  libpypy-c.dylib               	0x00000001009e2ab9 pypy_g_CALL_METHOD__AccessDirect_star_1 + 2201
41  libpypy-c.dylib               	0x00000001003ce5dd pypy_g_dispatch_bytecode__AccessDirect_None + 7997
42  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
43  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
44  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
45  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
46  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
47  libpypy-c.dylib               	0x00000001003d77f2 pypy_g_EXEC_STMT__AccessDirect_None + 994
48  libpypy-c.dylib               	0x00000001003cd7c8 pypy_g_dispatch_bytecode__AccessDirect_None + 4392
49  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
50  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
51  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
52  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
53  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
54  libpypy-c.dylib               	0x00000001003d6872 pypy_g_call_function__AccessDirect_None + 1762
55  libpypy-c.dylib               	0x00000001003ce428 pypy_g_dispatch_bytecode__AccessDirect_None + 7560
56  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
57  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
58  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
59  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
60  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
61  libpypy-c.dylib               	0x00000001003d6872 pypy_g_call_function__AccessDirect_None + 1762
62  libpypy-c.dylib               	0x00000001003ce34c pypy_g_dispatch_bytecode__AccessDirect_None + 7340
63  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
64  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
65  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
66  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
67  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
68  libpypy-c.dylib               	0x00000001003d6872 pypy_g_call_function__AccessDirect_None + 1762
69  libpypy-c.dylib               	0x00000001003ce3b9 pypy_g_dispatch_bytecode__AccessDirect_None + 7449
70  libpypy-c.dylib               	0x00000001003cc26b pypy_g_handle_bytecode__AccessDirect_None + 43
71  libpypy-c.dylib               	0x0000000100975b6c pypy_g_portal_5 + 76
72  libpypy-c.dylib               	0x0000000100e6408c pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 540
73  libpypy-c.dylib               	0x00000001003bf6b1 pypy_g_PyFrame_execute_frame + 1521
74  libpypy-c.dylib               	0x00000001003bed8c pypy_g_PyFrame_run + 236
75  libpypy-c.dylib               	0x0000000100368272 pypy_g_call_function__star_2 + 306
76  libpypy-c.dylib               	0x00000001002a4542 pypy_g_entry_point + 4642
77  libpypy-c.dylib               	0x00000001011d7e43 pypy_main_function + 131
78  python                        	0x0000000100000f14 start + 52

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00000001044eb438  rcx: 0x0000000104300580  rdx: 0x0000000000068e18
  rdi: 0x0000000101f56040  rsi: 0x00000001014f9b60  rbp: 0x00000000ffffffff  rsp: 0x00007fff5fbfe330
   r8: 0x00000001014fada0   r9: 0x0000000101520198  r10: 0x000000000000000f  r11: 0x000000000000000c
  r12: 0x00000001044f3aa0  r13: 0x000000010147a720  r14: 0x00000001044e6fd8  r15: 0x000000010451f118
  rip: 0x0000000100d35800  rfl: 0x0000000000010246  cr2: 0x0000000000000000
  
Logical CPU:     1
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000ff7 +python (???) <33232343-6431-3299-9B2C-EF3CD6BFD793> /Users/USER/*/python
       0x100003000 -        0x10145dff7 +libpypy-c.dylib (0) <97003214-7E9D-33B0-ADEF-8A858128CFB5> /Users/USER/*/libpypy-c.dylib
       0x1040d7000 -        0x10410dff7  libssl.0.9.8.dylib (52.40.1) <0121FFA1-8332-39FF-9542-3E80BBC323D7> /usr/lib/libssl.0.9.8.dylib
       0x104155000 -        0x10415cfff +_bitarray.pypy-26.so (0) <E9F35464-6A39-3B0A-9B64-3847D45D9507> /Users/USER/*/_bitarray.pypy-26.so
       0x1041dc000 -        0x1041dcff7 +_pwdgrp_cffi.pypy-26.so (0) <FC95A6F2-8184-3A8D-9800-E09D0A6895D5> /Users/USER/Downloads/*/_pwdgrp_cffi.pypy-26.so
       0x1041df000 -        0x1041e1fff +_curses_cffi.pypy-26.so (0) <B0691BA8-E998-3EC3-A12B-EDD7EF71E247> /Users/USER/Downloads/*/_curses_cffi.pypy-26.so
       0x1041ea000 -        0x1041ebfff  libpanel.5.4.dylib (44) <FB699180-AF56-34A8-90C7-8C0DC748F22B> /usr/lib/libpanel.5.4.dylib
       0x1041f1000 -        0x1041fafff +_cffi__gf1c0eb94x67809c30.pypy-26.so (0) <56EA04B2-A332-3874-A71C-411CE5A3D1F5> /Users/USER/*/_cffi__gf1c0eb94x67809c30.pypy-26.so
       0x1047d2000 -        0x1047ebfff +libumath_linalg_cffi.so (0) <FC8B4CBA-3BA2-3D7C-9761-61F23BDF4503> /Users/USER/*/libumath_linalg_cffi.so
       0x1047f1000 -        0x1047f5ff7 +lib_mtrand.so (0) <816FB6AD-7D2B-329D-92F6-3D72BAF2D2E1> /Users/USER/*/lib_mtrand.so
       0x1047f8000 -        0x1047f9ff7 +_psutil_posix.pypy-26.so (0) <60E10BE3-4215-3A15-B646-64B2C977A7DC> /Users/USER/*/_psutil_posix.pypy-26.so
       0x1053f4000 -        0x1053f9fff +_psutil_osx.pypy-26.so (0) <07062A84-67B1-3150-957C-0B1DEFEE95EF> /Users/USER/*/_psutil_osx.pypy-26.so
       0x106fc4000 -        0x106fe6fff +libpng16.16.dylib (0) <4FBB93E7-7294-3B41-AC6D-BFC5B4DA308B> /usr/local/lib/libpng16.16.dylib
       0x106fef000 -        0x106ff2fff +_cntr.pypy-26.so (0) <D219A9B9-8D0A-3FF1-AAD2-8A17D339E157> /Users/USER/*/_cntr.pypy-26.so
       0x107480000 -        0x1075cbfff +liblapack_lite.so (0) <9F744B71-664A-31D5-89D8-953E1E0B6097> /Users/USER/*/liblapack_lite.so
       0x107792000 -        0x1077bffff +_path.pypy-26.so (0) <07D37A9D-96D0-3159-BE46-BE12F7CBC34F> /Users/USER/*/_path.pypy-26.so
       0x1077d5000 -        0x1077e9fff +_png.pypy-26.so (0) <29632F52-3C49-3078-94A9-273790AB3C7A> /Users/USER/*/_png.pypy-26.so
       0x108a80000 -        0x108ab1fff +ft2font.pypy-26.so (0) <F5C4F5CF-F0FC-3181-896C-89E672DA4E69> /Users/USER/*/ft2font.pypy-26.so
       0x108acc000 -        0x108b39ff7 +libfreetype.6.dylib (0) <B5C01F34-7D52-33F3-A2E7-3555388623CE> /usr/local/lib/libfreetype.6.dylib
       0x109ba4000 -        0x109bd4ff7 +_image.pypy-26.so (0) <74B7C662-23A9-3458-921C-60E18216CB84> /Users/USER/*/_image.pypy-26.so
       0x109cae000 -        0x109cc9ff7 +_delaunay.pypy-26.so (0) <96E286C8-B334-3CFD-A05E-A052D91C6AD4> /Users/USER/*/_delaunay.pypy-26.so
       0x109cdc000 -        0x109d06ff7 +_tri.pypy-26.so (0) <8C8B1DD3-47DB-3B70-B1E4-8221760F09C6> /Users/USER/*/_tri.pypy-26.so
       0x109da1000 -        0x109dbbff7 +ttconv.pypy-26.so (0) <94D4361A-1D82-3B4B-9B16-78DEBB78AF45> /Users/USER/*/ttconv.pypy-26.so
       0x109f00000 -        0x109f4eff7 +_backend_agg.pypy-26.so (0) <EDE22BAE-29D0-3577-86A9-74E2055569B7> /Users/USER/*/_backend_agg.pypy-26.so
    0x7fff6d1c1000 -     0x7fff6d1f7887  dyld (353.2.3) <B1B370A5-479F-3533-8AD7-97B687D4F989> /usr/lib/dyld
    0x7fff881de000 -     0x7fff881f6ff7  libexpat.1.dylib (12) <C5FE8836-E277-3162-9D15-6735321CB2C6> /usr/lib/libexpat.1.dylib
    0x7fff886cc000 -     0x7fff886d1ff7  libunwind.dylib (35.3) <BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6> /usr/lib/system/libunwind.dylib
    0x7fff886d2000 -     0x7fff88702fff  libsystem_m.dylib (3086.1) <1E12AB45-6D96-36D0-A226-F24D9FB0D9D6> /usr/lib/system/libsystem_m.dylib
    0x7fff88703000 -     0x7fff88703ff7  liblaunch.dylib (559.40.1) <4F81CA3A-D2CE-3030-A89D-42F3DAD7BA8F> /usr/lib/system/liblaunch.dylib
    0x7fff88a59000 -     0x7fff88a66ff7  libbz2.1.0.dylib (36) <2DF83FBC-5C08-39E1-94F5-C28653791B5F> /usr/lib/libbz2.1.0.dylib
    0x7fff88b59000 -     0x7fff88b5fff7  libsystem_networkextension.dylib (167.40.3) <BA58B30B-8377-3B0A-8AE3-4F84021D9D4E> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff88c42000 -     0x7fff88c4dfff  libcommonCrypto.dylib (60061.30.1) <E789748D-F9A7-3CFF-B317-90DF348B1E95> /usr/lib/system/libcommonCrypto.dylib
    0x7fff890b1000 -     0x7fff890b3fff  libsystem_sandbox.dylib (358.20.5) <3F5E973F-C702-31AC-97BC-05F5C195683C> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff890b4000 -     0x7fff890e4ff7  libncurses.5.4.dylib (44) <F09809A4-53B9-3E91-A8FA-D3F584C03AA3> /usr/lib/libncurses.5.4.dylib
    0x7fff893da000 -     0x7fff897e7ff7  libLAPACK.dylib (1128) <F9201AE7-B031-36DB-BCF8-971E994EF7C1> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff898f2000 -     0x7fff89c0dfcf  com.apple.vImage (8.0 - 8.0) <1183FE6A-FDB6-3B3B-928D-50C7909F2308> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff8a2a0000 -     0x7fff8a3b2ff7  libvDSP.dylib (516) <151B3CCB-77D3-3715-A3D0-7C74CD5C7FFC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff8a5a7000 -     0x7fff8a5abfff  libcache.dylib (69) <45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1> /usr/lib/system/libcache.dylib
    0x7fff8a671000 -     0x7fff8a68dff7  libsystem_malloc.dylib (53.30.1) <DDA8928B-CC0D-3255-BD8A-3FEA0982B890> /usr/lib/system/libsystem_malloc.dylib
    0x7fff8a6cf000 -     0x7fff8a6cfff7  libunc.dylib (29) <5676F7EA-C1DF-329F-B006-D2C3022B7D70> /usr/lib/system/libunc.dylib
    0x7fff8a6d0000 -     0x7fff8a749fe7  libcorecrypto.dylib (233.30.1) <5779FFA0-4D9A-3AD4-B7F2-618227621DC8> /usr/lib/system/libcorecrypto.dylib
    0x7fff8a74a000 -     0x7fff8a74bfff  com.apple.TrustEvaluationAgent (2.0 - 25) <2D61A2C3-C83E-3A3F-8EC1-736DBEC250AB> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff8ad71000 -     0x7fff8ad71ff7  libkeymgr.dylib (28) <77845842-DE70-3CC5-BD01-C3D14227CED5> /usr/lib/system/libkeymgr.dylib
    0x7fff8ad72000 -     0x7fff8ad75ff7  libdyld.dylib (353.2.3) <CFBBE540-D503-3AFC-B5D6-644F1E69949B> /usr/lib/system/libdyld.dylib
    0x7fff8aee4000 -     0x7fff8aee6ff7  libutil.dylib (38) <471AD65E-B86E-3C4A-8ABD-B8665A2BCE3F> /usr/lib/libutil.dylib
    0x7fff8b530000 -     0x7fff8b538ffb  libcopyfile.dylib (118.1.2) <0C68D3A6-ACDD-3EF3-991A-CC82C32AB836> /usr/lib/system/libcopyfile.dylib
    0x7fff8c9fc000 -     0x7fff8c9fcfff  com.apple.Accelerate (1.10 - Accelerate 1.10) <2C8AF258-4F11-3BEC-A826-22D7199B3975> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff8ca05000 -     0x7fff8ca4bff7  libauto.dylib (186) <A260789B-D4D8-316A-9490-254767B8A5F1> /usr/lib/libauto.dylib
    0x7fff8cc0c000 -     0x7fff8cc7efff  com.apple.framework.IOKit (2.0.2 - 1050.20.2) <09C0518C-90DF-3FC3-96D6-34D35F72C8EF> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff8d626000 -     0x7fff8d643fff  libsystem_kernel.dylib (2782.40.9) <16AD15EF-3DAE-3F63-9D26-26CCE1920762> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8e005000 -     0x7fff8e006ff7  libsystem_blocks.dylib (65) <9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1> /usr/lib/system/libsystem_blocks.dylib
    0x7fff8e309000 -     0x7fff8e311fff  libsystem_dnssd.dylib (576.30.4) <0CEB5910-843F-315C-A1DE-5D955A48A045> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8e499000 -     0x7fff8e548fe7  libvMisc.dylib (516) <6739E390-46E7-3BFA-9B69-B278562326E6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff8ed15000 -     0x7fff8ed4dfff  libsystem_network.dylib (412.20.3) <6105C134-6722-3C0A-A4CE-5E1261E2E1CC> /usr/lib/system/libsystem_network.dylib
    0x7fff8f0eb000 -     0x7fff8f163ff7  com.apple.SystemConfiguration (1.14.4 - 1.14) <3DFFD7F7-BD23-3F4C-A209-C4A0D99F6573> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff8f3e7000 -     0x7fff8f3ecfff  libsystem_stats.dylib (163.30.2) <D0E96837-3CF6-323D-B711-6DF6F660E530> /usr/lib/system/libsystem_stats.dylib
    0x7fff8f3ee000 -     0x7fff8f3eefff  com.apple.Accelerate.vecLib (3.10 - vecLib 3.10) <9D749502-A228-3BF1-B52F-A182DEEB2C4D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff8f3ef000 -     0x7fff8f419ff7  libdispatch.dylib (442.1.4) <502CF32B-669B-3709-8862-08188225E4F0> /usr/lib/system/libdispatch.dylib
    0x7fff8f41a000 -     0x7fff8f422fff  libsystem_platform.dylib (63) <64E34079-D712-3D66-9CE2-418624A5C040> /usr/lib/system/libsystem_platform.dylib
    0x7fff8f95a000 -     0x7fff8f985fff  libc++abi.dylib (125) <88A22A0F-87C6-3002-BFBA-AC0F2808B8B9> /usr/lib/libc++abi.dylib
    0x7fff8fb41000 -     0x7fff8fb4cff7  libkxld.dylib (2782.40.9) <2ADAE067-78A0-371E-A5A8-1E7C892D193C> /usr/lib/system/libkxld.dylib
    0x7fff9025a000 -     0x7fff90270ff7  libsystem_asl.dylib (267) <F153AC5B-0542-356E-88C8-20A62CA704E2> /usr/lib/system/libsystem_asl.dylib
    0x7fff90e5c000 -     0x7fff90ee8fe7  libsystem_c.dylib (1044.40.1) <F0635E0F-FE4B-34DB-ACF9-A58C1E9070E9> /usr/lib/system/libsystem_c.dylib
    0x7fff9113d000 -     0x7fff914d5ff7  com.apple.CoreFoundation (6.9 - 1153.18) <5C0892B8-9691-341F-9279-CA3A74D59AA0> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff91624000 -     0x7fff9162dfff  libsystem_pthread.dylib (105.40.1) <ACE90967-ECD0-3251-AEEB-461E3C6414F7> /usr/lib/system/libsystem_pthread.dylib
    0x7fff91ebf000 -     0x7fff91ec0fff  libsystem_secinit.dylib (18) <581DAD0F-6B63-3A48-B63B-917AF799ABAA> /usr/lib/system/libsystem_secinit.dylib
    0x7fff91fb8000 -     0x7fff91fb9fff  libDiagnosticMessagesClient.dylib (100) <2EE8E436-5CDC-34C5-9959-5BA218D507FB> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff929e1000 -     0x7fff929e3fff  libsystem_configuration.dylib (699.40.2) <56F94DCE-DBDE-3615-8F07-DE6270D9F8BE> /usr/lib/system/libsystem_configuration.dylib
    0x7fff92a6e000 -     0x7fff92a6fffb  libremovefile.dylib (35) <3485B5F4-6CE8-3C62-8DFD-8736ED6E8531> /usr/lib/system/libremovefile.dylib
    0x7fff92a70000 -     0x7fff92ac4fff  libc++.1.dylib (120) <1B9530FD-989B-3174-BB1C-BDC159501710> /usr/lib/libc++.1.dylib
    0x7fff9301a000 -     0x7fff9301bff3  libSystem.B.dylib (1213) <1866C519-C5F3-3D09-8C17-A8F703664521> /usr/lib/libSystem.B.dylib
    0x7fff93129000 -     0x7fff9312bff7  libsystem_coreservices.dylib (9) <41B7C578-5A53-31C8-A96F-C73E030B0938> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff9312c000 -     0x7fff93133ff7  libcompiler_rt.dylib (35) <BF8FC133-EE10-3DA6-9B90-92039E28678F> /usr/lib/system/libcompiler_rt.dylib
    0x7fff938a7000 -     0x7fff93a35fff  libBLAS.dylib (1128) <497912C1-A98E-3281-BED7-E9C751552F61> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff93a70000 -     0x7fff93a80ff7  libbsm.0.dylib (34) <A3A2E56C-2B65-37C7-B43A-A1F926E1A0BB> /usr/lib/libbsm.0.dylib
    0x7fff93c6e000 -     0x7fff93c96fff  libsystem_info.dylib (459.40.1) <2E16C4B3-A327-3957-9C41-143911979A1E> /usr/lib/system/libsystem_info.dylib
    0x7fff93e5b000 -     0x7fff93e5dfff  libquarantine.dylib (76.20.1) <7AF90041-2768-378A-925A-D83161863642> /usr/lib/system/libquarantine.dylib
    0x7fff949b2000 -     0x7fff94a96fff  libcrypto.0.9.8.dylib (52.40.1) <D123FC57-E2EB-3E08-A51B-6C317EA83EB5> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff95d06000 -     0x7fff95d17ff7  libz.1.dylib (55) <88C7C7DE-04B8-316F-8B74-ACD9F3DE1AA1> /usr/lib/libz.1.dylib
    0x7fff96644000 -     0x7fff96655ff3  libsystem_coretls.dylib (35.40.1) <155DA0A9-2046-332E-BFA3-D7974A51F731> /usr/lib/system/libsystem_coretls.dylib
    0x7fff96670000 -     0x7fff96855ff7  libicucore.A.dylib (531.48) <3CD34752-B1F9-31D2-865D-B5B0F0BE3111> /usr/lib/libicucore.A.dylib
    0x7fff9690c000 -     0x7fff96912fff  libsystem_trace.dylib (72.20.1) <840F5301-B55A-3078-90B9-FEFFD6CD741A> /usr/lib/system/libsystem_trace.dylib
    0x7fff9691a000 -     0x7fff96931ff7  libLinearAlgebra.dylib (1128) <E78CCBAA-A999-3B65-8EC9-06DB15E67C37> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff96994000 -     0x7fff9699dff7  libsystem_notify.dylib (133.1.1) <61147800-F320-3DAA-850C-BADF33855F29> /usr/lib/system/libsystem_notify.dylib
    0x7fff969be000 -     0x7fff96bb846f  libobjc.A.dylib (647) <759E155D-BC42-3D4E-869B-6F57D477177C> /usr/lib/libobjc.A.dylib
    0x7fff97081000 -     0x7fff97086ff7  libmacho.dylib (862) <126CA2ED-DE91-308F-8881-B9DAEC3C63B6> /usr/lib/system/libmacho.dylib
    0x7fff97087000 -     0x7fff97088fff  libffi.dylib (18.1) <0F6C6A4D-1210-3585-8DA1-B8A94B9924A5> /usr/lib/libffi.dylib
    0x7fff9724a000 -     0x7fff97272fff  libxpc.dylib (559.40.1) <5C829202-962E-3744-8B50-00D38CC88E84> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 3
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 3069114
    thread_create: 0
    thread_set_state: 9

VM Region Summary:
ReadOnly portion of Libraries: Total=146.0M resident=114.0M(78%) swapped_out_or_unallocated=31.9M(22%)
Writable regions: Total=323.4M written=292.1M(90%) resident=299.4M(93%) swapped_out=0K(0%) unallocated=23.9M(7%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                            312.3M
MALLOC (admin)                       16K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                        2064K
__DATA                             21.0M
__LINKEDIT                         97.6M
__TEXT                             48.3M
__UNICODE                           552K
shared memory                         4K
===========                      =======
TOTAL                             545.8M

 

From fijall at gmail.com  Thu Sep  3 08:42:14 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 3 Sep 2015 08:42:14 +0200
Subject: [pypy-dev] segmentation fault 11 on OS X
In-Reply-To: <CAOwaaSgbYTbq3UzZi6XsRjQJm7SZrQB+tF4-aPjtD7=3fT=Fxg@mail.gmail.com>
References: <CAOwaaSgbYTbq3UzZi6XsRjQJm7SZrQB+tF4-aPjtD7=3fT=Fxg@mail.gmail.com>
Message-ID: <CAK5idxT-SxUPNEtRGy9=QfZZkUHZ7Y1fgfVF67-UN9qQhATVzg@mail.gmail.com>

that's certainly a bug. Would be very good to get some sort of info.
Can you do PYPYLOG=jit-log-noopt:log as an environment variable and
send us the file "log" (it might be huge)

On Thu, Sep 3, 2015 at 2:58 AM, Christian Walder
<walderchristian at gmail.com> wrote:
> Hello,
>
> I'm running into a segmentation fault on pypy.
>
> Is the attached OS X crash report useful for diagnosing the problem?
>
> I haven't succeeded in making a minimal example of this issue, as it occurs
> in the middle of a complex program, and the same program even runs correctly
> when processing a smaller amount of data.
>
> I'm using the latest nightly build but the same thing happens if I compile
> the latest pypy from git.
>
> Thanks again for pypy.
>
> best,
> Christian
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From lac at openend.se  Fri Sep  4 12:40:25 2015
From: lac at openend.se (Laura Creighton)
Date: Fri, 4 Sep 2015 12:40:25 +0200
Subject: [pypy-dev] W3C web accessibility (WCAG 2.0)
Message-ID: <201509041040.t84AePGN025690@fido.openend.se>

Somebody mailed webmaster wanting to know how Python documentation
faired w.r.t. the WCAG 2.0 Standard. https://www.w3.org/WAI/intro/wcag20

What he really wants to know is how hard is it for blind people to
read the docs, and whether significant whitespace is a problem for
blind python developers. I've referred him to some blind-users mailing
lists so he can ask real blind people those questions, but have we ever
tried to make the Python docs WCAG compliant?  And if we tried, is
there something we can direct interested people to?

Thanks very much,
Laura


From hengha.mao at gmail.com  Tue Sep  8 05:07:30 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 11:07:30 +0800
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
Message-ID: <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>

Unfortunatelly, I still could not make a simple case to reproduce the issue.
However, we observed the same issue happen several times and core dump
generated in the application these days.
I used gdb to show the disassemble:
(gdb) disassemble /rm
Dump of assembler code for function rpyvmprof_f_pypy_rrr:
   0x00007f27ff816b40 <+0>:     41 57   push   %r15
   0x00007f27ff816b42 <+2>:     41 56   push   %r14
   0x00007f27ff816b44 <+4>:     41 55   push   %r13
   0x00007f27ff816b46 <+6>:     41 54   push   %r12
   0x00007f27ff816b48 <+8>:     49 89 d5        mov    %rdx,%r13
   0x00007f27ff816b4b <+11>:    55      push   %rbp
   0x00007f27ff816b4c <+12>:    53      push   %rbx
   0x00007f27ff816b4d <+13>:    49 89 f4        mov    %rsi,%r12
   0x00007f27ff816b50 <+16>:    48 89 fb        mov    %rdi,%rbx
   0x00007f27ff816b53 <+19>:    48 83 ec 18     sub    $0x18,%rsp
   0x00007f27ff816b57 <+23>:    e8 74 ee b6 00  callq  0x7f28003859d0
<pypy_g_stack_check___>
   0x00007f27ff816b5c <+28>:    48 83 3d 1c 66 94 02 00 cmpq
$0x0,0x294661c(%rip)        # 0x7f280215d180 <pypy_g_ExcData>
   0x00007f27ff816b64 <+36>:    0f 85 36 01 00 00       jne
 0x7f27ff816ca0 <rpyvmprof_f_pypy_rrr+352>
   0x00007f27ff816b6a <+42>:    66 48 8d 3d 8e b3 2f 01 data16 lea
0x12fb38e(%rip),%rdi        # 0x7f2800b11f00
   0x00007f27ff816b72 <+50>:    66 66 48 e8 6e ec cf ff data16 data16 callq
0x7f27ff5157e8 <__tls_get_addr at plt>
   0x00007f27ff816b7a <+58>:    f6 43 04 01     testb  $0x1,0x4(%rbx)
   0x00007f27ff816b7e <+62>:    48 8b 68 30     mov    0x30(%rax),%rbp
=> 0x00007f27ff816b82 <+66>:    4c 8b 75 48     mov    0x48(%rbp),%r14
   0x00007f27ff816b86 <+70>:    0f 85 4c 01 00 00       jne
 0x7f27ff816cd8 <rpyvmprof_f_pypy_rrr+408>
   0x00007f27ff816b8c <+76>:    f6 45 04 01     testb  $0x1,0x4(%rbp)
   0x00007f27ff816b90 <+80>:    4c 89 73 18     mov    %r14,0x18(%rbx)
   0x00007f27ff816b94 <+84>:    0f 85 2e 01 00 00       jne
 0x7f27ff816cc8 <rpyvmprof_f_pypy_rrr+392>
   0x00007f27ff816b9a <+90>:    48 89 5d 48     mov    %rbx,0x48(%rbp)
   0x00007f27ff816b9e <+94>:    48 89 de        mov    %rbx,%rsi
   0x00007f27ff816ba1 <+97>:    48 89 ef        mov    %rbp,%rdi
   0x00007f27ff816ba4 <+100>:   e8 f7 ae fd ff  callq  0x7f27ff7f1aa0
<pypy_g_ExecutionContext_call_trace>
   0x00007f27ff816ba9 <+105>:   4c 8b 3d d0 65 94 02    mov
 0x29465d0(%rip),%r15        # 0x7f280215d180 <pypy_g_ExcData>
   0x00007f27ff816bb0 <+112>:   4c 89 ea        mov    %r13,%rdx
   0x00007f27ff816bb3 <+115>:   4d 85 ff        test   %r15,%r15
   0x00007f27ff816bb6 <+118>:   49 89 dd        mov    %rbx,%r13
   0x00007f27ff816bb9 <+121>:   49 89 ee        mov    %rbp,%r14
   0x00007f27ff816bbc <+124>:   0f 84 5e 03 00 00       je
0x7f27ff816f20 <rpyvmprof_f_pypy_rrr+992>
   0x00007f27ff816bc2 <+130>:   48 63 15 63 0e 95 02    movslq
0x2950e63(%rip),%rdx        # 0x7f2802167a2c <pypydtcount>

And the content of regesters:
(gdb) i r
rax            0x468917e8       1183389672
rbx            0x4df8bd0        81759184
rcx            0x7000000000000a60       8070450532247931488
rdx            0x14     20
rsi            0x0      0
rdi            0x7f2800b11f00   139809787027200
rbp            0x0      0x0
rsp            0x4688cc40       0x4688cc40
r8             0x7f2800f57d80   139809791507840
r9             0x100000000      4294967296
r10            0x4df8b80        81759104
r11            0x3472a7aeee     225261891310
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x4688ce50       1183370832
rip            0x7f27ff816b82   0x7f27ff816b82 <rpyvmprof_f_pypy_rrr+66>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x63     99
gs             0x0      0


I searched for "rpyvmprof_f" and found the matched py file in pypy
"rpython/rlib/rvmprof/cintf.py".
Is this the matched code where the issue happened? And what does these code
do?


On Mon, Aug 31, 2015 at 5:41 PM, Yicong Huang <hengha.mao at gmail.com> wrote:

> I am not sure whether it is a bug of pypy.
> I tried extracting the code from the whole programme, but it worked
> correctly.
>
> rpython_startup_code();
> int res = pypy_setup_home("/usr/local/pypy/libpypy-c.so", 1);
> char *b = "import
> sys\nsys.path.insert(0,'job_runtime/lib/python2.7/site-packages/udf')\00010260";
> pypy_execute_source(b);
>
> I will do some further experiments. And if there are any methods to debug,
> I could follow.
>
> Thanks!
>
>
> On Mon, Aug 31, 2015 at 5:15 PM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
>
>> Can you please file a bug on either pypy or vmprof-python?
>>
>> On Mon, Aug 31, 2015 at 11:00 AM, Yicong Huang <hengha.mao at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > We observed the program was cored dump. And examing the core file, we
>> found
>> > the call stack:
>> >
>> > #0  0x00007f26487e6b82 in rpyvmprof_f_pypy_rrr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #1  0x00007f26494a797a in rpyvmprof_t_pypy_rrr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #2  0x00007f26487a1ad4 in
>> > pypy_g_appexec___src__glob___________________import_sys () from
>> > /usr/local/pypy/libpypy-c.so
>> > #3  0x00007f26486f980b in pypy_g.pypy_execute_source () from
>> > /usr/local/pypy/libpypy-c.so
>> > #4  0x00007f26486f9994 in pypy_g_pypy_execute_source_ptr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #5  0x00007f26484e6f42 in pypy_execute_source_ptr () from
>> > /usr/local/pypy/libpypy-c.so
>> > #6  0x00007f26484e6d82 in pypy_execute_source () from
>> > /usr/local/pypy/libpypy-c.so
>> > ...
>> >
>> > And debugging the core file, the char* buffer passed to
>> > pypy_execute_source() was:
>> > (gdb) print pyExBuffer
>> > $1 = "import
>> >
>> sys\nsys.path.insert(0,'job_runtime/lib/python2.7/site-packages/udf')\000/1440989742122"...
>> >
>> > The code was to add a directory to sys.path().
>> > The error was not reproduceable by extracting the piece of code from the
>> > whole programme, and I've no ideas why the segmentation fault happened.
>> >
>> > Does anyone knows what the function "rpyvmprof_f_pypy_rrr ()" did? And
>> are
>> > there any methods to debug and found out the cause?
>> >
>> >
>> >
>> > _______________________________________________
>> > pypy-dev mailing list
>> > pypy-dev at python.org
>> > https://mail.python.org/mailman/listinfo/pypy-dev
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/d9d56b50/attachment.html>

From arigo at tunes.org  Tue Sep  8 08:33:25 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Sep 2015 08:33:25 +0200
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
 <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
Message-ID: <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>

Hi Yicong,

On Tue, Sep 8, 2015 at 5:07 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
>    0x00007f27ff816b6a <+42>:    66 48 8d 3d 8e b3 2f 01 data16 lea
> 0x12fb38e(%rip),%rdi        # 0x7f2800b11f00
>    0x00007f27ff816b72 <+50>:    66 66 48 e8 6e ec cf ff data16 data16 callq
> 0x7f27ff5157e8 <__tls_get_addr at plt>
>    0x00007f27ff816b7e <+62>:    48 8b 68 30     mov    0x30(%rax),%rbp
> => 0x00007f27ff816b82 <+66>:    4c 8b 75 48     mov    0x48(%rbp),%r14

The first two instructions are reading the TLS (thread-local storage);
then the 3rd is mostly probably reading the current executioncontext;
then the 4th is trying to read something out of the
executioncontext---which is NULL at this point.

I may be wrong, but I think that this crash can only occur in these
two cases: if rpython_startup_code() was not called yet (which should
not be the case here), or if the crash occurs in a different thread
and pypy_thread_attach() was not called yet in this thread.

You should be able to check if the program was running multiple
threads by doing "info threads" in gdb at the point of the crash.  If
it is, did you call pypy_init_threads() once from the main thread and
then pypy_thread_attach() in that other thread?


A bient?t,

Armin.

From hengha.mao at gmail.com  Tue Sep  8 09:20:43 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 15:20:43 +0800
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
 <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
 <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>
Message-ID: <CAOEzsGDrc3Byo4ObHBFfLUA-f6VgeVgz-8zUT0ZWMiO7aYmfwg@mail.gmail.com>

Here are the output of gdb "info threads". We didn't call
"pypy_init_threads()" or "pypy_thread_attach()" in the code.
(gdb) info threads
  Id   Target Id         Frame
  132  Thread 0x414ea940 (LWP 32385) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  131  Thread 0x413e9940 (LWP 32384) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  130  Thread 0x4025c940 (LWP 32382) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  129  Thread 0x45f88940 (LWP 32455) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  128  Thread 0x43760940 (LWP 32412) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  127  Thread 0x43861940 (LWP 32413) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  126  Thread 0x4648d940 (LWP 32460) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  125  Thread 0x4365f940 (LWP 32409) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  124  Thread 0x46089940 (LWP 32456) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  123  Thread 0x46f98940 (LWP 32716) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  122  Thread 0x45c85940 (LWP 32452) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  121  Thread 0x41157940 (LWP 32381) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  120  Thread 0x4517a940 (LWP 32440) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  119  Thread 0x47099940 (LWP 32717) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  118  Thread 0x4234c940 (LWP 32390) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  117  Thread 0x4035d940 (LWP 32386) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  116  Thread 0x42a53940 (LWP 32397) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  115  Thread 0x41b6b940 (LWP 32380) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  114  Thread 0x44f78940 (LWP 32438) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  113  Thread 0x4719a940 (LWP 32718) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  112  Thread 0x4224b940 (LWP 32388) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  111  Thread 0x4254e940 (LWP 32392) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  110  Thread 0x4658e940 (LWP 32461) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  109  Thread 0x42b54940 (LWP 32398) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  108  Thread 0x45b84940 (LWP 32451) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  107  Thread 0x4729b940 (LWP 32719) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  106  Thread 0x41e56940 (LWP 32389) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  105  Thread 0x42f58940 (LWP 32402) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  104  Thread 0x4264f940 (LWP 32393) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  103  Thread 0x4668f940 (LWP 32462) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  102  Thread 0x45a83940 (LWP 32449) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  101  Thread 0x4739c940 (LWP 32720) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  100  Thread 0x4315a940 (LWP 32404) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  99   Thread 0x42851940 (LWP 32395) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  98   Thread 0x45881940 (LWP 32447) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  97   Thread 0x4749d940 (LWP 32721) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  96   Thread 0x46b94940 (LWP 32712) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  95   Thread 0x4345d940 (LWP 32407) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  94   Thread 0x46790940 (LWP 2815) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  93   Thread 0x44e77940 (LWP 32437) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  92   Thread 0x4355e940 (LWP 32408) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  91   Thread 0x46c95940 (LWP 32713) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  90   Thread 0x4759e940 (LWP 32722) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  89   Thread 0x44d76940 (LWP 32436) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  88   Thread 0x46d96940 (LWP 32714) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  87   Thread 0x4769f940 (LWP 32723) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  86   Thread 0x44a73940 (LWP 32433) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  85   Thread 0x4214a940 (LWP 32377) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  84   Thread 0x477a0940 (LWP 32724) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  83   Thread 0x46e97940 (LWP 32715) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  82   Thread 0x44972940 (LWP 32432) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  81   Thread 0x478a1940 (LWP 32725) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  80   Thread 0x44871940 (LWP 32431) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  79   Thread 0x479a2940 (LWP 32726) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  78   Thread 0x47aa3940 (LWP 32727) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  77   Thread 0x47ba4940 (LWP 32728) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  76   Thread 0x47ca5940 (LWP 32729) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  75   Thread 0x47fa8940 (LWP 2188) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  74   Thread 0x47da6940 (LWP 32730) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  73   Thread 0x480a9940 (LWP 2189) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  72   Thread 0x4527b940 (LWP 32441) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  71   Thread 0x485ae940 (LWP 2195) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  70   Thread 0x4537c940 (LWP 32442) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  69   Thread 0x4618a940 (LWP 32457) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  68   Thread 0x45982940 (LWP 32448) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  67   Thread 0x484ad940 (LWP 2194) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  66   Thread 0x486af940 (LWP 2196) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  65   Thread 0x4325b940 (LWP 32405) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  64   Thread 0x40ced940 (LWP 32375) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  63   Thread 0x41056940 (LWP 32370) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  62   Thread 0x41ced940 (LWP 32450) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  61   Thread 0x46992940 (LWP 32710) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  60   Thread 0x40772940 (LWP 3069) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  59   Thread 0x483ac940 (LWP 2193) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  58   Thread 0x4628b940 (LWP 32458) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  57   Thread 0x42049940 (LWP 32376) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  56   Thread 0x4048e940 (LWP 32373) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  55   Thread 0x488b1940 (LWP 3071) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  54   Thread 0x46a93940 (LWP 32711) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  53   Thread 0x44770940 (LWP 32430) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  52   Thread 0x42e57940 (LWP 32401) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  51   Thread 0x481aa940 (LWP 2190) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  50   Thread 0x4446d940 (LWP 32425) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  49   Thread 0x43f68940 (LWP 32420) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  48   Thread 0x40dee940 (LWP 32378) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  47   Thread 0x4567f940 (LWP 32445) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  46   Thread 0x43a63940 (LWP 32415) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  45   Thread 0x45e87940 (LWP 32454) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  44   Thread 0x487b0940 (LWP 2197) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  43   Thread 0x41969940 (LWP 32369) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  42   Thread 0x40eef940 (LWP 32379) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  41   Thread 0x41868940 (LWP 32351) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  40   Thread 0x45079940 (LWP 32439) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  39   Thread 0x4638c940 (LWP 32459) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  38   Thread 0x4466f940 (LWP 32429) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  37   Thread 0x4436c940 (LWP 32424) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  36   Thread 0x47ea7940 (LWP 2187) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  35   Thread 0x43059940 (LWP 32403) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  34   Thread 0x4416a940 (LWP 32422) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  33   Thread 0x482ab940 (LWP 2191) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  32   Thread 0x43d66940 (LWP 32418) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  31   Thread 0x42c55940 (LWP 32399) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  30   Thread 0x45d86940 (LWP 32453) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  29   Thread 0x45780940 (LWP 32446) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  28   Thread 0x4547d940 (LWP 32443) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  27   Thread 0x44b74940 (LWP 32434) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  26   Thread 0x4557e940 (LWP 32444) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  25   Thread 0x40a40940 (LWP 32352) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  24   Thread 0x412e8940 (LWP 32350) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  23   Thread 0x44c75940 (LWP 32435) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  22   Thread 0x7f27f911d8c0 (LWP 31988) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  21   Thread 0x40b41940 (LWP 32368) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  20   Thread 0x41c6c940 (LWP 32383) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  19   Thread 0x4456e940 (LWP 32426) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  18   Thread 0x4426b940 (LWP 32423) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  17   Thread 0x43e67940 (LWP 32419) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  16   Thread 0x44069940 (LWP 32421) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  15   Thread 0x43c65940 (LWP 32417) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  14   Thread 0x4244d940 (LWP 32391) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  13   Thread 0x43b64940 (LWP 32416) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  12   Thread 0x43962940 (LWP 32414) 0x000000347320af59 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  11   Thread 0x42d56940 (LWP 32400) 0x000000347320cd91 in sem_wait () from
/lib64/libpthread.so.0
  10   Thread 0x4335c940 (LWP 32406) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  9    Thread 0x42952940 (LWP 32396) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  8    Thread 0x42750940 (LWP 32394) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  7    Thread 0x415eb940 (LWP 32387) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  6    Thread 0x41a6a940 (LWP 32374) 0x0000003472ad4d98 in epoll_wait ()
from /lib64/libc.so.6
  5    Thread 0x4093f940 (LWP 3068) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4    Thread 0x41767940 (LWP 32346) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  3    Thread 0x40671940 (LWP 32345) 0x0000003472a9a901 in nanosleep ()
from /lib64/libc.so.6
  2    Thread 0x4015b940 (LWP 3070) 0x000000347320b1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 1    Thread 0x46891940 (LWP 3067) 0x00007f27ff816b82 in
rpyvmprof_f_pypy_rrr () from /usr/local/pypy/libpypy-c.so



On Tue, Sep 8, 2015 at 2:33 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Yicong,
>
> On Tue, Sep 8, 2015 at 5:07 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
> >    0x00007f27ff816b6a <+42>:    66 48 8d 3d 8e b3 2f 01 data16 lea
> > 0x12fb38e(%rip),%rdi        # 0x7f2800b11f00
> >    0x00007f27ff816b72 <+50>:    66 66 48 e8 6e ec cf ff data16 data16
> callq
> > 0x7f27ff5157e8 <__tls_get_addr at plt>
> >    0x00007f27ff816b7e <+62>:    48 8b 68 30     mov    0x30(%rax),%rbp
> > => 0x00007f27ff816b82 <+66>:    4c 8b 75 48     mov    0x48(%rbp),%r14
>
> The first two instructions are reading the TLS (thread-local storage);
> then the 3rd is mostly probably reading the current executioncontext;
> then the 4th is trying to read something out of the
> executioncontext---which is NULL at this point.
>
> I may be wrong, but I think that this crash can only occur in these
> two cases: if rpython_startup_code() was not called yet (which should
> not be the case here), or if the crash occurs in a different thread
> and pypy_thread_attach() was not called yet in this thread.
>
> You should be able to check if the program was running multiple
> threads by doing "info threads" in gdb at the point of the crash.  If
> it is, did you call pypy_init_threads() once from the main thread and
> then pypy_thread_attach() in that other thread?
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/ee06c194/attachment-0001.html>

From arigo at tunes.org  Tue Sep  8 10:12:24 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Sep 2015 10:12:24 +0200
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAOEzsGDrc3Byo4ObHBFfLUA-f6VgeVgz-8zUT0ZWMiO7aYmfwg@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
 <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
 <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>
 <CAOEzsGDrc3Byo4ObHBFfLUA-f6VgeVgz-8zUT0ZWMiO7aYmfwg@mail.gmail.com>
Message-ID: <CAMSv6X2ADsT=D1S5bYxhaoEnAXpfEYvFc0fJ2ukhFr5DdWOtBw@mail.gmail.com>

Hi,

On Tue, Sep 8, 2015 at 9:20 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
> Here are the output of gdb "info threads". We didn't call
> "pypy_init_threads()" or "pypy_thread_attach()" in the code.

Well, then.  Read again the documentation for these two functions: you
need to call them if your program is going to call Python code in more
than just one thread.


Armin

From hengha.mao at gmail.com  Tue Sep  8 11:44:33 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 17:44:33 +0800
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAMSv6X2ADsT=D1S5bYxhaoEnAXpfEYvFc0fJ2ukhFr5DdWOtBw@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
 <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
 <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>
 <CAOEzsGDrc3Byo4ObHBFfLUA-f6VgeVgz-8zUT0ZWMiO7aYmfwg@mail.gmail.com>
 <CAMSv6X2ADsT=D1S5bYxhaoEnAXpfEYvFc0fJ2ukhFr5DdWOtBw@mail.gmail.com>
Message-ID: <CAOEzsGBEqxrP9rLK+2girG0UQCgJnyBw_uUgb588-cbTR1HQdg@mail.gmail.com>

Great thanks Armin!
I found out we did call python code from different theads.
Here are my understanding, please correct me if I am wrong:

In main thread:
rpython_startup_code();
pypy_init_threads();
res = pypy_setup_home(..);

And in other worker thread, after main thread do the initilization:
pypy_thread_attach();

Will there any problems if main thread exit before other worker thread do
the initilization "pypy_thread_attach()"?





On Tue, Sep 8, 2015 at 4:12 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi,
>
> On Tue, Sep 8, 2015 at 9:20 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
> > Here are the output of gdb "info threads". We didn't call
> > "pypy_init_threads()" or "pypy_thread_attach()" in the code.
>
> Well, then.  Read again the documentation for these two functions: you
> need to call them if your program is going to call Python code in more
> than just one thread.
>
>
> Armin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/b67f557a/attachment.html>

From lac at openend.se  Tue Sep  8 12:36:49 2015
From: lac at openend.se (Laura Creighton)
Date: Tue, 08 Sep 2015 12:36:49 +0200
Subject: [pypy-dev] Python CI and CD support available on Semaphore
	(feedback appreciated) (fwd)
Message-ID: <201509081036.t88Aan0F007515@fido.openend.se>

This showed up on python-list.  Should we try to get them to
make PyPy a supported Python?

Laura


------- Forwarded Message
Subject: Python CI and CD support available on Semaphore (feedback appreciated)
From: =?UTF-8?Q?Filip_Komnenovi=C4=87?= <filip at renderedtext.com>

HI folks, 

We have recently launched Python support on our continuous integration
and deployment service and are looking for communities feedback. If
you're up for it, please give a test drive to our service with your
Python projects and give us your thoughts on what we could further
improve upon.

Official blog post announcing Python support: http://bit.ly/1KYrVsT
Our website: https://semaphoreci.com/

Thanks in advance!

BTW we offer free plans for open source projects and have limited free plans for private projects.
- -- 
https://mail.python.org/mailman/listinfo/python-list

------- End of Forwarded Message

From hengha.mao at gmail.com  Tue Sep  8 13:35:09 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 19:35:09 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
Message-ID: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>

Hi,

Our scenario is we had a main process, and it will create severl worker
threads. Python code is running in worker threads.
>From PyPy document, we should do the following:
In main process:
rpython_startup_code();
pypy_init_threads();
pypy_setup_home(...)

And in worker thread that need to execute python code:
pypy_thread_attach();

However, the problem is the code of the main process is in another module
that we don't have source code access.
So I am thinking could we do PyPy initialize and Finalize in thread itself?
We could run python code in thread one by one.
The process looks like:
Main process create thread pool -> thread 1 initialized Pypy-> thread 1 run
Python code -> thread 1 finish -> thread 1 finalize Pypy -> thread 2
initialized Pypy -> thread 2 run Python code -> thread 2 finish -> thread 2
finialize Pypy ...

For now, if we do initialize again in thread 2, it will hang.
And if we don't do initilize in thread 2, it will core dump by segmatation
fault.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/526bd4f1/attachment.html>

From arigo at tunes.org  Tue Sep  8 13:34:40 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Sep 2015 13:34:40 +0200
Subject: [pypy-dev] Segmentation fault at rpyvmprof_f_pypy_rrr ()
In-Reply-To: <CAOEzsGBEqxrP9rLK+2girG0UQCgJnyBw_uUgb588-cbTR1HQdg@mail.gmail.com>
References: <CAOEzsGB2b9KU6Kkv5Rb+_8O=RNoChmmAFnjqyOL02G97eyTbjw@mail.gmail.com>
 <CAK5idxQTHeEvjQe7j9RUj-nhUv_HjZkV0Py-SgWRgm9xxa7XuQ@mail.gmail.com>
 <CAOEzsGD--OiDC4DmGdHOxkb-cX5u5MdCqX=LSUw+t1TKv--wzA@mail.gmail.com>
 <CAOEzsGCV=C5JssHmKot1mRr05ZtTCzRkkoDV4vmg_gQKyq7ATw@mail.gmail.com>
 <CAMSv6X0Mf017ZGUm3uRtnb5pcsjjBE2J+Ta00JHNr9+XCNOKvg@mail.gmail.com>
 <CAOEzsGDrc3Byo4ObHBFfLUA-f6VgeVgz-8zUT0ZWMiO7aYmfwg@mail.gmail.com>
 <CAMSv6X2ADsT=D1S5bYxhaoEnAXpfEYvFc0fJ2ukhFr5DdWOtBw@mail.gmail.com>
 <CAOEzsGBEqxrP9rLK+2girG0UQCgJnyBw_uUgb588-cbTR1HQdg@mail.gmail.com>
Message-ID: <CAMSv6X1b=pQ2a_OVAhQ5_Bpc3u6XJi2RpBduAQWSpHkD2vGJJg@mail.gmail.com>

Hi,

On Tue, Sep 8, 2015 at 11:44 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
> In main thread:
> rpython_startup_code();
> pypy_init_threads();
> res = pypy_setup_home(..);
>
> And in other worker thread, after main thread do the initilization:
> pypy_thread_attach();

Yes, that's how it should be.

> Will there any problems if main thread exit before other worker thread do
> the initilization "pypy_thread_attach()"?

No, it should not be a problem.

Note that every pypy_thread_attach() call leaks a bit of memory right
now.  If your program has a lot of threads that exit and new threads
that replace them, then you'll really have a leak.  I hope it is not
the case for you.  Otherwise, we need to think about adding some
function like "pypy_thread_detach()"...


A bient?t,

Armin.

From arigo at tunes.org  Tue Sep  8 13:40:03 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Sep 2015 13:40:03 +0200
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
Message-ID: <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>

Hi Yicong,

On Tue, Sep 8, 2015 at 1:35 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> The process looks like:
> Main process create thread pool -> thread 1 initialized Pypy-> thread 1 run
> Python code -> thread 1 finish -> thread 1 finalize Pypy -> thread 2
> initialized Pypy -> thread 2 run Python code -> thread 2 finish -> thread 2
> finialize Pypy ...

It's most probably fine to do the following in the thread:

* first, acquire a lock to make sure there are no race conditions
* if pypy has not been initialized so far:
*     rpython_startup_code();
*     pypy_init_threads();
*     pypy_setup_home(...)
*     any other initialization, like pypy_execute_source_ptr()
* else:
*     pypy_thread_attach();
* release the lock
* call python code


A bient?t,

Armin.

From hengha.mao at gmail.com  Tue Sep  8 13:57:09 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 19:57:09 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
Message-ID: <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>

Hi Armin,

I tried the following in one thread, and it hang in
pypy_execute_source_ptr().
*     rpython_startup_code();
*     pypy_init_threads();
*     pypy_setup_home(...)
*     pypy_execute_source_ptr()

On Tue, Sep 8, 2015 at 7:40 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Yicong,
>
> On Tue, Sep 8, 2015 at 1:35 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> > The process looks like:
> > Main process create thread pool -> thread 1 initialized Pypy-> thread 1
> run
> > Python code -> thread 1 finish -> thread 1 finalize Pypy -> thread 2
> > initialized Pypy -> thread 2 run Python code -> thread 2 finish ->
> thread 2
> > finialize Pypy ...
>
> It's most probably fine to do the following in the thread:
>
> * first, acquire a lock to make sure there are no race conditions
> * if pypy has not been initialized so far:
> *     rpython_startup_code();
> *     pypy_init_threads();
> *     pypy_setup_home(...)
> *     any other initialization, like pypy_execute_source_ptr()
> * else:
> *     pypy_thread_attach();
> * release the lock
> * call python code
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/4c8da4d5/attachment.html>

From lac at openend.se  Tue Sep  8 15:10:30 2015
From: lac at openend.se (Laura Creighton)
Date: Tue, 08 Sep 2015 15:10:30 +0200
Subject: [pypy-dev] Python CI and CD support available on Semaphore
	(feedback appreciated) (fwd)
In-Reply-To: <201509081036.t88Aan0F007515@fido.openend.se>
References: <201509081036.t88Aan0F007515@fido.openend.se>
Message-ID: <201509081310.t88DAUDR013169@fido.openend.se>

In a message of Tue, 08 Sep 2015 12:36:49 +0200, Laura Creighton writes:
>This showed up on python-list.  Should we try to get them to
>make PyPy a supported Python?
>
>Laura

Ha!  PyPy is _already_ a supported system.  And Filip wants to know
if there is anything else he can do to make things easier for
PyPy developers and people who want to test packages against PyPy

Laura

From arigo at tunes.org  Tue Sep  8 15:19:31 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Sep 2015 15:19:31 +0200
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
Message-ID: <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>

Hi Yicong,

On Tue, Sep 8, 2015 at 1:57 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> I tried the following in one thread, and it hang in
> pypy_execute_source_ptr().
> *     rpython_startup_code();
> *     pypy_init_threads();
> *     pypy_setup_home(...)
> *     pypy_execute_source_ptr()

I meant "do whatever you did so far here".  I can't debug a new
problem you get if I only know "it hangs"...


A bient?t,

Armin.

From hengha.mao at gmail.com  Tue Sep  8 16:10:11 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 22:10:11 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
Message-ID: <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>

Hi Armin,

Sorry for I didn't describe the problem clearly.
The issue is well reproducible with the belolw simple piece of the code:

#include ...

int main()
{
 rpython_startup_code();
 pypy_init_threads();
 pypy_setup_home(...);
 pypy_execute_source_ptr("print \'hello\'");
}

It hangs in pypy_execute_source().
And if we remove "pypy_init_threads()", the code works.

On Tue, Sep 8, 2015 at 9:19 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Yicong,
>
> On Tue, Sep 8, 2015 at 1:57 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> > I tried the following in one thread, and it hang in
> > pypy_execute_source_ptr().
> > *     rpython_startup_code();
> > *     pypy_init_threads();
> > *     pypy_setup_home(...)
> > *     pypy_execute_source_ptr()
>
> I meant "do whatever you did so far here".  I can't debug a new
> problem you get if I only know "it hangs"...
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/fc3aab5f/attachment.html>

From hengha.mao at gmail.com  Tue Sep  8 17:00:36 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Tue, 8 Sep 2015 23:00:36 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
Message-ID: <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>

With gdb debug, it blocked at this stack:

#0  0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007ffff6369305 in RPyGilAcquire () from .//../dist/libpypy-c.so
#2  0x00007ffff55bb8ed in pypy_g_pypy_execute_source_ptr () from
.//../dist/libpypy-c.so
#3  0x00007ffff53a8f42 in pypy_execute_source_ptr () from
.//../dist/libpypy-c.so
#4  0x00007ffff53a8d82 in pypy_execute_source () from
.//../dist/libpypy-c.so
#5  0x0000000000400b2e in main () at udf_call_test.c:84


On Tue, Sep 8, 2015 at 10:10 PM, Yicong Huang <hengha.mao at gmail.com> wrote:

> Hi Armin,
>
> Sorry for I didn't describe the problem clearly.
> The issue is well reproducible with the belolw simple piece of the code:
>
> #include ...
>
> int main()
> {
>  rpython_startup_code();
>  pypy_init_threads();
>  pypy_setup_home(...);
>  pypy_execute_source_ptr("print \'hello\'");
> }
>
> It hangs in pypy_execute_source().
> And if we remove "pypy_init_threads()", the code works.
>
> On Tue, Sep 8, 2015 at 9:19 PM, Armin Rigo <arigo at tunes.org> wrote:
>
>> Hi Yicong,
>>
>> On Tue, Sep 8, 2015 at 1:57 PM, Yicong Huang <hengha.mao at gmail.com>
>> wrote:
>> > I tried the following in one thread, and it hang in
>> > pypy_execute_source_ptr().
>> > *     rpython_startup_code();
>> > *     pypy_init_threads();
>> > *     pypy_setup_home(...)
>> > *     pypy_execute_source_ptr()
>>
>> I meant "do whatever you did so far here".  I can't debug a new
>> problem you get if I only know "it hangs"...
>>
>>
>> A bient?t,
>>
>> Armin.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150908/caf613f5/attachment.html>

From fijall at gmail.com  Tue Sep  8 23:05:57 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 8 Sep 2015 23:05:57 +0200
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
 <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
Message-ID: <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>

do you have a minimal example where it doesn't work? did you try a
very minimal program?

On Tue, Sep 8, 2015 at 5:00 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> With gdb debug, it blocked at this stack:
>
> #0  0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00007ffff6369305 in RPyGilAcquire () from .//../dist/libpypy-c.so
> #2  0x00007ffff55bb8ed in pypy_g_pypy_execute_source_ptr () from
> .//../dist/libpypy-c.so
> #3  0x00007ffff53a8f42 in pypy_execute_source_ptr () from
> .//../dist/libpypy-c.so
> #4  0x00007ffff53a8d82 in pypy_execute_source () from
> .//../dist/libpypy-c.so
> #5  0x0000000000400b2e in main () at udf_call_test.c:84
>
>
> On Tue, Sep 8, 2015 at 10:10 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
>>
>> Hi Armin,
>>
>> Sorry for I didn't describe the problem clearly.
>> The issue is well reproducible with the belolw simple piece of the code:
>>
>> #include ...
>>
>> int main()
>> {
>>  rpython_startup_code();
>>  pypy_init_threads();
>>  pypy_setup_home(...);
>>  pypy_execute_source_ptr("print \'hello\'");
>> }
>>
>> It hangs in pypy_execute_source().
>> And if we remove "pypy_init_threads()", the code works.
>>
>> On Tue, Sep 8, 2015 at 9:19 PM, Armin Rigo <arigo at tunes.org> wrote:
>>>
>>> Hi Yicong,
>>>
>>> On Tue, Sep 8, 2015 at 1:57 PM, Yicong Huang <hengha.mao at gmail.com>
>>> wrote:
>>> > I tried the following in one thread, and it hang in
>>> > pypy_execute_source_ptr().
>>> > *     rpython_startup_code();
>>> > *     pypy_init_threads();
>>> > *     pypy_setup_home(...)
>>> > *     pypy_execute_source_ptr()
>>>
>>> I meant "do whatever you did so far here".  I can't debug a new
>>> problem you get if I only know "it hangs"...
>>>
>>>
>>> A bient?t,
>>>
>>> Armin.
>>
>>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From hengha.mao at gmail.com  Wed Sep  9 04:30:54 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Wed, 9 Sep 2015 10:30:54 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
 <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
 <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>
Message-ID: <CAOEzsGBjaj80KFE7H+J++xJ6=8v0XHFw1iT0WG57cszB=U3VOA@mail.gmail.com>

Hi Maciej

The minimal program is as below:
nt main()
{
 rpython_startup_code();
 pypy_init_threads();
 pypy_setup_home(...);
 pypy_execute_source_ptr("print \'hello\'");
}

It hangs in pypy_execute_source().
And if we remove "pypy_init_threads()", the code works.

With gdb debug, it blocked at this stack:

#0  0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007ffff6369305 in RPyGilAcquire () from .//../dist/libpypy-c.so
#2  0x00007ffff55bb8ed in pypy_g_pypy_execute_source_ptr () from
.//../dist/libpypy-c.so
#3  0x00007ffff53a8f42 in pypy_execute_source_ptr () from
.//../dist/libpypy-c.so
#4  0x00007ffff53a8d82 in pypy_execute_source () from
.//../dist/libpypy-c.so
#5  0x0000000000400b2e in main () at udf_call_test.c:84

The alternative method is  we might add a finialze() method to clear all
enviroment, and another thread could initialize again.

On Wed, Sep 9, 2015 at 5:05 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:

> do you have a minimal example where it doesn't work? did you try a
> very minimal program?
>
> On Tue, Sep 8, 2015 at 5:00 PM, Yicong Huang <hengha.mao at gmail.com> wrote:
> > With gdb debug, it blocked at this stack:
> >
> > #0  0x0000003fea40b1c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> > /lib64/libpthread.so.0
> > #1  0x00007ffff6369305 in RPyGilAcquire () from .//../dist/libpypy-c.so
> > #2  0x00007ffff55bb8ed in pypy_g_pypy_execute_source_ptr () from
> > .//../dist/libpypy-c.so
> > #3  0x00007ffff53a8f42 in pypy_execute_source_ptr () from
> > .//../dist/libpypy-c.so
> > #4  0x00007ffff53a8d82 in pypy_execute_source () from
> > .//../dist/libpypy-c.so
> > #5  0x0000000000400b2e in main () at udf_call_test.c:84
> >
> >
> > On Tue, Sep 8, 2015 at 10:10 PM, Yicong Huang <hengha.mao at gmail.com>
> wrote:
> >>
> >> Hi Armin,
> >>
> >> Sorry for I didn't describe the problem clearly.
> >> The issue is well reproducible with the belolw simple piece of the code:
> >>
> >> #include ...
> >>
> >> int main()
> >> {
> >>  rpython_startup_code();
> >>  pypy_init_threads();
> >>  pypy_setup_home(...);
> >>  pypy_execute_source_ptr("print \'hello\'");
> >> }
> >>
> >> It hangs in pypy_execute_source().
> >> And if we remove "pypy_init_threads()", the code works.
> >>
> >> On Tue, Sep 8, 2015 at 9:19 PM, Armin Rigo <arigo at tunes.org> wrote:
> >>>
> >>> Hi Yicong,
> >>>
> >>> On Tue, Sep 8, 2015 at 1:57 PM, Yicong Huang <hengha.mao at gmail.com>
> >>> wrote:
> >>> > I tried the following in one thread, and it hang in
> >>> > pypy_execute_source_ptr().
> >>> > *     rpython_startup_code();
> >>> > *     pypy_init_threads();
> >>> > *     pypy_setup_home(...)
> >>> > *     pypy_execute_source_ptr()
> >>>
> >>> I meant "do whatever you did so far here".  I can't debug a new
> >>> problem you get if I only know "it hangs"...
> >>>
> >>>
> >>> A bient?t,
> >>>
> >>> Armin.
> >>
> >>
> >
> >
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > https://mail.python.org/mailman/listinfo/pypy-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150909/3b20fba6/attachment-0001.html>

From arigo at tunes.org  Wed Sep  9 09:57:43 2015
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 9 Sep 2015 09:57:43 +0200
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGBjaj80KFE7H+J++xJ6=8v0XHFw1iT0WG57cszB=U3VOA@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
 <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
 <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>
 <CAOEzsGBjaj80KFE7H+J++xJ6=8v0XHFw1iT0WG57cszB=U3VOA@mail.gmail.com>
Message-ID: <CAMSv6X0rwaDZAHNX0P4Wd1wL3Rw+VsnE4sJCNpZ-SRT95senfg@mail.gmail.com>

Hi,

On Wed, Sep 9, 2015 at 4:30 AM, Yicong Huang <hengha.mao at gmail.com> wrote:
>  rpython_startup_code();
>  pypy_init_threads();
>  pypy_setup_home(...);
>  pypy_execute_source_ptr("print \'hello\'");

Sorry!  It seems to work if you call pypy_init_threads() after
pypy_setup_home().


Armin

From anto.cuni at gmail.com  Wed Sep  9 11:39:07 2015
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 9 Sep 2015 11:39:07 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: (fijal,
 arigo) merge optresult-unroll - this branch improves warmup by about
In-Reply-To: <20150908131153.2676D1C03B3@cobra.cs.uni-duesseldorf.de>
References: <20150908131153.2676D1C03B3@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAHPg78yKUFpCe8UV-_7SAn7-KdELhnEj_FK8ZnHFNzKGf_6ORQ@mail.gmail.com>

Hi,

On Tue, Sep 8, 2015 at 3:11 PM, fijal <noreply at buildbot.pypy.org> wrote:

> Author: Maciej Fijalkowski <fijall at gmail.com>
> Branch:
> Changeset: r79543:3c45f447b1e3
> Date: 2015-09-08 15:11 +0200
> http://bitbucket.org/pypy/pypy/changeset/3c45f447b1e3/
>
> Log:    (fijal, arigo) merge optresult-unroll - this branch improves warmup
>         by about 20% by changing the underlaying structure of the
>         ResOperations by killing Boxes. It also rewrites unrolling to
>         something (hopefully) a bit saner
>
> diff too long, truncating to 2000 out of 44326 lines
>
> diff --git a/pypy/goal/targetpypystandalone.py
> b/pypy/goal/targetpypystandalone.py
> --- a/pypy/goal/targetpypystandalone.py
> +++ b/pypy/goal/targetpypystandalone.py
> @@ -341,8 +341,8 @@
>
>      def jitpolicy(self, driver):
>          from pypy.module.pypyjit.policy import PyPyJitPolicy
> -        from pypy.module.pypyjit.hooks import pypy_hooks
> -        return PyPyJitPolicy(pypy_hooks)
> +        #from pypy.module.pypyjit.hooks import pypy_hooks
> +        return PyPyJitPolicy()#pypy_hooks)
>
> ?is still intended or just a typo? I suspect this disables
pypyjit?.set_compile_hook etc?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150909/f40980c2/attachment.html>

From fijall at gmail.com  Wed Sep  9 13:13:44 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 9 Sep 2015 13:13:44 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: (fijal,
 arigo) merge optresult-unroll - this branch improves warmup by about
In-Reply-To: <CAHPg78yKUFpCe8UV-_7SAn7-KdELhnEj_FK8ZnHFNzKGf_6ORQ@mail.gmail.com>
References: <20150908131153.2676D1C03B3@cobra.cs.uni-duesseldorf.de>
 <CAHPg78yKUFpCe8UV-_7SAn7-KdELhnEj_FK8ZnHFNzKGf_6ORQ@mail.gmail.com>
Message-ID: <CAK5idxSfwoMWC+HsSsWzu8+8fJfpUGKqJh_pppKpOxNO9RGMVA@mail.gmail.com>

yes, it's not a typo but "not a merge blocker". I'll reenable them
once we decide what to do now

On Wed, Sep 9, 2015 at 11:39 AM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Hi,
>
> On Tue, Sep 8, 2015 at 3:11 PM, fijal <noreply at buildbot.pypy.org> wrote:
>>
>> Author: Maciej Fijalkowski <fijall at gmail.com>
>> Branch:
>> Changeset: r79543:3c45f447b1e3
>> Date: 2015-09-08 15:11 +0200
>> http://bitbucket.org/pypy/pypy/changeset/3c45f447b1e3/
>>
>> Log:    (fijal, arigo) merge optresult-unroll - this branch improves
>> warmup
>>         by about 20% by changing the underlaying structure of the
>>         ResOperations by killing Boxes. It also rewrites unrolling to
>>         something (hopefully) a bit saner
>>
>> diff too long, truncating to 2000 out of 44326 lines
>>
>> diff --git a/pypy/goal/targetpypystandalone.py
>> b/pypy/goal/targetpypystandalone.py
>> --- a/pypy/goal/targetpypystandalone.py
>> +++ b/pypy/goal/targetpypystandalone.py
>> @@ -341,8 +341,8 @@
>>
>>      def jitpolicy(self, driver):
>>          from pypy.module.pypyjit.policy import PyPyJitPolicy
>> -        from pypy.module.pypyjit.hooks import pypy_hooks
>> -        return PyPyJitPolicy(pypy_hooks)
>> +        #from pypy.module.pypyjit.hooks import pypy_hooks
>> +        return PyPyJitPolicy()#pypy_hooks)
>>
> is still intended or just a typo? I suspect this disables
> pypyjit.set_compile_hook etc?
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Thu Sep 10 08:27:10 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 10 Sep 2015 08:27:10 +0200
Subject: [pypy-dev] buildbot seems down
Message-ID: <CAK5idxTgxYskZsfhN8cpckQ3VCyntYZ6kXfX+p1AT93gXeihfQ@mail.gmail.com>

any ideas?

From david.schneider at hhu.de  Thu Sep 10 09:10:43 2015
From: david.schneider at hhu.de (David Schneider)
Date: Thu, 10 Sep 2015 09:10:43 +0200
Subject: [pypy-dev] buildbot seems down
In-Reply-To: <CAK5idxTgxYskZsfhN8cpckQ3VCyntYZ6kXfX+p1AT93gXeihfQ@mail.gmail.com>
References: <CAK5idxTgxYskZsfhN8cpckQ3VCyntYZ6kXfX+p1AT93gXeihfQ@mail.gmail.com>
Message-ID: <8A4164F6-AC88-4BAD-8218-465BF7662479@hhu.de>

> 
> On 10.09.2015, at 08:27, Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> any ideas?

The server had crashed, it is back up again.

David

From phyo.arkarlwin at gmail.com  Fri Sep 11 12:26:17 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Fri, 11 Sep 2015 16:56:17 +0630
Subject: [pypy-dev] use as benchmark pypy vs python if you please
In-Reply-To: <CAMSv6X3Xjx1KTt50MQDAnb0kfxEBUaMzT91eU6WK3Yj2=hqNDw@mail.gmail.com>
References: <CAGGBzXJ0KWSYR_mZj1gjeTCpfiD24ELPHV+freG6tO9vqPE=fA@mail.gmail.com>
 <CAMSv6X3Xjx1KTt50MQDAnb0kfxEBUaMzT91eU6WK3Yj2=hqNDw@mail.gmail.com>
Message-ID: <CA+HjJrgpNey0zxm_pDeURE3X8he3=C=PigTJah2AaEvQNtafgg@mail.gmail.com>

i am just testing a n_queen solver, yesterday with 2.6.1 vs Nodejs.

The code i tested is from https://github.com/chaddotson/puzzles

But pypy is much faster as nqueen grows . And it is 40% faster than nodejs.

In smaller numbers < 10 it is slower but it has to do with JIT Warmup right?



(pypy-current)~/g/nqueen-benchmark >>> python python_n_queens_solver.py 13
N-Queens Found 73712 Solutions in 94.664358s on a 13x13 board
(pypy-current)~/g/nqueen-benchmark >>> pypy python_n_queens_solver.py 13
N-Queens Found 73712 Solutions in 5.488652s on a 13x13 board
(pypy-current)~/g/nqueen-benchmark >>> node javascript_n_queens_solver.js
13

                   ?
N-Queens Found 73712 solutions in 7.112s on a 13x13 board




On Tue, Sep 1, 2015 at 5:58 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Dima,
>
> On Mon, Aug 4, 2014 at 5:04 PM, Dima Tisnek <dimaqq at gmail.com> wrote:
> > Attached is n-queens solver (pardon my naive algorithm), it runs:
> > python 2.7.6: 17s
> > pypy 2.4.0 alpha: 23s
> > same nojit: 32s
> >
> > I've tried similar-looking algorithm for another problem before, and has
> > similar results -- somehow pypy was slower.
> >
> > feel free to investigate / tweak or even use on speed.pypy.org
>
> So, it took us more than one year, but now I finally figured it out.
> The reason it is slower in PyPy is because sets recompute the items'
> hash much more often than in CPython.  I fixed it in the branch
> 'keys_with_hash' (which is just too late for pypy 2.6.1).  Some
> microbenchmarks are 2x or 3x faster now.
>
> In your code, it shows up as the _diff() function, which returns "a -
> b" where a and b are sets of complicated objects.  Actually, there are
> always disjoint sets, so the original code might be a bit buggy :-)
> But the _diff() operation is now twice faster.  I get the following
> times on your nq.py example:
>
>     python 2.7.3: 15.5s
>     pypy 2.6.1 in keys_with_hash: 10.9s
>     same with '--jit off': 20.3s
>
>
> A bient?t,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150911/8c20de01/attachment.html>

From phyo.arkarlwin at gmail.com  Fri Sep 11 13:39:53 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Fri, 11 Sep 2015 18:09:53 +0630
Subject: [pypy-dev] use as benchmark pypy vs python if you please
In-Reply-To: <CA+HjJrgpNey0zxm_pDeURE3X8he3=C=PigTJah2AaEvQNtafgg@mail.gmail.com>
References: <CAGGBzXJ0KWSYR_mZj1gjeTCpfiD24ELPHV+freG6tO9vqPE=fA@mail.gmail.com>
 <CAMSv6X3Xjx1KTt50MQDAnb0kfxEBUaMzT91eU6WK3Yj2=hqNDw@mail.gmail.com>
 <CA+HjJrgpNey0zxm_pDeURE3X8he3=C=PigTJah2AaEvQNtafgg@mail.gmail.com>
Message-ID: <CA+HjJrjKX+FuimQE1Pn+UvMkkXjLq99YvPfyngQoOJs0pJkwtQ@mail.gmail.com>

Forgot to add , they are different code and there is no Set operation , so
might not be related.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150911/bd69ea63/attachment.html>

From hengha.mao at gmail.com  Sat Sep 12 09:07:21 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Sat, 12 Sep 2015 15:07:21 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAMSv6X0rwaDZAHNX0P4Wd1wL3Rw+VsnE4sJCNpZ-SRT95senfg@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
 <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
 <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>
 <CAOEzsGBjaj80KFE7H+J++xJ6=8v0XHFw1iT0WG57cszB=U3VOA@mail.gmail.com>
 <CAMSv6X0rwaDZAHNX0P4Wd1wL3Rw+VsnE4sJCNpZ-SRT95senfg@mail.gmail.com>
Message-ID: <CAOEzsGBz-WsvXXm8KqPh9HXSdeyR_ooZ88eKtbfbEpAy_L+Obw@mail.gmail.com>

With some experiments, we found out the method might have some problems if
thread which call pypy_init_thread() exited before the later thread call
pypy_thread_attach().

Here is the log output: (the thread 6443 call pypy_init_threads() and the
thread 6343 later call pypy_thread_attach() )
PypyEnviron inited with thread, id::6343
PypyEnviron inited with thread attach, id::6443

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f4b9eba7b82 in rpyvmprof_f_pypy_rrr () from
/usr/local/pypy/libpypy-c.so
[Current thread is 1 (Thread 0x46557940 (LWP 6443))]
(gdb) bt
#0  0x00007f4b9eba7b82 in rpyvmprof_f_pypy_rrr () from
/usr/local/pypy/libpypy-c.so
#1  0x00007f4b9f86897a in rpyvmprof_t_pypy_rrr () from
/usr/local/pypy/libpypy-c.so
#2  0x00007f4b9eb62ad4 in
pypy_g_appexec___src__glob___________________import_sys () from
/usr/local/pypy/libpypy-c.so
#3  0x00007f4b9eaba80b in pypy_g.pypy_execute_source () from
/usr/local/pypy/libpypy-c.so
#4  0x00007f4b9eaba994 in pypy_g_pypy_execute_source_ptr () from
/usr/local/pypy/libpypy-c.so
#5  0x00007f4b9e8a7f42 in pypy_execute_source_ptr () from
/usr/local/pypy/libpypy-c.so
#6  0x00007f4b9e8a7d82 in pypy_execute_source () from
/usr/local/pypy/libpypy-c.so

The output of asm looks quite similar as previous.

Dump of assembler code for function rpyvmprof_f_pypy_rrr:
   0x00007f4b9eba7b40 <+0>:     41 57   push   %r15
   0x00007f4b9eba7b42 <+2>:     41 56   push   %r14
   0x00007f4b9eba7b44 <+4>:     41 55   push   %r13
   0x00007f4b9eba7b46 <+6>:     41 54   push   %r12
   0x00007f4b9eba7b48 <+8>:     49 89 d5        mov    %rdx,%r13
   0x00007f4b9eba7b4b <+11>:    55      push   %rbp
   0x00007f4b9eba7b4c <+12>:    53      push   %rbx
   0x00007f4b9eba7b4d <+13>:    49 89 f4        mov    %rsi,%r12
   0x00007f4b9eba7b50 <+16>:    48 89 fb        mov    %rdi,%rbx
   0x00007f4b9eba7b53 <+19>:    48 83 ec 18     sub    $0x18,%rsp
   0x00007f4b9eba7b57 <+23>:    e8 74 ee b6 00  callq  0x7f4b9f7169d0
<pypy_g_stack_check___>
   0x00007f4b9eba7b5c <+28>:    48 83 3d 1c 66 94 02 00 cmpq
$0x0,0x294661c(%rip)        # 0x7f4ba14ee180 <pypy_g_ExcData>
   0x00007f4b9eba7b64 <+36>:    0f 85 36 01 00 00       jne
 0x7f4b9eba7ca0 <rpyvmprof_f_pypy_rrr+352>
   0x00007f4b9eba7b6a <+42>:    66 48 8d 3d 8e b3 2f 01 data16 lea
0x12fb38e(%rip),%rdi        # 0x7f4b9fea2f00
   0x00007f4b9eba7b72 <+50>:    66 66 48 e8 6e ec cf ff data16 data16 callq
0x7f4b9e8a67e8 <__tls_get_addr at plt>
   0x00007f4b9eba7b7a <+58>:    f6 43 04 01     testb  $0x1,0x4(%rbx)
   0x00007f4b9eba7b7e <+62>:    48 8b 68 30     mov    0x30(%rax),%rbp
=> 0x00007f4b9eba7b82 <+66>:    4c 8b 75 48     mov    0x48(%rbp),%r14
   0x00007f4b9eba7b86 <+70>:    0f 85 4c 01 00 00       jne
 0x7f4b9eba7cd8 <rpyvmprof_f_pypy_rrr+408>
   0x00007f4b9eba7b8c <+76>:    f6 45 04 01     testb  $0x1,0x4(%rbp)
   0x00007f4b9eba7b90 <+80>:    4c 89 73 18     mov    %r14,0x18(%rbx)
   0x00007f4b9eba7b94 <+84>:    0f 85 2e 01 00 00       jne
 0x7f4b9eba7cc8 <rpyvmprof_f_pypy_rrr+392>
   0x00007f4b9eba7b9a <+90>:    48 89 5d 48     mov    %rbx,0x48(%rbp)
   0x00007f4b9eba7b9e <+94>:    48 89 de        mov    %rbx,%rsi
   0x00007f4b9eba7ba1 <+97>:    48 89 ef        mov    %rbp,%rdi

And with "info thread", we confirmed that the thread 6343 was no longer
existed:

(gdb) info thread
  Id   Target Id         Frame
  121  Thread 0x4584a940 (LWP 6306) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  120  Thread 0x45648940 (LWP 6302) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  119  Thread 0x43527940 (LWP 6261) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  118  Thread 0x41c32940 (LWP 6219) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  117  Thread 0x43224940 (LWP 6258) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  116  Thread 0x45042940 (LWP 6295) 0x00007f4ba1f55901 in nanosleep () from
/lib64/libc.so.6
  115  Thread 0x45a4c940 (LWP 6309) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  114  Thread 0x41b31940 (LWP 6218) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  113  Thread 0x43628940 (LWP 6262) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  112  Thread 0x42f21940 (LWP 6255) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  111  Thread 0x42416940 (LWP 6244) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  110  Thread 0x40b9a940 (LWP 6227) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  109  Thread 0x44335940 (LWP 6277) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  108  Thread 0x44436940 (LWP 6278) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  107  Thread 0x42618940 (LWP 6246) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  106  Thread 0x44e40940 (LWP 6293) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  105  Thread 0x40a99940 (LWP 6217) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  104  Thread 0x4121f940 (LWP 6243) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  103  Thread 0x402a3940 (LWP 6240) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  102  Thread 0x43729940 (LWP 6263) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  101  Thread 0x42c1e940 (LWP 6252) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  100  Thread 0x42315940 (LWP 6241) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  99   Thread 0x42214940 (LWP 6239) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  98   Thread 0x40992940 (LWP 6229) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  97   Thread 0x44234940 (LWP 6276) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  96   Thread 0x44537940 (LWP 6279) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  95   Thread 0x4281a940 (LWP 6248) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  94   Thread 0x44d3f940 (LWP 6292) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  93   Thread 0x4382a940 (LWP 6266) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  92   Thread 0x4291b940 (LWP 6249) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  91   Thread 0x44638940 (LWP 6280) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  90   Thread 0x4101d940 (LWP 6231) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  89   Thread 0x44133940 (LWP 6275) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  88   Thread 0x44c3e940 (LWP 6291) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  87   Thread 0x47466940 (LWP 6434) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  86   Thread 0x43a2c940 (LWP 6268) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  85   Thread 0x47b6d940 (LWP 6441) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  84   Thread 0x46c5e940 (LWP 6426) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  83   Thread 0x47062940 (LWP 6430) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  82   Thread 0x42a1c940 (LWP 6250) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  81   Thread 0x41d33940 (LWP 6237) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  80   Thread 0x403a4940 (LWP 6283) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  79   Thread 0x42012940 (LWP 6233) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  78   Thread 0x43f31940 (LWP 6273) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  77   Thread 0x47567940 (LWP 6435) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  76   Thread 0x4483a940 (LWP 6287) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  75   Thread 0x43c2e940 (LWP 6270) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  74   Thread 0x46d5f940 (LWP 6427) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  73   Thread 0x4786a940 (LWP 6438) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  72   Thread 0x46b5d940 (LWP 6425) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  71   Thread 0x47264940 (LWP 6432) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  70   Thread 0x46f61940 (LWP 6429) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  69   Thread 0x44739940 (LWP 6284) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  68   Thread 0x43426940 (LWP 6260) 0x00007f4ba1f55901 in nanosleep () from
/lib64/libc.so.6
  67   Thread 0x41e4a940 (LWP 6235) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  66   Thread 0x42b1d940 (LWP 6251) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
---Type <return> to continue, or q <return> to quit---
  65   Thread 0x47668940 (LWP 6436) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  64   Thread 0x45e50940 (LWP 6313) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  63   Thread 0x46658940 (LWP 6447) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  62   Thread 0x45345940 (LWP 6298) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  61   Thread 0x43d2f940 (LWP 6271) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  60   Thread 0x46e60940 (LWP 6428) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  59   Thread 0x4796b940 (LWP 6439) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  58   Thread 0x46a5c940 (LWP 6423) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  57   Thread 0x47365940 (LWP 6433) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  56   Thread 0x46355940 (LWP 6318) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  55   Thread 0x404a5940 (LWP 6285) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  54   Thread 0x43123940 (LWP 6257) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  53   Thread 0x45547940 (LWP 6300) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  52   Thread 0x47769940 (LWP 6437) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  51   Thread 0x45749940 (LWP 6304) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  50   Thread 0x43e30940 (LWP 6272) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  49   Thread 0x4685a940 (LWP 6421) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  48   Thread 0x416e8940 (LWP 6445) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  47   Thread 0x47a6c940 (LWP 6440) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  46   Thread 0x406b6940 (LWP 6242) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  45   Thread 0x46456940 (LWP 6319) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  44   Thread 0x405a6940 (LWP 6286) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  43   Thread 0x45244940 (LWP 6297) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  42   Thread 0x43022940 (LWP 6256) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  41   Thread 0x44032940 (LWP 6274) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  40   Thread 0x4695b940 (LWP 6422) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  39   Thread 0x42113940 (LWP 6238) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  38   Thread 0x46254940 (LWP 6317) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  37   Thread 0x47163940 (LWP 6431) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  36   Thread 0x45143940 (LWP 6296) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  35   Thread 0x41ecb940 (LWP 6307) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  34   Thread 0x45b4d940 (LWP 6310) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  33   Thread 0x44b3d940 (LWP 6290) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  32   Thread 0x43b2d940 (LWP 6269) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  31   Thread 0x46759940 (LWP 6420) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  30   Thread 0x42719940 (LWP 6247) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  29   Thread 0x41485940 (LWP 6223) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  28   Thread 0x417e9940 (LWP 6234) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  27   Thread 0x46153940 (LWP 6316) 0x00007f4ba1f55901 in nanosleep () from
/lib64/libc.so.6
  26   Thread 0x40f1c940 (LWP 6230) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  25   Thread 0x45f51940 (LWP 6314) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  24   Thread 0x45d4f940 (LWP 6312) 0x00007f4ba1f55901 in nanosleep () from
/lib64/libc.so.6
  23   Thread 0x40d1a940 (LWP 6212) 0x00007f4ba1f55901 in nanosleep () from
/lib64/libc.so.6
  22   Thread 0x44f41940 (LWP 6294) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  21   Thread 0x46052940 (LWP 6315) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  20   Thread 0x45c4e940 (LWP 6311) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  19   Thread 0x4594b940 (LWP 6308) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  18   Thread 0x45446940 (LWP 6299) 0x00007f4ba3c5bf59 in
pthread_cond_wait@@GLIBC_2.3.2
() from /lib64/libpthread.so.0
  17   Thread 0x4493b940 (LWP 6288) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  16   Thread 0x44a3c940 (LWP 6289) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  15   Thread 0x42e20940 (LWP 6254) 0x00007f4ba3c5dd91 in sem_wait () from
/lib64/libpthread.so.0
  14   Thread 0x4392b940 (LWP 6267) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  13   Thread 0x43325940 (LWP 6259) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  12   Thread 0x42517940 (LWP 6245) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  11   Thread 0x42d1f940 (LWP 6253) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  10   Thread 0x418ea940 (LWP 6236) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  9    Thread 0x41384940 (LWP 6213) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  8    Thread 0x4111e940 (LWP 6232) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  7    Thread 0x41586940 (LWP 6224) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  6    Thread 0x40854940 (LWP 6222) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  5    Thread 0x4014e940 (LWP 6228) 0x00007f4ba1f8fd98 in epoll_wait ()
from /lib64/libc.so.6
  4    Thread 0x7f4ba9c048b0 (LWP 6056) 0x00007f4ba1f55901 in nanosleep ()
from /lib64/libc.so.6
  3    Thread 0x41a30940 (LWP 6446) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  2    Thread 0x40e1b940 (LWP 6444) 0x00007f4ba3c5c1c0 in
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 1    Thread 0x46557940 (LWP 6443) 0x00007f4b9eba7b82 in
rpyvmprof_f_pypy_rrr () from /usr/local/pypy/libpypy-c.so
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150912/9c35fceb/attachment-0001.html>

From fijall at gmail.com  Sun Sep 13 09:08:48 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 13 Sep 2015 09:08:48 +0200
Subject: [pypy-dev] use as benchmark pypy vs python if you please
In-Reply-To: <CA+HjJrgpNey0zxm_pDeURE3X8he3=C=PigTJah2AaEvQNtafgg@mail.gmail.com>
References: <CAGGBzXJ0KWSYR_mZj1gjeTCpfiD24ELPHV+freG6tO9vqPE=fA@mail.gmail.com>
 <CAMSv6X3Xjx1KTt50MQDAnb0kfxEBUaMzT91eU6WK3Yj2=hqNDw@mail.gmail.com>
 <CA+HjJrgpNey0zxm_pDeURE3X8he3=C=PigTJah2AaEvQNtafgg@mail.gmail.com>
Message-ID: <CAK5idxTZh+Fd6nWcQL=5oFG-eJw0rjm6vqdutoepcL-TBFjtcQ@mail.gmail.com>

PyPy warmup is quite slow, so very very likely

On Fri, Sep 11, 2015 at 12:26 PM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> i am just testing a n_queen solver, yesterday with 2.6.1 vs Nodejs.
>
> The code i tested is from https://github.com/chaddotson/puzzles
>
> But pypy is much faster as nqueen grows . And it is 40% faster than nodejs.
>
> In smaller numbers < 10 it is slower but it has to do with JIT Warmup right?
>
>
>
> (pypy-current)~/g/nqueen-benchmark >>> python python_n_queens_solver.py 13
> N-Queens Found 73712 Solutions in 94.664358s on a 13x13 board
> (pypy-current)~/g/nqueen-benchmark >>> pypy python_n_queens_solver.py 13
> N-Queens Found 73712 Solutions in 5.488652s on a 13x13 board
> (pypy-current)~/g/nqueen-benchmark >>> node javascript_n_queens_solver.js 13
> ?
> N-Queens Found 73712 solutions in 7.112s on a 13x13 board
>
>
>
>
> On Tue, Sep 1, 2015 at 5:58 PM, Armin Rigo <arigo at tunes.org> wrote:
>>
>> Hi Dima,
>>
>> On Mon, Aug 4, 2014 at 5:04 PM, Dima Tisnek <dimaqq at gmail.com> wrote:
>> > Attached is n-queens solver (pardon my naive algorithm), it runs:
>> > python 2.7.6: 17s
>> > pypy 2.4.0 alpha: 23s
>> > same nojit: 32s
>> >
>> > I've tried similar-looking algorithm for another problem before, and has
>> > similar results -- somehow pypy was slower.
>> >
>> > feel free to investigate / tweak or even use on speed.pypy.org
>>
>> So, it took us more than one year, but now I finally figured it out.
>> The reason it is slower in PyPy is because sets recompute the items'
>> hash much more often than in CPython.  I fixed it in the branch
>> 'keys_with_hash' (which is just too late for pypy 2.6.1).  Some
>> microbenchmarks are 2x or 3x faster now.
>>
>> In your code, it shows up as the _diff() function, which returns "a -
>> b" where a and b are sets of complicated objects.  Actually, there are
>> always disjoint sets, so the original code might be a bit buggy :-)
>> But the _diff() operation is now twice faster.  I get the following
>> times on your nq.py example:
>>
>>     python 2.7.3: 15.5s
>>     pypy 2.6.1 in keys_with_hash: 10.9s
>>     same with '--jit off': 20.3s
>>
>>
>> A bient?t,
>>
>> Armin.
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From hengha.mao at gmail.com  Sun Sep 13 18:16:43 2015
From: hengha.mao at gmail.com (Yicong Huang)
Date: Mon, 14 Sep 2015 00:16:43 +0800
Subject: [pypy-dev] Could PyPy have finalize() method or could be
 initialized thread by thread ?
In-Reply-To: <CAOEzsGBz-WsvXXm8KqPh9HXSdeyR_ooZ88eKtbfbEpAy_L+Obw@mail.gmail.com>
References: <CAOEzsGD_B05S0pPs9uj62jc8cYqz=RDcZhp6QR9XhSssc3bM4A@mail.gmail.com>
 <CAMSv6X0-ODjYd5gUF5Q-FAL1Og_iS0JK9jS3RqGjoqSXev_24w@mail.gmail.com>
 <CAOEzsGAW9Mt0pTj99zsbtDgRY1ui8hjGPMav8HZrnj43adhWvg@mail.gmail.com>
 <CAMSv6X0dhsuFGJ0fopjiKen6aXy9JB4Wd9fHPUhQxCVk-ftEoA@mail.gmail.com>
 <CAOEzsGAkLWkEY6+5sukcGgh=TOPvyyU6vQi-7fOMZM+mcG1=qQ@mail.gmail.com>
 <CAOEzsGATR+n9-R8ekw_QQ7zy8EO8FnvfNU7pjrEnMeDRexcfuw@mail.gmail.com>
 <CAK5idxQPWdbHry4zWZ1VqUtU+-9xJCNd6BMRZUBiu49TCp+uhQ@mail.gmail.com>
 <CAOEzsGBjaj80KFE7H+J++xJ6=8v0XHFw1iT0WG57cszB=U3VOA@mail.gmail.com>
 <CAMSv6X0rwaDZAHNX0P4Wd1wL3Rw+VsnE4sJCNpZ-SRT95senfg@mail.gmail.com>
 <CAOEzsGBz-WsvXXm8KqPh9HXSdeyR_ooZ88eKtbfbEpAy_L+Obw@mail.gmail.com>
Message-ID: <CAOEzsGCqpUL381V3oVGkc3pvS2creufDuz1VkVm7sgz9WHVr+A@mail.gmail.com>

Finally, we found out in this case we also need to call pypy_setup_home()
in the thread attach.

In 1st thread:
rpython_startup_code();
pypy_setup_home("..", 1);
pypy_init_threads();

And in the following threads:
pypy_setup_home("..", 1);
pypy_thread_attach();



On Sat, Sep 12, 2015 at 3:07 PM, Yicong Huang <hengha.mao at gmail.com> wrote:

> With some experiments, we found out the method might have some problems if
> thread which call pypy_init_thread() exited before the later thread call
> pypy_thread_attach().
>
> Here is the log output: (the thread 6443 call pypy_init_threads() and the
> thread 6343 later call pypy_thread_attach() )
> PypyEnviron inited with thread, id::6343
> PypyEnviron inited with thread attach, id::6443
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007f4b9eba7b82 in rpyvmprof_f_pypy_rrr () from
> /usr/local/pypy/libpypy-c.so
> [Current thread is 1 (Thread 0x46557940 (LWP 6443))]
> (gdb) bt
> #0  0x00007f4b9eba7b82 in rpyvmprof_f_pypy_rrr () from
> /usr/local/pypy/libpypy-c.so
> #1  0x00007f4b9f86897a in rpyvmprof_t_pypy_rrr () from
> /usr/local/pypy/libpypy-c.so
> #2  0x00007f4b9eb62ad4 in
> pypy_g_appexec___src__glob___________________import_sys () from
> /usr/local/pypy/libpypy-c.so
> #3  0x00007f4b9eaba80b in pypy_g.pypy_execute_source () from
> /usr/local/pypy/libpypy-c.so
> #4  0x00007f4b9eaba994 in pypy_g_pypy_execute_source_ptr () from
> /usr/local/pypy/libpypy-c.so
> #5  0x00007f4b9e8a7f42 in pypy_execute_source_ptr () from
> /usr/local/pypy/libpypy-c.so
> #6  0x00007f4b9e8a7d82 in pypy_execute_source () from
> /usr/local/pypy/libpypy-c.so
>
> The output of asm looks quite similar as previous.
>
> Dump of assembler code for function rpyvmprof_f_pypy_rrr:
>    0x00007f4b9eba7b40 <+0>:     41 57   push   %r15
>    0x00007f4b9eba7b42 <+2>:     41 56   push   %r14
>    0x00007f4b9eba7b44 <+4>:     41 55   push   %r13
>    0x00007f4b9eba7b46 <+6>:     41 54   push   %r12
>    0x00007f4b9eba7b48 <+8>:     49 89 d5        mov    %rdx,%r13
>    0x00007f4b9eba7b4b <+11>:    55      push   %rbp
>    0x00007f4b9eba7b4c <+12>:    53      push   %rbx
>    0x00007f4b9eba7b4d <+13>:    49 89 f4        mov    %rsi,%r12
>    0x00007f4b9eba7b50 <+16>:    48 89 fb        mov    %rdi,%rbx
>    0x00007f4b9eba7b53 <+19>:    48 83 ec 18     sub    $0x18,%rsp
>    0x00007f4b9eba7b57 <+23>:    e8 74 ee b6 00  callq  0x7f4b9f7169d0
> <pypy_g_stack_check___>
>    0x00007f4b9eba7b5c <+28>:    48 83 3d 1c 66 94 02 00 cmpq
> $0x0,0x294661c(%rip)        # 0x7f4ba14ee180 <pypy_g_ExcData>
>    0x00007f4b9eba7b64 <+36>:    0f 85 36 01 00 00       jne
>  0x7f4b9eba7ca0 <rpyvmprof_f_pypy_rrr+352>
>    0x00007f4b9eba7b6a <+42>:    66 48 8d 3d 8e b3 2f 01 data16 lea
> 0x12fb38e(%rip),%rdi        # 0x7f4b9fea2f00
>    0x00007f4b9eba7b72 <+50>:    66 66 48 e8 6e ec cf ff data16 data16
> callq 0x7f4b9e8a67e8 <__tls_get_addr at plt>
>    0x00007f4b9eba7b7a <+58>:    f6 43 04 01     testb  $0x1,0x4(%rbx)
>    0x00007f4b9eba7b7e <+62>:    48 8b 68 30     mov    0x30(%rax),%rbp
> => 0x00007f4b9eba7b82 <+66>:    4c 8b 75 48     mov    0x48(%rbp),%r14
>    0x00007f4b9eba7b86 <+70>:    0f 85 4c 01 00 00       jne
>  0x7f4b9eba7cd8 <rpyvmprof_f_pypy_rrr+408>
>    0x00007f4b9eba7b8c <+76>:    f6 45 04 01     testb  $0x1,0x4(%rbp)
>    0x00007f4b9eba7b90 <+80>:    4c 89 73 18     mov    %r14,0x18(%rbx)
>    0x00007f4b9eba7b94 <+84>:    0f 85 2e 01 00 00       jne
>  0x7f4b9eba7cc8 <rpyvmprof_f_pypy_rrr+392>
>    0x00007f4b9eba7b9a <+90>:    48 89 5d 48     mov    %rbx,0x48(%rbp)
>    0x00007f4b9eba7b9e <+94>:    48 89 de        mov    %rbx,%rsi
>    0x00007f4b9eba7ba1 <+97>:    48 89 ef        mov    %rbp,%rdi
>
> And with "info thread", we confirmed that the thread 6343 was no longer
> existed:
>
> (gdb) info thread
>   Id   Target Id         Frame
>   121  Thread 0x4584a940 (LWP 6306) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   120  Thread 0x45648940 (LWP 6302) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   119  Thread 0x43527940 (LWP 6261) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   118  Thread 0x41c32940 (LWP 6219) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   117  Thread 0x43224940 (LWP 6258) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   116  Thread 0x45042940 (LWP 6295) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   115  Thread 0x45a4c940 (LWP 6309) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   114  Thread 0x41b31940 (LWP 6218) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   113  Thread 0x43628940 (LWP 6262) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   112  Thread 0x42f21940 (LWP 6255) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   111  Thread 0x42416940 (LWP 6244) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   110  Thread 0x40b9a940 (LWP 6227) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   109  Thread 0x44335940 (LWP 6277) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   108  Thread 0x44436940 (LWP 6278) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   107  Thread 0x42618940 (LWP 6246) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   106  Thread 0x44e40940 (LWP 6293) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   105  Thread 0x40a99940 (LWP 6217) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   104  Thread 0x4121f940 (LWP 6243) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   103  Thread 0x402a3940 (LWP 6240) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   102  Thread 0x43729940 (LWP 6263) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   101  Thread 0x42c1e940 (LWP 6252) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   100  Thread 0x42315940 (LWP 6241) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   99   Thread 0x42214940 (LWP 6239) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   98   Thread 0x40992940 (LWP 6229) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   97   Thread 0x44234940 (LWP 6276) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   96   Thread 0x44537940 (LWP 6279) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   95   Thread 0x4281a940 (LWP 6248) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   94   Thread 0x44d3f940 (LWP 6292) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   93   Thread 0x4382a940 (LWP 6266) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   92   Thread 0x4291b940 (LWP 6249) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   91   Thread 0x44638940 (LWP 6280) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   90   Thread 0x4101d940 (LWP 6231) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   89   Thread 0x44133940 (LWP 6275) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   88   Thread 0x44c3e940 (LWP 6291) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   87   Thread 0x47466940 (LWP 6434) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   86   Thread 0x43a2c940 (LWP 6268) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   85   Thread 0x47b6d940 (LWP 6441) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   84   Thread 0x46c5e940 (LWP 6426) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   83   Thread 0x47062940 (LWP 6430) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   82   Thread 0x42a1c940 (LWP 6250) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   81   Thread 0x41d33940 (LWP 6237) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   80   Thread 0x403a4940 (LWP 6283) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   79   Thread 0x42012940 (LWP 6233) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   78   Thread 0x43f31940 (LWP 6273) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   77   Thread 0x47567940 (LWP 6435) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   76   Thread 0x4483a940 (LWP 6287) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   75   Thread 0x43c2e940 (LWP 6270) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   74   Thread 0x46d5f940 (LWP 6427) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   73   Thread 0x4786a940 (LWP 6438) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   72   Thread 0x46b5d940 (LWP 6425) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   71   Thread 0x47264940 (LWP 6432) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   70   Thread 0x46f61940 (LWP 6429) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   69   Thread 0x44739940 (LWP 6284) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   68   Thread 0x43426940 (LWP 6260) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   67   Thread 0x41e4a940 (LWP 6235) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   66   Thread 0x42b1d940 (LWP 6251) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
> ---Type <return> to continue, or q <return> to quit---
>   65   Thread 0x47668940 (LWP 6436) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   64   Thread 0x45e50940 (LWP 6313) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   63   Thread 0x46658940 (LWP 6447) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   62   Thread 0x45345940 (LWP 6298) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   61   Thread 0x43d2f940 (LWP 6271) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   60   Thread 0x46e60940 (LWP 6428) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   59   Thread 0x4796b940 (LWP 6439) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   58   Thread 0x46a5c940 (LWP 6423) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   57   Thread 0x47365940 (LWP 6433) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   56   Thread 0x46355940 (LWP 6318) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   55   Thread 0x404a5940 (LWP 6285) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   54   Thread 0x43123940 (LWP 6257) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   53   Thread 0x45547940 (LWP 6300) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   52   Thread 0x47769940 (LWP 6437) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   51   Thread 0x45749940 (LWP 6304) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   50   Thread 0x43e30940 (LWP 6272) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   49   Thread 0x4685a940 (LWP 6421) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   48   Thread 0x416e8940 (LWP 6445) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   47   Thread 0x47a6c940 (LWP 6440) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   46   Thread 0x406b6940 (LWP 6242) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   45   Thread 0x46456940 (LWP 6319) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   44   Thread 0x405a6940 (LWP 6286) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   43   Thread 0x45244940 (LWP 6297) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   42   Thread 0x43022940 (LWP 6256) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   41   Thread 0x44032940 (LWP 6274) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   40   Thread 0x4695b940 (LWP 6422) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   39   Thread 0x42113940 (LWP 6238) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   38   Thread 0x46254940 (LWP 6317) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   37   Thread 0x47163940 (LWP 6431) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   36   Thread 0x45143940 (LWP 6296) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   35   Thread 0x41ecb940 (LWP 6307) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   34   Thread 0x45b4d940 (LWP 6310) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   33   Thread 0x44b3d940 (LWP 6290) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   32   Thread 0x43b2d940 (LWP 6269) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   31   Thread 0x46759940 (LWP 6420) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   30   Thread 0x42719940 (LWP 6247) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   29   Thread 0x41485940 (LWP 6223) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   28   Thread 0x417e9940 (LWP 6234) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   27   Thread 0x46153940 (LWP 6316) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   26   Thread 0x40f1c940 (LWP 6230) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   25   Thread 0x45f51940 (LWP 6314) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   24   Thread 0x45d4f940 (LWP 6312) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   23   Thread 0x40d1a940 (LWP 6212) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   22   Thread 0x44f41940 (LWP 6294) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   21   Thread 0x46052940 (LWP 6315) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   20   Thread 0x45c4e940 (LWP 6311) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   19   Thread 0x4594b940 (LWP 6308) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   18   Thread 0x45446940 (LWP 6299) 0x00007f4ba3c5bf59 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   17   Thread 0x4493b940 (LWP 6288) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   16   Thread 0x44a3c940 (LWP 6289) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   15   Thread 0x42e20940 (LWP 6254) 0x00007f4ba3c5dd91 in sem_wait () from
> /lib64/libpthread.so.0
>   14   Thread 0x4392b940 (LWP 6267) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   13   Thread 0x43325940 (LWP 6259) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   12   Thread 0x42517940 (LWP 6245) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   11   Thread 0x42d1f940 (LWP 6253) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   10   Thread 0x418ea940 (LWP 6236) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   9    Thread 0x41384940 (LWP 6213) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> ---Type <return> to continue, or q <return> to quit---
>   8    Thread 0x4111e940 (LWP 6232) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   7    Thread 0x41586940 (LWP 6224) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   6    Thread 0x40854940 (LWP 6222) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   5    Thread 0x4014e940 (LWP 6228) 0x00007f4ba1f8fd98 in epoll_wait ()
> from /lib64/libc.so.6
>   4    Thread 0x7f4ba9c048b0 (LWP 6056) 0x00007f4ba1f55901 in nanosleep ()
> from /lib64/libc.so.6
>   3    Thread 0x41a30940 (LWP 6446) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
>   2    Thread 0x40e1b940 (LWP 6444) 0x00007f4ba3c5c1c0 in
> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 1    Thread 0x46557940 (LWP 6443) 0x00007f4b9eba7b82 in
> rpyvmprof_f_pypy_rrr () from /usr/local/pypy/libpypy-c.so
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/61c4f885/attachment-0001.html>

From dcp2k at 163.com  Mon Sep 14 08:59:44 2015
From: dcp2k at 163.com (=?GBK?B?09q0886w?=)
Date: Mon, 14 Sep 2015 14:59:44 +0800 (CST)
Subject: [pypy-dev] pypy 2.6 memory leak bug!!  very importent
Message-ID: <4361085.bd76.14fcaa6f972.Coremail.dcp2k@163.com>

hi,
    i use pypy 2.6 with BeautifulSoup module and pymongo.  i make a spider with the pypy.
when i run pypy ,i found a problem ,the pypy use memory higher then 6GB
when i run pypy at once , the pypy use only  240mb memory!
the screenshot in the attachment!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/badb41d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy.png
Type: image/png
Size: 138071 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/badb41d2/attachment-0001.png>

From dcp2k at 163.com  Mon Sep 14 08:52:57 2015
From: dcp2k at 163.com (=?GBK?B?09q0886w?=)
Date: Mon, 14 Sep 2015 14:52:57 +0800 (CST)
Subject: [pypy-dev] pypy segment fault bug
Message-ID: <22b94e3b.ba0f.14fcaa0c4cb.Coremail.dcp2k@163.com>

hi manager:
      i use pypy do something. i found a bug when i run my code!


Fatal error in cpyext, CPython compatibility layer, calling PyTuple_New
Either report a bug or consider not using this particular extension
<MemoryError object at 0x7f71cb01a7c0>
RPython traceback:
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_5
  File "pypy_interpreter_pyopcode.c", line 3578, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 5853, in dispatch_bytecode__AccessDirect_None
Segmentation fault (core dumped)

     and i found pypy can not use the redis module, i use pypy 2.6.

https://github.com/andymccurdy/redis-py







 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/4e426b8d/attachment.html>

From amauryfa at gmail.com  Mon Sep 14 10:45:22 2015
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 14 Sep 2015 10:45:22 +0200
Subject: [pypy-dev] pypy segment fault bug
In-Reply-To: <22b94e3b.ba0f.14fcaa0c4cb.Coremail.dcp2k@163.com>
References: <22b94e3b.ba0f.14fcaa0c4cb.Coremail.dcp2k@163.com>
Message-ID: <CAGmFidZ5ZyVXJLBT-L_w64L-+qR=x7pzcun0W6ZpoML+PW+LWg@mail.gmail.com>

Hi,

Please be more specific and indicate what kind of program you were running:
which extensions modules were used, and which function was called.

For the redis module: which error did you get?


2015-09-14 8:52 GMT+02:00 ??? <dcp2k at 163.com>:

> hi manager:
>       i use pypy do something. i found a bug when i run my code!
>
>
> Fatal error in cpyext, CPython compatibility layer, calling PyTuple_New
> Either report a bug or consider not using this particular extension
> <MemoryError object at 0x7f71cb01a7c0>
> RPython traceback:
>   File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_5
>   File "pypy_interpreter_pyopcode.c", line 3578, in
> handle_bytecode__AccessDirect_None
>   File "pypy_interpreter_pyopcode.c", line 5853, in
> dispatch_bytecode__AccessDirect_None
> Segmentation fault (core dumped)
>
>      and i found pypy can not use the redis module, i use pypy 2.6.
>
> https://github.com/andymccurdy/redis-py
>
>
>
>
>
>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/aaad1e79/attachment.html>

From amauryfa at gmail.com  Mon Sep 14 10:50:59 2015
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 14 Sep 2015 10:50:59 +0200
Subject: [pypy-dev] pypy 2.6 memory leak bug!! very importent
In-Reply-To: <4361085.bd76.14fcaa6f972.Coremail.dcp2k@163.com>
References: <4361085.bd76.14fcaa6f972.Coremail.dcp2k@163.com>
Message-ID: <CAGmFida8uUsNqjFH-Vib9B+v9UOZUDYb7zYd1ZCqPGPmbDLc-w@mail.gmail.com>

Hi,

2015-09-14 8:59 GMT+02:00 ??? <dcp2k at 163.com>:

> hi,
>     i use pypy 2.6 with BeautifulSoup module and pymongo.  i make a spider
> with the pypy.
> when i run pypy ,i found a problem ,the pypy use memory higher then 6GB
> when i run pypy at once , the pypy use only  240mb memory!
> the screenshot in the attachment!
>

This might be because of the differences in memory management.
Unlike CPython, PyPy does not free resources as soon as the last reference
to an object goes away. See
http://pypy.readthedocs.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

The solution is often to close resources explicitly or use "with" blocks.





>
>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/e4c2b6d9/attachment.html>

From victortaylor76 at yahoo.com  Mon Sep 14 15:12:16 2015
From: victortaylor76 at yahoo.com (Victor Taylor)
Date: Mon, 14 Sep 2015 13:12:16 +0000 (UTC)
Subject: [pypy-dev] pypy on ppc
Message-ID: <690077425.3015643.1442236336026.JavaMail.yahoo@mail.yahoo.com>

Hi,?I was looking to run pypy on a PPC64 machine but realized from the install page that pypy support on PPC is stalled. Looking at the sources I found that there is a branch for PPC and that there have been some recent commits on that branch. I would like to know the approximate timeframe when pypy on PPC be available??Also could I build the current PPC branch and use the binary for the time being till the complete port is available (I am assuming the branch builds and gives me a binary without some features which are still under development; I initially just need to use basic functionality)?
Thanks,Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/05f45a1b/attachment.html>

From victortaylor76 at yahoo.com  Mon Sep 14 15:21:26 2015
From: victortaylor76 at yahoo.com (Victor Taylor)
Date: Mon, 14 Sep 2015 13:21:26 +0000 (UTC)
Subject: [pypy-dev] pypy on ppc
Message-ID: <1384278984.3018982.1442236886581.JavaMail.yahoo@mail.yahoo.com>

Hi,?I was looking to run pypy on a PPC64 machine but realized from the install page that pypy support on PPC is stalled. Looking at the sources I found that there is a branch for PPC and that there have been some recent commits on that branch. I would like to know the approximate timeframe when pypy on PPC be available??Also could I build the current PPC branch and use the binary for the time being till the complete port is available (I am assuming the branch builds and gives me a binary without some features which are still under development; I initially just need to use basic functionality)?
Thanks,Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/ceedae57/attachment.html>

From fijall at gmail.com  Mon Sep 14 15:28:13 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 14 Sep 2015 15:28:13 +0200
Subject: [pypy-dev] pypy on ppc
In-Reply-To: <690077425.3015643.1442236336026.JavaMail.yahoo@mail.yahoo.com>
References: <690077425.3015643.1442236336026.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAK5idxSkHGmxFP=Wt+eW5rmy4vkcSXBmouME=WLmkgvBF4RuuQ@mail.gmail.com>

Hi Victor.

PPC64 backend is probably expected to be finished some time this year.
this is an open source software that's distributed for free so we
obviously don't make any actual promises.

The current PPC backend on a branch will netiher build nor work even
if build was fixed, it really requires a bit more work.

 Best regards,
Maciej Fijalkowski

On Mon, Sep 14, 2015 at 3:12 PM, Victor Taylor via pypy-dev
<pypy-dev at python.org> wrote:
> Hi,
>
> I was looking to run pypy on a PPC64 machine but realized from the install
> page that pypy support on PPC is stalled. Looking at the sources I found
> that there is a branch for PPC and that there have been some recent commits
> on that branch. I would like to know the approximate timeframe when pypy on
> PPC be available?
>
> Also could I build the current PPC branch and use the binary for the time
> being till the complete port is available (I am assuming the branch builds
> and gives me a binary without some features which are still under
> development; I initially just need to use basic functionality)?
>
> Thanks,
> Victor
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From arigo at tunes.org  Mon Sep 14 18:00:16 2015
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 14 Sep 2015 18:00:16 +0200
Subject: [pypy-dev] pypy on ppc
In-Reply-To: <CAK5idxSkHGmxFP=Wt+eW5rmy4vkcSXBmouME=WLmkgvBF4RuuQ@mail.gmail.com>
References: <690077425.3015643.1442236336026.JavaMail.yahoo@mail.yahoo.com>
 <CAK5idxSkHGmxFP=Wt+eW5rmy4vkcSXBmouME=WLmkgvBF4RuuQ@mail.gmail.com>
Message-ID: <CAMSv6X1GQqDaAW5GEM-9KabR-A0DWVhUU9Qa=pBqGV1WJJjeHQ@mail.gmail.com>

Hi Victor,

On Mon, Sep 14, 2015 at 3:28 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> PPC64 backend is probably expected to be finished some time this year.
> this is an open source software that's distributed for free so we
> obviously don't make any actual promises.
>
> The current PPC backend on a branch will netiher build nor work even
> if build was fixed, it really requires a bit more work.

More precisely, I'm working on the PPC64 JIT backends these days (big-
and little-endian), expecting to finish some time in October.

In the meantime, you could try to translate a version of PyPy without
any JIT, which should mostly work but not be particularly useful...


A bient?t,

Armin.

From cherian.rosh at gmail.com  Tue Sep 15 05:39:50 2015
From: cherian.rosh at gmail.com (Roshan Cherian)
Date: Mon, 14 Sep 2015 20:39:50 -0700
Subject: [pypy-dev] cffi dlopen
Message-ID: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>

Hi Team,

I am not sure if I should be asking the question here, however hoping
someone could help.

we use ffi.cdef for definitions and ffi.dlopen to open shared library. To
my understanding ffi.dlopen only works in the presence of a c compiler to
dynamically link the shared lib. We have a linux box without gcc in which
we are supposed to run this setup. We do have dlopen on the box as man
dlopen returns. Could I know if it is at all possible to use ffi.dlopen
without a C compiler?

Apologies if I am totally off.

Thanks,
-Roshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150914/4a85d33a/attachment-0001.html>

From fijall at gmail.com  Tue Sep 15 08:02:23 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 15 Sep 2015 08:02:23 +0200
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
Message-ID: <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>

ffi.dlopen does not require a C compiler, ffi.verify does (which we
strongly encourage to use). Note that since cffi 1.0 you only require
C compiler to create extensions, you can distribute them without a
compiler. See documentation for details

On Tue, Sep 15, 2015 at 5:39 AM, Roshan Cherian <cherian.rosh at gmail.com> wrote:
> Hi Team,
>
> I am not sure if I should be asking the question here, however hoping
> someone could help.
>
> we use ffi.cdef for definitions and ffi.dlopen to open shared library. To my
> understanding ffi.dlopen only works in the presence of a c compiler to
> dynamically link the shared lib. We have a linux box without gcc in which we
> are supposed to run this setup. We do have dlopen on the box as man dlopen
> returns. Could I know if it is at all possible to use ffi.dlopen without a C
> compiler?
>
> Apologies if I am totally off.
>
> Thanks,
> -Roshan
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Tue Sep 15 09:11:57 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 15 Sep 2015 09:11:57 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: I *think* the inputargs
 should always contain InputArgXxx objects that
In-Reply-To: <20150914173110.B2CDD1C1455@cobra.cs.uni-duesseldorf.de>
References: <20150914173110.B2CDD1C1455@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxQpnHb9KK7PftOUGGO3vaPTBsuh0KaXUGOy5CoT5WBHVA@mail.gmail.com>

It might contain something else than InputArgXxx (because of e.g. not
tracing from the start), but indeed the forwarded should be set to
None by the time we reach the backend (maybe we forget it too late?)

On Mon, Sep 14, 2015 at 7:31 PM, arigo <noreply at buildbot.pypy.org> wrote:
> Author: Armin Rigo <arigo at tunes.org>
> Branch:
> Changeset: r79638:cfe5d8e88d3d
> Date: 2015-09-14 19:31 +0200
> http://bitbucket.org/pypy/pypy/changeset/cfe5d8e88d3d/
>
> Log:    I *think* the inputargs should always contain InputArgXxx objects
>         that are not forwarded. (Hitting the case from test_ll_random)
>
> diff --git a/rpython/jit/backend/x86/regalloc.py b/rpython/jit/backend/x86/regalloc.py
> --- a/rpython/jit/backend/x86/regalloc.py
> +++ b/rpython/jit/backend/x86/regalloc.py
> @@ -134,6 +134,8 @@
>          self.final_jump_op = None
>
>      def _prepare(self, inputargs, operations, allgcrefs):
> +        for box in inputargs:
> +            assert box.get_forwarded() is None
>          cpu = self.assembler.cpu
>          self.fm = X86FrameManager(cpu.get_baseofs_of_frame_field())
>          operations = cpu.gc_ll_descr.rewrite_assembler(cpu, operations,
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> https://mail.python.org/mailman/listinfo/pypy-commit

From arigo at tunes.org  Tue Sep 15 10:49:40 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 15 Sep 2015 10:49:40 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: I *think* the inputargs
 should always contain InputArgXxx objects that
In-Reply-To: <CAK5idxQpnHb9KK7PftOUGGO3vaPTBsuh0KaXUGOy5CoT5WBHVA@mail.gmail.com>
References: <20150914173110.B2CDD1C1455@cobra.cs.uni-duesseldorf.de>
 <CAK5idxQpnHb9KK7PftOUGGO3vaPTBsuh0KaXUGOy5CoT5WBHVA@mail.gmail.com>
Message-ID: <CAMSv6X2sPb-vbZXnOHcZ-tC7przLjbeU8mQpCpAT76xgFEKB7w@mail.gmail.com>

Hi Maciej,

On Tue, Sep 15, 2015 at 9:11 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> It might contain something else than InputArgXxx (because of e.g. not
> tracing from the start), but indeed the forwarded should be set to
> None by the time we reach the backend (maybe we forget it too late?)

No, I think it's only test_random.py that reuses operations from the
main loop as fail_args when compiling a bridge, and these operations
sometimes already have a get_forwarded() from the main loop's rewrite
step.  It should not occur outside this test.  It took me a while to
figure out what was wrong, though :-)


A bient?t,

Armin.

From fijall at gmail.com  Tue Sep 15 11:25:27 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 15 Sep 2015 11:25:27 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: I *think* the inputargs
 should always contain InputArgXxx objects that
In-Reply-To: <CAMSv6X2sPb-vbZXnOHcZ-tC7przLjbeU8mQpCpAT76xgFEKB7w@mail.gmail.com>
References: <20150914173110.B2CDD1C1455@cobra.cs.uni-duesseldorf.de>
 <CAK5idxQpnHb9KK7PftOUGGO3vaPTBsuh0KaXUGOy5CoT5WBHVA@mail.gmail.com>
 <CAMSv6X2sPb-vbZXnOHcZ-tC7przLjbeU8mQpCpAT76xgFEKB7w@mail.gmail.com>
Message-ID: <CAK5idxSW5tixHYfJMaXneMEzo0VJGtmEpcVbRn_By2eYvOOVZw@mail.gmail.com>

On Tue, Sep 15, 2015 at 10:49 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Maciej,
>
> On Tue, Sep 15, 2015 at 9:11 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> It might contain something else than InputArgXxx (because of e.g. not
>> tracing from the start), but indeed the forwarded should be set to
>> None by the time we reach the backend (maybe we forget it too late?)
>
> No, I think it's only test_random.py that reuses operations from the
> main loop as fail_args when compiling a bridge, and these operations
> sometimes already have a get_forwarded() from the main loop's rewrite
> step.  It should not occur outside this test.  It took me a while to
> figure out what was wrong, though :-)
>
>
> A bient?t,
>
> Armin.

Yes, forwarded has this problem that if you forget to clean it, there
is a bit of trouble hard to debug :/ not sure what is the solution

From arigo at tunes.org  Tue Sep 15 13:59:41 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 15 Sep 2015 13:59:41 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: I *think* the inputargs
 should always contain InputArgXxx objects that
In-Reply-To: <CAK5idxSW5tixHYfJMaXneMEzo0VJGtmEpcVbRn_By2eYvOOVZw@mail.gmail.com>
References: <20150914173110.B2CDD1C1455@cobra.cs.uni-duesseldorf.de>
 <CAK5idxQpnHb9KK7PftOUGGO3vaPTBsuh0KaXUGOy5CoT5WBHVA@mail.gmail.com>
 <CAMSv6X2sPb-vbZXnOHcZ-tC7przLjbeU8mQpCpAT76xgFEKB7w@mail.gmail.com>
 <CAK5idxSW5tixHYfJMaXneMEzo0VJGtmEpcVbRn_By2eYvOOVZw@mail.gmail.com>
Message-ID: <CAMSv6X2WS+yvsBcfquzPq93HPGR2BDvZKDmnU-Ne8muwfEHn+g@mail.gmail.com>

Hi Fijal,

On Tue, Sep 15, 2015 at 11:25 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Yes, forwarded has this problem that if you forget to clean it, there
> is a bit of trouble hard to debug :/ not sure what is the solution

I think it's enough (or will become enough after one or two more such
issues) to check in the next step that all operations and inputargs
that you receive are not forwarded.  That's what I did in this
checkin.


A bient?t,

Armin.

From arigo at tunes.org  Tue Sep 15 14:23:51 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 15 Sep 2015 14:23:51 +0200
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
Message-ID: <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>

Hi Roshan,

On Tue, Sep 15, 2015 at 8:02 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> ffi.dlopen does not require a C compiler, ffi.verify does (which we
> strongly encourage to use). Note that since cffi 1.0 you only require
> C compiler to create extensions, you can distribute them without a
> compiler. See documentation for details

I added more emphasis about that to the documentation's Overview page.
You can see it at https://bitbucket.org/cffi/cffi/wiki/overview (grep
for "C compiler").


A bient?t,

Armin.

From cherian.rosh at gmail.com  Tue Sep 15 17:01:48 2015
From: cherian.rosh at gmail.com (Roshan Cherian)
Date: Tue, 15 Sep 2015 08:01:48 -0700
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
Message-ID: <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>

Thanks Armin and Maciej.

Thanks for replying, let me share my case I have libical.so built into a
path which is set in LD_LIBRARY_PATH.

I have upgraded to pypy2.6.1 with libffi3.2.1 and cffi 1.2.1. I have run
the following:

>export LD_LIBRARY_PATH=./lib
>./pypy/bin/pypy>>
from cffi import FFI
ffi=FFI()
ffi.ctypes('''..
''')
ffi.dlopen('ical')

fails with an error not able to load
ffi.dlopen('libical.so')

>>>>libical=ffi.dlopen('libical.so')
<cffi.api.FFILibrary_libical.so <http://cffi.api.ffilibrary_libical.so/> object
at 0x00007f4f40f8da60>

>>>> import ctypes.util

>>>> libical = ffi.dlopen(ctypes.util.find_library('ical'))

>>>>
libical.ical_set_unknown_token_handling_setting(libical.ICAL_ASSUME_IANA_TOKEN)
I get an error: AttributeError: ical_set_unknown_token_handling_setting

However if I yum install libical and do the above it works just fine,
meaning I don't get a AttributeError, so I believe its a problem in loading
from LD_LIBRARY_PATH. I did see the following:
https://bitbucket.org/cffi/cffi/issues/58/dlopen-ignores-ld_library_path-and-doesnt,
however I don't understand quite well what the solution was

I haven't tried out ffi.verify I am not sure how to load a shared lib using
ffi.verify, I am sorry if my understanding is wrong.

Thanks,
-Roshan

On Tue, Sep 15, 2015 at 5:23 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Roshan,
>
> On Tue, Sep 15, 2015 at 8:02 AM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
> > ffi.dlopen does not require a C compiler, ffi.verify does (which we
> > strongly encourage to use). Note that since cffi 1.0 you only require
> > C compiler to create extensions, you can distribute them without a
> > compiler. See documentation for details
>
> I added more emphasis about that to the documentation's Overview page.
> You can see it at https://bitbucket.org/cffi/cffi/wiki/overview (grep
> for "C compiler").
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150915/f8315689/attachment.html>

From arigo at tunes.org  Tue Sep 15 17:17:27 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 15 Sep 2015 17:17:27 +0200
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
Message-ID: <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>

Hi Roshan,

On Tue, Sep 15, 2015 at 5:01 PM, Roshan Cherian <cherian.rosh at gmail.com> wrote:
>>>>> libical = ffi.dlopen(ctypes.util.find_library('ical'))
>>>>> libical.ical_set_unknown_token_handling_setting(libical.ICAL_ASSUME_IANA_TOKEN)
>
> I get an error: AttributeError: ical_set_unknown_token_handling_setting

This means the library file was found, but it doesn't contain any
symbol of the name "ical_set_unknown_token_handling_setting".  It may
be because such a name is actually a macro.  In that case you can't
use ffi.dlopen().

You should look at ffi.set_source() instead (and *not* ffi.verify();
Maciej probably mentioned this by mistake, it is now called
set_source()).

> I haven't tried out ffi.verify I am not sure how to load a shared lib using
> ffi.verify, I am sorry if my understanding is wrong.

See http://cffi.readthedocs.org/en/latest/overview.html#real-example-api-level-out-of-line
.  In your case you need:

ffi.set_source("_ical_cffi",
    """ #include <ical.h>
    """,
    include_dirs=['./include'],    # or where ical.h is
    libraries=['ical'],
    library_dirs=['./lib'],             # or where libical.so is
)

You also need the same ffi.cdef() as you use now, and ffi.compile() as
shown in the example.  The ffi.cdef() can use the syntax ``...``
(dot-dot-dot) in many places when it is combined with
ffi.set_source().  See the rest of the documentation section for more.


A bient?t,

Armin.

From arigo at tunes.org  Wed Sep 16 10:16:32 2015
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 16 Sep 2015 10:16:32 +0200
Subject: [pypy-dev] speed.pypy.org
Message-ID: <CAMSv6X1ko0tGk+LJMnjdeuonHbJ27K7o7TZ0ZWT-0zUo1rDDHA@mail.gmail.com>

Hi all,

Summarizing a few comments on irc: the main page of speed.pypy.org is
broken right now.  (The rest seems to work.)


A bient?t,

Armin.

From kostia.lopuhin at gmail.com  Wed Sep 16 10:32:25 2015
From: kostia.lopuhin at gmail.com (=?UTF-8?B?0JrQvtGB0YLRjyDQm9C+0L/Rg9GF0LjQvQ==?=)
Date: Wed, 16 Sep 2015 11:32:25 +0300
Subject: [pypy-dev] speed.pypy.org
In-Reply-To: <CAMSv6X1ko0tGk+LJMnjdeuonHbJ27K7o7TZ0ZWT-0zUo1rDDHA@mail.gmail.com>
References: <CAMSv6X1ko0tGk+LJMnjdeuonHbJ27K7o7TZ0ZWT-0zUo1rDDHA@mail.gmail.com>
Message-ID: <CAAvCB=SemvA2ybOc6Mv39d=s7QTkVPDB15QeLoY1oopyNSxJDg@mail.gmail.com>

Looks like the problem is on the server, not in JS:
http://speed.pypy.org/json/ returns empty array for "benchmarks"
field.

2015-09-16 11:16 GMT+03:00 Armin Rigo <arigo at tunes.org>:
> Hi all,
>
> Summarizing a few comments on irc: the main page of speed.pypy.org is
> broken right now.  (The rest seems to work.)
>
>
> A bient?t,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From matti.picus at gmail.com  Wed Sep 16 19:27:02 2015
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 16 Sep 2015 20:27:02 +0300
Subject: [pypy-dev] speed.pypy.org
In-Reply-To: <CAMSv6X1ko0tGk+LJMnjdeuonHbJ27K7o7TZ0ZWT-0zUo1rDDHA@mail.gmail.com>
References: <CAMSv6X1ko0tGk+LJMnjdeuonHbJ27K7o7TZ0ZWT-0zUo1rDDHA@mail.gmail.com>
Message-ID: <55F9A666.7040006@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150916/2df91e46/attachment.html>

From phyo.arkarlwin at gmail.com  Wed Sep 16 23:59:16 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Thu, 17 Sep 2015 04:29:16 +0630
Subject: [pypy-dev] pypy 2.6 memory leak bug!! very importent
In-Reply-To: <4361085.bd76.14fcaa6f972.Coremail.dcp2k@163.com>
References: <4361085.bd76.14fcaa6f972.Coremail.dcp2k@163.com>
Message-ID: <CA+HjJrgGyR848BazDAmWOXRfwizaT2Boow9HDHYDy3YQeSWtXw@mail.gmail.com>

If you can show as a sample code it will be better.

On Mon, Sep 14, 2015 at 1:29 PM, ??? <dcp2k at 163.com> wrote:

> hi,
>     i use pypy 2.6 with BeautifulSoup module and pymongo.  i make a spider
> with the pypy.
> when i run pypy ,i found a problem ,the pypy use memory higher then 6GB
> when i run pypy at once , the pypy use only  240mb memory!
> the screenshot in the attachment!
>
>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150917/3fa5b4ea/attachment.html>

From admalledd at gmail.com  Fri Sep 18 07:53:18 2015
From: admalledd at gmail.com (Eric Driggers)
Date: Thu, 17 Sep 2015 22:53:18 -0700
Subject: [pypy-dev] State of GUI toolkits with PyPy?
Message-ID: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>

Looking at rewriting a number of my older python2 scripts to python3
and was hoping in the mean time to also make all of them play nice
with PyPy where possible. However a number of them use pyqt when I
needed a GUI. From what I can find QT still does not play nice with
PyPy yet, however are there any others? Has there been movement on GUI
toolkits/libraries with CFFI/CTypes/cpyext support via pypy?

The compatibility wiki has not really had those edited since sometime
around early 2013...

https://bitbucket.org/pypy/compatibility/wiki/Home

Wondering is all before I try and see myself and spend a few days
trying to build them with pypy.

From fijall at gmail.com  Fri Sep 18 08:27:18 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 18 Sep 2015 08:27:18 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
Message-ID: <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>

Hi Eric

There has been some success with WxPython, but I don't think anyone
got pyqt running on PyPy. Cffi is one option with pymetabiosis being
the other one worth considering. Also I have a bit no clue how much
CPython C extensions your bindings/qt uses, but we have an emulation
layer for those that should work as long as the extension plays nicely
(will be dead slow though)

Cheers,
fijal

On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd at gmail.com> wrote:
> Looking at rewriting a number of my older python2 scripts to python3
> and was hoping in the mean time to also make all of them play nice
> with PyPy where possible. However a number of them use pyqt when I
> needed a GUI. From what I can find QT still does not play nice with
> PyPy yet, however are there any others? Has there been movement on GUI
> toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
>
> The compatibility wiki has not really had those edited since sometime
> around early 2013...
>
> https://bitbucket.org/pypy/compatibility/wiki/Home
>
> Wondering is all before I try and see myself and spend a few days
> trying to build them with pypy.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From cherian.rosh at gmail.com  Fri Sep 18 10:02:13 2015
From: cherian.rosh at gmail.com (Roshan Cherian)
Date: Fri, 18 Sep 2015 01:02:13 -0700
Subject: [pypy-dev] Fwd:  cffi dlopen
In-Reply-To: <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
 <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>
 <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
Message-ID: <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>

Hi Armin/Maciej,

Thanks for the reply, following the code sample I wrote up the following:

from cffi import FFI

ffi = FFI()


ffi.set_source("_ical_cffi_ext",

    """ // passed to the real C compiler

        #include <libical/ical.h>

    """,

    include_dirs=['./include'],    # where ical.h is

        libraries=['ical'],

        library_dirs=['./lib'],)   # or a list of libraries to link with


ffi.cdef("""     // some declarations from the man page


        typedef struct icalcomponent_impl icalcomponent;


        typedef struct icalproperty_impl icalproperty;


        typedef ... icalparameter;


        typedef struct icalvalue_impl icalvalue;


        typedef ... icaltimezonechange; //really typedef struct
_icaltimezonechange
icaltimezonechange;


        struct _icaltimezonechange {

            int          utc_offset;

            int          prev_utc_offset;

            int          year;          /**< Actual year, e.g. 2001. */

            int          month;         /**< 1 (Jan) to 12 (Dec). */

            int          day;

            int          hour;

            int          minute;

            int          second;

            int          is_daylight;

        };


""")


if __name__ == "__main__":

    ffi.compile()


_icaltimezonechange is opaque as its in src/libical/icaltimezone.c a c file
and not in in ical.h. However this struct is required for my purpose.
However when it compiles I do get errors like:


_ical_cffi_ext.c:455: error: dereferencing pointer to incomplete type

_ical_cffi_ext.c:457: error: invalid use of undefined type 'struct
_icaltimezonechange'

_ical_cffi_ext.c:458: error: dereferencing pointer to incomplete type

_ical_cffi_ext.c:468: error: invalid application of 'sizeof' to incomplete
type 'struct _icaltimezonechange'

_ical_cffi_ext.c:468: error: initializer element is not constant

_ical_cffi_ext.c:468: error: (near initialization for
'_cffi_struct_unions[2].alignment')


Can I know what should be done for these cases?


Thanks,

-Roshan

On Tue, Sep 15, 2015 at 8:17 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Roshan,
>
> On Tue, Sep 15, 2015 at 5:01 PM, Roshan Cherian <cherian.rosh at gmail.com>
> wrote:
> >>>>> libical = ffi.dlopen(ctypes.util.find_library('ical'))
> >>>>>
> libical.ical_set_unknown_token_handling_setting(libical.ICAL_ASSUME_IANA_TOKEN)
> >
> > I get an error: AttributeError: ical_set_unknown_token_handling_setting
>
> This means the library file was found, but it doesn't contain any
> symbol of the name "ical_set_unknown_token_handling_setting".  It may
> be because such a name is actually a macro.  In that case you can't
> use ffi.dlopen().
>
> You should look at ffi.set_source() instead (and *not* ffi.verify();
> Maciej probably mentioned this by mistake, it is now called
> set_source()).
>
> > I haven't tried out ffi.verify I am not sure how to load a shared lib
> using
> > ffi.verify, I am sorry if my understanding is wrong.
>
> See
> http://cffi.readthedocs.org/en/latest/overview.html#real-example-api-level-out-of-line
> .  In your case you need:
>
> ffi.set_source("_ical_cffi",
>     """ #include <ical.h>
>     """,
>     include_dirs=['./include'],    # or where ical.h is
>     libraries=['ical'],
>     library_dirs=['./lib'],             # or where libical.so is
> )
>
> You also need the same ffi.cdef() as you use now, and ffi.compile() as
> shown in the example.  The ffi.cdef() can use the syntax ``...``
> (dot-dot-dot) in many places when it is combined with
> ffi.set_source().  See the rest of the documentation section for more.
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150918/07c5a900/attachment.html>

From arigo at tunes.org  Fri Sep 18 12:49:03 2015
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 18 Sep 2015 12:49:03 +0200
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
 <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>
 <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
 <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>
Message-ID: <CAMSv6X1d7Rs-7vbo3f9wJ=wQ6ZN0e3fmFw6fOVhPSCosA2n6_Q@mail.gmail.com>

Hi Roshan,

On Fri, Sep 18, 2015 at 10:02 AM, Roshan Cherian <cherian.rosh at gmail.com> wrote:
> _icaltimezonechange is opaque as its in src/libical/icaltimezone.c a c file
> and not in in ical.h. However this struct is required for my purpose.

All structs must be declared in C before you import them into Python.
In this case, the "cheat" to access this structure is the same as if
you wrote C code: you need to give the real C compiler a declaration
of this struct.  Then you can import it as you did.  (So you need to
write this struct twice.)

ffi.set_source("_ical_cffi_ext",
    """ // passed to the real C compiler
        #include <libical/ical.h>

        struct _icaltimezonechange {
            int          utc_offset;
            int          prev_utc_offset;
            int          year;          /**< Actual year, e.g. 2001. */
            int          month;         /**< 1 (Jan) to 12 (Dec). */
            int          day;
            int          hour;
            int          minute;
            int          second;
            int          is_daylight;
        };
    """,
        include_dirs=['./include'],    # where ical.h is
        libraries=['ical'],
        library_dirs=['./lib'],)   # or a list of libraries to link with


A bient?t,

Armin.

From phyo.arkarlwin at gmail.com  Fri Sep 18 13:10:36 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Fri, 18 Sep 2015 17:40:36 +0630
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
Message-ID: <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>

Use Electron + RapydScript on client side , along with bootstrap or
Material Design Light . https://github.com/atsepkov/RapydScript

And use PyPy on backend.
you got everything done in python.

On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall at gmail.com>
wrote:

> Hi Eric
>
> There has been some success with WxPython, but I don't think anyone
> got pyqt running on PyPy. Cffi is one option with pymetabiosis being
> the other one worth considering. Also I have a bit no clue how much
> CPython C extensions your bindings/qt uses, but we have an emulation
> layer for those that should work as long as the extension plays nicely
> (will be dead slow though)
>
> Cheers,
> fijal
>
> On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd at gmail.com>
> wrote:
> > Looking at rewriting a number of my older python2 scripts to python3
> > and was hoping in the mean time to also make all of them play nice
> > with PyPy where possible. However a number of them use pyqt when I
> > needed a GUI. From what I can find QT still does not play nice with
> > PyPy yet, however are there any others? Has there been movement on GUI
> > toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
> >
> > The compatibility wiki has not really had those edited since sometime
> > around early 2013...
> >
> > https://bitbucket.org/pypy/compatibility/wiki/Home
> >
> > Wondering is all before I try and see myself and spend a few days
> > trying to build them with pypy.
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > https://mail.python.org/mailman/listinfo/pypy-dev
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150918/18266a7f/attachment.html>

From rymg19 at gmail.com  Fri Sep 18 16:34:07 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Fri, 18 Sep 2015 09:34:07 -0500
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
Message-ID: <115F543E-DD9B-4DEB-AA84-211193EDC15E@gmail.com>

I'd advise you to try PGI (https://github.com/lazka/pgi). It's a set of PyPy-compatible Gtk+ 3 bindings that's mostly compatible with PyGObject. They're not complete, but I've used them before, and they work quite well.

On September 18, 2015 12:53:18 AM CDT, Eric Driggers <admalledd at gmail.com> wrote:
>Looking at rewriting a number of my older python2 scripts to python3
>and was hoping in the mean time to also make all of them play nice
>with PyPy where possible. However a number of them use pyqt when I
>needed a GUI. From what I can find QT still does not play nice with
>PyPy yet, however are there any others? Has there been movement on GUI
>toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
>
>The compatibility wiki has not really had those edited since sometime
>around early 2013...
>
>https://bitbucket.org/pypy/compatibility/wiki/Home
>
>Wondering is all before I try and see myself and spend a few days
>trying to build them with pypy.
>_______________________________________________
>pypy-dev mailing list
>pypy-dev at python.org
>https://mail.python.org/mailman/listinfo/pypy-dev

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150918/2a9cb0eb/attachment.html>

From phyo.arkarlwin at gmail.com  Sat Sep 19 10:32:39 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Sat, 19 Sep 2015 15:02:39 +0630
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
Message-ID: <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>

With this stack , It works on every platform that pypy works. Also possible
for mobile UI

On Fri, Sep 18, 2015 at 5:40 PM, Phyo Arkar <phyo.arkarlwin at gmail.com>
wrote:

> Use Electron + RapydScript on client side , along with bootstrap or
> Material Design Light . https://github.com/atsepkov/RapydScript
>
> And use PyPy on backend.
> you got everything done in python.
>
> On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
>
>> Hi Eric
>>
>> There has been some success with WxPython, but I don't think anyone
>> got pyqt running on PyPy. Cffi is one option with pymetabiosis being
>> the other one worth considering. Also I have a bit no clue how much
>> CPython C extensions your bindings/qt uses, but we have an emulation
>> layer for those that should work as long as the extension plays nicely
>> (will be dead slow though)
>>
>> Cheers,
>> fijal
>>
>> On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd at gmail.com>
>> wrote:
>> > Looking at rewriting a number of my older python2 scripts to python3
>> > and was hoping in the mean time to also make all of them play nice
>> > with PyPy where possible. However a number of them use pyqt when I
>> > needed a GUI. From what I can find QT still does not play nice with
>> > PyPy yet, however are there any others? Has there been movement on GUI
>> > toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
>> >
>> > The compatibility wiki has not really had those edited since sometime
>> > around early 2013...
>> >
>> > https://bitbucket.org/pypy/compatibility/wiki/Home
>> >
>> > Wondering is all before I try and see myself and spend a few days
>> > trying to build them with pypy.
>> > _______________________________________________
>> > pypy-dev mailing list
>> > pypy-dev at python.org
>> > https://mail.python.org/mailman/listinfo/pypy-dev
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150919/943fd2b2/attachment-0001.html>

From admalledd at gmail.com  Sat Sep 19 19:32:44 2015
From: admalledd at gmail.com (Eric Driggers)
Date: Sat, 19 Sep 2015 10:32:44 -0700
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
Message-ID: <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>

I have a preference against web-based UIs for things that are meant to
exist/run just on my one machine. Especially since some of these are
shorter-lived but "heavy" scripts (working with them for only a few
minutes).

So the short update that I can see is:

* There is/was work with WxPython as a GSOC project, but that has been
left to mostly stagnate. ( https://bitbucket.org/waedt/wxpython_cffi )
I was unable to reproduce any of the demos/tests easily, probably a
bit too much time has passed for someone like me to be able to pick it
up and carry on. Would need an amount of love first from someone
knowledgeable to bring it forward and be develop-able again.
* https://github.com/rguillebert/pymetabiosis (aka: use CPython for a
GUI toolkit via embedding the interp into PyPy), although quite the
nice workaround I feel that if you are going to have to fall back to
CPython (and thus install all the modules required there) I might as
well stay with CPython for these scripts
* cffi: aka "the hard way", write hooks/wrappers into toolkit of choice myself.
* Some form of web-based GUI (eg flask+bootstrap, RapydScript, and
more): Although I like web-interfaces, they are not appropriate for
every use case. Thick, heavy workloads bound to one computer do not
integrate or scale easily with python-based webUI stuff from my
experience.
* https://github.com/lazka/pgi works wonderfully and will probably be
what I use here on out.
* https://bitbucket.org/dholth/pysdl2-cffi Bit more work to get
started, but nice if you need some of the bells and whistles SDL2
brings (joystick inputs, easy-ish GL use)

Thanks Ryan for pointing me to PGI, few examples I have run worked
wonderfully so far for all the widgets I need.

On Sat, Sep 19, 2015 at 1:32 AM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> With this stack , It works on every platform that pypy works. Also possible
> for mobile UI
>
> On Fri, Sep 18, 2015 at 5:40 PM, Phyo Arkar <phyo.arkarlwin at gmail.com>
> wrote:
>>
>> Use Electron + RapydScript on client side , along with bootstrap or
>> Material Design Light . https://github.com/atsepkov/RapydScript
>>
>> And use PyPy on backend.
>> you got everything done in python.
>>
>> On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall at gmail.com>
>> wrote:
>>>
>>> Hi Eric
>>>
>>> There has been some success with WxPython, but I don't think anyone
>>> got pyqt running on PyPy. Cffi is one option with pymetabiosis being
>>> the other one worth considering. Also I have a bit no clue how much
>>> CPython C extensions your bindings/qt uses, but we have an emulation
>>> layer for those that should work as long as the extension plays nicely
>>> (will be dead slow though)
>>>
>>> Cheers,
>>> fijal
>>>
>>> On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd at gmail.com>
>>> wrote:
>>> > Looking at rewriting a number of my older python2 scripts to python3
>>> > and was hoping in the mean time to also make all of them play nice
>>> > with PyPy where possible. However a number of them use pyqt when I
>>> > needed a GUI. From what I can find QT still does not play nice with
>>> > PyPy yet, however are there any others? Has there been movement on GUI
>>> > toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
>>> >
>>> > The compatibility wiki has not really had those edited since sometime
>>> > around early 2013...
>>> >
>>> > https://bitbucket.org/pypy/compatibility/wiki/Home
>>> >
>>> > Wondering is all before I try and see myself and spend a few days
>>> > trying to build them with pypy.
>>> > _______________________________________________
>>> > pypy-dev mailing list
>>> > pypy-dev at python.org
>>> > https://mail.python.org/mailman/listinfo/pypy-dev
>>> _______________________________________________
>>> pypy-dev mailing list
>>> pypy-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
>

From fijall at gmail.com  Sun Sep 20 08:36:47 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 20 Sep 2015 08:36:47 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
Message-ID: <CAK5idxSgGNE=R6sYBz7rBrc=4hhQT1vcsbyN0KgWEWhWCF9LWg@mail.gmail.com>

There is  also pygame-cffi, which is I guess slightly higher up than
sdl (but not something *I* would personally use for a UI either) -
https://github.com/CTPUG/pygame_cffi

On Sat, Sep 19, 2015 at 7:32 PM, Eric Driggers <admalledd at gmail.com> wrote:
> I have a preference against web-based UIs for things that are meant to
> exist/run just on my one machine. Especially since some of these are
> shorter-lived but "heavy" scripts (working with them for only a few
> minutes).
>
> So the short update that I can see is:
>
> * There is/was work with WxPython as a GSOC project, but that has been
> left to mostly stagnate. ( https://bitbucket.org/waedt/wxpython_cffi )
> I was unable to reproduce any of the demos/tests easily, probably a
> bit too much time has passed for someone like me to be able to pick it
> up and carry on. Would need an amount of love first from someone
> knowledgeable to bring it forward and be develop-able again.
> * https://github.com/rguillebert/pymetabiosis (aka: use CPython for a
> GUI toolkit via embedding the interp into PyPy), although quite the
> nice workaround I feel that if you are going to have to fall back to
> CPython (and thus install all the modules required there) I might as
> well stay with CPython for these scripts
> * cffi: aka "the hard way", write hooks/wrappers into toolkit of choice myself.
> * Some form of web-based GUI (eg flask+bootstrap, RapydScript, and
> more): Although I like web-interfaces, they are not appropriate for
> every use case. Thick, heavy workloads bound to one computer do not
> integrate or scale easily with python-based webUI stuff from my
> experience.
> * https://github.com/lazka/pgi works wonderfully and will probably be
> what I use here on out.
> * https://bitbucket.org/dholth/pysdl2-cffi Bit more work to get
> started, but nice if you need some of the bells and whistles SDL2
> brings (joystick inputs, easy-ish GL use)
>
> Thanks Ryan for pointing me to PGI, few examples I have run worked
> wonderfully so far for all the widgets I need.
>
> On Sat, Sep 19, 2015 at 1:32 AM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
>> With this stack , It works on every platform that pypy works. Also possible
>> for mobile UI
>>
>> On Fri, Sep 18, 2015 at 5:40 PM, Phyo Arkar <phyo.arkarlwin at gmail.com>
>> wrote:
>>>
>>> Use Electron + RapydScript on client side , along with bootstrap or
>>> Material Design Light . https://github.com/atsepkov/RapydScript
>>>
>>> And use PyPy on backend.
>>> you got everything done in python.
>>>
>>> On Fri, Sep 18, 2015 at 12:57 PM, Maciej Fijalkowski <fijall at gmail.com>
>>> wrote:
>>>>
>>>> Hi Eric
>>>>
>>>> There has been some success with WxPython, but I don't think anyone
>>>> got pyqt running on PyPy. Cffi is one option with pymetabiosis being
>>>> the other one worth considering. Also I have a bit no clue how much
>>>> CPython C extensions your bindings/qt uses, but we have an emulation
>>>> layer for those that should work as long as the extension plays nicely
>>>> (will be dead slow though)
>>>>
>>>> Cheers,
>>>> fijal
>>>>
>>>> On Fri, Sep 18, 2015 at 7:53 AM, Eric Driggers <admalledd at gmail.com>
>>>> wrote:
>>>> > Looking at rewriting a number of my older python2 scripts to python3
>>>> > and was hoping in the mean time to also make all of them play nice
>>>> > with PyPy where possible. However a number of them use pyqt when I
>>>> > needed a GUI. From what I can find QT still does not play nice with
>>>> > PyPy yet, however are there any others? Has there been movement on GUI
>>>> > toolkits/libraries with CFFI/CTypes/cpyext support via pypy?
>>>> >
>>>> > The compatibility wiki has not really had those edited since sometime
>>>> > around early 2013...
>>>> >
>>>> > https://bitbucket.org/pypy/compatibility/wiki/Home
>>>> >
>>>> > Wondering is all before I try and see myself and spend a few days
>>>> > trying to build them with pypy.
>>>> > _______________________________________________
>>>> > pypy-dev mailing list
>>>> > pypy-dev at python.org
>>>> > https://mail.python.org/mailman/listinfo/pypy-dev
>>>> _______________________________________________
>>>> pypy-dev mailing list
>>>> pypy-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pypy-dev
>>>
>>>
>>

From arigo at tunes.org  Sun Sep 20 09:27:03 2015
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 20 Sep 2015 09:27:03 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
Message-ID: <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>

Hi Eric,

Thanks for this list that summarizes the situation!  It's information
that we should put or link to from somewhere (the FAQ?).

Maybe it should be put in the compatibility wiki, but that wiki looks
really, really outdated now, to the point that fijal suggested that we
might as well close it down.  The experiment of crowd-sourcing this
wiki has failed.

Nowadays you can, more and more often, go to the other project's
website or PyPI page and see a mention about the PyPy compatibility
status there.  But it doesn't help much when gathering a list of all
GUI toolkits available (say).  So I would say that we should clean up
from our wiki all projects with "not working" or "unknown" status (go
check yourself what that project's PyPI page says), and then update it
to contain at least Eric's list in the "GUI" section.  Does anyone
feel like doing that?  If not, we will close down the wiki and add the
list to the FAQ with a date.


A bient?t,

Armin.

From admalledd at gmail.com  Sun Sep 20 12:06:33 2015
From: admalledd at gmail.com (Eric Driggers)
Date: Sun, 20 Sep 2015 03:06:33 -0700
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
Message-ID: <CAK-ecOjj27OKRX5vVWp+xR4CG3n_vCXPeyTeUjY16wjzaPaRXw@mail.gmail.com>

For the compatibility wiki, if nothing major changes this week I feel
fine doing a large pass through it to try and update it. So long as
you don't mind me in the meanwhile on IRC asking silly questions about
some of them. I long ago found it to be a useful resource, and it
still places high on search results making it in my opinion something
worth trying to salvage it a bit.


On Sun, Sep 20, 2015 at 12:27 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Eric,
>
> Thanks for this list that summarizes the situation!  It's information
> that we should put or link to from somewhere (the FAQ?).
>
> Maybe it should be put in the compatibility wiki, but that wiki looks
> really, really outdated now, to the point that fijal suggested that we
> might as well close it down.  The experiment of crowd-sourcing this
> wiki has failed.
>
> Nowadays you can, more and more often, go to the other project's
> website or PyPI page and see a mention about the PyPy compatibility
> status there.  But it doesn't help much when gathering a list of all
> GUI toolkits available (say).  So I would say that we should clean up
> from our wiki all projects with "not working" or "unknown" status (go
> check yourself what that project's PyPI page says), and then update it
> to contain at least Eric's list in the "GUI" section.  Does anyone
> feel like doing that?  If not, we will close down the wiki and add the
> list to the FAQ with a date.
>
>
> A bient?t,
>
> Armin.

From lac at openend.se  Sun Sep 20 15:11:18 2015
From: lac at openend.se (Laura Creighton)
Date: Sun, 20 Sep 2015 15:11:18 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
Message-ID: <201509201311.t8KDBIjc026007@fido.openend.se>

In a message of Sun, 20 Sep 2015 09:27:03 +0200, Armin Rigo writes:
>Nowadays you can, more and more often, go to the other project's
>website or PyPI page and see a mention about the PyPy compatibility
>status there.  But it doesn't help much when gathering a list of all
>GUI toolkits available (say).  So I would say that we should clean up
>from our wiki all projects with "not working" or "unknown" status (go
>check yourself what that project's PyPI page says), and then update it
>to contain at least Eric's list in the "GUI" section.  Does anyone
>feel like doing that?  If not, we will close down the wiki and add the
>list to the FAQ with a date.
>
>
>A bient?t,
>
>Armin.

I think the FAQ is better, unless we find a new way to really, really
advertise the wikis existence.  Because most people I meet simply don't
know that it is there.

Laura

From fijall at gmail.com  Sun Sep 20 18:08:10 2015
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 20 Sep 2015 18:08:10 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <201509201311.t8KDBIjc026007@fido.openend.se>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
 <201509201311.t8KDBIjc026007@fido.openend.se>
Message-ID: <CAK5idxTfnbuoDC=wq6TNC3b470sRN=v_oVdMset5_WBcSwKr-w@mail.gmail.com>

I don't think this is true Laura, it shows up a lot in google searches

On Sun, Sep 20, 2015 at 3:11 PM, Laura Creighton <lac at openend.se> wrote:
> In a message of Sun, 20 Sep 2015 09:27:03 +0200, Armin Rigo writes:
>>Nowadays you can, more and more often, go to the other project's
>>website or PyPI page and see a mention about the PyPy compatibility
>>status there.  But it doesn't help much when gathering a list of all
>>GUI toolkits available (say).  So I would say that we should clean up
>>from our wiki all projects with "not working" or "unknown" status (go
>>check yourself what that project's PyPI page says), and then update it
>>to contain at least Eric's list in the "GUI" section.  Does anyone
>>feel like doing that?  If not, we will close down the wiki and add the
>>list to the FAQ with a date.
>>
>>
>>A bient?t,
>>
>>Armin.
>
> I think the FAQ is better, unless we find a new way to really, really
> advertise the wikis existence.  Because most people I meet simply don't
> know that it is there.
>
> Laura
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From arigo at tunes.org  Sun Sep 20 18:37:05 2015
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 20 Sep 2015 18:37:05 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAK5idxTfnbuoDC=wq6TNC3b470sRN=v_oVdMset5_WBcSwKr-w@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
 <201509201311.t8KDBIjc026007@fido.openend.se>
 <CAK5idxTfnbuoDC=wq6TNC3b470sRN=v_oVdMset5_WBcSwKr-w@mail.gmail.com>
Message-ID: <CAMSv6X3O7gabubaa9r7hzDKhjLD+J4ugWnmB0KGW3m6S-DPf9Q@mail.gmail.com>

Hi Maciej,

On Sun, Sep 20, 2015 at 6:08 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> I don't think this is true Laura, it shows up a lot in google searches

I don't think you can argue against Laura's "most people I meet simply
don't know that it is there", which is in all likelihood a truth about
the people that Laura meets.  However what you said is also true: it
does show up in various searches like "pypy gui".  I think we can only
conclude that there are many people that don't have the idea of using
google to do the same searches as we do.


A bient?t,

Armin.

From cfbolz at gmx.de  Sun Sep 20 18:41:15 2015
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 20 Sep 2015 18:41:15 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAMSv6X3O7gabubaa9r7hzDKhjLD+J4ugWnmB0KGW3m6S-DPf9Q@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
 <201509201311.t8KDBIjc026007@fido.openend.se>
 <CAK5idxTfnbuoDC=wq6TNC3b470sRN=v_oVdMset5_WBcSwKr-w@mail.gmail.com>
 <CAMSv6X3O7gabubaa9r7hzDKhjLD+J4ugWnmB0KGW3m6S-DPf9Q@mail.gmail.com>
Message-ID: <659522cf-8d23-44b9-a406-a46b54300bba@email.android.com>

There's a simple solution anyway, which is to link from the FAQ to the wiki. 

Carl Friedrich

On September 20, 2015 6:37:05 PM GMT+02:00, Armin Rigo <arigo at tunes.org> wrote:
>Hi Maciej,
>
>On Sun, Sep 20, 2015 at 6:08 PM, Maciej Fijalkowski <fijall at gmail.com>
>wrote:
>> I don't think this is true Laura, it shows up a lot in google
>searches
>
>I don't think you can argue against Laura's "most people I meet simply
>don't know that it is there", which is in all likelihood a truth about
>the people that Laura meets.  However what you said is also true: it
>does show up in various searches like "pypy gui".  I think we can only
>conclude that there are many people that don't have the idea of using
>google to do the same searches as we do.
>
>
>A bient?t,
>
>Armin.
>_______________________________________________
>pypy-dev mailing list
>pypy-dev at python.org
>https://mail.python.org/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150920/e6f9324d/attachment.html>

From lac at openend.se  Sun Sep 20 18:42:01 2015
From: lac at openend.se (Laura Creighton)
Date: Sun, 20 Sep 2015 18:42:01 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAMSv6X3O7gabubaa9r7hzDKhjLD+J4ugWnmB0KGW3m6S-DPf9Q@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
 <201509201311.t8KDBIjc026007@fido.openend.se>
 <CAK5idxTfnbuoDC=wq6TNC3b470sRN=v_oVdMset5_WBcSwKr-w@mail.gmail.com>
 <CAMSv6X3O7gabubaa9r7hzDKhjLD+J4ugWnmB0KGW3m6S-DPf9Q@mail.gmail.com>
Message-ID: <201509201642.t8KGg1Bs014027@fido.openend.se>

In a message of Sun, 20 Sep 2015 18:37:05 +0200, Armin Rigo writes:
>Hi Maciej,
>
>On Sun, Sep 20, 2015 at 6:08 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> I don't think this is true Laura, it shows up a lot in google searches
>
>I don't think you can argue against Laura's "most people I meet simply
>don't know that it is there", which is in all likelihood a truth about
>the people that Laura meets.  However what you said is also true: it
>does show up in various searches like "pypy gui".  I think we can only
>conclude that there are many people that don't have the idea of using
>google to do the same searches as we do.

And what they do is mail me and ask ...  This biases my sample, of
course.

Laura

>
>
>A bient?t,
>
>Armin.

From bokr at oz.net  Sun Sep 20 19:19:03 2015
From: bokr at oz.net (Bengt Richter)
Date: Sun, 20 Sep 2015 19:19:03 +0200
Subject: [pypy-dev] State of GUI toolkits with PyPy?
In-Reply-To: <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
References: <CAK-ecOhKmo_=b6y4tWCTF+nfj2SQSiTbc4bupHJYQ2rvB3-KTg@mail.gmail.com>
 <CAK5idxTJaHNG6xAV7Eb7HSSTRmxqegj6uL1vGbRE4yEb8g8RDw@mail.gmail.com>
 <CA+HjJriGhTrnfi77DdU2BOQuBfz-EArCqU-dW6=wOSnKbhwFLQ@mail.gmail.com>
 <CA+HjJrivhRcL+E1CAkf8LpxnO+aETRnkr=xNNMsj+CJxSKBanw@mail.gmail.com>
 <CAK-ecOg3OOYMzzo1_w8mCMSFKjuLW1Y-fHRLGmESCBP4_MTuCw@mail.gmail.com>
 <CAMSv6X2_0++vNhXAgxDNHb5D3YmgyAutgA_pefmrVLNmGd0UYA@mail.gmail.com>
Message-ID: <mtmpgp$5hf$1@ger.gmane.org>

On 09/20/2015 09:27 AM Armin Rigo wrote:
> Hi Eric,
>
> Thanks for this list that summarizes the situation!  It's information
> that we should put or link to from somewhere (the FAQ?).
>
> Maybe it should be put in the compatibility wiki, but that wiki looks
> really, really outdated now, to the point that fijal suggested that we
> might as well close it down.  The experiment of crowd-sourcing this
> wiki has failed.
>
> Nowadays you can, more and more often, go to the other project's
> website or PyPI page and see a mention about the PyPy compatibility
> status there.  But it doesn't help much when gathering a list of all
> GUI toolkits available (say).  So I would say that we should clean up
> from our wiki all projects with "not working" or "unknown" status (go
> check yourself what that project's PyPI page says), and then update it
> to contain at least Eric's list in the "GUI" section.  Does anyone
> feel like doing that?  If not, we will close down the wiki and add the
> list to the FAQ with a date.
>
>
> A bient??t,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

1) If you ask me, the most important place to have up to date
top level info presenting pypy as you'd like it presented,
with references to further info is:

     https://en.wikipedia.org/wiki/PyPy

2) The other thing I'd like to see is less dead links.

Maybe someone could see if pypy can run
     https://pypi.python.org/pypi/LinkChecker
and set up a cron job to pester the page maintainers? ;-)
(disclaimer: have not looked at LinkChecker, but seems appropriate)

(might have to tweak it to detect dead wiki links though, since they
produce an invitation to create a new page, not a 404 -- but you'd
think wiki software would come with a tool for this ?)

3) IMO most wiki searchers will just be looking for info, and
will not be able or not have the time to contribute, but if they
could run a script that generated useful info about the compatibility
of pypy to their platform/software context in the form of a  report
that could be pasted as the body of an email and sent for automatic processing
(modulo spam control ;-/), and which contained an an html section to extend a
compatibility table, then maybe crowd sourcing would work a little better?

The qubes-os.org project does this to generate a table of hardware compatibility
to help people identify CPUs and chipsets that can run their os with full or
partial success. Their hardware compatibility page is table is
     https://www.qubes-os.org/hcl/
they explain how to contribute new data here:
     https://www.qubes-os.org/doc/HCL/
Maybe something analogous could be done for pypy compatibility?

4) BTW, they seem to be using cpython2.7 a lot, and I'm sure speedup would be good ;-)
It's an interesting project. Security by compartmentalization, using xen and fedora, with
others coming.

Just thought I'd throw something into the idea pot ;-)

Regards,
Bengt Richter
(lurking mostly, off doing other things ;-)










From cherian.rosh at gmail.com  Mon Sep 21 21:58:07 2015
From: cherian.rosh at gmail.com (Roshan Cherian)
Date: Mon, 21 Sep 2015 12:58:07 -0700
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAMSv6X1d7Rs-7vbo3f9wJ=wQ6ZN0e3fmFw6fOVhPSCosA2n6_Q@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
 <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>
 <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
 <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>
 <CAMSv6X1d7Rs-7vbo3f9wJ=wQ6ZN0e3fmFw6fOVhPSCosA2n6_Q@mail.gmail.com>
Message-ID: <CAHL69gGg9i9mHvJaChAOLe+296KOuJPVGXAxEWFKssBH_fdrLQ@mail.gmail.com>

Thanks Armin and Maciej. I now have the code running on a box without gcc
on it and I don't use ffi.dlopen, I now distribute the generated
_ical_cffi_ext.c which was generated using ffi.compile() and use distuitils
to build it to site-packges of pypy. Thanks a lot for this.

I do have a question on memory management, currently I am using lib.
Currently lib provides me with icalcomponent_free which I pass in as the
function to be used in __del__. Should I be using this or should I be using
something specific from the python extension? This is what I see in the
python extension which was created.

static void _cffi_d_icalcomponent_free(icalcomponent * x0)
{
  icalcomponent_free(x0);
}
#ifndef PYPY_VERSION
static PyObject *
_cffi_f_icalcomponent_free(PyObject *self, PyObject *arg0)
{
  icalcomponent * x0;
  Py_ssize_t datasize;

  datasize = _cffi_prepare_pointer_call_argument(
      _cffi_type(1), arg0, (char **)&x0);
  if (datasize != 0) {
    if (datasize < 0)
      return NULL;
    x0 = (icalcomponent *)alloca((size_t)datasize);
    memset((void *)x0, 0, (size_t)datasize);
    if (_cffi_convert_array_from_object((char *)x0, _cffi_type(1), arg0) <
0)
      return NULL;
  }

  Py_BEGIN_ALLOW_THREADS
  _cffi_restore_errno();
  { icalcomponent_free(x0); }
  _cffi_save_errno();
  Py_END_ALLOW_THREADS

  (void)self; /* unused */
  Py_INCREF(Py_None);
  return Py_None;
}
#else
#  define _cffi_f_icalcomponent_free _cffi_d_icalcomponent_free
#endif

Thanks for the help,
-Roshan

On Fri, Sep 18, 2015 at 3:49 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Roshan,
>
> On Fri, Sep 18, 2015 at 10:02 AM, Roshan Cherian <cherian.rosh at gmail.com>
> wrote:
> > _icaltimezonechange is opaque as its in src/libical/icaltimezone.c a c
> file
> > and not in in ical.h. However this struct is required for my purpose.
>
> All structs must be declared in C before you import them into Python.
> In this case, the "cheat" to access this structure is the same as if
> you wrote C code: you need to give the real C compiler a declaration
> of this struct.  Then you can import it as you did.  (So you need to
> write this struct twice.)
>
> ffi.set_source("_ical_cffi_ext",
>     """ // passed to the real C compiler
>         #include <libical/ical.h>
>
>         struct _icaltimezonechange {
>             int          utc_offset;
>             int          prev_utc_offset;
>             int          year;          /**< Actual year, e.g. 2001. */
>             int          month;         /**< 1 (Jan) to 12 (Dec). */
>             int          day;
>             int          hour;
>             int          minute;
>             int          second;
>             int          is_daylight;
>         };
>     """,
>         include_dirs=['./include'],    # where ical.h is
>         libraries=['ical'],
>         library_dirs=['./lib'],)   # or a list of libraries to link with
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150921/4c5f88c0/attachment.html>

From phyo.arkarlwin at gmail.com  Mon Sep 21 22:19:37 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Tue, 22 Sep 2015 02:49:37 +0630
Subject: [pypy-dev] Trying to support PyPy on PyAV
Message-ID: <CA+HjJrgdGG8_H3-g+ZSQ7D8r8SOdgMFBfXfM1yeuySSd=nmmzg@mail.gmail.com>

Mike Boers is trying to support PyAV (python Audio Video
editing/merging/converting library based on FFMPEG) .

The current master fails 6 of the unit tests:

   - 4 of them are in __repr__ methods, and seem to be due to basic
   difference in module name handling.
   - 1 is with Numpy; I expect there was an API change there.
   - 2 is with memoryviews; I suspect there are marginal differences in
   that implementation.


https://github.com/mikeboers/PyAV/issues/130

I am forwarding it here.

Thanks

Phyo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150922/490fa51d/attachment.html>

From arigo at tunes.org  Tue Sep 22 11:05:14 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 22 Sep 2015 11:05:14 +0200
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAHL69gGg9i9mHvJaChAOLe+296KOuJPVGXAxEWFKssBH_fdrLQ@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
 <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>
 <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
 <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>
 <CAMSv6X1d7Rs-7vbo3f9wJ=wQ6ZN0e3fmFw6fOVhPSCosA2n6_Q@mail.gmail.com>
 <CAHL69gGg9i9mHvJaChAOLe+296KOuJPVGXAxEWFKssBH_fdrLQ@mail.gmail.com>
Message-ID: <CAMSv6X0vDGm0Z97tRC_7=EpbmUfvQv_P8+=oz53G_k182mJ6cg@mail.gmail.com>

Hi Roshan,

On Mon, Sep 21, 2015 at 9:58 PM, Roshan Cherian <cherian.rosh at gmail.com> wrote:
> I do have a question on memory management, currently I am using lib.
> Currently lib provides me with icalcomponent_free which I pass in as the
> function to be used in __del__. Should I be using this or should I be using
> something specific from the python extension? This is what I see in the
> python extension which was created.
>
> static void _cffi_d_icalcomponent_free(icalcomponent * x0)
> (...)

This is the code in C that implements the function
"lib.icalcomponent_free()".  There are similar pieces of code for all
other functions.  What are you asking specifically?  If it's ok to
call such functions from a __del__()?  Yes, it is.

Sometimes you can use ffi.gc() instead and give the function
"lib.icalcomponent_free" directly as a second argument; then you don't
need a __del__.  But if the __del__ solution suits your case, then
that's fine.


A bient?t,

Armin.

From cherian.rosh at gmail.com  Tue Sep 22 19:37:47 2015
From: cherian.rosh at gmail.com (Roshan Cherian)
Date: Tue, 22 Sep 2015 10:37:47 -0700
Subject: [pypy-dev] cffi dlopen
In-Reply-To: <CAMSv6X0vDGm0Z97tRC_7=EpbmUfvQv_P8+=oz53G_k182mJ6cg@mail.gmail.com>
References: <CAHL69gGpdp7WOcfoTRyWB5HbWjgv+59Pk2jb2=UWCeHeoyVU5g@mail.gmail.com>
 <CAK5idxRk7chxdYYaE4dVdv-_gFsK+EH1Bvo2LS_UrGfwEi4gXw@mail.gmail.com>
 <CAMSv6X06VxWQTwUZTJL6UnkkE1wycvh27pM7W=R0FUu7CK3u-g@mail.gmail.com>
 <CAHL69gE61zbNRFo4CRUZSFTu4zzaxPR6dPUq8HrUFBefu=xvRQ@mail.gmail.com>
 <CAMSv6X0B=36ev-gx69rXhh9_o6Tbeb9gW5o97wsiXzSOpz8WYA@mail.gmail.com>
 <CAHL69gFRD_hUvukecdLVg38zre2NJL4V49mDNJccwf7iNagw=g@mail.gmail.com>
 <CAHL69gHpVYOLP=mVfgDmZtFJLqwR4Uk+2vo6FZjzenLA1vObpg@mail.gmail.com>
 <CAMSv6X1d7Rs-7vbo3f9wJ=wQ6ZN0e3fmFw6fOVhPSCosA2n6_Q@mail.gmail.com>
 <CAHL69gGg9i9mHvJaChAOLe+296KOuJPVGXAxEWFKssBH_fdrLQ@mail.gmail.com>
 <CAMSv6X0vDGm0Z97tRC_7=EpbmUfvQv_P8+=oz53G_k182mJ6cg@mail.gmail.com>
Message-ID: <CAHL69gF7resUTLJUJrX0pF8+7YZJW3LAn68wCJwbHoQpajhWcw@mail.gmail.com>

Thanks Armin. Yes __del__ fits my case and thanks for giving me so much
information.

Thanks,
-Roshan

On Tue, Sep 22, 2015 at 2:05 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Roshan,
>
> On Mon, Sep 21, 2015 at 9:58 PM, Roshan Cherian <cherian.rosh at gmail.com>
> wrote:
> > I do have a question on memory management, currently I am using lib.
> > Currently lib provides me with icalcomponent_free which I pass in as the
> > function to be used in __del__. Should I be using this or should I be
> using
> > something specific from the python extension? This is what I see in the
> > python extension which was created.
> >
> > static void _cffi_d_icalcomponent_free(icalcomponent * x0)
> > (...)
>
> This is the code in C that implements the function
> "lib.icalcomponent_free()".  There are similar pieces of code for all
> other functions.  What are you asking specifically?  If it's ok to
> call such functions from a __del__()?  Yes, it is.
>
> Sometimes you can use ffi.gc() instead and give the function
> "lib.icalcomponent_free" directly as a second argument; then you don't
> need a __del__.  But if the __del__ solution suits your case, then
> that's fine.
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150922/50534da0/attachment.html>

From tuom.larsen at gmail.com  Mon Sep 28 15:57:22 2015
From: tuom.larsen at gmail.com (Tuom Larsen)
Date: Mon, 28 Sep 2015 15:57:22 +0200
Subject: [pypy-dev] Copy of list
Message-ID: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>

Dear PyPy developers!

In CPython, a common idiom to copy a list is to use slice, as in:

    copy = original[:]

I noticed that under PyPy 2.6.0 it seems quite a bit slower than using
`list` constructor:

    from timeit import timeit
    print timeit('b = a[:]', 'a = list(range(100))')    # 0.0732719898224
    print timeit('b = list(a)', 'a = list(range(100))') # 0.00285792350769

Please, could some comment on what is the preferred way to copy a list
under PyPy? Should I try to avoid the "slice way"?

Thanks!

From vincent.legoll at gmail.com  Mon Sep 28 18:47:11 2015
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Mon, 28 Sep 2015 18:47:11 +0200
Subject: [pypy-dev] Copy of list
In-Reply-To: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
Message-ID: <CAEwRq=pNhS+DOzt5YK5YSvozFE13cwLprGcrFRghMAYJhk-Bhw@mail.gmail.com>

Hello,

is your code actually such a heavy list-copy-through-slicing user ?

This question is independent from pypy's eventual desire to speed
this python "idiom", though.

I myself was using it, but went to use list(), as that look more natural,
to my eyes, but that's a matter of taste anyways, I think...


On Mon, Sep 28, 2015 at 3:57 PM, Tuom Larsen <tuom.larsen at gmail.com> wrote:
> Dear PyPy developers!
>
> In CPython, a common idiom to copy a list is to use slice, as in:
>
>     copy = original[:]
>
> I noticed that under PyPy 2.6.0 it seems quite a bit slower than using
> `list` constructor:
>
>     from timeit import timeit
>     print timeit('b = a[:]', 'a = list(range(100))')    # 0.0732719898224
>     print timeit('b = list(a)', 'a = list(range(100))') # 0.00285792350769
>
> Please, could some comment on what is the preferred way to copy a list
> under PyPy? Should I try to avoid the "slice way"?
>
> Thanks!
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev



-- 
Vincent Legoll

From oscar.j.benjamin at gmail.com  Mon Sep 28 19:21:33 2015
From: oscar.j.benjamin at gmail.com (Oscar Benjamin)
Date: Mon, 28 Sep 2015 17:21:33 +0000
Subject: [pypy-dev] Copy of list
In-Reply-To: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
Message-ID: <CAHVvXxRjOc+Ade6w4eRYNjdiH3b=7dCsM0-+Q-qKkmQ8ACcphw@mail.gmail.com>

On Mon, 28 Sep 2015 at 14:57 Tuom Larsen <tuom.larsen at gmail.com> wrote:

> Dear PyPy developers!
>
> In CPython, a common idiom to copy a list is to use slice, as in:
>
>     copy = original[:]
>
> I noticed that under PyPy 2.6.0 it seems quite a bit slower than using
> `list` constructor:
>
>     from timeit import timeit
>     print timeit('b = a[:]', 'a = list(range(100))')    # 0.0732719898224
>     print timeit('b = list(a)', 'a = list(range(100))') # 0.00285792350769
>
> Please, could some comment on what is the preferred way to copy a list
> under PyPy? Should I try to avoid the "slice way"?
>

I don't get the same timings here:

enojb at it054759:~$ pypy -m timeit -s 'a = list(range(100))' 'b = a[:]'
1000000000 loops, best of 3: 0.00142 usec per loop
enojb at it054759:~$ pypy -m timeit -s 'a = list(range(100))' 'b = list(a)'
1000000000 loops, best of 3: 0.00109 usec per loop

So for me it's about the same. However if you look closer you'll see that
it's about 1 nanosecond in either case. That's really a very short time.
Why is so short? I guess because it's not really copying the lists. If I
try with a much bigger list it takes the same time:

enojb at it054759:~$ pypy -m timeit -s 'a = list(range(1000000))' 'b = a[:]'
1000000000 loops, best of 3: 0.00142 usec per loop
enojb at it054759:~$ pypy -m timeit -s 'a = list(range(1000000))' 'b =
list(a)'
1000000000 loops, best of 3: 0.00105 usec per loop

I would guess that the actual copy has somehow been optimised away. If I
make the expression do some actual work instead of just copying a list then
the differences are insignificant:

enojb at it054759:~$ pypy -m timeit -s 'a = list(range(100))' 'b = sum(a[:])'
1000000 loops, best of 3: 0.212 usec per loop
enojb at it054759:~$ pypy -m timeit -s 'a = list(range(100))' 'b =
sum(list(a))'
1000000 loops, best of 3: 0.205 usec per loop

So I wouldn't worry about how many nanoseconds the copy takes. Finish your
application and then if the difference between slice/list copy actually
affects whole application performance in a significant way then this
question may be worth considering.

Until then just code it whichever way seems clearest to you. Bear in mind
that the two are not equivalent since b[:] will return a tuple if b is a
tuple, or a range if b is a range etc.

--
Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150928/42a22f6e/attachment.html>

From arigo at tunes.org  Mon Sep 28 20:17:10 2015
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 28 Sep 2015 20:17:10 +0200
Subject: [pypy-dev] Copy of list
In-Reply-To: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
Message-ID: <CAMSv6X3wuqG46R3XXOx3b5WYnnXucRW9UM+zPXrYssPrhc-27A@mail.gmail.com>

Hi Tuom,

On Mon, Sep 28, 2015 at 3:57 PM, Tuom Larsen <tuom.larsen at gmail.com> wrote:
>     from timeit import timeit
>     print timeit('b = a[:]', 'a = list(range(100))')    # 0.0732719898224
>     print timeit('b = list(a)', 'a = list(range(100))') # 0.00285792350769

In addition to the other comments, this is not testing what you think
it is: 'range(100)' returns a list optimized for being a range, and
'list(range(100))' does it too.  You can see it like this:

>>>> import __pypy__
>>>> __pypy__.strategy([])
'EmptyListStrategy'
>>>> __pypy__.strategy(range(100))
'SimpleRangeListStrategy'
>>>> __pypy__.strategy(list(range(100)))
'SimpleRangeListStrategy'

The SimpleRangeListStrategy means that the list is implemented as just
a number, here 100.

>>>> __pypy__.strategy(range(100)[:])
'IntegerListStrategy'

So we discover here that slicing a range-list is not as optimized as
it could be.  It expands it to an array containing all the integers.
That's the reason for why the slicing version seems slower in your
tests.  But optimizing that would of course be pointless in almost any
real program.


A bient?t,

Armin.

From tuom.larsen at gmail.com  Tue Sep 29 07:31:20 2015
From: tuom.larsen at gmail.com (Tuom Larsen)
Date: Tue, 29 Sep 2015 07:31:20 +0200
Subject: [pypy-dev] Copy of list
In-Reply-To: <CAMSv6X3wuqG46R3XXOx3b5WYnnXucRW9UM+zPXrYssPrhc-27A@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
 <CAMSv6X3wuqG46R3XXOx3b5WYnnXucRW9UM+zPXrYssPrhc-27A@mail.gmail.com>
Message-ID: <CALkqZMdhPgPQcttaRWRmp7Qx2aKH3niLQ_VLmed9LO_UcTJCQg@mail.gmail.com>

Hello Armin,

Thanks for the answer!

On Mon, Sep 28, 2015 at 8:17 PM, Armin Rigo <arigo at tunes.org> wrote:
>
> In addition to the other comments, this is not testing what you think
> it is: 'range(100)' returns a list optimized for being a range, and
> 'list(range(100))' does it too.  You can see it like this:
>
>>>>> import __pypy__
>>>>> __pypy__.strategy([])
> 'EmptyListStrategy'
>>>>> __pypy__.strategy(range(100))
> 'SimpleRangeListStrategy'
>>>>> __pypy__.strategy(list(range(100)))
> 'SimpleRangeListStrategy'
>
> The SimpleRangeListStrategy means that the list is implemented as just
> a number, here 100.
>
>>>>> __pypy__.strategy(range(100)[:])
> 'IntegerListStrategy'
>
> So we discover here that slicing a range-list is not as optimized as
> it could be.  It expands it to an array containing all the integers.
> That's the reason for why the slicing version seems slower in your
> tests.  But optimizing that would of course be pointless in almost any
> real program.

However, I still get "slice-way"  twice as slow as "constructor-way"
when I use normal lists:

    from timeit import timeit
    print timeit('b = a[:]', 'a = [1,2,3,4,5,6,7,8,9,0]')    # 0.0329349040985
    print timeit('b = list(a)', 'a = [1,2,3,4,5,6,7,8,9,0]') # 0.0171940326691

or:

    pypy -m timeit -s 'a = [1,2,3,4,5,6,7,8,9,0]' 'b = a[:]' # 0.0306
usec per loop
    pypy -m timeit -s 'a = [1,2,3,4,5,6,7,8,9,0]' 'b = list(a)' #
0.0149 usec per loop

Please, let me rephrase my question: currently I use `[:]` because it
is faster in CPython (0.131 usec vs 0.269 usec per loop). I almost
don't mind changing it to `list()` because of PyPy but I was wondering
what do PyPy developers recommend. I don't understand why is `[:]`
twice as slow as `list()` as it seems it should do the same thing
(create a list and copy the content). So my question is, is there a
reason why `list()` is fundamentally faster, and then I would switch
to it, or maybe/perhaps/somewhere-in-the-future PyPy would make it as
fast as `[:]`, as it does the same amount of work, and then I could
leave it as it is (`[:]`)?

From arigo at tunes.org  Tue Sep 29 09:25:30 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 29 Sep 2015 09:25:30 +0200
Subject: [pypy-dev] Copy of list
In-Reply-To: <CALkqZMdhPgPQcttaRWRmp7Qx2aKH3niLQ_VLmed9LO_UcTJCQg@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
 <CAMSv6X3wuqG46R3XXOx3b5WYnnXucRW9UM+zPXrYssPrhc-27A@mail.gmail.com>
 <CALkqZMdhPgPQcttaRWRmp7Qx2aKH3niLQ_VLmed9LO_UcTJCQg@mail.gmail.com>
Message-ID: <CAMSv6X30MSguvFt73myw5zJsSZK_-RAWyeJxLx5eEpNfzYg3NQ@mail.gmail.com>

Hi Tuom,

On Tue, Sep 29, 2015 at 7:31 AM, Tuom Larsen <tuom.larsen at gmail.com> wrote:
> Please, let me rephrase my question: currently I use `[:]` because it
> is faster in CPython (0.131 usec vs 0.269 usec per loop). I almost
> don't mind changing it to `list()` because of PyPy but I was wondering
> what do PyPy developers recommend. I don't understand why is `[:]`
> twice as slow as `list()` as it seems it should do the same thing
> (create a list and copy the content).

Looking at the jit logs, it is tripped by a RPython function with a
loop in its slow-path.  Fixed in 4e688540cfe9.

There is still a bit of overhead.  For example, lst[:] is equivalent
to lst[0:9223372036854775807].  The general logic looks like this:
when doing lst[a:b], if b > len(lst) then replace b with len(lst).
This means here a check if 9223372036854775807 > len(lst)...  It is
not possible that the length of a list be that huge, but this
knowledge is not codified explicitly.

Yes, we could improve that in the future.
But this is really advanced details.  You should write 'list()' or
'[:]' as you feel more natural, or maybe as benefits the speed of
CPython if it makes an important difference there.  Using 'timeit' to
measure microbenchmarks in PyPy may or may not give a useful result.
In this case it did only after you stopped using range() and only
because we don't have more advanced optimizations that realize that
the resulting list is not needed at all.  In general, you should not
rely on it.

What you should do instead is measure how much time is spent in some
real loop of your algorithm, and compare it with variants.  (Make sure
every variant is run in its own process, otherwise the JITting of
similar pieces of code might interfere in unexpected ways.)  If you're
lucky you may be able to find a variant that is overall much faster.
If you're not, it means that what you're changing is not relevant for
performance.


A bient?t,

Armin.

From niki.spahiev at gmail.com  Tue Sep 29 11:11:30 2015
From: niki.spahiev at gmail.com (Niki Spahiev)
Date: Tue, 29 Sep 2015 12:11:30 +0300
Subject: [pypy-dev] FIY: Basic Block Versioning JIT
Message-ID: <mudkk2$fbp$1@ger.gmane.org>

http://pointersgonewild.com/2015/09/24/basic-block-versioning-my-best-result-yet/

HTH
Niki


From tuom.larsen at gmail.com  Tue Sep 29 12:27:25 2015
From: tuom.larsen at gmail.com (Tuom Larsen)
Date: Tue, 29 Sep 2015 12:27:25 +0200
Subject: [pypy-dev] Copy of list
In-Reply-To: <CAMSv6X30MSguvFt73myw5zJsSZK_-RAWyeJxLx5eEpNfzYg3NQ@mail.gmail.com>
References: <CALkqZMfbcXibdbBOSR8P_3XSDxk9qsJuqBb+yXHHf37iVuX-dA@mail.gmail.com>
 <CAMSv6X3wuqG46R3XXOx3b5WYnnXucRW9UM+zPXrYssPrhc-27A@mail.gmail.com>
 <CALkqZMdhPgPQcttaRWRmp7Qx2aKH3niLQ_VLmed9LO_UcTJCQg@mail.gmail.com>
 <CAMSv6X30MSguvFt73myw5zJsSZK_-RAWyeJxLx5eEpNfzYg3NQ@mail.gmail.com>
Message-ID: <CALkqZMdT8F1NvL-kxizv_hExmwJ0RJ31gYzUBnSkEYOF41nUgA@mail.gmail.com>

Hi Armin,

thanks a lot, both for the explanation and the fix! I will try it soon.

Have a nice day!

Tuom

PS: The speed difference came from larger piece of code, which I tried
to reproduce in "minimal viable test case". Hence that `timeit`, where
it showed up as well. But in any case, thanks a lot once more!


On Tue, Sep 29, 2015 at 9:25 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Tuom,
>
> On Tue, Sep 29, 2015 at 7:31 AM, Tuom Larsen <tuom.larsen at gmail.com> wrote:
>> Please, let me rephrase my question: currently I use `[:]` because it
>> is faster in CPython (0.131 usec vs 0.269 usec per loop). I almost
>> don't mind changing it to `list()` because of PyPy but I was wondering
>> what do PyPy developers recommend. I don't understand why is `[:]`
>> twice as slow as `list()` as it seems it should do the same thing
>> (create a list and copy the content).
>
> Looking at the jit logs, it is tripped by a RPython function with a
> loop in its slow-path.  Fixed in 4e688540cfe9.
>
> There is still a bit of overhead.  For example, lst[:] is equivalent
> to lst[0:9223372036854775807].  The general logic looks like this:
> when doing lst[a:b], if b > len(lst) then replace b with len(lst).
> This means here a check if 9223372036854775807 > len(lst)...  It is
> not possible that the length of a list be that huge, but this
> knowledge is not codified explicitly.
>
> Yes, we could improve that in the future.
> But this is really advanced details.  You should write 'list()' or
> '[:]' as you feel more natural, or maybe as benefits the speed of
> CPython if it makes an important difference there.  Using 'timeit' to
> measure microbenchmarks in PyPy may or may not give a useful result.
> In this case it did only after you stopped using range() and only
> because we don't have more advanced optimizations that realize that
> the resulting list is not needed at all.  In general, you should not
> rely on it.
>
> What you should do instead is measure how much time is spent in some
> real loop of your algorithm, and compare it with variants.  (Make sure
> every variant is run in its own process, otherwise the JITting of
> similar pieces of code might interfere in unexpected ways.)  If you're
> lucky you may be able to find a variant that is overall much faster.
> If you're not, it means that what you're changing is not relevant for
> performance.
>
>
> A bient?t,
>
> Armin.

From arigo at tunes.org  Tue Sep 29 12:40:10 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 29 Sep 2015 12:40:10 +0200
Subject: [pypy-dev] FIY: Basic Block Versioning JIT
In-Reply-To: <mudkk2$fbp$1@ger.gmane.org>
References: <mudkk2$fbp$1@ger.gmane.org>
Message-ID: <CAMSv6X3hX06SLgCg30r0M_4Te+GKB3uABsW7XaPTz9iPn3Agaw@mail.gmail.com>

Hi Niki,

On Tue, Sep 29, 2015 at 11:11 AM, Niki Spahiev <niki.spahiev at gmail.com> wrote:
> http://pointersgonewild.com/2015/09/24/basic-block-versioning-my-best-result-yet/

It would look cool if it was 2005.  To me, in 2015, it sounds
completely outdated...  I'm sure that PyPy or V8 are both able to
optimize away most type checks too, and do many more
optimizations on top of that that go beyond just removing some checks.
This is just an impression from reading the blog post you linked to,
but I'm not interested in reading more unless I'm told there are still
interesting new things in there.


A bient?t,

Armin.

From cfbolz at gmx.de  Tue Sep 29 13:18:02 2015
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 29 Sep 2015 13:18:02 +0200
Subject: [pypy-dev] FIY: Basic Block Versioning JIT
In-Reply-To: <CAMSv6X3hX06SLgCg30r0M_4Te+GKB3uABsW7XaPTz9iPn3Agaw@mail.gmail.com>
References: <mudkk2$fbp$1@ger.gmane.org>
 <CAMSv6X3hX06SLgCg30r0M_4Te+GKB3uABsW7XaPTz9iPn3Agaw@mail.gmail.com>
Message-ID: <560A736A.2010502@gmx.de>

On 29/09/15 12:40, Armin Rigo wrote:
> Hi Niki,
>
> On Tue, Sep 29, 2015 at 11:11 AM, Niki Spahiev <niki.spahiev at gmail.com> wrote:
>> http://pointersgonewild.com/2015/09/24/basic-block-versioning-my-best-result-yet/
>
> It would look cool if it was 2005.  To me, in 2015, it sounds
> completely outdated...  I'm sure that PyPy or V8 are both able to
> optimize away most type checks too, and do many more
> optimizations on top of that that go beyond just removing some checks.
> This is just an impression from reading the blog post you linked to,
> but I'm not interested in reading more unless I'm told there are still
> interesting new things in there.

One thing that's very cool in BBV that I'm not aware of any other JIT
doing is to have type-specialized entry points for uninlinable methods.
Ie if a method is not inlined then the caller calls a type specialized
entry point with all the local type knowledge taken into account. In
addition, the result type is propagated back out from the uninlined
method to the calling function.

Maybe we can think how to achieve that effect for call_assembler, but I
don't think it's entirely trivial.

Cheers,

Carl Friedrich

From arigo at tunes.org  Tue Sep 29 14:57:20 2015
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 29 Sep 2015 14:57:20 +0200
Subject: [pypy-dev] FIY: Basic Block Versioning JIT
In-Reply-To: <560A736A.2010502@gmx.de>
References: <mudkk2$fbp$1@ger.gmane.org>
 <CAMSv6X3hX06SLgCg30r0M_4Te+GKB3uABsW7XaPTz9iPn3Agaw@mail.gmail.com>
 <560A736A.2010502@gmx.de>
Message-ID: <CAMSv6X0FaTUkPVxfJfw8ZMgzuz7xfjK+tS0gqvp3zmVL4JivCQ@mail.gmail.com>

Hi,

On Tue, Sep 29, 2015 at 1:18 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> It would look cool if it was 2005.  To me, in 2015, it sounds
>> completely outdated...
>
> One thing that's very cool in BBV that I'm not aware of any other JIT
> doing is to have type-specialized entry points for uninlinable methods.

Right...  More generally the work is interesting as a way to compare
the Psyco-style, HHVM-style approach with tracing JITs.  It shows that
the former can be done simply and cleanly, probably more so than even
a simple tracing JIT can.  It pushes forward the idea to use a smaller
base language ("low-level javascript") which has a similar result to
the meta-tracing approach of PyPy.  It gives a good, modern point of
comparison for both approaches.  (Obviously, though, as author of
Psyco I'd have liked if it was even mentioned in this paper...  the
basic idea is exactly the same one.)


A bient?t,

Armin.

From william.leslie.ttg at gmail.com  Tue Sep 29 15:00:06 2015
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Tue, 29 Sep 2015 23:00:06 +1000
Subject: [pypy-dev] FIY: Basic Block Versioning JIT
In-Reply-To: <560A736A.2010502@gmx.de>
References: <mudkk2$fbp$1@ger.gmane.org>
 <CAMSv6X3hX06SLgCg30r0M_4Te+GKB3uABsW7XaPTz9iPn3Agaw@mail.gmail.com>
 <560A736A.2010502@gmx.de>
Message-ID: <CAHgd1hEUD4oM5SsJETHB_TJa305PrzjyGLei=MEKO9XeQnNydw@mail.gmail.com>

On 29 September 2015 at 21:18, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> One thing that's very cool in BBV that I'm not aware of any other JIT
> doing is to have type-specialized entry points for uninlinable methods.
> Ie if a method is not inlined then the caller calls a type specialized
> entry point with all the local type knowledge taken into account. In
> addition, the result type is propagated back out from the uninlined
> method to the calling function.

I couldn't help but think when I read this post last week that it's
like a dynamic equivalent of CFA2; which is exciting because CFA2 is
such a dramatic improvement over k-CFA for intraprocedural analysis.

It's good to see how well such a simple principle about specialising
type information can produce such good results.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

From luisjosenovoa at gmail.com  Wed Sep 30 14:24:39 2015
From: luisjosenovoa at gmail.com (=?UTF-8?Q?Luis_Jos=C3=A9_Novoa?=)
Date: Wed, 30 Sep 2015 08:24:39 -0400
Subject: [pypy-dev] About gurobipy
In-Reply-To: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
Message-ID: <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>

Hi All,

My name is Luis Novoa. Im working on a large scale optimization problem
using python/gurobipy for my implementation. I was wondering if any of you
in this list has used gurobipy with pypy, or if it is even possible at this
time.

Thanks in advance,

Luis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150930/08dfffc4/attachment.html>

From phyo.arkarlwin at gmail.com  Wed Sep 30 18:35:06 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Wed, 30 Sep 2015 23:05:06 +0630
Subject: [pypy-dev] About gurobipy
In-Reply-To: <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
Message-ID: <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>

On Wed, Sep 30, 2015 at 6:54 PM, Luis Jos? Novoa <luisjosenovoa at gmail.com>
wrote:

> gurobipy


Never heard of it.

Here are things PyPy Can help:

- If it is Pure Python
- If CExtensions are with CFFI
- If file objects (if any) are closed

PyPy will work fine and you can expect average 7x performance gain , up to
20-30x.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150930/700e00f1/attachment.html>

From arigo at tunes.org  Wed Sep 30 19:53:20 2015
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 30 Sep 2015 19:53:20 +0200
Subject: [pypy-dev] About gurobipy
In-Reply-To: <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
Message-ID: <CAMSv6X02Brv7NkTpCgAOyQL+FVFMDJSacxJYt8dFi5_AiatL6Q@mail.gmail.com>

Hi,

If you could point us to a place where we could have a quick look at
the CPython C extension code implementing gurobipy (not gurobi!), we
could give you a more precise answer.


A bient?t,

Armin.

From svpcom at gmail.com  Wed Sep 30 20:10:52 2015
From: svpcom at gmail.com (Vasily Evseenko)
Date: Wed, 30 Sep 2015 21:10:52 +0300
Subject: [pypy-dev] About gurobipy
In-Reply-To: <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
 <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
Message-ID: <560C25AC.8030609@gmail.com>

Hi,
Could you explain about closed file objects (do you mean open file
descriptors)?
I've never heard about this restriction before.

30.09.2015 19:35, Phyo Arkar ?????:
>
> On Wed, Sep 30, 2015 at 6:54 PM, Luis Jos? Novoa
> <luisjosenovoa at gmail.com <mailto:luisjosenovoa at gmail.com>> wrote:
>
>     gurobipy
>
>
> Never heard of it.
>
> Here are things PyPy Can help:
>
> - If it is Pure Python
> - If CExtensions are with CFFI
> - If file objects (if any) are closed 
>
> PyPy will work fine and you can expect average 7x performance gain ,
> up to 20-30x.
>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150930/3746878b/attachment.html>

From amauryfa at gmail.com  Wed Sep 30 20:17:26 2015
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 30 Sep 2015 20:17:26 +0200
Subject: [pypy-dev] About gurobipy
In-Reply-To: <560C25AC.8030609@gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
 <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
 <560C25AC.8030609@gmail.com>
Message-ID: <CAGmFidaWaxvZFdp1G46NVUirJ=jfC6nxxhu6YbSKeZfkSYYUEQ@mail.gmail.com>

2015-09-30 20:10 GMT+02:00 Vasily Evseenko <svpcom at gmail.com>:

> Hi,
> Could you explain about closed file objects (do you mean open file
> descriptors)?
> I've never heard about this restriction before.
>

PyPy uses a different garbage collection strategy, and unlike CPython,
objects are not deallocated as soon as the variable goes out of scope:
http://pypy.readthedocs.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

FWIW, Java has a very similar behavior.




>
> 30.09.2015 19:35, Phyo Arkar ?????:
>
>
> On Wed, Sep 30, 2015 at 6:54 PM, Luis Jos? Novoa <luisjosenovoa at gmail.com>
> wrote:
>
>> gurobipy
>
>
> Never heard of it.
>
> Here are things PyPy Can help:
>
> - If it is Pure Python
> - If CExtensions are with CFFI
> - If file objects (if any) are closed
>
> PyPy will work fine and you can expect average 7x performance gain , up to
> 20-30x.
>
>
>
>
> _______________________________________________
> pypy-dev mailing listpypy-dev at python.orghttps://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150930/16db6e1c/attachment.html>

From rymg19 at gmail.com  Wed Sep 30 20:17:50 2015
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Wed, 30 Sep 2015 13:17:50 -0500
Subject: [pypy-dev] About gurobipy
In-Reply-To: <560C25AC.8030609@gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
 <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
 <560C25AC.8030609@gmail.com>
Message-ID: <CAO41-mNTXv=z=PhfsHo=w0kmo05+EswdNRQ2cv3z-K+QsQpJBA@mail.gmail.com>

http://pypy.readthedocs.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

On Wed, Sep 30, 2015 at 1:10 PM, Vasily Evseenko <svpcom at gmail.com> wrote:

> Hi,
> Could you explain about closed file objects (do you mean open file
> descriptors)?
> I've never heard about this restriction before.
>
> 30.09.2015 19:35, Phyo Arkar ?????:
>
>
> On Wed, Sep 30, 2015 at 6:54 PM, Luis Jos? Novoa <luisjosenovoa at gmail.com>
> wrote:
>
>> gurobipy
>
>
> Never heard of it.
>
> Here are things PyPy Can help:
>
> - If it is Pure Python
> - If CExtensions are with CFFI
> - If file objects (if any) are closed
>
> PyPy will work fine and you can expect average 7x performance gain , up to
> 20-30x.
>
>
>
>
> _______________________________________________
> pypy-dev mailing listpypy-dev at python.orghttps://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150930/ee4fda40/attachment-0001.html>

From lac at openend.se  Wed Sep 30 20:39:12 2015
From: lac at openend.se (Laura Creighton)
Date: Wed, 30 Sep 2015 20:39:12 +0200
Subject: [pypy-dev] close your files
In-Reply-To: <CAO41-mNTXv=z=PhfsHo=w0kmo05+EswdNRQ2cv3z-K+QsQpJBA@mail.gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
 <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
 <560C25AC.8030609@gmail.com>
 <CAO41-mNTXv=z=PhfsHo=w0kmo05+EswdNRQ2cv3z-K+QsQpJBA@mail.gmail.com>
Message-ID: <201509301839.t8UIdCEW018979@fido.openend.se>

If your code is new enough that it is written like this:

with open('output.txt', 'w') as f:
    f.write('Stuff')

you don't have to worry, you will be fine.  The with statement will
handle the closing for you.

If you don't use many files, well things will still work.  It's sloppy,
but as long as you don't run out of file descriptors, you code will still
work.

If you use lots of files, and don't close them, and don't rely on
the with statement to close them for you ... you can run out.  Bad
things happen.

Laura

From phyo.arkarlwin at gmail.com  Wed Sep 30 23:24:53 2015
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Thu, 1 Oct 2015 03:54:53 +0630
Subject: [pypy-dev] About gurobipy
In-Reply-To: <560C25AC.8030609@gmail.com>
References: <CAFKi5F9jc7Db5jeq1+rUbt4KPE+166AXRPD_a2N2-YQVaXup6A@mail.gmail.com>
 <CAFKi5F88EbiFK6dv14iJL_EUKvDj6Kq9b2QCC30PcJxKENGomg@mail.gmail.com>
 <CA+HjJriK43KhYk5Adz4x3j4nLpyzrZU_ogYSpzFssZB18wbA_A@mail.gmail.com>
 <560C25AC.8030609@gmail.com>
Message-ID: <CA+HjJrivCx9JZHbfhV6nkCOHK40GsW0J302b1yeGj9H2ev5OOQ@mail.gmail.com>

Some of the badly written programs keep files open and expecting GC to
close them, especially code written before with statement has introduced.

I have seen them in some web frameworks and many other modules.

They open file , process them and just ignore closing, causing pypy to fail
to work. Fixing them is just a matter of using with statement or manually
closing .

On Thu, Oct 1, 2015 at 12:40 AM, Vasily Evseenko <svpcom at gmail.com> wrote:

> Hi,
> Could you explain about closed file objects (do you mean open file
> descriptors)?
> I've never heard about this restriction before.
>
> 30.09.2015 19:35, Phyo Arkar ?????:
>
>
> On Wed, Sep 30, 2015 at 6:54 PM, Luis Jos? Novoa <luisjosenovoa at gmail.com>
> wrote:
>
>> gurobipy
>
>
> Never heard of it.
>
> Here are things PyPy Can help:
>
> - If it is Pure Python
> - If CExtensions are with CFFI
> - If file objects (if any) are closed
>
> PyPy will work fine and you can expect average 7x performance gain , up to
> 20-30x.
>
>
>
>
> _______________________________________________
> pypy-dev mailing listpypy-dev at python.orghttps://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20151001/537b0d94/attachment.html>