[pypy-svn] rev 1110 - pypy/trunk/doc

lac at codespeak.net lac at codespeak.net
Mon Jul 7 19:51:08 CEST 2003

Author: lac
Date: Mon Jul  7 19:51:07 2003
New Revision: 1110

This is close to what the paper will say in time for OSCON.  But we can
keep editiung it if we thing it is a useful introduction.  I am going to
make slides for some of the headings....

Our names look very silly.  Strongly suggest for the web version you
link to silly pictures of yourself or something.

Modified: pypy/trunk/doc/oscon2003-paper.txt
--- pypy/trunk/doc/oscon2003-paper.txt	(original)
+++ pypy/trunk/doc/oscon2003-paper.txt	Mon Jul  7 19:51:07 2003
@@ -4,6 +4,26 @@
 A report from the PyPy project
+..  line-block::
+ Laura Creighton
+ Stephan Diehl
+ Dinu Gherman
+ Jacob Hallén
+ Michael Hudson
+ Günter Jantzen
+ Holger Krekel
+ Anders Lehmann
+ Jens-Uwe Mager
+ Alex Martelli
+ Tomek Meka
+ Rocco Morretti
+ Samuele Pedronis
+ Anna Ravencroft
+ Armin Rigo
+ Guido Van Rossum
+ Christian Tismer
 The PyPy_ [#]_ project aims at producing a simple runtime-system for
 the Python_ language, written in Python itself.  **C** and **Lisp**
 are elder examples of languages which are self-hosting.  More
@@ -63,16 +83,18 @@
 This raises an interesting question.  What would *doing more of those*  
 mean?  The PyPy project takes one approach.
 Terminology (a short digression)
 In PyPy there is a distinction between **application level code**, which
 is the world that PyPy is interpreting, and which can use the full features 
 of the language, and the **interpreter level code** which is the world
-that CPython is interpreting.  This needs to be written in a subset of Python.
+that CPython is interpreting.  The interpreter level code
+needs to be written in a restricted subset of Python.
 (Currently you are mainly restricted to immutable objects; no dicts, you can
 use globals but you cannot modify them.  *What defines Restricted Python?*
-is a matter of current debate.
+is a matter of current debate.)
 In a Python-like language, a running interpreter has three main parts:
@@ -291,6 +313,22 @@
 We currently have three object spaces at least partially implemented.
+A Word of History
+The PyPy project was started in January of 2003 by Armin Rigo,
+Christian Tismer and Holger Krekel. The latter organized the initial
+Coding-Sprint in Hildesheim, Germany where the interpreter and the
+Trivial Object Space were implemented and people first got together.
+The second sprint in Göteborg, Sweden was organized by Jacob Hallén and
+Laura Creighton and it resulted in much of today's Standard Object Space
+implementation.  Benjamin Henrion and Godefroid Chapelle organized the
+third sprint in Louvain-La-Neuve, Belgium which led to a pretty complete
+Standard ObjectSpace and interpreter and the beginnings of Abstract
+Interpretation (Annotation Object Space).  These three coding
+sprints in the course of half a year brought PyPy to existence, though
+there was some off-sprint development and discussions going on.
 The Trivial Object Space
 A PyPy interpreter using the Trivial Object Space is an
@@ -377,7 +415,7 @@
  print (reduce(lambda x, y: x+y, [t[2] for t in slips], 0))/900
-Pypy said: 603 SEK, or appoximately 50 USD.   Don't believe people who
+Pypy said: 603 SEK, or appoximately 75 USD.   Don't believe people who
 tell you that Sprints are too expensive to hold. 
 The Annotation Object Space
@@ -386,7 +424,7 @@
 Brussels), June 21 - 24.  Great progress was made with the The
 Annotation Object Space, and began abstract, symbolic interpretation.
 (We also spent a lot of time firming up the Standard Object Space, and
-trying to write documentation).
+improving our documentation, and our documentation tools).
 In the two object spaces so far, application-level objects are
 represented in the interpreter as objects that represent a value.
@@ -522,17 +560,31 @@
-It is a little early for conclusions, but our architecture seems to
-be working so far.  Sprints are a lot of fun, and a great way to write
-code, and meet interesting people.  
+It is a little early for conclusions, but our architecture seems to be
+working so far.  Sprints are a lot of fun, and a great way to write
+code, and meet interesting people.  We're productively lazy, and so
+have created a few tools that could possibly be useful to other
+projects ... parts of our test rig, for example, and automatic ReST
+processing on checkins.  An Infastructure mini-Sprint, again at
+Hildesheim, is planned which may produce tools good enough to package
+and release separately.  
 Thank you
-The members of the PyPy team are distinctly grateful to RyanAir_, without
-which holding Sprints would be prohibitively expensive, and the
+As was to be expected we are using Python web applications (mailman_,
+roundup_, moinmoin_) to host our project.
+.. _mailman: http://www.list.org/
+.. _roundup: http://roundup.sourceforge.net/
+.. _moinmoin: http://moin.sourceforge.net/
+The members of the PyPy team are especiallly grateful to RyanAir_, without
+which holding Sprints would be prohibitively expensive, freenode.net_
+which lets us communicate with each other on the #pypy channel, and the
 Subversion_ development team, without whom restructuring the entire universe
 whenever we feel like it would have been close to impossible.
+.. _freenode.net: http://www.freenode.net/
 .. _RyanAir: http://www.ryanair.com/
 .. _Subversion: http://subversion.tigris.org/

More information about the Pypy-commit mailing list