Mailman 3 July 2009 - pypy-dev

ANN: psyco V2
by Christian Tismer Sept. 15, 2009

Sept. 15, 2009

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

supporting new libraries
by Vincent Legoll Aug. 1, 2009

Aug. 1, 2009

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

Re: [pypy-dev] supporting new libraries
by poelzi July 31, 2009

July 31, 2009

Hi, i personally have made quite bad experice with swig and mostly not so good with most bindings generators so far. recently i found http://code.google.com/p/pybindgen/ and found the quality of the the generator really a good starting point; also that it uses gccxml for itrospection for auto generated bindings removes a lot of pain :-) i started making me thoughts to refactor pybindgen to generate not only python wrappers ( i need lua wrappers sometimes, too). While beeing at it i thought, why not use it to generate pypy wrapping code, too. So python_c is just another target same as pypy. maybe some code can be shared between such same language, different interpreter backends. maybe the frontend could be abstracted a bit, too. so if someone writes a defs parser the gtk python definitions could be used and only the overloaded functions need customizations, same goes for the qt4 sip stuff i think. what do you think ? kindly regards poelzi PS: sorry for breaking the thread, i just subscribed :-)

1 0

Fix for build problem in Hebrew locales
by Yosef Meller July 30, 2009

July 30, 2009

Hi all, I'm in the process of doing my first translation of pypy-c, and have encountered a problem in running the translation. The issue is that Subversion automatically replaces the string $LastChanged$ with a date, and in Hebrew locales that date includes an apostrophe, while the string in the code is also delimited with apostrophes. The attached patch solves this by delimiting with quotation marks instead. Yours, Yosef.

2 1

Re: [pypy-dev] [pypy-svn] r66656 - pypy/branch/pyjitpl5/pypy/jit/metainterp
by Antonio Cuni July 28, 2009

July 28, 2009

arigo(a)codespeak.net wrote: > Author: arigo > Date: Mon Jul 27 21:07:20 2009 > New Revision: 66656 > > Modified: > pypy/branch/pyjitpl5/pypy/jit/metainterp/history.py > pypy/branch/pyjitpl5/pypy/jit/metainterp/optimize.py > Log: > An RPython-friendly way to dump a loop. in case you don't know, there is already code that serves this purpose, in backend.support.AbstractLogger (used by both x86 and cli backend); you can just set the PYPYJITLOG env variable and you get a .ops file containing a textual representation of the loop (btw, it would be nice to have a graphical viewer for it... hint hint :-)).

2 1

How to make a pypy distribution?
by Leonardo Santagada July 20, 2009

July 20, 2009

I want to make binaries to pypy and distribute but I don't know how. The biggest problem is that I didn't find were I can change the 2 hardcoded sys.path entries (lib python and modified lib python). I would like it to look to a relative dir from where pypy-c is, or at least be able to hardcode it to something sensible (not my wc dir). Here is the scenario that I want to address: A self contained pypy, with pypy-c in pypy/bin and libs in pypy/lib or maybe pypy/lib/pypy (so instead of on its on directory it can be easily moved to /usr/local for example). I want to start to distribute a compiled version of pypy for macs (based on trunk). For people to have the biggest set of package to test on I am translating with this command line: ./translate.py --thread --stackless --gc=hybrid targetpypystandalone.py --allworkingmodules Do anyone think that there is a better set of options? (maybe -- gc=hybrid is not needed but I want to be sure never to try to use boehm) -- Leonardo Santagada santagada at gmail.com

2 2

py.path.svnwc stopped working for me
by Christian Tismer July 10, 2009

July 10, 2009

def psycofiles(): path = py.path.svnwc(os.pardir) for p in path.visit(lambda x: x.check(versioned=1)): if p.check(dir=1): print p else: yield p.relto(path).replace('\\', '/') stopped working. I don't want to know why. I'm upset by the fact that it stopped working, even if the library is not guilty. Yes, I updated SVN. But it is the library that pretends to be working for me. and this is the reason why I hate libraries so much: They pretend to solve a problem, and they do this for a while (3 years in this case). But the payload is not worth it, because in the end, the library stops working. And the replies you will get are of the kind "well, why did you not update X and Y, and read list Z?" BECAUSE I HATE LIBRARIES! Libraries are just another way to subordinate people. I want a simple, readable piece of source code that I can understand, when it crashes. Not when I'm recreated and happy to read lots of twisted code. But right now, in a release process, when I love nothing more than a trivial SVN script that crashes, because it thinks it became important some time. py.lib is one of these crappy things. GO AWAY, you are not helpful. you are arrogant! Why I dare to say this? Code that makes me dependent, for the sake of saving a few lines, but obfuscating what's going on in a way that I get lost right before doing a release. That is crap. Holy shit! Arrogant code. Evict this code till before the invention of computers, please! I will stop using it, because it always has cost me a multiple of the time that I would have used without it. I hate libraries, and even more I hate unreadable libraries. Have you ever tried to find out why py.lib stops working? Do you always want to bend your head towards Mekka, thanking Allah that you did not hit that new bug in the library, today? Forget it! The only valid answer to arrogant code is ignoring it. Be arrogant! don't try to discuss that. I'm not going to be nice -- 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/

2 2

Re: [pypy-dev] [pypy-svn] r66150 - pypy/trunk/pypy/tool
by Antonio Cuni July 8, 2009

July 8, 2009

fijal(a)codespeak.net wrote: > try: > - BaseException > + BaseException = BaseException > except NameError: > BaseException = Exception this clearly show that you didn't write a test (or you didn't run it, if it's already there). Could you please try to follow tdd a bit more closely, especially on trunk?

3 3