Commits

Daniel Roberts  committed 06542ec Merge

Merge with default.

  • Participants
  • Parent commits 84a7ba8, 61fefec
  • Branches fold_intadd

Comments (0)

Files changed (620)

 ^pypy/doc/discussion/.+\.html$
 ^include/.+\.h$
 ^include/.+\.inl$
+^pypy/doc/_build/.*$
 ^pypy/doc/config/.+\.html$
 ^pypy/doc/config/style\.css$
 ^pypy/doc/jit/.+\.html$
 80037 greenlet
-80348 lib_pypy/pyrepl
+80409 lib_pypy/pyrepl
 80409 testrunner

File lib-python/modified-2.7.0/ctypes/test/test_internals.py

 import unittest
 from ctypes import *
 from sys import getrefcount as grc
-from ctypes.test import xfail
 
 # XXX This test must be reviewed for correctness!!!
 
         self.assertEqual(refcnt, grc(i))
         self.assertEqual(ci._objects, None)
 
-    @xfail
     def test_c_char_p(self):
         s = "Hello, World"
         refcnt = grc(s)
         cs = c_char_p(s)
         self.assertEqual(refcnt + 1, grc(s))
-        self.assertSame(cs._objects, s)
+        try:
+            # Moving gcs need to allocate a nonmoving buffer
+            cs._objects._obj
+        except AttributeError:
+            self.assertSame(cs._objects, s)
+        else:
+            self.assertSame(cs._objects._obj, s)
 
     def test_simple_struct(self):
         class X(Structure):

File lib-python/modified-2.7.0/ctypes/test/test_loading.py

 import sys, unittest
 import os
 from ctypes.util import find_library
-from ctypes.test import is_resource_enabled
+from ctypes.test import is_resource_enabled, xfail
 
 libc_name = None
 if os.name == "nt":
             self.assertRaises(AttributeError, dll.__getitem__, 1234)
 
     if os.name == "nt":
+        @xfail
         def test_1703286_A(self):
             from _ctypes import LoadLibrary, FreeLibrary
             # On winXP 64-bit, advapi32 loads at an address that does
             handle = LoadLibrary("advapi32")
             FreeLibrary(handle)
 
+        @xfail
         def test_1703286_B(self):
             # Since on winXP 64-bit advapi32 loads like described
             # above, the (arbitrarily selected) CloseEventLog function

File lib-python/modified-2.7.0/ctypes/test/test_parameters.py

 
         pa = c_wchar_p.from_param(c_wchar_p(u"123"))
         self.assertEqual(type(pa), c_wchar_p)
+    if sys.platform == "win32":
+        test_cw_strings = xfail(test_cw_strings)
 
     @xfail
     def test_int_pointers(self):

File lib-python/modified-2.7.0/sqlite3/test/regression.py

         """
         self.assertRaises(sqlite.Warning, self.con, 1)
 
+    def CheckUpdateDescriptionNone(self):
+        """
+        Call Cursor.update with an UPDATE query and check that it sets the
+        cursor's description to be None.
+        """
+        cur = self.con.cursor()
+        cur.execute("CREATE TABLE foo (id INTEGER)")
+        cur.execute("UPDATE foo SET id = 3 WHERE id = 1")
+        self.assertEqual(cur.description, None)
+
 def suite():
     regression_suite = unittest.makeSuite(RegressionTests, "Check")
     return unittest.TestSuite((regression_suite,))

File lib_pypy/_sqlite3.py

 from threading import _get_ident as thread_get_ident
 
 names = "sqlite3.dll libsqlite3.so.0 libsqlite3.so libsqlite3.dylib".split()
-for name in names: 
+for name in names:
     try:
-        sqlite = cdll.LoadLibrary(name) 
+        sqlite = cdll.LoadLibrary(name)
         break
     except OSError:
         continue
     return unicode(x, 'utf-8')
 
 class Connection(object):
-    def __init__(self, database, isolation_level="", detect_types=0, timeout=None, *args, **kwargs):
+    def __init__(self, database, isolation_level="", detect_types=0, timeout=None, cached_statements=None, factory=None):
         self.db = c_void_p()
         if sqlite.sqlite3_open(database, byref(self.db)) != SQLITE_OK:
             raise OperationalError("Could not open database")
         self.statement = None
 
     def _get_description(self):
+        if self.kind == "DML":
+            return None
         desc = []
         for i in xrange(sqlite.sqlite3_column_count(self.statement)):
             name = sqlite.sqlite3_column_name(self.statement, i).split("[")[0].strip()
 
 def _convert_result(con, val):
     if val is None:
-        sqlite.sqlite3_result_null(con)        
+        sqlite.sqlite3_result_null(con)
     elif isinstance(val, (bool, int, long)):
         sqlite.sqlite3_result_int64(con, int(val))
     elif isinstance(val, str):

File pypy/doc/Makefile

+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = _build
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html      to make standalone HTML files"
+	@echo "  dirhtml   to make HTML files named index.html in directories"
+	@echo "  pickle    to make pickle files"
+	@echo "  json      to make JSON files"
+	@echo "  htmlhelp  to make HTML files and a HTML help project"
+	@echo "  qthelp    to make HTML files and a qthelp project"
+	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  changes   to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck to check all external links for integrity"
+	@echo "  doctest   to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	-rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/PyPy.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/PyPy.qhc"
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+	      "run these through (pdf)latex."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."

File pypy/doc/__pypy__-module.rst

+=======================
+The ``__pypy__`` module
+=======================
+
+The ``__pypy__`` module is the main entry point to special features provided
+by PyPy's standard interpreter. Its content depends on `configuration options`_ 
+which may add new functionality and functions whose existence or non-existence 
+indicates the presence of such features. 
+
+.. _`configuration options`: config/index.html
+
+Generally available functionality
+=================================
+
+ - ``internal_repr(obj)``: return the interpreter-level representation of an
+   object.
+ - ``bytebuffer(length)``: return a new read-write buffer of the given length.
+   It works like a simplified array of characters (actually, depending on the
+   configuration the ``array`` module internally uses this).
+
+Thunk Object Space Functionality
+================================
+
+When the thunk object space is used (choose with :config:`objspace.name`),
+the following functions are put into ``__pypy__``:
+
+ - ``thunk``
+ - ``is_thunk``
+ - ``become``
+ - ``lazy``
+
+Those are all described in the `interface section of the thunk object space
+docs`_.
+
+For explanations and examples see the `thunk object space docs`_.
+
+.. _`thunk object space docs`: objspace-proxies.html#thunk
+.. _`interface section of the thunk object space docs`: objspace-proxies.html#thunk-interface
+
+Taint Object Space Functionality
+================================
+
+When the taint object space is used (choose with :config:`objspace.name`),
+the following names are put into ``__pypy__``:
+
+ - ``taint``
+ - ``is_tainted``
+ - ``untaint``
+ - ``taint_atomic``
+ - ``_taint_debug``
+ - ``_taint_look``
+ - ``TaintError``
+
+Those are all described in the `interface section of the taint object space
+docs`_.
+
+For more detailed explanations and examples see the `taint object space docs`_.
+
+.. _`taint object space docs`: objspace-proxies.html#taint
+.. _`interface section of the taint object space docs`: objspace-proxies.html#taint-interface
+
+Transparent Proxy Functionality
+===============================
+
+If `transparent proxies`_ are enabled (with :config:`objspace.std.withtproxy`)
+the following functions are put into ``__pypy__``:
+
+ - ``tproxy(typ, controller)``: Return something that looks like it is of type
+   typ. Its behaviour is completely controlled by the controller. See the docs
+   about `transparent proxies`_ for detail.
+
+ - ``get_tproxy_controller(obj)``: If obj is really a transparent proxy, return
+   its controller. Otherwise return None.
+
+.. _`transparent proxies`: objspace-proxies.html#tproxy
+
+
+Functionality available on py.py (not after translation)
+========================================================
+
+ - ``isfake(obj)``: returns True if ``obj`` is faked.
+
+ - ``interp_pdb()``: start a pdb at interpreter-level.
+
+
+

File pypy/doc/__pypy__-module.txt

-=======================
-The ``__pypy__`` module
-=======================
-
-The ``__pypy__`` module is the main entry point to special features provided
-by PyPy's standard interpreter. Its content depends on `configuration options`_ 
-which may add new functionality and functions whose existence or non-existence 
-indicates the presence of such features. 
-
-.. _`configuration options`: config/index.html
-
-Generally available functionality
-=================================
-
- - ``internal_repr(obj)``: return the interpreter-level representation of an
-   object.
- - ``bytebuffer(length)``: return a new read-write buffer of the given length.
-   It works like a simplified array of characters (actually, depending on the
-   configuration the ``array`` module internally uses this).
-
-Thunk Object Space Functionality
-================================
-
-When the thunk object space is used (choose with :config:`objspace.name`),
-the following functions are put into ``__pypy__``:
-
- - ``thunk``
- - ``is_thunk``
- - ``become``
- - ``lazy``
-
-Those are all described in the `interface section of the thunk object space
-docs`_.
-
-For explanations and examples see the `thunk object space docs`_.
-
-.. _`thunk object space docs`: objspace-proxies.html#thunk
-.. _`interface section of the thunk object space docs`: objspace-proxies.html#thunk-interface
-
-Taint Object Space Functionality
-================================
-
-When the taint object space is used (choose with :config:`objspace.name`),
-the following names are put into ``__pypy__``:
-
- - ``taint``
- - ``is_tainted``
- - ``untaint``
- - ``taint_atomic``
- - ``_taint_debug``
- - ``_taint_look``
- - ``TaintError``
-
-Those are all described in the `interface section of the taint object space
-docs`_.
-
-For more detailed explanations and examples see the `taint object space docs`_.
-
-.. _`taint object space docs`: objspace-proxies.html#taint
-.. _`interface section of the taint object space docs`: objspace-proxies.html#taint-interface
-
-Transparent Proxy Functionality
-===============================
-
-If `transparent proxies`_ are enabled (with :config:`objspace.std.withtproxy`)
-the following functions are put into ``__pypy__``:
-
- - ``tproxy(typ, controller)``: Return something that looks like it is of type
-   typ. Its behaviour is completely controlled by the controller. See the docs
-   about `transparent proxies`_ for detail.
-
- - ``get_tproxy_controller(obj)``: If obj is really a transparent proxy, return
-   its controller. Otherwise return None.
-
-.. _`transparent proxies`: objspace-proxies.html#tproxy
-
-
-Functionality available on py.py (not after translation)
-========================================================
-
- - ``isfake(obj)``: returns True if ``obj`` is faked.
-
- - ``interp_pdb()``: start a pdb at interpreter-level.
-
-
-

File pypy/doc/_ref.rst

+.. _`demo/`: ../../demo
+.. _`demo/pickle_coroutine.py`: ../../demo/pickle_coroutine.py
+.. _`lib-python/`: ../../lib-python
+.. _`lib-python/2.5.2/dis.py`: ../../lib-python/2.5.2/dis.py
+.. _`annotation/`:
+.. _`pypy/annotation`: ../../../../pypy/annotation
+.. _`pypy/annotation/annrpython.py`: ../../../../pypy/annotation/annrpython.py
+.. _`annotation/binaryop.py`: ../../../../pypy/annotation/binaryop.py
+.. _`pypy/annotation/builtin.py`: ../../../../pypy/annotation/builtin.py
+.. _`pypy/annotation/model.py`: ../../../../pypy/annotation/model.py
+.. _`bin/`: ../../../../pypy/bin
+.. _`config/`: ../../../../pypy/config
+.. _`pypy/config/pypyoption.py`: ../../../../pypy/config/pypyoption.py
+.. _`doc/`: ../../../../pypy/doc
+.. _`doc/config/`: ../../../../pypy/doc/config
+.. _`doc/discussion/`: ../../../../pypy/doc/discussion
+.. _`interpreter/`:
+.. _`pypy/interpreter`: ../../../../pypy/interpreter
+.. _`pypy/interpreter/argument.py`: ../../../../pypy/interpreter/argument.py
+.. _`interpreter/astcompiler/`:
+.. _`pypy/interpreter/astcompiler`: ../../../../pypy/interpreter/astcompiler
+.. _`pypy/interpreter/executioncontext.py`: ../../../../pypy/interpreter/executioncontext.py
+.. _`pypy/interpreter/function.py`: ../../../../pypy/interpreter/function.py
+.. _`interpreter/gateway.py`:
+.. _`pypy/interpreter/gateway.py`: ../../../../pypy/interpreter/gateway.py
+.. _`pypy/interpreter/generator.py`: ../../../../pypy/interpreter/generator.py
+.. _`pypy/interpreter/mixedmodule.py`: ../../../../pypy/interpreter/mixedmodule.py
+.. _`pypy/interpreter/module.py`: ../../../../pypy/interpreter/module.py
+.. _`pypy/interpreter/nestedscope.py`: ../../../../pypy/interpreter/nestedscope.py
+.. _`pypy/interpreter/pyopcode.py`: ../../../../pypy/interpreter/pyopcode.py
+.. _`interpreter/pyparser/`:
+.. _`pypy/interpreter/pyparser`: ../../../../pypy/interpreter/pyparser
+.. _`pypy/interpreter/pyparser/pytokenizer.py`: ../../../../pypy/interpreter/pyparser/pytokenizer.py
+.. _`pypy/interpreter/pyparser/parser.py`: ../../../../pypy/interpreter/pyparser/parser.py
+.. _`pypy/interpreter/pyparser/pyparse.py`: ../../../../pypy/interpreter/pyparser/pyparse.py
+.. _`pypy/interpreter/pyparser/future.py`: ../../../../pypy/interpreter/pyparser/future.py
+.. _`pypy/interpreter/pyparser/metaparser.py`: ../../../../pypy/interpreter/pyparser/metaparser.py
+.. _`pypy/interpreter/astcompiler/astbuilder.py`: ../../../../pypy/interpreter/astcompiler/astbuilder.py
+.. _`pypy/interpreter/astcompiler/optimize.py`: ../../../../pypy/interpreter/astcompiler/optimize.py
+.. _`pypy/interpreter/astcompiler/codegen.py`: ../../../../pypy/interpreter/astcompiler/codegen.py
+.. _`pypy/interpreter/astcompiler/tools/asdl_py.py`: ../../../../pypy/interpreter/astcompiler/tools/asdl_py.py
+.. _`pypy/interpreter/astcompiler/tools/Python.asdl`: ../../../../pypy/interpreter/astcompiler/tools/Python.asdl
+.. _`pypy/interpreter/astcompiler/assemble.py`: ../../../../pypy/interpreter/astcompiler/assemble.py
+.. _`pypy/interpreter/astcompiler/symtable.py`: ../../../../pypy/interpreter/astcompiler/symtable.py
+.. _`pypy/interpreter/astcompiler/asthelpers.py`: ../../../../pypy/interpreter/astcompiler/asthelpers.py
+.. _`pypy/interpreter/astcompiler/ast.py`: ../../../../pypy/interpreter/astcompiler/ast.py
+.. _`pypy/interpreter/typedef.py`: ../../../../pypy/interpreter/typedef.py
+.. _`lib/`:
+.. _`lib_pypy/`: ../../lib_pypy
+.. _`lib/distributed/`: ../../lib_pypy/distributed
+.. _`lib_pypy/stackless.py`: ../../lib_pypy/stackless.py
+.. _`lib_pypy/pypy_test/`: ../../lib_pypy/pypy_test
+.. _`module/`:
+.. _`pypy/module`:
+.. _`pypy/module/`: ../../../../pypy/module
+.. _`pypy/module/__builtin__/__init__.py`: ../../../../pypy/module/__builtin__/__init__.py
+.. _`pypy/module/_stackless/test/test_clonable.py`: ../../../../pypy/module/_stackless/test/test_clonable.py
+.. _`pypy/module/_stackless/test/test_composable_coroutine.py`: ../../../../pypy/module/_stackless/test/test_composable_coroutine.py
+.. _`objspace/`:
+.. _`pypy/objspace`: ../../../../pypy/objspace
+.. _`objspace/dump.py`: ../../../../pypy/objspace/dump.py
+.. _`objspace/flow/`: ../../../../pypy/objspace/flow
+.. _`objspace/std/`:
+.. _`pypy/objspace/std`: ../../../../pypy/objspace/std
+.. _`objspace/taint.py`: ../../../../pypy/objspace/taint.py
+.. _`objspace/thunk.py`:
+.. _`pypy/objspace/thunk.py`: ../../../../pypy/objspace/thunk.py
+.. _`objspace/trace.py`:
+.. _`pypy/objspace/trace.py`: ../../../../pypy/objspace/trace.py
+.. _`pypy/rlib`:
+.. _`rlib/`: ../../../../pypy/rlib
+.. _`pypy/rlib/rarithmetic.py`: ../../../../pypy/rlib/rarithmetic.py
+.. _`pypy/rlib/test`: ../../../../pypy/rlib/test
+.. _`pypy/rpython`:
+.. _`pypy/rpython/`:
+.. _`rpython/`: ../../../../pypy/rpython
+.. _`rpython/lltypesystem/`: ../../../../pypy/rpython/lltypesystem
+.. _`pypy/rpython/lltypesystem/lltype.py`:
+.. _`rpython/lltypesystem/lltype.py`: ../../../../pypy/rpython/lltypesystem/lltype.py
+.. _`rpython/memory/`: ../../../../pypy/rpython/memory
+.. _`rpython/memory/gc/generation.py`: ../../../../pypy/rpython/memory/gc/generation.py
+.. _`rpython/memory/gc/hybrid.py`: ../../../../pypy/rpython/memory/gc/hybrid.py
+.. _`rpython/memory/gc/markcompact.py`: ../../../../pypy/rpython/memory/gc/markcompact.py
+.. _`rpython/memory/gc/marksweep.py`: ../../../../pypy/rpython/memory/gc/marksweep.py
+.. _`rpython/memory/gc/semispace.py`: ../../../../pypy/rpython/memory/gc/semispace.py
+.. _`rpython/ootypesystem/`: ../../../../pypy/rpython/ootypesystem
+.. _`rpython/ootypesystem/ootype.py`: ../../../../pypy/rpython/ootypesystem/ootype.py
+.. _`rpython/rint.py`: ../../../../pypy/rpython/rint.py
+.. _`rpython/rlist.py`: ../../../../pypy/rpython/rlist.py
+.. _`rpython/rmodel.py`: ../../../../pypy/rpython/rmodel.py
+.. _`pypy/rpython/rtyper.py`: ../../../../pypy/rpython/rtyper.py
+.. _`pypy/rpython/test/test_llinterp.py`: ../../../../pypy/rpython/test/test_llinterp.py
+.. _`pypy/test_all.py`: ../../../../pypy/test_all.py
+.. _`tool/`: ../../../../pypy/tool
+.. _`tool/algo/`: ../../../../pypy/tool/algo
+.. _`tool/pytest/`: ../../../../pypy/tool/pytest
+.. _`pypy/translator`:
+.. _`translator/`: ../../../../pypy/translator
+.. _`translator/backendopt/`: ../../../../pypy/translator/backendopt
+.. _`translator/c/`: ../../../../pypy/translator/c
+.. _`translator/cli/`: ../../../../pypy/translator/cli
+.. _`translator/goal/`: ../../../../pypy/translator/goal
+.. _`pypy/translator/goal/targetnopstandalone.py`: ../../../../pypy/translator/goal/targetnopstandalone.py
+.. _`translator/jvm/`: ../../../../pypy/translator/jvm
+.. _`translator/stackless/`: ../../../../pypy/translator/stackless
+.. _`translator/tool/`: ../../../../pypy/translator/tool
+.. _`translator/js/`: http://codespeak.net/svn/pypy/branch/oo-jit/pypy/translator/js/

File pypy/doc/_ref.txt

-.. _`demo/`: ../../demo
-.. _`demo/pickle_coroutine.py`: ../../demo/pickle_coroutine.py
-.. _`lib-python/`: ../../lib-python
-.. _`lib-python/2.5.2/dis.py`: ../../lib-python/2.5.2/dis.py
-.. _`annotation/`:
-.. _`pypy/annotation`: ../../pypy/annotation
-.. _`pypy/annotation/annrpython.py`: ../../pypy/annotation/annrpython.py
-.. _`annotation/binaryop.py`: ../../pypy/annotation/binaryop.py
-.. _`pypy/annotation/builtin.py`: ../../pypy/annotation/builtin.py
-.. _`pypy/annotation/model.py`: ../../pypy/annotation/model.py
-.. _`bin/`: ../../pypy/bin
-.. _`config/`: ../../pypy/config
-.. _`pypy/config/pypyoption.py`: ../../pypy/config/pypyoption.py
-.. _`doc/`: ../../pypy/doc
-.. _`doc/config/`: ../../pypy/doc/config
-.. _`doc/discussion/`: ../../pypy/doc/discussion
-.. _`interpreter/`:
-.. _`pypy/interpreter`: ../../pypy/interpreter
-.. _`pypy/interpreter/argument.py`: ../../pypy/interpreter/argument.py
-.. _`interpreter/astcompiler/`:
-.. _`pypy/interpreter/astcompiler`: ../../pypy/interpreter/astcompiler
-.. _`pypy/interpreter/executioncontext.py`: ../../pypy/interpreter/executioncontext.py
-.. _`pypy/interpreter/function.py`: ../../pypy/interpreter/function.py
-.. _`interpreter/gateway.py`:
-.. _`pypy/interpreter/gateway.py`: ../../pypy/interpreter/gateway.py
-.. _`pypy/interpreter/generator.py`: ../../pypy/interpreter/generator.py
-.. _`pypy/interpreter/mixedmodule.py`: ../../pypy/interpreter/mixedmodule.py
-.. _`pypy/interpreter/module.py`: ../../pypy/interpreter/module.py
-.. _`pypy/interpreter/nestedscope.py`: ../../pypy/interpreter/nestedscope.py
-.. _`pypy/interpreter/pyopcode.py`: ../../pypy/interpreter/pyopcode.py
-.. _`interpreter/pyparser/`:
-.. _`pypy/interpreter/pyparser`: ../../pypy/interpreter/pyparser
-.. _`pypy/interpreter/pyparser/pytokenizer.py`: ../../pypy/interpreter/pyparser/pytokenizer.py
-.. _`pypy/interpreter/pyparser/parser.py`: ../../pypy/interpreter/pyparser/parser.py
-.. _`pypy/interpreter/pyparser/pyparse.py`: ../../pypy/interpreter/pyparser/pyparse.py
-.. _`pypy/interpreter/pyparser/future.py`: ../../pypy/interpreter/pyparser/future.py
-.. _`pypy/interpreter/pyparser/metaparser.py`: ../../pypy/interpreter/pyparser/metaparser.py
-.. _`pypy/interpreter/astcompiler/astbuilder.py`: ../../pypy/interpreter/astcompiler/astbuilder.py
-.. _`pypy/interpreter/astcompiler/optimize.py`: ../../pypy/interpreter/astcompiler/optimize.py
-.. _`pypy/interpreter/astcompiler/codegen.py`: ../../pypy/interpreter/astcompiler/codegen.py
-.. _`pypy/interpreter/astcompiler/tools/asdl_py.py`: ../../pypy/interpreter/astcompiler/tools/asdl_py.py
-.. _`pypy/interpreter/astcompiler/tools/Python.asdl`: ../../pypy/interpreter/astcompiler/tools/Python.asdl
-.. _`pypy/interpreter/astcompiler/assemble.py`: ../../pypy/interpreter/astcompiler/assemble.py
-.. _`pypy/interpreter/astcompiler/symtable.py`: ../../pypy/interpreter/astcompiler/symtable.py
-.. _`pypy/interpreter/astcompiler/asthelpers.py`: ../../pypy/interpreter/astcompiler/asthelpers.py
-.. _`pypy/interpreter/astcompiler/ast.py`: ../../pypy/interpreter/astcompiler/ast.py
-.. _`pypy/interpreter/typedef.py`: ../../pypy/interpreter/typedef.py
-.. _`lib/`:
-.. _`lib_pypy/`: ../../lib_pypy
-.. _`lib/distributed/`: ../../lib_pypy/distributed
-.. _`lib_pypy/stackless.py`: ../../lib_pypy/stackless.py
-.. _`lib_pypy/pypy_test/`: ../../lib_pypy/pypy_test
-.. _`module/`:
-.. _`pypy/module`:
-.. _`pypy/module/`: ../../pypy/module
-.. _`pypy/module/__builtin__/__init__.py`: ../../pypy/module/__builtin__/__init__.py
-.. _`pypy/module/_stackless/test/test_clonable.py`: ../../pypy/module/_stackless/test/test_clonable.py
-.. _`pypy/module/_stackless/test/test_composable_coroutine.py`: ../../pypy/module/_stackless/test/test_composable_coroutine.py
-.. _`objspace/`:
-.. _`pypy/objspace`: ../../pypy/objspace
-.. _`objspace/dump.py`: ../../pypy/objspace/dump.py
-.. _`objspace/flow/`: ../../pypy/objspace/flow
-.. _`objspace/std/`:
-.. _`pypy/objspace/std`: ../../pypy/objspace/std
-.. _`objspace/taint.py`: ../../pypy/objspace/taint.py
-.. _`objspace/thunk.py`:
-.. _`pypy/objspace/thunk.py`: ../../pypy/objspace/thunk.py
-.. _`objspace/trace.py`:
-.. _`pypy/objspace/trace.py`: ../../pypy/objspace/trace.py
-.. _`pypy/rlib`:
-.. _`rlib/`: ../../pypy/rlib
-.. _`pypy/rlib/rarithmetic.py`: ../../pypy/rlib/rarithmetic.py
-.. _`pypy/rlib/test`: ../../pypy/rlib/test
-.. _`pypy/rpython`:
-.. _`pypy/rpython/`:
-.. _`rpython/`: ../../pypy/rpython
-.. _`rpython/lltypesystem/`: ../../pypy/rpython/lltypesystem
-.. _`pypy/rpython/lltypesystem/lltype.py`:
-.. _`rpython/lltypesystem/lltype.py`: ../../pypy/rpython/lltypesystem/lltype.py
-.. _`rpython/memory/`: ../../pypy/rpython/memory
-.. _`rpython/memory/gc/generation.py`: ../../pypy/rpython/memory/gc/generation.py
-.. _`rpython/memory/gc/hybrid.py`: ../../pypy/rpython/memory/gc/hybrid.py
-.. _`rpython/memory/gc/markcompact.py`: ../../pypy/rpython/memory/gc/markcompact.py
-.. _`rpython/memory/gc/marksweep.py`: ../../pypy/rpython/memory/gc/marksweep.py
-.. _`rpython/memory/gc/semispace.py`: ../../pypy/rpython/memory/gc/semispace.py
-.. _`rpython/ootypesystem/`: ../../pypy/rpython/ootypesystem
-.. _`rpython/ootypesystem/ootype.py`: ../../pypy/rpython/ootypesystem/ootype.py
-.. _`rpython/rint.py`: ../../pypy/rpython/rint.py
-.. _`rpython/rlist.py`: ../../pypy/rpython/rlist.py
-.. _`rpython/rmodel.py`: ../../pypy/rpython/rmodel.py
-.. _`pypy/rpython/rtyper.py`: ../../pypy/rpython/rtyper.py
-.. _`pypy/rpython/test/test_llinterp.py`: ../../pypy/rpython/test/test_llinterp.py
-.. _`pypy/test_all.py`: ../../pypy/test_all.py
-.. _`tool/`: ../../pypy/tool
-.. _`tool/algo/`: ../../pypy/tool/algo
-.. _`tool/pytest/`: ../../pypy/tool/pytest
-.. _`pypy/translator`:
-.. _`translator/`: ../../pypy/translator
-.. _`translator/backendopt/`: ../../pypy/translator/backendopt
-.. _`translator/c/`: ../../pypy/translator/c
-.. _`translator/cli/`: ../../pypy/translator/cli
-.. _`translator/goal/`: ../../pypy/translator/goal
-.. _`pypy/translator/goal/targetnopstandalone.py`: ../../pypy/translator/goal/targetnopstandalone.py
-.. _`translator/jvm/`: ../../pypy/translator/jvm
-.. _`translator/stackless/`: ../../pypy/translator/stackless
-.. _`translator/tool/`: ../../pypy/translator/tool
-.. _`translator/js/`: http://codespeak.net/svn/pypy/branch/oo-jit/pypy/translator/js/

File pypy/doc/architecture.rst

+==================================================
+Goals and Architecture Overview 
+==================================================
+
+.. contents::
+
+
+This document gives an overview of the goals and architecture of PyPy.
+See `getting started`_ for a practical introduction and starting points. 
+
+Mission statement 
+====================
+
+We aim to provide:
+
+ * a common translation and support framework for producing
+   implementations of dynamic languages, emphasizing a clean
+   separation between language specification and implementation
+   aspects.
+
+ * a compliant, flexible and fast implementation of the Python_ Language 
+   using the above framework to enable new advanced features without having
+   to encode low level details into it.
+
+By separating concerns in this way, we intend for our implementation
+of Python - and other dynamic languages - to become robust against almost 
+all implementation decisions, including target platform, memory and 
+threading models, optimizations applied, up to to the point of being able to
+automatically *generate* Just-in-Time compilers for dynamic languages.
+
+Conversely, our implementation techniques, including the JIT compiler 
+generator, should become robust against changes in the languages 
+implemented. 
+
+
+High Level Goals
+=============================
+
+PyPy - the Translation Framework 
+-----------------------------------------------
+
+Traditionally, language interpreters are written in a target platform language
+like C/Posix, Java or C#.  Each such implementation fundamentally provides 
+a mapping from application source code to the target environment.  One of 
+the goals of the "all-encompassing" environments, like the .NET framework
+and to some extent the Java virtual machine, is to provide standardized
+and higher level functionalities in order to support language implementers
+for writing language implementations. 
+
+PyPy is experimenting with a more ambitious approach.  We are using a
+subset of the high-level language Python, called RPython_, in which we
+write languages as simple interpreters with few references to and
+dependencies on lower level details.  Our translation framework then
+produces a concrete virtual machine for the platform of our choice by
+inserting appropriate lower level aspects.  The result can be customized
+by selecting other feature and platform configurations.
+
+Our goal is to provide a possible solution to the problem of language
+implementers: having to write ``l * o * p`` interpreters for ``l``
+dynamic languages and ``p`` platforms with ``o`` crucial design
+decisions.  PyPy aims at having any one of these parameters changeable
+independently from each other:
+
+* ``l``: the language that we analyze can be evolved or entirely replaced;
+
+* ``o``: we can tweak and optimize the translation process to produce 
+  platform specific code based on different models and trade-offs;
+
+* ``p``: we can write new translator back-ends to target different
+  physical and virtual platforms.
+
+By contrast, a standardized target environment - say .NET -
+enforces ``p=1`` as far as it's concerned.  This helps making ``o`` a
+bit smaller by providing a higher-level base to build upon.  Still,
+we believe that enforcing the use of one common environment 
+is not necessary.  PyPy's goal is to give weight to this claim - at least 
+as far as language implementation is concerned - showing an approach
+to the ``l * o * p`` problem that does not rely on standardization.
+
+The most ambitious part of this goal is to `generate Just-In-Time
+Compilers`_ in a language-independent way, instead of only translating
+the source interpreter into an interpreter for the target platform.
+This is an area of language implementation that is commonly considered
+very challenging because of the involved complexity.
+
+
+PyPy - the Python Interpreter 
+--------------------------------------------
+
+Our main motivation for developing the translation framework is to
+provide a full featured, customizable, fast_ and `very compliant`_ Python
+implementation, working on and interacting with a large variety of
+platforms and allowing the quick introduction of new advanced language
+features.
+
+This Python implementation is written in RPython as a relatively simple
+interpreter, in some respects easier to understand than CPython, the C
+reference implementation of Python.  We are using its high level and
+flexibility to quickly experiment with features or implementation
+techniques in ways that would, in a traditional approach, require
+pervasive changes to the source code.  For example, PyPy's Python
+interpreter can optionally provide lazily computed objects - a small
+extension that would require global changes in CPython.  Another example
+is the garbage collection technique: changing CPython to use a garbage
+collector not based on reference counting would be a major undertaking,
+whereas in PyPy it is an issue localized in the translation framework,
+and fully orthogonal to the interpreter source code.
+
+
+PyPy Architecture 
+===========================
+
+As you would expect from a project implemented using ideas from the world
+of `Extreme Programming`_, the architecture of PyPy has evolved over time
+and continues to evolve.  Nevertheless, the high level architecture is 
+stable. As described above, there are two rather independent basic
+subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
+
+.. _`translation framework`:
+
+The Translation Framework
+-------------------------
+
+The job of the translation tool chain is to translate RPython_ programs
+into an efficient version of that program for one of various target
+platforms, generally one that is considerably lower-level than Python.
+
+The approach we have taken is to reduce the level of abstraction of the
+source RPython program in several steps, from the high level down to the
+level of the target platform, whatever that may be.  Currently we
+support two broad flavours of target platforms: the ones that assume a
+C-like memory model with structures and pointers, and the ones that
+assume an object-oriented model with classes, instances and methods (as,
+for example, the Java and .NET virtual machines do).
+
+The translation tool chain never sees the RPython source code or syntax
+trees, but rather starts with the *code objects* that define the
+behaviour of the function objects one gives it as input.  It can be
+considered as "freezing" a pre-imported RPython program into an
+executable form suitable for the target platform.
+
+The steps of the translation process can be summarized as follows:
+
+* The code object of each source functions is converted to a `control
+  flow graph` by the `Flow Object Space`_.
+
+* The control flow graphs are processed by the Annotator_, which
+  performs whole-program type inference to annotate each variable of
+  the control flow graph with the types it may take at run-time.
+
+* The information provided by the annotator is used by the RTyper_ to
+  convert the high level operations of the control flow graphs into
+  operations closer to the abstraction level of the target platform.
+
+* Optionally, `various transformations`_ can then be applied which, for
+  example, perform optimizations such as inlining, add capabilities
+  such as stackless_-style concurrency, or insert code for the
+  `garbage collector`_.
+
+* Then, the graphs are converted to source code for the target platform
+  and compiled into an executable.
+
+This process is described in much more detail in the `document about
+the translation process`_ and in the paper `Compiling dynamic language
+implementations`_.
+
+.. _`control flow graph`: translation.html#the-flow-model
+.. _`Flow Object Space`: objspace.html#the-flow-object-space
+.. _Annotator: translation.html#the-annotation-pass
+.. _RTyper: rtyper.html#overview
+.. _`various transformations`: translation.html#the-optional-transformations
+.. _`document about the translation process`: translation.html
+.. _`garbage collector`: garbage_collection.html
+
+
+.. _`standard interpreter`: 
+.. _`python interpreter`: 
+
+The Python Interpreter
+-------------------------------------
+
+PyPy's *Python Interpreter* is written in RPython and implements the
+full Python language.  This interpreter very closely emulates the
+behavior of CPython.  It contains the following key components:
+
+- a bytecode compiler responsible for producing Python code objects 
+  from the source code of a user application;
+
+- a `bytecode evaluator`_ responsible for interpreting 
+  Python code objects;
+
+- a `standard object space`_, responsible for creating and manipulating
+  the Python objects seen by the application.
+
+The *bytecode compiler* is the preprocessing phase that produces a
+compact bytecode format via a chain of flexible passes (tokenizer,
+lexer, parser, abstract syntax tree builder, bytecode generator).  The
+*bytecode evaluator* interprets this bytecode.  It does most of its work
+by delegating all actual manipulations of user objects to the *object
+space*.  The latter can be thought of as the library of built-in types.
+It defines the implementation of the user objects, like integers and
+lists, as well as the operations between them, like addition or
+truth-value-testing.
+
+This division between bytecode evaluator and object space is very
+important, as it gives a lot of flexibility.  One can plug in 
+different `object spaces`_ to get different or enriched behaviours 
+of the Python objects.  Additionally, a special more abstract object
+space, the `flow object space`_, allows us to reuse the bytecode
+evaluator for our translation framework.
+
+.. _`bytecode evaluator`: interpreter.html
+.. _`standard object space`: objspace.html#the-standard-object-space
+.. _`object spaces`: objspace.html
+.. _`flow object space`: objspace.html#the-flow-object-space
+
+.. _`the translation framework`:
+
+
+Further reading
+===============
+
+All of PyPy's documentation can be reached from the `documentation
+index`_.  Of particular interest after reading this document might be:
+
+ * `getting-started`_: a hands-on guide to getting involved with the
+   PyPy source code.
+
+ * `PyPy's approach to virtual machine construction`_: a paper
+   presented to the Dynamic Languages Symposium attached to OOPSLA
+   2006.
+
+ * `The translation document`_: a detailed description of our
+   translation process.
+
+ * All our `Technical reports`_, including `Compiling dynamic language
+   implementations`_.
+
+ * `JIT Generation in PyPy`_, describing how we produce a Just-in-time
+   Compiler from an interpreter.
+
+.. _`documentation index`: docindex.html
+.. _`getting-started`: getting-started.html
+.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
+.. _`the translation document`: translation.html
+.. _`Compiling dynamic language implementations`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`Technical reports`: index-report.html
+
+.. _`getting started`: getting-started.html
+.. _`Extreme Programming`: http://www.extremeprogramming.org/
+
+.. _fast: faq.html#how-fast-is-pypy
+.. _`very compliant`: cpython_differences.html
+
+.. _`RPython`: coding-guide.html#rpython
+
+.. _Python: http://docs.python.org/ref
+.. _Psyco: http://psyco.sourceforge.net
+.. _stackless: stackless.html
+.. _`generate Just-In-Time Compilers`: jit/index.html
+.. _`JIT Generation in PyPy`: jit/index.html
+
+.. include:: _ref.rst
+

File pypy/doc/architecture.txt

-==================================================
-PyPy - Goals and Architecture Overview 
-==================================================
-
-.. contents::
-.. sectnum::
-
-This document gives an overview of the goals and architecture of PyPy.
-See `getting started`_ for a practical introduction and starting points. 
-
-Mission statement 
-====================
-
-We aim to provide:
-
- * a common translation and support framework for producing
-   implementations of dynamic languages, emphasizing a clean
-   separation between language specification and implementation
-   aspects.
-
- * a compliant, flexible and fast implementation of the Python_ Language 
-   using the above framework to enable new advanced features without having
-   to encode low level details into it.
-
-By separating concerns in this way, we intend for our implementation
-of Python - and other dynamic languages - to become robust against almost 
-all implementation decisions, including target platform, memory and 
-threading models, optimizations applied, up to to the point of being able to
-automatically *generate* Just-in-Time compilers for dynamic languages.
-
-Conversely, our implementation techniques, including the JIT compiler 
-generator, should become robust against changes in the languages 
-implemented. 
-
-
-High Level Goals
-=============================
-
-PyPy - the Translation Framework 
------------------------------------------------
-
-Traditionally, language interpreters are written in a target platform language
-like C/Posix, Java or C#.  Each such implementation fundamentally provides 
-a mapping from application source code to the target environment.  One of 
-the goals of the "all-encompassing" environments, like the .NET framework
-and to some extent the Java virtual machine, is to provide standardized
-and higher level functionalities in order to support language implementers
-for writing language implementations. 
-
-PyPy is experimenting with a more ambitious approach.  We are using a
-subset of the high-level language Python, called RPython_, in which we
-write languages as simple interpreters with few references to and
-dependencies on lower level details.  Our translation framework then
-produces a concrete virtual machine for the platform of our choice by
-inserting appropriate lower level aspects.  The result can be customized
-by selecting other feature and platform configurations.
-
-Our goal is to provide a possible solution to the problem of language
-implementers: having to write ``l * o * p`` interpreters for ``l``
-dynamic languages and ``p`` platforms with ``o`` crucial design
-decisions.  PyPy aims at having any one of these parameters changeable
-independently from each other:
-
-* ``l``: the language that we analyze can be evolved or entirely replaced;
-
-* ``o``: we can tweak and optimize the translation process to produce 
-  platform specific code based on different models and trade-offs;
-
-* ``p``: we can write new translator back-ends to target different
-  physical and virtual platforms.
-
-By contrast, a standardized target environment - say .NET -
-enforces ``p=1`` as far as it's concerned.  This helps making ``o`` a
-bit smaller by providing a higher-level base to build upon.  Still,
-we believe that enforcing the use of one common environment 
-is not necessary.  PyPy's goal is to give weight to this claim - at least 
-as far as language implementation is concerned - showing an approach
-to the ``l * o * p`` problem that does not rely on standardization.
-
-The most ambitious part of this goal is to `generate Just-In-Time
-Compilers`_ in a language-independent way, instead of only translating
-the source interpreter into an interpreter for the target platform.
-This is an area of language implementation that is commonly considered
-very challenging because of the involved complexity.
-
-
-PyPy - the Python Interpreter 
---------------------------------------------
-
-Our main motivation for developing the translation framework is to
-provide a full featured, customizable, fast_ and `very compliant`_ Python
-implementation, working on and interacting with a large variety of
-platforms and allowing the quick introduction of new advanced language
-features.
-
-This Python implementation is written in RPython as a relatively simple
-interpreter, in some respects easier to understand than CPython, the C
-reference implementation of Python.  We are using its high level and
-flexibility to quickly experiment with features or implementation
-techniques in ways that would, in a traditional approach, require
-pervasive changes to the source code.  For example, PyPy's Python
-interpreter can optionally provide lazily computed objects - a small
-extension that would require global changes in CPython.  Another example
-is the garbage collection technique: changing CPython to use a garbage
-collector not based on reference counting would be a major undertaking,
-whereas in PyPy it is an issue localized in the translation framework,
-and fully orthogonal to the interpreter source code.
-
-
-PyPy Architecture 
-===========================
-
-As you would expect from a project implemented using ideas from the world
-of `Extreme Programming`_, the architecture of PyPy has evolved over time
-and continues to evolve.  Nevertheless, the high level architecture is 
-stable. As described above, there are two rather independent basic
-subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
-
-.. _`translation framework`:
-
-The Translation Framework
--------------------------
-
-The job of the translation tool chain is to translate RPython_ programs
-into an efficient version of that program for one of various target
-platforms, generally one that is considerably lower-level than Python.
-
-The approach we have taken is to reduce the level of abstraction of the
-source RPython program in several steps, from the high level down to the
-level of the target platform, whatever that may be.  Currently we
-support two broad flavours of target platforms: the ones that assume a
-C-like memory model with structures and pointers, and the ones that
-assume an object-oriented model with classes, instances and methods (as,
-for example, the Java and .NET virtual machines do).
-
-The translation tool chain never sees the RPython source code or syntax
-trees, but rather starts with the *code objects* that define the
-behaviour of the function objects one gives it as input.  It can be
-considered as "freezing" a pre-imported RPython program into an
-executable form suitable for the target platform.
-
-The steps of the translation process can be summarized as follows:
-
-* The code object of each source functions is converted to a `control
-  flow graph` by the `Flow Object Space`_.
-
-* The control flow graphs are processed by the Annotator_, which
-  performs whole-program type inference to annotate each variable of
-  the control flow graph with the types it may take at run-time.
-
-* The information provided by the annotator is used by the RTyper_ to
-  convert the high level operations of the control flow graphs into
-  operations closer to the abstraction level of the target platform.
-
-* Optionally, `various transformations`_ can then be applied which, for
-  example, perform optimizations such as inlining, add capabilities
-  such as stackless_-style concurrency, or insert code for the
-  `garbage collector`_.
-
-* Then, the graphs are converted to source code for the target platform
-  and compiled into an executable.
-
-This process is described in much more detail in the `document about
-the translation process`_ and in the paper `Compiling dynamic language
-implementations`_.
-
-.. _`control flow graph`: translation.html#the-flow-model
-.. _`Flow Object Space`: objspace.html#the-flow-object-space
-.. _Annotator: translation.html#the-annotation-pass
-.. _RTyper: rtyper.html#overview
-.. _`various transformations`: translation.html#the-optional-transformations
-.. _`document about the translation process`: translation.html
-.. _`garbage collector`: garbage_collection.html
-
-
-.. _`standard interpreter`: 
-.. _`python interpreter`: 
-
-The Python Interpreter
--------------------------------------
-
-PyPy's *Python Interpreter* is written in RPython and implements the
-full Python language.  This interpreter very closely emulates the
-behavior of CPython.  It contains the following key components:
-
-- a bytecode compiler responsible for producing Python code objects 
-  from the source code of a user application;
-
-- a `bytecode evaluator`_ responsible for interpreting 
-  Python code objects;
-
-- a `standard object space`_, responsible for creating and manipulating
-  the Python objects seen by the application.
-
-The *bytecode compiler* is the preprocessing phase that produces a
-compact bytecode format via a chain of flexible passes (tokenizer,
-lexer, parser, abstract syntax tree builder, bytecode generator).  The
-*bytecode evaluator* interprets this bytecode.  It does most of its work
-by delegating all actual manipulations of user objects to the *object
-space*.  The latter can be thought of as the library of built-in types.
-It defines the implementation of the user objects, like integers and
-lists, as well as the operations between them, like addition or
-truth-value-testing.
-
-This division between bytecode evaluator and object space is very
-important, as it gives a lot of flexibility.  One can plug in 
-different `object spaces`_ to get different or enriched behaviours 
-of the Python objects.  Additionally, a special more abstract object
-space, the `flow object space`_, allows us to reuse the bytecode
-evaluator for our translation framework.
-
-.. _`bytecode evaluator`: interpreter.html
-.. _`standard object space`: objspace.html#the-standard-object-space
-.. _`object spaces`: objspace.html
-.. _`flow object space`: objspace.html#the-flow-object-space
-
-.. _`the translation framework`:
-
-
-Further reading
-===============
-
-All of PyPy's documentation can be reached from the `documentation
-index`_.  Of particular interest after reading this document might be:
-
- * `getting-started`_: a hands-on guide to getting involved with the
-   PyPy source code.
-
- * `PyPy's approach to virtual machine construction`_: a paper
-   presented to the Dynamic Languages Symposium attached to OOPSLA
-   2006.
-
- * `The translation document`_: a detailed description of our
-   translation process.
-
- * All our `Technical reports`_, including `Compiling dynamic language
-   implementations`_.
-
- * `JIT Generation in PyPy`_, describing how we produce a Just-in-time
-   Compiler from an interpreter.
-
-.. _`documentation index`: docindex.html
-.. _`getting-started`: getting-started.html
-.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
-.. _`the translation document`: translation.html
-.. _`Compiling dynamic language implementations`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
-.. _`Technical reports`: index-report.html
-
-.. _`getting started`: getting-started.html
-.. _`Extreme Programming`: http://www.extremeprogramming.org/
-
-.. _fast: faq.html#how-fast-is-pypy
-.. _`very compliant`: cpython_differences.html
-
-.. _`RPython`: coding-guide.html#rpython
-
-.. _Python: http://docs.python.org/ref
-.. _Psyco: http://psyco.sourceforge.net
-.. _stackless: stackless.html
-.. _`generate Just-In-Time Compilers`: jit/index.html
-.. _`JIT Generation in PyPy`: jit/index.html
-
-.. include:: _ref.txt
-

File pypy/doc/buildtool.rst

+============
+PyPyBuilder
+============
+
+.. include:: crufty.rst
+
+What is this?
+=============
+
+PyPyBuilder is an application that allows people to build PyPy instances on
+demand. If you have a nice idle machine connected to the Internet, and don't
+mind us 'borrowing' it every once in a while, you can start up the client
+script (in bin/client) and have the server send compile jobs to your machine.
+If someone requests a build of PyPy that is not already available on the PyPy
+website, and your machine is capable of making such a build, the server may ask
+your machine to create it. If enough people participate, with diverse enough
+machines, a 'build farm' is created.
+
+Quick usage instructions
+========================
+
+For the impatient, that just want to get started, some quick instructions.
+
+First you'll need to have a checkout of the 'buildtool' package, that can
+be found here::
+
+  https://codespeak.net/svn/pypy/build/buildtool
+
+To start a compilation, run (from the buildtool root directory)::
+
+  $ ./bin/startcompile.py [options] <email address>
+
+where the options can be found by using --help, and the email address will be
+used to send mail to once the compilation is finished.
+
+To start a build server, to participate in the build farm, do::
+
+  $ ./bin/buildserver.py
+
+That's it for the compilation script and build server, if you have your own
+project and want to set up your own meta server, you'll have to be a bit more
+patient and read the details below...
+
+Components
+==========
+
+The application consists of 3 main components: a meta server component, a
+client component that handles compilations (let's call this a 'build server')
+and a small client component to start compile jobs (which we'll call
+'requesting clients' for now).
+
+The server waits for build server to register, and for compile job
+requests. When participating clients register, they pass the server information
+about what compilations the system can handle (system info), and a set of
+options to use for compilation (compile info).
+
+When now a requesting client requests a compilation job, the server checks
+whether a suitable binary is already available based on the system and compile
+info, and if so returns that. If there isn't one, the server walks through a
+list of connected participating clients to see if one of them can handle the
+job, and if so dispatches the compilation. If there's no participating client
+to handle the job, it gets queued until there is.