Mailman 3 February 2007 - pypy-dev

documentation age
by Carl Friedrich Bolz 14 Feb '07

14 Feb '07

Hi all! Just a pointer to a wonderful hack [1] that Samuele implemented yesterday evening: http://wyvern.cs.uni-duesseldorf.de/~cfbolz/pypy-dist/pypy/doc/ This is a copy of parts of the PyPy documentation, but with different coloring than usual: The title gives a general age of the document in shades of gray (with white being very young and gray being very old). All the text is colored in shades of yellow, giving the *relative* age of the lines making up a paragraph (using the median of all the revisions). In addition, every paragraph has a tooltip showing its age as a revision number. In my opinion it is quite useful for finding outdated documentation. It can be improved of course, but I think even the current status is very useful. Cheers, Carl Friedrich [1] http://codespeak.net/svn/user/pedronis/docage.py

1 0

rlib.parsing.test.test_ebnfparse / test_jsonparse
by Scott Dial 10 Feb '07

10 Feb '07

This test is invoking pygame despite what seems to be an attempt to have that be an option of the testing suite. This is happening on snake and my win32 box, but unfortunately my box actually has pygame installed. Thus, the testing gets halted waiting on me to click the [X]. I don't know the appropriate change to make, so I will defer patching it to whoever knows that. -- Scott Dial scott(a)scottdial.com scodial(a)cs.indiana.edu

3 2

codespeak.net downtime due to hosts switch
by Martin Pajak 10 Feb '07

10 Feb '07

Hello all, in recent weeks, codespeak.net has been causing some problems, mostly internal ones but ones to be taken seriously (kernel oops - mostly resulting in the need to restart). So we plan to switch to another host system, and then investigate further on the to-be-old system. As there are releases pending, i'd like to get the migration done before that and plan to do it: Feb 10th, saturday, around 10 AM GMT+2 if nobody objects. In case of problems i will switch back to the old system by means of a DNS switch (and i'll take special care that no mails or commits go astray) greetings, Martin

2 1

changes from py-trunk / dist merge (38224)
by holger krekel 09 Feb '07

09 Feb '07

Hi all, so i just merged the py-trunk branch to py-dist (which is the one used as an external by pypy-dist currently) and also did a few changes to pypy-dist itself to accomodate for the new situation. The update includes a number of internal cleanups and refactorings, most of which should not be visible from the user side (well, we also cleaned up all py.* namespaces to only provide what is supposed to be maintained in the future, that might catch you). And lots of documentation updates, including docstrings. For distributed testing the options you can put into conftest.py files have now more systematic names and meanings: * `dist_hosts`: a required list of host specifications * `dist_rsync_roots` - a list of relative locations to copy to the remote machines. * `dist_rsync_ignore` - a list of relative locations to ignore for rsyncing * `dist_remotepython` - the remote python executable to run. * `dist_nicelevel` - process priority of remote nodes. * `dist_boxed` - will run each single test in a separate process (allowing to survive segfaults for example) * `dist_taskspernode` - Maximum number of tasks being queued to remote nodes NOTE that pypy/conftest.py defines dist_rsync_roots (and dist_rsync_ignore) itself so you don't need to do that yourself anymore. Ah, and in case we didn't mention it yet, you invoke distributed testing with one of: py.test -d py.test --dist Noticeable is also that Stdout/Stderr capturing is now done FD-based instead of only patching sys.stdout/stderr. In other non-pypy related news, the tkinter and py.path.extpy classes got removed, and some other not-really-used stuff (or so i presume :). Please let us know if you experience any regressions/problems as the current py-dist is soon to become the 0.9 release (there still is a bit of documentation and packaging work to be done, and fixing bugs). best, holger with lots of help/work from fijal, guido and cf P.S.: Armin, we didn't fix htmlconftest yet. -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77)

1 0

pypy/dist => pypy/trunk
by Armin Rigo 08 Feb '07

08 Feb '07

Hi ! As part of the preparation for the upcoming release, we are going to implement the idea that 'pypy/trunk' will be for the future a better name for normal development to go on, and 'pypy/dist' is a better name for the place where people can get something stable. So we will soon copy pypy/dist to pypy/trunk, to get: * http://codespeak.net/svn/pypy/trunk => the normal development repo * http://codespeak.net/svn/pypy/dist => a stable snapshot The idea is that people that would like to get a known-working but recent PyPy can checkout or update the pypy/dist path, and people working on PyPy itself can work in pypy/trunk. When this is done (due sometime between tomorrow and Monday) most checkins should go to pypy/trunk. Holger will write-protect pypy/dist to avoid accidental checkins. Reminder: you can switch your existing working copy by doing: svn info # look at URL, which must be exactly http://codespeak.net/svn/pypy/dist # and then do: svn switch http://codespeak.net/svn/pypy/trunk It really works like an update, so it should keep your local changes, which you can then checkin (and they go to the new location, pypy/trunk). But never fully trust svn: if you have something important better make a backup of the working copy first. A bientot, Armin

1 0

release planning
by Armin Rigo 08 Feb '07

08 Feb '07

Hi, I've created extradoc/planning/1.0/ to put txt files planning the tasks of the upcoming release. If you want to help with the documentation, check if I missed something and possibly assign yourself to the items there. (I've put my name on two items only so far but I plan to do more.) Armin

1 0

JIT status
by Armin Rigo 08 Feb '07

08 Feb '07

Hi all, The JIT has now reached the state it will have in the upcoming PyPy release (it's still on a branch, but it will be merged). What it does is produce machine code in memory, and run it. What it does not do is gain much speed by doing so. Yet. It's just bad timing that the release and EU-driven deadlines mean that we have no time left to put the pieces together now - but essentially they are there already. We expect the jit to become useful during March, and then we'll in all likeliness do another release - if only because we promized to the EU numbers like "50% of the speed of C" for the most extremely algorithmic examples. Back to the present. Let me describe the current status. The produced machine code is kind of good (the backend performs some liftime analysis and register allocation). The "timeshifter", which produces the jit frontend, is able to handle rather incredibly tricky situations successfully. From a user point of view the jit has some rough edges but nothing fundamental, and by construction it can jit absolutely any kind of Python code - generators, nested scopes, exec statements, sys._getframe().f_back.f_back.f_locals, etc. At the moment only the interpreter's main dispatch loop (i.e. mostly only pyopcode.py) is fed to the timeshifter, so the produced jit can remove the bytecode interpretation overhead, but cannot look inside the implementation of space.add(), for example. So it gives results that look like Python2C+gcc: it produces machine code that is essentially a sequence of calls to space.add(), space.cmp(), space.is_true(), etc. As we all know, Python2C gives a ~2x speed-up; we get about the same with our jit, except that the start-up overhead is greater - calling small functions is still quite slower with the jit than without. On the other hand, Python2C doesn't emulate frames, for example, so AFAIK pypy contains the first Python compiler ever where sys._getframe() completely works (Psyco emulates frames but not at 100%). Only the 386 backend is complete; mwh guesses that there is some degree of likeliness that the ppc backend will be completed in time for the release too. How to compile a pypy-c with a jit: use translate.py on targetjit (located in pypy/jit/goal/). Then: export PYPYJITLOG=log # logs machine code into file 'log' pypy-c >>> def f(x): return x*5 >>> import pypyjit >>> pypyjit.enable(f.func_code) >>> f(7) ..../jit/codegen/i386/viewcode.py log A bientot, Armin.

1 0

Re: [pypy-dev] [pypy-svn] r38126 - pypy/dist/pypy
by Ben.Young＠risk.sungard.com 08 Feb '07

08 Feb '07

Hi Carl, Did you mean to return a dictionary here? Or am I missing something obvious :) ? Good luck to everyone with the release! Cheers, Ben Ben Young - Senior Software Engineer SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR Tel +44 1223 266042 - Main +44 1223 266000 - http://www.sungard.com/ CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. Thank you. cfbolz(a)codespeak.net Sent by: pypy-svn-bounces(a)codespeak.net 07/02/2007 22:29 Please respond to pypy-dev(a)codespeak.net To pypy-svn(a)codespeak.net cc Subject [pypy-svn] r38126 - pypy/dist/pypy Author: cfbolz Date: Wed Feb 7 23:29:30 2007 New Revision: 38126 Modified: pypy/dist/pypy/conftest.py Log: add space.newlist op (to give parsing test a chance to pass). Modified: pypy/dist/pypy/conftest.py ============================================================================== --- pypy/dist/pypy/conftest.py (original) +++ pypy/dist/pypy/conftest.py Wed Feb 7 23:29:30 2007 @@ -93,6 +93,9 @@ def is_true(self, obj): return bool(obj) + def newlist(self): + return {} + class OpErrKeyboardInterrupt(KeyboardInterrupt): pass _______________________________________________ pypy-svn mailing list pypy-svn(a)codespeak.net http://codespeak.net/mailman/listinfo/pypy-svn

2 1

JS Interpreter and the mozilla testing suite
by Leonardo Santagada 04 Feb '07

04 Feb '07

We are able to parse most of the mozilla suite of tests, so I made a little driver (a thing that runs the mozilla suite) to run the tests against our interpreter. Most of the tests suite breaks after the parsing on some missing opcode or when trying to access some non implemented function (or object, or prototype, or constructor). The parts that get as far as finishing building the test cases are here: 6-2.js passed 5 of 5 tests 7.1-1.js passed 4 of 4 tests 7.1-2.js passed 3 of 3 tests 7.7.2.js passed 1 of 1 tests 7.7.3-1.js passed 25 of 25 tests 7.7.3.js passed 166 of 184 tests 10.1.3.js passed 15 of 15 tests 10.1.6.js passed 0 of 16 tests 10.2.3-1.js passed 0 of 2 tests 11.12-1.js passed 6 of 6 tests 11.13.2-2.js passed 2 of 58 tests 11.13.2-3.js passed 2 of 76 tests 11.13.2-4.js passed 14 of 36 tests 11.13.2-5.js passed 6 of 44 tests 11.13.js passed 6 of 6 tests 11.14-1.js passed 2 of 2 tests 11.2.2-11.js passed 1 of 1 tests 11.5.1.js passed 26 of 26 tests 11.6.3.js passed 20 of 24 tests 11.9.1.js passed 29 of 63 tests 11.9.2.js passed 29 of 63 tests 11.9.3.js passed 29 of 63 tests 12.5-1.js passed 3 of 7 tests 12.5-2.js passed 3 of 7 tests 15.1.1.1.js passed 2 of 2 tests 15.1.1.2.js passed 2 of 2 tests 15.2.2.2.js passed 2 of 2 tests 15.3.5.1.js passed 0 of 2 tests 15.4.1.3.js passed 1 of 5 tests 15.4.2.2-2.js passed 0 of 14 tests 15.6.1.js passed 19 of 19 tests 15.6.3.1-4.js passed 0 of 2 tests 15.6.3.js passed 0 of 2 tests 15.6.4.2-1.js passed 0 of 46 tests 15.7.3.1-2.js passed 0 of 2 tests 15.8-1.js passed 0 of 2 tests Not much but this is just the start. If someone wants to run all tests on their machines just checkout the latest revision and run driver.py... it will try to run all the test suite (yep, i'm planning on improving this) and write the results to result.txt while on screen you get what tests are running. Warning: this might take some hours Somehow my code crashed the python interpreter (2.4.4) on one of the test files... will try to reproduce the crash and send a bug report upstream. Now I will work on some simple stuff like the MOD operator and this kind of stuff to make more tests run :) abraços, Leonardo Santagada

2 1

pypy 1.0 release meeting invitation
by Michael Hudson 01 Feb '07

01 Feb '07

Hi PyPy-developers! The release is drawing closer (the currently planned date is February, 15th) and it is time to meet and discuss the necessary work. Therefore we invite you all to a sync-meeting on Friday, February 2nd, 2007 14.00 UTC+1 #pypy-sync Regular Topics ============== * activity reports (LAST/NEXT/BLOCKERS, everybody posts prepared comma-separated lists of things) * resolving blockers/dependencies Release Goals ============= This topic is to get a common view on what the release goals are. A preliminary list of goals is: * object optimizations * pypy.net * more working modules * some performance * maturity * build tool * JIT preview * security prototype * js backend? * debian packaging? Task Planning ============= This topic is to collect tasks to be done for the release and divide them among people. Some tasks that we could think of: * work out a timeframe for jit usefulness * fix llvm(?) * test pypy-cs, run benchmarks. * windows testing! * documentation!!! * pypy.net * object optimizations (WP6) * release announcement * improve getting-started * transparent proxies * security prototype * make build-tool useable * polish js backend? Hope to see you all on friday! Cheers, mwh -- Python enjoys making tradeoffs that drive *someone* crazy <wink>. -- Tim Peters, comp.lang.python

6 6