http://permalink.gmane.org/gmane.comp.python.pypy hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.python.pypy/11561 <pre> Nobody is working on any of the OO backends at the moment. It might be worthwhile to document what we mean by 'from scratch', too. Graphs that haven't been rtyped actually have most of the information that oo-style or untyped backends might care about, the most significant things missing probably involve dealing with constants as well as the extregistry. -- 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. </pre> William ML Leslie 2013-05-22T06:23:03 http://permalink.gmane.org/gmane.comp.python.pypy/11560 <pre>I really wish pypy is able to support jvm, cli and dalvik, so that it is possible to write core business logic in python which runs everywhere. Is there any plan to implement a better ootype as well as OO backends? On Thu, May 9, 2013 at 2:19 AM, Armin Rigo &lt;arigo&lt; at &gt;tunes.org&gt; wrote: _______________________________________________ pypy-dev mailing list pypy-dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/pypy-dev </pre> James Lan 2013-05-22T06:11:30 http://permalink.gmane.org/gmane.comp.python.pypy/11559 <pre>Hi all, The bugfix PyPy 2.0.2 has been released (on all platforms but OS/X which should come later in the day). ========================= PyPy 2.0.2 - Fermi Panini ========================= We're pleased to announce PyPy 2.0.2. This is a stable bugfix release over 2.0 and 2.0.1. You can download it here: http://pypy.org/download.html It fixes a crash in the JIT when calling external C functions (with ctypes/cffi) in a multithreaded context. What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (pypy 2.0 and cpython 2.7.3 performance comparison: http://speed.pypy.org) due to its integrated tracing JIT compiler. This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Support for ARM is progressing but not bug-free yet. Highlights ========== This release contains only the fix described above. A crash (or wrong results) used to occur if all these conditions were true: - your program is multit</pre> Armin Rigo 2013-05-21T09:27:11 http://permalink.gmane.org/gmane.comp.python.pypy/11558 <pre> In a way it should not have happened at all. But also in a way I would argue cpyext is broken (annotation-wise) and my changes merely exposed brokenness. It's still my duty to fix it though ;-) Cheers, fijal </pre> Maciej Fijalkowski 2013-05-18T19:57:13 http://permalink.gmane.org/gmane.comp.python.pypy/11557 <pre>_______________________________________________ pypy-dev mailing list pypy-dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/pypy-dev </pre> Matti Picus 2013-05-18T19:49:42 http://permalink.gmane.org/gmane.comp.python.pypy/11556 <pre> It's disabled because I broke it. I'll unbreak it some time soon, it's just that issue is involved. I'm sorry about that, but there was no goal to deprecate it any time soon. Cheers, fijal </pre> Maciej Fijalkowski 2013-05-18T19:45:36 http://permalink.gmane.org/gmane.comp.python.pypy/11555 <pre>cpyext is currently disabled on default. Is there a branch to revive it? Or are we expecting cffi to replace all interaction with external c code? I'm not sure what will be more painful, getting the world to rewrite all modules or supporting cpyext, both seem non-trivial. (I'm opening the discussion here since I'm not sure if everyone was heard in the discussion on IRC) Matti </pre> Matti Picus 2013-05-18T18:51:00 http://permalink.gmane.org/gmane.comp.python.pypy/11554 <pre> Cool, thanks for sharing! Cheers, fijal PS. No, it's not a spam message despite looking like one, genuinely thanks </pre> Maciej Fijalkowski 2013-05-18T18:10:29 http://permalink.gmane.org/gmane.comp.python.pypy/11553 <pre>FYI. Performance comparison of pypy and CPython using a fractal terrain generator and writing out a png file. Pypy is 6-11x faster on my Ubuntu Intel system. For 1024x1024 map: sriley&lt; at &gt;xxxy:/data/src/cityserver$ time pypy map.py real 0m0.656s user 0m0.596s sys 0m0.052s sriley&lt; at &gt;xxx:/data/src/cityserver$ time python map.py real 0m4.189s user 0m4.132s sys 0m0.044s For 4096x4096 map: sriley&lt; at &gt;xxx:/data/src/cityserver$ time pypy map.py real 0m6.511s user 0m6.152s sys 0m0.328s sriley&lt; at &gt;xxx:/data/src/cityserver$ time python map.py real 1m7.641s user 1m7.124s sys 0m0.324s Sean. _______________________________________________ pypy-dev mailing list pypy-dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/pypy-dev </pre> sean riley 2013-05-18T18:03:47 http://permalink.gmane.org/gmane.comp.python.pypy/11552 <pre>============================== PyPy 2.0.1 - Bohr Smørrebrød ============================== We're pleased to announce PyPy 2.0.1. This is a stable bugfix release over 2.0. You can download it here: http://pypy.org/download.html The fixes are mainly about fatal errors or crashes in our stdlib. See below for more details. What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast due to its integrated tracing JIT compiler. (pypy 2.0 and cpython 2.7.3 performance comparison: http://speed.pypy.org) This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Support for ARM is progressing but not bug-free yet. Highlights ========== - fix an occasional crash in the JIT that ends in `RPython Fatal error: NotImplementedError` (https://bugs.pypy.org/issue1482). - `id(x)` is now always a positive number (except on int/float/long/complex). This fixes an issue in `_sqlite.py` (mostly for 32-bit Linux). </pre> Armin Rigo 2013-05-16T17:10:03 http://permalink.gmane.org/gmane.comp.python.pypy/11551 <pre>Hi Armin, this simple test case works now without crashing :-) Regards, Emil Am Thu, 16 May 2013 09:02:09 +0200 schrieb Armin Rigo &lt;arigo&lt; at &gt;tunes.org&gt;: </pre> Emil Kroymann 2013-05-16T15:36:40 http://permalink.gmane.org/gmane.comp.python.pypy/11550 <pre>Hi Emil, On Thu, May 16, 2013 at 2:29 PM, Geert Jansen &lt;geertj&lt; at &gt;gmail.com&gt; wrote: It most probably works. :-) A bientôt, Armin. </pre> Armin Rigo 2013-05-16T15:21:06 http://permalink.gmane.org/gmane.comp.python.pypy/11549 <pre>Hi, On Thu, May 16, 2013 at 3:02 AM, Armin Rigo &lt;arigo&lt; at &gt;tunes.org&gt; wrote: Does the problem exist with CPython/cffi/greenlet too? I'm just about to start a module using these three. Thanks, Geert _______________________________________________ pypy-dev mailing list pypy-dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/pypy-dev </pre> Geert Jansen 2013-05-16T12:29:27 http://permalink.gmane.org/gmane.comp.python.pypy/11548 <pre> Also, it's not that string concatenation has poor performance, it has quadratic performance. It's the same as in cpython if you made two references to s, your performance will plummet. (each s + 'a' would do a copy). We simply don't have the refcount hack Please use l.append('a') and later ''.join() </pre> Maciej Fijalkowski 2013-05-16T09:45:20 http://permalink.gmane.org/gmane.comp.python.pypy/11547 <pre>Hi Jasper, On Thu, May 16, 2013 at 9:14 AM, Jasper Spaans &lt;spaans&lt; at &gt;fox-it.com&gt; wrote: It's a statistical profiler based on signals: whenever a signal is delivered, it checks where it is and counts. What occurs is that the signal delivery points are a bit more restricted when running JITted code. The inner loop of your example: is quickly compiled to machine code that does this: guard that t &lt; 1000000 append "c2" to the list local_context_stack.data s = s + "a" remove the last item from local_context_stack.data guard that there was no signal jump back to the top of the loop So it only checks for signals once per loop at the end, instead of (as usual when interpreting) at random points during the loop. Signals will never be delivered when "c2" is in the local_context_stack... A bientôt, Armin. </pre> Armin Rigo 2013-05-16T07:42:39 http://permalink.gmane.org/gmane.comp.python.pypy/11546 <pre>Hi list, I was toying around a bit with writing a statistical profiler in python, and came up with https://gist.github.com/jap/5584946 For reference, the main routine is: with Profiler() as p: with ProfilerContext("c1"): s = "" for t in range(100000): with ProfilerContext("c2"): s = s + "a" s = s + "b" print p.get_data() When running it on my local machine, this gives the following output: spaans&lt; at &gt;spaans-e6500:/tmp$ /usr/bin/time ~/xsrc/pypy-2.0/bin/pypy pmp.py Counter({'c1': 638}) 6.42user 0.42system 0:07.06elapsed 97%CPU (0avgtext+0avgdata 30160maxresident)k 0inputs+0outputs (0major+8383minor)pagefaults 0swaps spaans&lt; at &gt;spaans-e6500:/tmp$ /usr/bin/time python pmp.py Counter({'c1': 18, 'c2': 3}) 0.23user 0.02system 0:00.25elapsed 98%CPU (0avgtext+0avgdata 8200maxresident)k 0inputs+0outputs (0major+2226minor)pagefaults 0swaps So, two things seem to happen: the pypy version is almost 30 times slower than the python version (but hey, string </pre> Jasper Spaans 2013-05-16T07:14:24 http://permalink.gmane.org/gmane.comp.python.pypy/11545 <pre>Hi Emil, On Mon, May 13, 2013 at 6:35 PM, Emil Kroymann &lt;emil.kroymann&lt; at &gt;isaco.de&gt; wrote: Thanks for the report! I still have no clue why we didn't see a similar report earlier: any combination of cffi callbacks and stackless-like features explodes. So well, now it should be fixed both in "default" and in the branch "release-2.0.x" out of which we're planning to make the release 2.0.1 very soon. Is there any chance you can try it out? (If you didn't get the whole mercurial repository, you can download https://bitbucket.org/pypy/pypy/get/release-2.0.x.tar.bz2 .) Armin </pre> Armin Rigo 2013-05-16T07:02:09 http://permalink.gmane.org/gmane.comp.python.pypy/11544 <pre>Hi Armin, Thank you for the explanation. Knowing nothing about C (difficult syntax to understand) I will try the way to connect Fortran code. Have a nice day, Fabio 2013/5/14 Armin Rigo &lt;arigo&lt; at &gt;tunes.org&gt; _______________________________________________ pypy-dev mailing list pypy-dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/pypy-dev </pre> Fabio D'Orta 2013-05-15T09:51:07 http://permalink.gmane.org/gmane.comp.python.pypy/11543 <pre>2013/5/14 Stefano Rivera &lt;stefano&lt; at &gt;rivera.za.net&gt; (i.e. the __pycache__ directory) Could you compare your patch with the py3k version of pypy? I already found interesting differences in importing.py, with bugs or inefficiencies on both sides. </pre> Amaury Forgeot d'Arc 2013-05-14T20:06:01 http://permalink.gmane.org/gmane.comp.python.pypy/11542 <pre>Sorry, a bit behind on my mail... Hi Kura (2013.05.10_11:50:13_+0200) Running a daily automated build on Wheezy would probably be useful. I've done builds of 2.0.0 for wheezy [0] if that's useful to anyone. My packaging process is really centred around packaging for the distro, so I'm patching pypy a bit [1] (mainly, PEP3147 support). Those patches get out of date quickly, which is why I haven't got around to doing daily deb builds yet (I'm scared of how much maintainance work they are going to be). So, my plan is to just build a simple deb from a pypy translation, that doesn't interact with the Debian system much at all. I prepared something like that here [2], but must just turn that into a Python script that we can include in the pypy repo. I think it'll be fairly trivial. [0] http://people.debian.org/~stefanor/pypy/wheezy/ [1] http://anonscm.debian.org/gitweb/?p=collab-maint/pypy.git;a=tree;f=debian/patches [2] http://bitbucket.org/stefanor/pypy-upstream SR </pre> Stefano Rivera 2013-05-14T19:16:44 http://permalink.gmane.org/gmane.comp.python.pypy/11541 <pre>Hi Fabio, On Tue, May 14, 2013 at 5:31 PM, Fabio D'Orta &lt;fabio88.dorta&lt; at &gt;gmail.com&gt; wrote: Ah, you're trying to import an .so that is a CPython C extension module. That's not what CFFI is for. With CFFI you can connect directly to C (and probably Fortran) code that is not specifically written for Python (i.e. doesn't contain "#include &lt;Python.h&gt;"). You can call C code from Python with CFFI; this C code may be living in its own (Python-independent) .so file, or may just be more sources that will be compiled along during the call to ffi.verify() if you use "sources=[...]". Look up http://cffi.readthedocs.org for more information. A bientôt, Armin. </pre> Armin Rigo 2013-05-14T15:59:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.pypy