[pypy-svn] r71798 - in pypy/release/1.2.x: . pypy/doc pypy/doc/jit pypy/doc/tool
arigo at codespeak.net
arigo at codespeak.net
Fri Mar 5 15:12:48 CET 2010
Author: arigo
Date: Fri Mar 5 15:12:41 2010
New Revision: 71798
Added:
pypy/release/1.2.x/pypy/doc/release-1.2.0.txt
- copied unchanged from r71659, pypy/trunk/pypy/doc/release-1.2.0.txt
Modified:
pypy/release/1.2.x/LICENSE
pypy/release/1.2.x/pypy/doc/architecture.txt
pypy/release/1.2.x/pypy/doc/contributor.txt
pypy/release/1.2.x/pypy/doc/docindex.txt
pypy/release/1.2.x/pypy/doc/download.txt
pypy/release/1.2.x/pypy/doc/extradoc.txt
pypy/release/1.2.x/pypy/doc/faq.txt
pypy/release/1.2.x/pypy/doc/getting-started-dev.txt
pypy/release/1.2.x/pypy/doc/getting-started-python.txt
pypy/release/1.2.x/pypy/doc/getting-started.txt
pypy/release/1.2.x/pypy/doc/how-to-release.txt
pypy/release/1.2.x/pypy/doc/index.txt
pypy/release/1.2.x/pypy/doc/jit/overview.txt
pypy/release/1.2.x/pypy/doc/jit/pyjitpl5.txt
pypy/release/1.2.x/pypy/doc/project-ideas.txt
pypy/release/1.2.x/pypy/doc/tool/makecontributor.py
pypy/release/1.2.x/pypy/doc/translation.txt
Log:
svn merge svn+ssh://codespeak.net/svn/pypy/trunk -r71631:71659
Modified: pypy/release/1.2.x/LICENSE
==============================================================================
--- pypy/release/1.2.x/LICENSE (original)
+++ pypy/release/1.2.x/LICENSE Fri Mar 5 15:12:41 2010
@@ -35,18 +35,18 @@
copyrighted by one or more of the following people and organizations:
Armin Rigo
- Samuele Pedroni
+ Maciej Fijalkowski
Carl Friedrich Bolz
- Maciek Fijalkowski
- Michael Hudson
+ Samuele Pedroni
Antonio Cuni
+ Michael Hudson
Christian Tismer
Holger Krekel
Eric van Riet Paap
Richard Emslie
Anders Chrigstrom
- Aurelien Campeas
Amaury Forgeot d Arc
+ Aurelien Campeas
Anders Lehmann
Niklaus Haldimann
Seo Sanghyeon
@@ -54,11 +54,12 @@
Lawrence Oluyede
Jakub Gustak
Guido Wesdorp
- Niko Matsakis
- Toon Verwaest
+ Benjamin Peterson
Alexander Schremmer
+ Niko Matsakis
Ludovic Aubry
Alex Martelli
+ Toon Verwaest
Stephan Diehl
Adrien Di Mascio
Stefan Schwarzer
@@ -66,8 +67,8 @@
Patrick Maupin
Jacob Hallen
Laura Creighton
- Camillo Bruni
Bob Ippolito
+ Camillo Bruni
Simon Burton
Bruno Gola
Alexandre Fayolle
@@ -75,34 +76,35 @@
Guido van Rossum
Valentino Volonghi
Adrian Kuhn
- Anders Hammarquist
Paul deGrandis
Gerald Klix
Wanja Saatkamp
+ Anders Hammarquist
Oscar Nierstrasz
Eugene Oden
Lukas Renggli
- Bartosz SKOWRON
Guenter Jantzen
Dinu Gherman
+ Bartosz SKOWRON
Georg Brandl
- Benjamin Peterson
Ben Young
- Nicolas Chauvat
Jean-Paul Calderone
+ Nicolas Chauvat
Rocco Moretti
Michael Twomey
- Boris Feigin
+ boria
Jared Grubb
Olivier Dormond
Stuart Williams
Jens-Uwe Mager
Justas Sadzevicius
+ Mikael Schönenberg
Brian Dorsey
Jonathan David Riehl
Beatrice During
Elmo Mäntynen
Andreas Friedge
+ Alex Gaynor
Anders Qvist
Alan McIntyre
Bert Freudenberg
Modified: pypy/release/1.2.x/pypy/doc/architecture.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/architecture.txt (original)
+++ pypy/release/1.2.x/pypy/doc/architecture.txt Fri Mar 5 15:12:41 2010
@@ -250,7 +250,7 @@
.. _`Extreme Programming`: http://www.extremeprogramming.org/
.. _fast: faq.html#how-fast-is-pypy
-.. _`very compliant`: http://codespeak.net:8099/summary?category=lib-python&branch=%3Ctrunk%3E
+.. _`very compliant`: cpython_differences.html
.. _`RPython`: coding-guide.html#rpython
Modified: pypy/release/1.2.x/pypy/doc/contributor.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/contributor.txt (original)
+++ pypy/release/1.2.x/pypy/doc/contributor.txt Fri Mar 5 15:12:41 2010
@@ -8,18 +8,18 @@
Armin Rigo
- Samuele Pedroni
+ Maciej Fijalkowski
Carl Friedrich Bolz
- Maciek Fijalkowski
- Michael Hudson
+ Samuele Pedroni
Antonio Cuni
+ Michael Hudson
Christian Tismer
Holger Krekel
Eric van Riet Paap
Richard Emslie
Anders Chrigstrom
- Aurelien Campeas
Amaury Forgeot d Arc
+ Aurelien Campeas
Anders Lehmann
Niklaus Haldimann
Seo Sanghyeon
@@ -27,11 +27,12 @@
Lawrence Oluyede
Jakub Gustak
Guido Wesdorp
- Niko Matsakis
- Toon Verwaest
+ Benjamin Peterson
Alexander Schremmer
+ Niko Matsakis
Ludovic Aubry
Alex Martelli
+ Toon Verwaest
Stephan Diehl
Adrien Di Mascio
Stefan Schwarzer
@@ -39,8 +40,8 @@
Patrick Maupin
Jacob Hallen
Laura Creighton
- Camillo Bruni
Bob Ippolito
+ Camillo Bruni
Simon Burton
Bruno Gola
Alexandre Fayolle
@@ -48,46 +49,46 @@
Guido van Rossum
Valentino Volonghi
Adrian Kuhn
- Anders Hammarquist
Paul deGrandis
Gerald Klix
Wanja Saatkamp
+ Anders Hammarquist
Oscar Nierstrasz
Eugene Oden
Lukas Renggli
- Bartosz SKOWRON
Guenter Jantzen
Dinu Gherman
+ Bartosz SKOWRON
Georg Brandl
Ben Young
- Nicolas Chauvat
Jean-Paul Calderone
+ Nicolas Chauvat
Rocco Moretti
Michael Twomey
- Boris Feigin
+ boria
Jared Grubb
Olivier Dormond
Stuart Williams
Jens-Uwe Mager
Justas Sadzevicius
+ Mikael Schönenberg
Brian Dorsey
Jonathan David Riehl
Beatrice During
Elmo Mäntynen
Andreas Friedge
+ Alex Gaynor
Anders Qvist
Alan McIntyre
Bert Freudenberg
Pieter Zieschang
- Ignas Mikalajunas
Jacob Oscarson
Lutz Paelike
- Benjamin Peterson
Michael Schneider
Artur Lisiecki
Lene Wagner
Christopher Armstrong
- Joshua Gilbert
+ Jan de Mooij
Jacek Generowicz
Gasper Zejn
Stephan Busemann
@@ -95,11 +96,10 @@
Godefroid Chappelle
Toby Watson
Andrew Thompson
- Gintautas Miliauskas
+ Joshua Gilbert
Anders Sigfridsson
- Neil Shepperd
+ David Schneider
Michael Chermside
tav
- Igor Trindade Oliveira
Martin Blais
Victor Stinner
Modified: pypy/release/1.2.x/pypy/doc/docindex.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/docindex.txt (original)
+++ pypy/release/1.2.x/pypy/doc/docindex.txt Fri Mar 5 15:12:41 2010
@@ -73,9 +73,9 @@
Windows, on top of .NET, and on top of Java.
To dig into PyPy it is recommended to try out the current
Subversion HEAD, which is always working or mostly working,
-instead of the `release 1.1.0`__.
+instead of the latest release, which is `1.2.0`__.
-.. __: release-1.1.0.html
+.. __: release-1.2.0.html
PyPy is mainly developed on Linux and Mac OS X. Windows is supported,
but platform-specific bugs tend to take longer before we notice and fix
Modified: pypy/release/1.2.x/pypy/doc/download.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/download.txt (original)
+++ pypy/release/1.2.x/pypy/doc/download.txt Fri Mar 5 15:12:41 2010
@@ -2,19 +2,28 @@
Download one of the following release files:
=============================================
-PyPy 1.1 Sources:
+PyPy 1.2 Sources:
-----------------
-* `pypy-1.1.0.tar.bz2`_ (sources, unix line endings) or
-* `pypy-1.1.0.tar.gz`_ (sources, unix line endings) or
-* `pypy-1.1.0.zip`_ (sources, windows line-endings)
-
-.. _`pypy-1.1.0.tar.bz2`: http://codespeak.net/download/pypy/pypy-1.1.0.tar.bz2
-.. _`pypy-1.1.0.zip`: http://codespeak.net/download/pypy/pypy-1.1.0.zip
-.. _`pypy-1.1.0.tar.gz`: http://codespeak.net/download/pypy/pypy-1.1.0.tar.gz
+* `pypy-1.2.0.tar.bz2`_ (sources, unix line endings) or
+* `pypy-1.2.0.tar.gz`_ (sources, unix line endings) or
+* `pypy-1.2.0.zip`_ (sources, windows line-endings)
+
+.. _`pypy-1.2.0.tar.bz2`: http://codespeak.net/download/pypy/pypy-1.2.0.tar.bz2
+.. _`pypy-1.2.0.zip`: http://codespeak.net/download/pypy/pypy-1.2.0.zip
+.. _`pypy-1.2.0.tar.gz`: http://codespeak.net/download/pypy/pypy-1.2.0.tar.gz
Prebuilt binaries
~~~~~~~~~~~~~~~~~
-We do not provide prebuilt binaries yet (but would happily
-link to other people's pages with one version or another).
+XXX
+
+The ``lang`` repository
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``lang`` part of our repository, which contains other interpreters
+developped mostly as external contributions, has moved and is no longer
+included in the above packages. You can grab it by `browsing the
+Subversion source`__.
+
+.. __: http://codespeak.net/svn/pypy/lang/
Modified: pypy/release/1.2.x/pypy/doc/extradoc.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/extradoc.txt (original)
+++ pypy/release/1.2.x/pypy/doc/extradoc.txt Fri Mar 5 15:12:41 2010
@@ -7,6 +7,9 @@
*Articles about PyPy published so far, most recent first:* (bibtex_ file)
+* `High performance implementation of Python for CLI/.NET with JIT compiler generation for dynamic languages`_,
+ A. Cuni, Ph.D. thesis
+
* `Tracing the Meta-Level: PyPy's Tracing JIT Compiler`_,
C.F. Bolz, A. Cuni, M. Fijalkowski, A. Rigo
@@ -55,6 +58,7 @@
.. _bibtex: http://codespeak.net/svn/pypy/extradoc/talk/bibtex.bib
+.. _`High performance implementation of Python for CLI/.NET with JIT compiler generation for dynamic languages`: http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf
.. _`How to *not* write Virtual Machines for Dynamic Languages`: http://codespeak.net/svn/pypy/extradoc/talk/dyla2007/dyla.pdf
.. _`Tracing the Meta-Level: PyPy's Tracing JIT Compiler`: http://codespeak.net/svn/pypy/extradoc/talk/icooolps2009/bolz-tracing-jit.pdf
.. _`Faster than C#: Efficient Implementation of Dynamic Languages on .NET`: http://codespeak.net/svn/pypy/extradoc/talk/icooolps2009-dotnet/cli-jit.pdf
@@ -72,9 +76,17 @@
Talks and Presentations
----------------------------------
+Talks in 2010
++++++++++++++
+
+* `PyCon 2010`_.
+
+
Talks in 2009
+++++++++++++
+* `RuPy 2009`_.
+
* `EuroPython talks 2009`_.
* `PyCon talks 2009`_.
@@ -227,6 +239,8 @@
* `Architecture introduction slides`_ a mostly up-to-date
introduction for the Amsterdam PyPy-Sprint Dec 2003.
+.. _`PyCon 2010`: http://morepypy.blogspot.com/2010/02/pycon-2010-report.html
+.. _`RuPy 2009`: http://morepypy.blogspot.com/2009/11/pypy-on-rupy-2009.html
.. _`PyPy 3000`: http://codespeak.net/pypy/extradoc/talk/ep2006/pypy3000.txt
.. _`What can PyPy do for you`: http://codespeak.net/pypy/extradoc/talk/ep2006/usecases-slides.html
.. _`PyPy introduction at EuroPython 2006`: http://codespeak.net/pypy/extradoc/talk/ep2006/intro.pdf
Modified: pypy/release/1.2.x/pypy/doc/faq.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/faq.txt (original)
+++ pypy/release/1.2.x/pypy/doc/faq.txt Fri Mar 5 15:12:41 2010
@@ -56,10 +56,12 @@
OS X and mostly works under Windows too (but is tested there less
extensively). PyPy needs a CPython running on the target platform to
bootstrap, as cross compilation is not really meant to work yet.
-At the moment you need CPython 2.4 (with ctypes 0.9.9.6 or newer) or
-CPython 2.5 for the translation process.
+At the moment you need CPython 2.4 (with ctypes) or CPython 2.5 or 2.6
+for the translation process.
-PyPy also basically works in a 64-bit Linux environment.
+PyPy also basically works in a 64-bit Linux environment, but
+*it requires a 32-bit Intel CPU* for the JIT right now. (It works
+fine in a 32-bit chroot of an Intel 64.)
------------------------------------------------
Which Python version (2.x?) does PyPy implement?
@@ -131,19 +133,25 @@
.. _whysoslow:
-The answer to this question depends on how the PyPy interpreter is run. When
-optimized and translated to C, the PyPy interpreter runs somewhere between 1
-and 2 times slower than CPython. If the PyPy interpreter is run on top of
-CPython, i.e., without translation of any kind, then it is slower by a factor
-of 2000. Obtaining good measurements for the performance when run on the CLI or
-JVM is difficult, but it is safe to say that PyPy currently runs slower than
-IronPython (CLI) or Jython (JVM) for most tests.
-
-The work on the Just-In-Time compiler is currently at its fifth revision,
-but it looks like this revision is finally going to make it. It is work
-in progress; see the `JIT documentation`_.
+In three words, PyPy is "kind of fast". In more than three
+words, the answer to this question is hard to give as a single
+number. The fastest PyPy available so far is clearly PyPy
+`with a JIT included`_, optimized and translated to C. This
+version of PyPy is "kind of fast" in the sense that there are
+numerous examples of Python code that run *much faster* than
+CPython, up to a large number of times faster. And there are
+also examples of code that are just as slow as without the
+JIT. A PyPy that does not include a JIT has performance that
+is more predictable: it runs generally somewhere between 1 and
+2 times slower than CPython, in the worst case up to 4 times
+slower.
+
+Obtaining good measurements for the performance when run on
+the CLI or JVM is difficult, but the JIT on the CLI `seems to
+work nicely`__ too.
-.. _`JIT documentation`: jit/index.html
+.. __: http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf
+.. _`with a JIT included`: jit/index.html
.. _`prolog and javascript`:
@@ -163,10 +171,11 @@
Currently, we have preliminary versions of a JavaScript interpreter
(Leonardo Santagada as his Summer of PyPy project), a `Prolog interpreter`_
(Carl Friedrich Bolz as his Bachelor thesis), and a `SmallTalk interpreter`_
-(produced during a sprint). All of them are unfinished at the moment.
+(produced during a sprint). `All of them`_ are unfinished at the moment.
.. _`Prolog interpreter`: http://codespeak.net/svn/pypy/lang/prolog/
.. _`SmallTalk interpreter`: http://dx.doi.org/10.1007/978-3-540-89275-5_7
+.. _`All of them`: http://codespeak.net/svn/pypy/lang/
Development
========================================================================
Modified: pypy/release/1.2.x/pypy/doc/getting-started-dev.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/getting-started-dev.txt (original)
+++ pypy/release/1.2.x/pypy/doc/getting-started-dev.txt Fri Mar 5 15:12:41 2010
@@ -334,7 +334,7 @@
++++++++++++++++++++++++++++
`ctypes`_ is included in CPython 2.5 and higher. CPython 2.4 users needs to
-install it (version 0.9.9.6 or later) if they want to run low-level tests. See
+install it if they want to run low-level tests. See
the `download page of ctypes`_.
.. _`download page of ctypes`: http://sourceforge.net/project/showfiles.php?group_id=71702
Modified: pypy/release/1.2.x/pypy/doc/getting-started-python.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/getting-started-python.txt (original)
+++ pypy/release/1.2.x/pypy/doc/getting-started-python.txt Fri Mar 5 15:12:41 2010
@@ -47,34 +47,28 @@
* ``libncurses-dev`` (for the optional ``_minimal_curses`` module)
* ``libexpat1-dev`` (for the optional ``pyexpat`` module)
* ``libssl-dev`` (for the optional ``_ssl`` module)
- * ``libgc-dev`` (only when translating with `--opt=0, 1` or `size`)
+ * ``libgc-dev`` (Boehm: only when translating with `--opt=0, 1` or `size`)
2. Translation is somewhat time-consuming (30 min to
over one hour) and RAM-hungry. If you have less than 1.5 GB of
RAM (or a slow machine) you might want to pick the
`optimization level`_ `1` in the next step. A level of
- `2` or `3` gives much better results, though.
+ `2` or `3` or `jit` gives much better results, though.
Let me stress this another time: at ``--opt=1`` you get the Boehm
GC, which is here mostly for historical and for testing reasons.
You really do not want to pick it. The resulting ``pypy-c`` is
slow.
- Alternatively, if you want to enable the experimental JIT, choose
- the optimization level ``jit``.
-
3. Run::
cd pypy/translator/goal
- python translate.py --opt=3 targetpypystandalone.py
-
- possibly replacing ``--opt=3`` with ``--opt=jit`` or another
- `optimization level`_ of your choice.
+ python translate.py --opt=jit targetpypystandalone.py
- On Linux 32-bit Intel machines, you can get some extra speed
- (and extra translation time) by adding ``--gcrootfinder=asmgcc``
- just after the ``--opt`` option. (This option is implied by
- ``--opt=jit``.)
+ possibly replacing ``--opt=jit`` with another `optimization level`_
+ of your choice like ``--opt=2`` if you do not want the included JIT
+ compiler. (The default level so far is 2. Do not use ``--opt=jit``
+ on something else than Intel **32-bit** machines.)
.. _`optimization level`: config/opt.html
@@ -99,11 +93,13 @@
>>>>
This executable can be moved around or copied on other machines; see
-Installation_ below.
+Installation_ below. For now a JIT-enabled ``pypy-c`` always produces
+debugging output to stderr when it exits, unless translated with
+``--jit-debug=off``.
The ``translate.py`` script takes a very large number of options controlling
what to translate and how. See ``translate.py -h``. Some of the more
-interesting options are:
+interesting options (but for now incompatible with the JIT) are:
* ``--stackless``: this produces a pypy-c that includes features
inspired by `Stackless Python <http://www.stackless.com>`__.
@@ -121,54 +117,12 @@
.. _`translate PyPy with the thunk object space`:
-Translating with the thunk object space
+Translating with non-standard options
++++++++++++++++++++++++++++++++++++++++
-One of the original features provided by PyPy is the "thunk"
-object space, providing lazily-computed objects in a fully
-transparent manner::
-
- cd pypy
- python bin/py.py -o thunk
-
- >>>> from __pypy__ import thunk
- >>>> def longcomputation(lst):
- .... print "computing..."
- .... return sum(lst)
- ....
- >>>> x = thunk(longcomputation, range(5))
- >>>> y = thunk(longcomputation, range(10))
-
-From the application perspective, ``x`` and ``y`` represent
-exactly the objects being returned by the ``longcomputation()``
-invocations. You can put these objects into a dictionary
-without triggering the computation::
-
- >>>> d = {5: x, 10: y}
- >>>> result = d[5]
- >>>> result
- computing...
- 10
- >>>> type(d[10])
- computing...
- <type 'int'>
- >>>> d[10]
- 45
-
-It is interesting to note that this lazy-computing Python extension
-is solely implemented in a small `objspace/thunk.py`_ file consisting
-of around 200 lines of code.
-
-It is also possible to translate a PyPy version using the "thunk" object
-space::
-
- cd pypy/translator/goal
- python translate.py targetpypystandalone.py --objspace=thunk
-
-the example above should work in the translated result.
-
-If you want know more about pypy-exclusive features go to `objspace proxies`_
-document.
+It is possible to have non-standard features enabled for translation,
+but they are not really tested any more. Look for example at the
+`objspace proxies`_ document.
.. _`objspace proxies`: objspace-proxies.html
@@ -181,7 +135,15 @@
./translate.py --backend=cli targetpypystandalone.py
-The executable and all its dependecies will be stored in the
+Or better, try out the experimental `branch/cli-jit`_ described by
+Antonio Cuni's `Ph.D. thesis`_ and translate with the JIT::
+
+ ./translate.py -Ojit --backend=cli targetpypystandalone.py
+
+.. _`branch/cli-jit`: http://codespeak.net/svn/pypy/branch/cli-jit/
+.. _`Ph.D. thesis`: http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf
+
+The executable and all its dependencies will be stored in the
./pypy-cli-data directory. To run pypy.NET, you can run
./pypy-cli-data/main.exe. If you are using Linux or Mac, you can use
the convenience ./pypy-cli script::
@@ -251,11 +213,11 @@
``PREFIX/pypy/lib`` can all be found. The prefixes that are tried are::
.
- ./share/pypy-1.1
+ ./share/pypy-1.2
..
- ../share/pypy-1.1
+ ../share/pypy-1.2
../..
- ../../share/pypy-1.1
+ ../../share/pypy-1.2
../../..
etc.
@@ -334,11 +296,6 @@
.. _`CLI backend`: cli-backend.html
.. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
.. _clr: clr-module.html
-.. _`CPythons core language regression tests`: http://codespeak.net:8099/summary?category=lib-python&branch=%3Ctrunk%3E
+.. _`CPythons core language regression tests`: http://codespeak.net:8099/summary?category=applevel&branch=%3Ctrunk%3E
.. include:: _ref.txt
-
-
-
-
-
Modified: pypy/release/1.2.x/pypy/doc/getting-started.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/getting-started.txt (original)
+++ pypy/release/1.2.x/pypy/doc/getting-started.txt Fri Mar 5 15:12:41 2010
@@ -14,10 +14,9 @@
Python itself, flexible and easy to experiment with.
We target a large variety of platforms, small and large, by providing a
compiler toolsuite that can produce custom Python versions. Platform, memory
-and threading models are aspects of the translation process - as
-opposed to encoding low level details into the language implementation itself.
-Eventually, dynamic optimization techniques - implemented as another
-translation aspect - should become robust against language changes. `more...`_
+and threading models, as well as the JIT compiler itself, are aspects of the
+translation process - as opposed to encoding low level details into the
+language implementation itself. `more...`_
.. _Python: http://docs.python.org/ref
.. _`more...`: architecture.html
Modified: pypy/release/1.2.x/pypy/doc/how-to-release.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/how-to-release.txt (original)
+++ pypy/release/1.2.x/pypy/doc/how-to-release.txt Fri Mar 5 15:12:41 2010
@@ -23,14 +23,14 @@
some of the next updates may be done before or after branching; make
sure things are ported back to the trunk and to the branch as
necessary
-* update dist/pypy/doc/contributor.txt (and possibly dist/LICENSE)
-* update dist/README
-* write release announcement dist/pypy/doc/release-x.y(.z).txt
+* update pypy/doc/contributor.txt (and possibly LICENSE)
+* update README
+* write release announcement pypy/doc/release-x.y(.z).txt
the release announcement should contain a direct link to the download page
(which is getting started).
-* update dist/pypy/doc/getting-started.txt links at the top
+* update pypy/doc/getting-started.txt links at the top
and release number references, make sure it is generally up-to-date
-* use, after the necessary updates, dist/pypy/tool/makerelease.py to
+* use, after the necessary updates, pypy/tool/makerelease.py to
make the tarballs on codespeak; this generates html doc for the
tarballs too. Use::
@@ -44,6 +44,8 @@
if some stuff is missing. We have some support for running part of
our nightly tests on tarballs (see
http://codespeak.net/svn/user/pedronis/tarball-testing).
-* write a news item for the release in dist/pypy/doc/news.txt
+* write a news item for the release in pypy/doc/news.txt
+* update http://codespeak.net/svn/pypy/dist and codespeak's
+ precomputed html files
* send announcements to pypy-dev, pypy-funding, python-list,
python-announce, python-dev ...
Modified: pypy/release/1.2.x/pypy/doc/index.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/index.txt (original)
+++ pypy/release/1.2.x/pypy/doc/index.txt Fri Mar 5 15:12:41 2010
@@ -8,7 +8,7 @@
Getting into PyPy ...
=============================================
-* `Release 1.1`_: the latest official release
+* `Release 1.2`_: the latest official release
* `PyPy Blog`_: news and status info about PyPy
@@ -56,4 +56,4 @@
.. _`Documentation`: docindex.html
.. _`Getting Started`: getting-started.html
.. _papers: extradoc.html
-.. _`Release 1.1`: release-1.1.0.html
+.. _`Release 1.2`: release-1.2.0.html
Modified: pypy/release/1.2.x/pypy/doc/jit/overview.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/jit/overview.txt (original)
+++ pypy/release/1.2.x/pypy/doc/jit/overview.txt Fri Mar 5 15:12:41 2010
@@ -16,23 +16,30 @@
--------
Writing an interpreter for a complex dynamic language like Python is not
-a small task. So doing it a high-level language looks like a good idea,
-because high-level languages have many advantages over low-level ones
-(flexibility, ease of implementation, no low-level issues...). This is
-the basic observation behind PyPy.
-
-But coding in a high-level language has other benefits beyond the
-obvious ones. Perhaps most importantly, it allows the language
-interpreter to be analyzed when turned into a compiler. This is
-precisely what our JIT compiler generator does. Based on tracing
-JIT techniques, **it can turn the interpreter of an arbitrary
-dynamic language into a just-in-time compiler for the same language.**
-It works mostly automatically and only needs guidance by the language
-implementor in the form of a small number of hints in the source code of
-the interpreter. The resulting JIT compiler has the same language
-semantics as the original interpreter by construction. It generates
-machine code for the user program while aggressively optimizing it,
-leading to a big performance boost.
+a small task, especially if, for performance goals, we want to write a
+Just-in-Time (JIT) compiler too.
+
+The good news is that it's not what we did. We indeed wrote an
+interpreter for Python, but we never wrote any JIT compiler for Python
+in PyPy. Instead, we use the fact that our interpreter for Python is
+written in RPython, which is a nice, high-level language -- and we turn
+it *automatically* into a JIT compiler for Python.
+
+This transformation is of course completely transparent to the user,
+i.e. the programmer writing Python programs. The goal (which we
+achieved) is to support *all* Python features -- including, for example,
+random frame access and debuggers. But it is also mostly transparent to
+the language implementor, i.e. to the source code of the Python
+interpreter. It only needs a bit of guidance: we had to put a small
+number of hints in the source code of our interpreter. Based on these
+hints, the *JIT compiler generator* produces a JIT compiler which has
+the same language semantics as the original interpreter by construction.
+This JIT compiler itself generates machine code at runtime, aggressively
+optimizing the user's program and leading to a big performance boost,
+while keeping the semantics unmodified. Of course, the interesting bit
+is that our Python language interpreter can evolve over time without
+getting out of sync with the JIT compiler.
+
The path we followed
--------------------
@@ -47,13 +54,15 @@
compilers. If this turns out to be correct, the practical speed of
dynamic languages could be vastly improved.
-Today (beginning 2009), our prototype is no longer using partial
-evaluation -- at least not in a way that would convince paper reviewers.
-It is instead based on the notion of *tracing JIT,* recently studied for
-Java and JavaScript. When compared to all existing tracing JITs so far,
-however, partial evaluation gives us some extra techniques that we
-already had in our previous JIT generators, notably how to optimize
-structures by removing allocations.
+All these previous JIT compiler generators were producing JIT compilers
+similar to the hand-written Psyco. But today, starting from 2009, our
+prototype is no longer using partial evaluation -- at least not in a way
+that would convince paper reviewers. It is instead based on the notion
+of *tracing JIT,* recently studied for Java and JavaScript. When
+compared to all existing tracing JITs so far, however, partial
+evaluation gives us some extra techniques that we already had in our
+previous JIT generators, notably how to optimize structures by removing
+allocations.
The closest comparison to our current JIT is Tamarin's TraceMonkey.
However, this JIT compiler is written manually, which is quite some
@@ -87,12 +96,8 @@
is modified, so that they cannot get out of sync no matter how fast
the language evolves.
-* Fast enough: we think that we can get some rather good performance out
- of the generated JIT compilers. That's the whole point, of course.
- Previous experience shows that it should be possible. Our previous
- generated JIT compilers were similar to the hand-written Psyco; due
- to limits in automating the way Psyco works, our current generated
- JIT compilers are instead similar to tracing JITs like TraceMonkey.
+* Fast enough: we can get some rather good performance out of the
+ generated JIT compilers. That's the whole point, of course.
Alternative approaches to improve speed
Modified: pypy/release/1.2.x/pypy/doc/jit/pyjitpl5.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/jit/pyjitpl5.txt (original)
+++ pypy/release/1.2.x/pypy/doc/jit/pyjitpl5.txt Fri Mar 5 15:12:41 2010
@@ -172,7 +172,7 @@
* `Tracing the Meta-Level: PyPy's Tracing JIT Compiler`__
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/ipcoolps2009/bolz-tracing-jit.pdf
+.. __: http://codespeak.net/svn/pypy/extradoc/talk/icooolps2009/bolz-tracing-jit-final.pdf
as well as the `blog posts with the JIT tag.`__
Modified: pypy/release/1.2.x/pypy/doc/project-ideas.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/project-ideas.txt (original)
+++ pypy/release/1.2.x/pypy/doc/project-ideas.txt Fri Mar 5 15:12:41 2010
@@ -1,8 +1,6 @@
Independent project ideas relating to PyPy
==========================================
-*NOTE: This is an extremely outdated list, don't consider it seriously*
-
PyPy allows experimentation in many directions -- indeed facilitating
experimentation in language implementation was one of the main
motivations for the project. This page is meant to collect some ideas
@@ -23,35 +21,41 @@
--------------------------------
PyPy's Just-In-Time compiler relies on backends for actual code
-generation. Right now we are working on the ``pyjitpl5`` branch, which
-is not stable. Working on the JIT backends should be soon possible.
-Open ideas are to write a backend for AMD64 (Intel 64); or .NET or
-Java (requires porting the JIT frontend to ootype too, which is not too
-hard); or trying to use LLVM-JIT.
+generation. We have so far a 32-bit Intel backend, and a CLI one. Open
+ideas are to write a backend for **Intel 64** (AMD64); or a backend for
+Java; or trying again to use LLVM-JIT (which I do not really recommend).
CTypes
------
Support ctypes on more backends. Right now ctypes is supported only
-when compiling PyPy to C. A nice project would be to support it when
+when compiling PyPy to C, and there is a bit of unfinished work to
+support it on **Intel 64.** A nice project would be to support it when
compiling to .NET or the JVM. That's not too hard, the only thing needed
is to port a small module that does the actual invocation of external
-libraries (a related project would be to port this module to Jython or
-IronPython to get support for ctypes there).
+libraries (a related project is to port this module to Jython or
+IronPython to get support for ctypes there, which is something that was
+tried but not finished as far as I know).
.. _distribution:
.. _persistence:
-Experiment with distribution and persistence
---------------------------------------------
+Extensions of the Python language
+---------------------------------
+
++----------------------------------------------------------------------+
+| :NOTE: |
+| |
+| The ideas in this paragraph are marked as "experimental". We may |
+| or may not be interested in helping you out. You are warned :-) |
+| |
++----------------------------------------------------------------------+
One of the advantages of PyPy's implementation is that the Python-level type
of an object and its implementation are completely independent. This should
allow a much more intuitive interface to, for example, objects that are backed
-by a persistent store.
-
-The `transparent proxy`_ objects are a key step in this
+by a persistent store. The `transparent proxy`_ objects are a key step in this
direction; now all that remains is to implement the interesting bits :-)
An example project might be to implement functionality akin to the `ZODB's
@@ -61,15 +65,22 @@
Another example would be to implement a multi-CPU extension that internally
uses several processes and uses transparent proxies to share object views.
+Other ideas are to do something interesting with sandboxing_; or to
+work more on the Stackless_ features (e.g. integrate it with the JIT);
+or revive the logic object space, which tried to bring unification-like
+features to Python.
+
+.. _sandboxing: sandbox.html
+.. _Stackless: stackless.html
+
-Various Ideas
--------------
+Other languages
+---------------
-- improve one of the existing interpreters (e.g. the Prolog, the Scheme or
- the JavaScript interpreter or the Smalltalk VM), or start a new one
+Improve one of the `existing interpreters`__, or start a new one.
+Experiment with the JIT compiler generator.
-- revive the logic object space, which tried to bring unification-like
- features to Python
+.. __: http://codespeak.net/svn/pypy/lang/
Or else...
Modified: pypy/release/1.2.x/pypy/doc/tool/makecontributor.py
==============================================================================
--- pypy/release/1.2.x/pypy/doc/tool/makecontributor.py (original)
+++ pypy/release/1.2.x/pypy/doc/tool/makecontributor.py Fri Mar 5 15:12:41 2010
@@ -8,12 +8,12 @@
try:
path = py.std.sys.argv[1]
except IndexError:
- print "usage: %s PATH" %(py.std.sys.argv[0])
+ print "usage: %s ROOTPATH" %(py.std.sys.argv[0])
raise SystemExit, 1
d = {}
-for logentry in py.path.svnwc(py.std.sys.argv[1]).log():
+for logentry in py.path.svnwc(path).log():
a = logentry.author
if a in d:
d[a] += 1
@@ -30,6 +30,8 @@
cutoff = 5 # cutoff for authors in the LICENSE file
mark = False
for author, count in items:
+ if author in excluded:
+ continue
user = uconf.system.User(author)
try:
realname = user.realname.strip()
Modified: pypy/release/1.2.x/pypy/doc/translation.txt
==============================================================================
--- pypy/release/1.2.x/pypy/doc/translation.txt (original)
+++ pypy/release/1.2.x/pypy/doc/translation.txt Fri Mar 5 15:12:41 2010
@@ -27,7 +27,7 @@
this task into several steps, and the purpose of this document is to
introduce them.
-As of the 1.1 release, RPython_ programs can be translated into the following
+As of the 1.2 release, RPython_ programs can be translated into the following
languages/platforms: C/POSIX, CLI/.NET
and Java/JVM (in addition, there's `a backend`_ that translates
`application-level`_ into `interpreter-level`_ code, but this is a special
More information about the Pypy-commit
mailing list