Mailman 3 August 2009 - pypy-dev

ANN: psyco V2
by Christian Tismer 15 Sep '09

15 Sep '09

Announcing Psyco V2 source release ---------------------------------- This is the long awaited announcement of Psyco V2. Psyco V2 is a continuation of the well-known psyco project, which was called finished and was dis-continued by its author Armin Rigo in 2005, in favor of the PyPy project. This is a new project, using Psyco's code base with permission of Armin. Questions and complaints should go to me (tismer(a)stackless.com) or the mailing list (psyco-devel(a)lists.sourceforge.net); Armin is explicitly not in charge of (t)his project any longer! As one of the founders and an active member of the PyPy project, I was very happy to be invited to work on Psyco V2, by FATTOC, LLC. Psyco V2 tries to extend on the original Psyco approach "an extension module that just makes Python faster". Psyco is a just-in-time compiler that accelerates arbitrary Python code by specialization. We believe that Psyco's approach can be carried out much further than it was tried so far, when it's first version was abandoned. This first V2 release is source-only. There is no web-site, yet, and there are no binaries for download. These will be available in a few days on http://www.psyco.org . For the time being, please stick with subversion access, building the extension module from source code. The repository is here: http://codespeak.net/svn/psyco/v2/dist Check-out the repository, and run the setup.py script, given that you have access to a C compiler. Psyco V2 will run on X86 based 32 bit Linux, 32 bit Windows, and Mac OS X. Psyco is not supporting 64 bit, yet. But it is well being considered. The current improvements are, shortly: - Support for Python 2.4, 2.5 and 2.6 - a lot of new builtins - generators, fast and fully supported. More information is coming soon on http://www.psyco.org . This is the beginning of a series of new Psyco versions. Many more improvements are prepared and about to be published, soon, starting with the current version 2.0.0 . Stay tuned, this is just the beginning of psyco's re-birth! For questions about Psyco V2, please join the mailing list psyco-devel(a)lists.sourceforge.net or contact me on IRC: #psyco on irc.freenode.net . Psyco V2 is fundamentally supported by FATTOC, LLC. See http://www.fattoc.com . Without their continuous support, this work would not have been possible at all. I wish to express my deepest thanks to FATTOC, for allowing me to continue on Psyco with all the energy that this ambitious project needs, and will need. Further special thanks are going to Armin Rigo, John Benediktsson, David Salomon, Miki Tebeka, Raymond Hettinger, Fabrizio Milo, Michael Foord, Dinu Gherman, Stephan Diehl, Laura Creighton and Andrea Tismer, for all the support and discussions. Looking forward to a great future of Psyco! July 17, 2009 -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

3 2

Re: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been
by Laura Creighton 28 Aug '09

28 Aug '09

In a message of Fri, 28 Aug 2009 09:12:27 +0200, holger krekel writes: >On Fri, Aug 28, 2009 at 06:19 +0200, Laura Creighton wrote: >> Sorry, I meant to sent that to pypy-z. My fault. > >to clarify what laura refers to here: pypy-z is an internal >mailing list for discussing pypy funding, contracts, >proposals and such. Most who are regular pypy >contributors are members of that list. > >best, >holger Ah yes, thanks for the clarification, Holger. Laura

1 0

Re: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been
by Laura Creighton 28 Aug '09

28 Aug '09

In a message of Thu, 27 Aug 2009 16:12:52 CDT, Benjamin Peterson writes: >2009/8/26 Laura Creighton <lac(a)openend.se>: >> delayed by one day. Â KLM is putting him up someplace. Â So says his >> mother in email to me. > >Is this information really relevant to PyPy development? Even if my >mother decides to send my "personal" messages to half the world, you >don't have to help her. :) > > > >-- >Regards, >Benjamin Sorry, I meant to sent that to pypy-z. My fault. Laura

2 1

Benjamin's flight from Amsterdam to Minneapolis has been
by Laura Creighton 28 Aug '09

28 Aug '09

delayed by one day. KLM is putting him up someplace. So says his mother in email to me. Laura

3 2

New performance monitoring functionality in Linux kernel 2.6.31
by Jacob Hallén 27 Aug '09

27 Aug '09

The upcoming Linux kernel release has functionality for monitoring low level events like cache misses, page faults, instructions and cycles. It may be useful in future development and debugging of the PyPy JIT. The new kernel is expected to be released in about 2 weeks. All relevant links can be found in this article: http://www.h-online.com/open/Kernel-Log-Coming-in-2-6-31-Part-4-Tracing- architecture-virtualisation--/news/114082 Jacob

1 0

Re: [pypy-dev] [pypy-svn] r67223 - pypy/build/bot2/pypybuildbot
by Maciej Fijalkowski 27 Aug '09

27 Aug '09

Are you aware that this breaks some other tests, because our asmgcc does not provide a way to have a callback (and ie xml parser is based on ctypes & callbacks). Cheers, fijal On Wed, Aug 26, 2009 at 2:09 PM, <arigo(a)codespeak.net> wrote: > Author: arigo > Date: Wed Aug 26 22:09:39 2009 > New Revision: 67223 > > Modified: > pypy/build/bot2/pypybuildbot/builds.py > Log: > Translate pypy-c-jit with our own GC now, to avoid seeing in lib-python > the memory-not-freed-early-enough bugs common to pypy-c-boehm. > > > Modified: pypy/build/bot2/pypybuildbot/builds.py > ============================================================================== > --- pypy/build/bot2/pypybuildbot/builds.py (original) > +++ pypy/build/bot2/pypybuildbot/builds.py Wed Aug 26 22:09:39 2009 > @@ -200,7 +200,7 @@ > > setup_steps(platform, self) > > - self.addStep(Translate(['-Ojit', '--gc=boehm'], > + self.addStep(Translate(['-Ojit', '--gc=hybrid','--gcrootfinder=asmgcc'], > ['--withoutmod-thread'])) > > self.addStep(ShellCmd( > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

1 0

befunge
by Terrence Cole 20 Aug '09

20 Aug '09

I have built an RPython implementation of befunge98 on top of pypy. It took about a week at 30%, and about half of that was spent writing a befunge implementation of pidigits[1]. I honestly expected to have more trouble getting this working, which is one of the reasons I chose something as simple as befunge. There were some hiccups, certainly, but compared to working with parrot and llvm, pypy was startlingly easy to get up and running. On to benchmarks. Time taken to compute the first 1,000 digits of pi: befunge.py: 3:03.18 befunge-c: 0:02.76 As advertised, I was able to write and test in python and run it through the translator to get... the wrong test output. This was, naturally, my own fault. As it turns out, pidigits requires arbitrary precision integer support. A quick skim of rarithmatic and rbignum and a bit of hacking later, and I got the awesomely cool results you see above. It was my plan at this point to lay down some benchmarks against other language implementations of pidigits showing how awesome pypy is. Unfortunately, the pidigits test is basically entirely limited by the performance of the bignum library in use. This effectively means that every language that can use gmp does, and gets a result of 3-7 seconds, which makes the pidigits test basically useless for meaningful interpreter benchmarking. That said, it is still a good benchmark for bignum libraries, so here goes: Time taken to compute the first 10,000 digits of pi: befunge-c: 5:22.13 pypy-c [2]: 5:35.26 python-2.5 [2]: 1:31.56 python-2.5(gmp) [3]: 0:10.22 >From what I see on the pyjitpl5 branch, jit support seems to be wildly in flux at the moment. I'm thinking I probably want to put jit support on hold until things settle down, although it's definitely on my todo list. Supporting jit on top of befunge will, I think, be an interesting edge case because the language was specifically designed to be hard to compile. Does pypy want a befunge interpreter? It is a rather easier to read interpreter than malbolge or javascript, although I did write it myself, so I may be biased. Some of the more esoteric instructions and edge cases are still missing, and there are several improvements that I would still like to try, but it basically works now, so I figured I would throw it out there. Pypy isn't using a DVCS, so I'm not sure what the best way is for me to share this code. For now I've just attached it inline -- it's only 12KiB, packed up. Untar it into the lang directory and it will create a befunge subdirectory. Let me know if there is a better way to share code. -Terrence Cole [1] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=all… [2] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=pyt… [3] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=pyt…

3 7

sys.prefix
by Gabriel Lavoie 18 Aug '09

18 Aug '09

Hello, I have this tool to test on PyPy: http://furius.ca/snakefood/ It seems the code requires "sys.prefix" but it seems it doesn't exists on PyPy. Is it normal? I will probably be able to make the code work without this. >>>> import sys >>>> sys.prefix Traceback (most recent call last): File "<console>", line 1, in <interactive> AttributeError: 'module' object has no attribute 'prefix' Thank you, Gabriel -- Gabriel Lavoie glavoie(a)gmail.com

1 0

have pypy active branches use py.lib 1.0 final
by Samuele Pedroni 10 Aug '09

10 Aug '09

Given that py.lib 1.0 final is out, I think it makes sense to switch pypy active branches starting from trunk to use an external pointing to that. There are going to be some changes and possibly issues that will need addressing, the work may need to happen on a branch at first. I plan to work on this middle of next week if there are no objections. Samuele PS: the window buildbot is also down, given that we host it we will look into that

3 2

supporting new libraries
by Vincent Legoll 01 Aug '09

01 Aug '09

Hello, I would like to know how hard it is to support new libraries, for example (probably far from the simplest, but would certainly be cool to have - kind) pygtk (+pygobject, etc...) Could someone help in finding what would be needed to get that one(s) working ? Maybe with an approximate estimation of the difficulty of each step, or what kind of required knowledge to have. In case it would be too early to attempt such project, a slight explanation of what are the blocking points. That kind of information could (should ?) be added to wiki or FAQ, as a honey-pot for new contributors... The help could simply be a pointer to the obvious documentation that I managed to miss user@host:~/repo/svn/pypy-trunk/pypy/translator/goal$ ./pypy-c -c 'import pygtk' Traceback (most recent call last): File "?", line 33, in run_toplevel File "?", line 349, in run_it File "<string>", line 1, in <module> ImportError: No module named pygtk -- Vincent Legoll

4 6