Mailman 3 March 2009 - pypy-dev

Speeding Up SimPy
by Steven H. Rogers 17 Mar '09

17 Mar '09

SimPy (http://simpy.sf.net) is a very nice discrete event simulation package written in Python. It is, however, rather slow for large models and I'm looking at ways to speed it up. SimPy should be a good test case for PyPy and when the JIT stabilizes, PyPy may provide faster execution times. As we'd like to see some immediate benefits, I've tried Psyco which provides a worthwhile 45% improvement on one model and I'll look at modifying SimPy to work better with it. SimPy makes heavy use of generators, so I'm interested in the support for them planned for the next release. How close is Psyco generator support to being useful? Greenlets look like they could be a viable alternative to generators for simulating concurrency. How expensive are greenlets compared to generators? Regards, Steve

2 2

distributed version control mirror of trunk?
by Filippo Giunchedi 13 Mar '09

13 Mar '09

Hi, regarding the switch to a DVCS discussed in http://codespeak.net/pipermail/pypy-dev/2008q3/004816.html I was wondering if there's a (one way) mirror of SVN trunk/branches to a DVCS such as git or if such mirror is planned or wished. thanks in advance, filippo -- Filippo Giunchedi - http://esaurito.net - 0x6B79D401 I never forget a face, but in your case I'll be glad to make an exception. -- Groucho Marx

2 1

Leysin Winter Sprint
by Armin Rigo 11 Mar '09

11 Mar '09

Hi all! ===================================================================== PyPy Leysin Winter Sprint (14-21th April 2009) ===================================================================== .. image:: http://www.ermina.ch/002.JPG The next PyPy sprint will be in Leysin, Switzerland, for the sixth time. This sprint will take place immediately after Easter. This is a fully public sprint: newcomers and topics other than those proposed below are welcome. ------------------------------ Goals and topics of the sprint ------------------------------ * The overall idea of the sprint is to continue working on making PyPy ready for general use. There are a few tasks left in there. In parallel, we will continue the work on the JIT, if there is general interest. And as usual, we are ready to add any other task -- please mention on the mailing list what you would like to work on; the list of task is not really fixed. * And as usual, the main side goal is to have fun in winter sports :-) We can take a day off for ski until Sunday, the 19th; afterwards, the installations close. (There was quite a lot of snow this winter, so there should be some left even though it's relatively late in the season.) ----------------------- Location & Accomodation ----------------------- Leysin, Switzerland, "same place as before". Let me refresh your memory: both the sprint venue and the lodging will be in a very spacious pair of chalets built specifically for bed & breakfast: http://www.ermina.ch/. The place has a good ADSL Internet connexion with wireless installed. You can of course arrange your own lodging anywhere (so long as you are in Leysin, you cannot be more than a 15 minutes walk away from the sprint venue), but I definitely recommend lodging there too -- you won't find a better view anywhere else (though you probably won't get much worse ones easily, either :-) Please *confirm* that you are coming so that we can adjust the reservations as appropriate. The rate so far has been around 60 CHF a night all included in 2-person rooms, with breakfast. There are larger rooms too (less expensive) and maybe the possibility to get a single room if you really want to. Please register by svn: http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2009/people… or on the pypy-sprint mailing list if you do not yet have check-in rights: http://codespeak.net/mailman/listinfo/pypy-sprint You need a Swiss-to-(insert country here) power adapter. There will be some Swiss-to-EU adapters around -- bring a EU-format power strip if you have one. ----------- Exact times ----------- Officially, 14-21 April 2009. The idea is that the 14th should be the arrival day, so we won't work too much until the 15th. ----------------------------------------------------------------------- Armin

2 2

RunSnakeRun
by Laura Creighton 11 Mar '09

11 Mar '09

I'd never heard of this before, and thought it looked cool. http://www.vrplumber.com/programming/runsnakerun/ Laura

1 0

sandboxed exec function with context passing?
by Jurgis Pralgauskis 09 Mar '09

09 Mar '09

I would like to use sandboxed pypy for online step by step tutorials... 1) I need ability to pass context then. 2) and also would be nice to get result as variable not just like output. my experiments are based on explanations from http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox maybe my question seems too trivial, but I looked around pypy_interact code, its class inherits from 2 calsses I followed one of them and went till sandlib.py handle_until_return() but here didn't see anything apparent and felt like lost... could smb direct me ? :) or just tell the functions which would act like usual eval/exec (just sandboxed) Thanks in advance -- Jurgis Pralgauskis

2 1

cleaned builds with lots of failures, issues with nightly translations
by Samuele Pedroni 06 Mar '09

06 Mar '09

I cleaned up the builds with lots of failures that happened on 3rd. Btw build files are stored with names starting with build numbers in the builder directories (named like the builders) under /home/buildmaster/pypy on codespeak. It seems that some our nightly translations by buildbot are timing out now, it may be legitimate and then we need to up the timeouts or something wrong may be going on, I don't have time to investigate that right now. Samuele

2 1

Compiling RSDL and ExternalCompilationInfo
by Leonardo Santagada 03 Mar '09

03 Mar '09

I've tried running some RSDL examples in my computer and they are not working, but if I try to compile the code by hand it works (without the framework and includes it does complain the same as translation on pypy): Apfelstrudel:~/projects/pypy/pypy/rlib/rsdl/macosx-sdl-main santagada$ gcc -I/Library/Frameworks/SDL.framework/Headers -framework Cocoa - framework SDL SDLMain.m Undefined symbols: "_SDL_main", referenced from: -[SDLMain applicationDidFinishLaunching:] in ccCdkKBZ.o ld: symbol(s) not found collect2: ld returned 1 exit status The error is because the supporting code does not have a main (I think). But when I try to translate something with pypy I get this other error on this paste http://paste.pocoo.org/show/106398/ wich ends with: pypy.translator.platform.CompilationError: <CompilationError err='Undefined symbols:\n "_CPSEnableForegroundOperation", referenced from:\n _CustomApplicationMain in cckWdEVi.o\n...erenced from: \n _NSApp$non_lazy_ptr in cckWdEVi.o\nld: symbol(s) not found \ncollect2: ld returned 1 exit status\n'> Apfelstrudel:~/projects/pypy/pypy/rlib/rsdl santagada$ Using py.test to run the example it stops saying I don't have sdl installed (the error defined on the check_sdl_installation in eci.py. The eci.py file should be defining it but besides Version/A/Headers (which I also tried changing on my WC) appears to be trying to define what I typed to gcc. What could be going on? -- Leonardo Santagada santagada at gmail.com

1 0

Re: [pypy-dev] Parsing in PyPy (and runicode)
by Frank Wierzbicki 02 Mar '09

02 Mar '09

On Mon, Mar 2, 2009 at 11:55 AM, Jim Idle <jimi(a)temporal-wave.com> wrote: >> Well knowing that the Java one is quick is a good indication that the >> rpython one can be quick also. > > Yes - I think so. Perhaps one way is to ignore the current runtime, which > has been written more for functionality than performance as far as I can > see, and write an RPython runtime that is strictly aimed at performance and > RPython semantics etc. It is not a huge project to do this, but it is some > work of course. Indeed the Java parser has not been optimized for performance (yet) -- it was written with compatibility as the #1 concern. In particular I'm sure I've lost a bit of performance in order to support _ast.py and ast.py. -Frank

1 0

Re: [pypy-dev] Parsing in PyPy (and runicode)
by Leonardo Santagada 02 Mar '09

02 Mar '09

On Feb 27, 2009, at 7:36 PM, Jim Idle wrote: > Leonardo Santagada wrote: >> >> On Feb 27, 2009, at 3:19 PM, Jacob Hallén wrote: >> >>> fredagen den 27 februari 2009 skrev Frank Wierzbicki: >>>> On Thu, Feb 26, 2009 at 2:55 PM, Leonardo Santagada <santagada(a)gmail.com >>>> > >>> >>> Andrew Dalke, who is very thorough in his investigation of >>> software, has >>> written som interesting things about his experience with ANTLR as >>> well as >>> some other parsing projects. In short, he likes ANTLR as a tool, >>> but in his >>> application, it is considerably slower than some other alternatives. >>> He also has something called python4ply, which is a ready, MIT >>> licensed >>> parser for Python. >>> >>> You can find his articles on >>> http://www.dalkescientific.com/writings/diary/archive/ >> >> >> The problem he might be having is with the python backend for >> ANTLR, wich neither us (we are going to have to create a rpython >> one) nor cpython (which would use a c89 one) would have. but this >> is just a guess as I have had no time to read his article yet, > All I can find is info about using the Python backend. > Unfortunately, the Python backend is very slow. There was some > discussion between the Python runtime author and Guido about why - I > can't re-quote as it was private email, but basically the runtime > and the generated code are method-call heavy, which isn't a good > idea in Python. Also, as string handling and other things are not > particularly quick, it is hard to get Python to perform when running > a parser using a design that wasn't specifically tailored for > Python. After all, Python wasn't really aimed at writing things like > lexers and parsers and is much better at things in other domains. > All that said, I think that the Python runtime will get better as > there will be more expansive choices for backend runtime authors in > the future. Then again, is the speed of the parser going to be a > factor? Not much I think. Well I did take a look at both the support code and the generated code (and a fast look at the runtime). The support code in java is really crazy, at least for me I didn't get most of it (I should read the docs later). Now the generated code seems to be following the java backend so far as being almost RPython. there is a problem that RPython doesn't have sets so it will take some time to make it work... but I think it is doable. Somehow my generated code has "pass" before every block of code on both parsers and lexers, the reason for that is still a mistery for me (do anyone knows why?). Maybe in this weekend I will have more time to look/work more seriosly on this. > The Java runtime is a lot quicker that the Python runtime and unless > there are Python translation units with 25,000 lines (there will be > somewhere ;-), performance would not be a factor. > > When I wrote the C runtime however, I did not make a blind copy of > the Java runtime, hence the performance is akin to hand written > code. For instance the GNU C parser written for ANTLR and running > with the C runtime, is almost the same speed as the GNU C parser > itself. This is great, but is the code C89 or do you use something from a newer standard? Because the only way to have a shot at using it with cpython would be if it was C89... though using the same parser in jython and pypy would be cool enough. > None of this would help (in terms of ANTLR) if you want a Python > parser that runs in Python of course :-) Well knowing that the Java one is quick is a good indication that the rpython one can be quick also. Thanks for all the info and for the quick response, -- Leonardo Santagada santagada at gmail.com

1 0

pypy translation error :\
by Jurgis Pralgauskis 01 Mar '09

01 Mar '09

Hello, maybe smb could give a hint, why: http://files.akl.lt/users/jurgis/etc/pypy_translation_error.txt ps.: I acted according to instructions on http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox my env: python 2.5.2, Ubuntu 8.04 Thanks in advance -- Jurgis Pralgauskis Don't worry, be happy and make things better ;) http://sagemath.visiems.lt

2 1