[pypy-svn] pypy default: merge the documentation-cleanup branch
cfbolz
commits-noreply at bitbucket.org
Sat Apr 30 16:01:35 CEST 2011
Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch:
Changeset: r43809:d52d395aac40
Date: 2011-04-30 15:55 +0200
http://bitbucket.org/pypy/pypy/changeset/d52d395aac40/
Log: merge the documentation-cleanup branch
diff --git a/pypy/doc/config/objspace.std.optimized_int_add.rst b/pypy/doc/config/objspace.std.optimized_int_add.txt
copy from pypy/doc/config/objspace.std.optimized_int_add.rst
copy to pypy/doc/config/objspace.std.optimized_int_add.txt
diff --git a/pypy/doc/throwaway.txt b/pypy/doc/throwaway.txt
new file mode 100644
--- /dev/null
+++ b/pypy/doc/throwaway.txt
@@ -0,0 +1,3 @@
+.. warning::
+
+ This documentation should be removed (as discussed during the Gothenburg sprint in 2011)
diff --git a/pypy/doc/config/objspace.std.withcelldict.rst b/pypy/doc/config/objspace.std.withcelldict.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withcelldict.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Enable cell-dicts. This optimization is not helpful without the JIT. In the
-presence of the JIT, it greatly helps looking up globals.
diff --git a/pypy/doc/config/objspace.std.withprebuiltint.rst b/pypy/doc/config/objspace.std.withprebuiltint.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withprebuiltint.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-This option enables the caching of small integer objects (similar to what
-CPython does). The range of which integers are cached can be influenced with
-the :config:`objspace.std.prebuiltintfrom` and
-:config:`objspace.std.prebuiltintto` options.
-
diff --git a/pypy/doc/config/objspace.honor__builtins__.rst b/pypy/doc/config/objspace.honor__builtins__.txt
copy from pypy/doc/config/objspace.honor__builtins__.rst
copy to pypy/doc/config/objspace.honor__builtins__.txt
diff --git a/pypy/doc/discussions.rst b/pypy/doc/discussions.rst
--- a/pypy/doc/discussions.rst
+++ b/pypy/doc/discussions.rst
@@ -7,35 +7,11 @@
.. toctree::
+
+ discussion/finalizer-order.rst
+ discussion/howtoimplementpickling.rst
+ discussion/improve-rpython.rst
+ discussion/outline-external-ootype.rst
+ discussion/VM-integration.rst
- discussion/GC-performance.rst
- discussion/VM-integration.rst
- discussion/chained_getattr.rst
- discussion/cli-optimizations.rst
- discussion/cmd-prompt-translation.rst
- discussion/compiled-swamp.rst
- discussion/ctypes_modules.rst
- discussion/ctypes_todo.rst
- discussion/distribution.rst
- discussion/distribution-implementation.rst
- discussion/distribution-newattempt.rst
- discussion/distribution-roadmap.rst
- discussion/emptying-the-malloc-zoo.rst
- discussion/finalizer-order.rst
- discussion/gc.rst
- discussion/howtoimplementpickling.rst
- discussion/improve-rpython.rst
- discussion/outline-external-ootype.rst
- discussion/oz-thread-api.rst
- discussion/paper-wishlist.rst
- discussion/parsing-ideas.rst
- discussion/pypy_metaclasses_in_cl.rst
- discussion/removing-stable-compiler.rst
- discussion/security-ideas.rst
- discussion/somepbc-refactoring-plan.rst
- discussion/summer-of-pypy-pytest.rst
- discussion/testing-zope.rst
- discussion/thoughts_string_interning.rst
- discussion/translation-swamp.rst
- discussion/use_case_of_logic.rst
diff --git a/pypy/doc/discussion/cmd-prompt-translation.rst b/pypy/doc/discussion/cmd-prompt-translation.rst
deleted file mode 100644
--- a/pypy/doc/discussion/cmd-prompt-translation.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-
-t = Translation(entry_point[,<options>])
-t.annotate([<options>])
-t.rtype([<options>])
-t.backendopt[_<backend>]([<options>])
-t.source[_<backend>]([<options>])
-f = t.compile[_<backend>]([<options>])
-
-and t.view(), t.viewcg()
-
-<backend> = c|llvm (for now)
-you can skip steps
-
-<options> = argtypes (for annotation) plus
- keyword args: gc=...|policy=<annpolicy> etc
-
-
-
diff --git a/pypy/doc/config/objspace.std.optimized_comparison_op.rst b/pypy/doc/config/objspace.std.optimized_comparison_op.txt
copy from pypy/doc/config/objspace.std.optimized_comparison_op.rst
copy to pypy/doc/config/objspace.std.optimized_comparison_op.txt
diff --git a/pypy/doc/video-index.rst b/pypy/doc/video-index.rst
--- a/pypy/doc/video-index.rst
+++ b/pypy/doc/video-index.rst
@@ -20,14 +20,14 @@
such as `mplayer`_, `xine`_, `vlc`_ or the windows media player.
.. _`mplayer`: http://www.mplayerhq.hu/design7/dload.html
-.. _`xine`: http://xinehq.de/index.php/releases
+.. _`xine`: http://www.xine-project.org
.. _`vlc`: http://www.videolan.org/vlc/
You can find the necessary codecs in the ffdshow-library:
-http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php
+http://sourceforge.net/projects/ffdshow/
or use the original divx codec (for Windows):
-http://www.divx.com/divx/windows/download/index.php
+http://www.divx.com/software/divx-plus
Copyrights and Licensing
@@ -162,7 +162,7 @@
PAL, 48 min, divx AVI
Holger Krekel and Armin Rigo talk about the basic implementation,
-implementation level aspects and the translation toolchain. This
+implementation level aspects and the RPython translation toolchain. This
talk also gives an insight into how a developer works with these tools on
a daily basis, and pays special attention to flow graphs.
@@ -184,7 +184,7 @@
PAL, 44 min, divx AVI
-Michael Hudson gives an in-depth, very technical introduction to a PyPy sprint. The film provides a detailed and hands-on overview about the architecture of PyPy, especially the translation toolchain.
+Michael Hudson gives an in-depth, very technical introduction to a PyPy sprint. The film provides a detailed and hands-on overview about the architecture of PyPy, especially the RPython translation toolchain.
Scripting .NET with IronPython by Jim Hugunin
@@ -292,5 +292,5 @@
PAL 72 min, DivX AVI
-Core developers Armin Rigo, Samuele Pedroni and Carl Friedrich Bolz are giving an overview of the PyPy architecture, the standard interpreter, the translation toolchain and the just-in-time compiler.
+Core developers Armin Rigo, Samuele Pedroni and Carl Friedrich Bolz are giving an overview of the PyPy architecture, the standard interpreter, the RPython translation toolchain and the just-in-time compiler.
diff --git a/pypy/doc/config/index.rst b/pypy/doc/config/index.rst
--- a/pypy/doc/config/index.rst
+++ b/pypy/doc/config/index.rst
@@ -50,3 +50,12 @@
.. _`overview`: commandline.html
.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html
.. _`What PyPy can do for your objects`: ../objspace-proxies.html
+
+
+.. toctree::
+ :maxdepth: 2
+
+ commandline
+ translation
+ objspace
+ opt
diff --git a/pypy/doc/config/translation.list_comprehension_operations.rst b/pypy/doc/config/translation.list_comprehension_operations.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.list_comprehension_operations.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Experimental optimization for list comprehensions in RPython.
-
diff --git a/pypy/doc/config/objspace.soabi.rst b/pypy/doc/config/objspace.soabi.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.soabi.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-This option controls the tag included into extension module file names. The
-default is something like `pypy-14`, which means that `import foo` will look for
-a file named `foo.pypy-14.so` (or `foo.pypy-14.pyd` on Windows).
-
-This is an implementation of PEP3149_, with two differences:
-
- * the filename without tag `foo.so` is not considered.
- * the feature is also available on Windows.
-
-When set to the empty string (with `--soabi=`), the interpreter will only look
-for a file named `foo.so`, and will crash if this file was compiled for another
-Python interpreter.
-
-.. _PEP3149: http://www.python.org/dev/peps/pep-3149/
diff --git a/pypy/doc/config/objspace.usemodules._ast.rst b/pypy/doc/config/objspace.usemodules._ast.txt
copy from pypy/doc/config/objspace.usemodules._ast.rst
copy to pypy/doc/config/objspace.usemodules._ast.txt
diff --git a/pypy/doc/index-report.rst b/pypy/doc/index-report.rst
--- a/pypy/doc/index-report.rst
+++ b/pypy/doc/index-report.rst
@@ -1,4 +1,7 @@
-.. include:: crufty.rst
+.. warning::
+
+ Some of these reports are interesting for historical reasons only.
+
============================================
PyPy - Overview over the EU-reports
@@ -9,7 +12,7 @@
They also are very good documentation if you'd like to know in more
detail about motivation and implementation of the various parts
and aspects of PyPy. Feel free to send questions or comments
-to `pypy-dev`_, the development list.
+to `pypy-dev`_, the development list.
Reports of 2007
===============
@@ -93,8 +96,8 @@
-.. _`py-lib`: http://codespeak.net/py/current/doc/
-.. _`py.test`: http://codespeak.net/py/current/doc/test.html
+.. _`py-lib`: http://pylib.org/
+.. _`py.test`: http://pytest.org/
.. _codespeak: http://codespeak.net/
.. _`pypy-dev`: http://codespeak.net/mailman/listinfo/pypy-dev
@@ -137,35 +140,35 @@
`D14.1 Report about Milestone/Phase 1`_ describes what happened in the PyPy
project during the first year of EU funding (December 2004 - December 2005)
-.. _`PyPy EU Final Activity Report`: http://codespeak.net/pypy/extradoc/eu-report/PYPY-EU-Final-Activity-Report.pdf
-.. _`D01.2-4 Project Organization`: http://codespeak.net/pypy/extradoc/eu-report/D01.2-4_Project_Organization-2007-03-28.pdf
-.. _`D02.1 Development Tools and Website`: http://codespeak.net/pypy/extradoc/eu-report/D02.1_Development_Tools_and_Website-2007-03-21.pdf
-.. _`D02.2 Release Scheme`: http://codespeak.net/svn/pypy/extradoc/eu-report/D02.2_Release_Scheme-2007-03-30.pdf
-.. _`D02.3 Testing Tool`: http://codespeak.net/pypy/extradoc/eu-report/D02.3_Testing_Framework-2007-03-23.pdf
-.. _`D03.1 Extension Compiler`: http://codespeak.net/pypy/extradoc/eu-report/D03.1_Extension_Compiler-2007-03-21.pdf
-.. _`D04.1 Partial Python Implementation`: http://codespeak.net/svn/pypy/extradoc/eu-report/D04.1_Partial_Python_Implementation_on_top_of_CPython.pdf
-.. _`D04.2 Complete Python Implementation`: http://codespeak.net/svn/pypy/extradoc/eu-report/D04.2_Complete_Python_Implementation_on_top_of_CPython.pdf
-.. _`D04.3 Parser and Bytecode Compiler`: http://codespeak.net/svn/pypy/extradoc/eu-report/D04.3_Report_about_the_parser_and_bytecode_compiler.pdf
-.. _`D04.4 PyPy as a Research Tool`: http://codespeak.net/svn/pypy/extradoc/eu-report/D04.4_Release_PyPy_as_a_research_tool.pdf
-.. _`D05.1 Compiling Dynamic Language Implementations`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
-.. _`D05.2 A Compiled Version of PyPy`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.2_A_compiled,_self-contained_version_of_PyPy.pdf
-.. _`D05.3 Implementation with Translation Aspects`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.3_Publish_on_implementation_with_translation_aspects.pdf
-.. _`D05.4 Encapsulating Low Level Aspects`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.4_Publish_on_encapsulating_low_level_language_aspects.pdf
-.. _`D06.1 Core Object Optimization Results`: http://codespeak.net/svn/pypy/extradoc/eu-report/D06.1_Core_Optimizations-2007-04-30.pdf
-.. _`D07.1 Massive Parallelism and Translation Aspects`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
-.. _`D08.2 JIT Compiler Architecture`: http://codespeak.net/pypy/extradoc/eu-report/D08.2_JIT_Compiler_Architecture-2007-05-01.pdf
-.. _`D08.1 JIT Compiler Release`: http://codespeak.net/pypy/extradoc/eu-report/D08.1_JIT_Compiler_Release-2007-04-30.pdf
-.. _`D09.1 Constraint Solving and Semantic Web`: http://codespeak.net/pypy/extradoc/eu-report/D09.1_Constraint_Solving_and_Semantic_Web-2007-05-11.pdf
-.. _`D10.1 Aspect-Oriented, Design-by-Contract Programming and RPython static checking`: http://codespeak.net/pypy/extradoc/eu-report/D10.1_Aspect_Oriented_Programming_in_PyPy-2007-03-22.pdf
-.. _`D11.1 PyPy for Embedded Devices`: http://codespeak.net/pypy/extradoc/eu-report/D11.1_PyPy_for_Embedded_Devices-2007-03-26.pdf
-.. _`D12.1 High-Level-Backends and Feature Prototypes`: http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-2007-03-22.pdf
-.. _`D13.1 Integration and Configuration`: http://codespeak.net/pypy/extradoc/eu-report/D13.1_Integration_and_Configuration-2007-03-30.pdf
-.. _`D14.1 Report about Milestone/Phase 1`: http://codespeak.net/svn/pypy/extradoc/eu-report/D14.1_Report_about_Milestone_Phase_1.pdf
-.. _`D14.2 Tutorials and Guide Through the PyPy Source Code`: http://codespeak.net/pypy/extradoc/eu-report/D14.2_Tutorials_and_Guide_Through_the_PyPy_Source_Code-2007-03-22.pdf
-.. _`D14.3 Report about Milestone/Phase 2`: http://codespeak.net/pypy/extradoc/eu-report/D14.3_Report_about_Milestone_Phase_2-final-2006-08-03.pdf
-.. _`D14.4 PyPy-1.0 Milestone report`: http://codespeak.net/pypy/extradoc/eu-report/D14.4_Report_About_Milestone_Phase_3-2007-05-01.pdf
-.. _`D14.5 Documentation of the development process`: http://codespeak.net/pypy/extradoc/eu-report/D14.5_Documentation_of_the_development_process-2007-03-30.pdf
+.. _`PyPy EU Final Activity Report`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/PYPY-EU-Final-Activity-Report.pdf
+.. _`D01.2-4 Project Organization`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D01.2-4_Project_Organization-2007-03-28.pdf
+.. _`D02.1 Development Tools and Website`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D02.1_Development_Tools_and_Website-2007-03-21.pdf
+.. _`D02.2 Release Scheme`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D02.2_Release_Scheme-2007-03-30.pdf
+.. _`D02.3 Testing Tool`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D02.3_Testing_Framework-2007-03-23.pdf
+.. _`D03.1 Extension Compiler`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D03.1_Extension_Compiler-2007-03-21.pdf
+.. _`D04.1 Partial Python Implementation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D04.1_Partial_Python_Implementation_on_top_of_CPython.pdf
+.. _`D04.2 Complete Python Implementation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D04.2_Complete_Python_Implementation_on_top_of_CPython.pdf
+.. _`D04.3 Parser and Bytecode Compiler`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D04.3_Report_about_the_parser_and_bytecode_compiler.pdf
+.. _`D04.4 PyPy as a Research Tool`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D04.4_Release_PyPy_as_a_research_tool.pdf
+.. _`D05.1 Compiling Dynamic Language Implementations`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`D05.2 A Compiled Version of PyPy`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.2_A_compiled,_self-contained_version_of_PyPy.pdf
+.. _`D05.3 Implementation with Translation Aspects`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.3_Publish_on_implementation_with_translation_aspects.pdf
+.. _`D05.4 Encapsulating Low Level Aspects`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.4_Publish_on_encapsulating_low_level_language_aspects.pdf
+.. _`D06.1 Core Object Optimization Results`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D06.1_Core_Optimizations-2007-04-30.pdf
+.. _`D07.1 Massive Parallelism and Translation Aspects`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
+.. _`D08.2 JIT Compiler Architecture`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D08.2_JIT_Compiler_Architecture-2007-05-01.pdf
+.. _`D08.1 JIT Compiler Release`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D08.1_JIT_Compiler_Release-2007-04-30.pdf
+.. _`D09.1 Constraint Solving and Semantic Web`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D09.1_Constraint_Solving_and_Semantic_Web-2007-05-11.pdf
+.. _`D10.1 Aspect-Oriented, Design-by-Contract Programming and RPython static checking`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D10.1_Aspect_Oriented_Programming_in_PyPy-2007-03-22.pdf
+.. _`D11.1 PyPy for Embedded Devices`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D11.1_PyPy_for_Embedded_Devices-2007-03-26.pdf
+.. _`D12.1 High-Level-Backends and Feature Prototypes`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-2007-03-22.pdf
+.. _`D13.1 Integration and Configuration`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D13.1_Integration_and_Configuration-2007-03-30.pdf
+.. _`D14.1 Report about Milestone/Phase 1`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D14.1_Report_about_Milestone_Phase_1.pdf
+.. _`D14.2 Tutorials and Guide Through the PyPy Source Code`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D14.2_Tutorials_and_Guide_Through_the_PyPy_Source_Code-2007-03-22.pdf
+.. _`D14.3 Report about Milestone/Phase 2`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D14.3_Report_about_Milestone_Phase_2-final-2006-08-03.pdf
+.. _`D14.4 PyPy-1.0 Milestone report`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D14.4_Report_About_Milestone_Phase_3-2007-05-01.pdf
+.. _`D14.5 Documentation of the development process`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D14.5_Documentation_of_the_development_process-2007-03-30.pdf
-.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
+.. _`PyPy's approach to virtual machine construction`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dls2006/pypy-vm-construction.pdf
diff --git a/pypy/doc/config/translation.ootype.mangle.rst b/pypy/doc/config/translation.ootype.mangle.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.ootype.mangle.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Mangle the names of user defined attributes of the classes, in order
-to ensure that every name is unique. Default is true, and it should
-not be turned off unless you know what you are doing.
diff --git a/pypy/doc/release-0.6.rst b/pypy/doc/release-0.6.rst
--- a/pypy/doc/release-0.6.rst
+++ b/pypy/doc/release-0.6.rst
@@ -9,11 +9,11 @@
What it is and where to start
-----------------------------
-Getting started: http://codespeak.net/pypy/index.cgi?doc/getting-started.html
+Getting started: getting-started.html
-PyPy Documentation: http://codespeak.net/pypy/index.cgi?doc
+PyPy Documentation: index.html
-PyPy Homepage: http://codespeak.net/pypy/
+PyPy Homepage: http://pypy.org
PyPy is a MIT-licensed reimplementation of Python written in
Python itself. The long term goals are an implementation that
@@ -89,9 +89,9 @@
from numerous people. Please feel free to give feedback and
raise questions.
- contact points: http://codespeak.net/pypy/index.cgi?contact
+ contact points: http://pypy.org/contact.html
- contributor list: http://codespeak.net/pypy/index.cgi?doc/contributor.html
+ contributor list: contributor.html
have fun,
diff --git a/pypy/doc/config/objspace.usemodules._warnings.rst b/pypy/doc/config/objspace.usemodules._warnings.txt
copy from pypy/doc/config/objspace.usemodules._warnings.rst
copy to pypy/doc/config/objspace.usemodules._warnings.txt
diff --git a/pypy/doc/config/objspace.usemodules._random.rst b/pypy/doc/config/objspace.usemodules._random.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._random.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_random' module. It is necessary to use the module "random" from the standard library.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules.pyexpat.rst b/pypy/doc/config/objspace.usemodules.pyexpat.txt
copy from pypy/doc/config/objspace.usemodules.pyexpat.rst
copy to pypy/doc/config/objspace.usemodules.pyexpat.txt
diff --git a/pypy/doc/config/objspace.std.withmapdict.rst b/pypy/doc/config/objspace.std.withmapdict.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withmapdict.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Enable the new version of "sharing dictionaries".
-
-See the section in `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#sharing-dicts
diff --git a/pypy/doc/config/translation.stackless.rst b/pypy/doc/config/translation.stackless.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.stackless.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Run the `stackless transform`_ on each generated graph, which enables the use
-of coroutines at RPython level and the "stackless" module when translating
-PyPy.
-
-.. _`stackless transform`: ../stackless.html
diff --git a/pypy/doc/config/translation.backendopt.none.rst b/pypy/doc/config/translation.backendopt.none.txt
copy from pypy/doc/config/translation.backendopt.none.rst
copy to pypy/doc/config/translation.backendopt.none.txt
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.txt
copy from pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.rst
copy to pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.txt
diff --git a/pypy/doc/discussion/use_case_of_logic.rst b/pypy/doc/discussion/use_case_of_logic.rst
deleted file mode 100644
--- a/pypy/doc/discussion/use_case_of_logic.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-Use cases for a combination of Logic and Object Oriented programming approach
--------------------------------------------------------------------------------
-
-Workflows
-=========
-
-Defining the next state by solving certain constraints. The more
-general term might be State machines.
-
-Business Logic
-==============
-
-We define Business Logic as expressing consistency (as an example) on
-a set of objects in a business application.
-
-For example checking the consistency of a calculation before
-committing the changes.
-
-The domain is quite rich in example of uses of Business Logic.
-
-Datamining
-===========
-
-An example is Genetic sequence matching.
-
-Databases
-=========
-
-Validity constraints for the data can be expressed as constraints.
-
-Constraints can be used to perform type inference when querying the
-database.
-
-Semantic web
-=============
-
-The use case is like the database case, except the ontology language
-it self is born out of Descriptive Logic
-
-
-User Interfaces
-===============
-
-We use rules to describe the layout and visibility constraints of
-elements that are to be displayed on screen. The rule can also help
-describing how an element is to be displayed depending on its state
-(for instance, out of bound values can be displayed in a different
-colour).
-
-Configuration
-==============
-
-User configuration can use information inferred from : the current
-user, current platforms , version requirements, ...
-
-The validity of the configuration can be checked with the constraints.
-
-
-Scheduling and planning
-========================
-
-Timetables, process scheduling, task scheduling.
-
-Use rules to determine when to execute tasks (only start batch, if load
-is low, and previous batch is finished.
-
-Load sharing.
-
-Route optimization. Planning the routes of a technician based on tools
-needed and such
-
-An example is scheduling a conference like Europython see:
-
-http://lists.logilab.org/pipermail/python-logic/2005-May/000107.html
-
diff --git a/pypy/doc/config/objspace.std.withprebuiltchar.rst b/pypy/doc/config/objspace.std.withprebuiltchar.rst
deleted file mode 100644
diff --git a/pypy/doc/config/translation.backend.rst b/pypy/doc/config/translation.backend.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backend.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Which backend to use when translating, see `translation documentation`_.
-
-.. _`translation documentation`: ../translation.html
diff --git a/pypy/doc/config/objspace.usemodules.token.rst b/pypy/doc/config/objspace.usemodules.token.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.token.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'token' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules._winreg.rst b/pypy/doc/config/objspace.usemodules._winreg.txt
copy from pypy/doc/config/objspace.usemodules._winreg.rst
copy to pypy/doc/config/objspace.usemodules._winreg.txt
diff --git a/pypy/doc/config/translation.debug.rst b/pypy/doc/config/translation.debug.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.debug.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Record extra debugging information during annotation. This leads to slightly
-less obscure error messages.
diff --git a/pypy/doc/config/objspace.usemodules.math.rst b/pypy/doc/config/objspace.usemodules.math.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.math.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'math' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/translation.backendopt.rst b/pypy/doc/config/translation.backendopt.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-This group contains options about various backend optimization passes. Most of
-them are described in the `EU report about optimization`_
-
-.. _`EU report about optimization`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
-
diff --git a/pypy/doc/config/translation.jit.rst b/pypy/doc/config/translation.jit.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.jit.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Enable the JIT generator, for targets that have JIT support.
-Experimental so far.
diff --git a/pypy/doc/image/compat-matrix.png b/pypy/doc/image/compat-matrix.png
index 162c06062b42cdb56745203c7b181707a1b14a69..060537165eca2f94eee1fabb9a0c235fe39e51ee
GIT binary patch
[cut]
diff --git a/pypy/doc/config/objspace.std.builtinshortcut.rst b/pypy/doc/config/objspace.std.builtinshortcut.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.builtinshortcut.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-A shortcut speeding up primitive operations between built-in types.
-
-This is a space-time trade-off: at the moment, this option makes a
-translated pypy-c executable bigger by about 1.7 MB. (This can probably
-be improved with careful analysis.)
diff --git a/pypy/doc/config/translation.cc.rst b/pypy/doc/config/translation.cc.txt
copy from pypy/doc/config/translation.cc.rst
copy to pypy/doc/config/translation.cc.txt
diff --git a/pypy/doc/config/objspace.std.prebuiltintfrom.rst b/pypy/doc/config/objspace.std.prebuiltintfrom.txt
copy from pypy/doc/config/objspace.std.prebuiltintfrom.rst
copy to pypy/doc/config/objspace.std.prebuiltintfrom.txt
diff --git a/pypy/doc/config/objspace.usemodules.operator.rst b/pypy/doc/config/objspace.usemodules.operator.txt
copy from pypy/doc/config/objspace.usemodules.operator.rst
copy to pypy/doc/config/objspace.usemodules.operator.txt
diff --git a/pypy/doc/config/objspace.usemodules.__pypy__.rst b/pypy/doc/config/objspace.usemodules.__pypy__.txt
copy from pypy/doc/config/objspace.usemodules.__pypy__.rst
copy to pypy/doc/config/objspace.usemodules.__pypy__.txt
diff --git a/pypy/doc/config/objspace.honor__builtins__.rst b/pypy/doc/config/objspace.honor__builtins__.rst
deleted file mode 100644
diff --git a/pypy/doc/config/objspace.std.multimethods.rst b/pypy/doc/config/objspace.std.multimethods.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.multimethods.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-Choose the multimethod implementation.
-
-* ``doubledispatch`` turns
- a multimethod call into a sequence of normal method calls.
-
-* ``mrd`` uses a technique known as Multiple Row Displacement
- which precomputes a few compact tables of numbers and
- function pointers.
diff --git a/pypy/doc/config/translation.linkerflags.rst b/pypy/doc/config/translation.linkerflags.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.linkerflags.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Experimental. Specify extra flags to pass to the linker.
diff --git a/pypy/doc/config/objspace.std.withmethodcache.rst b/pypy/doc/config/objspace.std.withmethodcache.txt
copy from pypy/doc/config/objspace.std.withmethodcache.rst
copy to pypy/doc/config/objspace.std.withmethodcache.txt
diff --git a/pypy/doc/config/objspace.usemodules._random.rst b/pypy/doc/config/objspace.usemodules._random.txt
copy from pypy/doc/config/objspace.usemodules._random.rst
copy to pypy/doc/config/objspace.usemodules._random.txt
diff --git a/pypy/doc/how-to-release.rst b/pypy/doc/how-to-release.rst
--- a/pypy/doc/how-to-release.rst
+++ b/pypy/doc/how-to-release.rst
@@ -1,4 +1,6 @@
-.. include:: crufty.rst
+.. include:: needswork.txt
+
+.. needs work, it talks about svn. also, it is not really user documentation
Making a PyPy Release
=======================
diff --git a/pypy/doc/config/objspace.usemodules.mmap.rst b/pypy/doc/config/objspace.usemodules.mmap.txt
copy from pypy/doc/config/objspace.usemodules.mmap.rst
copy to pypy/doc/config/objspace.usemodules.mmap.txt
diff --git a/pypy/doc/config/translation.simplifying.rst b/pypy/doc/config/translation.simplifying.txt
copy from pypy/doc/config/translation.simplifying.rst
copy to pypy/doc/config/translation.simplifying.txt
diff --git a/pypy/doc/config/objspace.std.withmethodcache.rst b/pypy/doc/config/objspace.std.withmethodcache.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withmethodcache.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Enable method caching. See the section "Method Caching" in `Standard
-Interpreter Optimizations <../interpreter-optimizations.html#method-caching>`__.
diff --git a/pypy/doc/config/translation.jit_backend.rst b/pypy/doc/config/translation.jit_backend.txt
copy from pypy/doc/config/translation.jit_backend.rst
copy to pypy/doc/config/translation.jit_backend.txt
diff --git a/pypy/doc/config/translation.dump_static_data_info.rst b/pypy/doc/config/translation.dump_static_data_info.txt
copy from pypy/doc/config/translation.dump_static_data_info.rst
copy to pypy/doc/config/translation.dump_static_data_info.txt
diff --git a/pypy/doc/config/objspace.usemodules.__pypy__.rst b/pypy/doc/config/objspace.usemodules.__pypy__.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.__pypy__.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-Use the '__pypy__' module.
-This module is expected to be working and is included by default.
-It contains special PyPy-specific functionality.
-For example most of the special functions described in the `object space proxies`
-document are in the module.
-See the `__pypy__ module documentation`_ for more details.
-
-.. _`object space proxy`: ../objspace-proxies.html
-.. _`__pypy__ module documentation`: ../__pypy__-module.html
diff --git a/pypy/doc/config/objspace.usemodules._hashlib.rst b/pypy/doc/config/objspace.usemodules._hashlib.txt
copy from pypy/doc/config/objspace.usemodules._hashlib.rst
copy to pypy/doc/config/objspace.usemodules._hashlib.txt
diff --git a/pypy/doc/discussion/security-ideas.rst b/pypy/doc/discussion/security-ideas.rst
deleted file mode 100644
--- a/pypy/doc/discussion/security-ideas.rst
+++ /dev/null
@@ -1,312 +0,0 @@
-==============
-Security ideas
-==============
-
-These are some notes I (Armin) took after a talk at Chalmers by Steve
-Zdancewic: "Encoding Information Flow in Haskell". That talk was
-presenting a pure Haskell approach with monad-like constructions; I
-think that the approach translates well to PyPy at the level of RPython.
-
-
-The problem
------------
-
-The problem that we try to solve here is: how to give the programmer a
-way to write programs that are easily checked to be "secure", in the
-sense that bugs shouldn't allow confidential information to be
-unexpectedly leaked. This is not security as in defeating actively
-malicious attackers.
-
-
-Example
--------
-
-Let's suppose that we want to write a telnet-based application for a
-bidding system. We want normal users to be able to log in with their
-username and password, and place bids (i.e. type in an amount of money).
-The server should record the highest bid so far but not allow users to
-see that number. Additionally, the administrator should be able to log
-in with his own password and see the highest bid. The basic program::
-
- def mainloop():
- while True:
- username = raw_input()
- password = raw_input()
- user = authenticate(username, password)
- if user == 'guest':
- serve_guest()
- elif user == 'admin':
- serve_admin()
-
- def serve_guest():
- global highest_bid
- print "Enter your bid:"
- n = int(raw_input())
- if n > highest_bid: #
- highest_bid = n #
- print "Thank you"
-
- def serve_admin():
- print "Highest big is:", highest_bid
-
-The goal is to make this program more secure by declaring and enforcing
-the following properties: first, the guest code is allowed to manipulate
-the highest_bid, as in the lines marked with ``#``, but these lines must
-not leak back the highest_bid in a form visible to the guest user;
-second, the printing in serve_admin() must only be allowed if the user
-that logged in is really the administrator (e.g. catch bugs like
-accidentally swapping the serve_guest() and serve_admin() calls in
-mainloop()).
-
-
-Preventing leak of information in guest code: 1st try
------------------------------------------------------
-
-The basic technique to prevent leaks is to attach "confidentiality
-level" tags to objects. In this example, the highest_bid int object
-would be tagged with label="secret", e.g. by being initialized as::
-
- highest_bid = tag(0, label="secret")
-
-At first, we can think about an object space where all objects have such
-a label, and the label propagates to operations between objects: for
-example, code like ``highest_bid += 1`` would produce a new int object
-with again label="secret".
-
-Where this approach doesn't work is with if/else or loops. In the above
-example, we do::
-
- if n > highest_bid:
- ...
-
-However, by the object space rules introduced above, the result of the
-comparison is a "secret" bool objects. This means that the guest code
-cannot know if it is True or False, and so the PyPy interpreter has no
-clue if it must following the ``then`` or ``else`` branch of the ``if``.
-So the guest code could do ``highest_bid += 1`` and probably even
-``highest_bid = max(highest_bid, n)`` if max() is a clever enough
-built-in function, but clearly this approach doesn't work well for more
-complicated computations that we would like to perform at this point.
-
-There might be very cool possible ideas to solve this with doing some
-kind of just-in-time flow object space analysis. However, here is a
-possibly more practical approach. Let's forget about the object space
-tricks and start again. (See `Related work`_ for why the object space
-approach doesn't work too well.)
-
-
-Preventing leak of information in guest code with the annotator instead
------------------------------------------------------------------------
-
-Suppose that the program runs on top of CPython and not necessarily
-PyPy. We will only need PyPy's annotator. The idea is to mark the code
-that manipulates highest_bid explicitly, and make it RPython in the
-sense that we can take its flow space and follow the calls (we don't
-care about the precise types here -- we will use different annotations).
-Note that only the bits that manipulates the secret values needs to be
-RPython. Example::
-
- # on top of CPython, 'hidden' is a type that hides a value without
- # giving any way to normal programs to access it, so the program
- # cannot do anything with 'highest_bid'
-
- highest_bid = hidden(0, label="secure")
-
- def enter_bid(n):
- if n > highest_bid.value:
- highest_bid.value = n
-
- enter_bid = secure(enter_bid)
-
- def serve_guest():
- print "Enter your bid:"
- n = int(raw_input())
- enter_bid(n)
- print "Thank you"
-
-The point is that the expression ``highest_bid.value`` raises a
-SecurityException when run normally: it is not allowed to read this
-value. The secure() decorator uses the annotator on the enter_bid()
-function, with special annotations that I will describe shortly. Then
-secure() returns a "compiled" version of enter_bid. The compiled
-version is checked to satisfy the security constrains, and it contains
-special code that then enables the ``highest_bid.value`` to work.
-
-The annotations propagated by secure() are ``SomeSecurityLevel``
-annotations. Normal constants are propagated as
-SomeSecurityLevel("public"). The ``highest_bid.value`` returns the
-annotation SomeSecurityLevel("secret"), which is the label of the
-constant ``highest_bid`` hidden object. We define operations between
-two SomeSecurityLevels to return a SomeSecurityLevel which is the max of
-the secret levels of the operands.
-
-The key point is that secure() checks that the return value is
-SomeSecurityLevel("public"). It also checks that only
-SomeSecurityLevel("public") values are stored e.g. in global data
-structures.
-
-In this way, any CPython code like serve_guest() can safely call
-``enter_bid(n)``. There is no way to leak information about the current
-highest bid back out of the compiled enter_bid().
-
-
-Declassification
-----------------
-
-Now there must be a controlled way to leak the highest_bid value,
-otherwise it is impossible even for the admin to read it. Note that
-serve_admin(), which prints highest_bid, is considered to "leak" this
-value because it is an input-output, i.e. it escapes the program. This
-is a leak that we actually want -- the terminology is that serve_admin()
-must "declassify" the value.
-
-To do this, there is a capability-like model that is easy to implement
-for us. Let us modify the main loop as follows::
-
- def mainloop():
- while True:
- username = raw_input()
- password = raw_input()
- user, priviledge_token = authenticate(username, password)
- if user == 'guest':
- serve_guest()
- elif user == 'admin':
- serve_admin(priviledge_token)
- del priviledge_token # make sure nobody else uses it
-
-The idea is that the authenticate() function (shown later) also returns
-a "token" object. This is a normal Python object, but it should not be
-possible for normal Python code to instantiate such an object manually.
-In this example, authenticate() returns a ``priviledge("public")`` for
-guests, and a ``priviledge("secret")`` for admins. Now -- and this is
-the insecure part of this scheme, but it is relatively easy to control
--- the programmer must make sure that these priviledge_token objects
-don't go to unexpected places, particularly the "secret" one. They work
-like capabilities: having a reference to them allows parts of the
-program to see secret information, of a confidentiality level up to the
-one corresponding to the token.
-
-Now we modify serve_admin() as follows:
-
- def serve_admin(token):
- print "Highest big is:", declassify(highest_bid, token=token)
-
-The declassify() function reads the value if the "token" is privileged
-enough, and raises an exception otherwise.
-
-What are we protecting here? The fact that we need the administrator
-token in order to see the highest bid. If by mistake we swap the
-serve_guest() and serve_admin() lines in mainloop(), then what occurs is
-that serve_admin() would be called with the guest token. Then
-declassify() would fail. If we assume that authenticate() is not buggy,
-then the rest of the program is safe from leak bugs.
-
-There are another variants of declassify() that are convenient. For
-example, in the RPython parts of the code, declassify() can be used to
-control more precisely at which confidentiality levels we want which
-values, if there are more than just two such levels. The "token"
-argument could also be implicit in RPython parts, meaning "use the
-current level"; normal non-RPython code always runs at "public" level,
-but RPython functions could run with higher current levels, e.g. if they
-are called with a "token=..." argument.
-
-(Do not confuse this with what enter_bid() does: enter_bid() runs at the
-public level all along. It is ok for it to compute with, and even
-modify, the highest_bid.value. The point of enter_bid() was that by
-being an RPython function the annotator can make sure that the value, or
-even anything that gives a hint about the value, cannot possibly escape
-from the function.)
-
-It is also useful to have "globally trusted" administrator-level RPython
-functions that always run at a higher level than the caller, a bit like
-Unix programs with the "suid" bit. If we set aside the consideration
-that it should not be possible to make new "suid" functions too easily,
-then we could define the authenticate() function of our server example
-as follows::
-
- def authenticate(username, password):
- database = {('guest', 'abc'): priviledge("public"),
- ('admin', '123'): priviledge("secret")}
- token_obj = database[username, password]
- return username, declassify(token_obj, target_level="public")
-
- authenticate = secure(authenticate, suid="secret")
-
-The "suid" argument makes the compiled function run on level "secret"
-even if the caller is "public" or plain CPython code. The declassify()
-in the function is allowed because of the current level of "secret".
-Note that the function returns a "public" tuple -- the username is
-public, and the token_obj is declassified to public. This is the
-property that allows CPython code to call it.
-
-Of course, like a Unix suid program the authenticate() function could be
-buggy and leak information, but like suid programs it is small enough
-for us to feel that it is secure just by staring at the code.
-
-An alternative to the suid approach is to play with closures, e.g.::
-
- def setup():
- #initialize new levels -- this cannot be used to access existing levels
- public_level = create_new_priviledge("public")
- secret_level = create_new_priviledge("secret")
-
- database = {('guest', 'abc'): public_level,
- ('admin', '123'): secret_level}
-
- def authenticate(username, password):
- token_obj = database[username, password]
- return username, declassify(token_obj, target_level="public",
- token=secret_level)
-
- return secure(authenticate)
-
- authenticate = setup()
-
-In this approach, declassify() works because it has access to the
-secret_level token. We still need to make authenticate() a secure()
-compiled function to hide the database and the secret_level more
-carefully; otherwise, code could accidentally find them by inspecting
-the traceback of the KeyError exception if the username or password is
-invalid. Also, secure() will check for us that authenticate() indeed
-returns a "public" tuple.
-
-This basic model is easy to extend in various directions. For example
-secure() RPython functions should be allowed to return non-public
-results -- but then they have to be called either with an appropriate
-"token=..." keyword, or else they return hidden objects again. They
-could also be used directly from other RPython functions, in which the
-level of what they return is propagated.
-
-
-Related work
-------------
-
-What I'm describing here is nothing more than an adaptation of existing
-techniques to RPython.
-
-It is noteworthy to mention at this point why the object space approach
-doesn't work as well as we could first expect. The distinction between
-static checking and dynamic checking (with labels only attached to
-values) seems to be well known; also, it seems to be well known that the
-latter is too coarse in practice. The problem is about branching and
-looping. From the object space' point of view it is quite hard to know
-what a newly computed value really depends on. Basically, it is
-difficult to do better than: after is_true() has been called on a secret
-object, then we must assume that all objects created are also secret
-because they could depend in some way on the truth-value of the previous
-secret object.
-
-The idea to dynamically use static analysis is the key new idea
-presented by Steve Zdancewic in his talk. You can have small controlled
-RPython parts of the program that must pass through a static analysis,
-and we only need to check dynamically that some input conditions are
-satisfied when other parts of the program call the RPython parts.
-Previous research was mostly about designing languages that are
-completely statically checked at compile-time. The delicate part is to
-get the static/dynamic mixture right so that even indirect leaks are not
-possible -- e.g. leaks that would occur from calling functions with
-strange arguments to provoke exceptions, and where the presence of the
-exception or not would be information in itself. This approach seems to
-do that reliably. (Of course, at the talk many people including the
-speaker were wondering about ways to move more of the checking at
-compile-time, but Python people won't have such worries :-)
diff --git a/pypy/doc/config/objspace.usemodules.posix.rst b/pypy/doc/config/objspace.usemodules.posix.txt
copy from pypy/doc/config/objspace.usemodules.posix.rst
copy to pypy/doc/config/objspace.usemodules.posix.txt
diff --git a/pypy/doc/discussion/parsing-ideas.rst b/pypy/doc/discussion/parsing-ideas.rst
deleted file mode 100644
--- a/pypy/doc/discussion/parsing-ideas.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-add a way to modularize regular expressions:
-
-_HEXNUM = "...";
-_DECNUM = "...";
-NUM = "{_HEXNUM}|{_DECNUM}";
diff --git a/pypy/doc/index.rst b/pypy/doc/index.rst
--- a/pypy/doc/index.rst
+++ b/pypy/doc/index.rst
@@ -11,20 +11,37 @@
Getting into PyPy ...
=============================================
-* `Release 1.4`_: the latest official release
+* `Release 1.5`_: the latest official release
* `PyPy Blog`_: news and status info about PyPy
-* `Documentation`_: extensive documentation about PyPy.
-
-* `Getting Started`_: Getting started and playing with PyPy.
-
* `Papers`_: Academic papers, talks, and related projects
* `Videos`_: Videos of PyPy talks and presentations
* `speed.pypy.org`_: Daily benchmarks of how fast PyPy is
+Documentation for the PyPy Python Interpreter
+===============================================
+
+`getting started`_ provides hands-on instructions
+including a two-liner to run the PyPy Python interpreter
+on your system, examples on advanced features and
+entry points for using the `RPython toolchain`_.
+
+`FAQ`_ contains some frequently asked questions.
+
+New features of PyPy's Python Interpreter and
+Translation Framework:
+
+ * `Differences between PyPy and CPython`_
+ * `What PyPy can do for your objects`_
+ * `Stackless and coroutines`_
+ * `JIT Generation in PyPy`_
+ * `Sandboxing Python code`_
+
+Status_ of the project.
+
Mailing lists, bug tracker, IRC channel
=============================================
@@ -32,13 +49,13 @@
* `Development mailing list`_: development and conceptual
discussions.
-* `Subversion commit mailing list`_: updates to code and
+* `Mercurial commit mailing list`_: updates to code and
documentation.
+* `Sprint mailing list`_: mailing list for organizing upcoming sprints.
+
* `Development bug/feature tracker`_: filing bugs and feature requests.
-* `Sprint mailing list`_: mailing list for organizing upcoming sprints.
-
* **IRC channel #pypy on freenode**: Many of the core developers are hanging out
at #pypy on irc.freenode.net. You are welcome to join and ask questions
(if they are not already developed in the FAQ_).
@@ -60,18 +77,291 @@
.. _`development bug/feature tracker`: https://codespeak.net/issue/pypy-dev/
.. _here: http://tismerysoft.de/pypy/irc-logs/pypy
.. _`sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint
-.. _`subversion commit mailing list`: http://codespeak.net/mailman/listinfo/pypy-svn
+.. _`Mercurial commit mailing list`: http://codespeak.net/mailman/listinfo/pypy-svn
.. _`development mailing list`: http://codespeak.net/mailman/listinfo/pypy-dev
.. _`FAQ`: faq.html
-.. _`Documentation`: docindex.html
.. _`Getting Started`: getting-started.html
.. _`Papers`: extradoc.html
.. _`Videos`: video-index.html
-.. _`Release 1.4`: http://pypy.org/download.html
+.. _`Release 1.5`: http://pypy.org/download.html
.. _`speed.pypy.org`: http://speed.pypy.org
+.. _`RPython toolchain`: translation.html
-Detailed Documentation
-======================
+
+Project Documentation
+=====================================
+
+PyPy was funded by the EU for several years. See the `web site of the EU
+project`_ for more details.
+
+.. _`web site of the EU project`: http://pypy.org
+
+architecture_ gives a complete view of PyPy's basic design.
+
+`coding guide`_ helps you to write code for PyPy (especially also describes
+coding in RPython a bit).
+
+`sprint reports`_ lists reports written at most of our sprints, from
+2003 to the present.
+
+`papers, talks and related projects`_ lists presentations
+and related projects as well as our published papers.
+
+`PyPy video documentation`_ is a page linking to the videos (e.g. of talks and
+introductions) that are available.
+
+`Technical reports`_ is a page that contains links to the
+reports that we submitted to the European Union.
+
+`development methodology`_ describes our sprint-driven approach.
+
+`LICENSE`_ contains licensing details (basically a straight MIT-license).
+
+`Glossary`_ of PyPy words to help you align your inner self with
+the PyPy universe.
+
+
+Status
+===================================
+
+PyPy can be used to run Python programs on Linux, OS/X,
+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 latest release, which is `1.5`__.
+
+.. __: release-1.5.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
+them. Linux 64-bit machines are supported (though it may also take some
+time before we notice and fix bugs).
+
+PyPy's own tests `summary`_, daily updated, run through BuildBot infrastructure.
+You can also find CPython's compliance tests run with compiled ``pypy-c``
+executables there.
+
+information dating from early 2007:
+
+`PyPy LOC statistics`_ shows LOC statistics about PyPy.
+
+`PyPy statistics`_ is a page with various statistics about the PyPy project.
+
+`compatibility matrix`_ is a diagram that shows which of the various features
+of the PyPy interpreter work together with which other features.
+
+
+Source Code Documentation
+===============================================
+
+`object spaces`_ discusses the object space interface
+and several implementations.
+
+`bytecode interpreter`_ explains the basic mechanisms
+of the bytecode interpreter and virtual machine.
+
+`interpreter optimizations`_ describes our various strategies for
+improving the performance of our interpreter, including alternative
+object implementations (for strings, dictionaries and lists) in the
+standard object space.
+
+`translation`_ is a detailed overview of our translation process. The
+rtyper_ is the largest component of our translation process.
+
+`dynamic-language translation`_ is a paper that describes
+the translation process, especially the flow object space
+and the annotator in detail. (This document is one
+of the `EU reports`_.)
+
+`low-level encapsulation`_ describes how our approach hides
+away a lot of low level details. This document is also part
+of the `EU reports`_.
+
+`translation aspects`_ describes how we weave different
+properties into our interpreter during the translation
+process. This document is also part of the `EU reports`_.
+
+`garbage collector`_ strategies that can be used by the virtual
+machines produced by the translation process.
+
+`parser`_ contains (outdated, unfinished) documentation about
+the parser.
+
+`rlib`_ describes some modules that can be used when implementing programs in
+RPython.
+
+`configuration documentation`_ describes the various configuration options that
+allow you to customize PyPy.
+
+`CLI backend`_ describes the details of the .NET backend.
+
+`JIT Generation in PyPy`_ describes how we produce the Python Just-in-time Compiler
+from our Python interpreter.
+
+
+
+.. _`FAQ`: faq.html
+.. _Glossary: glossary.html
+.. _`PyPy video documentation`: video-index.html
+.. _parser: parser.html
+.. _`development methodology`: dev_method.html
+.. _`sprint reports`: sprint-reports.html
+.. _`papers, talks and related projects`: extradoc.html
+.. _`PyPy LOC statistics`: http://codespeak.net/~hpk/pypy-stat/
+.. _`PyPy statistics`: http://codespeak.net/pypy/trunk/pypy/doc/statistic
+.. _`object spaces`: objspace.html
+.. _`interpreter optimizations`: interpreter-optimizations.html
+.. _`translation`: translation.html
+.. _`dynamic-language translation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`low-level encapsulation`: low-level-encapsulation.html
+.. _`translation aspects`: translation-aspects.html
+.. _`configuration documentation`: config/
+.. _`coding guide`: coding-guide.html
+.. _`architecture`: architecture.html
+.. _`getting started`: getting-started.html
+.. _`bytecode interpreter`: interpreter.html
+.. _`EU reports`: index-report.html
+.. _`Technical reports`: index-report.html
+.. _`summary`: http://codespeak.net:8099/summary
+.. _`ideas for PyPy related projects`: project-ideas.html
+.. _`Nightly builds and benchmarks`: http://tuatara.cs.uni-duesseldorf.de/benchmark.html
+.. _`directory reference`:
+.. _`rlib`: rlib.html
+.. _`Sandboxing Python code`: sandbox.html
+.. _`LICENSE`: https://bitbucket.org/pypy/pypy/src/default/LICENSE
+
+PyPy directory cross-reference
+------------------------------
+
+Here is a fully referenced alphabetical two-level deep
+directory overview of PyPy:
+
+================================ ===========================================
+Directory explanation/links
+================================ ===========================================
+`pypy/annotation/`_ `type inferencing code`_ for `RPython`_ programs
+
+`pypy/bin/`_ command-line scripts, mainly `py.py`_ and `translatorshell.py`_
+
+`pypy/config/`_ handles the numerous options for building and running PyPy
+
+`pypy/doc/`_ text versions of PyPy developer documentation
+
+`pypy/doc/config/`_ documentation for the numerous translation options
+
+`pypy/doc/discussion/`_ drafts of ideas and documentation
+
+``doc/*/`` other specific documentation topics or tools
+
+`pypy/interpreter/`_ `bytecode interpreter`_ and related objects
+ (frames, functions, modules,...)
+
+`pypy/interpreter/pyparser/`_ interpreter-level Python source parser
+
+`pypy/interpreter/astcompiler/`_ interpreter-level bytecode compiler, via an AST
+ representation
+
+`pypy/module/`_ contains `mixed modules`_ implementing core modules with
+ both application and interpreter level code.
+ Not all are finished and working. Use the ``--withmod-xxx``
+ or ``--allworkingmodules`` translation options.
+
+`pypy/objspace/`_ `object space`_ implementations
+
+`pypy/objspace/trace.py`_ the `trace object space`_ monitoring bytecode and space operations
+
+`pypy/objspace/dump.py`_ the dump object space saves a large, searchable log file
+ with all operations
+
+`pypy/objspace/thunk.py`_ the `thunk object space`_, providing unique object features
+
+`pypy/objspace/flow/`_ the FlowObjSpace_ implementing `abstract interpretation`_
+
+`pypy/objspace/std/`_ the StdObjSpace_ implementing CPython's objects and types
+
+`pypy/rlib/`_ a `"standard library"`_ for RPython_ programs
+
+`pypy/rpython/`_ the `RPython Typer`_
+
+`pypy/rpython/lltypesystem/`_ the `low-level type system`_ for C-like backends
+
+`pypy/rpython/ootypesystem/`_ the `object-oriented type system`_ for OO backends
+
+`pypy/rpython/memory/`_ the `garbage collector`_ construction framework
+
+`pypy/tool/`_ various utilities and hacks used from various places
+
+`pypy/tool/algo/`_ general-purpose algorithmic and mathematic
+ tools
+
+`pypy/tool/pytest/`_ support code for our `testing methods`_
+
+`pypy/translator/`_ translation_ backends and support code
+
+`pypy/translator/backendopt/`_ general optimizations that run before a backend generates code
+
+`pypy/translator/c/`_ the `GenC backend`_, producing C code from an
+ RPython program (generally via the rtyper_)
+
+`pypy/translator/cli/`_ the `CLI backend`_ for `.NET`_ (Microsoft CLR or Mono_)
+
+`pypy/translator/goal/`_ our `main PyPy-translation scripts`_ live here
+
+`pypy/translator/jvm/`_ the Java backend
+
+`pypy/translator/stackless/`_ the `Stackless Transform`_
+
+`pypy/translator/tool/`_ helper tools for translation, including the Pygame
+ `graph viewer`_
+
+``*/test/`` many directories have a test subdirectory containing test
+ modules (see `Testing in PyPy`_)
+
+``_cache/`` holds cache files from internally `translating application
+ level to interpreterlevel`_ code.
+================================ ===========================================
+
+.. _`bytecode interpreter`: interpreter.html
+.. _`translating application level to interpreterlevel`: geninterp.html
+.. _`Testing in PyPy`: coding-guide.html#testing-in-pypy
+.. _`mixed modules`: coding-guide.html#mixed-modules
+.. _`modules`: coding-guide.html#modules
+.. _`basil`: http://people.cs.uchicago.edu/~jriehl/BasilTalk.pdf
+.. _`object space`: objspace.html
+.. _FlowObjSpace: objspace.html#the-flow-object-space
+.. _`trace object space`: objspace.html#the-trace-object-space
+.. _`taint object space`: objspace-proxies.html#taint
+.. _`thunk object space`: objspace-proxies.html#thunk
+.. _`transparent proxies`: objspace-proxies.html#tproxy
+.. _`Differences between PyPy and CPython`: cpython_differences.html
+.. _`What PyPy can do for your objects`: objspace-proxies.html
+.. _`Stackless and coroutines`: stackless.html
+.. _StdObjSpace: objspace.html#the-standard-object-space
+.. _`abstract interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
+.. _`rpython`: coding-guide.html#rpython
+.. _`type inferencing code`: translation.html#the-annotation-pass
+.. _`RPython Typer`: translation.html#rpython-typer
+.. _`testing methods`: coding-guide.html#testing-in-pypy
+.. _`translation`: translation.html
+.. _`GenC backend`: translation.html#genc
+.. _`CLI backend`: cli-backend.html
+.. _`py.py`: getting-started-python.html#the-py.py-interpreter
+.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
+.. _JIT: jit/index.html
+.. _`JIT Generation in PyPy`: jit/index.html
+.. _`just-in-time compiler generator`: jit/index.html
+.. _rtyper: rtyper.html
+.. _`low-level type system`: rtyper.html#low-level-type
+.. _`object-oriented type system`: rtyper.html#oo-type
+.. _`garbage collector`: garbage_collection.html
+.. _`Stackless Transform`: translation.html#the-stackless-transform
+.. _`main PyPy-translation scripts`: getting-started-python.html#translating-the-pypy-python-interpreter
+.. _`.NET`: http://www.microsoft.com/net/
+.. _Mono: http://www.mono-project.com/
+.. _`"standard library"`: rlib.html
+.. _`graph viewer`: getting-started-dev.html#try-out-the-translator
+.. _`compatibility matrix`: image/compat-matrix.png
+
.. The following documentation is important and reasonably up-to-date:
@@ -80,6 +370,7 @@
.. toctree::
:maxdepth: 1
+ :hidden:
getting-started.rst
getting-started-python.rst
@@ -89,15 +380,18 @@
architecture.rst
coding-guide.rst
cpython_differences.rst
- cleanup-todo.rst
garbage_collection.rst
interpreter.rst
objspace.rst
+ __pypy__-module.rst
+ objspace-proxies.rst
+ config/index.rst
dev_method.rst
extending.rst
extradoc.rst
+ video-index.rst
glossary.rst
@@ -105,12 +399,12 @@
interpreter-optimizations.rst
configuration.rst
- low-level-encapsulation.rst
parser.rst
rlib.rst
rtyper.rst
+ rffi.rst
+
translation.rst
- jit/_ref.rst
jit/index.rst
jit/overview.rst
jit/pyjitpl5.rst
@@ -124,6 +418,7 @@
index-report.rst
stackless.rst
+ sandbox.rst
discussions.rst
@@ -132,12 +427,14 @@
sprint-reports.rst
eventhistory.rst
+ statistic/index.rst
Indices and tables
==================
* :ref:`genindex`
-* :ref:`modindex`
* :ref:`search`
* :ref:`glossary`
+
+.. include:: _ref.txt
diff --git a/pypy/doc/index-of-release-notes.rst b/pypy/doc/index-of-release-notes.rst
--- a/pypy/doc/index-of-release-notes.rst
+++ b/pypy/doc/index-of-release-notes.rst
@@ -15,3 +15,4 @@
release-1.4.0.rst
release-1.4.0beta.rst
release-1.4.1.rst
+ release-1.5.0.rst
diff --git a/pypy/doc/config/objspace.std.sharesmallstr.rst b/pypy/doc/config/objspace.std.sharesmallstr.rst
deleted file mode 100644
diff --git a/pypy/doc/config/objspace.geninterp.rst b/pypy/doc/config/objspace.geninterp.txt
copy from pypy/doc/config/objspace.geninterp.rst
copy to pypy/doc/config/objspace.geninterp.txt
diff --git a/pypy/doc/config/translation.cli.exception_transformer.rst b/pypy/doc/config/translation.cli.exception_transformer.txt
copy from pypy/doc/config/translation.cli.exception_transformer.rst
copy to pypy/doc/config/translation.cli.exception_transformer.txt
diff --git a/pypy/doc/config/translation.backendopt.stack_optimization.rst b/pypy/doc/config/translation.backendopt.stack_optimization.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.stack_optimization.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Enable the optimized code generation for stack based machine, if the backend support it
diff --git a/pypy/doc/config/objspace.usemodules._codecs.rst b/pypy/doc/config/objspace.usemodules._codecs.txt
copy from pypy/doc/config/objspace.usemodules._codecs.rst
copy to pypy/doc/config/objspace.usemodules._codecs.txt
diff --git a/pypy/doc/config/objspace.usemodules.unicodedata.rst b/pypy/doc/config/objspace.usemodules.unicodedata.txt
copy from pypy/doc/config/objspace.usemodules.unicodedata.rst
copy to pypy/doc/config/objspace.usemodules.unicodedata.txt
diff --git a/pypy/doc/config/translation.rst b/pypy/doc/config/translation.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/translation.jit_backend.rst b/pypy/doc/config/translation.jit_backend.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.jit_backend.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Choose the backend to use for the JIT.
-By default, this is the best backend for the current platform.
diff --git a/pypy/doc/config/objspace.std.newshortcut.rst b/pypy/doc/config/objspace.std.newshortcut.txt
copy from pypy/doc/config/objspace.std.newshortcut.rst
copy to pypy/doc/config/objspace.std.newshortcut.txt
diff --git a/pypy/doc/config/objspace.std.methodcachesizeexp.rst b/pypy/doc/config/objspace.std.methodcachesizeexp.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.methodcachesizeexp.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Set the cache size (number of entries) for :config:`objspace.std.withmethodcache`.
diff --git a/pypy/doc/config/objspace.std.rst b/pypy/doc/config/objspace.std.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/objspace.extmodules.rst b/pypy/doc/config/objspace.extmodules.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.extmodules.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-You can pass a comma-separated list of third-party builtin modules
-which should be translated along with the standard modules within
-``pypy.module``.
-
-The module names need to be fully qualified (i.e. have a ``.`` in them),
-be on the ``$PYTHONPATH`` and not conflict with any existing ones, e.g.
-``mypkg.somemod``.
-
-Once translated, the module will be accessible with a simple::
-
- import somemod
-
diff --git a/pypy/doc/config/objspace.usemodules._ast.rst b/pypy/doc/config/objspace.usemodules._ast.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._ast.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_ast' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules.sys.rst b/pypy/doc/config/objspace.usemodules.sys.txt
copy from pypy/doc/config/objspace.usemodules.sys.rst
copy to pypy/doc/config/objspace.usemodules.sys.txt
diff --git a/pypy/doc/config/translation.ootype.rst b/pypy/doc/config/translation.ootype.txt
copy from pypy/doc/config/translation.ootype.rst
copy to pypy/doc/config/translation.ootype.txt
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline.rst b/pypy/doc/config/translation.backendopt.profile_based_inline.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.profile_based_inline.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-Inline flowgraphs only for call-sites for which there was a minimal
-number of calls during an instrumented run of the program. Callee
-flowgraphs are considered candidates based on a weight heuristic like
-for basic inlining. (see :config:`translation.backendopt.inline`,
-:config:`translation.backendopt.profile_based_inline_threshold` ).
-
-The option takes as value a string which is the arguments to pass to
-the program for the instrumented run.
-
-This optimization is not used by default.
\ No newline at end of file
diff --git a/pypy/doc/Makefile b/pypy/doc/Makefile
--- a/pypy/doc/Makefile
+++ b/pypy/doc/Makefile
@@ -31,32 +31,38 @@
-rm -rf $(BUILDDIR)/*
html:
+ python config/generate.py
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
dirhtml:
+ python config/generate.py
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
pickle:
+ python config/generate.py
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
+ python config/generate.py
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
+ python config/generate.py
$(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:
+ python config/generate.py
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
@@ -66,6 +72,7 @@
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/PyPy.qhc"
latex:
+ python config/generate.py
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@@ -73,17 +80,20 @@
"run these through (pdf)latex."
changes:
+ python config/generate.py
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
+ python config/generate.py
$(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:
+ python config/generate.py
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
diff --git a/pypy/doc/config/objspace.usemodules._md5.rst b/pypy/doc/config/objspace.usemodules._md5.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._md5.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Use the built-in '_md5' module.
-This module is expected to be working and is included by default.
-There is also a pure Python version in lib_pypy which is used
-if the built-in is disabled, but it is several orders of magnitude
-slower.
diff --git a/pypy/doc/config/objspace.std.builtinshortcut.rst b/pypy/doc/config/objspace.std.builtinshortcut.txt
copy from pypy/doc/config/objspace.std.builtinshortcut.rst
copy to pypy/doc/config/objspace.std.builtinshortcut.txt
diff --git a/pypy/doc/discussion/ctypes_todo.rst b/pypy/doc/discussion/ctypes_todo.rst
deleted file mode 100644
--- a/pypy/doc/discussion/ctypes_todo.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-Few ctypes-related todo points:
-
-* Write down missing parts and port all tests, eventually adding
- additional tests.
-
- - for unions and structs, late assignment of _fields_ is somewhat buggy.
- Tests about behavior of getattr working properly on instances
- are missing or not comprehensive. Some tests are skipped because I didn't
- understand the details.
-
- - _fields_ can be tuples too as well as lists
-
- - restype being a function is not working.
-
- - there are features, which we don't support like buffer() and
- array() protocols.
-
- - are the _CData_value return lifetime/gc semantics correct?
-
- - for some ABIs we will need completely filled ffitypes to do the
- right thing for passing structures by value, we are now passing enough
- information to rawffi that it should be possible to construct such precise
- ffitypes in most cases
-
- - bitfields are not implemented
-
- - byteorder is not implemented
-
-* as all stuff is applevel, we cannot have it really fast right now.
-
-* we shall at least try to approach ctypes from the point of the jit
- backends (at least on platforms that we support). The thing is that
- we need a lot broader support of jit backends for different argument
- passing in order to do it.
diff --git a/pypy/doc/config/objspace.std.optimized_list_getitem.rst b/pypy/doc/config/objspace.std.optimized_list_getitem.txt
copy from pypy/doc/config/objspace.std.optimized_list_getitem.rst
copy to pypy/doc/config/objspace.std.optimized_list_getitem.txt
diff --git a/pypy/doc/config/objspace.std.withropeunicode.rst b/pypy/doc/config/objspace.std.withropeunicode.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withropeunicode.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Use ropes to implement unicode strings (and also normal strings).
-
-See the section in `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#ropes
-
-
diff --git a/pypy/doc/config/objspace.std.optimized_int_add.rst b/pypy/doc/config/objspace.std.optimized_int_add.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.optimized_int_add.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Optimize the addition of two integers a bit. Enabling this option gives small
-speedups.
diff --git a/pypy/doc/distribution.rst b/pypy/doc/distribution.rst
--- a/pypy/doc/distribution.rst
+++ b/pypy/doc/distribution.rst
@@ -1,10 +1,8 @@
-.. include:: crufty.rst
+.. include:: needswork.txt
- .. ^^ Incomplete, superceded elsewhere
-
-========================
-lib/distributed features
-========================
+=============================
+lib_pypy/distributed features
+=============================
The 'distributed' library is an attempt to provide transparent, lazy
access to remote objects. This is accomplished using
diff --git a/pypy/doc/config/objspace.usemodules._multiprocessing.rst b/pypy/doc/config/objspace.usemodules._multiprocessing.txt
copy from pypy/doc/config/objspace.usemodules._multiprocessing.rst
copy to pypy/doc/config/objspace.usemodules._multiprocessing.txt
diff --git a/pypy/doc/discussion/howtoimplementpickling.rst b/pypy/doc/discussion/howtoimplementpickling.rst
--- a/pypy/doc/discussion/howtoimplementpickling.rst
+++ b/pypy/doc/discussion/howtoimplementpickling.rst
@@ -1,3 +1,5 @@
+.. XXX think more, some of this might be useful
+
Designing thread pickling or "the Essence of Stackless Python"
--------------------------------------------------------------
diff --git a/pypy/doc/config/objspace.std.withrope.rst b/pypy/doc/config/objspace.std.withrope.txt
copy from pypy/doc/config/objspace.std.withrope.rst
copy to pypy/doc/config/objspace.std.withrope.txt
diff --git a/pypy/doc/discussion/compiled-swamp.rst b/pypy/doc/discussion/compiled-swamp.rst
deleted file mode 100644
--- a/pypy/doc/discussion/compiled-swamp.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-
-We've got huge swamp of compiled pypy-c's used for:
-
-* benchmarks
-* tests
-* compliance tests
-* play1
-* downloads
-* ...
-
-We've got build tool, which we don't use, etc. etc.
-
-Idea is to formalize it more or less, so we'll have single script
-to make all of this work, upload builds to the web page etc.
diff --git a/pypy/doc/config/objspace.usemodules.operator.rst b/pypy/doc/config/objspace.usemodules.operator.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.operator.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'operator' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/config/test/test_makerestdoc.py b/pypy/config/test/test_makerestdoc.py
--- a/pypy/config/test/test_makerestdoc.py
+++ b/pypy/config/test/test_makerestdoc.py
@@ -20,14 +20,14 @@
config = Config(descr)
txt = descr.make_rest_doc().text()
- result = {"": checkrest(txt, descr._name + ".txt")}
+ result = {"": txt}
for path in config.getpaths(include_groups=True):
subconf, step = config._cfgimpl_get_home_by_path(path)
fullpath = (descr._name + "." + path)
prefix = fullpath.rsplit(".", 1)[0]
txt = getattr(subconf._cfgimpl_descr, step).make_rest_doc(
prefix).text()
- result[path] = checkrest(txt, fullpath + ".txt")
+ result[path] = txt
return result
def test_simple():
@@ -68,7 +68,6 @@
ChoiceOption("bar", "more doc", ["a", "b", "c"],
default="a")])
result = generate_html(descr)
- assert "more doc" in result[""]
def test_cmdline_overview():
descr = OptionDescription("foo", "doc", [
diff --git a/pypy/doc/config/objspace.name.rst b/pypy/doc/config/objspace.name.txt
copy from pypy/doc/config/objspace.name.rst
copy to pypy/doc/config/objspace.name.txt
diff --git a/pypy/doc/config/translation.stackless.rst b/pypy/doc/config/translation.stackless.txt
copy from pypy/doc/config/translation.stackless.rst
copy to pypy/doc/config/translation.stackless.txt
diff --git a/pypy/doc/config/objspace.usemodules.termios.rst b/pypy/doc/config/objspace.usemodules.termios.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.termios.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'termios' module.
-This module is expected to be fully working.
diff --git a/pypy/tool/rest/directive.py b/pypy/tool/rest/directive.py
--- a/pypy/tool/rest/directive.py
+++ b/pypy/tool/rest/directive.py
@@ -1,108 +1,9 @@
-# XXX this file is messy since it tries to deal with several docutils versions
import py
-from pypy.tool.rest.convert import convert_dot, latexformula2png
-
import sys
import docutils
from docutils import nodes
-from docutils.parsers.rst import directives, states, roles
-from docutils.parsers.rst.directives import images
-
-if hasattr(images, "image"):
- directives_are_functions = True
-else:
- directives_are_functions = False
-
-try:
- from docutils.utils import unescape # docutils version > 0.3.5
-except ImportError:
- from docutils.parsers.rst.states import unescape # docutils 0.3.5
-
-if not directives_are_functions:
- ImageClass = images.Image
-
-else:
- class ImageClass(object):
- option_spec = images.image.options
- def run(self):
- return images.image(u'image',
- self.arguments,
- self.options,
- self.content,
- self.lineno,
- self.content_offset,
- self.block_text,
- self.state,
- self.state_machine)
-
-
-backend_to_image_format = {"html": "png", "latex": "pdf"}
-
-class GraphvizDirective(ImageClass):
- def convert(self, fn, path):
- path = py.path.local(path).dirpath()
- dot = path.join(fn)
- result = convert_dot(dot, backend_to_image_format[_backend])
- return result.relto(path)
-
- def run(self):
- newname = self.convert(self.arguments[0],
- self.state.document.settings._source)
- text = self.block_text.replace("graphviz", "image", 1)
- self.block_text = text.replace(self.arguments[0], newname, 1)
- self.name = u'image'
- self.arguments = [newname]
- return ImageClass.run(self)
-
- def old_interface(self):
- def f(name, arguments, options, content, lineno,
- content_offset, block_text, state, state_machine):
- for arg in "name arguments options content lineno " \
- "content_offset block_text state state_machine".split():
- setattr(self, arg, locals()[arg])
- return self.run()
- f.arguments = (1, 0, 1)
- f.options = self.option_spec
- return f
-
-
-_backend = None
-def set_backend_and_register_directives(backend):
- #XXX this is only used to work around the inflexibility of docutils:
- # a directive does not know the target format
- global _backend
- _backend = backend
- if not directives_are_functions:
- directives.register_directive("graphviz", GraphvizDirective)
- else:
- directives.register_directive("graphviz",
- GraphvizDirective().old_interface())
- roles.register_canonical_role("latexformula", latexformula_role)
-
-def latexformula_role(name, rawtext, text, lineno, inliner,
- options={}, content=[]):
- if _backend == 'latex':
- options['format'] = 'latex'
- return roles.raw_role(name, rawtext, text, lineno, inliner,
- options, content)
- else:
- # XXX: make the place of the image directory configurable
- sourcedir = py.path.local(inliner.document.settings._source).dirpath()
- imagedir = sourcedir.join("img")
- if not imagedir.check():
- imagedir.mkdir()
- # create halfway senseful imagename:
- # use hash of formula + alphanumeric characters of it
- # could
- imagename = "%s_%s.png" % (
- hash(text), "".join([c for c in text if c.isalnum()]))
- image = imagedir.join(imagename)
- latexformula2png(unescape(text, True), image)
- imagenode = nodes.image(image.relto(sourcedir), uri=image.relto(sourcedir))
- return [imagenode], []
-latexformula_role.content = True
-latexformula_role.options = {}
+from docutils.parsers.rst import roles
def register_linkrole(role_name, callback):
def source_role(name, rawtext, text, lineno, inliner, options={},
diff --git a/pypy/doc/config/objspace.timing.rst b/pypy/doc/config/objspace.timing.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.timing.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-timing of various parts of the interpreter (simple profiling)
diff --git a/pypy/doc/config/objspace.usemodules.signal.rst b/pypy/doc/config/objspace.usemodules.signal.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.signal.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'signal' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/config/objspace.usepycfiles.rst b/pypy/doc/config/objspace.usepycfiles.txt
copy from pypy/doc/config/objspace.usepycfiles.rst
copy to pypy/doc/config/objspace.usepycfiles.txt
diff --git a/pypy/doc/configuration.rst b/pypy/doc/configuration.rst
--- a/pypy/doc/configuration.rst
+++ b/pypy/doc/configuration.rst
@@ -4,22 +4,23 @@
Due to more and more available configuration options it became quite annoying to
hand the necessary options to where they are actually used and even more
-annoying to add new options. To circumvent these problems the configuration
-management was introduced. There all the necessary options are stored into an
-configuration object, which is available nearly everywhere in the translation
-toolchain and in the standard interpreter so that adding new options becomes
+annoying to add new options. To circumvent these problems configuration
+management was introduced. There all the necessary options are stored in a
+configuration object, which is available nearly everywhere in the `RPython
+toolchain`_ and in the standard interpreter so that adding new options becomes
trivial. Options are organized into a tree. Configuration objects can be
created in different ways, there is support for creating an optparse command
line parser automatically.
+_`RPython toolchain`: translation.html
Main Assumption
===============
Configuration objects are produced at the entry points and handed down to
where they are actually used. This keeps configuration local but available
-everywhere and consistent. The configuration values can be created using the
-command line (already implemented) or a file (still to be done).
+everywhere and consistent. The configuration values are created using the
+command line.
API Details
@@ -183,12 +184,12 @@
The usage of config objects in PyPy
===================================
-The two large parts of PyPy, the standard interpreter and the translation
+The two large parts of PyPy, the Python interpreter and the `RPython
+toolchain`_
toolchain, have two separate sets of options. The translation toolchain options
can be found on the ``config`` attribute of all ``TranslationContext``
-instances and are described in translationoption.py_. The interpreter options
+instances and are described in `pypy/config/translationoption.py`_. The interpreter options
are attached to the object space, also under the name ``config`` and are
-described in pypyoption.py_.
+described in `pypy/config/pypyoption.py`_.
-.. _translationoption.py: ../config/translationoption.py
-.. _pypyoption.py: ../config/pypyoption.py
+.. include:: _ref.txt
diff --git a/pypy/doc/jit/index.rst b/pypy/doc/jit/index.rst
--- a/pypy/doc/jit/index.rst
+++ b/pypy/doc/jit/index.rst
@@ -4,7 +4,7 @@
:abstract:
- When PyPy is translated into an executable like ``pypy-c``, the
+ When PyPy is translated into an executable such as ``pypy-c``, the
executable contains a full virtual machine that can optionally
include a Just-In-Time compiler. This JIT compiler is **generated
automatically from the interpreter** that we wrote in RPython.
diff --git a/pypy/doc/config/objspace.timing.rst b/pypy/doc/config/objspace.timing.txt
copy from pypy/doc/config/objspace.timing.rst
copy to pypy/doc/config/objspace.timing.txt
diff --git a/pypy/doc/config/translation.shared.rst b/pypy/doc/config/translation.shared.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.shared.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Build pypy as a shared library or a DLL, with a small executable to run it.
-This is necessary on Windows to expose the C API provided by the cpyext module.
diff --git a/pypy/doc/crufty.rst b/pypy/doc/crufty.txt
copy from pypy/doc/crufty.rst
copy to pypy/doc/crufty.txt
diff --git a/pypy/doc/config/objspace.std.sharesmallstr.rst b/pypy/doc/config/objspace.std.sharesmallstr.txt
copy from pypy/doc/config/objspace.std.sharesmallstr.rst
copy to pypy/doc/config/objspace.std.sharesmallstr.txt
diff --git a/pypy/doc/config/objspace.usemodules.select.rst b/pypy/doc/config/objspace.usemodules.select.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.select.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'select' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/config/objspace.usemodules.select.rst b/pypy/doc/config/objspace.usemodules.select.txt
copy from pypy/doc/config/objspace.usemodules.select.rst
copy to pypy/doc/config/objspace.usemodules.select.txt
diff --git a/pypy/doc/geninterp.rst b/pypy/doc/geninterp.rst
deleted file mode 100644
--- a/pypy/doc/geninterp.rst
+++ /dev/null
@@ -1,192 +0,0 @@
-.. include:: crufty.rst
-
- .. ^^ apparently dead
-
-The Interpreter-Level backend
------------------------------
-
-http://codespeak.net/pypy/trunk/pypy/translator/geninterplevel.py
-
-Motivation
-++++++++++
-
-PyPy often makes use of `application-level`_ helper methods.
-The idea of the 'geninterplevel' backend is to automatically transform
-such application level implementations to their equivalent representation
-at interpreter level. Then, the RPython to C translation hopefully can
-produce more efficient code than always re-interpreting these methods.
-
-One property of translation from application level Python to
-Python is, that the produced code does the same thing as the
-corresponding interpreted code, but no interpreter is needed
-any longer to execute this code.
-
-.. _`application-level`: coding-guide.html#app-preferable
-
-Bootstrap issue
-+++++++++++++++
-
-One issue we had so far was of bootstrapping: some pieces of the
-interpreter (e.g. exceptions) were written in geninterped code.
-It is unclear how much of it is left, thought.
-
-That bootstrap issue is (was?) solved by invoking a new bytecode interpreter
-which runs on FlowObjspace. FlowObjspace is complete without
-complicated initialization. It is able to do abstract interpretation
-of any Rpythonic code, without actually implementing anything. It just
-records all the operations the bytecode interpreter would have done by
-building flowgraphs for all the code. What the Python backend does is
-just to produce correct Python code from these flowgraphs and return
-it as source code. In the produced code Python operations recorded in
-the original flowgraphs are replaced by calls to the corresponding
-methods in the `object space`_ interface.
-
-.. _`object space`: objspace.html
-
-Example
-+++++++
-
-.. _implementation: ../../../../pypy/translator/geninterplevel.py
-
-Let's try a little example. You might want to look at the flowgraph that it
-produces. Here, we directly run the Python translation and look at the
-generated source. See also the header section of the implementation_ for the
-interface::
-
- >>> from pypy.translator.geninterplevel import translate_as_module
- >>> entrypoint, source = translate_as_module("""
- ...
- ... def g(n):
- ... i = 0
- ... while n:
- ... i = i + n
- ... n = n - 1
- ... return i
- ...
- ... """)
-
-This call has invoked a PyPy bytecode interpreter running on FlowObjspace,
-recorded every possible codepath into a flowgraph, and then rendered the
-following source code::
-
- #!/bin/env python
- # -*- coding: LATIN-1 -*-
-
- def initapp2interpexec(space):
- """NOT_RPYTHON"""
-
- def g(space, w_n_1):
- goto = 3 # startblock
- while True:
-
- if goto == 1:
- v0 = space.is_true(w_n)
- if v0 == True:
- goto = 2
- else:
- goto = 4
-
- if goto == 2:
- w_1 = space.add(w_0, w_n)
- w_2 = space.sub(w_n, gi_1)
- w_n, w_0 = w_2, w_1
- goto = 1
- continue
-
- if goto == 3:
- w_n, w_0 = w_n_1, gi_0
- goto = 1
- continue
-
- if goto == 4:
- return w_0
-
- fastf_g = g
-
- g3dict = space.newdict()
- gs___name__ = space.new_interned_str('__name__')
- gs_app2interpexec = space.new_interned_str('app2interpexec')
- space.setitem(g3dict, gs___name__, gs_app2interpexec)
- gs_g = space.new_interned_str('g')
- from pypy.interpreter import gateway
- gfunc_g = space.wrap(gateway.interp2app(fastf_g, unwrap_spec=[gateway.ObjSpace, gateway.W_Root]))
- space.setitem(g3dict, gs_g, gfunc_g)
- gi_1 = space.wrap(1)
- gi_0 = space.wrap(0)
- return g3dict
-
-You see that actually a single function is produced:
-``initapp2interpexec``. This is the function that you will call with a
-space as argument. It defines a few functions and then does a number
-of initialization steps, builds the global objects the function need,
-and produces the PyPy function object ``gfunc_g``.
-
-The return value is ``g3dict``, which contains a module name and the
-function we asked for.
-
-Let's have a look at the body of this code: The definition of ``g`` is
-used as ``fast_g`` in the ``gateway.interp2app`` which constructs a
-PyPy function object which takes care of argument unboxing (based on
-the ``unwrap_spec``), and of invoking the original ``g``.
-
-We look at the definition of ``g`` itself which does the actual
-computation. Comparing to the flowgraph, you see a code block for
-every block in the graph. Since Python has no goto statement, the
-jumps between the blocks are implemented by a loop that switches over
-a ``goto`` variable.
-
-::
-
- . if goto == 1:
- v0 = space.is_true(w_n)
- if v0 == True:
- goto = 2
- else:
- goto = 4
-
-This is the implementation of the "``while n:``". There is no implicit state,
-everything is passed over to the next block by initializing its
-input variables. This directly resembles the nature of flowgraphs.
-They are completely stateless.
-
-
-::
-
- . if goto == 2:
- w_1 = space.add(w_0, w_n)
- w_2 = space.sub(w_n, gi_1)
- w_n, w_0 = w_2, w_1
- goto = 1
- continue
-
-The "``i = i + n``" and "``n = n - 1``" instructions.
-You see how every instruction produces a new variable.
-The state is again shuffled around by assigning to the
-input variables ``w_n`` and ``w_0`` of the next target, block 1.
-
-Note that it is possible to rewrite this by re-using variables,
-trying to produce nested blocks instead of the goto construction
-and much more. The source would look much more like what we
-used to write by hand. For the C backend, this doesn't make much
-sense since the compiler optimizes it for us. For the Python interpreter it could
-give a bit more speed. But this is a temporary format and will
-get optimized anyway when we produce the executable.
-
-Interplevel Snippets in the Sources
-+++++++++++++++++++++++++++++++++++
-
-Code written in application space can consist of complete files
-to be translated, or they
-can be tiny snippets scattered all over a source file, similar
-to our example from above.
-
-Translation of these snippets is done automatically and cached
-in pypy/_cache with the modulename and the md5 checksum appended
-to it as file name. If you have run your copy of pypy already,
-this folder should exist and have some generated files in it.
-These files consist of the generated code plus a little code
-that auto-destructs the cached file (plus .pyc/.pyo versions)
-if it is executed as __main__. On windows this means you can wipe
-a cached code snippet clear by double-clicking it. Note also that
-the auto-generated __init__.py file wipes the whole directory
-when executed.
diff --git a/pypy/doc/config/objspace.usemodules._md5.rst b/pypy/doc/config/objspace.usemodules._md5.txt
copy from pypy/doc/config/objspace.usemodules._md5.rst
copy to pypy/doc/config/objspace.usemodules._md5.txt
diff --git a/pypy/doc/config/translation.platform.rst b/pypy/doc/config/translation.platform.txt
copy from pypy/doc/config/translation.platform.rst
copy to pypy/doc/config/translation.platform.txt
diff --git a/pypy/doc/config/objspace.std.withmapdict.rst b/pypy/doc/config/objspace.std.withmapdict.txt
copy from pypy/doc/config/objspace.std.withmapdict.rst
copy to pypy/doc/config/objspace.std.withmapdict.txt
diff --git a/pypy/doc/config/objspace.std.methodcachesizeexp.rst b/pypy/doc/config/objspace.std.methodcachesizeexp.txt
copy from pypy/doc/config/objspace.std.methodcachesizeexp.rst
copy to pypy/doc/config/objspace.std.methodcachesizeexp.txt
diff --git a/pypy/doc/discussion/somepbc-refactoring-plan.rst b/pypy/doc/discussion/somepbc-refactoring-plan.rst
deleted file mode 100644
--- a/pypy/doc/discussion/somepbc-refactoring-plan.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-==========================
- Refactoring SomePBCs
-==========================
-
-Motivation
-==========
-
-Some parts of the annotator, and especially specialization, are quite obscure
-and hackish. One cause for this is the need to manipulate Python objects like
-functions directly. This makes it hard to attach additional information directly
-to the objects. It makes specialization messy because it has to create new dummy
-function objects just to represent the various specialized versions of the function.
-
-
-Plan
-====
-
-Let's introduce nice wrapper objects. This refactoring is oriented towards
-the following goal: replacing the content of SomePBC() with a plain set of
-"description" wrapper objects. We shall probably also remove the possibility
-for None to explicitly be in the set and add a can_be_None flag (this is
-closer to what the other SomeXxx classes do).
-
-
-XxxDesc classes
-===============
-
-To be declared in module pypy.annotator.desc, with a mapping
-annotator.bookkeeper.descs = {<python object>: <XxxDesc instance>}
-accessed with bookkeeper.getdesc(<python object>).
-
-Maybe later the module should be moved out of pypy.annotation but for now I
-suppose that it's the best place.
-
-The goal is to have a single Desc wrapper even for functions and classes that
-are specialized.
-
-FunctionDesc
-
- Describes (usually) a Python function object. Contains flow graphs: one
- in the common case, zero for external functions, more than one if there
- are several specialized versions. Also describes the signature of the
- function in a nice format (i.e. not by relying on func_code inspection).
-
-ClassDesc
-
- Describes a Python class object. Generally just maps to a ClassDef, but
- could map to more than one in the presence of specialization. So we get
- SomePBC({<ClassDesc>}) annotations for the class, and when it's
- instantiated it becomes SomeInstance(classdef=...) for the particular
- selected classdef.
-
-MethodDesc
-
- Describes a bound method. Just references a FunctionDesc and a ClassDef
- (not a ClassDesc, because it's read out of a SomeInstance).
-
-FrozenDesc
-
- Describes a frozen pre-built instance. That's also a good place to store
- some information currently in dictionaries of the bookkeeper.
-
-MethodOfFrozenDesc
-
- Describes a method of a FrozenDesc. Just references a FunctionDesc and a
- FrozenDesc.
-
-NB: unbound method objects are the same as function for our purposes, so they
-become the same FunctionDesc as their im_func.
-
-These XxxDesc classes should share some common interface, as we'll see during
-the refactoring. A common base class might be a good idea (at least I don't
-see why it would be a bad idea :-)
-
-
-Implementation plan
-===================
-
-* make a branch (/branch/somepbc-refactoring/)
-
-* change the definition of SomePBC, start pypy.annotation.desc
-
-* fix all places that use SomePBC :-)
-
-* turn Translator.flowgraphs into a plain list of flow graphs,
- and make the FunctionDescs responsible for computing their own flow graphs
-
-* move external function functionality into the FunctionDescs too
-
-
-Status
-======
-
-Done, branch merged.
-
-
-RTyping PBCs of functions
-=========================
-
-The FuncDesc.specialize() method takes an args_s and return a
-corresponding graph. The caller of specialize() parses the actual
-arguments provided by the simple_call or call_args operation, so that
-args_s is a flat parsed list. The returned graph must have the same
-number and order of input variables.
-
-For each call family, we compute a table like this (after annotation
-finished)::
-
- call_shape FuncDesc1 FuncDesc2 FuncDesc3 ...
- ----------------------------------------------------------
- call0 shape1 graph1
- call1 shape1 graph1 graph2
- call2 shape1 graph3 graph4
- call3 shape2 graph5 graph6
-
-
-We then need to merge some of the lines if they look similar enough,
-e.g. call0 and call1. Precisely, we can merge two lines if they only
-differ in having more or less holes. In theory, the same graph could
-appear in two lines that are still not mergeable because of other
-graphs. For sanity of implementation, we should check that at the end
-each graph only appears once in the table (unless there is only one
-*column*, in which case all problems can be dealt with at call sites).
-
-(Note that before this refactoring, the code was essentially requiring
-that the table ended up with either one single row or one single
-column.)
-
-The table is computed when the annotation is complete, in
-compute_at_fixpoint(), which calls the FuncDesc's consider_call_site()
-for each call site. The latter merges lines as soon as possible. The
-table is attached to the call family, grouped by call shape.
-
-During RTyping, compute_at_fixpoint() is called after each new ll
-helper is annotated. Normally, this should not modify existing tables
-too much, but in some situations it will. So the rule is that
-consider_call_site() should not add new (unmerged) rows to the table
-after the table is considered "finished" (again, unless there is only
-one column, in which case we should not discover new columns).
-
-XXX this is now out of date, in the details at least.
-
-RTyping other callable PBCs
-===========================
-
-The above picture attaches "calltable" information to the call
-families containing the function. When it comes to rtyping a call of
-another kind of pbc (class, instance-method, frozenpbc-method) we have
-two basic choices:
-
- - associate the calltable information with the funcdesc that
- ultimately ends up getting called, or
-
- - attach the calltable to the callfamily that contains the desc
- that's actually being called.
-
-Neither is totally straightforward: the former is closer to what
-happens on the trunk but new families of funcdescs need to be created
-at the end of annotation or by normalisation. The latter is more of a
-change. The former is also perhaps a bit unnatural for ootyped
-backends.
diff --git a/pypy/doc/config/translation.backendopt.constfold.rst b/pypy/doc/config/translation.backendopt.constfold.txt
copy from pypy/doc/config/translation.backendopt.constfold.rst
copy to pypy/doc/config/translation.backendopt.constfold.txt
diff --git a/pypy/doc/eventhistory.rst b/pypy/doc/eventhistory.rst
--- a/pypy/doc/eventhistory.rst
+++ b/pypy/doc/eventhistory.rst
@@ -54,7 +54,7 @@
backends. For more details, read the last `sprint status`_ page and
enjoy the pictures_.
-.. _`sprint status`: http://codespeak.net/pypy/extradoc/sprintinfo/tokyo/tokyo-planning.html
+.. _`sprint status`: https://bitbucket.org/pypy/extradoc/src/tip/sprintinfo/tokyo/tokyo-planning.txt
.. _`pictures`: http://www.flickr.com/photos/19046555@N00/sets/72057594116388174/
PyPy at Python UK/ACCU Conference (United Kingdom)
@@ -63,12 +63,12 @@
*April 19th - April 22nd 2006.* Several talks about PyPy were hold at
this year's Python UK/ACCU conference. Read more at the `ACCU site`_.
-.. _`ACCU site`: http://www.accu.org/
+.. _`ACCU site`: http://accu.org/
PyPy at XPDay France 2006 in Paris March 23rd - March 24th 2006
==================================================================
-Logilab presented PyPy at the first `french XP Day`_ that it was
+Logilab presented PyPy at the first french XP Day that it was
sponsoring and which was held in Paris. There was over a hundred
attendants. Interesting talks included Python as an agile language and
Tools for continuous integration.
@@ -99,7 +99,7 @@
Talks at PyCon 2006 (Dallas, Texas, USA)
===================================================================
-*Feb 24th - Feb 26th 2006.* PyPy developers spoke at `PyCon 2006`_.
+*Feb 24th - Feb 26th 2006.* PyPy developers spoke at PyCon 2006.
.. _`PyCon 2006`: http://us.pycon.org/TX2006/HomePage
@@ -247,7 +247,7 @@
.. _`breakthrough`: http://codespeak.net/~hpk/hildesheim2-sprint-www/hildesheim2-sprint-www-Thumbnails/36.jpg
.. _`hurray`: http://codespeak.net/~hpk/hildesheim2-sprint-www/hildesheim2-sprint-www-Pages/Image37.html
.. _`pictures from the sprint`: http://codespeak.net/~hpk/hildesheim2-sprint-www/
-.. _`Trillke-Gut`: http://www.trillke.net/images/HomePagePictureSmall.jpg
+.. _`Trillke-Gut`: http://www.trillke.net
EuroPython 2005 sprints finished
======================================================
@@ -310,6 +310,6 @@
Read more in `EuroPython sprint announcement`_, see who is planning to attend
on `the people page`_. There is also a page_ in the python wiki.
-.. _`EuroPython sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/europython-2006/announce.html
-.. _`the people page`: http://codespeak.net/pypy/extradoc/sprintinfo/europython-2006/people.html
+.. _`EuroPython sprint announcement`: https://bitbucket.org/pypy/extradoc/src/tip/sprintinfo/post-ep2006/announce.txt
+.. _`the people page`: https://bitbucket.org/pypy/extradoc/src/tip/sprintinfo/post-ep2006/people.txt
.. _page: http://wiki.python.org/moin/EuroPython2006
diff --git a/pypy/doc/discussion/testing-zope.rst b/pypy/doc/discussion/testing-zope.rst
deleted file mode 100644
--- a/pypy/doc/discussion/testing-zope.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-Testing Zope on top of pypy-c
-=============================
-
-Getting Zope packages
----------------------
-
-If you don't have a full Zope installation, you can pick a Zope package,
-check it out via Subversion, and get all its dependencies (replace
-``$PKG`` with, for example, ``zope.interface``)::
-
- svn co svn://svn.zope.org/repos/main/$PKG/trunk $PKG
- cd $PKG
- python bootstrap.py
- bin/buildout
- bin/test
-
-Required pypy-c version
------------------------
-
-You probably need a pypy-c built with --allworkingmodules, at least::
-
- cd pypy/translator/goal
- ./translate.py targetpypystandalone.py --allworkingmodules
-
-Workarounds
------------
-
-At the moment, our ``gc`` module is incomplete, making the Zope test
-runner unhappy. Quick workaround: go to the
-``lib-python/modified-2.4.1`` directory and create a
-``sitecustomize.py`` with the following content::
-
- print "<adding dummy stuff into the gc module>"
- import gc
- gc.get_threshold = lambda : (0, 0, 0)
- gc.get_debug = lambda : 0
- gc.garbage = []
-
-Running the tests
------------------
-
-To run the tests we need the --oldstyle option, as follows::
-
- cd $PKG
- pypy-c --oldstyle bin/test
diff --git a/pypy/doc/config/translation.gcremovetypeptr.rst b/pypy/doc/config/translation.gcremovetypeptr.txt
copy from pypy/doc/config/translation.gcremovetypeptr.rst
copy to pypy/doc/config/translation.gcremovetypeptr.txt
diff --git a/pypy/doc/config/objspace.std.withrangelist.rst b/pypy/doc/config/objspace.std.withrangelist.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withrangelist.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-Enable "range list" objects. They are an additional implementation of the Python
-``list`` type, indistinguishable for the normal user. Whenever the ``range``
-builtin is called, an range list is returned. As long as this list is not
-mutated (and for example only iterated over), it uses only enough memory to
-store the start, stop and step of the range. This makes using ``range`` as
-efficient as ``xrange``, as long as the result is only used in a ``for``-loop.
-
-See the section in `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#range-lists
-
diff --git a/pypy/doc/config/translation.gcrootfinder.rst b/pypy/doc/config/translation.gcrootfinder.txt
copy from pypy/doc/config/translation.gcrootfinder.rst
copy to pypy/doc/config/translation.gcrootfinder.txt
--- a/pypy/doc/config/translation.gcrootfinder.rst
+++ b/pypy/doc/config/translation.gcrootfinder.txt
@@ -1,15 +1,16 @@
-Choose method how to find roots in the GC. Boehm and refcounting have their own
-methods, this is mostly only interesting for framework GCs. For those you have
-a choice of various alternatives:
+Choose the method used to find the roots in the GC. This only
+applies to our framework GCs. You have a choice of two
+alternatives:
- - use a shadow stack (XXX link to paper), e.g. explicitly maintaining a stack
- of roots
+- ``--gcrootfinder=shadowstack``: use a so-called "shadow
+ stack", which is an explicitly maintained custom stack of
+ root pointers. This is the most portable solution.
- - use stackless to find roots by unwinding the stack. Requires
- :config:`translation.stackless`. Note that this turned out to
- be slower than just using a shadow stack.
+- ``--gcrootfinder=asmgcc``: use assembler hackery to find the
+ roots directly from the normal stack. This is a bit faster,
+ but platform specific. It works so far with GCC or MSVC,
+ on i386 and x86-64.
- - use GCC and i386 specific assembler hackery to find the roots on the stack.
- This is fastest but platform specific.
-
- - Use LLVM's GC facilities to find the roots.
+You may have to force the use of the shadowstack root finder if
+you are running into troubles or if you insist on translating
+PyPy with other compilers like clang.
diff --git a/pypy/doc/config/translation.force_make.rst b/pypy/doc/config/translation.force_make.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.force_make.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Force executing makefile instead of using platform.
diff --git a/pypy/doc/config/objspace.std.withrangelist.rst b/pypy/doc/config/objspace.std.withrangelist.txt
copy from pypy/doc/config/objspace.std.withrangelist.rst
copy to pypy/doc/config/objspace.std.withrangelist.txt
diff --git a/pypy/doc/discussion/chained_getattr.rst b/pypy/doc/discussion/chained_getattr.rst
deleted file mode 100644
--- a/pypy/doc/discussion/chained_getattr.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-
-
-"chained getattr/module global lookup" optimization
-(discussion during trillke-sprint 2007, anto/holger,
-a bit of samuele and cf earlier on)
-
-random example:
-
- code:
- import os.path
- normed = [os.path.normpath(p) for p in somelist]
- bytecode:
- [...]
- LOAD_GLOBAL (os)
- LOAD_ATTR (path)
- LOAD_ATTR (normpath)
- LOAD_FAST (p)
- CALL_FUNCTION 1
-
- would be turned by pypy-compiler into:
-
- LOAD_CHAINED_GLOBAL (os,path,normpath)
- LOAD_FAST (p)
- CALL_FUNCTION 1
-
- now for the LOAD_CHAINED_GLOBAL bytecode implementation:
-
- Module dicts have a special implementation, providing:
-
- - an extra "fastlookup" rpython-dict serving as a cache for
- LOAD_CHAINED_GLOBAL places within the modules:
-
- * keys are e.g. ('os', 'path', 'normpath')
-
- * values are tuples of the form:
- ([obj1, obj2, obj3], [ver1, ver2])
-
- "ver1" refer to the version of the globals of "os"
- "ver2" refer to the version of the globals of "os.path"
- "obj3" is the resulting "normpath" function
-
- - upon changes to the global dict, "fastlookup.clear()" is called
-
- - after the fastlookup entry is filled for a given
- LOAD_CHAINED_GLOBAL index, the following checks need
- to be performed in the bytecode implementation::
-
- value = f_globals.fastlookup.get(key, None)
- if value is None:
- # fill entry
- else:
- # check that our cached lookups are still valid
- assert isinstance(value, tuple)
- objects, versions = value
- i = 0
- while i < len(versions):
- lastversion = versions[i]
- ver = getver_for_obj(objects[i])
- if ver == -1 or ver != lastversion:
- name = key[i]
- objects[i] = space.getattr(curobj, name)
- versions[i] = ver
- curobj = objects[i]
- i += 1
- return objects[i]
-
- def getver_for_obj(obj):
- if "obj is not Module":
- return -1
- return obj.w_dict.version
diff --git a/pypy/doc/config/objspace.soabi.rst b/pypy/doc/config/objspace.soabi.txt
copy from pypy/doc/config/objspace.soabi.rst
copy to pypy/doc/config/objspace.soabi.txt
diff --git a/pypy/doc/config/objspace.std.newshortcut.rst b/pypy/doc/config/objspace.std.newshortcut.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.newshortcut.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Performance only: cache and shortcut calling __new__ from builtin types
diff --git a/pypy/doc/rtyper.rst b/pypy/doc/rtyper.rst
--- a/pypy/doc/rtyper.rst
+++ b/pypy/doc/rtyper.rst
@@ -66,7 +66,7 @@
each operation. In both cases the analysis of an operation depends on the
annotations of its input arguments. This is reflected in the usage of the same
``__extend__`` syntax in the source files (compare e.g.
-`annotation/binaryop.py`_ and `rpython/rint.py`_).
+`pypy/annotation/binaryop.py`_ and `pypy/rpython/rint.py`_).
The analogy stops here, though: while it runs, the Annotator is in the middle
of computing the annotations, so it might need to reflow and generalize until
@@ -104,7 +104,7 @@
implementations for the same high-level operations. This is the reason for
turning representations into explicit objects.
-The base Repr class is defined in `rpython/rmodel.py`_. Most of the
+The base Repr class is defined in `pypy/rpython/rmodel.py`_. Most of the
``rpython/r*.py`` files define one or a few subclasses of Repr. The method
getrepr() of the RTyper will build and cache a single Repr instance per
SomeXxx() instance; moreover, two SomeXxx() instances that are equal get the
@@ -131,9 +131,9 @@
The RPython Typer uses a standard low-level model which we believe can
correspond rather directly to various target languages such as C.
This model is implemented in the first part of
-`rpython/lltypesystem/lltype.py`_.
+`pypy/rpython/lltypesystem/lltype.py`_.
-The second part of `rpython/lltypesystem/lltype.py`_ is a runnable
+The second part of `pypy/rpython/lltypesystem/lltype.py`_ is a runnable
implementation of these types, for testing purposes. It allows us to write
and test plain Python code using a malloc() function to obtain and manipulate
structures and arrays. This is useful for example to implement and test
@@ -191,7 +191,7 @@
types like list in this elementary world. The ``malloc()`` function is a kind
of placeholder, which must eventually be provided by the code generator for the
target platform; but as we have just seen its Python implementation in
-`rpython/lltypesystem/lltype.py`_ works too, which is primarily useful for
+`pypy/rpython/lltypesystem/lltype.py`_ works too, which is primarily useful for
testing, interactive exploring, etc.
The argument to ``malloc()`` is the structure type directly, but it returns a
@@ -316,7 +316,7 @@
with care: the bigger structure of which they are part of could be freed while
the Ptr to the substructure is still in use. In general, it is a good idea to
avoid passing around pointers to inlined substructures of malloc()ed structures.
-(The testing implementation of `rpython/lltypesystem/lltype.py`_ checks to some
+(The testing implementation of `pypy/rpython/lltypesystem/lltype.py`_ checks to some
extent that you are not trying to use a pointer to a structure after its
container has been freed, using weak references. But pointers to non-GC
structures are not officially meant to be weak references: using them after what
@@ -429,7 +429,7 @@
change needed to the Annotator to allow it to perform type inference of our
very-low-level snippets of code.
-See for example `rpython/rlist.py`_.
+See for example `pypy/rpython/rlist.py`_.
.. _`oo type`:
@@ -441,10 +441,10 @@
targeting low level backends such as C, but it is not good
enough for targeting higher level backends such as .NET CLI or Java
JVM, so a new object oriented model has been introduced. This model is
-implemented in the first part of `rpython/ootypesystem/ootype.py`_.
+implemented in the first part of `pypy/rpython/ootypesystem/ootype.py`_.
As for the low-level typesystem, the second part of
-`rpython/ootypesystem/ootype.py`_ is a runnable implementation of
+`pypy/rpython/ootypesystem/ootype.py`_ is a runnable implementation of
these types, for testing purposes.
@@ -791,4 +791,5 @@
assert res == ~3
.. _annotator: translation.html#the-annotation-pass
-.. include:: _ref.rst
+
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.std.optimized_list_getitem.rst b/pypy/doc/config/objspace.std.optimized_list_getitem.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.optimized_list_getitem.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Optimized list[int] a bit.
diff --git a/pypy/doc/config/objspace.std.prebuiltintto.rst b/pypy/doc/config/objspace.std.prebuiltintto.txt
copy from pypy/doc/config/objspace.std.prebuiltintto.rst
copy to pypy/doc/config/objspace.std.prebuiltintto.txt
diff --git a/pypy/doc/config/objspace.usemodules.parser.rst b/pypy/doc/config/objspace.usemodules.parser.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.parser.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the 'parser' module.
-This is PyPy implementation of the standard library 'parser' module (e.g. if
-this option is enabled and you say ``import parser`` you get this module).
-It is enabled by default.
diff --git a/pypy/doc/config/objspace.disable_call_speedhacks.rst b/pypy/doc/config/objspace.disable_call_speedhacks.txt
copy from pypy/doc/config/objspace.disable_call_speedhacks.rst
copy to pypy/doc/config/objspace.disable_call_speedhacks.txt
diff --git a/pypy/doc/carbonpython.rst b/pypy/doc/carbonpython.rst
deleted file mode 100644
--- a/pypy/doc/carbonpython.rst
+++ /dev/null
@@ -1,230 +0,0 @@
-==================================================
-CarbonPython, aka C# considered harmful
-==================================================
-
-CarbonPython overview
-=====================
-
-CarbonPython is an experimental RPython to .NET compiler. Its main
-focus is to produce DLLs to be used by other .NET programs, not
-standalone executables; if you want to compile an RPython standalone
-program, have a look to `translate.py`_.
-
-Compiled RPython programs are much faster (up to 250x) than
-interpreted IronPython programs, hence it might be a convenient
-replacement for C# when more speed is needed. RPython programs can be
-as fast as C# programs.
-
-RPython is a restrict subset of Python, static enough to be analyzed
-and compiled efficiently to lower level languages. To read more about
-the RPython limitations read the `RPython description`_.
-
-**Disclaimer**: RPython is a much less convenient language than Python
-to program with. If you do not need speed, there is no reason to look
-at RPython.
-
-**Big disclaimer**: CarbonPython is still in a pre-alpha stage: it's
-not meant to be used for production code, and the API might change in
-the future. Despite this, it might be useful in some situations and
-you are encouraged to try it by yourself. Suggestions, bug-reports and
-even better patches are welcome.
-
-.. _`RPython description`: coding-guide.html#restricted-python
-.. _`translate.py`: faq.html#how-do-i-compile-my-own-interpreters
-
-
-Quick start
-===========
-
-Suppose you want to write a little DLL in RPython and call its
-function from C#.
-
-Here is the file mylibrary.py::
-
- from pypy.translator.cli.carbonpython import export
-
- @export(int, int)
- def add(x, y):
- return x+y
-
- @export(int, int)
- def sub(x, y):
- return x-y
-
-
-And here the C# program main.cs::
-
- using System;
- public class CarbonPythonTest
- {
- public static void Main()
- {
- Console.WriteLine(mylibrary.add(40, 2));
- Console.WriteLine(mylibrary.sub(44, 2));
- }
- }
-
-Once the files have been created, you can compile ``mylibrary.py``
-with CarbonPython to get the corresponding DLL::
-
- $ python carbonpython.py mylibrary.py
- ... lot of stuff
-
-Then, we compile main.cs into an executable, being sure to add a
-reference to the newly created ``mylibrary.dll``::
-
- # with mono on linux
- $ gmcs /r:mylibrary.dll main.cs
-
- # with Microsoft CLR on windows
- c:\> csc /r:mylibrary main.cs
-
-Now we can run the executable to see whether the answers are right::
-
- $ mono main.exe
- 42
- 42
-
-
-Multiple entry-points
-=====================
-
-In RPython, the type of each variable is inferred by the `Annotator`_:
-the annotator analyzed the whole program top-down starting from an
-entry-point, i.e. a function whose we specified the types of the
-parameters.
-
-This approach works for a standalone executables, but not for a
-library that by definition is composed by more than one
-entry-point. Thus, you need to explicitly specify which functions you
-want to include in your DLL, together with the expected input types.
-
-To mark a function as an entry-point, you use the ``@export``
-decorator, which is defined in ``pypy.translator.cli.carbonpython``,
-as shown by the previous example. Note that you do not need to
-specify the return type, because it is automatically inferenced by the
-annotator.
-
-.. _`Annotator`: translation.html#annotator
-
-
-Namespaces
-==========
-
-Since `CLS`_ (Common Language Specification) does not support module
-level static methods, RPython functions marked as entry-points are
-compiled to static methods of a class, in order to be accessible by
-every CLS-compliant language such as C# or VB.NET.
-
-The class which each function is placed in depends on its
-**namespace**; for example, if the namespace of a function ``foo`` is
-``A.B.C``, the function will be rendered as a static method of the
-``C`` class inside the ``A.B`` namespace. This allows C# and
-IronPython code to call the function using the intuitive ``A.B.C.foo``
-syntax.
-
-By default, the default namespace for exported function is the same as
-the name of the module. Thus in the previous example the default
-namespace is ``mylibrary`` and the functions are placed inside the
-corresponding class in the global namespace.
-
-You can change the default namespace by setting the ``_namespace_``
-variable in the module you are compiling::
-
- _namespace_ = 'Foo.Bar'
-
- @export(int, int)
- def f(x, y):
- pass
-
-Finally, you can also set a specific namespace on a per-function
-basis, using the appropriate keyword argument of the ``@export``
-decorator::
-
- @export(int, int, namespace='Foo.Bar')
- def f(x, y):
- pass
-
-
-.. _`CLS`: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf
-
-
-Exporting classes
-=================
-
-RPython libraries can also export classes: to export a class, add the
-``@export`` decorator to its ``__init__`` method; similarly, you can
-also export any methods of the class::
-
- class MyClass:
-
- @export(int)
- def __init__(self, x):
- self.x = x
-
- @export
- def getx(self):
- return self.x
-
-
-Note that the type of ``self`` must not be specified: it will
-automatically assumed to be ``MyClass``.
-
-The ``__init__`` method is not automatically mapped to the .NET
-constructor; to properly initialize an RPython object from C# or
-IronPython code you need to explicitly call ``__init__``; for example,
-in C#::
-
- MyClass obj = new MyClass();
- obj.__init__(x);
-
-Note that this is needed only when calling RPython code from
-outside; the RPython compiler automatically calls ``__init__``
-whenever an RPython class is instantiated.
-
-In the future this discrepancy will be fixed and the ``__init__``
-method will be automatically mapped to the constructor.
-
-
-Accessing .NET libraries
-========================
-
-**Warning**: the API for accessing .NET classes from RPython is highly
-experimental and will probably change in the future.
-
-In RPython you can access native .NET classes through the ``CLR``
-object defined in ``translator.cli.dotnet``: from there, you can
-navigate through namespaces using the usual dot notation; for example,
-``CLR.System.Collections.ArrayList`` refers to the ``ArrayList`` class
-in the ``System.Collections`` namespace.
-
-To instantiate a .NET class, simply call it::
-
- ArrayList = CLR.System.Collections.ArrayList
- def foo():
- obj = ArrayList()
- obj.Add(42)
- return obj
-
-At the moment there is no special syntax support for indexers and
-properties: for example, you can't access ArrayList's elements using
-the square bracket notation, but you have to call the call the
-``get_Item`` and ``set_Item`` methods; similarly, to access a property
-``XXX`` you need to call ``get_XXX`` and ``set_XXX``::
-
- def foo():
- obj = ArrayList()
- obj.Add(42)
- print obj.get_Item(0)
- print obj.get_Count()
-
-Static methods and are also supported, as well as overloadings::
-
- Math = CLR.System.Math
- def foo():
- print Math.Abs(-42)
- print Math.Abs(-42.0)
-
-
-At the moment, it is not possible to reference assemblies other than
-mscorlib. This will be fixed soon.
diff --git a/pypy/doc/config/translation.jit_profiler.rst b/pypy/doc/config/translation.jit_profiler.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.jit_profiler.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Integrate profiler support into the JIT
diff --git a/pypy/doc/config/translation.rst b/pypy/doc/config/translation.txt
copy from pypy/doc/config/translation.rst
copy to pypy/doc/config/translation.txt
diff --git a/pypy/doc/config/objspace.std.withcelldict.rst b/pypy/doc/config/objspace.std.withcelldict.txt
copy from pypy/doc/config/objspace.std.withcelldict.rst
copy to pypy/doc/config/objspace.std.withcelldict.txt
diff --git a/pypy/doc/config/objspace.usemodules.signal.rst b/pypy/doc/config/objspace.usemodules.signal.txt
copy from pypy/doc/config/objspace.usemodules.signal.rst
copy to pypy/doc/config/objspace.usemodules.signal.txt
diff --git a/pypy/doc/objspace-proxies.rst b/pypy/doc/objspace-proxies.rst
--- a/pypy/doc/objspace-proxies.rst
+++ b/pypy/doc/objspace-proxies.rst
@@ -11,17 +11,13 @@
behavior of all objects in a running program is easy to implement on
top of PyPy.
-Here is what we implemented so far, in historical order:
+Here is what we have implemented so far, in historical order:
* *Thunk Object Space*: lazily computed objects, computing only when an
operation is performed on them; lazy functions, computing their result
only if and when needed; and a way to globally replace an object with
another.
-* *Taint Object Space*: a soft security system; your application cannot
- accidentally compute results based on tainted objects unless it
- explicitly untaints them first.
-
* *Dump Object Space*: dumps all operations performed on all the objects
into a large log file. For debugging your applications.
@@ -133,293 +129,295 @@
function behaves lazily: all calls to it return a thunk object.
-.. _taint:
+.. broken right now:
-The Taint Object Space
-======================
+ .. _taint:
-Motivation
-----------
+ The Taint Object Space
+ ======================
-The Taint Object Space provides a form of security: "tainted objects",
-inspired by various sources, see [D12.1]_ for a more detailed discussion.
+ Motivation
+ ----------
-The basic idea of this kind of security is not to protect against
-malicious code but to help with handling and boxing sensitive data.
-It covers two kinds of sensitive data: secret data which should not leak,
-and untrusted data coming from an external source and that must be
-validated before it is used.
+ The Taint Object Space provides a form of security: "tainted objects",
+ inspired by various sources, see [D12.1]_ for a more detailed discussion.
-The idea is that, considering a large application that handles these
-kinds of sensitive data, there are typically only a small number of
-places that need to explicitly manipulate that sensitive data; all the
-other places merely pass it around, or do entirely unrelated things.
+ The basic idea of this kind of security is not to protect against
+ malicious code but to help with handling and boxing sensitive data.
+ It covers two kinds of sensitive data: secret data which should not leak,
+ and untrusted data coming from an external source and that must be
+ validated before it is used.
-Nevertheless, if a large application needs to be reviewed for security,
-it must be entirely carefully checked, because it is possible that a
-bug at some apparently unrelated place could lead to a leak of sensitive
-information in a way that an external attacker could exploit. For
-example, if any part of the application provides web services, an
-attacker might be able to issue unexpected requests with a regular web
-browser and deduce secret information from the details of the answers he
-gets. Another example is the common CGI attack where an attacker sends
-malformed inputs and causes the CGI script to do unintended things.
+ The idea is that, considering a large application that handles these
+ kinds of sensitive data, there are typically only a small number of
+ places that need to explicitly manipulate that sensitive data; all the
+ other places merely pass it around, or do entirely unrelated things.
-An approach like that of the Taint Object Space allows the small parts
-of the program that manipulate sensitive data to be explicitly marked.
-The effect of this is that although these small parts still need a
-careful security review, the rest of the application no longer does,
-because even a bug would be unable to leak the information.
+ Nevertheless, if a large application needs to be reviewed for security,
+ it must be entirely carefully checked, because it is possible that a
+ bug at some apparently unrelated place could lead to a leak of sensitive
+ information in a way that an external attacker could exploit. For
+ example, if any part of the application provides web services, an
+ attacker might be able to issue unexpected requests with a regular web
+ browser and deduce secret information from the details of the answers he
+ gets. Another example is the common CGI attack where an attacker sends
+ malformed inputs and causes the CGI script to do unintended things.
-We have implemented a simple two-level model: objects are either
-regular (untainted), or sensitive (tainted). Objects are marked as
-sensitive if they are secret or untrusted, and only declassified at
-carefully-checked positions (e.g. where the secret data is needed, or
-after the untrusted data has been fully validated).
+ An approach like that of the Taint Object Space allows the small parts
+ of the program that manipulate sensitive data to be explicitly marked.
+ The effect of this is that although these small parts still need a
+ careful security review, the rest of the application no longer does,
+ because even a bug would be unable to leak the information.
-It would be simple to extend the code for more fine-grained scales of
-secrecy. For example it is typical in the literature to consider
-user-specified lattices of secrecy levels, corresponding to multiple
-"owners" that cannot access data belonging to another "owner" unless
-explicitly authorized to do so.
+ We have implemented a simple two-level model: objects are either
+ regular (untainted), or sensitive (tainted). Objects are marked as
+ sensitive if they are secret or untrusted, and only declassified at
+ carefully-checked positions (e.g. where the secret data is needed, or
+ after the untrusted data has been fully validated).
-Tainting and untainting
------------------------
+ It would be simple to extend the code for more fine-grained scales of
+ secrecy. For example it is typical in the literature to consider
+ user-specified lattices of secrecy levels, corresponding to multiple
+ "owners" that cannot access data belonging to another "owner" unless
+ explicitly authorized to do so.
-Start a py.py with the Taint Object Space and try the following example::
+ Tainting and untainting
+ -----------------------
- $ py.py -o taint
- >>>> from __pypy__ import taint
- >>>> x = taint(6)
+ Start a py.py with the Taint Object Space and try the following example::
- # x is hidden from now on. We can pass it around and
- # even operate on it, but not inspect it. Taintness
- # is propagated to operation results.
+ $ py.py -o taint
+ >>>> from __pypy__ import taint
+ >>>> x = taint(6)
- >>>> x
- TaintError
+ # x is hidden from now on. We can pass it around and
+ # even operate on it, but not inspect it. Taintness
+ # is propagated to operation results.
- >>>> if x > 5: y = 2 # see below
- TaintError
+ >>>> x
+ TaintError
- >>>> y = x + 5 # ok
- >>>> lst = [x, y]
- >>>> z = lst.pop()
- >>>> t = type(z) # type() works too, tainted answer
- >>>> t
- TaintError
- >>>> u = t is int # even 'is' works
- >>>> u
- TaintError
+ >>>> if x > 5: y = 2 # see below
+ TaintError
-Notice that using a tainted boolean like ``x > 5`` in an ``if``
-statement is forbidden. This is because knowing which path is followed
-would give away a hint about ``x``; in the example above, if the
-statement ``if x > 5: y = 2`` was allowed to run, we would know
-something about the value of ``x`` by looking at the (untainted) value
-in the variable ``y``.
+ >>>> y = x + 5 # ok
+ >>>> lst = [x, y]
+ >>>> z = lst.pop()
+ >>>> t = type(z) # type() works too, tainted answer
+ >>>> t
+ TaintError
+ >>>> u = t is int # even 'is' works
+ >>>> u
+ TaintError
-Of course, there is a way to inspect tainted objects. The basic way is
-to explicitly "declassify" it with the ``untaint()`` function. In an
-application, the places that use ``untaint()`` are the places that need
-careful security review. To avoid unexpected objects showing up, the
-``untaint()`` function must be called with the exact type of the object
-to declassify. It will raise ``TaintError`` if the type doesn't match::
+ Notice that using a tainted boolean like ``x > 5`` in an ``if``
+ statement is forbidden. This is because knowing which path is followed
+ would give away a hint about ``x``; in the example above, if the
+ statement ``if x > 5: y = 2`` was allowed to run, we would know
+ something about the value of ``x`` by looking at the (untainted) value
+ in the variable ``y``.
- >>>> from __pypy__ import taint
- >>>> untaint(int, x)
- 6
- >>>> untaint(int, z)
- 11
- >>>> untaint(bool, x > 5)
- True
- >>>> untaint(int, x > 5)
- TaintError
+ Of course, there is a way to inspect tainted objects. The basic way is
+ to explicitly "declassify" it with the ``untaint()`` function. In an
+ application, the places that use ``untaint()`` are the places that need
+ careful security review. To avoid unexpected objects showing up, the
+ ``untaint()`` function must be called with the exact type of the object
+ to declassify. It will raise ``TaintError`` if the type doesn't match::
+ >>>> from __pypy__ import taint
+ >>>> untaint(int, x)
+ 6
+ >>>> untaint(int, z)
+ 11
+ >>>> untaint(bool, x > 5)
+ True
+ >>>> untaint(int, x > 5)
+ TaintError
-Taint Bombs
------------
-In this area, a common problem is what to do about failing operations.
-If an operation raises an exception when manipulating a tainted object,
-then the very presence of the exception can leak information about the
-tainted object itself. Consider::
+ Taint Bombs
+ -----------
- >>>> 5 / (x-6)
+ In this area, a common problem is what to do about failing operations.
+ If an operation raises an exception when manipulating a tainted object,
+ then the very presence of the exception can leak information about the
+ tainted object itself. Consider::
-By checking if this raises ``ZeroDivisionError`` or not, we would know
-if ``x`` was equal to 6 or not. The solution to this problem in the
-Taint Object Space is to introduce *Taint Bombs*. They are a kind of
-tainted object that doesn't contain a real object, but a pending
-exception. Taint Bombs are indistinguishable from normal tainted
-objects to unprivileged code. See::
+ >>>> 5 / (x-6)
- >>>> x = taint(6)
- >>>> i = 5 / (x-6) # no exception here
- >>>> j = i + 1 # nor here
- >>>> k = j + 5 # nor here
- >>>> untaint(int, k)
- TaintError
+ By checking if this raises ``ZeroDivisionError`` or not, we would know
+ if ``x`` was equal to 6 or not. The solution to this problem in the
+ Taint Object Space is to introduce *Taint Bombs*. They are a kind of
+ tainted object that doesn't contain a real object, but a pending
+ exception. Taint Bombs are indistinguishable from normal tainted
+ objects to unprivileged code. See::
-In the above example, all of ``i``, ``j`` and ``k`` contain a Taint
-Bomb. Trying to untaint it raises an exception - a generic
-``TaintError``. What we win is that the exception gives little away,
-and most importantly it occurs at the point where ``untaint()`` is
-called, not where the operation failed. This means that all calls to
-``untaint()`` - but not the rest of the code - must be carefully
-reviewed for what occurs if they receive a Taint Bomb; they might catch
-the ``TaintError`` and give the user a generic message that something
-went wrong, if we are reasonably careful that the message or even its
-presence doesn't give information away. This might be a
-problem by itself, but there is no satisfying general solution here:
-it must be considered on a case-by-case basis. Again, what the
-Taint Object Space approach achieves is not solving these problems, but
-localizing them to well-defined small parts of the application - namely,
-around calls to ``untaint()``.
+ >>>> x = taint(6)
+ >>>> i = 5 / (x-6) # no exception here
+ >>>> j = i + 1 # nor here
+ >>>> k = j + 5 # nor here
+ >>>> untaint(int, k)
+ TaintError
-The ``TaintError`` exception deliberately does not include any
-useful error messages, because they might give information away.
-Of course, this makes debugging quite a bit harder; a difficult
-problem to solve properly. So far we have implemented a way to peek in a Taint
-Box or Bomb, ``__pypy__._taint_look(x)``, and a "debug mode" that
-prints the exception as soon as a Bomb is created - both write
-information to the low-level stderr of the application, where we hope
-that it is unlikely to be seen by anyone but the application
-developer.
+ In the above example, all of ``i``, ``j`` and ``k`` contain a Taint
+ Bomb. Trying to untaint it raises an exception - a generic
+ ``TaintError``. What we win is that the exception gives little away,
+ and most importantly it occurs at the point where ``untaint()`` is
+ called, not where the operation failed. This means that all calls to
+ ``untaint()`` - but not the rest of the code - must be carefully
+ reviewed for what occurs if they receive a Taint Bomb; they might catch
+ the ``TaintError`` and give the user a generic message that something
+ went wrong, if we are reasonably careful that the message or even its
+ presence doesn't give information away. This might be a
+ problem by itself, but there is no satisfying general solution here:
+ it must be considered on a case-by-case basis. Again, what the
+ Taint Object Space approach achieves is not solving these problems, but
+ localizing them to well-defined small parts of the application - namely,
+ around calls to ``untaint()``.
+ The ``TaintError`` exception deliberately does not include any
+ useful error messages, because they might give information away.
+ Of course, this makes debugging quite a bit harder; a difficult
+ problem to solve properly. So far we have implemented a way to peek in a Taint
+ Box or Bomb, ``__pypy__._taint_look(x)``, and a "debug mode" that
+ prints the exception as soon as a Bomb is created - both write
+ information to the low-level stderr of the application, where we hope
+ that it is unlikely to be seen by anyone but the application
+ developer.
-Taint Atomic functions
-----------------------
-Occasionally, a more complicated computation must be performed on a
-tainted object. This requires first untainting the object, performing the
-computations, and then carefully tainting the result again (including
-hiding all exceptions into Bombs).
+ Taint Atomic functions
+ ----------------------
-There is a built-in decorator that does this for you::
+ Occasionally, a more complicated computation must be performed on a
+ tainted object. This requires first untainting the object, performing the
+ computations, and then carefully tainting the result again (including
+ hiding all exceptions into Bombs).
- >>>> @__pypy__.taint_atomic
- >>>> def myop(x, y):
- .... while x > 0:
- .... x -= y
- .... return x
- ....
- >>>> myop(42, 10)
- -8
- >>>> z = myop(taint(42), 10)
- >>>> z
- TaintError
- >>>> untaint(int, z)
- -8
+ There is a built-in decorator that does this for you::
-The decorator makes a whole function behave like a built-in operation.
-If no tainted argument is passed in, the function behaves normally. But
-if any of the arguments is tainted, it is automatically untainted - so
-the function body always sees untainted arguments - and the eventual
-result is tainted again (possibly in a Taint Bomb).
+ >>>> @__pypy__.taint_atomic
+ >>>> def myop(x, y):
+ .... while x > 0:
+ .... x -= y
+ .... return x
+ ....
+ >>>> myop(42, 10)
+ -8
+ >>>> z = myop(taint(42), 10)
+ >>>> z
+ TaintError
+ >>>> untaint(int, z)
+ -8
-It is important for the function marked as ``taint_atomic`` to have no
-visible side effects, as these could cause information leakage.
-This is currently not enforced, which means that all ``taint_atomic``
-functions have to be carefully reviewed for security (but not the
-callers of ``taint_atomic`` functions).
+ The decorator makes a whole function behave like a built-in operation.
+ If no tainted argument is passed in, the function behaves normally. But
+ if any of the arguments is tainted, it is automatically untainted - so
+ the function body always sees untainted arguments - and the eventual
+ result is tainted again (possibly in a Taint Bomb).
-A possible future extension would be to forbid side-effects on
-non-tainted objects from all ``taint_atomic`` functions.
+ It is important for the function marked as ``taint_atomic`` to have no
+ visible side effects, as these could cause information leakage.
+ This is currently not enforced, which means that all ``taint_atomic``
+ functions have to be carefully reviewed for security (but not the
+ callers of ``taint_atomic`` functions).
-An example of usage: given a tainted object ``passwords_db`` that
-references a database of passwords, we can write a function
-that checks if a password is valid as follows::
+ A possible future extension would be to forbid side-effects on
+ non-tainted objects from all ``taint_atomic`` functions.
- @taint_atomic
- def validate(passwords_db, username, password):
- assert type(passwords_db) is PasswordDatabase
- assert type(username) is str
- assert type(password) is str
- ...load username entry from passwords_db...
- return expected_password == password
+ An example of usage: given a tainted object ``passwords_db`` that
+ references a database of passwords, we can write a function
+ that checks if a password is valid as follows::
-It returns a tainted boolean answer, or a Taint Bomb if something
-went wrong. A caller can do::
+ @taint_atomic
+ def validate(passwords_db, username, password):
+ assert type(passwords_db) is PasswordDatabase
+ assert type(username) is str
+ assert type(password) is str
+ ...load username entry from passwords_db...
+ return expected_password == password
- ok = validate(passwords_db, 'john', '1234')
- ok = untaint(bool, ok)
+ It returns a tainted boolean answer, or a Taint Bomb if something
+ went wrong. A caller can do::
-This can give three outcomes: ``True``, ``False``, or a ``TaintError``
-exception (with no information on it) if anything went wrong. If even
-this is considered giving too much information away, the ``False`` case
-can be made indistinguishable from the ``TaintError`` case (simply by
-raising an exception in ``validate()`` if the password is wrong).
+ ok = validate(passwords_db, 'john', '1234')
+ ok = untaint(bool, ok)
-In the above example, the security results achieved are the following:
-as long as ``validate()`` does not leak information, no other part of
-the code can obtain more information about a passwords database than a
-Yes/No answer to a precise query.
+ This can give three outcomes: ``True``, ``False``, or a ``TaintError``
+ exception (with no information on it) if anything went wrong. If even
+ this is considered giving too much information away, the ``False`` case
+ can be made indistinguishable from the ``TaintError`` case (simply by
+ raising an exception in ``validate()`` if the password is wrong).
-A possible extension of the ``taint_atomic`` decorator would be to check
-the argument types, as ``untaint()`` does, for the same reason: to
-prevent bugs where a function like ``validate()`` above is accidentally
-called with the wrong kind of tainted object, which would make it
-misbehave. For now, all ``taint_atomic`` functions should be
-conservative and carefully check all assumptions on their input
-arguments.
+ In the above example, the security results achieved are the following:
+ as long as ``validate()`` does not leak information, no other part of
+ the code can obtain more information about a passwords database than a
+ Yes/No answer to a precise query.
+ A possible extension of the ``taint_atomic`` decorator would be to check
+ the argument types, as ``untaint()`` does, for the same reason: to
+ prevent bugs where a function like ``validate()`` above is accidentally
+ called with the wrong kind of tainted object, which would make it
+ misbehave. For now, all ``taint_atomic`` functions should be
+ conservative and carefully check all assumptions on their input
+ arguments.
-.. _`taint-interface`:
-Interface
----------
+ .. _`taint-interface`:
-.. _`like a built-in operation`:
+ Interface
+ ---------
-The basic rule of the Tainted Object Space is that it introduces two new
-kinds of objects, Tainted Boxes and Tainted Bombs (which are not types
-in the Python sense). Each box internally contains a regular object;
-each bomb internally contains an exception object. An operation
-involving Tainted Boxes is performed on the objects contained in the
-boxes, and gives a Tainted Box or a Tainted Bomb as a result (such an
-operation does not let an exception be raised). An operation called
-with a Tainted Bomb argument immediately returns the same Tainted Bomb.
+ .. _`like a built-in operation`:
-In a PyPy running with (or translated with) the Taint Object Space,
-the ``__pypy__`` module exposes the following interface:
+ The basic rule of the Tainted Object Space is that it introduces two new
+ kinds of objects, Tainted Boxes and Tainted Bombs (which are not types
+ in the Python sense). Each box internally contains a regular object;
+ each bomb internally contains an exception object. An operation
+ involving Tainted Boxes is performed on the objects contained in the
+ boxes, and gives a Tainted Box or a Tainted Bomb as a result (such an
+ operation does not let an exception be raised). An operation called
+ with a Tainted Bomb argument immediately returns the same Tainted Bomb.
-* ``taint(obj)``
+ In a PyPy running with (or translated with) the Taint Object Space,
+ the ``__pypy__`` module exposes the following interface:
- Return a new Tainted Box wrapping ``obj``. Return ``obj`` itself
- if it is already tainted (a Box or a Bomb).
+ * ``taint(obj)``
-* ``is_tainted(obj)``
+ Return a new Tainted Box wrapping ``obj``. Return ``obj`` itself
+ if it is already tainted (a Box or a Bomb).
- Check if ``obj`` is tainted (a Box or a Bomb).
+ * ``is_tainted(obj)``
-* ``untaint(type, obj)``
+ Check if ``obj`` is tainted (a Box or a Bomb).
- Untaints ``obj`` if it is tainted. Raise ``TaintError`` if the type
- of the untainted object is not exactly ``type``, or if ``obj`` is a
- Bomb.
+ * ``untaint(type, obj)``
-* ``taint_atomic(func)``
+ Untaints ``obj`` if it is tainted. Raise ``TaintError`` if the type
+ of the untainted object is not exactly ``type``, or if ``obj`` is a
+ Bomb.
- Return a wrapper function around the callable ``func``. The wrapper
- behaves `like a built-in operation`_ with respect to untainting the
- arguments, tainting the result, and returning a Bomb.
+ * ``taint_atomic(func)``
-* ``TaintError``
+ Return a wrapper function around the callable ``func``. The wrapper
+ behaves `like a built-in operation`_ with respect to untainting the
+ arguments, tainting the result, and returning a Bomb.
- Exception. On purpose, it provides no attribute or error message.
+ * ``TaintError``
-* ``_taint_debug(level)``
+ Exception. On purpose, it provides no attribute or error message.
- Set the debugging level to ``level`` (0=off). At level 1 or above,
- all Taint Bombs print a diagnostic message to stderr when they are
- created.
+ * ``_taint_debug(level)``
-* ``_taint_look(obj)``
+ Set the debugging level to ``level`` (0=off). At level 1 or above,
+ all Taint Bombs print a diagnostic message to stderr when they are
+ created.
- For debugging purposes: prints (to stderr) the type and address of
- the object in a Tainted Box, or prints the exception if ``obj`` is
- a Taint Bomb.
+ * ``_taint_look(obj)``
+
+ For debugging purposes: prints (to stderr) the type and address of
+ the object in a Tainted Box, or prints the exception if ``obj`` is
+ a Taint Bomb.
.. _dump:
@@ -485,7 +483,7 @@
----------------------------------------------------
Suppose we want to have a list which stores all operations performed on
-it for later analysis. We can use the small `tputil`_ module to help
+it for later analysis. We can use the small `lib_pypy/tputil.py`_ module to help
with transparently proxying builtin instances::
from tputil import make_proxy
@@ -534,10 +532,10 @@
.. _tputil:
-tputil help module
+tputil helper module
----------------------------
-The `tputil.py`_ module provides:
+The `lib_pypy/tputil.py`_ module provides:
* ``make_proxy(controller, type, obj)``: function which
creates a transparent proxy controlled by the given
@@ -595,8 +593,8 @@
to application level code.
Transparent proxies are implemented on top of the `standard object
-space`_, in `proxy_helpers.py`_, `proxyobject.py`_ and
-`transparent.py`_. To use them you will need to pass a
+space`_, in `pypy/objspace/std/proxy_helpers.py`_, `pypy/objspace/std/proxyobject.py`_ and
+`pypy/objspace/std/transparent.py`_. To use them you will need to pass a
`--objspace-std-withtproxy`_ option to ``py.py`` or
``translate.py``. This registers implementations named
``W_TransparentXxx`` - which usually correspond to an
@@ -607,12 +605,8 @@
lists, dicts, exceptions, tracebacks and frames.
.. _`standard object space`: objspace.html#the-standard-object-space
-.. _`proxy_helpers.py`: ../../../../pypy/objspace/std/proxy_helpers.py
-.. _`proxyobject.py`: ../../../../pypy/objspace/std/proxyobject.py
-.. _`transparent.py`: ../../../../pypy/objspace/std/transparent.py
-.. _`tputil.py`: ../../lib_pypy/tputil.py
.. [D12.1] `High-Level Backends and Interpreter Feature Prototypes`, PyPy
EU-Report, 2007, http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-2007-03-22.pdf
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.allworkingmodules.rst b/pypy/doc/config/objspace.allworkingmodules.txt
copy from pypy/doc/config/objspace.allworkingmodules.rst
copy to pypy/doc/config/objspace.allworkingmodules.txt
diff --git a/pypy/doc/config/objspace.usemodules.fcntl.rst b/pypy/doc/config/objspace.usemodules.fcntl.txt
copy from pypy/doc/config/objspace.usemodules.fcntl.rst
copy to pypy/doc/config/objspace.usemodules.fcntl.txt
diff --git a/pypy/doc/config/objspace.rst b/pypy/doc/config/objspace.txt
copy from pypy/doc/config/objspace.rst
copy to pypy/doc/config/objspace.txt
diff --git a/pypy/doc/config/objspace.usemodules._weakref.rst b/pypy/doc/config/objspace.usemodules._weakref.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._weakref.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-Use the '_weakref' module, necessary for the standard lib 'weakref' module.
-PyPy's weakref implementation is not completely stable yet. The first
-difference to CPython is that weak references only go away after the next
-garbage collection, not immediately. The other problem seems to be that under
-certain circumstances (that we have not determined) weak references keep the
-object alive.
diff --git a/pypy/doc/config/objspace.usemodules.array.rst b/pypy/doc/config/objspace.usemodules.array.txt
copy from pypy/doc/config/objspace.usemodules.array.rst
copy to pypy/doc/config/objspace.usemodules.array.txt
diff --git a/pypy/doc/config/translation.backendopt.mallocs.rst b/pypy/doc/config/translation.backendopt.mallocs.txt
copy from pypy/doc/config/translation.backendopt.mallocs.rst
copy to pypy/doc/config/translation.backendopt.mallocs.txt
diff --git a/pypy/doc/config/objspace.std.prebuiltintto.rst b/pypy/doc/config/objspace.std.prebuiltintto.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.prebuiltintto.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-See :config:`objspace.std.withprebuiltint`.
diff --git a/pypy/doc/discussion/paper-wishlist.rst b/pypy/doc/discussion/paper-wishlist.rst
deleted file mode 100644
--- a/pypy/doc/discussion/paper-wishlist.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-Things we would like to write papers about
-==========================================
-
-- object space architecture + reflective space
-- stackless transformation
-- composable coroutines
-- jit:
- - overview paper
- - putting our jit into the context of classical partial evaluation
- - a jit technical paper too, probably
-
-- sandboxing
-
-Things about which writing a paper would be nice, which need more work first
-============================================================================
-
-- taint object space
-- logic object space
-
-- jit
-
- - with some more work: how to deal in a JIT backend with less-that-
- full-function compilation unit
-
- - work in progress (Anto?): our JIT on the JVM
- - (later) removing the overhead of features not used, e.g. thunk space or
- another special space
diff --git a/pypy/doc/config/translation.vanilla.rst b/pypy/doc/config/translation.vanilla.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.vanilla.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Try to make the resulting compiled program as portable (=movable to another
-machine) as possible. Which is not much.
diff --git a/pypy/doc/interpreter-optimizations.rst b/pypy/doc/interpreter-optimizations.rst
--- a/pypy/doc/interpreter-optimizations.rst
+++ b/pypy/doc/interpreter-optimizations.rst
@@ -79,7 +79,7 @@
$ bin/py.py --objspace-std-withrope
faking <type 'module'>
- PyPy 0.99.0 in StdObjSpace on top of Python 2.4.4c1 (startuptime: 17.24 secs)
+ PyPy 1.5.0-alpha0 in StdObjSpace on top of Python 2.7.1+ (startuptime: 11.38 secs)
>>>> import sys
>>>> sys.maxint
2147483647
@@ -90,7 +90,8 @@
You can enable this feature with the :config:`objspace.std.withrope` option.
-.. _`"Ropes: An alternative to Strings."`: http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf
+.. _`"Ropes: An alternative to Strings."`: http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9450&rep=rep1&type=pdf
+
Integer Optimizations
---------------------
@@ -134,7 +135,6 @@
implementations for various purposes (see below).
This is now the default implementation of dictionaries in the Python interpreter.
-option.
Sharing Dicts
+++++++++++++
@@ -205,28 +205,11 @@
User Class Optimizations
------------------------
-Shadow Tracking
-+++++++++++++++
-
-Shadow tracking is a general optimization that speeds up method calls for user
-classes (that don't have special meta-class). For this a special dict
-representation is used together with multidicts. This dict representation is
-used only for instance dictionaries. The instance dictionary tracks whether an
-instance attribute shadows an attribute of its class. This makes method calls
-slightly faster in the following way: When calling a method the first thing that
-is checked is the class dictionary to find descriptors. Normally, when a method
-is found, the instance dictionary is then checked for instance attributes
-shadowing the class attribute. If we know that there is no shadowing (since
-instance dict tells us that) we can save this lookup on the instance dictionary.
-
-*This was deprecated and is no longer available.*
-
Method Caching
++++++++++++++
-Shadow tracking is also an important building block for the method caching
-optimization. A method cache is introduced where the result of a method lookup
+A method cache is introduced where the result of a method lookup
is stored (which involves potentially many lookups in the base classes of a
class). Entries in the method cache are stored using a hash computed from
the name being looked up, the call site (i.e. the bytecode object and
@@ -344,14 +327,12 @@
improving results by anything from 15-40 per cent.
Another optimization, or rather set of optimizations, that has a uniformly good
-effect is the set of three 'method optimizations', i.e. shadow tracking, the
+effect are the two 'method optimizations', i.e. the
method cache and the LOOKUP_METHOD and CALL_METHOD opcodes. On a heavily
object-oriented benchmark (richards) they combine to give a speed-up of nearly
50%, and even on the extremely un-object-oriented pystone benchmark, the
improvement is over 20%.
-.. waffles about ropes
-
When building pypy, all generally useful optimizations are turned on by default
unless you explicitly lower the translation optimization level with the
``--opt`` option.
diff --git a/pypy/doc/config/objspace.usemodules._multiprocessing.rst b/pypy/doc/config/objspace.usemodules._multiprocessing.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._multiprocessing.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_multiprocessing' module.
-Used by the 'multiprocessing' standard lib module. This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules.oracle.rst b/pypy/doc/config/objspace.usemodules.oracle.txt
copy from pypy/doc/config/objspace.usemodules.oracle.rst
copy to pypy/doc/config/objspace.usemodules.oracle.txt
diff --git a/pypy/doc/config/objspace.usemodules.errno.rst b/pypy/doc/config/objspace.usemodules.errno.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.errno.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'errno' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules.posix.rst b/pypy/doc/config/objspace.usemodules.posix.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.posix.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the essential 'posix' module.
-This module is essential, included by default and cannot be removed (even when
-specified explicitly, the option gets overridden later).
diff --git a/pypy/doc/config/objspace.std.getattributeshortcut.rst b/pypy/doc/config/objspace.std.getattributeshortcut.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.getattributeshortcut.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Performance only: track types that override __getattribute__.
diff --git a/pypy/doc/config/objspace.usemodules.cpyext.rst b/pypy/doc/config/objspace.usemodules.cpyext.txt
copy from pypy/doc/config/objspace.usemodules.cpyext.rst
copy to pypy/doc/config/objspace.usemodules.cpyext.txt
diff --git a/pypy/doc/statistic/style.css b/pypy/doc/statistic/style.css
deleted file mode 100644
--- a/pypy/doc/statistic/style.css
+++ /dev/null
@@ -1,1083 +0,0 @@
-body,body.editor,body.body {
- font: 110% "Times New Roman", Arial, Verdana, Helvetica, serif;
- background: White;
- color: Black;
-}
-
-a, a.reference {
- text-decoration: none;
-}
-a[href]:hover { text-decoration: underline; }
-
-img {
- border: none;
- vertical-align: middle;
-}
-
-p, div.text {
- text-align: left;
- line-height: 1.5em;
- margin: 0.5em 0em 0em 0em;
-}
-
-
-
-p a:active {
- color: Red;
- background-color: transparent;
-}
-
-p img {
- border: 0;
- margin: 0;
-}
-
-img.inlinephoto {
- padding: 0;
- padding-right: 1em;
- padding-top: 0.7em;
- float: left;
-}
-
-hr {
- clear: both;
- height: 1px;
- color: #8CACBB;
- background-color: transparent;
-}
-
-
-ul {
- line-height: 1.5em;
- /*list-style-image: url("bullet.gif"); */
- margin-left: 1.5em;
- padding:0;
-}
-
-ol {
- line-height: 1.5em;
- margin-left: 1.5em;
- padding:0;
-}
-
-ul a, ol a {
- text-decoration: underline;
-}
-
-dl {
-}
-
-dt {
- font-weight: bold;
-}
-
-dd {
- line-height: 1.5em;
- margin-bottom: 1em;
-}
-
-blockquote {
- font-family: Times, "Times New Roman", serif;
- font-style: italic;
- font-size: 120%;
-}
-
-code {
- color: Black;
- /*background-color: #dee7ec;*/
- background-color: #cccccc;
-}
-
-pre {
- padding: 1em;
- border: 1px solid #8cacbb;
- color: Black;
- background-color: #dee7ec;
- background-color: #cccccc;
- overflow: auto;
-}
-
-
-.netscape4 {
- display: none;
-}
-
-/* main page styles */
-
-/*a[href]:hover { color: black; text-decoration: underline; }
-a[href]:link { color: black; text-decoration: underline; }
-a[href] { color: black; text-decoration: underline; }
-*/
-
-span.menu_selected {
- color: black;
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
- padding-right: 0.3em;
- background-color: #cccccc;
-}
-
-
-a.menu {
- /*color: #3ba6ec; */
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
- padding-right: 0.3em;
-}
-
-a.menu[href]:visited, a.menu[href]:link{
- /*color: #3ba6ec; */
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
-}
-
-a.menu[href]:hover {
- /*color: black;*/
-}
-
-div.project_title{
- /*border-spacing: 20px;*/
- font: 160% Verdana, Helvetica, Arial, sans-serif;
- color: #3ba6ec;
- vertical-align: center;
- padding-bottom: 0.3em;
-}
-
-a.wikicurrent {
- font: 100% Verdana, Helvetica, Arial, sans-serif;
- color: #3ba6ec;
- vertical-align: middle;
-}
-
-
-table.body {
- border: 0;
- /*padding: 0;
- border-spacing: 0px;
- border-collapse: separate;
- */
-}
-
-td.page-header-left {
- padding: 5px;
- /*border-bottom: 1px solid #444444;*/
-}
-
-td.page-header-top {
- padding: 0;
-
- /*border-bottom: 1px solid #444444;*/
-}
-
-td.sidebar {
- padding: 1 0 0 1;
-}
-
-td.sidebar p.classblock {
- padding: 0 5 0 5;
- margin: 1 1 1 1;
- border: 1px solid #444444;
- background-color: #eeeeee;
-}
-
-td.sidebar p.userblock {
- padding: 0 5 0 5;
- margin: 1 1 1 1;
- border: 1px solid #444444;
- background-color: #eeeeff;
-}
-
-td.content {
- padding: 1 5 1 5;
- vertical-align: top;
- width: 100%;
-}
-
-p.ok-message {
- background-color: #22bb22;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-p.error-message {
- background-color: #bb2222;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-
-p:first-child {
- margin: 0 ;
- padding: 0;
-}
-
-/* style for forms */
-table.form {
- padding: 2;
- border-spacing: 0px;
- border-collapse: separate;
-}
-
-table.form th {
- color: #333388;
- text-align: right;
- vertical-align: top;
- font-weight: normal;
-}
-table.form th.header {
- font-weight: bold;
- background-color: #eeeeff;
- text-align: left;
-}
-
-table.form th.required {
- font-weight: bold;
-}
-
-table.form td {
- color: #333333;
- empty-cells: show;
- vertical-align: top;
-}
-
-table.form td.optional {
- font-weight: bold;
- font-style: italic;
-}
-
-table.form td.html {
- color: #777777;
-}
-
-/* style for lists */
-table.list {
- border-spacing: 0px;
- border-collapse: separate;
- vertical-align: top;
- padding-top: 0;
- width: 100%;
-}
-
-table.list th {
- padding: 0 4 0 4;
- color: #404070;
- background-color: #eeeeff;
- border-right: 1px solid #404070;
- border-top: 1px solid #404070;
- border-bottom: 1px solid #404070;
- vertical-align: top;
- empty-cells: show;
-}
-table.list th a[href]:hover { color: #404070 }
-table.list th a[href]:link { color: #404070 }
-table.list th a[href] { color: #404070 }
-table.list th.group {
- background-color: #f4f4ff;
- text-align: center;
- font-size: 120%;
-}
-
-table.list td {
- padding: 0 4 0 4;
- border: 0 2 0 2;
- border-right: 1px solid #404070;
- color: #404070;
- background-color: white;
- vertical-align: top;
- empty-cells: show;
-}
-
-table.list tr.normal td {
- background-color: white;
- white-space: nowrap;
-}
-
-table.list tr.alt td {
- background-color: #efefef;
- white-space: nowrap;
-}
-
-table.list td:first-child {
- border-left: 1px solid #404070;
- border-right: 1px solid #404070;
-}
-
-table.list th:first-child {
- border-left: 1px solid #404070;
- border-right: 1px solid #404070;
-}
-
-table.list tr.navigation th {
- text-align: right;
-}
-table.list tr.navigation th:first-child {
- border-right: none;
- text-align: left;
-}
-
-
-/* style for message displays */
-table.messages {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.messages th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.messages th {
- font-weight: bold;
- color: black;
- text-align: left;
- border-bottom: 1px solid #afafaf;
-}
-
-table.messages td {
- font-family: monospace;
- background-color: #efefef;
- border-bottom: 1px solid #afafaf;
- color: black;
- empty-cells: show;
- border-right: 1px solid #afafaf;
- vertical-align: top;
- padding: 2 5 2 5;
-}
-
-table.messages td:first-child {
- border-left: 1px solid #afafaf;
- border-right: 1px solid #afafaf;
-}
-
-/* style for file displays */
-table.files {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.files th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.files th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
-}
-
-table.files td {
- font-family: monospace;
- empty-cells: show;
-}
-
-/* style for history displays */
-table.history {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.history th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
- font-size: 100%;
-}
-
-table.history th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
- font-size: 90%;
-}
-
-table.history td {
- font-size: 90%;
- vertical-align: top;
- empty-cells: show;
-}
-
-
-/* style for class list */
-table.classlist {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.classlist th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.classlist th {
- font-weight: bold;
- text-align: left;
-}
-
-
-/* style for class help display */
-table.classhelp {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.classhelp th {
- font-weight: bold;
- text-align: left;
- color: #707040;
-}
-
-table.classhelp td {
- padding: 2 2 2 2;
- border: 1px solid black;
- text-align: left;
- vertical-align: top;
- empty-cells: show;
-}
-
-
-/* style for "other" displays */
-table.otherinfo {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.otherinfo th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.otherinfo th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
-}
-
-input {
- border: 1px solid #8cacbb;
- color: Black;
- background-color: white;
- vertical-align: middle;
- margin-bottom: 1px; /* IE bug fix */
- padding: 0.1em;
-}
-
-select {
- border: 1px solid #8cacbb;
- color: Black;
- background-color: white;
- vertical-align: middle;
- margin-bottom: 1px; /* IE bug fix */
- padding: 0.1em;
-}
-
-
-a.nonexistent {
- color: #FF2222;
-}
-a.nonexistent:visited {
- color: #FF2222;
-}
-a.external {
- color: #AA6600;
-}
-
-/*
-dl,ul,ol {
- margin-top: 1pt;
-}
-tt,pre {
- font-family: Lucida Console,Courier New,Courier,monotype;
- font-size: 12pt;
-}
-pre.code {
- margin-top: 8pt;
- margin-bottom: 8pt;
- background-color: #FFFFEE;
- white-space:pre;
- border-style:solid;
- border-width:1pt;
- border-color:#999999;
- color:#111111;
- padding:5px;
- width:100%;
-}
-*/
-div.diffold {
- background-color: #FFFF80;
- border-style:none;
- border-width:thin;
- width:100%;
-}
-div.diffnew {
- background-color: #80FF80;
- border-style:none;
- border-width:thin;
- width:100%;
-}
-div.message {
- margin-top: 6pt;
- background-color: #E8FFE8;
- border-style:solid;
- border-width:1pt;
- border-color:#999999;
- color:#440000;
- padding:5px;
- width:100%;
-}
-strong.highlight {
- background-color: #FFBBBB;
-/* as usual, NetScape fucks up with innocent CSS
- border-color: #FFAAAA;
- border-style: solid;
- border-width: 1pt;
-*/
-}
-
-table.navibar {
- background-color: #C8C8C8;
- border-spacing: 3px;
-}
-td.navibar {
- background-color: #E8E8E8;
- vertical-align: top;
- text-align: right;
- padding: 0px;
-}
-
-div.pagename {
- font-size: 140%;
- color: blue;
- text-align: center;
- font-weight: bold;
- background-color: white;
- padding: 0 ;
-}
-
-a.wikiaction, input.wikiaction {
- color: black;
- text-decoration: None;
- text-align: center;
- color: black;
- /*border: 1px solid #3ba6ec; */
- margin: 4px;
- padding: 5;
- padding-bottom: 0;
- white-space: nowrap;
-}
-
-a.wikiaction[href]:hover {
- color: black;
- text-decoration: none;
- /*background-color: #dddddd; */
-}
-
-span.wikiuserpref {
- padding-top: 1em;
- font-size: 120%;
-}
-
-div.wikitrail {
- vertical-align: bottom;
- /*font-size: -1;*/
- padding-top: 1em;
- display: none;
-}
-
-div.wikiaction {
- vertical-align: middle;
- /*border-bottom: 1px solid #8cacbb;*/
- padding-bottom:1em;
- text-align: left;
- width: 100%;
-}
-
-div.wikieditmenu {
- text-align: right;
-}
-
-form.wikiedit {
- border: 1px solid #8cacbb;
- background-color: #f0f0f0;
- background-color: #fabf00;
- padding: 1em;
- padding-right: 0em;
-}
-
-div.legenditem {
- padding-top: 0.5em;
- padding-left: 0.3em;
-}
-
-span.wikitoken {
- background-color: #eeeeee;
-}
-
-
-div#contentspace h1:first-child, div.heading:first-child {
- padding-top: 0;
- margin-top: 0;
-}
-div#contentspace h2:first-child {
- padding-top: 0;
- margin-top: 0;
-}
-
-/* heading and paragraph text */
-
-div.heading, h1 {
- font-family: Verdana, Helvetica, Arial, sans-serif;
- background-color: #58b3ef;
- background-color: #FFFFFF;
- /*color: #4893cf;*/
- color: black;
- padding-top: 1.0em;
- padding-bottom:0.2em;
- text-align: left;
- margin-top: 0em;
- /*margin-bottom:8pt;*/
- font-weight: bold;
- font-size: 115%;
- border-bottom: 1px solid #8CACBB;
-}
-
-
-h1, h2, h3, h4, h5, h6 {
- color: Black;
- clear: left;
- font: 100% Verdana, Helvetica, Arial, sans-serif;
- margin: 0;
- padding-left: 0em;
- padding-top: 1em;
- padding-bottom: 0.2em;
- /*border-bottom: 1px solid #8CACBB;*/
-}
-/* h1,h2 { padding-top: 0; }*/
-
-
-h1 { font-size: 145%; }
-h2 { font-size: 135%; }
-h3 { font-size: 125%; }
-h4 { font-size: 120%; }
-h5 { font-size: 110%; }
-h6 { font-size: 80%; }
-
-h1 a { text-decoration: None;}
-
-div.exception {
- background-color: #bb2222;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-pre.exception {
- font-size: 110%;
- padding: 1em;
- border: 1px solid #8cacbb;
- color: Black;
- background-color: #dee7ec;
- background-color: #cccccc;
-}
-
-/* defines for navgiation bar (documentation) */
-
-
-div.direntry {
- padding-top: 0.3em;
- padding-bottom: 0.3em;
- margin-right: 1em;
- font-weight: bold;
- background-color: #dee7ec;
- font-size: 110%;
-}
-
-div.fileentry {
- font-family: Verdana, Helvetica, Arial, sans-serif;
- padding-bottom: 0.3em;
- white-space: nowrap;
- line-height: 150%;
-}
-
-a.fileentry {
- white-space: nowrap;
-}
-
-
-span.left {
- text-align: left;
-}
-span.right {
- text-align: right;
-}
-
-div.navbar {
- /*margin: 0;*/
- font-size: 80% /*smaller*/;
- font-weight: bold;
- text-align: left;
- /* position: fixed; */
- top: 100pt;
- left: 0pt; /* auto; */
- width: 120pt;
- /* right: auto;
- right: 0pt; 2em; */
-}
-
-
-div.history a {
- /* font-size: 70%; */
-}
-
-div.wikiactiontitle {
- font-weight: bold;
-}
-
-/* REST defines */
-
-div.document {
- margin: 0;
-}
-
-h1.title {
- margin: 0;
-}
-
-td.toplist {
- vertical-align: top;
-}
-
-img#pyimg {
- position: absolute;
- top: 4px;
- left: 4px;
-}
-
-img#extraimg {
- position: absolute;
- right: 14px;
- top: 4px;
-}
-
-div#navspace {
- position: absolute;
- top: 130px;
- left: 11px;
- font-size: 100%;
- width: 150px;
- overflow: hidden; /* scroll; */
-}
-
-div#metaspace {
- position: absolute;
- top: 40px;
- left: 170px;
-}
-
-div#errorline {
- position: relative;
- top: 5px;
- float: right;
-}
-
-div#contentspace {
- position: absolute;
- /* font: 120% "Times New Roman", serif;*/
- font: 110% Verdana, Helvetica, Arial, sans-serif;
- top: 130px;
- left: 170px;
- margin-right: 5px;
-}
-
-div#menubar {
-/* width: 400px; */
- float: left;
-}
-
-/* for the documentation page */
-div#docinfoline {
- position: relative;
- top: 5px;
- left: 0px;
-
- /*background-color: #dee7ec; */
- padding: 5pt;
- padding-bottom: 1em;
- color: black;
- /*border-width: 1pt;
- border-style: solid;*/
-
-}
-
-div#docnavlist {
- /*background-color: #dee7ec; */
- padding: 5pt;
- padding-bottom: 2em;
- color: black;
- border-width: 1pt;
- /*border-style: solid;*/
-}
-
-
-/* text markup */
-
-div.listtitle {
- color: Black;
- clear: left;
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- margin: 0;
- padding-left: 0em;
- padding-top: 0em;
- padding-bottom: 0.2em;
- margin-right: 0.5em;
- border-bottom: 1px solid #8CACBB;
-}
-
-div.actionbox h3 {
- padding-top: 0;
- padding-right: 0.5em;
- padding-left: 0.5em;
- background-color: #fabf00;
- text-align: center;
- border: 1px solid black; /* 8cacbb; */
-}
-
-div.actionbox a {
- display: block;
- padding-bottom: 0.5em;
- padding-top: 0.5em;
- margin-left: 0.5em;
-}
-
-div.actionbox a.history {
- display: block;
- padding-bottom: 0.5em;
- padding-top: 0.5em;
- margin-left: 0.5em;
- font-size: 90%;
-}
-
-div.actionbox {
- margin-bottom: 2em;
- padding-bottom: 1em;
- overflow: hidden; /* scroll; */
-}
-
-/* taken from docutils (oh dear, a bit senseless) */
-ol.simple, ul.simple {
- margin-bottom: 1em }
-
-ol.arabic {
- list-style: decimal }
-
-ol.loweralpha {
- list-style: lower-alpha }
-
-ol.upperalpha {
- list-style: upper-alpha }
-
-ol.lowerroman {
- list-style: lower-roman }
-
-ol.upperroman {
- list-style: upper-roman }
-
-
-/*
-:Author: David Goodger
-:Contact: goodger at users.sourceforge.net
-:date: $Date: 2003/01/22 22:26:48 $
-:version: $Revision: 1.29 $
-:copyright: This stylesheet has been placed in the public domain.
-
-Default cascading style sheet for the HTML output of Docutils.
-*/
-/*
-.first {
- margin-top: 0 }
-
-.last {
- margin-bottom: 0 }
-
-a.toc-backref {
- text-decoration: none ;
- color: black }
-
-dd {
- margin-bottom: 0.5em }
-
-div.abstract {
- margin: 2em 5em }
-
-div.abstract p.topic-title {
- font-weight: bold ;
- text-align: center }
-
-div.attention, div.caution, div.danger, div.error, div.hint,
-div.important, div.note, div.tip, div.warning {
- margin: 2em ;
- border: medium outset ;
- padding: 1em }
-
-div.attention p.admonition-title, div.caution p.admonition-title,
-div.danger p.admonition-title, div.error p.admonition-title,
-div.warning p.admonition-title {
- color: red ;
- font-weight: bold ;
- font-family: sans-serif }
-
-div.hint p.admonition-title, div.important p.admonition-title,
-div.note p.admonition-title, div.tip p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
-div.dedication {
- margin: 2em 5em ;
- text-align: center ;
- font-style: italic }
-
-div.dedication p.topic-title {
- font-weight: bold ;
- font-style: normal }
-
-div.figure {
- margin-left: 2em }
-
-div.footer, div.header {
- font-size: smaller }
-
-div.system-messages {
- margin: 5em }
-
-div.system-messages h1 {
- color: red }
-
-div.system-message {
- border: medium outset ;
- padding: 1em }
-
-div.system-message p.system-message-title {
- color: red ;
- font-weight: bold }
-
-div.topic {
- margin: 2em }
-
-h1.title {
- text-align: center }
-
-h2.subtitle {
- text-align: center }
-
-hr {
- width: 75% }
-
-p.caption {
- font-style: italic }
-
-p.credits {
- font-style: italic ;
- font-size: smaller }
-
-p.label {
- white-space: nowrap }
-
-p.topic-title {
- font-weight: bold }
-
-pre.address {
- margin-bottom: 0 ;
- margin-top: 0 ;
- font-family: serif ;
- font-size: 100% }
-
-pre.line-block {
- font-family: serif ;
- font-size: 100% }
-
-pre.literal-block, pre.doctest-block {
- margin-left: 2em ;
- margin-right: 2em ;
- background-color: #eeeeee }
-
-span.classifier {
- font-family: sans-serif ;
- font-style: oblique }
-
-span.classifier-delimiter {
- font-family: sans-serif ;
- font-weight: bold }
-
-span.interpreted {
- font-family: sans-serif }
-
-span.option {
- white-space: nowrap }
-
-span.option-argument {
- font-style: italic }
-
-span.pre {
- white-space: pre }
-
-span.problematic {
- color: red }
-
-table {
- margin-top: 0.5em ;
- margin-bottom: 0.5em }
-
-table.citation {
- border-left: solid thin gray ;
- padding-left: 0.5ex }
-
-table.docinfo {
- margin: 2em 4em }
-
-table.footnote {
- border-left: solid thin black ;
- padding-left: 0.5ex }
-
-td, th {
- padding-left: 0.5em ;
- padding-right: 0.5em ;
- vertical-align: top }
-
-th.docinfo-name, th.field-name {
- font-weight: bold ;
- text-align: left ;
- white-space: nowrap }
-
-h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
- font-size: 100% }
-
-tt {
- background-color: #eeeeee }
-
-ul.auto-toc {
- list-style-type: none }
-*/
-
-div.section {
- margin-top: 1.0em ;
-}
diff --git a/pypy/doc/config/translation.platform.rst b/pypy/doc/config/translation.platform.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.platform.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-select the target platform, in case of cross-compilation
diff --git a/pypy/doc/config/translation.instrumentctl.rst b/pypy/doc/config/translation.instrumentctl.txt
copy from pypy/doc/config/translation.instrumentctl.rst
copy to pypy/doc/config/translation.instrumentctl.txt
diff --git a/pypy/doc/config/translation.fork_before.rst b/pypy/doc/config/translation.fork_before.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.fork_before.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-This is an option mostly useful when working on the PyPy toolchain. If you use
-it, translate.py will fork before the specified phase. If the translation
-crashes after that fork, you can fix the bug in the toolchain, and continue
-translation at the fork-point.
diff --git a/pypy/doc/config/objspace.std.withmethodcachecounter.rst b/pypy/doc/config/objspace.std.withmethodcachecounter.txt
copy from pypy/doc/config/objspace.std.withmethodcachecounter.rst
copy to pypy/doc/config/objspace.std.withmethodcachecounter.txt
diff --git a/pypy/doc/windows.rst b/pypy/doc/windows.rst
--- a/pypy/doc/windows.rst
+++ b/pypy/doc/windows.rst
@@ -13,10 +13,21 @@
Translating PyPy with Visual Studio
-----------------------------------
-We routinely test the translation toolchain using Visual Studio .NET
+We routinely test the `RPython translation toolchain`_ using Visual Studio .NET
2005, Professional Edition, and Visual Studio .NET 2008, Express
Edition. Other configurations may work as well.
+The translation scripts will set up the appropriate environment variables
+for the compiler. They will attempt to locate the same compiler version that
+was used to build the Python interpreter doing the
+translation. Failing that, they will pick the most recent Visual Studio
+compiler they can find. In addition, the target architecture
+(32 bits, 64 bits) is automatically selected. A 32 bit build can only be built
+using a 32 bit Python and vice versa.
+
+**Note:** PyPy is currently not supported for 64 bit Windows, and translation
+will be aborted in this case.
+
The compiler is all you need to build pypy-c, but it will miss some
modules that relies on third-party libraries. See below how to get
and build them.
@@ -111,3 +122,4 @@
cp .libs/libffi-5.dll <somewhere on the PATH>
.. _`libffi source files`: http://sourceware.org/libffi/
+.. _`RPython translation toolchain`: translation.html
diff --git a/pypy/doc/dev_method.rst b/pypy/doc/dev_method.rst
--- a/pypy/doc/dev_method.rst
+++ b/pypy/doc/dev_method.rst
@@ -20,7 +20,7 @@
Main tools for achieving this is:
* py.test - automated testing
- * Subversion - version control
+ * Mercurial - version control
* Transparent communication and documentation (mailinglists, IRC, tutorials
etc etc)
@@ -237,124 +237,3 @@
interested in using sprints as away of making contact with active developers
(Python/compiler design etc)!
-If you have questions about our sprints and EU-funding - please send an email
-to pypy-funding at codespeak.net, our mailinglist for project coordination.
-
-Previous sprints?
-+++++++++++++++++
-
-The PyPy team has been sprinting on the following occasions::
-
- * Hildesheim Feb 2003
- * Gothenburg May 2003
- * Europython/Louvain-La-Neuve June 2003
- * Berlin Sept 2003
- * Amsterdam Dec 2003
- * Europython/Gothenburg June 2004
- * Vilnius Nov 2004
- * Leysin Jan 2005
- * PyCon/Washington March 2005
- * Europython/Gothenburg June 2005
- * Hildesheim July 2005
- * Heidelberg Aug 2005
- * Paris Oct 2005
- * Gothenburg Dec 2005
- * Mallorca Jan 2006
- * PyCon/Dallas Feb 2006
- * Louvain-La-Neuve March 2006
- * Leysin April 2006
- * Tokyo April 2006
- * Düsseldorf June 2006
- * Europython/Geneva July 2006
- * Limerick Aug 2006
- * Düsseldorf Oct 2006
- * Leysin Jan 2007
- * Hildesheim Feb 2007
-
-People who have participated and contributed during our sprints and thus
-contributing to PyPy (if we have missed someone here - please contact us
-so we can correct it):
-
- Armin Rigo
- Holger Krekel
- Samuele Pedroni
- Christian Tismer
- Laura Creighton
- Jacob Hallén
- Michael Hudson
- Richard Emslie
- Anders Chrigström
- Alex Martelli
- Ludovic Aubry
- Adrien DiMascio
- Nicholas Chauvat
- Niklaus Haldimann
- Anders Lehmann
- Carl Friedrich Bolz
- Eric Van Riet Paap
- Stephan Diel
- Dinu Gherman
- Jens-Uwe Mager
- Marcus Denker
- Bert Freudenberg
- Gunther Jantzen
- Henrion Benjamin
- Godefroid Chapelle
- Anna Ravenscroft
- Tomek Meka
- Jonathan David Riehl
- Patrick Maupain
- Etienne Posthumus
- Nicola Paolucci
- Albertas Agejevas
- Marius Gedminas
- Jesus Cea Avion
- Olivier Dormond
- Jacek Generowicz
- Brian Dorsey
- Guido van Rossum
- Bob Ippolito
- Alan McIntyre
- Lutz Paelike
- Michael Chermside
- Beatrice Düring
- Boris Feigin
- Amaury Forgeot d'Arc
- Andrew Thompson
- Valentino Volonghi
- Aurelien Campeas
- Stephan Busemann
- Johan Hahn
- Gerald Klix
- Gene Oden
- Josh Gilbert
- Geroge Paci
- Martin Blais
- Stuart Williams
- Jiwon Seo
- Michael Twomey
- Wanja Saatkamp
- Alexandre Fayolle
- Raphaël Collet
- Grégoire Dooms
- Sanghyeon Seo
- Yutaka Niibe
- Yusei Tahara
- George Toshida
- Koichi Sasada
- Guido Wesdorp
- Maciej Fijalkowski
- Antonio Cuni
- Lawrence Oluyede
- Fabrizio Milo
- Alexander Schremmer
- David Douard
- Michele Frettoli
- Simon Burton
- Aaron Bingham
- Pieter Zieschang
- Sad Rejeb
- Brian Sutherland
- Georg Brandl
-
-
diff --git a/pypy/doc/config/translation.fork_before.rst b/pypy/doc/config/translation.fork_before.txt
copy from pypy/doc/config/translation.fork_before.rst
copy to pypy/doc/config/translation.fork_before.txt
diff --git a/pypy/doc/config/translation.builtins_can_raise_exceptions.rst b/pypy/doc/config/translation.builtins_can_raise_exceptions.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.builtins_can_raise_exceptions.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/style.css b/pypy/doc/style.css
deleted file mode 100644
--- a/pypy/doc/style.css
+++ /dev/null
@@ -1,1091 +0,0 @@
-body,body.editor,body.body {
- font: 90% "Times New Roman", Arial, Verdana, Helvetica, serif;
- background: White;
- color: Black;
-}
-
-a, a.reference {
- text-decoration: none;
-}
-a[href]:hover { text-decoration: underline; }
-
-img {
- border: none;
- vertical-align: middle;
-}
-
-p, div.text {
- text-align: left;
- line-height: 1.5em;
- margin: 0.5em 0em 0em 0em;
-}
-
-
-
-p a:active {
- color: Red;
- background-color: transparent;
-}
-
-p img {
- border: 0;
- margin: 0;
-}
-
-img.inlinephoto {
- padding: 0;
- padding-right: 1em;
- padding-top: 0.7em;
- float: left;
-}
-
-hr {
- clear: both;
- height: 1px;
- color: #8CACBB;
- background-color: transparent;
-}
-
-
-ul {
- line-height: 1.5em;
- /*list-style-image: url("bullet.gif"); */
- margin-left: 1.5em;
- padding:0;
-}
-
-ol {
- line-height: 1.5em;
- margin-left: 1.5em;
- padding:0;
-}
-
-ul a, ol a {
- text-decoration: underline;
-}
-
-dl {
-}
-
-dt {
- font-weight: bold;
-}
-
-dd {
- line-height: 1.5em;
- margin-bottom: 1em;
-}
-
-blockquote {
- font-family: Times, "Times New Roman", serif;
- font-style: italic;
- font-size: 120%;
-}
-
-code {
- color: Black;
- /*background-color: #dee7ec;*/
- background-color: #cccccc;
-}
-
-pre {
- padding: 1em;
- border: 1px solid #8cacbb;
- color: Black;
- background-color: #dee7ec;
- background-color: #cccccc;
- overflow: auto;
-}
-
-
-.netscape4 {
- display: none;
-}
-
-/* main page styles */
-
-/*a[href]:hover { color: black; text-decoration: underline; }
-a[href]:link { color: black; text-decoration: underline; }
-a[href] { color: black; text-decoration: underline; }
-*/
-
-span.menu_selected {
- color: black;
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
- padding-right: 0.3em;
- background-color: #cccccc;
-}
-
-
-a.menu {
- /*color: #3ba6ec; */
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
- padding-right: 0.3em;
-}
-
-a.menu[href]:visited, a.menu[href]:link{
- /*color: #3ba6ec; */
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- text-decoration: none;
-}
-
-a.menu[href]:hover {
- /*color: black;*/
-}
-
-div.project_title{
- /*border-spacing: 20px;*/
- font: 160% Verdana, Helvetica, Arial, sans-serif;
- color: #3ba6ec;
- vertical-align: center;
- padding-bottom: 0.3em;
-}
-
-a.wikicurrent {
- font: 100% Verdana, Helvetica, Arial, sans-serif;
- color: #3ba6ec;
- vertical-align: middle;
-}
-
-
-table.body {
- border: 0;
- /*padding: 0;
- border-spacing: 0px;
- border-collapse: separate;
- */
-}
-
-td.page-header-left {
- padding: 5px;
- /*border-bottom: 1px solid #444444;*/
-}
-
-td.page-header-top {
- padding: 0;
-
- /*border-bottom: 1px solid #444444;*/
-}
-
-td.sidebar {
- padding: 1 0 0 1;
-}
-
-td.sidebar p.classblock {
- padding: 0 5 0 5;
- margin: 1 1 1 1;
- border: 1px solid #444444;
- background-color: #eeeeee;
-}
-
-td.sidebar p.userblock {
- padding: 0 5 0 5;
- margin: 1 1 1 1;
- border: 1px solid #444444;
- background-color: #eeeeff;
-}
-
-td.content {
- padding: 1 5 1 5;
- vertical-align: top;
- width: 100%;
-}
-
-p.ok-message {
- background-color: #22bb22;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-p.error-message {
- background-color: #bb2222;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-
-p:first-child {
- margin: 0 ;
- padding: 0;
-}
-
-/* style for forms */
-table.form {
- padding: 2;
- border-spacing: 0px;
- border-collapse: separate;
-}
-
-table.form th {
- color: #333388;
- text-align: right;
- vertical-align: top;
- font-weight: normal;
-}
-table.form th.header {
- font-weight: bold;
- background-color: #eeeeff;
- text-align: left;
-}
-
-table.form th.required {
- font-weight: bold;
-}
-
-table.form td {
- color: #333333;
- empty-cells: show;
- vertical-align: top;
-}
-
-table.form td.optional {
- font-weight: bold;
- font-style: italic;
-}
-
-table.form td.html {
- color: #777777;
-}
-
-/* style for lists */
-table.list {
- border-spacing: 0px;
- border-collapse: separate;
- vertical-align: top;
- padding-top: 0;
- width: 100%;
-}
-
-table.list th {
- padding: 0 4 0 4;
- color: #404070;
- background-color: #eeeeff;
- border-right: 1px solid #404070;
- border-top: 1px solid #404070;
- border-bottom: 1px solid #404070;
- vertical-align: top;
- empty-cells: show;
-}
-table.list th a[href]:hover { color: #404070 }
-table.list th a[href]:link { color: #404070 }
-table.list th a[href] { color: #404070 }
-table.list th.group {
- background-color: #f4f4ff;
- text-align: center;
- font-size: 120%;
-}
-
-table.list td {
- padding: 0 4 0 4;
- border: 0 2 0 2;
- border-right: 1px solid #404070;
- color: #404070;
- background-color: white;
- vertical-align: top;
- empty-cells: show;
-}
-
-table.list tr.normal td {
- background-color: white;
- white-space: nowrap;
-}
-
-table.list tr.alt td {
- background-color: #efefef;
- white-space: nowrap;
-}
-
-table.list td:first-child {
- border-left: 1px solid #404070;
- border-right: 1px solid #404070;
-}
-
-table.list th:first-child {
- border-left: 1px solid #404070;
- border-right: 1px solid #404070;
-}
-
-table.list tr.navigation th {
- text-align: right;
-}
-table.list tr.navigation th:first-child {
- border-right: none;
- text-align: left;
-}
-
-
-/* style for message displays */
-table.messages {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.messages th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.messages th {
- font-weight: bold;
- color: black;
- text-align: left;
- border-bottom: 1px solid #afafaf;
-}
-
-table.messages td {
- font-family: monospace;
- background-color: #efefef;
- border-bottom: 1px solid #afafaf;
- color: black;
- empty-cells: show;
- border-right: 1px solid #afafaf;
- vertical-align: top;
- padding: 2 5 2 5;
-}
-
-table.messages td:first-child {
- border-left: 1px solid #afafaf;
- border-right: 1px solid #afafaf;
-}
-
-/* style for file displays */
-table.files {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.files th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.files th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
-}
-
-table.files td {
- font-family: monospace;
- empty-cells: show;
-}
-
-/* style for history displays */
-table.history {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.history th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
- font-size: 100%;
-}
-
-table.history th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
- font-size: 90%;
-}
-
-table.history td {
- font-size: 90%;
- vertical-align: top;
- empty-cells: show;
-}
-
-
-/* style for class list */
-table.classlist {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.classlist th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.classlist th {
- font-weight: bold;
- text-align: left;
-}
-
-
-/* style for class help display */
-table.classhelp {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.classhelp th {
- font-weight: bold;
- text-align: left;
- color: #707040;
-}
-
-table.classhelp td {
- padding: 2 2 2 2;
- border: 1px solid black;
- text-align: left;
- vertical-align: top;
- empty-cells: show;
-}
-
-
-/* style for "other" displays */
-table.otherinfo {
- border-spacing: 0px;
- border-collapse: separate;
- width: 100%;
-}
-
-table.otherinfo th.header{
- padding-top: 10px;
- border-bottom: 1px solid gray;
- font-weight: bold;
- background-color: white;
- color: #707040;
-}
-
-table.otherinfo th {
- border-bottom: 1px solid #afafaf;
- font-weight: bold;
- text-align: left;
-}
-
-input {
- border: 1px solid #8cacbb;
- color: Black;
- background-color: white;
- vertical-align: middle;
- margin-bottom: 1px; /* IE bug fix */
- padding: 0.1em;
-}
-
-select {
- border: 1px solid #8cacbb;
- color: Black;
- background-color: white;
- vertical-align: middle;
- margin-bottom: 1px; /* IE bug fix */
- padding: 0.1em;
-}
-
-
-a.nonexistent {
- color: #FF2222;
-}
-a.nonexistent:visited {
- color: #FF2222;
-}
-a.external {
- color: #AA6600;
-}
-
-/*
-dl,ul,ol {
- margin-top: 1pt;
-}
-tt,pre {
- font-family: Lucida Console,Courier New,Courier,monotype;
- font-size: 12pt;
-}
-pre.code {
- margin-top: 8pt;
- margin-bottom: 8pt;
- background-color: #FFFFEE;
- white-space:pre;
- border-style:solid;
- border-width:1pt;
- border-color:#999999;
- color:#111111;
- padding:5px;
- width:100%;
-}
-*/
-div.diffold {
- background-color: #FFFF80;
- border-style:none;
- border-width:thin;
- width:100%;
-}
-div.diffnew {
- background-color: #80FF80;
- border-style:none;
- border-width:thin;
- width:100%;
-}
-div.message {
- margin-top: 6pt;
- background-color: #E8FFE8;
- border-style:solid;
- border-width:1pt;
- border-color:#999999;
- color:#440000;
- padding:5px;
- width:100%;
-}
-strong.highlight {
- background-color: #FFBBBB;
-/* as usual, NetScape fucks up with innocent CSS
- border-color: #FFAAAA;
- border-style: solid;
- border-width: 1pt;
-*/
-}
-
-table.navibar {
- background-color: #C8C8C8;
- border-spacing: 3px;
-}
-td.navibar {
- background-color: #E8E8E8;
- vertical-align: top;
- text-align: right;
- padding: 0px;
-}
-
-div.pagename {
- font-size: 140%;
- color: blue;
- text-align: center;
- font-weight: bold;
- background-color: white;
- padding: 0 ;
-}
-
-a.wikiaction, input.wikiaction {
- color: black;
- text-decoration: None;
- text-align: center;
- color: black;
- /*border: 1px solid #3ba6ec; */
- margin: 4px;
- padding: 5;
- padding-bottom: 0;
- white-space: nowrap;
-}
-
-a.wikiaction[href]:hover {
- color: black;
- text-decoration: none;
- /*background-color: #dddddd; */
-}
-
-span.wikiuserpref {
- padding-top: 1em;
- font-size: 120%;
-}
-
-div.wikitrail {
- vertical-align: bottom;
- /*font-size: -1;*/
- padding-top: 1em;
- display: none;
-}
-
-div.wikiaction {
- vertical-align: middle;
- /*border-bottom: 1px solid #8cacbb;*/
- padding-bottom:1em;
- text-align: left;
- width: 100%;
-}
-
-div.wikieditmenu {
- text-align: right;
-}
-
-form.wikiedit {
- border: 1px solid #8cacbb;
- background-color: #f0f0f0;
- background-color: #fabf00;
- padding: 1em;
- padding-right: 0em;
-}
-
-div.legenditem {
- padding-top: 0.5em;
- padding-left: 0.3em;
-}
-
-span.wikitoken {
- background-color: #eeeeee;
-}
-
-
-div#contentspace h1:first-child, div.heading:first-child {
- padding-top: 0;
- margin-top: 0;
-}
-div#contentspace h2:first-child {
- padding-top: 0;
- margin-top: 0;
-}
-
-/* heading and paragraph text */
-
-div.heading, h1 {
- font-family: Verdana, Helvetica, Arial, sans-serif;
- background-color: #58b3ef;
- background-color: #FFFFFF;
- /*color: #4893cf;*/
- color: black;
- padding-top: 1.0em;
- padding-bottom:0.2em;
- text-align: left;
- margin-top: 0em;
- /*margin-bottom:8pt;*/
- font-weight: bold;
- font-size: 115%;
- border-bottom: 1px solid #8CACBB;
-}
-
-
-h1, h2, h3, h4, h5, h6 {
- color: Black;
- clear: left;
- font: 100% Verdana, Helvetica, Arial, sans-serif;
- margin: 0;
- padding-left: 0em;
- padding-top: 1em;
- padding-bottom: 0.2em;
- /*border-bottom: 1px solid #8CACBB;*/
-}
-/* h1,h2 { padding-top: 0; }*/
-
-
-h1 { font-size: 145%; }
-h2 { font-size: 135%; }
-h3 { font-size: 125%; }
-h4 { font-size: 120%; }
-h5 { font-size: 110%; }
-h6 { font-size: 80%; }
-
-h1 a { text-decoration: None;}
-
-div.exception {
- background-color: #bb2222;
- padding: 5 5 5 5;
- color: white;
- font-weight: bold;
-}
-pre.exception {
- font-size: 110%;
- padding: 1em;
- border: 1px solid #8cacbb;
- color: Black;
- background-color: #dee7ec;
- background-color: #cccccc;
-}
-
-/* defines for navgiation bar (documentation) */
-
-
-div.direntry {
- padding-top: 0.3em;
- padding-bottom: 0.3em;
- margin-right: 1em;
- font-weight: bold;
- background-color: #dee7ec;
- font-size: 110%;
-}
-
-div.fileentry {
- font-family: Verdana, Helvetica, Arial, sans-serif;
- padding-bottom: 0.3em;
- white-space: nowrap;
- line-height: 150%;
-}
-
-a.fileentry {
- white-space: nowrap;
-}
-
-
-span.left {
- text-align: left;
-}
-span.right {
- text-align: right;
-}
-
-div.navbar {
- /*margin: 0;*/
- font-size: 80% /*smaller*/;
- font-weight: bold;
- text-align: left;
- /* position: fixed; */
- top: 100pt;
- left: 0pt; /* auto; */
- width: 120pt;
- /* right: auto;
- right: 0pt; 2em; */
-}
-
-
-div.history a {
- /* font-size: 70%; */
-}
-
-div.wikiactiontitle {
- font-weight: bold;
-}
-
-/* REST defines */
-
-div.document {
- margin: 0;
-}
-
-h1.title {
- margin: 0;
-}
-
-td.toplist {
- vertical-align: top;
-}
-
-img#pyimg {
- position: absolute;
- top: 0px;
- left: 20px;
- margin: 20px;
-}
-
-img#extraimg {
- position: absolute;
- right: 14px;
- top: 4px;
-}
-
-div#navspace {
- position: absolute;
- top: 130px;
- left: 11px;
- font-size: 100%;
- width: 150px;
- overflow: hidden; /* scroll; */
-}
-
-div#metaspace {
- position: absolute;
- top: 40px;
- left: 210px;
-}
-
-div#errorline {
- position: relative;
- top: 5px;
- float: right;
-}
-
-div#contentspace {
- position: absolute;
- /* font: 120% "Times New Roman", serif;*/
- font: 110% Verdana, Helvetica, Arial, sans-serif;
- top: 140px;
- left: 130px;
- margin-right: 140px;
-}
-
-div#menubar {
-/* width: 400px; */
- float: left;
-}
-
-/* for the documentation page */
-div#docinfoline {
- position: relative;
- top: 5px;
- left: 0px;
-
- /*background-color: #dee7ec; */
- padding: 5pt;
- padding-bottom: 1em;
- color: black;
- /*border-width: 1pt;
- border-style: solid;*/
-
-}
-
-div#docnavlist {
- /*background-color: #dee7ec; */
- padding: 5pt;
- padding-bottom: 2em;
- color: black;
- border-width: 1pt;
- /*border-style: solid;*/
-}
-
-
-/* text markup */
-
-div.listtitle {
- color: Black;
- clear: left;
- font: 120% Verdana, Helvetica, Arial, sans-serif;
- margin: 0;
- padding-left: 0em;
- padding-top: 0em;
- padding-bottom: 0.2em;
- margin-right: 0.5em;
- border-bottom: 1px solid #8CACBB;
-}
-
-div.actionbox h3 {
- padding-top: 0;
- padding-right: 0.5em;
- padding-left: 0.5em;
- background-color: #fabf00;
- text-align: center;
- border: 1px solid black; /* 8cacbb; */
-}
-
-div.actionbox a {
- display: block;
- padding-bottom: 0.5em;
- padding-top: 0.5em;
- margin-left: 0.5em;
-}
-
-div.actionbox a.history {
- display: block;
- padding-bottom: 0.5em;
- padding-top: 0.5em;
- margin-left: 0.5em;
- font-size: 90%;
-}
-
-div.actionbox {
- margin-bottom: 2em;
- padding-bottom: 1em;
- overflow: hidden; /* scroll; */
-}
-
-/* taken from docutils (oh dear, a bit senseless) */
-ol.simple, ul.simple {
- margin-bottom: 1em }
-
-ol.arabic {
- list-style: decimal }
-
-ol.loweralpha {
- list-style: lower-alpha }
-
-ol.upperalpha {
- list-style: upper-alpha }
-
-ol.lowerroman {
- list-style: lower-roman }
-
-ol.upperroman {
- list-style: upper-roman }
-
-
-/*
-:Author: David Goodger
-:Contact: goodger at users.sourceforge.net
-:date: $Date: 2003/01/22 22:26:48 $
-:version: $Revision: 1.29 $
-:copyright: This stylesheet has been placed in the public domain.
-
-Default cascading style sheet for the HTML output of Docutils.
-*/
-/*
-.first {
- margin-top: 0 }
-
-.last {
- margin-bottom: 0 }
-
-a.toc-backref {
- text-decoration: none ;
- color: black }
-
-dd {
- margin-bottom: 0.5em }
-
-div.abstract {
- margin: 2em 5em }
-
-div.abstract p.topic-title {
- font-weight: bold ;
- text-align: center }
-
-div.attention, div.caution, div.danger, div.error, div.hint,
-div.important, div.note, div.tip, div.warning {
- margin: 2em ;
- border: medium outset ;
- padding: 1em }
-
-div.attention p.admonition-title, div.caution p.admonition-title,
-div.danger p.admonition-title, div.error p.admonition-title,
-div.warning p.admonition-title {
- color: red ;
- font-weight: bold ;
- font-family: sans-serif }
-
-div.hint p.admonition-title, div.important p.admonition-title,
-div.note p.admonition-title, div.tip p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
-div.dedication {
- margin: 2em 5em ;
- text-align: center ;
- font-style: italic }
-
-div.dedication p.topic-title {
- font-weight: bold ;
- font-style: normal }
-
-div.figure {
- margin-left: 2em }
-
-div.footer, div.header {
- font-size: smaller }
-
-div.system-messages {
- margin: 5em }
-
-div.system-messages h1 {
- color: red }
-
-div.system-message {
- border: medium outset ;
- padding: 1em }
-
-div.system-message p.system-message-title {
- color: red ;
- font-weight: bold }
-
-div.topic {
- margin: 2em }
-
-h1.title {
- text-align: center }
-
-h2.subtitle {
- text-align: center }
-
-hr {
- width: 75% }
-
-p.caption {
- font-style: italic }
-
-p.credits {
- font-style: italic ;
- font-size: smaller }
-
-p.label {
- white-space: nowrap }
-
-p.topic-title {
- font-weight: bold }
-
-pre.address {
- margin-bottom: 0 ;
- margin-top: 0 ;
- font-family: serif ;
- font-size: 100% }
-
-pre.line-block {
- font-family: serif ;
- font-size: 100% }
-
-pre.literal-block, pre.doctest-block {
- margin-left: 2em ;
- margin-right: 2em ;
- background-color: #eeeeee }
-
-span.classifier {
- font-family: sans-serif ;
- font-style: oblique }
-
-span.classifier-delimiter {
- font-family: sans-serif ;
- font-weight: bold }
-
-span.interpreted {
- font-family: sans-serif }
-
-span.option {
- white-space: nowrap }
-
-span.option-argument {
- font-style: italic }
-
-span.pre {
- white-space: pre }
-
-span.problematic {
- color: red }
-
-table {
- margin-top: 0.5em ;
- margin-bottom: 0.5em }
-
-table.citation {
- border-left: solid thin gray ;
- padding-left: 0.5ex }
-
-table.docinfo {
- margin: 2em 4em }
-
-table.footnote {
- border-left: solid thin black ;
- padding-left: 0.5ex }
-
-td, th {
- padding-left: 0.5em ;
- padding-right: 0.5em ;
- vertical-align: top }
-
-th.docinfo-name, th.field-name {
- font-weight: bold ;
- text-align: left ;
- white-space: nowrap }
-
-h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
- font-size: 100% }
-
-tt {
- background-color: #eeeeee }
-
-ul.auto-toc {
- list-style-type: none }
-*/
-
-div.section {
- margin-top: 1.0em ;
-}
-
-div.abstract {
- margin: 2em 4em }
-
-div.abstract p.topic-title {
- font-weight: bold ;
- text-align: center }
diff --git a/pypy/doc/config/translation.gcremovetypeptr.rst b/pypy/doc/config/translation.gcremovetypeptr.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.gcremovetypeptr.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-If set, save one word in every object. Framework GC only.
diff --git a/pypy/doc/config/objspace.usemodules._lsprof.rst b/pypy/doc/config/objspace.usemodules._lsprof.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._lsprof.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the '_lsprof' module.
diff --git a/pypy/doc/config/translation.jit_profiler.rst b/pypy/doc/config/translation.jit_profiler.txt
copy from pypy/doc/config/translation.jit_profiler.rst
copy to pypy/doc/config/translation.jit_profiler.txt
diff --git a/pypy/doc/config/objspace.usemodules._sha.rst b/pypy/doc/config/objspace.usemodules._sha.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._sha.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Use the built-in _'sha' module.
-This module is expected to be working and is included by default.
-There is also a pure Python version in lib_pypy which is used
-if the built-in is disabled, but it is several orders of magnitude
-slower.
diff --git a/pypy/doc/config/translation.shared.rst b/pypy/doc/config/translation.shared.txt
copy from pypy/doc/config/translation.shared.rst
copy to pypy/doc/config/translation.shared.txt
diff --git a/pypy/doc/config/translation.force_make.rst b/pypy/doc/config/translation.force_make.txt
copy from pypy/doc/config/translation.force_make.rst
copy to pypy/doc/config/translation.force_make.txt
diff --git a/pypy/doc/config/objspace.usemodules.rbench.rst b/pypy/doc/config/objspace.usemodules.rbench.txt
copy from pypy/doc/config/objspace.usemodules.rbench.rst
copy to pypy/doc/config/objspace.usemodules.rbench.txt
diff --git a/pypy/config/makerestdoc.py b/pypy/config/makerestdoc.py
--- a/pypy/config/makerestdoc.py
+++ b/pypy/config/makerestdoc.py
@@ -28,9 +28,6 @@
fullpath = get_fullpath(self, path)
result = Rest(
Title(fullpath, abovechar="=", belowchar="="),
- Directive("contents"),
- Paragraph(Link("back to parent", path + ".html")),
- Title("Basic Option Information"),
ListItem(Strong("name:"), self._name),
ListItem(Strong("description:"), self.doc))
if self.cmdline is not None:
@@ -132,47 +129,27 @@
def make_rest_doc(self, path=""):
fullpath = get_fullpath(self, path)
content = Rest(
- Title(fullpath, abovechar="=", belowchar="="),
- Directive("contents"))
- if path:
- content.add(
- Paragraph(Link("back to parent", path + ".html")))
+ Title(fullpath, abovechar="=", belowchar="="))
+ toctree = []
+ for child in self._children:
+ subpath = fullpath + "." + child._name
+ toctree.append(subpath)
+ content.add(Directive("toctree", *toctree, maxdepth=4))
content.join(
- Title("Basic Option Information"),
ListItem(Strong("name:"), self._name),
- ListItem(Strong("description:"), self.doc),
- Title("Sub-Options"))
+ ListItem(Strong("description:"), self.doc))
stack = []
- prefix = fullpath
curr = content
config = Config(self)
- for ending in self.getpaths(include_groups=True):
- subpath = fullpath + "." + ending
- while not (subpath.startswith(prefix) and
- subpath[len(prefix)] == "."):
- curr, prefix = stack.pop()
- print subpath, fullpath, ending, curr
- sub, step = config._cfgimpl_get_home_by_path(ending)
- doc = getattr(sub._cfgimpl_descr, step).doc
- if doc:
- new = curr.add(ListItem(Link(subpath + ":", subpath + ".html"),
- Em(doc)))
- else:
- new = curr.add(ListItem(Link(subpath + ":", subpath + ".html")))
- stack.append((curr, prefix))
- prefix = subpath
- curr = new
return content
def _get_section_header(cmdline, fullpath, subdescr):
# XXX: pypy specific hack
txtfile = configdocdir.join(fullpath + ".txt")
- print txtfile,
if not txtfile.check():
- print "not found"
+ print txtfile, "not found"
return ""
- print "found"
content = txtfile.read()
if ".. internal" in content:
return "Internal Options"
@@ -221,7 +198,7 @@
from docutils import nodes
from pypy.config.pypyoption import get_pypy_config
from pypy.config.makerestdoc import get_cmdline
- txt = docdir.join("config", text + ".txt")
+ txt = docdir.join("config", text + ".rst")
html = docdir.join("config", text + ".html")
assert txt.check()
assert name == "config"
@@ -247,9 +224,8 @@
shortest_long_option = cmd
text = shortest_long_option
target = prefix + relative
- print text, target
reference_node = nodes.reference(rawtext, text, name=text, refuri=target)
return [reference_node], []
config_role.content = True
config_role.options = {}
- roles.register_canonical_role("config", config_role)
+ return config_role
diff --git a/pypy/doc/config/translation.instrumentctl.rst b/pypy/doc/config/translation.instrumentctl.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.instrumentctl.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/discussion/cli-optimizations.rst b/pypy/doc/discussion/cli-optimizations.rst
deleted file mode 100644
--- a/pypy/doc/discussion/cli-optimizations.rst
+++ /dev/null
@@ -1,233 +0,0 @@
-Possible optimizations for the CLI backend
-==========================================
-
-Stack push/pop optimization
----------------------------
-
-The CLI's VM is a stack based machine: this fact doesn't play nicely
-with the SSI form the flowgraphs are generated in. At the moment
-gencli does a literal translation of the SSI statements, allocating a
-new local variable for each variable of the flowgraph.
-
-For example, consider the following RPython code and the corresponding
-flowgraph::
-
- def bar(x, y):
- foo(x+y, x-y)
-
-
- inputargs: x_0 y_0
- v0 = int_add(x_0, y_0)
- v1 = int_sub(x_0, y_0)
- v2 = directcall((sm foo), v0, v1)
-
-This is the IL code generated by the CLI backend::
-
- .locals init (int32 v0, int32 v1, int32 v2)
-
- block0:
- ldarg 'x_0'
- ldarg 'y_0'
- add
- stloc 'v0'
- ldarg 'x_0'
- ldarg 'y_0'
- sub
- stloc 'v1'
- ldloc 'v0'
- ldloc 'v1'
- call int32 foo(int32, int32)
- stloc 'v2'
-
-As you can see, the results of 'add' and 'sub' are stored in v0 and
-v1, respectively, then v0 and v1 are reloaded onto stack. These
-store/load is redundant, since the code would work nicely even without
-them::
-
- .locals init (int32 v2)
-
- block0:
- ldarg 'x_0'
- ldarg 'y_0'
- add
- ldarg 'x_0'
- ldarg 'y_0'
- sub
- call int32 foo(int32, int32)
- stloc 'v2'
-
-I've checked the native code generated by the Mono Jit on x86 and I've
-seen that it does not optimize it. I haven't checked the native code
-generated by Microsoft CLR, yet.
-
-Thus, we might consider to optimize it manually; it should not be so
-difficult, but it is not trivial because we have to make sure that the
-dropped locals are used only once.
-
-
-Mapping RPython exceptions to native CLI exceptions
----------------------------------------------------
-
-Both RPython and CLI have its own set of exception classes: some of
-these are pretty similar; e.g., we have OverflowError,
-ZeroDivisionError and IndexError on the first side and
-OverflowException, DivideByZeroException and IndexOutOfRangeException
-on the other side.
-
-The first attempt was to map RPython classes to their corresponding
-CLI ones: this worked for simple cases, but it would have triggered
-subtle bugs in more complex ones, because the two exception
-hierarchies don't completely overlap.
-
-For now I've chosen to build an RPython exception hierarchy
-completely independent from the CLI one, but this means that we can't
-rely on exceptions raised by standard operations. The currently
-implemented solution is to do an exception translation on-the-fly; for
-example, the 'ind_add_ovf' is translated into the following IL code::
-
- .try
- {
- ldarg 'x_0'
- ldarg 'y_0'
- add.ovf
- stloc 'v1'
- leave __check_block_2
- }
- catch [mscorlib]System.OverflowException
- {
- newobj instance void class exceptions.OverflowError::.ctor()
- dup
- ldsfld class Object_meta pypy.runtime.Constants::exceptions_OverflowError_meta
- stfld class Object_meta Object::meta
- throw
- }
-
-I.e., it catches the builtin OverflowException and raises a RPython
-OverflowError.
-
-I haven't measured timings yet, but I guess that this machinery brings
-to some performance penalties even in the non-overflow case; a
-possible optimization is to do the on-the-fly translation only when it
-is strictly necessary, i.e. only when the except clause catches an
-exception class whose subclass hierarchy is compatible with the
-builtin one. As an example, consider the following RPython code::
-
- try:
- return mylist[0]
- except IndexError:
- return -1
-
-Given that IndexError has no subclasses, we can map it to
-IndexOutOfBoundException and directly catch this one::
-
- try
- {
- ldloc 'mylist'
- ldc.i4 0
- call int32 getitem(MyListType, int32)
- ...
- }
- catch [mscorlib]System.IndexOutOfBoundException
- {
- // return -1
- ...
- }
-
-By contrast we can't do so if the except clause catches classes that
-don't directly map to any builtin class, such as LookupError::
-
- try:
- return mylist[0]
- except LookupError:
- return -1
-
-Has to be translated in the old way::
-
- .try
- {
- ldloc 'mylist'
- ldc.i4 0
-
- .try
- {
- call int32 getitem(MyListType, int32)
- }
- catch [mscorlib]System.IndexOutOfBoundException
- {
- // translate IndexOutOfBoundException into IndexError
- newobj instance void class exceptions.IndexError::.ctor()
- dup
- ldsfld class Object_meta pypy.runtime.Constants::exceptions_IndexError_meta
- stfld class Object_meta Object::meta
- throw
- }
- ...
- }
- .catch exceptions.LookupError
- {
- // return -1
- ...
- }
-
-
-Specializing methods of List
-----------------------------
-
-Most methods of RPython lists are implemented by ll_* helpers placed
-in rpython/rlist.py. For some of those we have a direct correspondent
-already implemented in .NET List<>; we could use the oopspec attribute
-for doing an on-the-fly replacement of these low level helpers with
-their builtin correspondent. As an example the 'append' method is
-already mapped to pypylib.List.append. Thanks to Armin Rigo for the
-idea of using oopspec.
-
-
-Doing some caching on Dict
---------------------------
-
-The current implementations of ll_dict_getitem and ll_dict_get in
-ootypesystem.rdict do two consecutive lookups (calling ll_contains and
-ll_get) on the same key. We might cache the result of
-pypylib.Dict.ll_contains so that the successive ll_get don't need a
-lookup. Btw, we need some profiling before choosing the best way. Or
-we could directly refactor ootypesystem.rdict for doing a single
-lookup.
-
-XXX
-I tried it on revision 32917 and performance are slower! I don't know
-why, but pypy.net pystone.py is slower by 17%, and pypy.net
-richards.py is slower by 71% (!!!). I don't know why, need to be
-investigated further.
-
-
-Optimize StaticMethod
----------------------
-
-::
-
- 2006-10-02, 13:41
-
- <pedronis> antocuni: do you try to not wrap static methods that are just called and not passed around
- <antocuni> no
- I think I don't know how to detect them
- <pedronis> antocuni: you should try to render them just as static methods not as instances when possible
- you need to track what appears only in direct_calls vs other places
-
-
-Optimize Unicode
-----------------
-
-We should try to use native .NET unicode facilities instead of our
-own. These should save both time (especially startup time) and memory.
-
-On 2006-10-02 I got these benchmarks:
-
-Pypy.NET Startup time Memory used
-with unicodedata ~12 sec 112508 Kb
-without unicodedata ~6 sec 79004 Kb
-
-The version without unicodedata is buggy, of course.
-
-Unfortunately it seems that .NET doesn't expose all the things we
-need, so we will still need some data. For example there is no way to
-get the unicode name of a char.
diff --git a/pypy/doc/config/translation.backendopt.constfold.rst b/pypy/doc/config/translation.backendopt.constfold.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.constfold.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Do constant folding of operations and constant propagation on flowgraphs.
diff --git a/pypy/doc/config/objspace.usemodules.pyexpat.rst b/pypy/doc/config/objspace.usemodules.pyexpat.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.pyexpat.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use (experimental) pyexpat module written in RPython, instead of CTypes
-version which is used by default.
diff --git a/pypy/doc/glossary.rst b/pypy/doc/glossary.rst
--- a/pypy/doc/glossary.rst
+++ b/pypy/doc/glossary.rst
@@ -1,3 +1,5 @@
+.. include:: needswork.txt
+
.. _glossary:
********
@@ -12,219 +14,145 @@
.. glossary::
-**abstract interpretation**
- The technique of interpreting the bytecode of a user program with
- an interpreter that handles abstract objects instead of concrete ones.
- It can be used to check the bytecode or see what it does, without
- actually executing it with concrete values. See Theory_.
+ annotator
+ The component of the :term:`RPython toolchain` that performs a form
+ of :term:`type inference` on the flow graph. See the `annotator pass`_
+ in the documentation.
-.. _annotator:
+ application level
+ applevel_ code is normal Python code running on top of the PyPy or
+ :term:`CPython` interpreter (see :term:`interpreter level`)
-**annotator**
- The component of the translator_\ 's toolchain_ that performs a form
- of `type inference`_ on the flow graph. See the `annotator pass`_
- in the documentation.
+ backend
+ Code generator that converts an `RPython
+ <coding-guide.html#restricted-python>`__ program to a `target
+ language`_ using the :term:`RPython toolchain`. A backend uses either the
+ :term:`lltypesystem` or the :term:`ootypesystem`.
-.. _`application level`:
+ compile-time
+ In the context of the :term:`JIT`, compile time is when the JIT is
+ generating machine code "just in time".
-**application level**
- applevel_ code is normal Python code running on top of the PyPy or
- CPython_ interpreter (see `interpreter level`_)
+ CPython
+ The "default" implementation of Python, written in C and
+ distributed by the PSF_ on http://www.python.org.
-.. _backend:
+ external function
+ Functions that we don't want to implement in Python for various
+ reasons (e.g. they need to make calls into the OS) and whose
+ implementation will be provided by the backend.
-**backend**
- Code generator that converts an `RPython
- <coding-guide.html#restricted-python>`__ program to a `target
- language`_ using the PyPy toolchain_. A backend uses either the
- lltypesystem_ or the ootypesystem_.
+ garbage collection framework
+ Code that makes it possible to write `PyPy's garbage collectors`_
+ in Python itself.
-.. _`compile-time`:
+ interpreter level
+ Code running at this level is part of the implementation of the
+ PyPy interpreter and cannot interact normally with :term:`application
+ level` code; it typically provides implementation for an object
+ space and its builtins.
-**compile-time**
- In the context of the JIT_, compile time is when the JIT is
- generating machine code "just in time".
+ jit
+ `just in time compiler`_.
-.. _CPython:
+ llinterpreter
+ Piece of code that is able to interpret flow graphs. This is very
+ useful for testing purposes, especially if you work on the :term:`RPython`
+ Typer.
-**CPython**
- The "default" implementation of Python, written in C and
- distributed by the PSF_ on http://www.python.org.
+ lltypesystem
+ A `C-like type model <rtyper.html#low-level-types>`__ that contains
+ structs and pointers. A :term:`backend` that uses this type system is also
+ called a low-level backend. The C backend uses this
+ typesystem.
-.. _`external function`:
+ low-level helper
+ A function that the :term:`RTyper` can use a call to as part of implementing
+ some operation in terms of the target :term:`type system`.
-**external function**
- Functions that we don't want to implement in Python for various
- reasons (e.g. they need to make calls into the OS) and whose
- implementation will be provided by the backend.
+ mixed module
+ a module that accesses PyPy's :term:`interpreter level`. The name comes
+ from the fact that the module's implementation can be a mixture of
+ :term:`application level` and :term:`interpreter level` code.
-.. _`garbage collection framework`:
+ object space
+ The `object space <objspace.html>`__ (often abbreviated to
+ "objspace") creates all objects and knows how to perform operations
+ on the objects. You may think of an object space as being a library
+ offering a fixed API, a set of operations, with implementations
+ that a) correspond to the known semantics of Python objects, b)
+ extend or twist these semantics, or c) serve whole-program analysis
+ purposes.
-**garbage collection framework**
- Code that makes it possible to write `PyPy's garbage collectors`_
- in Python itself.
+ ootypesystem
+ An `object oriented type model <rtyper.html#object-oriented-types>`__
+ containing classes and instances. A :term:`backend` that uses this type system
+ is also called a high-level backend. The JVM and CLI backends
+ all use this typesystem.
-.. _`interpreter level`:
+ prebuilt constant
+ In :term:`RPython` module globals are considered constants. Moreover,
+ global (i.e. prebuilt) lists and dictionaries are supposed to be
+ immutable ("prebuilt constant" is sometimes abbreviated to "pbc").
-**interpreter level**
- Code running at this level is part of the implementation of the
- PyPy interpreter and cannot interact normally with `application
- level`_ code; it typically provides implementation for an object
- space and its builtins.
+ promotion
+ :term:`JIT` terminology. *promotion* is a way of "using" a :term:`run-time`
+ value at :term:`compile-time`, essentially by deferring compilation
+ until the run-time value is known. See if `the jit docs`_ help.
-.. _`jit`:
+ RPython
+ `Restricted Python`_, a limited subset of the Python_ language.
+ The limitations make :term:`type inference` possible.
+ It is also the language that the PyPy interpreter itself is written
+ in.
-**jit**
- `just in time compiler`_.
+ RPython toolchain
+ The `annotator pass`_, `The RPython Typer`_, and various
+ :term:`backend`\ s.
-.. _llinterpreter:
+ rtyper
+ Based on the type annotations, the `RPython Typer`_ turns the flow
+ graph into one that fits the model of the target platform/:term:`backend`
+ using either the :term:`lltypesystem` or the :term:`ootypesystem`.
-**llinterpreter**
- Piece of code that is able to interpret flow graphs. This is very
- useful for testing purposes, especially if you work on the RPython_
- Typer.
+ run-time
+ In the context of the :term:`JIT`, run time is when the code the JIT has
+ generated is executing.
-.. _lltypesystem:
+ specialization
+ A way of controlling how a specific function is handled by the
+ :term:`annotator`. One specialization is to treat calls to a function
+ with different argument types as if they were calls to different
+ functions with identical source.
-**lltypesystem**
- A `C-like type model <rtyper.html#low-level-types>`__ that contains
- structs and pointers. A backend_ that uses this type system is also
- called a low-level backend. The C backend uses this
- typesystem.
+ stackless
+ Technology that enables various forms of non conventional control
+ flow, such as coroutines, greenlets and tasklets. Inspired by
+ Christian Tismer's `Stackless Python <http://www.stackless.com>`__.
-.. _`low-level helper`:
+ standard interpreter
+ It is the `subsystem implementing the Python language`_, composed
+ of the bytecode interpreter and of the standard objectspace.
-**low-level helper**
- A function that the RTyper_ can use a call to as part of implementing
- some operation in terms of the target `type system`_.
+ transformation
+ Code that modifies flowgraphs to weave in translation aspects
-.. _`mixed module`:
+ translation-time
+ In the context of the :term:`JIT`, translation time is when the PyPy
+ source is being analyzed and the JIT itself is being created.
-**mixed module**
- a module that accesses PyPy's `interpreter level`_. The name comes
- from the fact that the module's implementation can be a mixture of
- `application level`_ and `interpreter level`_ code.
+ translator
+ Tool_ based on the PyPy interpreter which can translate
+ sufficiently static Python programs into low-level code.
-.. _`object space`:
+ type system
+ The RTyper can target either the :term:`lltypesystem` or the :term:`ootypesystem`.
-**multimethod**
- A callable object that invokes a different Python function based
- on the type of all its arguments (instead of just the class of the
- first argument, as with normal methods). See Theory_.
-
-**object space**
- The `object space <objspace.html>`__ (often abbreviated to
- "objspace") creates all objects and knows how to perform operations
- on the objects. You may think of an object space as being a library
- offering a fixed API, a set of operations, with implementations
- that a) correspond to the known semantics of Python objects, b)
- extend or twist these semantics, or c) serve whole-program analysis
- purposes.
-
-.. _ootypesystem:
-
-**ootypesystem**
- An `object oriented type model <rtyper.html#object-oriented-types>`__
- containing classes and instances. A backend_ that uses this type system
- is also called a high-level backend. The JVM and CLI backends
- all use this typesystem.
-
-.. _`prebuilt constant`:
-
-**prebuilt constant**
- In RPython_ module globals are considered constants. Moreover,
- global (i.e. prebuilt) lists and dictionaries are supposed to be
- immutable ("prebuilt constant" is sometimes abbreviated to "pbc").
-
-.. _`rpython`:
-
-.. _`promotion`:
-
-**promotion**
- JIT_ terminology. *promotion* is a way of "using" a `run-time`_
- value at `compile-time`_, essentially by deferring compilation
- until the run-time value is known. See if `the jit docs`_ help.
-
-**rpython**
- `Restricted Python`_, a limited subset of the Python_ language.
- The limitations make `type inference`_ possible.
- It is also the language that the PyPy interpreter itself is written
- in.
-
-.. _`rtyper`:
-
-**rtyper**
- Based on the type annotations, the `RPython Typer`_ turns the flow
- graph into one that fits the model of the target platform/backend_
- using either the lltypesystem_ or the ootypesystem_.
-
-.. _`run-time`:
-
-**run-time**
- In the context of the JIT_, run time is when the code the JIT has
- generated is executing.
-
-.. _`specialization`:
-
-**specialization**
- A way of controlling how a specific function is handled by the
- annotator_. One specialization is to treat calls to a function
- with different argument types as if they were calls to different
- functions with identical source.
-
-.. _`stackless`:
-
-**stackless**
- Technology that enables various forms of non conventional control
- flow, such as coroutines, greenlets and tasklets. Inspired by
- Christian Tismer's `Stackless Python <http://www.stackless.com>`__.
-
-.. _`standard interpreter`:
-
-**standard interpreter**
- It is the `subsystem implementing the Python language`_, composed
- of the bytecode interpreter and of the standard objectspace.
-
-.. _toolchain:
-
-**timeshifting**
- JIT_ terminology. *timeshifting* is to do with moving from the
- world where there are only `run-time`_ operations to a world where
- there are both `run-time`_ and `compile-time`_ operations.
-
-**toolchain**
- The `annotator pass`_, `The RPython Typer`_, and various
- `backends`_.
-
-.. _`transformation`:
-
-**transformation**
- Code that modifies flowgraphs to weave in `translation-aspects`_
-
-.. _`translation-time`:
-
-**translation-time**
- In the context of the JIT_, translation time is when the PyPy
- source is being analyzed and the JIT itself is being created.
-
-.. _`translator`:
-
-**translator**
- Tool_ based on the PyPy interpreter which can translate
- sufficiently static Python programs into low-level code.
-
-.. _`type system`:
-
-**type system**
- The RTyper can target either the lltypesystem_ or the ootypesystem_.
-
-.. _`type inference`:
-
-**type inference**
- Deduces either partially or fully the type of expressions as
- described in this `type inference article on Wikipedia`_.
- PyPy's tool-chain own flavour of type inference is described
- in the `annotator pass`_ section.
+ type inference
+ Deduces either partially or fully the type of expressions as
+ described in this `type inference article on Wikipedia`_.
+ The :term:`RPython toolchain`'s flavour of type inference is described
+ in the `annotator pass`_ section.
.. _applevel: coding-guide.html#application-level
.. _`target language`: getting-started-dev.html#trying-out-the-translator
@@ -235,13 +163,11 @@
.. _`The RPython Typer`: translation.html#the-rpython-typer
.. _`backends`: getting-started-dev.html#trying-out-the-translator
.. _Tool: getting-started-dev.html#trying-out-the-translator
-.. _`translation-aspects`: translation-aspects.html
.. _`PyPy's garbage collectors`: garbage_collection.html
.. _`Restricted Python`: coding-guide.html#restricted-python
.. _PSF: http://www.python.org/psf/
.. _Python: http://www.python.org
.. _`RPython Typer`: rtyper.html
.. _`subsystem implementing the Python language`: architecture.html#standard-interpreter
-.. _Theory: theory.html
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.usemodules.binascii.rst b/pypy/doc/config/objspace.usemodules.binascii.txt
copy from pypy/doc/config/objspace.usemodules.binascii.rst
copy to pypy/doc/config/objspace.usemodules.binascii.txt
diff --git a/pypy/doc/config/translation.type_system.rst b/pypy/doc/config/translation.type_system.txt
copy from pypy/doc/config/translation.type_system.rst
copy to pypy/doc/config/translation.type_system.txt
diff --git a/pypy/doc/config/objspace.logbytecodes.rst b/pypy/doc/config/objspace.logbytecodes.txt
copy from pypy/doc/config/objspace.logbytecodes.rst
copy to pypy/doc/config/objspace.logbytecodes.txt
diff --git a/pypy/doc/config/objspace.std.withtypeversion.rst b/pypy/doc/config/objspace.std.withtypeversion.txt
copy from pypy/doc/config/objspace.std.withtypeversion.rst
copy to pypy/doc/config/objspace.std.withtypeversion.txt
diff --git a/pypy/doc/config/objspace.usemodules._io.rst b/pypy/doc/config/objspace.usemodules._io.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._io.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_io module.
-Used by the 'io' standard lib module. This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules._lsprof.rst b/pypy/doc/config/objspace.usemodules._lsprof.txt
copy from pypy/doc/config/objspace.usemodules._lsprof.rst
copy to pypy/doc/config/objspace.usemodules._lsprof.txt
diff --git a/pypy/doc/config/translation.backendopt.remove_asserts.rst b/pypy/doc/config/translation.backendopt.remove_asserts.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.remove_asserts.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Remove raising of assertions from the flowgraphs, which might give small speedups.
diff --git a/pypy/doc/config/objspace.translationmodules.rst b/pypy/doc/config/objspace.translationmodules.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.translationmodules.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-This option enables all modules which are needed to translate PyPy using PyPy.
diff --git a/pypy/doc/release-1.5.0.rst b/pypy/doc/release-1.5.0.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/release-1.5.0.rst
@@ -0,0 +1,73 @@
+======================
+PyPy 1.5: Catching Up
+======================
+
+We're pleased to announce the 1.5 release of PyPy. This release updates
+PyPy with the features of CPython 2.7.1, including the standard library. Thus
+all the features of `CPython 2.6`_ and `CPython 2.7`_ are now supported. It
+also contains additional performance improvements. You can download it here:
+
+ http://pypy.org/download.html
+
+What is PyPy?
+=============
+
+PyPy is a very compliant Python interpreter, almost a drop-in replacement for
+CPython 2.7.1. It's fast (`pypy 1.5 and cpython 2.6.2`_ performance comparison)
+due to its integrated tracing JIT compiler.
+
+This release includes the features of CPython 2.6 and 2.7. It also includes a
+large number of small improvements to the tracing JIT compiler. It supports
+Intel machines running Linux 32/64 or Mac OS X. Windows is beta (it roughly
+works but a lot of small issues have not been fixed so far). Windows 64 is
+not yet supported.
+
+Numerous speed achievements are described on `our blog`_. Normalized speed
+charts comparing `pypy 1.5 and pypy 1.4`_ as well as `pypy 1.5 and cpython
+2.6.2`_ are available on our benchmark website. The speed improvement over 1.4
+seems to be around 25% on average.
+
+More highlights
+===============
+
+- The largest change in PyPy's tracing JIT is adding support for `loop invariant
+ code motion`_, which was mostly done by Håkan Ardö. This feature improves the
+ performance of tight loops doing numerical calculations.
+
+- The CPython extension module API has been improved and now supports many more
+ extensions. For information on which one are supported, please refer to our
+ `compatibility wiki`_.
+
+- These changes make it possible to support `Tkinter and IDLE`_.
+
+- The `cProfile`_ profiler is now working with the JIT. However, it skews the
+ performance in unstudied ways. Therefore it is not yet usable to analyze
+ subtle performance problems (the same is true for CPython of course).
+
+- There is an `external fork`_ which includes an RPython version of the
+ ``postgresql``. However, there are no prebuilt binaries for this.
+
+- Our developer documentation was moved to Sphinx and cleaned up. It now lives
+ on http://pypy.readthedocs.org
+
+- and many small things :-)
+
+
+Cheers,
+
+Carl Friedrich Bolz, Laura Creighton, Antonio Cuni, Maciej Fijalkowski,
+Amaury Forgeot d'Arc, Alex Gaynor, Armin Rigo and the PyPy team
+
+
+.. _`CPython 2.6`: http://docs.python.org/dev/whatsnew/2.6.html
+.. _`CPython 2.7`: http://docs.python.org/dev/whatsnew/2.7.html
+
+.. _`our blog`: http://morepypy.blogspot.com
+.. _`pypy 1.5 and pypy 1.4`: http://bit.ly/joPhHo
+.. _`pypy 1.5 and cpython 2.6.2`: http://bit.ly/mbVWwJ
+
+.. _`loop invariant code motion`: http://morepypy.blogspot.com/2011/01/loop-invariant-code-motion.html
+.. _`compatibility wiki`: https://bitbucket.org/pypy/compatibility/wiki/Home
+.. _`Tkinter and IDLE`: http://morepypy.blogspot.com/2011/04/using-tkinter-and-idle-with-pypy.html
+.. _`cProfile`: http://docs.python.org/library/profile.html
+.. _`external fork`: https://bitbucket.org/alex_gaynor/pypy-postgresql
diff --git a/pypy/doc/config/objspace.usemodules.array.rst b/pypy/doc/config/objspace.usemodules.array.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.array.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use interpreter-level version of array module (on by default).
diff --git a/pypy/doc/config/objspace.usemodules._file.rst b/pypy/doc/config/objspace.usemodules._file.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._file.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the '_file' module. It is an internal module that contains helper
-functionality for the builtin ``file`` type.
-
-.. internal
diff --git a/pypy/doc/config/objspace.usemodules.termios.rst b/pypy/doc/config/objspace.usemodules.termios.txt
copy from pypy/doc/config/objspace.usemodules.termios.rst
copy to pypy/doc/config/objspace.usemodules.termios.txt
diff --git a/pypy/doc/config/translation.backendopt.mallocs.rst b/pypy/doc/config/translation.backendopt.mallocs.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.mallocs.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-This optimization enables "malloc removal", which "explodes"
-allocations of structures which do not escape from the function they
-are allocated in into one or more additional local variables.
-
-An example. Consider this rather unlikely seeming code::
-
- class C:
- pass
- def f(y):
- c = C()
- c.x = y
- return c.x
-
-Malloc removal will spot that the ``C`` object can never leave ``f``
-and replace the above with code like this::
-
- def f(y):
- _c__x = y
- return _c__x
-
-It is rare for code to be directly written in a way that allows this
-optimization to be useful, but inlining often results in opportunities
-for its use (and indeed, this is one of the main reasons PyPy does its
-own inlining rather than relying on the C compilers).
-
-For much more information about this and other optimizations you can
-read section 4.1 of the technical report on "Massive Parallelism and
-Translation Aspects" which you can find on the `Technical reports page
-<../index-report.html>`__.
diff --git a/pypy/doc/discussion/finalizer-order.rst b/pypy/doc/discussion/finalizer-order.rst
--- a/pypy/doc/discussion/finalizer-order.rst
+++ b/pypy/doc/discussion/finalizer-order.rst
@@ -1,3 +1,6 @@
+.. XXX armin, what do we do with this?
+
+
Ordering finalizers in the SemiSpace GC
=======================================
diff --git a/pypy/doc/config/objspace.opcodes.rst b/pypy/doc/config/objspace.opcodes.txt
copy from pypy/doc/config/objspace.opcodes.rst
copy to pypy/doc/config/objspace.opcodes.txt
diff --git a/pypy/doc/config/objspace.usemodules._locale.rst b/pypy/doc/config/objspace.usemodules._locale.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._locale.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the '_locale' module.
-This module runs _locale written in RPython (instead of ctypes version).
-It's not really finished yet; it's enabled by default on Windows.
diff --git a/pypy/doc/config/makemodules.py b/pypy/doc/config/makemodules.py
--- a/pypy/doc/config/makemodules.py
+++ b/pypy/doc/config/makemodules.py
@@ -7,12 +7,12 @@
if __name__ == '__main__':
c = config.Config(pypyoption.pypy_optiondescription).usemodules
prefix = "objspace.usemodules"
- thisdir.join(prefix + ".txt").ensure()
+ thisdir.join(prefix + ".rst").ensure()
for p in c.getpaths(include_groups=True):
- basename = prefix + "." + p + ".txt"
+ basename = prefix + "." + p + ".rst"
f = thisdir.join(basename)
- if f.check() and f.size():
- continue
+ #if f.check() and f.size():
+ # continue
print "making docs for", p
text = ["Use the '%s' module. " % (p, )]
if p in pypyoption.essential_modules:
diff --git a/pypy/doc/config/objspace.std.withtproxy.rst b/pypy/doc/config/objspace.std.withtproxy.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withtproxy.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Enable `transparent proxies`_.
-
-.. _`transparent proxies`: ../objspace-proxies.html#tproxy
diff --git a/pypy/doc/config/objspace.usemodules.cStringIO.rst b/pypy/doc/config/objspace.usemodules.cStringIO.txt
copy from pypy/doc/config/objspace.usemodules.cStringIO.rst
copy to pypy/doc/config/objspace.usemodules.cStringIO.txt
diff --git a/pypy/doc/config/objspace.usemodules.thread.rst b/pypy/doc/config/objspace.usemodules.thread.txt
copy from pypy/doc/config/objspace.usemodules.thread.rst
copy to pypy/doc/config/objspace.usemodules.thread.txt
diff --git a/pypy/doc/config/objspace.std.logspaceoptypes.rst b/pypy/doc/config/objspace.std.logspaceoptypes.txt
copy from pypy/doc/config/objspace.std.logspaceoptypes.rst
copy to pypy/doc/config/objspace.std.logspaceoptypes.txt
diff --git a/pypy/doc/config/translation.simplifying.rst b/pypy/doc/config/translation.simplifying.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.simplifying.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.txt
copy from pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.rst
copy to pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.txt
diff --git a/pypy/doc/jit/pyjitpl5.rst b/pypy/doc/jit/pyjitpl5.rst
--- a/pypy/doc/jit/pyjitpl5.rst
+++ b/pypy/doc/jit/pyjitpl5.rst
@@ -10,8 +10,8 @@
The JIT's `theory`_ is great in principle, but the actual code is a different
story. This section tries to give a high level overview of how PyPy's JIT is
-implemented. It's helpful to have an understanding of how the PyPy `translation
-tool chain`_ works before digging into the sources.
+implemented. It's helpful to have an understanding of how the `RPython translation
+toolchain`_ works before digging into the sources.
Almost all JIT specific code is found in pypy/jit subdirectories. Translation
time code is in the codewriter directory. The metainterp directory holds
@@ -19,7 +19,7 @@
the backend directory is responsible for generating machine code.
.. _`theory`: overview.html
-.. _`translation tool chain`: ../translation.html
+.. _`RPython translation toolchain`: ../translation.html
JIT hints
@@ -160,8 +160,11 @@
in the machine code. Virtualizables, however, can escape from JIT controlled
code.
-Most of the JIT's optimizer is contained 2 files optimizefindnodes.py and
-optimizeopt.py.
+Other optimizations
+*******************
+
+Most of the JIT's optimizer is contained in the subdirectory
+``metainterp/optimizeopt/``. Refer to it for more details.
More resources
diff --git a/pypy/doc/config/objspace.usemodules.cStringIO.rst b/pypy/doc/config/objspace.usemodules.cStringIO.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.cStringIO.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the built-in cStringIO module.
-
-If not enabled, importing cStringIO gives you the app-level
-implementation from the standard library StringIO module.
diff --git a/pypy/doc/image/compat-matrix.sxc b/pypy/doc/image/compat-matrix.sxc
index 8086ba6179a7bcd49f43067ae42a80f2a5d3cca3..ab8455241eda4ec63bf647905b63bf9849fb8675
GIT binary patch
[cut]
diff --git a/pypy/doc/config/objspace.usemodules._stackless.rst b/pypy/doc/config/objspace.usemodules._stackless.txt
copy from pypy/doc/config/objspace.usemodules._stackless.rst
copy to pypy/doc/config/objspace.usemodules._stackless.txt
diff --git a/pypy/doc/discussion/gc.rst b/pypy/doc/discussion/gc.rst
deleted file mode 100644
--- a/pypy/doc/discussion/gc.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-
-*Note: this things are experimental and are being implemented on the
-`io-improvements`_ branch*
-
-.. _`io-improvements`: http://codespeak.net/svn/pypy/branch/io-improvements
-
-=============
-GC operations
-=============
-
-This document tries to gather gc-related issues which are very recent
-or in-development. Also, it tries to document needed gc refactorings
-and expected performance of certain gc-related operations.
-
-Problem area
-============
-
-Since some of our gcs are moving, we at some point decided to simplify
-the issue of having care of it by always copying the contents of
-data that goes to C level. This yields a performance penalty, also
-because some gcs does not move data around anyway.
-
-So we decided to introduce new operations which will simplify issues
-regarding this.
-
-Pure gc operations
-==================
-
-(All available from rlib.rgc)
-
-* can_move(p) - returns a flag telling whether pointer p will move.
- useful for example when you want to know whether memcopy is safe.
-
-* malloc_nonmovable(TP, n=None) - tries to allocate non-moving object.
- if it succeeds, it return an object, otherwise (for whatever reasons)
- returns null pointer. Does not raise! (never)
-
-Usage patterns
-==============
-
-Usually those functions are used via helpers located in rffi. For things like
-os.write - first get_nonmovingbuffer(data) that will give you a pointer
-suitable of passing to C and finally free_nonmovingbuffer.
-
-For os.read like usage - you first call alloc_buffer (that will allocate a
-buffer of desired size passable to C) and afterwards create str_from_buffer,
-finally calling keep_buffer_alive_until_here.
-
-String builder
-==============
-
-In Python strings are immutable by design. In RPython this still yields true,
-but since we cooperate with lower (C/POSIX) level, which has no notion of
-strings, we use buffers. Typical use case is to use list of characters l and
-than ''.join(l) in order to get string. This requires a lot of unnecessary
-copying, which yields performance penalty for such operations as string
-formatting. Hence the idea of string builder. String builder would be an
-object to which you can append strings or characters and afterwards build it
-to a string. Ideally, this set of operations would not contain any copying
-whatsoever.
-
-Low level gc operations for string builder
-------------------------------------------
-
-* alloc_buffer(T, size) - allocates Array(nolength=True) with possibility
- of later becoming of shape T
-
-* realloc_buffer(buf, newsize) - tries to shrink or enlarge buffer buf. Returns
- new pointer (since it might involve copying)
-
-* build_buffer(T, buf) - creates a type T (previously passed to alloc_buffer)
- from buffer.
-
-Depending on a gc, those might be implemented dumb (realloc always copies)
-or using C-level realloc. Might be implemented also in whatever clever way
-comes to mind.
-
diff --git a/pypy/doc/config/translation.instrument.rst b/pypy/doc/config/translation.instrument.txt
copy from pypy/doc/config/translation.instrument.rst
copy to pypy/doc/config/translation.instrument.txt
diff --git a/pypy/doc/config/translation.rweakref.rst b/pypy/doc/config/translation.rweakref.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.rweakref.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-This indicates if the backend and GC policy support RPython-level weakrefs.
-Can be tested in an RPython program to select between two implementation
-strategies.
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.rst b/pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Internal option. Switch to a different weight heuristic for inlining.
-This is for profile-based inlining (:config:`translation.backendopt.profile_based_inline`).
-
-.. internal
diff --git a/pypy/doc/config/translation.insist.rst b/pypy/doc/config/translation.insist.txt
copy from pypy/doc/config/translation.insist.rst
copy to pypy/doc/config/translation.insist.txt
diff --git a/pypy/doc/config/objspace.std.withstrslice.rst b/pypy/doc/config/objspace.std.withstrslice.txt
copy from pypy/doc/config/objspace.std.withstrslice.rst
copy to pypy/doc/config/objspace.std.withstrslice.txt
diff --git a/pypy/doc/config/objspace.usemodules._ssl.rst b/pypy/doc/config/objspace.usemodules._ssl.txt
copy from pypy/doc/config/objspace.usemodules._ssl.rst
copy to pypy/doc/config/objspace.usemodules._ssl.txt
diff --git a/pypy/doc/config/translation.linkerflags.rst b/pypy/doc/config/translation.linkerflags.txt
copy from pypy/doc/config/translation.linkerflags.rst
copy to pypy/doc/config/translation.linkerflags.txt
diff --git a/pypy/doc/config/translation.withsmallfuncsets.rst b/pypy/doc/config/translation.withsmallfuncsets.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.withsmallfuncsets.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Represent function sets smaller than this option's value as an integer instead
-of a function pointer. A call is then done via a switch on that integer, which
-allows inlining etc. Small numbers for this can speed up PyPy (try 5).
diff --git a/pypy/doc/config/objspace.usemodules.math.rst b/pypy/doc/config/objspace.usemodules.math.txt
copy from pypy/doc/config/objspace.usemodules.math.rst
copy to pypy/doc/config/objspace.usemodules.math.txt
diff --git a/pypy/doc/docindex.rst b/pypy/doc/docindex.rst
deleted file mode 100644
--- a/pypy/doc/docindex.rst
+++ /dev/null
@@ -1,314 +0,0 @@
-=================================================
-PyPy - a Python_ implementation written in Python
-=================================================
-
-.. _Python: http://www.python.org/doc/2.5.2/
-
-
-.. contents:: :depth: 1
-
-
-PyPy User Documentation
-===============================================
-
-`getting started`_ provides hands-on instructions
-including a two-liner to run the PyPy Python interpreter
-on your system, examples on advanced features and
-entry points for using PyPy's translation tool chain.
-
-`FAQ`_ contains some frequently asked questions.
-
-New features of PyPy's Python Interpreter and
-Translation Framework:
-
- * `Differences between PyPy and CPython`_
- * `What PyPy can do for your objects`_
- * `Stackless and coroutines`_
- * `JIT Generation in PyPy`_
- * `Sandboxing Python code`_
-
-Status_ of the project.
-
-
-Project Documentation
-=====================================
-
-PyPy was funded by the EU for several years. See the `web site of the EU
-project`_ for more details.
-
-.. _`web site of the EU project`: http://pypy.org
-
-architecture_ gives a complete view of PyPy's basic design.
-
-`coding guide`_ helps you to write code for PyPy (especially also describes
-coding in RPython a bit).
-
-`sprint reports`_ lists reports written at most of our sprints, from
-2003 to the present.
-
-`papers, talks and related projects`_ lists presentations
-and related projects as well as our published papers.
-
-`ideas for PyPy related projects`_ which might be a good way to get
-into PyPy.
-
-`PyPy video documentation`_ is a page linking to the videos (e.g. of talks and
-introductions) that are available.
-
-`Technical reports`_ is a page that contains links to the
-reports that we submitted to the European Union.
-
-`development methodology`_ describes our sprint-driven approach.
-
-`license`_ contains licensing details (basically a straight MIT-license).
-
-`Glossary`_ of PyPy words to help you align your inner self with
-the PyPy universe.
-
-
-Status
-===================================
-
-PyPy can be used to run Python programs on Linux, OS/X,
-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 latest release, which is `1.2.0`__.
-
-.. __: 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
-them. Linux 64-bit machines are supported (though it may also take some
-time before we notice and fix bugs).
-
-PyPy's own tests `summary`_, daily updated, run through BuildBot infrastructure.
-You can also find CPython's compliance tests run with compiled ``pypy-c``
-executables there.
-
-information dating from early 2007:
-
-`PyPy LOC statistics`_ shows LOC statistics about PyPy.
-
-`PyPy statistics`_ is a page with various statistics about the PyPy project.
-
-`compatibility matrix`_ is a diagram that shows which of the various features
-of the PyPy interpreter work together with which other features.
-
-
-Source Code Documentation
-===============================================
-
-`object spaces`_ discusses the object space interface
-and several implementations.
-
-`bytecode interpreter`_ explains the basic mechanisms
-of the bytecode interpreter and virtual machine.
-
-`interpreter optimizations`_ describes our various strategies for
-improving the performance of our interpreter, including alternative
-object implementations (for strings, dictionaries and lists) in the
-standard object space.
-
-`translation`_ is a detailed overview of our translation process. The
-rtyper_ is the largest component of our translation process.
-
-`dynamic-language translation`_ is a paper that describes
-the translation process, especially the flow object space
-and the annotator in detail. (This document is one
-of the `EU reports`_.)
-
-`low-level encapsulation`_ describes how our approach hides
-away a lot of low level details. This document is also part
-of the `EU reports`_.
-
-`translation aspects`_ describes how we weave different
-properties into our interpreter during the translation
-process. This document is also part of the `EU reports`_.
-
-`garbage collector`_ strategies that can be used by the virtual
-machines produced by the translation process.
-
-`parser`_ contains (outdated, unfinished) documentation about
-the parser.
-
-`rlib`_ describes some modules that can be used when implementing programs in
-RPython.
-
-`configuration documentation`_ describes the various configuration options that
-allow you to customize PyPy.
-
-`CLI backend`_ describes the details of the .NET backend.
-
-`JIT Generation in PyPy`_ describes how we produce the Python Just-in-time Compiler
-from our Python interpreter.
-
-
-
-.. _`FAQ`: faq.html
-.. _Glossary: glossary.html
-.. _`PyPy video documentation`: video-index.html
-.. _parser: parser.html
-.. _`development methodology`: dev_method.html
-.. _`sprint reports`: sprint-reports.html
-.. _`papers, talks and related projects`: extradoc.html
-.. _`license`: ../../LICENSE
-.. _`PyPy LOC statistics`: http://codespeak.net/~hpk/pypy-stat/
-.. _`PyPy statistics`: http://codespeak.net/pypy/trunk/pypy/doc/statistic
-.. _`object spaces`: objspace.html
-.. _`interpreter optimizations`: interpreter-optimizations.html
-.. _`translation`: translation.html
-.. _`dynamic-language translation`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
-.. _`low-level encapsulation`: low-level-encapsulation.html
-.. _`translation aspects`: translation-aspects.html
-.. _`configuration documentation`: config/
-.. _`coding guide`: coding-guide.html
-.. _`architecture`: architecture.html
-.. _`getting started`: getting-started.html
-.. _`theory`: theory.html
-.. _`bytecode interpreter`: interpreter.html
-.. _`EU reports`: index-report.html
-.. _`Technical reports`: index-report.html
-.. _`summary`: http://codespeak.net:8099/summary
-.. _`ideas for PyPy related projects`: project-ideas.html
-.. _`Nightly builds and benchmarks`: http://tuatara.cs.uni-duesseldorf.de/benchmark.html
-.. _`directory reference`:
-.. _`rlib`: rlib.html
-.. _`Sandboxing Python code`: sandbox.html
-
-PyPy directory cross-reference
-------------------------------
-
-Here is a fully referenced alphabetical two-level deep
-directory overview of PyPy:
-
-============================ ===========================================
-Directory explanation/links
-============================ ===========================================
-`annotation/`_ `type inferencing code`_ for `RPython`_ programs
-
-`bin/`_ command-line scripts, mainly `py.py`_ and `translatorshell.py`_
-
-`config/`_ handles the numerous options for building and running PyPy
-
-`doc/`_ text versions of PyPy developer documentation
-
-`doc/config/`_ documentation for the numerous translation options
-
-`doc/discussion/`_ drafts of ideas and documentation
-
-``doc/*/`` other specific documentation topics or tools
-
-`interpreter/`_ `bytecode interpreter`_ and related objects
- (frames, functions, modules,...)
-
-`interpreter/pyparser/`_ interpreter-level Python source parser
-
-`interpreter/astcompiler/`_ interpreter-level bytecode compiler, via an AST
- representation
-
-`module/`_ contains `mixed modules`_ implementing core modules with
- both application and interpreter level code.
- Not all are finished and working. Use the ``--withmod-xxx``
- or ``--allworkingmodules`` translation options.
-
-`objspace/`_ `object space`_ implementations
-
-`objspace/trace.py`_ the `trace object space`_ monitoring bytecode and space operations
-
-`objspace/dump.py`_ the dump object space saves a large, searchable log file
- with all operations
-
-`objspace/taint.py`_ the `taint object space`_, providing object tainting
-
-`objspace/thunk.py`_ the `thunk object space`_, providing unique object features
-
-`objspace/flow/`_ the FlowObjSpace_ implementing `abstract interpretation`
-
-`objspace/std/`_ the StdObjSpace_ implementing CPython's objects and types
-
-`rlib/`_ a `"standard library"`_ for RPython_ programs
-
-`rpython/`_ the `RPython Typer`_
-
-`rpython/lltypesystem/`_ the `low-level type system`_ for C-like backends
-
-`rpython/ootypesystem/`_ the `object-oriented type system`_ for OO backends
-
-`rpython/memory/`_ the `garbage collector`_ construction framework
-
-`tool/`_ various utilities and hacks used from various places
-
-`tool/algo/`_ general-purpose algorithmic and mathematic
- tools
-
-`tool/pytest/`_ support code for our `testing methods`_
-
-`translator/`_ translation_ backends and support code
-
-`translator/backendopt/`_ general optimizations that run before a backend generates code
-
-`translator/c/`_ the `GenC backend`_, producing C code from an
- RPython program (generally via the rtyper_)
-
-`translator/cli/`_ the `CLI backend`_ for `.NET`_ (Microsoft CLR or Mono_)
-
-`translator/goal/`_ our `main PyPy-translation scripts`_ live here
-
-`translator/jvm/`_ the Java backend
-
-`translator/stackless/`_ the `Stackless Transform`_
-
-`translator/tool/`_ helper tools for translation, including the Pygame
- `graph viewer`_
-
-``*/test/`` many directories have a test subdirectory containing test
- modules (see `Testing in PyPy`_)
-
-``_cache/`` holds cache files from internally `translating application
- level to interpreterlevel`_ code.
-============================ ===========================================
-
-.. _`bytecode interpreter`: interpreter.html
-.. _`translating application level to interpreterlevel`: geninterp.html
-.. _`Testing in PyPy`: coding-guide.html#testing-in-pypy
-.. _`mixed modules`: coding-guide.html#mixed-modules
-.. _`modules`: coding-guide.html#modules
-.. _`basil`: http://people.cs.uchicago.edu/~jriehl/BasilTalk.pdf
-.. _`object space`: objspace.html
-.. _FlowObjSpace: objspace.html#the-flow-object-space
-.. _`trace object space`: objspace.html#the-trace-object-space
-.. _`taint object space`: objspace-proxies.html#taint
-.. _`thunk object space`: objspace-proxies.html#thunk
-.. _`transparent proxies`: objspace-proxies.html#tproxy
-.. _`Differences between PyPy and CPython`: cpython_differences.html
-.. _`What PyPy can do for your objects`: objspace-proxies.html
-.. _`Stackless and coroutines`: stackless.html
-.. _StdObjSpace: objspace.html#the-standard-object-space
-.. _`abstract interpretation`: theory.html#abstract-interpretation
-.. _`rpython`: coding-guide.html#rpython
-.. _`type inferencing code`: translation.html#the-annotation-pass
-.. _`RPython Typer`: translation.html#rpython-typer
-.. _`testing methods`: coding-guide.html#testing-in-pypy
-.. _`translation`: translation.html
-.. _`GenC backend`: translation.html#genc
-.. _`CLI backend`: cli-backend.html
-.. _`py.py`: getting-started-python.html#the-py.py-interpreter
-.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
-.. _JIT: jit/index.html
-.. _`JIT Generation in PyPy`: jit/index.html
-.. _`just-in-time compiler generator`: jit/index.html
-.. _rtyper: rtyper.html
-.. _`low-level type system`: rtyper.html#low-level-type
-.. _`object-oriented type system`: rtyper.html#oo-type
-.. _`garbage collector`: garbage_collection.html
-.. _`Stackless Transform`: translation.html#the-stackless-transform
-.. _`main PyPy-translation scripts`: getting-started-python.html#translating-the-pypy-python-interpreter
-.. _`.NET`: http://www.microsoft.com/net/
-.. _Mono: http://www.mono-project.com/
-.. _`"standard library"`: rlib.html
-.. _`graph viewer`: getting-started-dev.html#try-out-the-translator
-.. _`compatibility matrix`: image/compat-matrix.png
-
-.. include:: _ref.rst
-
diff --git a/pypy/doc/config/objspace.usemodules.errno.rst b/pypy/doc/config/objspace.usemodules.errno.txt
copy from pypy/doc/config/objspace.usemodules.errno.rst
copy to pypy/doc/config/objspace.usemodules.errno.txt
diff --git a/pypy/doc/config/objspace.usemodules.itertools.rst b/pypy/doc/config/objspace.usemodules.itertools.txt
copy from pypy/doc/config/objspace.usemodules.itertools.rst
copy to pypy/doc/config/objspace.usemodules.itertools.txt
diff --git a/pypy/doc/config/translation.cli.exception_transformer.rst b/pypy/doc/config/translation.cli.exception_transformer.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.cli.exception_transformer.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the exception transformer instead of the native .NET exceptions to
-implement RPython exceptions. Enable this option only if you know what
-you are doing.
diff --git a/pypy/doc/config/objspace.usemodules.marshal.rst b/pypy/doc/config/objspace.usemodules.marshal.txt
copy from pypy/doc/config/objspace.usemodules.marshal.rst
copy to pypy/doc/config/objspace.usemodules.marshal.txt
diff --git a/pypy/doc/config/objspace.std.withsmallint.rst b/pypy/doc/config/objspace.std.withsmallint.txt
copy from pypy/doc/config/objspace.std.withsmallint.rst
copy to pypy/doc/config/objspace.std.withsmallint.txt
diff --git a/pypy/translator/cli/test/mylib.py b/pypy/translator/cli/test/mylib.py
deleted file mode 100644
--- a/pypy/translator/cli/test/mylib.py
+++ /dev/null
@@ -1,5 +0,0 @@
-from pypy.translator.cli.carbonpython import export
-
- at export(int, int)
-def sum(a, b):
- return a+b
diff --git a/pypy/doc/config/objspace.usemodules._sre.rst b/pypy/doc/config/objspace.usemodules._sre.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._sre.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_sre' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/translation.backendopt.print_statistics.rst b/pypy/doc/config/translation.backendopt.print_statistics.txt
copy from pypy/doc/config/translation.backendopt.print_statistics.rst
copy to pypy/doc/config/translation.backendopt.print_statistics.txt
diff --git a/pypy/doc/config/translation.taggedpointers.rst b/pypy/doc/config/translation.taggedpointers.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.taggedpointers.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Enable tagged pointers. This option is mostly useful for the Smalltalk and
-Prolog interpreters. For the Python interpreter the option
-:config:`objspace.std.withsmallint` should be used.
diff --git a/pypy/doc/crufty.rst b/pypy/doc/crufty.rst
deleted file mode 100644
--- a/pypy/doc/crufty.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. warning::
-
- This documentation may be out-of-date or obsolete (identified on 2011-03-14 at the PyCon US sprint)
diff --git a/pypy/doc/config/objspace.usemodules.imp.rst b/pypy/doc/config/objspace.usemodules.imp.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.imp.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'imp' module.
-This module is included by default.
diff --git a/pypy/doc/config/objspace.usemodules.time.rst b/pypy/doc/config/objspace.usemodules.time.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.time.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the 'time' module.
-
-Obsolete; use :config:`objspace.usemodules.rctime` for our up-to-date version
-of the application-level 'time' module.
diff --git a/pypy/doc/config/objspace.std.withtproxy.rst b/pypy/doc/config/objspace.std.withtproxy.txt
copy from pypy/doc/config/objspace.std.withtproxy.rst
copy to pypy/doc/config/objspace.std.withtproxy.txt
diff --git a/pypy/doc/config/translation.output.rst b/pypy/doc/config/translation.output.txt
copy from pypy/doc/config/translation.output.rst
copy to pypy/doc/config/translation.output.txt
diff --git a/pypy/doc/image/parsing_example3.dot b/pypy/doc/image/parsing_example3.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example3.dot
+++ /dev/null
@@ -1,13 +0,0 @@
-digraph G{
-"-1219325716" [label="n"];
-"-1219325716" -> "-1219325844";
-"-1219325844" [shape=box,label="__0_A\n'A'"];
-"-1219325716" -> "-1219324372";
-"-1219324372" [label="n"];
-"-1219324372" -> "-1219325524";
-"-1219325524" [shape=box,label="__0_A\n'A'"];
-"-1219324372" -> "-1219324308";
-"-1219324308" [label="n"];
-"-1219324308" -> "-1219325492";
-"-1219325492" [shape=box,label="__0_A\n'A'"];
-}
diff --git a/pypy/doc/config/objspace.std.mutable_builtintypes.rst b/pypy/doc/config/objspace.std.mutable_builtintypes.txt
copy from pypy/doc/config/objspace.std.mutable_builtintypes.rst
copy to pypy/doc/config/objspace.std.mutable_builtintypes.txt
diff --git a/pypy/doc/discussion/distribution-implementation.rst b/pypy/doc/discussion/distribution-implementation.rst
deleted file mode 100644
--- a/pypy/doc/discussion/distribution-implementation.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-=====================================================
-Random implementation details of distribution attempt
-=====================================================
-
-.. contents::
-.. sectnum::
-
-This document attempts to broaden this `dist thoughts`_.
-
-.. _`dist thoughts`: distribution-newattempt.html
-
-Basic implementation:
----------------------
-
-First we do split objects into value-only primitives (like int) and other.
-Basically immutable builtin types which cannot contain user-level objects
-(int, float, long, str, None, etc.) will be always transferred as value-only
-objects (having no states etc.). The every other object (user created classes,
-instances, modules, lists, tuples, etc. etc.) are always executed by reference.
-(Of course if somebody wants to ie. copy the instance, he can marshal/pickle
-this to string and send, but it's outside the scope of this attempt). Special
-case might be immutable data structure (tuple, frozenset) containing simple
-types (this becomes simple type).
-
-XXX: What to do with code types? Marshalling them and sending seems to have no
-sense. Remote execution? Local execution with remote f_locals and f_globals?
-
-Every remote object has got special class W_RemoteXXX where XXX is interp-level
-class implementing this object. W_RemoteXXX implements all the operations
-by using special app-level code that sends method name and arguments over the wire
-(arguments might be either simple objects which are simply send over the app-level
-code or references to local objects).
-
-So the basic scheme would look like::
-
- remote_ref = remote("Object reference")
- remote_ref.any_method()
-
-``remote_ref`` in above example looks like normal python object to user,
-but is implemented differently (W_RemoteXXX), and uses app-level proxy
-to forward each interp-level method call.
-
-Abstraction layers:
--------------------
-
-In this section we define remote side as a side on which calls are
-executed and local side is the one on which calls are run.
-
-* Looking from the local side, first thing that we see is object
- which looks like normal object (has got the same interp-level typedef)
- but has got different implementation. Basically this is the shallow copy
- of remote object (however you define shallow, it's up to the code which
- makes the copy. Basically the copy which can be marshalled or send over
- the wire or saved for future purpose). This is W_RemoteXXX where XXX is
- real object name. Some operations on that object requires accessing remote
- side of the object, some might not need such (for example remote int
- is totally the same int as local one, it could not even be implemented
- differently).
-
-* For every interp-level operation, which accesses internals that are not
- accessible at the local side, (basically all attribute accesses which
- are accessing things that are subclasses of W_Object) we provide special
- W_Remote version, which downloads necessary object when needed
- (if accessed). This is the same as normal W_RemoteXXX (we know the type!)
- but not needed yet.
-
-* From the remote point of view, every exported object which needs such
- has got a local appropriate storage W_LocalXXX where XXX is a type
- by which it could be accessed from a wire.
-
-The real pain:
---------------
-
-For every attribute access when we get W_RemoteXXX, we need to check
-the download flag - which sucks a bit. (And we have to support it somehow
-in annotator, which sucks a lot). The (some) idea is to wrap all the methods
-with additional checks, but that's both unclear and probably not necessary.
-
-XXX If we can easily change underlying implementation of an object, than
-this might become way easier. Right now I'll try to have it working and
-thing about RPython later.
-
-App-level remote tool:
-----------------------
-
-For purpose of app-level tool which can transfer the data (well, socket might
-be enough, but suppose I want to be more flexible), I would use `py.execnet`_,
-probably using some of the Armin's hacks to rewrite it using greenlets instead
-of threads.
-
-.. _`py.execnet`: http://codespeak.net/py/current/doc/execnet.html
diff --git a/pypy/doc/config/translation.backendopt.print_statistics.rst b/pypy/doc/config/translation.backendopt.print_statistics.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.print_statistics.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Debugging option. Print statics about the forest of flowgraphs as they
-go through the various backend optimizations.
\ No newline at end of file
diff --git a/pypy/doc/config/objspace.usemodules._locale.rst b/pypy/doc/config/objspace.usemodules._locale.txt
copy from pypy/doc/config/objspace.usemodules._locale.rst
copy to pypy/doc/config/objspace.usemodules._locale.txt
diff --git a/pypy/doc/config/translation.backendopt.really_remove_asserts.rst b/pypy/doc/config/translation.backendopt.really_remove_asserts.rst
deleted file mode 100644
diff --git a/pypy/doc/config/objspace.usemodules._warnings.rst b/pypy/doc/config/objspace.usemodules._warnings.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._warnings.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the '_warning' module. This module is expected to be working and is included by default.
diff --git a/pypy/doc/image/parsing_example8.dot b/pypy/doc/image/parsing_example8.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example8.dot
+++ /dev/null
@@ -1,21 +0,0 @@
-digraph G{
-"-1213611892" [label="list"];
-"-1213611892" -> "-1213608980";
-"-1213608980" [shape=box,label="DECIMAL\n'1'"];
-"-1213611892" -> "-1213623476";
-"-1213623476" [label="list"];
-"-1213623476" -> "-1213623380";
-"-1213623380" [shape=box,label="DECIMAL\n'2'"];
-"-1213623476" -> "-1213442868";
-"-1213442868" [label="list"];
-"-1213442868" -> "-1213441652";
-"-1213441652" [shape=box,label="DECIMAL\n'3'"];
-"-1213442868" -> "-1213441332";
-"-1213441332" [label="list"];
-"-1213441332" -> "-1213441620";
-"-1213441620" [shape=box,label="DECIMAL\n'4'"];
-"-1213441332" -> "-1213443060";
-"-1213443060" [label="list"];
-"-1213443060" -> "-1213442100";
-"-1213442100" [shape=box,label="DECIMAL\n'5'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/discussion/GC-performance.rst b/pypy/doc/discussion/GC-performance.rst
deleted file mode 100644
--- a/pypy/doc/discussion/GC-performance.rst
+++ /dev/null
@@ -1,118 +0,0 @@
-StartHeapsize# is the framework GC as of revision 31586 with initial
-bytes_malloced_threshold of 2-512 MB
-
-NewHeuristics is the framework GC with a new heuristics for adjusting
-the bytes_malloced_threshold
-
-::
-
- Pystone
- StartHeapsize2:
- This machine benchmarks at 5426.92 pystones/second
- This machine benchmarks at 5193.91 pystones/second
- This machine benchmarks at 5403.46 pystones/second
- StartHeapsize8:
- This machine benchmarks at 6075.33 pystones/second
- This machine benchmarks at 6007.21 pystones/second
- This machine benchmarks at 6122.45 pystones/second
- StartHeapsize32:
- This machine benchmarks at 6643.05 pystones/second
- This machine benchmarks at 6590.51 pystones/second
- This machine benchmarks at 6593.41 pystones/second
- StartHeapsize128:
- This machine benchmarks at 7065.47 pystones/second
- This machine benchmarks at 7102.27 pystones/second
- This machine benchmarks at 7082.15 pystones/second
- StartHeapsize512:
- This machine benchmarks at 7208.07 pystones/second
- This machine benchmarks at 7197.7 pystones/second
- This machine benchmarks at 7246.38 pystones/second
- NewHeuristics:
- This machine benchmarks at 6821.28 pystones/second
- This machine benchmarks at 6858.71 pystones/second
- This machine benchmarks at 6902.9 pystones/second
-
-
- Richards
- StartHeapSize2:
- Average time per iteration: 5456.21 ms
- Average time per iteration: 5529.31 ms
- Average time per iteration: 5398.82 ms
- StartHeapsize8:
- Average time per iteration: 4775.43 ms
- Average time per iteration: 4753.25 ms
- Average time per iteration: 4781.37 ms
- StartHeapsize32:
- Average time per iteration: 4554.84 ms
- Average time per iteration: 4501.86 ms
- Average time per iteration: 4531.59 ms
- StartHeapsize128:
- Average time per iteration: 4329.42 ms
- Average time per iteration: 4360.87 ms
- Average time per iteration: 4392.81 ms
- StartHeapsize512:
- Average time per iteration: 4371.72 ms
- Average time per iteration: 4399.70 ms
- Average time per iteration: 4354.66 ms
- NewHeuristics:
- Average time per iteration: 4763.56 ms
- Average time per iteration: 4803.49 ms
- Average time per iteration: 4840.68 ms
-
-
- translate rpystone
- time pypy-c translate --text --batch --backendopt --no-compile targetrpystonedalone.py
- StartHeapSize2:
- real 1m38.459s
- user 1m35.582s
- sys 0m0.440s
- StartHeapsize8:
- real 1m35.398s
- user 1m33.878s
- sys 0m0.376s
- StartHeapsize32:
- real 1m5.475s
- user 1m5.108s
- sys 0m0.180s
- StartHeapsize128:
- real 0m52.941s
- user 0m52.395s
- sys 0m0.328s
- StartHeapsize512:
- real 1m3.727s
- user 0m50.031s
- sys 0m1.240s
- NewHeuristics:
- real 0m53.449s
- user 0m52.771s
- sys 0m0.356s
-
-
- docutils
- time pypy-c rst2html doc/coding-guide.txt
- StartHeapSize2:
- real 0m36.125s
- user 0m35.562s
- sys 0m0.088s
- StartHeapsize8:
- real 0m32.678s
- user 0m31.106s
- sys 0m0.084s
- StartHeapsize32:
- real 0m22.041s
- user 0m21.085s
- sys 0m0.132s
- StartHeapsize128:
- real 0m19.350s
- user 0m18.653s
- sys 0m0.324s
- StartHeapsize512:
- real 0m19.116s
- user 0m17.517s
- sys 0m0.620s
- NewHeuristics:
- real 0m20.990s
- user 0m20.109s
- sys 0m0.196s
-
-
diff --git a/pypy/doc/config/objspace.usemodules.bz2.rst b/pypy/doc/config/objspace.usemodules.bz2.txt
copy from pypy/doc/config/objspace.usemodules.bz2.rst
copy to pypy/doc/config/objspace.usemodules.bz2.txt
diff --git a/pypy/doc/config/objspace.std.withstrjoin.rst b/pypy/doc/config/objspace.std.withstrjoin.txt
copy from pypy/doc/config/objspace.std.withstrjoin.rst
copy to pypy/doc/config/objspace.std.withstrjoin.txt
diff --git a/pypy/doc/discussion/emptying-the-malloc-zoo.rst b/pypy/doc/discussion/emptying-the-malloc-zoo.rst
deleted file mode 100644
--- a/pypy/doc/discussion/emptying-the-malloc-zoo.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-.. coding: utf-8
-
-Emptying the malloc zoo
-=======================
-
-Around the end-of-the-EU-project time there were two major areas of
-obscurity in the memory management area:
-
- 1. The confusing set of operations that the low-level backend are
- expected to implement.
-
- 2. The related, but slightly different, confusion of the various
- "flavours" of malloc: what's the difference between
- lltype.malloc(T, flavour='raw') and llmemory.raw_malloc(sizeof(T))?
-
-At the post-ep2007 sprint, Samuele and Michael attacked the first
-problem a bit: making the Boehm GC transformer only require three
-simple operations of the backend. This could be extending still
-further by having the gc transformer use rffi to insert calls to the
-relevant Boehm functions^Wmacros, and then the backend wouldn't need
-to know anything about Boehm at all (but... LLVM).
-
-A potential next step is to work out what we want the "llpython"
-interface to memory management to be.
-
-There are various use cases:
-
-**lltype.malloc(T) – T is a fixed-size GC container**
-
- This is the default case. Non-pointers inside the allocated memory
- will not be zeroed. The object will be managed by the GC, no
- deallocation required.
-
-**lltype.malloc(T, zero=True) – T is a GC container**
-
- As above, but all fields will be cleared.
-
-**lltype.malloc(U, raw=True) – U is not a GC container**
-
- Blah.
diff --git a/pypy/doc/config/translation.debug.rst b/pypy/doc/config/translation.debug.txt
copy from pypy/doc/config/translation.debug.rst
copy to pypy/doc/config/translation.debug.txt
diff --git a/pypy/doc/config/objspace.usemodules.token.rst b/pypy/doc/config/objspace.usemodules.token.txt
copy from pypy/doc/config/objspace.usemodules.token.rst
copy to pypy/doc/config/objspace.usemodules.token.txt
diff --git a/pypy/doc/config/objspace.std.mutable_builtintypes.rst b/pypy/doc/config/objspace.std.mutable_builtintypes.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.mutable_builtintypes.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Allow modification of builtin types. Disabled by default.
diff --git a/pypy/doc/config/translation.vanilla.rst b/pypy/doc/config/translation.vanilla.txt
copy from pypy/doc/config/translation.vanilla.rst
copy to pypy/doc/config/translation.vanilla.txt
diff --git a/pypy/doc/config/objspace.std.withprebuiltchar.rst b/pypy/doc/config/objspace.std.withprebuiltchar.txt
copy from pypy/doc/config/objspace.std.withprebuiltchar.rst
copy to pypy/doc/config/objspace.std.withprebuiltchar.txt
diff --git a/pypy/doc/config/translation.profopt.rst b/pypy/doc/config/translation.profopt.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.profopt.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Use GCCs profile-guided optimizations. This option specifies the the
-arguments with which to call pypy-c (and in general the translated
-RPython program) to gather profile data. Example for pypy-c: "-c 'from
-richards import main;main(); from test import pystone;
-pystone.main()'"
diff --git a/pypy/doc/config/objspace.usemodules.clr.rst b/pypy/doc/config/objspace.usemodules.clr.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.clr.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the 'clr' module.
diff --git a/pypy/doc/config/objspace.usemodules.crypt.rst b/pypy/doc/config/objspace.usemodules.crypt.txt
copy from pypy/doc/config/objspace.usemodules.crypt.rst
copy to pypy/doc/config/objspace.usemodules.crypt.txt
diff --git a/pypy/doc/config/objspace.usemodules._ssl.rst b/pypy/doc/config/objspace.usemodules._ssl.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._ssl.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the '_ssl' module, which implements SSL socket operations.
diff --git a/pypy/doc/config/objspace.usemodules._socket.rst b/pypy/doc/config/objspace.usemodules._socket.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._socket.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Use the '_socket' module.
-
-This is our implementation of '_socket', the Python builtin module
-exposing socket primitives, which is wrapped and used by the standard
-library 'socket.py' module. It is based on `rffi`_.
-
-.. _`rffi`: ../rffi.html
diff --git a/pypy/doc/config/translation.backendopt.inline.rst b/pypy/doc/config/translation.backendopt.inline.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.inline.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-Inline flowgraphs based on an heuristic, the default one considers
-essentially the a weight for the flowgraph based on the number of
-low-level operations in them (see
-:config:`translation.backendopt.inline_threshold` ).
-
-Some amount of inlining in order to have RPython builtin type helpers
-inlined is needed for malloc removal
-(:config:`translation.backendopt.mallocs`) to be effective.
-
-This optimization is used by default.
diff --git a/LICENSE b/LICENSE
--- a/LICENSE
+++ b/LICENSE
@@ -37,78 +37,154 @@
Armin Rigo
Maciej Fijalkowski
Carl Friedrich Bolz
+ Amaury Forgeot d'Arc
+ Antonio Cuni
Samuele Pedroni
- Antonio Cuni
Michael Hudson
+ Holger Krekel
Christian Tismer
- Holger Krekel
+ Benjamin Peterson
Eric van Riet Paap
+ Anders Chrigström
+ Håkan Ardö
Richard Emslie
- Anders Chrigstrom
- Amaury Forgeot d Arc
- Aurelien Campeas
+ Dan Villiom Podlaski Christiansen
+ Alexander Schremmer
+ Alex Gaynor
+ David Schneider
+ Aurelién Campeas
Anders Lehmann
+ Camillo Bruni
Niklaus Haldimann
+ Leonardo Santagada
+ Toon Verwaest
Seo Sanghyeon
- Leonardo Santagada
Lawrence Oluyede
+ Bartosz Skowron
Jakub Gustak
Guido Wesdorp
- Benjamin Peterson
- Alexander Schremmer
+ Adrien Di Mascio
+ Laura Creighton
+ Ludovic Aubry
Niko Matsakis
- Ludovic Aubry
+ Daniel Roberts
+ Jason Creighton
+ Jacob Hallén
Alex Martelli
- Toon Verwaest
+ Anders Hammarquist
+ Jan de Mooij
Stephan Diehl
- Adrien Di Mascio
+ Michael Foord
Stefan Schwarzer
Tomek Meka
Patrick Maupin
- Jacob Hallen
- Laura Creighton
Bob Ippolito
- Camillo Bruni
- Simon Burton
Bruno Gola
Alexandre Fayolle
Marius Gedminas
+ Simon Burton
+ Jean-Paul Calderone
+ John Witulski
+ Wim Lavrijsen
+ Andreas Stührk
+ Jean-Philippe St. Pierre
Guido van Rossum
+ Pavel Vinogradov
Valentino Volonghi
+ Paul deGrandis
Adrian Kuhn
- Paul deGrandis
+ tav
+ Georg Brandl
Gerald Klix
Wanja Saatkamp
- Anders Hammarquist
+ Boris Feigin
Oscar Nierstrasz
+ Dario Bertini
+ David Malcolm
Eugene Oden
+ Henry Mason
Lukas Renggli
Guenter Jantzen
+ Ronny Pfannschmidt
+ Bert Freudenberg
+ Amit Regmi
+ Ben Young
+ Nicolas Chauvat
+ Andrew Durdin
+ Michael Schneider
+ Nicholas Riley
+ Rocco Moretti
+ Gintautas Miliauskas
+ Michael Twomey
+ Igor Trindade Oliveira
+ Lucian Branescu Mihaila
+ Olivier Dormond
+ Jared Grubb
+ Karl Bartel
+ Gabriel Lavoie
+ Brian Dorsey
+ Victor Stinner
+ Stuart Williams
+ Toby Watson
+ Antoine Pitrou
+ Justas Sadzevicius
+ Neil Shepperd
+ Mikael Schönenberg
+ Gasper Zejn
+ Jonathan David Riehl
+ Elmo Mäntynen
+ Anders Qvist
+ Beatrice Düring
+ Alexander Sedov
+ Vincent Legoll
+ Alan McIntyre
+ Romain Guillebert
+ Alex Perry
+ Jens-Uwe Mager
+ Dan Stromberg
+ Lukas Diekmann
+ Carl Meyer
+ Pieter Zieschang
+ Alejandro J. Cura
+ Sylvain Thenault
+ Travis Francis Athougies
+ Henrik Vendelbo
+ Lutz Paelike
+ Jacob Oscarson
+ Martin Blais
+ Lucio Torre
+ Lene Wagner
+ Miguel de Val Borro
+ Ignas Mikalajunas
+ Artur Lisiecki
+ Joshua Gilbert
+ Godefroid Chappelle
+ Yusei Tahara
+ Christopher Armstrong
+ Stephan Busemann
+ Gustavo Niemeyer
+ William Leslie
+ Akira Li
+ Kristján Valur Jonsson
+ Bobby Impollonia
+ Andrew Thompson
+ Anders Sigfridsson
+ Jacek Generowicz
+ Dan Colish
+ Sven Hager
+ Zooko Wilcox-O Hearn
+ Anders Hammarquist
Dinu Gherman
- Bartosz Skowron
- Georg Brandl
- Ben Young
- Jean-Paul Calderone
- Nicolas Chauvat
- Rocco Moretti
- Michael Twomey
- 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
- Tav
+ Dan Colish
+ Daniel Neuhäuser
+ Michael Chermside
+ Konrad Delong
+ Anna Ravencroft
+ Greg Price
+ Armin Ronacher
+ Jim Baker
+ Philip Jenvey
+ Rodrigo Araújo
Heinrich-Heine University, Germany
Open End AB (formerly AB Strakt), Sweden
diff --git a/pypy/doc/config/objspace.std.withropeunicode.rst b/pypy/doc/config/objspace.std.withropeunicode.txt
copy from pypy/doc/config/objspace.std.withropeunicode.rst
copy to pypy/doc/config/objspace.std.withropeunicode.txt
diff --git a/pypy/doc/config/objspace.std.multimethods.rst b/pypy/doc/config/objspace.std.multimethods.txt
copy from pypy/doc/config/objspace.std.multimethods.rst
copy to pypy/doc/config/objspace.std.multimethods.txt
diff --git a/pypy/doc/config/objspace.name.rst b/pypy/doc/config/objspace.name.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.name.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-Determine which `Object Space`_ to use. The `Standard Object Space`_ gives the
-normal Python semantics, the others are `Object Space Proxies`_ giving
-additional features (except the Flow Object Space which is not intended
-for normal usage):
-
- * thunk_: The thunk object space adds lazy evaluation to PyPy.
- * taint_: The taint object space adds soft security features.
- * dump_: Using this object spaces results in the dumpimp of all operations
- to a log.
-
-.. _`Object Space`: ../objspace.html
-.. _`Object Space Proxies`: ../objspace-proxies.html
-.. _`Standard Object Space`: ../objspace.html#standard-object-space
-.. _thunk: ../objspace-proxies.html#thunk
-.. _taint: ../objspace-proxies.html#taint
-.. _dump: ../objspace-proxies.html#dump
diff --git a/pypy/doc/config/objspace.std.withsmalllong.rst b/pypy/doc/config/objspace.std.withsmalllong.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withsmalllong.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Enable "small longs", an additional implementation of the Python
-type "long", implemented with a C long long. It is mostly useful
-on 32-bit; on 64-bit, a C long long is the same as a C long, so
-its usefulness is limited to Python objects of type "long" that
-would anyway fit in an "int".
diff --git a/pypy/doc/config/objspace.opcodes.rst b/pypy/doc/config/objspace.opcodes.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.opcodes.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/objspace.usemodules.parser.rst b/pypy/doc/config/objspace.usemodules.parser.txt
copy from pypy/doc/config/objspace.usemodules.parser.rst
copy to pypy/doc/config/objspace.usemodules.parser.txt
diff --git a/pypy/doc/config/objspace.std.withrope.rst b/pypy/doc/config/objspace.std.withrope.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withrope.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Enable ropes to be the default string implementation.
-
-See the section in `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#ropes
-
-
diff --git a/pypy/doc/config/objspace.usemodules.crypt.rst b/pypy/doc/config/objspace.usemodules.crypt.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.crypt.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'crypt' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/config/objspace.std.logspaceoptypes.rst b/pypy/doc/config/objspace.std.logspaceoptypes.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.logspaceoptypes.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-.. internal
-
-Wrap "simple" bytecode implementations like BINARY_ADD with code that collects
-information about which types these bytecodes receive as arguments.
diff --git a/pypy/doc/config/objspace.usemodules.rst b/pypy/doc/config/objspace.usemodules.txt
copy from pypy/doc/config/objspace.usemodules.rst
copy to pypy/doc/config/objspace.usemodules.txt
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.clever_malloc_removal_heuristic.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Internal option. Switch to a different weight heuristic for inlining.
-This is for clever malloc removal (:config:`translation.backendopt.clever_malloc_removal`).
-
-.. internal
diff --git a/pypy/doc/config/objspace.usemodules._demo.rst b/pypy/doc/config/objspace.usemodules._demo.txt
copy from pypy/doc/config/objspace.usemodules._demo.rst
copy to pypy/doc/config/objspace.usemodules._demo.txt
diff --git a/pypy/doc/config/translation.noprofopt.rst b/pypy/doc/config/translation.noprofopt.txt
copy from pypy/doc/config/translation.noprofopt.rst
copy to pypy/doc/config/translation.noprofopt.txt
diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -43,67 +43,57 @@
complete and well tested, so if your project does not use many
extension modules there is a good chance that it will work with PyPy.
-We list the differences we know about in `cpython_differences`_.
+We list the differences we know about in `cpython differences`_.
-There is also an experimental support for CPython extension modules, so
-they'll run without change (from current observation, rather with little
-change) on trunk. It has been a part of 1.4 release, but support is still
-in alpha phase.
+--------------------------------------------
+Do CPython Extension modules work with PyPy?
+--------------------------------------------
+
+We have experimental support for CPython extension modules, so
+they run with minor changes. This has been a part of PyPy since
+the 1.4 release, but support is still in beta phase. CPython
+extension modules in PyPy are often much slower than in CPython due to
+the need to emulate refcounting. It is often faster to take out your
+CPython extension and replace it with a pure python version that the
+JIT can see.
+
+We fully support ctypes-based extensions.
+
+For information on which third party extensions work (or do not work)
+with PyPy see the `compatibility wiki`_.
+
.. _`extension modules`: cpython_differences.html#extension-modules
-.. _`cpython_differences`: cpython_differences.html
+.. _`cpython differences`: cpython_differences.html
+.. _`compatibility wiki`: https://bitbucket.org/pypy/compatibility/wiki/Home
---------------------------------
-On what platforms does PyPy run?
---------------------------------
+---------------------------------
+On which platforms does PyPy run?
+---------------------------------
PyPy is regularly and extensively tested on Linux machines and on Mac
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) or CPython 2.5 or 2.6
+At the moment you need CPython 2.5 - 2.7
for the translation process. PyPy's JIT requires an x86 or x86_64 CPU.
-
------------------------------------------------
Which Python version (2.x?) does PyPy implement?
------------------------------------------------
-PyPy currently aims to be fully compatible with Python 2.5. That means that
-it contains the standard library of Python 2.5 and that it supports 2.5
-features (such as the with statement).
+PyPy currently aims to be fully compatible with Python 2.7. That means that
+it contains the standard library of Python 2.7 and that it supports 2.7
+features (such as set comprehensions).
.. _threading:
-------------------------------------------------
-Do threads work? What are the modules that work?
+Does PyPy have a GIL? Why?
-------------------------------------------------
-Operating system-level threads basically work. If you enable the ``thread``
-module then PyPy will get support for GIL based threading.
-Note that PyPy also fully supports `stackless-like
-microthreads`_ (although both cannot be mixed yet).
-
-All pure-python modules should work, unless they rely on ugly
-cpython implementation details, in which case it's their fault.
-There is an increasing number of compatible CPython extensions working,
-including things like wxPython or PIL. This is an ongoing development effort
-to bring as many CPython extension modules working as possible.
-
-.. _`stackless-like microthreads`: stackless.html
-
-
-------------------------------------
-Can I use CPython extension modules?
-------------------------------------
-
-Yes, but the feature is in alpha state and is available only on trunk
-(not in the 1.2 release). However, we'll only ever support well-behaving
-CPython extensions. Please consult PyPy developers on IRC or mailing list
-for explanations if your favorite module works and how you can help to make
-it happen in case it does not.
-
-We fully support ctypes-based extensions, however.
+Yes, PyPy has a GIL. Removing the GIL is very hard. The first problem
+is that our garbage collectors are not re-entrant.
------------------------------------------
How do I write extension modules for PyPy?
@@ -113,44 +103,27 @@
.. __: extending.html
-
-.. _`slower than CPython`:
-.. _`how fast is pypy`:
-
-----------------
How fast is PyPy?
-----------------
+This really depends on your code.
+For pure Python algorithmic code, it is very fast. For more typical
+Python programs we generally are 3 times the speed of Cpython 2.6 .
+You might be interested in our `benchmarking site`_ and our
+`jit documentation`_.
-.. _whysoslow:
+.. _`benchmarking site`: http://speed.pypy.org
-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.
-
-.. __: http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf
-.. _`with a JIT included`: jit/index.html
+.. _`jit documentation`: jit/index.html
.. _`prolog and javascript`:
-----------------------------------------------------------------
-Can PyPy support interpreters for other languages beyond Python?
-----------------------------------------------------------------
+--------------------------------------------------------------------------
+Can I use PyPy's translation toolchain for other languages besides Python?
+--------------------------------------------------------------------------
-The toolsuite that translates the PyPy interpreter is quite
+Yes. The toolsuite that translates the PyPy interpreter is quite
general and can be used to create optimized versions of interpreters
for any language, not just Python. Of course, these interpreters
can make use of the same features that PyPy brings to Python:
@@ -161,11 +134,12 @@
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). On the `PyPy bitbucket page`_ there is also a
+Scheme and an Io implementation; both of these are unfinished at the moment.
-.. _`Prolog interpreter`: http://codespeak.net/svn/pypy/lang/prolog/
+.. _`Prolog interpreter`: https://bitbucket.org/cfbolz/pyrolog/
.. _`SmallTalk interpreter`: http://dx.doi.org/10.1007/978-3-540-89275-5_7
-.. _`All of them`: http://codespeak.net/svn/pypy/lang/
+.. _`PyPy bitbucket page`: https://bitbucket.org/pypy/
Development
@@ -175,36 +149,21 @@
How do I get into PyPy development? Can I come to sprints?
-----------------------------------------------------------
-Sure you can come to sprints! We always welcome newcomers and try to help them
-get started in the project as much as possible (e.g. by providing tutorials and
-pairing them with experienced PyPy developers). Newcomers should have some
-Python experience and read some of the PyPy documentation before coming to a
-sprint.
+Certainly you can come to sprints! We always welcome newcomers and try
+to help them as much as possible to get started with the project. We
+provide tutorials and pair them with experienced PyPy
+developers. Newcomers should have some Python experience and read some
+of the PyPy documentation before coming to a sprint.
-Coming to a sprint is usually also the best way to get into PyPy development.
-If you want to start on your own, take a look at the list of `project
-suggestions`_. If you get stuck or need advice, `contact us`_. Usually IRC is
+Coming to a sprint is usually the best way to get into PyPy development.
+If you get stuck or need advice, `contact us`_. IRC is
the most immediate way to get feedback (at least during some parts of the day;
-many PyPy developers are in Europe) and the `mailing list`_ is better for long
+most PyPy developers are in Europe) and the `mailing list`_ is better for long
discussions.
-.. _`project suggestions`: project-ideas.html
.. _`contact us`: index.html
.. _`mailing list`: http://codespeak.net/mailman/listinfo/pypy-dev
-----------------------------------------------------------------------
-I am getting strange errors while playing with PyPy, what should I do?
-----------------------------------------------------------------------
-
-It seems that a lot of strange, unexplainable problems can be magically
-solved by removing all the \*.pyc files from the PyPy source tree
-(the script `py.cleanup`_ from py/bin will do that for you).
-Another thing you can do is removing the directory pypy/_cache
-completely. If the error is persistent and still annoys you after this
-treatment please send us a bug report (or even better, a fix :-)
-
-.. _`py.cleanup`: http://codespeak.net/py/current/doc/bin.html
-
-------------------------------------------------------------
OSError: ... cannot restore segment prot after reloc... Help?
-------------------------------------------------------------
@@ -221,12 +180,12 @@
Be sure to enable it again if you need it!
-PyPy translation tool chain
-===========================
+The PyPy translation tool chain
+===============================
-----------------------------------------
-Can PyPy compile normal Python programs?
-----------------------------------------
+---------------------------------------------
+Can PyPy compile normal Python programs to C?
+---------------------------------------------
No, PyPy is not a Python compiler.
@@ -234,36 +193,13 @@
that a program will manipulate by doing a static analysis. It should be
clear if you are familiar with Python, but if in doubt see [BRETT]_.
-What could be attempted is static "soft typing", where you would use a
-whole bunch of heuristics to guess what types are probably going to show
-up where. In this way, you could compile the program into two copies of
-itself: a "fast" version and a "slow" version. The former would contain
-many guards that allow it to fall back to the latter if needed. That
-would be a wholly different project than PyPy, though. (As far as we
-understand it, this is the approach that the LLVM__ group would like to
-see LLVM used for, so if you feel like working very hard and attempting
-something like this, check with them.)
+If you want a fast Python program, please use our JIT_ instead.
-.. __: http://llvm.org/
-
-What PyPy contains is, on the one hand, an non-soft static type
-inferencer for RPython, which is a sublanguage that we defined just so
-that it's possible and not too hard to do that; and on the other hand,
-for the full Python language, we have an interpreter, and a JIT
-generator which can produce a Just-In-Time Compiler from the
-interpreter. The resulting JIT works for the full Python language in a
-way that doesn't need type inference at all.
-
-For more motivation and details about our approach see also [D05.1]_,
-section 3.
+.. _JIT: jit/index.html
.. [BRETT] Brett Cannon,
Localized Type Inference of Atomic Types in Python,
- http://www.ocf.berkeley.edu/~bac/thesis.pdf
-
-.. [D05.1] Compiling Dynamic Language Implementations,
- Report from the PyPy project to the E.U.,
- http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+ http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3231
.. _`PyPy's RPython`:
@@ -272,30 +208,26 @@
------------------------------
RPython is a restricted subset of the Python language. It is used for
-implementing dynamic language interpreters within the PyPy framework. The
-restrictions are to ensure that type inference (and so, ultimately, translation
-to other languages) of RPython programs is possible. These restrictions only
-apply after the full import happens, so at import time arbitrary Python code can
-be executed.
+implementing dynamic language interpreters within the PyPy toolchain. The
+restrictions ensure that type inference (and so, ultimately, translation
+to other languages) of RPython programs is possible.
The property of "being RPython" always applies to a full program, not to single
-functions or modules (the translation tool chain does a full program analysis).
-"Full program" in the context of "being RPython" is all the code reachable from
-an "entry point" function. The translation toolchain follows all calls
-recursively and discovers what belongs to the program and what not.
+functions or modules (the translation toolchain does a full program analysis).
+The translation toolchain follows all calls
+recursively and discovers what belongs to the program and what does not.
-The restrictions that apply to programs to be RPython mostly limit the ability
-of mixing types in arbitrary ways. RPython does not allow the usage of two
+RPython program restrictions mostly limit the ability
+to mix types in arbitrary ways. RPython does not allow the binding of two
different types in the same variable. In this respect (and in some others) it
-feels a bit like Java. Other features not allowed in RPython are the usage of
+feels a bit like Java. Other features not allowed in RPython are the use of
special methods (``__xxx__``) except ``__init__`` and ``__del__``, and the
-usage of reflection capabilities (e.g. ``__dict__``).
+use of reflection capabilities (e.g. ``__dict__``).
-Most existing standard library modules are not RPython, except for
-some functions in ``os``, ``math`` and ``time`` that are natively
-supported. In general it is quite unlikely that an existing Python
-program is by chance RPython; it is most likely that it would have to be
-heavily rewritten.
+You cannot use most existing standard library modules from RPython. The
+exceptions are
+some functions in ``os``, ``math`` and ``time`` that have native support.
+
To read more about the RPython limitations read the `RPython description`_.
.. _`RPython description`: coding-guide.html#restricted-python
@@ -312,29 +244,6 @@
.. _`sandboxed Python Interpreter`: sandbox.html
.. _`Zope's RestrictedPython`: http://pypi.python.org/pypi/RestrictedPython
--------------------------------------------------------------------------
-Can I use PyPy and RPython to compile smaller parts of my Python program?
--------------------------------------------------------------------------
-
-No. That would be possible, and we played with early attempts in that
-direction, but there are many delicate issues: for example, how the
-compiled and the non-compiled parts exchange data. Supporting this in a
-nice way would be a lot of work.
-
-PyPy is certainly a good starting point for someone that would like to
-work in that direction. Early attempts were dropped because they
-conflicted with refactorings that we needed in order to progress on the
-rest of PyPy; the currently active developers of PyPy have different
-priorities. If someone wants to start working in that direction I
-imagine that he might get a (very little) bit of support from us,
-though.
-
-Alternatively, it's possible to write a mixed-module, i.e. an extension
-module for PyPy in RPython, which you can then import from your Python
-program when it runs on top of PyPy. This is similar to writing a C
-extension module for CPython in term of investment of effort (without
-all the INCREF/DECREF mess, though).
-
------------------------------------------------------
What's the ``"NOT_RPYTHON"`` I see in some docstrings?
------------------------------------------------------
@@ -350,7 +259,7 @@
-------------------------------------------------------------------
It's not necessarily nonsense, but it's not really The PyPy Way. It's
-pretty hard, without some kind of type inference, to translate, say this
+pretty hard, without some kind of type inference, to translate this
Python::
a + b
@@ -369,16 +278,16 @@
Do I have to rewrite my programs in RPython?
--------------------------------------------
-No. PyPy always runs your code in its own interpreter, which is a
-full and compliant Python 2.5 interpreter. RPython_ is only the
+No. And you shouldn't try. PyPy always runs your code in its own interpreter, which is a
+full and compliant Python 2.7 interpreter. RPython is only the
language in which parts of PyPy itself are written and extension
-modules for it. The answer to whether something needs to be written as
-an extension module, apart from the "gluing to external libraries" reason, will
-change over time as speed for normal Python code improves.
+modules for it. Not only is it not necessary for you to rewrite your
+code in RPython, it probably won't give you any speed improvements if you
+try.
--------------------------
-Which backends are there?
--------------------------
+---------------------------------------------------
+Which backends are there for the RPython toolchain?
+---------------------------------------------------
Currently, there are backends for C_, the CLI_, and the JVM_.
All of these can translate the entire PyPy interpreter.
@@ -395,31 +304,22 @@
See the `getting-started`_ guide.
+.. _`getting-started`: getting-started-python.html
+
.. _`how do I compile my own interpreters`:
-------------------------------------
How do I compile my own interpreters?
-------------------------------------
+Begin by reading `Andrew Brown's tutorial`_ .
-Start from the example of
-`pypy/translator/goal/targetnopstandalone.py`_, which you compile by
-typing::
-
- python translate.py targetnopstandalone
-
-You can have a look at intermediate C source code, which is (at the
-moment) put in ``/tmp/usession-*/testing_1/testing_1.c``. Of course,
-all the functions and stuff used directly and indirectly by your
-``entry_point()`` function has to be RPython_.
-
-
-.. _`RPython`: coding-guide.html#rpython
-.. _`getting-started`: getting-started.html
-
-.. include:: _ref.rst
+.. _`Andrew Brown's tutorial`: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
----------------------------------------------------------
Why does PyPy draw a Mandelbrot fractal while translating?
----------------------------------------------------------
Because it's fun.
+
+.. include:: _ref.txt
+
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.clever_malloc_removal_threshold.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Weight threshold used to decide whether to inline flowgraphs.
-This is for clever malloc removal (:config:`translation.backendopt.clever_malloc_removal`).
diff --git a/pypy/doc/release-0.9.0.rst b/pypy/doc/release-0.9.0.rst
--- a/pypy/doc/release-0.9.0.rst
+++ b/pypy/doc/release-0.9.0.rst
@@ -59,7 +59,7 @@
**testing refinements**
py.test, our testing tool, now has preliminary support for doctests.
We now run all our tests every night, and you can see the summary at:
- http://snake.cs.uni-duesseldorf.de/pypytest/summary.html
+ http://buildbot.pypy.org/summary
What is PyPy (about)?
------------------------------------------------
diff --git a/pypy/doc/config/translation.gcrootfinder.rst b/pypy/doc/config/translation.gcrootfinder.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.gcrootfinder.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-Choose method how to find roots in the GC. Boehm and refcounting have their own
-methods, this is mostly only interesting for framework GCs. For those you have
-a choice of various alternatives:
-
- - use a shadow stack (XXX link to paper), e.g. explicitly maintaining a stack
- of roots
-
- - use stackless to find roots by unwinding the stack. Requires
- :config:`translation.stackless`. Note that this turned out to
- be slower than just using a shadow stack.
-
- - use GCC and i386 specific assembler hackery to find the roots on the stack.
- This is fastest but platform specific.
-
- - Use LLVM's GC facilities to find the roots.
diff --git a/pypy/doc/release-1.4.0beta.rst b/pypy/doc/release-1.4.0beta.rst
--- a/pypy/doc/release-1.4.0beta.rst
+++ b/pypy/doc/release-1.4.0beta.rst
@@ -33,4 +33,4 @@
Cheers,
The PyPy team
-.. _`list of patches`: http://codespeak.net/svn/pypy/trunk/pypy/module/cpyext/patches/
+.. _`list of patches`: https://bitbucket.org/pypy/pypy/src/tip/pypy/module/cpyext/patches/
diff --git a/pypy/doc/config/translation.builtins_can_raise_exceptions.rst b/pypy/doc/config/translation.builtins_can_raise_exceptions.txt
copy from pypy/doc/config/translation.builtins_can_raise_exceptions.rst
copy to pypy/doc/config/translation.builtins_can_raise_exceptions.txt
diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -17,6 +17,7 @@
^pypy/module/cpyext/test/.+\.manifest$
^pypy/module/test_lib_pypy/ctypes_tests/.+\.o$
^pypy/doc/.+\.html$
+^pypy/doc/config/.+\.rst$
^pypy/doc/basicblock\.asc$
^pypy/doc/.+\.svninfo$
^pypy/translator/c/src/libffi_msvc/.+\.obj$
diff --git a/pypy/doc/config/translation.backendopt.raisingop2direct_call.rst b/pypy/doc/config/translation.backendopt.raisingop2direct_call.txt
copy from pypy/doc/config/translation.backendopt.raisingop2direct_call.rst
copy to pypy/doc/config/translation.backendopt.raisingop2direct_call.txt
diff --git a/pypy/doc/config/objspace.usemodules._minimal_curses.rst b/pypy/doc/config/objspace.usemodules._minimal_curses.txt
copy from pypy/doc/config/objspace.usemodules._minimal_curses.rst
copy to pypy/doc/config/objspace.usemodules._minimal_curses.txt
diff --git a/pypy/doc/config/objspace.std.withdictmeasurement.rst b/pypy/doc/config/objspace.std.withdictmeasurement.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withdictmeasurement.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/config/translation.ootype.mangle.rst b/pypy/doc/config/translation.ootype.mangle.txt
copy from pypy/doc/config/translation.ootype.mangle.rst
copy to pypy/doc/config/translation.ootype.mangle.txt
diff --git a/pypy/doc/config/objspace.usemodules.zipimport.rst b/pypy/doc/config/objspace.usemodules.zipimport.txt
copy from pypy/doc/config/objspace.usemodules.zipimport.rst
copy to pypy/doc/config/objspace.usemodules.zipimport.txt
diff --git a/pypy/doc/config/translation.jit_ffi.rst b/pypy/doc/config/translation.jit_ffi.txt
copy from pypy/doc/config/translation.jit_ffi.rst
copy to pypy/doc/config/translation.jit_ffi.txt
diff --git a/pypy/doc/config/objspace.usemodules.itertools.rst b/pypy/doc/config/objspace.usemodules.itertools.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.itertools.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the interp-level 'itertools' module.
-If not included, a slower app-level version of itertools is used.
diff --git a/pypy/doc/config/translation.list_comprehension_operations.rst b/pypy/doc/config/translation.list_comprehension_operations.txt
copy from pypy/doc/config/translation.list_comprehension_operations.rst
copy to pypy/doc/config/translation.list_comprehension_operations.txt
diff --git a/pypy/doc/pypyconfig.py b/pypy/doc/pypyconfig.py
new file mode 100644
--- /dev/null
+++ b/pypy/doc/pypyconfig.py
@@ -0,0 +1,9 @@
+
+
+def setup(app):
+ import sys, os
+ sys.path.insert(0, os.path.abspath("../../"))
+ from pypy.config import makerestdoc
+ import py
+ role = makerestdoc.register_config_role(py.path.local())
+ app.add_role("config", role)
diff --git a/pypy/doc/config/objspace.usemodules.rst b/pypy/doc/config/objspace.usemodules.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/objspace.usemodules._rawffi.rst b/pypy/doc/config/objspace.usemodules._rawffi.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._rawffi.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-An experimental module providing very low-level interface to
-C-level libraries, for use when implementing ctypes, not
-intended for a direct use at all.
\ No newline at end of file
diff --git a/pypy/doc/architecture.rst b/pypy/doc/architecture.rst
--- a/pypy/doc/architecture.rst
+++ b/pypy/doc/architecture.rst
@@ -16,22 +16,20 @@
* a common translation and support framework for producing
implementations of dynamic languages, emphasizing a clean
separation between language specification and implementation
- aspects.
+ aspects. We call this the `RPython toolchain`_.
* 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.
+ which uses the above toolchain to enable new advanced high-level features
+ without having to encode the low-level details.
-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.
-
+By separating concerns in this way, our implementation
+of Python - and other dynamic languages - is able to automatically
+generate a Just-in-Time compiler for any dynamic language. It also
+allows a mix-and-match approach to implementation decisions, including
+many that have historically been outside of a user's control, such as
+target platform, memory and
+threading models, garbage collection strategies, and optimizations applied,
+including whether or not to have a JIT in the first place.
High Level Goals
=============================
@@ -40,9 +38,10 @@
-----------------------------------------------
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
+such as C/Posix, Java or C#. Each implementation provides
+a fundamental mapping between application source code and the target
+environment. One of
+the goals of the "all-encompassing" environments, such as 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.
@@ -50,7 +49,7 @@
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
+dependencies on lower level details. The `RPython toolchain`_
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.
@@ -58,8 +57,8 @@
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:
+decisions. PyPy aims at making it possible to change each of these
+variables independently such that:
* ``l``: the language that we analyze can be evolved or entirely replaced;
@@ -121,8 +120,8 @@
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
+The job of the RPython toolchain is to translate RPython_ programs
+into an efficient version of that program for one of the 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
@@ -133,7 +132,7 @@
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
+The RPython toolchain 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
@@ -161,7 +160,7 @@
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
+the RPython toolchain`_ and in the paper `Compiling dynamic language
implementations`_.
.. _`control flow graph`: translation.html#the-flow-model
@@ -169,10 +168,9 @@
.. _Annotator: translation.html#the-annotation-pass
.. _RTyper: rtyper.html#overview
.. _`various transformations`: translation.html#the-optional-transformations
-.. _`document about the translation process`: translation.html
+.. _`document about the RPython toolchain`: translation.html
.. _`garbage collector`: garbage_collection.html
-
-
+.. _`RPython toolchain`: translation.html
.. _`standard interpreter`:
.. _`python interpreter`:
@@ -233,17 +231,18 @@
* `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
+ * A tutorial of how to use the `RPython toolchain`_ to `implement your own
+ interpreter`_.
+
+.. _`documentation index`: index.html#project-documentation
.. _`getting-started`: getting-started.html
-.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
+.. _`PyPy's approach to virtual machine construction`: https://bitbucket.org/pypy/extradoc/raw/tip/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
+.. _`RPython toolchain`: translation.html
+.. _`Compiling dynamic language implementations`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
.. _`Technical reports`: index-report.html
.. _`getting started`: getting-started.html
@@ -254,11 +253,12 @@
.. _`RPython`: coding-guide.html#rpython
-.. _Python: http://docs.python.org/ref
+.. _Python: http://docs.python.org/reference/
.. _Psyco: http://psyco.sourceforge.net
.. _stackless: stackless.html
.. _`generate Just-In-Time Compilers`: jit/index.html
.. _`JIT Generation in PyPy`: jit/index.html
+.. _`implement your own interpreter`: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.usemodules._demo.rst b/pypy/doc/config/objspace.usemodules._demo.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._demo.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the '_demo' module.
-
-This is the demo module for mixed modules. Not enabled by default.
diff --git a/pypy/doc/image/parsing_example6.dot b/pypy/doc/image/parsing_example6.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example6.dot
+++ /dev/null
@@ -1,9 +0,0 @@
-digraph G{
-"-1213518708" [label="list"];
-"-1213518708" -> "-1213518196";
-"-1213518196" [shape=box,label="DECIMAL\n'1'"];
-"-1213518708" -> "-1213518260";
-"-1213518260" [label="list"];
-"-1213518260" -> "-1213520308";
-"-1213520308" [shape=box,label="DECIMAL\n'2'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/config/translation.backendopt.merge_if_blocks.rst b/pypy/doc/config/translation.backendopt.merge_if_blocks.txt
copy from pypy/doc/config/translation.backendopt.merge_if_blocks.rst
copy to pypy/doc/config/translation.backendopt.merge_if_blocks.txt
diff --git a/pypy/doc/config/objspace.extmodules.rst b/pypy/doc/config/objspace.extmodules.txt
copy from pypy/doc/config/objspace.extmodules.rst
copy to pypy/doc/config/objspace.extmodules.txt
diff --git a/pypy/doc/config/objspace.usemodules._rawffi.rst b/pypy/doc/config/objspace.usemodules._rawffi.txt
copy from pypy/doc/config/objspace.usemodules._rawffi.rst
copy to pypy/doc/config/objspace.usemodules._rawffi.txt
diff --git a/pypy/doc/cpython_differences.rst b/pypy/doc/cpython_differences.rst
--- a/pypy/doc/cpython_differences.rst
+++ b/pypy/doc/cpython_differences.rst
@@ -23,34 +23,47 @@
_ast
_bisect
_codecs
+ _collections
+ `_ffi`_
+ _hashlib
+ _io
+ _locale
_lsprof
+ _md5
`_minimal_curses`_
+ _multiprocessing
_random
`_rawffi`_
- _ssl
+ _sha
_socket
_sre
+ _ssl
+ _warnings
_weakref
+ _winreg
array
+ binascii
bz2
cStringIO
+ clr
+ cmath
`cpyext`_
crypt
errno
exceptions
fcntl
gc
+ imp
itertools
marshal
math
- md5
mmap
operator
+ oracle
parser
posix
pyexpat
select
- sha
signal
struct
symbol
@@ -77,8 +90,7 @@
* Supported by being rewritten in pure Python (possibly using ``ctypes``):
see the `lib_pypy/`_ directory. Examples of modules that we
- support this way: ``ctypes``, ``cPickle``,
- ``cStringIO``, ``cmath``, ``dbm`` (?), ``datetime``, ``binascii``...
+ support this way: ``ctypes``, ``cPickle``, ``cmath``, ``dbm``, ``datetime``...
Note that some modules are both in there and in the list above;
by default, the built-in module is used (but can be disabled
at translation time).
@@ -89,6 +101,7 @@
.. the nonstandard modules are listed below...
.. _`__pypy__`: __pypy__-module.html
+.. _`_ffi`: ctypes-implementation.html
.. _`_rawffi`: ctypes-implementation.html
.. _`_minimal_curses`: config/objspace.usemodules._minimal_curses.html
.. _`cpyext`: http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html
@@ -114,7 +127,7 @@
adopted by Jython or IronPython (or any other port of Python to Java or
.NET, like PyPy itself).
-This affects the precise time at which __del__ methods are called, which
+This affects the precise time at which ``__del__`` methods are called, which
is not reliable in PyPy (nor Jython nor IronPython). It also means that
weak references may stay alive for a bit longer than expected. This
makes "weak proxies" (as returned by ``weakref.proxy()``) somewhat less
@@ -124,12 +137,12 @@
``ReferenceError`` at any place that uses them.
There are a few extra implications for the difference in the GC. Most
-notably, if an object has a __del__, the __del__ is never called more
-than once in PyPy; but CPython will call the same __del__ several times
-if the object is resurrected and dies again. The __del__ methods are
+notably, if an object has a ``__del__``, the ``__del__`` is never called more
+than once in PyPy; but CPython will call the same ``__del__`` several times
+if the object is resurrected and dies again. The ``__del__`` methods are
called in "the right" order if they are on objects pointing to each
other, as in CPython, but unlike CPython, if there is a dead cycle of
-objects referencing each other, their __del__ methods are called anyway;
+objects referencing each other, their ``__del__`` methods are called anyway;
CPython would instead put them into the list ``garbage`` of the ``gc``
module. More information is available on the blog `[1]`__ `[2]`__.
@@ -142,7 +155,7 @@
and calling it a lot can lead to performance problem.
Note that if you have a long chain of objects, each with a reference to
-the next one, and each with a __del__, PyPy's GC will perform badly. On
+the next one, and each with a ``__del__``, PyPy's GC will perform badly. On
the bright side, in most other cases, benchmarks have shown that PyPy's
GCs perform much better than CPython's.
@@ -221,5 +234,9 @@
it could be supported, but then it will likely work in many
*more* case on PyPy than on CPython 2.6/2.7.)
+* the ``__builtins__`` name is always referencing the ``__builtin__`` module,
+ never a dictionary as it sometimes is in CPython. Assigning to
+ ``__builtins__`` has no effect.
-.. include:: _ref.rst
+.. include:: _ref.txt
+
diff --git a/pypy/doc/translation.rst b/pypy/doc/translation.rst
--- a/pypy/doc/translation.rst
+++ b/pypy/doc/translation.rst
@@ -1,18 +1,18 @@
-=====================
- PyPy - Translation
-=====================
+=============================
+ PyPy - The RPython Toolchain
+=============================
.. contents::
-This document describes the tool chain that we have developed to analyze
+This document describes the toolchain that we have developed to analyze
and "compile" RPython_ programs (like PyPy itself) to various target
platforms.
.. _RPython: coding-guide.html#restricted-python
It consists of three broad sections: a slightly simplified overview, a
-brief introduction to each of the major components of our tool chain and
+brief introduction to each of the major components of our toolchain and
then a more comprehensive section describing how the pieces fit together.
If you are reading this document for the first time, the Overview_ is
likely to be most useful, if you are trying to refresh your PyPy memory
@@ -21,7 +21,7 @@
Overview
========
-The job of translation tool chain is to translate RPython_ programs into an
+The job of the translation toolchain 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. It divides
this task into several steps, and the purpose of this document is to
@@ -29,11 +29,8 @@
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
-case in several ways).
+and Java/JVM.
-.. _`a backend`: geninterp.html
.. _`application-level`: coding-guide.html#application-level
.. _`interpreter-level`: coding-guide.html#interpreter-level
@@ -43,7 +40,7 @@
.. _`initialization time`:
-The translation tool chain never sees Python source code or syntax
+The RPython translation toolchain never sees Python 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. The
`bytecode evaluator`_ and the `Flow Object Space`_ work through these
@@ -93,7 +90,7 @@
(although these steps are not quite as distinct as you might think from
this presentation).
-There is an `interactive interface`_ called `translatorshell.py`_ to the
+There is an `interactive interface`_ called `pypy/bin/translatorshell.py`_ to the
translation process which allows you to interactively work through these
stages.
@@ -104,10 +101,9 @@
.. _`PDF color version`: image/translation.pdf
.. _`bytecode evaluator`: interpreter.html
-.. _`abstract interpretation`: theory.html#abstract-interpretation
+.. _`abstract interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
.. _`Flow Object Space`: objspace.html#the-flow-object-space
.. _`interactive interface`: getting-started-dev.html#try-out-the-translator
-.. _`translatorshell.py`: ../../../../pypy/bin/translatorshell.py
.. _`flow model`:
.. _`control flow graphs`:
@@ -120,7 +116,7 @@
which are the basic data structures of the translation
process.
-All these types are defined in `pypy.objspace.flow.model`_ (which is a rather
+All these types are defined in `pypy/objspace/flow/model.py`_ (which is a rather
important module in the PyPy source base, to reinforce the point).
The flow graph of a function is represented by the class ``FunctionGraph``.
@@ -274,7 +270,6 @@
should not attempt to actually mutate such Constants.
.. _`document describing object spaces`: objspace.html
-.. _`pypy.objspace.flow.model`: ../../../../pypy/objspace/flow/model.py
.. _Annotator:
@@ -298,7 +293,7 @@
An "annotation" is an instance of a subclass of ``SomeObject``. Each
subclass that represents a specific family of objects.
-Here is an overview (see ``pypy.annotation.model``):
+Here is an overview (see ``pypy/annotation/model/``):
* ``SomeObject`` is the base class. An instance of ``SomeObject()``
represents any Python object, and as such usually means that the input
@@ -390,7 +385,7 @@
The RPython Typer
=================
-http://codespeak.net/pypy/trunk/pypy/rpython/
+https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/
The RTyper is the first place where the choice of backend makes a
difference; as outlined above we are assuming that ANSI C is the target.
@@ -456,7 +451,7 @@
`D07.1 Massive Parallelism and Translation Aspects`_ for further details.
.. _`Technical report`:
-.. _`D07.1 Massive Parallelism and Translation Aspects`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
+.. _`D07.1 Massive Parallelism and Translation Aspects`: https://bitbucket.org/pypy/extradoc/raw/ee3059291497/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
Backend Optimizations
---------------------
@@ -630,17 +625,13 @@
The C Back-End
==============
-http://codespeak.net/pypy/trunk/pypy/translator/c/
-
-GenC is not really documented at the moment. The basic principle of creating
-code from flow graphs is similar to the `Python back-end`_. See also
-"Generating C code" in our `EU report about translation`_.
+https://bitbucket.org/pypy/pypy/src/default/pypy/translator/c/
GenC is usually the most actively maintained backend -- everyone working on
PyPy has a C compiler, for one thing -- and is usually where new features are
implemented first.
-.. _`EU report about translation`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`EU report about translation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
A Historical Note
@@ -710,37 +701,22 @@
GenJVM is almost entirely the work of Niko Matsakis, who worked on it
also as part of the Summer of PyPy program.
-.. _`Python again`:
-.. _`Python back-end`:
-
-The Interpreter-Level backend
------------------------------
-
-http://codespeak.net/pypy/trunk/pypy/translator/geninterplevel.py
-
-Above, this backend was described as a "special case in several ways". One of
-these ways is that the job it does is specific to PyPy's standard interpreter,
-and the other is that it does not even use the annotator -- it works directly
-the graphs produced by the Flow Object Space.
-
-See `geninterp's documentation <geninterp.html>`__.
-
.. _extfunccalls:
External Function Calls
=======================
-External function call approach is described in `rffi`_ documentation.
+The external function call approach is described in `rffi`_ documentation.
.. _`rffi`: rffi.html
How It Fits Together
====================
-As should be clear by now, the translation tool chain of PyPy is a flexible
+As should be clear by now, the translation toolchain of PyPy is a flexible
and complicated beast, formed from many separate components.
-The following image summarizes the various parts of the tool chain as of the
+The following image summarizes the various parts of the toolchain as of the
0.9 release, with the default translation to C highlighted:
.. image:: image/pypy-translation-0.9.png
@@ -768,4 +744,4 @@
collection of functions (which may refer to each other in a mutually
recursive fashion) and annotate and rtype them all at once.
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.ootype.rst b/pypy/doc/config/translation.ootype.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.ootype.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-This group contains options specific for ootypesystem.
diff --git a/pypy/doc/old_news.rst b/pypy/doc/old_news.rst
deleted file mode 100644
--- a/pypy/doc/old_news.rst
+++ /dev/null
@@ -1,306 +0,0 @@
-The PyPy project aims at producing a flexible and fast Python_
-implementation. The guiding idea is to translate a Python-level
-description of the Python language itself to lower level languages.
-Rumors have it that the secret goal is being faster-than-C which is
-nonsense, isn't it? `more...`_
-
-.. _Python: http://www.python.org/doc/current/ref/ref.html
-.. _`more...`: architecture.html#mission-statement
-
-
-Leysin Winter Sports Sprint, 12th - 19th January 2008
-==================================================================
-
-.. raw:: html
-
- <table border=0><tr><td colspan="3">
-
-The next PyPy sprint will be held in Leysin, Switzerland, for
-the fifth time. The overall idea of the sprint is to continue
-working on making PyPy ready for general use.
-
-.. raw:: html
-
- </td></tr><tr><td valign="top">
-
-The proposed topics are: ctypes, JIT, testing, LLVM. This is
-a fully public sprint, so newcomers and other topics are
-welcome. And like previous winters, the main side goal is to
-have fun in winter sports :-) See the `sprint announcement`__
-for details.
-
-.. raw:: html
-
- </td><td>
- </td><td><img src="http://www.ermina.ch/002.JPG"></td></tr></table>
-
-.. __: http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2008/announcement.html
-
-
-PyPy blog started
-=================
-
-A few days ago some of the PyPy developers started a `PyPy Status Blog`_. Let's
-see how this works out. *(November 13th, 2007)*
-
-.. _`PyPy Status Blog`: http://morepypy.blogspot.com
-
-
-PyPy/Squeak Sprint in Bern finished
-===================================
-
-The Bern sprint, being the first Squeak-PyPy-collaboration-sprint is finished.
-The week was very intense and productive, see `Bern Sprint Summary blog post`_
-for a list of things we accomplished. We covered most of what happened during
-the sprint in quite some detail on the `PyPy Squeak blog`_. The sprint was
-hosted by the Software Composition Group of the University of Bern from the
-22nd to the 26th of October 2007.
-
-.. _`Bern sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/bern2007/announce.html
-.. _`people that are known to come`: http://codespeak.net/pypy/extradoc/sprintinfo/bern2007/people.html
-.. _`Bern Sprint Summary blog post`: http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html
-.. _`PyPy Squeak blog`: http://pypysqueak.blogspot.com
-
-
-
-PyPy Sprint in Gothenburg: 19nd-25th November 2007
-==================================================================
-
-
-The next post-EU-project PyPy sprint will be in Gothenburg, Sweden. It will
-focus on cleaning up the PyPy codebase and making it ready for the next round
-of improvements. It is a "public" sprint but it will probably be more suitable
-for people already somewhat acquainted with PyPy. For more information see the
-`Gothenburg sprint announcement`_ or a list of the `people that are known to
-come to Gothenburg`_.
-
-.. _`Gothenburg sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2007/announce.html
-.. _`people that are known to come to Gothenburg`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2007/people.html
-
-
-
-
-PyPy Sprint at EuroPython, Vilnius is finished
-==================================================================
-
-The sprint at the last EuroPython_ conference in Vilnius from the 9th to
-the 11th of July, 2007 is finished. For more information
-see the `Vilnius sprint announcement`_.
-
-
-.. _EuroPython: http://europython.org
-.. _`Vilnius sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/post-ep2007/announcement.html
-
-
-Review passed with flying colours
-=================================
-
-On the 31st of May 2007 the PyPy project was reviewed by the EU
-Commission in Brussels. Reviewers were Roel Wuyts, Unversité Libre de
-Bruxelles and Aki Lumiaho, Ramboll, Finland. Present was also our
-Project Officer, Charles McMillan. After 6 hours of presentations of
-the various aspects of the project, it only took the reviewers a few
-minutes to decide that the project was accepted, without any further
-work being required. Professor Wuyts, who has dynamic programming
-languages as his main field of research was very enthusiastic about
-the entire project and the results with the Just In Time Compiler
-Generator in particular. He offered his help in establishing
-collaborations with the communities around Prolog, Smalltalk, Lisp and
-other dynamic languages, as well as giving hints on how to get our
-results most widely publicized.
-
-The preparations for the review left the team rather exhausted so
-development progress will be rather slow until the sprint at
-Europython in the second week of July.
-
-PyPy EU funding period over, Review ahead
-===========================================================
-
-The 28 month EU project period of PyPy is over and new things are to come!
-On 11th May we `submitted last documents`_ to the European Union and are now
-heading towards a 31st May Review Meeting in Bruxelles. The `PyPy EU Final
-Activity Report`_ summarizes what we did and what we have in mind
-on technical, scientific and community levels. It also contains reflections
-and recommendations possibly interesting to other projects aiming at
-EU funded Open Source research. *(12th May, 2007)*
-
-.. _`submitted last documents`: http://codespeak.net/pypy/dist/pypy/doc/index-report.html
-.. _`PyPy EU Final Activity Report`: http://codespeak.net/pypy/extradoc/eu-report/PYPY-EU-Final-Activity-Report.pdf
-
-PyPy 1.0: JIT compiler generator, optimizations and more
-==================================================================
-
-We are proud to release PyPy 1.0.0, our sixth public release (Download_). See
-the `release announcement <release-1.0.0.html>`__ to read about the
-many new features in this release, especially the results of our
-JIT generation technology. See also our detailed instructions on
-how to `get started`_. *(March 27th, 2007)*
-
-.. _Download: getting-started.html#just-the-facts
-.. _`get started`: getting-started.html
-
-
-
-
-PyPy Trillke Sprints (25-28th Feb and 1-5th March 2007) finished
-==================================================================
-
-Both of the sprints that mark the end of the EU period are over. There were very
-good results, both on a `report level`_ as well as on a `technical level`_.
-The sprint also had a good discussion about the future of PyPy after the EU
-project ends, see the `mail Armin wrote`_ and `the meeting's minutes`_. You can
-also look at the pictures that `Carl Friedrich`_ and that `Lene took`_ during
-the sprint or read the `sprint announcement`_. *(March 10th, 2007)*
-
-.. _`sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/trillke-2007/announcement.html
-.. _`report level`: http://codespeak.net/pipermail/pypy-dev/2007q1/003578.html
-.. _`technical level`: http://codespeak.net/pipermail/pypy-dev/2007q1/003579.html
-.. _`Carl Friedrich`: http://codespeak.net/~cfbolz/hildesheim3-sprint-pictures/
-.. _`Lene took`: http://codespeak.net/~lene/trillke-sprint-web/Page1.html
-.. _`mail Armin wrote`: http://codespeak.net/pipermail/pypy-dev/2007q1/003577.html
-.. _`the meeting's minutes`: http://codespeak.net/svn/pypy/extradoc/minute/post-eu-structure.txt
-
-
-
-
-PyPy 0.99.0: optimizations, backends, new object spaces and more
-==================================================================
-
-We are proud to release PyPy 0.99.0, our fifth public release. See
-the `release announcement <release-0.99.0.html>`__ to read about the
-many new features in this release. See also our detailed instructions on
-how to `get started`_. *(February 17th, 2007)*
-
-.. _`get started`: getting-started.html
-
-
-py lib 0.9.0: py.test, distributed execution, greenlets and more
-==================================================================
-
-Our development support and testing library was publically released, see the
-`0.9 release announcement <http://codespeak.net/py/dist/release-0.9.0.html>`__
-and its extensive `online documentation <http://codespeak.net/py/dist/>`__.
-*(February 15th, 2007)*
-
-
-
-Leysin Winter Sports Sprint, 8th - 14th January 2007
-==================================================================
-
-.. raw:: html
-
- <table border=0><tr><td>
-
-The PyPy Leysin sprint is over. We worked hard on various topics, including
-preparing the upcoming py-lib and PyPy releases. For more details, see the
-`Leysin sprint report`_, the `Leysin announcement`_ and the
-`list of people present`_.
-
-
-.. raw:: html
-
- </td><td><img src="http://www.ermina.ch/002.JPG"></td></tr></table>
-
-.. _`Leysin announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2007/announcement.html
-.. _`Leysin sprint report`: http://codespeak.net/pipermail/pypy-dev/2007q1/003481.html
-.. _`list of people present`: http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2007/people.txt
-
-
-Massive Parallelism and Translation Aspects
-========================================================
-
-Our next big `EU report`_ about Stackless features, optimizations, and
-memory management is finished. You can download it `as pdf`_.
-
-.. _`EU report`: index-report.html
-.. _`as pdf`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
-
-
-Duesseldorf sprint #2, 30th October - 5th November over
-==================================================================
-
-The Duesseldorf sprint is over. It was a very productive sprint with work done
-in various areas. Read the `sprint report`_ for a detailed description of what
-was achieved and the `full announcement`_ for various details.
-
-.. _`full announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006b/announce.html
-.. _`sprint report`: http://codespeak.net/pipermail/pypy-dev/2006q4/003396.html
-
-
-
-Dynamic Languages Symposium (OOPSLA, 23rd October)
-==================================================================
-
-We will present a paper at the `Dynamic Languages Symposium`_ describing
-`PyPy's approach to virtual machine construction`_. The DLS is a
-one-day forum within OOPSLA'06 (Portland, Oregon, USA). The paper is a
-motivated overview of the annotation/rtyping translation tool-chain,
-with experimental results.
-
-As usual, terminology with PyPy is delicate :-) Indeed, the title is
-both correct and misleading - it does not describe "the" PyPy virtual
-machine, since we have never hand-written one. This paper focuses on
-how we are generating such VMs, not what they do.
-
-.. _`Dynamic Languages Symposium`: http://www.oopsla.org/2006/submission/tracks/dynamic_languages_symposium.html
-.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
-
-
-
-Summer of PyPy: Calls for proposals open now!
-==================================================================
-
-Happily, we are able to offer students mentoring and full sprint
-participant's funding if we receive a proposal outlining an
-interesting project related to PyPy and its development tools. This
-follows up on the "Summer of Code" campaign from Google but is
-completely independent from it and also works differently.
-See the full call for details:
-
- http://codespeak.net/pypy/dist/pypy/doc/summer-of-pypy.html
-
-
-Ireland sprint 21st-27th August
-==================================================================
-
-The last PyPy sprint happened in the nice city of
-Limerick in Ireland from 21st till 27th August.
-The main focus of the sprint was on JIT compiler works,
-various optimization works, porting extension modules,
-infrastructure works like a build tool for PyPy and
-extended (distributed) testing.
-Read the full `announcement`_ for more details.
-
-.. _`announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/ireland-2006/announce.html
-
-Release of PyPy video documentation
-==================================================================
-
-The PyPy team is happy to announce that the first bunch of PyPy videos
-can now be downloaded from:
-
-http://codespeak.net/pypy/dist/pypy/doc/video-index.html
-
-The videos introduce involved people and contain different talks, tutorials and
-interviews and can be downloaded via bittorrent. **29th June 2006**
-
-PyPy 0.9.0
-==================================================================
-
-We are proud to release PyPy 0.9.0, our fourth public release. See
-the `release announcement <release-0.9.0.html>`__ to read about the
-many new features in this release.
-
-PyPy and Summer of Code 2006
-==================================================================
-
-PyPy will again mentor students through Google's `Summer of Code`_
-campaign. Three students will kick-off their work on PyPy by
-participating in the Duesseldorf sprint. They will be exploring a
-back-end for Microsoft.NET, work on ways to build web applications
-with Javascript code (in this case by translating RPython to
-Javascript) and porting some CPython modules to use ctypes. Welcome to
-the team!
-
-.. _`Summer of Code`: http://code.google.com/soc/psf/about.html
-
diff --git a/pypy/doc/discussion/distribution.rst b/pypy/doc/discussion/distribution.rst
deleted file mode 100644
--- a/pypy/doc/discussion/distribution.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-===================================================
-(Semi)-transparent distribution of RPython programs
-===================================================
-
-Some (rough) ideas how I see distribution
------------------------------------------
-
-The main point about it, is to behave very much like JIT - not
-to perform distribution on Python source code level, but instead
-perform distribution of RPython source, and eventually perform
-distribution of interpreter at the end.
-
-This attempt gives same advantages as off-line JIT (any RPython based
-interpreter, etc.) and gives nice field to play with different
-distribution heuristics. This also makes eventually nice possibility
-of integrating JIT with distribution, thus allowing distribution
-heuristics to have more information that they might have otherwise and
-as well with specializing different nodes in performing different tasks.
-
-Flow graph level
-----------------
-
-Probably the best place to perform distribution attempt is to insert
-special graph distributing operations into low-level graphs (either lltype
-or ootype based), which will allow distribution heuristic to decide
-on entrypoint to block/graph/some other structure??? what variables/functions
-are accessed inside some part and if it's worth transferring it over wire.
-
-Backend level
--------------
-
-Backends will need explicit support for distribution of any kind. Basically
-it should be possible for backend to remotely call block/graph/structure
-in any manner (it should strongly depend on backend possibilities).
diff --git a/pypy/doc/config/objspace.usemodules._hashlib.rst b/pypy/doc/config/objspace.usemodules._hashlib.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._hashlib.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_hashlib' module.
-Used by the 'hashlib' standard lib module, and indirectly by the various cryptographic libs. This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules._socket.rst b/pypy/doc/config/objspace.usemodules._socket.txt
copy from pypy/doc/config/objspace.usemodules._socket.rst
copy to pypy/doc/config/objspace.usemodules._socket.txt
diff --git a/pypy/doc/maemo.rst b/pypy/doc/maemo.rst
deleted file mode 100644
--- a/pypy/doc/maemo.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-How to run PyPy on top of maemo platform
-========================================
-
-This howto explains how to use Scratchbox_ to cross-compile PyPy's
-Python Interpreter to an `Internet-Tablet-OS`_, more specifically
-the Maemo_ platform. This howto should work well for getting
-a usable Python Interpreter for Nokia's N810_ device.
-
-setup cross-compilation environment
--------------------------------------
-
-The main steps are to install scratchbox and the Maemo SDK. Please refer
-to Nokia's `INSTALL.txt`_ for more detail.
-
-Adjust linux kernel settings
-+++++++++++++++++++++++++++++++++
-
-In order to install and run scratchbox you will need to adjust
-your Linux kernel settings. Note that the VDSO setting may
-crash your computer - if that is the case, try running without
-this setting. You can try it like this::
-
- $ echo 4096 | sudo tee /proc/sys/vm/mmap_min_addr
- $ echo 0 | sudo tee /proc/sys/vm/vdso_enabled
-
-If that works fine for you (on some machines the vdso setting can freeze machines)
-you can make the changes permanent by editing ``/etc/sysctl.conf`` to contain::
-
- vm.vdso_enabled = 0
- vm.mmap_min_addr = 4096
-
-install scratchbox packages
-+++++++++++++++++++++++++++++++++
-
-Download
-
- http://repository.maemo.org/stable/diablo/maemo-scratchbox-install_4.1.1.sh
-
-and run this script as root::
-
- $ sh maemo-scratchbox-install_4.1.1.sh -s /scratchbox -u ACCOUNTNAME
-
-The script will automatically download Debian packages or tarballs
-and pre-configure a scratchbox environment with so called "devkits"
-and "toolchains" for performing cross-compilation. It's fine
-and recommended to use your linux account name as a scratchbox
-ACCOUNTNAME.
-
-It also sets up an "sbox" group on your system and makes you
-a member - giving the right to login to a scratchbox environment.
-
-testing that scratchbox environment works
-+++++++++++++++++++++++++++++++++++++++++++++++
-
-Login freshly to your Linux account in order to activate
-your membership in the "sbox" unix group and then type::
-
- $ /scratchbox/login
-
-This should warn you with something like "sb-conf: no current
-target" because we have not yet created a cross-compilation
-target.
-
-Note that Scratchbox starts daemon services which
-can be controlled via::
-
- /scratchbox/sbin/sbox_ctl start|stop
-
-
-Installing the Maemo SDK
-+++++++++++++++++++++++++++++++
-
-To mimic the specific N810_ environment we now install the Maemo-SDK.
-This will create an target within our new scratchbox environment
-that we then use to compile PyPy.
-
-Make sure that you are a member of the "sbox" group - this might
-require logging out and in again.
-
-Then, download
-
- http://repository.maemo.org/stable/diablo/maemo-sdk-install_4.1.1.sh
-
-and execute it with user privileges::
-
- $ sh maemo-sdk-install_4.1.1.sh
-
-When being asked select the default "Runtime + Dev" packages. You do not need
-Closed source Nokia binaries for PyPy. This installation
-script will download "rootstraps" and create so called
-"targets" and preselect the "DIABLO_ARMEL" target for ARM
-compilation. Within the targets a large number of packages
-will be pre-installed resulting in a base scratchbox
-environment that is usable for cross compilation of PyPy.
-
-Customizing the DIABLO_ARMEL target for PyPy
-++++++++++++++++++++++++++++++++++++++++++++++++
-
-As PyPy does not yet provide a debian package description
-file for use on Maemo, we have to install some dependencies manually
-into our Scratchbox target environment.
-
-1. Go into your scratchbox by executing ``/scratchbox/login``
- (this should bring you to a shell with the DIABLO_ARMEL target)
-
-2. Add these lines to ``/etc/apt/sources.list``::
-
- deb http://repository.maemo.org/extras/ diablo free non-free
- deb http://repository.maemo.org/extras-devel/ diablo free non-free
-
- NOTE: if you have an older version of Maemo on your device you
- can try substitute "chinook" for "diablo" in the above lines
- and/or update your firmware. You can probably see which version
- you are using by looking at the other content of the ``sources.list``.
-
-3. Perform ``apt-get update``.
-
-4. Install some necessary packages::
-
- apt-get install python2.5-dev libffi4-dev zlib1g-dev libbz2-dev libgc-dev libncurses5-dev
-
- The "libgc-dev" package is only needed if you want to use the Boehm
- garbage collector.
-
-5. Leave the scratchbox shell again with ``exit``.
-
-
-Translating PyPy for the Maemo platform
-------------------------------------------
-
-You at least need "gcc" and "libc-dev" packages on your host system
-to compile pypy. The scratchbox and its DIABLO_ARMEL target contains
-its own copies of GCC, various C libraries and header files
-which pypy needs for successful cross-compilation.
-
-Now, on the host system, perform a subversion checkout of PyPy::
-
- svn co https://codespeak.net/svn/pypy/trunk pypy-trunk
-
-Several svn revisions since the 60000's are known to work and
-the last manually tested one is currently 65011.
-
-Change to the ``pypy-trunk/pypy/translator/goal`` directory and execute::
-
- python translate.py --platform=maemo --opt=3
-
-You need to run translate.py using Python 2.5. This will last some 30-60
-minutes on most machines. For compiling the C source code PyPy's tool chain
-will use our scratchbox/Maemo cross-compilation environment.
-
-When this step succeeds, your ``goal`` directory will contain a binary called
-``pypy-c`` which is executable on the Maemo device. To run this binary
-on your device you need to also copy some support files. A good way to
-perform copies to your device is to install OpenSSH on the
-mobile device and use "scp" or rsync for transferring files.
-
-You can just copy your whole pypy-trunk directory over to your mobile
-device - however, only these should be needed::
-
- lib/pypy1.2/lib_pypy
- lib/pypy1.2/lib-python
- pypy/translator/goal/pypy-c
-
-It is necessary that the ``pypy-c`` can find a "lib-python" and "lib_pypy" directory
-if you want to successfully startup the interpreter on the device.
-
-Start ``pypy-c`` on the device. If you see an error like "setupterm: could not find terminal"
-you probably need to perform this install on the device::
-
- apt-get install ncurses-base
-
-Eventually you should see something like::
-
- Nokia-N810-51-3:~/pypy/trunk# ./pypy-c
- Python Python 2.5.2 (pypy 1.0.0 build 59527) on linux2
- Type "help", "copyright", "credits" or "license" for more information.
- And now for something completely different: ``E09 2K @CAA:85?''
- >>>>
-
-
-.. _N810: http://en.wikipedia.org/wiki/Nokia_N810
-.. _`Internet-Tablet-OS`: http://en.wikipedia.org/wiki/Internet_Tablet_OS
-.. _Maemo: http://www.maemo.org
-.. _Scratchbox: http://www.scratchbox.org
-.. _`INSTALL.txt`: http://tablets-dev.nokia.com/4.1/INSTALL.txt
-
-
diff --git a/pypy/doc/config/translation.cc.rst b/pypy/doc/config/translation.cc.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.cc.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Specify which C compiler to use.
diff --git a/pypy/doc/config/objspace.lonepycfiles.rst b/pypy/doc/config/objspace.lonepycfiles.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.lonepycfiles.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-If turned on, PyPy accepts to import a module ``x`` if it finds a
-file ``x.pyc`` even if there is no file ``x.py``.
-
-This is the way that CPython behaves, but it is disabled by
-default for PyPy because it is a common cause of issues: most
-typically, the ``x.py`` file is removed (manually or by a
-version control system) but the ``x`` module remains
-accidentally importable because the ``x.pyc`` file stays
-around.
-
-The usual reason for wanting this feature is to distribute
-non-open-source Python programs by distributing ``pyc`` files
-only, but this use case is not practical for PyPy at the
-moment because multiple versions of PyPy compiled with various
-optimizations might be unable to load each other's ``pyc``
-files.
diff --git a/pypy/doc/config/objspace.std.withtypeversion.rst b/pypy/doc/config/objspace.std.withtypeversion.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withtypeversion.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-This (mostly internal) option enables "type versions": Every type object gets an
-(only internally visible) version that is updated when the type's dict is
-changed. This is e.g. used for invalidating caches. It does not make sense to
-enable this option alone.
-
-.. internal
diff --git a/pypy/doc/image/parsing_example1.dot b/pypy/doc/image/parsing_example1.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example1.dot
+++ /dev/null
@@ -1,27 +0,0 @@
-digraph G{
-"-1213931828" [label="additive"];
-"-1213931828" -> "-1213951956";
-"-1213951956" [label="multitive"];
-"-1213951956" -> "-1213949172";
-"-1213949172" [label="primary"];
-"-1213949172" -> "-1213949812";
-"-1213949812" [shape=box,label="DECIMAL\l'12'"];
-"-1213931828" -> "-1213935220";
-"-1213935220" [shape=box,label="__0_+\l'+'"];
-"-1213931828" -> "-1213951316";
-"-1213951316" [label="additive"];
-"-1213951316" -> "-1213948180";
-"-1213948180" [label="multitive"];
-"-1213948180" -> "-1213951380";
-"-1213951380" [label="primary"];
-"-1213951380" -> "-1213951508";
-"-1213951508" [shape=box,label="DECIMAL\l'4'"];
-"-1213948180" -> "-1213948788";
-"-1213948788" [shape=box,label="__1_*\l'*'"];
-"-1213948180" -> "-1213951060";
-"-1213951060" [label="multitive"];
-"-1213951060" -> "-1213948980";
-"-1213948980" [label="primary"];
-"-1213948980" -> "-1213950420";
-"-1213950420" [shape=box,label="DECIMAL\l'5'"];
-}
diff --git a/pypy/doc/config/translation.thread.rst b/pypy/doc/config/translation.thread.txt
copy from pypy/doc/config/translation.thread.rst
copy to pypy/doc/config/translation.thread.txt
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.rst b/pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.txt
copy from pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.rst
copy to pypy/doc/config/translation.backendopt.profile_based_inline_heuristic.txt
diff --git a/pypy/doc/config/objspace.usemodules.fcntl.rst b/pypy/doc/config/objspace.usemodules.fcntl.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.fcntl.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'fcntl' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/config/objspace.disable_call_speedhacks.rst b/pypy/doc/config/objspace.disable_call_speedhacks.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.disable_call_speedhacks.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-disable the speed hacks that the interpreter normally does. Usually you don't
-want to set this to False, but some object spaces require it.
diff --git a/pypy/doc/config/objspace.usemodules.gc.rst b/pypy/doc/config/objspace.usemodules.gc.txt
copy from pypy/doc/config/objspace.usemodules.gc.rst
copy to pypy/doc/config/objspace.usemodules.gc.txt
diff --git a/pypy/doc/config/objspace.std.withsmalllong.rst b/pypy/doc/config/objspace.std.withsmalllong.txt
copy from pypy/doc/config/objspace.std.withsmalllong.rst
copy to pypy/doc/config/objspace.std.withsmalllong.txt
diff --git a/pypy/doc/config/objspace.nofaking.rst b/pypy/doc/config/objspace.nofaking.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.nofaking.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-This options prevents the automagic borrowing of implementations of
-modules and types not present in PyPy from CPython.
-
-As such, it is required when translating, as then there is no CPython
-to borrow from. For running py.py it is useful for testing the
-implementation of modules like "posix", but it makes everything even
-slower than it is already.
diff --git a/pypy/doc/config/translation.gctransformer.rst b/pypy/doc/config/translation.gctransformer.txt
copy from pypy/doc/config/translation.gctransformer.rst
copy to pypy/doc/config/translation.gctransformer.txt
diff --git a/pypy/doc/config/translation.backend.rst b/pypy/doc/config/translation.backend.txt
copy from pypy/doc/config/translation.backend.rst
copy to pypy/doc/config/translation.backend.txt
diff --git a/pypy/doc/config/translation.backendopt.really_remove_asserts.rst b/pypy/doc/config/translation.backendopt.really_remove_asserts.txt
copy from pypy/doc/config/translation.backendopt.really_remove_asserts.rst
copy to pypy/doc/config/translation.backendopt.really_remove_asserts.txt
diff --git a/pypy/doc/__pypy__-module.rst b/pypy/doc/__pypy__-module.rst
--- a/pypy/doc/__pypy__-module.rst
+++ b/pypy/doc/__pypy__-module.rst
@@ -37,27 +37,29 @@
.. _`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
-================================
+.. broken:
-When the taint object space is used (choose with :config:`objspace.name`),
-the following names are put into ``__pypy__``:
+ Taint Object Space Functionality
+ ================================
- - ``taint``
- - ``is_tainted``
- - ``untaint``
- - ``taint_atomic``
- - ``_taint_debug``
- - ``_taint_look``
- - ``TaintError``
+ When the taint object space is used (choose with :config:`objspace.name`),
+ the following names are put into ``__pypy__``:
-Those are all described in the `interface section of the taint object space
-docs`_.
+ - ``taint``
+ - ``is_tainted``
+ - ``untaint``
+ - ``taint_atomic``
+ - ``_taint_debug``
+ - ``_taint_look``
+ - ``TaintError``
-For more detailed explanations and examples see the `taint object space docs`_.
+ Those are all described in the `interface section of 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
+ 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
===============================
diff --git a/pypy/doc/config/objspace.usemodules.exceptions.rst b/pypy/doc/config/objspace.usemodules.exceptions.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.exceptions.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'exceptions' module.
-This module is essential, included by default and should not be removed.
diff --git a/pypy/doc/config/objspace.std.withstrjoin.rst b/pypy/doc/config/objspace.std.withstrjoin.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withstrjoin.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Enable "string join" objects.
-
-See the page about `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#string-join-objects
-
-
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal.txt
copy from pypy/doc/config/translation.backendopt.clever_malloc_removal.rst
copy to pypy/doc/config/translation.backendopt.clever_malloc_removal.txt
diff --git a/pypy/doc/config/objspace.usemodules.gc.rst b/pypy/doc/config/objspace.usemodules.gc.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.gc.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Use the 'gc' module.
-This module is expected to be working and is included by default.
-Note that since the gc module is highly implementation specific, it contains
-only the ``collect`` function in PyPy, which forces a collection when compiled
-with the framework or with Boehm.
diff --git a/pypy/doc/config/objspace.usemodules.micronumpy.rst b/pypy/doc/config/objspace.usemodules.micronumpy.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.micronumpy.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the micronumpy module.
-This module provides a very basic numpy-like interface. Major use-case
-is to show how jit scales for other code.
diff --git a/pypy/doc/config/translation.log.rst b/pypy/doc/config/translation.log.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.log.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Include debug prints in the translation.
-
-These must be enabled by setting the PYPYLOG environment variable.
-The exact set of features supported by PYPYLOG is described in
-pypy/translation/c/src/debug.h.
diff --git a/pypy/doc/discussion/oz-thread-api.rst b/pypy/doc/discussion/oz-thread-api.rst
deleted file mode 100644
--- a/pypy/doc/discussion/oz-thread-api.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-Some rough notes about the Oz threading model
-=============================================
-
-(almost verbatim from CTM)
-
-Scheduling
-----------
-
-Fair scheduling through round-robin.
-
-With priority levels : three queues exist, which manage high, medium,
-low priority threads. The time slice ratio for these is
-100:10:1. Threads inherit the priority of their parent.
-
-Mozart uses an external timer approach to implement thread preemption.
-
-Thread ops
-----------
-
-All these ops are defined in a Thread namespace/module.
-
-this() -> current thread's name (*not* another thread's name)
-state(t) -> return state of t in {runnable, blocked, terminated}
-suspend(t) : suspend t
-resume(t) : resume execution of t
-preempt(t) : preempt t
-terminate(t) : terminate t immediately
-injectException(t, e) : raise exception e in t
-setPriority(t, p) : set t's priority to p
-
-Interestingly, coroutines can be build upon this thread
-API. Coroutines have two ops : spawn and resume.
-
-spawn(p) -> creates a coroutine with procedure p, returns pid
-resume(c) : transfers control from current coroutine to c
-
-The implementation of these ops in terms of the threads API is as
-follows :
-
-def spawn(p):
- in_thread:
- pid = Thread.this()
- Thread.suspend(pid)
- p()
-
-def resume(cid):
- Thread.resume cid
- Thread.suspend(Thread.this())
-
diff --git a/pypy/doc/config/objspace.usemodules.rbench.rst b/pypy/doc/config/objspace.usemodules.rbench.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.rbench.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the built-in 'rbench' module.
-This module contains geninterpreted versions of pystone and richards,
-so it is useful to measure the interpretation overhead of the various
-pypy-\*.
diff --git a/pypy/doc/config/objspace.usemodules.__builtin__.rst b/pypy/doc/config/objspace.usemodules.__builtin__.txt
copy from pypy/doc/config/objspace.usemodules.__builtin__.rst
copy to pypy/doc/config/objspace.usemodules.__builtin__.txt
diff --git a/pypy/doc/config/objspace.std.withstrbuf.rst b/pypy/doc/config/objspace.std.withstrbuf.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withstrbuf.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Enable "string buffer" objects.
-
-Similar to "string join" objects, but using a StringBuilder to represent
-a string built by repeated application of ``+=``.
diff --git a/pypy/doc/config/translation.compilerflags.rst b/pypy/doc/config/translation.compilerflags.txt
copy from pypy/doc/config/translation.compilerflags.rst
copy to pypy/doc/config/translation.compilerflags.txt
diff --git a/pypy/doc/cleanup.rst b/pypy/doc/cleanup.rst
--- a/pypy/doc/cleanup.rst
+++ b/pypy/doc/cleanup.rst
@@ -5,41 +5,12 @@
.. doc-index: This needs merging somehow
-.. svn-help.rst: Needs merging/replacing with hg stuff:
-
-
.. toctree::
- buildtool.rst
distribution.rst
- externaltools.rst
-
- geninterp.rst
-
- objspace-proxies.rst
-
- old_news.rst
-
- project-ideas.rst
-
- rffi.rst
-
- sandbox.rst
-
- statistic/index.rst
-
- theory.rst
-
- translation-aspects.rst
-
- docindex.rst
-
- svn-help.rst
-
dot-net.rst
- maemo.rst
diff --git a/pypy/doc/config/objspace.usemodules.cmath.rst b/pypy/doc/config/objspace.usemodules.cmath.txt
copy from pypy/doc/config/objspace.usemodules.cmath.rst
copy to pypy/doc/config/objspace.usemodules.cmath.txt
diff --git a/pypy/doc/config/objspace.usemodules._bisect.rst b/pypy/doc/config/objspace.usemodules._bisect.txt
copy from pypy/doc/config/objspace.usemodules._bisect.rst
copy to pypy/doc/config/objspace.usemodules._bisect.txt
diff --git a/pypy/doc/config/translation.no__thread.rst b/pypy/doc/config/translation.no__thread.txt
copy from pypy/doc/config/translation.no__thread.rst
copy to pypy/doc/config/translation.no__thread.txt
diff --git a/pypy/doc/config/translation.backendopt.inline.rst b/pypy/doc/config/translation.backendopt.inline.txt
copy from pypy/doc/config/translation.backendopt.inline.rst
copy to pypy/doc/config/translation.backendopt.inline.txt
diff --git a/pypy/doc/config/objspace.usemodules._minimal_curses.rst b/pypy/doc/config/objspace.usemodules._minimal_curses.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._minimal_curses.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_curses' module.
-This module is just a stub. It only implements a few functions.
diff --git a/pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.rst b/pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-Introduce a new opcode called ``CALL_LIKELY_BUILTIN``. It is used when something
-is called, that looks like a builtin function (but could in reality be shadowed
-by a name in the module globals). For all module globals dictionaries it is
-then tracked which builtin name is shadowed in this module. If the
-``CALL_LIKELY_BUILTIN`` opcode is executed, it is checked whether the builtin is
-shadowed. If not, the corresponding builtin is called. Otherwise the object that
-is shadowing it is called instead. If no shadowing is happening, this saves two
-dictionary lookups on calls to builtins.
-
-For more information, see the section in `Standard Interpreter Optimizations`_.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#call-likely-builtin
diff --git a/pypy/doc/config/objspace.usemodules.symbol.rst b/pypy/doc/config/objspace.usemodules.symbol.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.symbol.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'symbol' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/cli-backend.rst b/pypy/doc/cli-backend.rst
--- a/pypy/doc/cli-backend.rst
+++ b/pypy/doc/cli-backend.rst
@@ -198,12 +198,12 @@
int_add
STORE v2
-The code produced works correctly but has some inefficiency issue that
+The code produced works correctly but has some inefficiency issues that
can be addressed during the optimization phase.
The CLI Virtual Machine is fairly expressive, so the conversion
between PyPy's low level operations and CLI instruction is relatively
-simple: many operations maps directly to the correspondent
+simple: many operations maps directly to the corresponding
instruction, e.g int_add and sub.
By contrast some instructions do not have a direct correspondent and
@@ -223,7 +223,7 @@
Mapping exceptions
------------------
-Both RPython and CLI have its own set of exception classes: some of
+Both RPython and CLI have their own set of exception classes: some of
these are pretty similar; e.g., we have OverflowError,
ZeroDivisionError and IndexError on the first side and
OverflowException, DivideByZeroException and IndexOutOfRangeException
@@ -435,14 +435,14 @@
To do so, you can install `Python for .NET`_. Unfortunately, it does
not work out of the box under Linux.
-To make it working, download and unpack the source package of Python
+To make it work, download and unpack the source package of Python
for .NET; the only version tested with PyPy is the 1.0-rc2, but it
might work also with others. Then, you need to create a file named
Python.Runtime.dll.config at the root of the unpacked archive; put the
-following lines inside the file (assuming you are using Python 2.4)::
+following lines inside the file (assuming you are using Python 2.7)::
<configuration>
- <dllmap dll="python24" target="libpython2.4.so.1.0" os="!windows"/>
+ <dllmap dll="python27" target="libpython2.7.so.1.0" os="!windows"/>
</configuration>
The installation should be complete now. To run Python for .NET,
diff --git a/pypy/doc/config/translation.backendopt.storesink.rst b/pypy/doc/config/translation.backendopt.storesink.txt
copy from pypy/doc/config/translation.backendopt.storesink.rst
copy to pypy/doc/config/translation.backendopt.storesink.txt
diff --git a/pypy/doc/needswork.txt b/pypy/doc/needswork.txt
new file mode 100644
--- /dev/null
+++ b/pypy/doc/needswork.txt
@@ -0,0 +1,3 @@
+.. warning::
+
+ This documentation needs work (as discussed during the Gothenburg sprint in 2011)
diff --git a/pypy/doc/getting-started-dev.rst b/pypy/doc/getting-started-dev.rst
--- a/pypy/doc/getting-started-dev.rst
+++ b/pypy/doc/getting-started-dev.rst
@@ -10,10 +10,9 @@
-------------------------
The translator is a tool based on the PyPy interpreter which can translate
-sufficiently static Python programs into low-level code (in particular it can
-be used to translate the `full Python interpreter`_). To be able to use it
-you need to (if you want to look at the flowgraphs, which you obviously
-should):
+sufficiently static RPython programs into low-level code (in particular it can
+be used to translate the `full Python interpreter`_). To be able to experiment with it
+you need to:
* Download and install Pygame_.
@@ -99,7 +98,7 @@
9
To translate and run for the CLI you must have the SDK installed: Windows
-users need the `.NET Framework SDK 2.0`_, while Linux and Mac users
+users need the `.NET Framework SDK`_, while Linux and Mac users
can use Mono_. To translate and run for the JVM you must have a JDK
installed (at least version 5) and ``java``/``javac`` on your path.
@@ -146,41 +145,39 @@
Where to start reading the sources
----------------------------------
-PyPy is made from parts that are relatively independent from each other.
+PyPy is made from parts that are relatively independent of each other.
You should start looking at the part that attracts you most (all paths are
relative to the PyPy top level directory). You may look at our `directory reference`_
or start off at one of the following points:
* `pypy/interpreter`_ contains the bytecode interpreter: bytecode dispatcher
- in pyopcode.py_, frame and code objects in eval.py_ and pyframe.py_,
- function objects and argument passing in function.py_ and argument.py_,
- the object space interface definition in baseobjspace.py_, modules in
- module.py_ and mixedmodule.py_. Core types supporting the bytecode
- interpreter are defined in typedef.py_.
+ in `pypy/interpreter/pyopcode.py`_, frame and code objects in `pypy/interpreter/eval.py`_ and `pypy/interpreter/pyframe.py`_,
+ function objects and argument passing in `pypy/interpreter/function.py`_ and `pypy/interpreter/argument.py`_,
+ the object space interface definition in `pypy/interpreter/baseobjspace.py`_, modules in
+ `pypy/interpreter/module.py`_ and `pypy/interpreter/mixedmodule.py`_. Core types supporting the bytecode
+ interpreter are defined in `pypy/interpreter/typedef.py`_.
* `pypy/interpreter/pyparser`_ contains a recursive descent parser,
- and input data files that allow it to parse both Python 2.3 and 2.4
- syntax. Once the input data has been processed, the parser can be
+ and grammar files that allow it to parse the syntax of various Python
+ versions. Once the grammar has been processed, the parser can be
translated by the above machinery into efficient code.
* `pypy/interpreter/astcompiler`_ contains the compiler. This
contains a modified version of the compiler package from CPython
- that fixes some bugs and is translatable. That the compiler and
- parser are translatable is new in 0.8.0 and it makes using the
- resulting binary interactively much more pleasant.
+ that fixes some bugs and is translatable.
* `pypy/objspace/std`_ contains the `Standard object space`_. The main file
- is objspace.py_. For each type, the files ``xxxtype.py`` and
+ is `pypy/objspace/std/objspace.py`_. For each type, the files ``xxxtype.py`` and
``xxxobject.py`` contain respectively the definition of the type and its
(default) implementation.
-* `pypy/objspace`_ contains a few other object spaces: the thunk_,
- trace_ and flow_ object spaces. The latter is a relatively short piece
+* `pypy/objspace`_ contains a few other object spaces: the `pypy/objspace/thunk.py`_,
+ `pypy/objspace/trace.py`_ and `pypy/objspace/flow`_ object spaces. The latter is a relatively short piece
of code that builds the control flow graphs when the bytecode interpreter
runs in it.
* `pypy/translator`_ contains the code analysis and generation stuff.
- Start reading from translator.py_, from which it should be easy to follow
+ Start reading from translator.py, from which it should be easy to follow
the pieces of code involved in the various translation phases.
* `pypy/annotation`_ contains the data model for the type annotation that
@@ -190,24 +187,25 @@
* `pypy/rpython`_ contains the code of the RPython typer. The typer transforms
annotated flow graphs in a way that makes them very similar to C code so
that they can be easy translated. The graph transformations are controlled
- by the stuff in `pypy/rpython/rtyper.py`_. The object model that is used can
+ by the code in `pypy/rpython/rtyper.py`_. The object model that is used can
be found in `pypy/rpython/lltypesystem/lltype.py`_. For each RPython type
there is a file rxxxx.py that contains the low level functions needed for
this type.
-* `pypy/rlib`_ contains the RPython standard library, things that you can
+* `pypy/rlib`_ contains the `RPython standard library`_, things that you can
use from rpython.
+.. _`RPython standard library`: rlib.html
+
.. _optionaltool:
Running PyPy's unit tests
-------------------------
-PyPy development always was and is still thorougly test-driven.
+PyPy development always was and is still thoroughly test-driven.
We use the flexible `py.test testing tool`_ which you can `install independently
-<http://pytest.org/getting-started.html>`_ and use indepedently
-from PyPy for other projects.
+<http://pytest.org/getting-started.html>`_ and use for other projects.
The PyPy source tree comes with an inlined version of ``py.test``
which you can invoke by typing::
@@ -263,7 +261,7 @@
If you start an untranslated Python interpreter via::
- python pypy-svn/pypy/bin/py.py
+ python pypy/bin/py.py
If you press
<Ctrl-C> on the console you enter the interpreter-level console, a
@@ -347,18 +345,6 @@
pygame: http://www.pygame.org/download.shtml
-CTypes on Python 2.4
-++++++++++++++++++++++++++++
-
-`ctypes`_ is included in CPython 2.5 and higher. CPython 2.4 users needs to
-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
-.. _`ctypes`: http://starship.python.net/crew/theller/ctypes/
-
-.. _`py.test`:
-
py.test and the py lib
+++++++++++++++++++++++
@@ -367,7 +353,7 @@
We use the `py library`_ for filesystem path manipulations, terminal
writing, logging and some other support functionality.
-You don't neccessarily need to install these two libraries because
+You don't necessarily need to install these two libraries because
we also ship them inlined in the PyPy source tree.
Getting involved
@@ -390,33 +376,18 @@
.. _`Spidermonkey`: http://www.mozilla.org/js/spidermonkey/
-.. _`.NET Framework SDK 2.0`: http://msdn.microsoft.com/netframework/downloads/updates/default.aspx
+.. _`.NET Framework SDK`: http://msdn.microsoft.com/netframework/
.. _Mono: http://www.mono-project.com/Main_Page
.. _`CLI backend`: cli-backend.html
.. _clr: clr-module.html
.. _`Dot Graphviz`: http://www.graphviz.org/
.. _Pygame: http://www.pygame.org/
-.. _pyopcode.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/pyopcode.py
-.. _eval.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/eval.py
-.. _pyframe.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/pyframe.py
-.. _function.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/function.py
-.. _argument.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/argument.py
-.. _baseobjspace.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/baseobjspace.py
-.. _module.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/module.py
-.. _mixedmodule.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/mixedmodule.py
-.. _typedef.py: http://codespeak.net/svn/pypy/trunk/pypy/interpreter/typedef.py
.. _Standard object space: objspace.html#the-standard-object-space
-.. _objspace.py: ../../../../pypy/objspace/std/objspace.py
-.. _thunk: ../../../../pypy/objspace/thunk.py
-.. _trace: ../../../../pypy/objspace/trace.py
-.. _flow: ../../../../pypy/objspace/flow/
-.. _translator.py: ../../../../pypy/translator/translator.py
.. _mailing lists: index.html
-.. _documentation: docindex.html
+.. _documentation: index.html#project-documentation
.. _unit tests: coding-guide.html#test-design
-.. _`directory reference`: docindex.html#directory-reference
+.. _`directory reference`: index.html#pypy-directory-reference
-.. include:: _ref.rst
-
+.. include:: _ref.txt
diff --git a/pypy/doc/image/parsing_example9.dot b/pypy/doc/image/parsing_example9.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example9.dot
+++ /dev/null
@@ -1,13 +0,0 @@
-digraph G{
-"-1219430228" [label="list"];
-"-1219430228" -> "-1213608980";
-"-1213608980" [shape=box,label="DECIMAL\n'1'"];
-"-1219430228" -> "-1213623380";
-"-1213623380" [shape=box,label="DECIMAL\n'2'"];
-"-1219430228" -> "-1213441652";
-"-1213441652" [shape=box,label="DECIMAL\n'3'"];
-"-1219430228" -> "-1213441620";
-"-1213441620" [shape=box,label="DECIMAL\n'4'"];
-"-1219430228" -> "-1213442100";
-"-1213442100" [shape=box,label="DECIMAL\n'5'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/interpreter.rst b/pypy/doc/interpreter.rst
--- a/pypy/doc/interpreter.rst
+++ b/pypy/doc/interpreter.rst
@@ -14,7 +14,7 @@
PyPy's bytecode interpreter has a structure reminiscent of CPython's
Virtual Machine: It processes code objects parsed and compiled from
-Python source code. It is implemented in the `interpreter/`_ directory.
+Python source code. It is implemented in the `pypy/interpreter/`_ directory.
People familiar with the CPython implementation will easily recognize
similar concepts there. The major differences are the overall usage of
the `object space`_ indirection to perform operations on objects, and
@@ -22,12 +22,13 @@
Code objects are a nicely preprocessed, structured representation of
source code, and their main content is *bytecode*. We use the same
-compact bytecode format as CPython 2.4. Our bytecode compiler is
+compact bytecode format as CPython 2.7, with minor differences in the bytecode
+set. Our bytecode compiler is
implemented as a chain of flexible passes (tokenizer, lexer, parser,
abstract syntax tree builder, bytecode generator). The latter passes
are based on the ``compiler`` package from the standard library of
CPython, with various improvements and bug fixes. The bytecode compiler
-(living under `interpreter/astcompiler/`_) is now integrated and is
+(living under `pypy/interpreter/astcompiler/`_) is now integrated and is
translated with the rest of PyPy.
Code objects contain
@@ -37,7 +38,7 @@
calling its ``frame.eval()`` method. This main entry point
initialize appropriate namespaces and then interprets each
bytecode instruction. Python's standard library contains
-the `lib-python/2.5.2/dis.py`_ module which allows to view
+the `lib-python/2.7.0/dis.py`_ module which allows to view
the Virtual's machine bytecode instructions::
>>> import dis
@@ -145,21 +146,15 @@
file location can be constructed for tracebacks
Moreover the Frame class itself has a number of methods which implement
-the actual bytecodes found in a code object. In fact, PyPy already constructs
-four specialized Frame class variants depending on the code object:
+the actual bytecodes found in a code object. The methods of the ``PyFrame``
+class are added in various files:
-- PyInterpFrame (in `pypy/interpreter/pyopcode.py`_) for
- basic simple code objects (not involving generators or nested scopes)
+- the class ``PyFrame`` is defined in `pypy/interpreter/pyframe.py`_.
-- PyNestedScopeFrame (in `pypy/interpreter/nestedscope.py`_)
- for code objects that reference nested scopes, inherits from PyInterpFrame
+- the file `pypy/interpreter/pyopcode.py`_ add support for all Python opcode.
-- PyGeneratorFrame (in `pypy/interpreter/generator.py`_)
- for code objects that yield values to the caller, inherits from PyInterpFrame
-
-- PyNestedScopeGeneratorFrame for code objects that reference
- nested scopes and yield values to the caller, inherits from both PyNestedScopeFrame
- and PyGeneratorFrame
+- nested scope support is added to the ``PyFrame`` class in
+ `pypy/interpreter/nestedscope.py`_.
.. _Code:
@@ -269,7 +264,7 @@
example and the higher level `chapter on Modules in the coding
guide`_.
-.. _`__builtin__ module`: http://codespeak.net/svn/pypy/trunk/pypy/module/
+.. _`__builtin__ module`: https://bitbucket.org/pypy/pypy/src/tip/pypy/module/__builtin__/
.. _`chapter on Modules in the coding guide`: coding-guide.html#modules
.. _`Gateway classes`:
@@ -407,4 +402,4 @@
as a reference for the exact attributes of interpreter classes visible
at application level.
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.cli.rst b/pypy/doc/config/translation.cli.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.cli.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/translation.backendopt.remove_asserts.rst b/pypy/doc/config/translation.backendopt.remove_asserts.txt
copy from pypy/doc/config/translation.backendopt.remove_asserts.rst
copy to pypy/doc/config/translation.backendopt.remove_asserts.txt
diff --git a/pypy/doc/getting-started.rst b/pypy/doc/getting-started.rst
--- a/pypy/doc/getting-started.rst
+++ b/pypy/doc/getting-started.rst
@@ -9,46 +9,117 @@
What is PyPy ?
==============
-PyPy is an implementation of the Python_ programming language written in
-Python itself, flexible and easy to experiment with.
+In common parlance, PyPy has been used to mean two things. The first is the
+`RPython translation toolchain`_, which is a framework for generating
+dynamic programming language implementations. And the second is one
+particular implementation that is so generated --
+an implementation of the Python_ programming language written in
+Python itself. It is designed to be flexible and easy to experiment with.
+
+This double usage has proven to be confusing, and we are trying to move
+away from using the word PyPy to mean both things. From now on we will
+try to use PyPy to only mean the Python implementation, and say the
+`RPython translation toolchain`_ when we mean the framework. Some older
+documents, presentations, papers and videos will still have the old
+usage. You are hereby warned.
+
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, 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
+.. _Python: http://docs.python.org/reference/
+.. _`RPython translation toolchain`: translation.html
.. _`more...`: architecture.html
Just the facts
==============
+Download a pre-built PyPy
+-------------------------
+
+The quickest way to start using PyPy is to download a prebuilt binary for your
+OS and architecture. You can either use the `most recent release`_ or one of
+our `development nightly build`_. Please note that the nightly builds are not
+guaranteed to be as stable as official releases, use them at your own risk.
+
+.. _`most recent release`: http://pypy.org/download.html
+.. _`development nightly build`: http://buildbot.pypy.org/nightly/trunk/
+
+Installing PyPy
+---------------
+
+PyPy is ready to be executed as soon as you unpack the tarball or the zip
+file, with no need install it in any specific location::
+
+ $ tar xf pypy-1.5-linux.tar.bz2
+
+ $ ./pypy-1.5-linux/bin/pypy
+ Python 2.7.1 (?, Apr 27 2011, 12:44:21)
+ [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2
+ Type "help", "copyright", "credits" or "license" for more information.
+ And now for something completely different: ``implementing LOGO in LOGO:
+ "turtles all the way down"''
+ >>>>
+
+If you want to make PyPy available system-wide, you can put a symlink to the
+``pypy`` executable in ``/usr/local/bin``. It is important to put a symlink
+and not move the binary there, else PyPy would not be able to find its
+library.
+
+If you want to install 3rd party libraries, the most convenient way is to
+install distribute_ and pip_:
+
+ $ curl -O http://python-distribute.org/distribute_setup.py
+
+ $ curl -O https://github.com/pypa/pip/raw/master/contrib/get-pip.py
+
+ $ ./pypy-1.5-linux/bin/pypy distribute_setup.py
+
+ $ ./pypy-1.5-linux/bin/pypy get-pip.py
+
+ $ ./pypy-1.5-linux/bin/pip install pygments # for example
+
+3rd party libraries will be installed in ``pypy-1.5-linux/site-packages``, and
+the scripts in ``pypy-1.5-linux/bin``.
+
+Installing using virtualenv
+---------------------------
+
+It is often convenient to run pypy inside a virtualenv. To do this
+you need a recent version of virtualenv -- 1.6.1 or greater. You can
+then install PyPy both from a precompiled tarball or from a mercurial
+checkout::
+
+ # from a tarball
+ $ virtualenv -p /opt/pypy-c-jit-41718-3fb486695f20-linux/bin/pypy my-pypy-env
+
+ # from the mercurial checkout
+ $ virtualenv -p /path/to/pypy/pypy/translator/goal/pypy-c my-pypy-env
+
+Note that bin/python is now a symlink to bin/pypy.
+
+.. _`distribute`: http://www.python-distribute.org/
+.. _`pip`: http://pypi.python.org/pypi/pip
+
+
Clone the repository
--------------------
-Before you can play with PyPy, you will need to obtain a copy
-of the sources. This can be done either by `downloading them
-from the download page`_ or by checking them out from the
-repository using mercurial. We suggest using mercurial if one
-wants to access the current development.
+If you prefer to `compile PyPy by yourself`_, or if you want to modify it, you
+will need to obtain a copy of the sources. This can be done either by
+`downloading them from the download page`_ or by checking them out from the
+repository using mercurial. We suggest using mercurial if one wants to access
+the current development.
.. _`downloading them from the download page`: http://pypy.org/download.html
-If you choose to use mercurial,
-first make sure you have ``subversion`` installed.
You must issue the following command on your
command line, DOS box, or terminal::
hg clone http://bitbucket.org/pypy/pypy pypy
-If you get an error like this::
-
- abort: repository [svn]http://codespeak.net/svn/pypy/build/testrunner not found!
-
-it probably means that your mercurial version is too old. You need at least
-Mercurial 1.6 to clone the PyPy repository.
-
This will clone the repository and place it into a directory
named ``pypy``, and will get you the PyPy source in
``pypy/pypy`` and documentation files in ``pypy/pypy/doc``.
@@ -64,39 +135,26 @@
where XXXXX is the revision id.
+
+.. _`compile PyPy by yourself`: getting-started-python.html
.. _`our nightly tests:`: http://buildbot.pypy.org/summary?branch=<trunk>
-If you want to commit to our repository on bitbucket, you will have to
-install subversion in addition to mercurial.
-
-Installing using virtualenv
----------------------------
-
-It is often convenient to run pypy inside a virtualenv. To do this
-you need a recent version of virtualenv -- 1.5 or greater. You can
-then install PyPy both from a precompiled tarball or from a mercurial
-checkout::
-
- # from a tarball
- $ virtualenv -p /opt/pypy-c-jit-41718-3fb486695f20-linux/bin/pypy my-pypy-env
-
- # from the mercurial checkout
- $ virtualenv -p /path/to/pypy/pypy/translator/goal/pypy-c my-pypy-env
-
-Note that bin/python is now a symlink to bin/pypy.
-
-
Where to go from here
-----------------------
+======================
After you successfully manage to get PyPy's source you can read more about:
- `Building and using PyPy's Python interpreter`_
- - `Learning more about the translation toolchain and how to develop (with) PyPy`_
+ - `Learning more about the RPython toolchain and how to develop (with) PyPy`_
+ - `Tutorial for how to write an interpreter with the RPython toolchain and make it fast`_
+ - `Look at our benchmark results`_
.. _`Building and using PyPy's Python interpreter`: getting-started-python.html
-.. _`Learning more about the translation toolchain and how to develop (with) PyPy`: getting-started-dev.html
+.. _`Learning more about the RPython toolchain and how to develop (with) PyPy`: getting-started-dev.html
+.. _`Tutorial for how to write an interpreter with the RPython toolchain and make it fast`: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
+.. _`Look at our benchmark results`: http://speed.pypy.org
+.. _setuptools: http://pypi.python.org/pypi/setuptools
Understanding PyPy's architecture
---------------------------------
@@ -106,7 +164,7 @@
interesting information. Additionally, in true hacker spirit, you
may just `start reading sources`_ .
-.. _`documentation section`: docindex.html
+.. _`documentation section`: index.html#project-documentation
.. _`start reading sources`: getting-started-dev.html#start-reading-sources
Filing bugs or feature requests
@@ -121,4 +179,4 @@
.. _bug reports: https://codespeak.net/issue/pypy-dev/
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.cli.rst b/pypy/doc/config/translation.cli.txt
copy from pypy/doc/config/translation.cli.rst
copy to pypy/doc/config/translation.cli.txt
diff --git a/pypy/doc/config/translation.backendopt.none.rst b/pypy/doc/config/translation.backendopt.none.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.none.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Do not run any backend optimizations.
diff --git a/pypy/doc/config/objspace.std.optimized_comparison_op.rst b/pypy/doc/config/objspace.std.optimized_comparison_op.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.optimized_comparison_op.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Optimize the comparison of two integers a bit.
diff --git a/pypy/doc/image/parsing_example5.dot b/pypy/doc/image/parsing_example5.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example5.dot
+++ /dev/null
@@ -1,21 +0,0 @@
-digraph G{
-"-1219949908" [label="n"];
-"-1219949908" -> "-1214026452";
-"-1214026452" [shape=box,label="__0_a\n'a'"];
-"-1219949908" -> "-1214028276";
-"-1214028276" [shape=box,label="__1_b\n'b'"];
-"-1219949908" -> "-1214027316";
-"-1214027316" [shape=box,label="__2_c\n'c'"];
-"-1219949908" -> "-1219949876";
-"-1219949876" [label="n"];
-"-1219949876" -> "-1214141364";
-"-1214141364" [shape=box,label="__0_a\n'a'"];
-"-1219949876" -> "-1214141748";
-"-1214141748" [shape=box,label="__1_b\n'b'"];
-"-1219949876" -> "-1214140756";
-"-1214140756" [shape=box,label="__2_c\n'c'"];
-"-1219949876" -> "-1219949748";
-"-1219949748" [label="m"];
-"-1219949748" -> "-1214414868";
-"-1214414868" [shape=box,label="__5_d\n'd'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/config/objspace.usemodules._testing.rst b/pypy/doc/config/objspace.usemodules._testing.txt
copy from pypy/doc/config/objspace.usemodules._testing.rst
copy to pypy/doc/config/objspace.usemodules._testing.txt
diff --git a/pypy/doc/rlib.rst b/pypy/doc/rlib.rst
--- a/pypy/doc/rlib.rst
+++ b/pypy/doc/rlib.rst
@@ -14,13 +14,11 @@
to change at some point. Usually it is useful to look at the tests in
`pypy/rlib/test`_ to get an impression of how to use a module.
-.. _`pypy/rlib`: ../../../../pypy/rlib
-.. _`pypy/rlib/test`: ../../../../pypy/rlib/test
``listsort``
============
-The listsort_ module contains an implementation of the timsort sorting algorithm
+The `pypy/rlib/listsort.py`_ module contains an implementation of the timsort sorting algorithm
(the sort method of lists is not RPython). To use it, subclass from the
``listsort.TimSort`` class and override the ``lt`` method to change the
comparison behaviour. The constructor of ``TimSort`` takes a list as an
@@ -29,19 +27,16 @@
be sorted using the ``listsort`` module in one program, otherwise the annotator
will be confused.
-.. _listsort: ../../../../pypy/rlib/listsort.py
-
``nonconst``
============
-The nonconst_ module is useful mostly for tests. The `flow object space`_ and
+The `pypy/rlib/nonconst.py`_ module is useful mostly for tests. The `flow object space`_ and
the `annotator`_ do quite some constant folding, which is sometimes not desired
in a test. To prevent constant folding on a certain value, use the ``NonConst``
class. The constructor of ``NonConst`` takes an arbitrary value. The instance of
``NonConst`` will behave during annotation like that value, but no constant
folding will happen.
-.. _nonconst: ../../../../pypy/rlib/nonconst.py
.. _`flow object space`: objspace.html#the-flow-object-space
.. _`annotator`: translation.html#the-annotation-pass
@@ -49,7 +44,7 @@
``objectmodel``
===============
-The objectmodel_ module is a mixed bag of various functionality. Some of the
+The `pypy/rlib/objectmodel.py`_ module is a mixed bag of various functionality. Some of the
more useful ones are:
``ComputedIntSymbolic``:
@@ -95,24 +90,21 @@
won't be allocated but represented by *tagged pointers**, that is pointers
that have the lowest bit set.
-.. _objectmodel: ../../../../pypy/rlib/objectmodel.py
-
``rarithmetic``
===============
-The rarithmetic_ module contains functionality to handle the small differences
+The `pypy/rlib/rarithmetic.py`_ module contains functionality to handle the small differences
in the behaviour of arithmetic code in regular Python and RPython code. Most of
them are already described in the `coding guide`_
-.. _rarithmetic: ../../../../pypy/rlib/rarithmetic.py
.. _`coding guide`: coding-guide.html
``rbigint``
===========
-The rbigint module contains a full RPython implementation of the Python ``long``
+The `pypy/rlib/rbigint.py`_ module contains a full RPython implementation of the Python ``long``
type (which itself is not supported in RPython). The ``rbigint`` class contains
that implementation. To construct ``rbigint`` instances use the static methods
``fromint``, ``frombool``, ``fromfloat`` and ``fromdecimalstr``. To convert back
@@ -122,36 +114,30 @@
these underscores left out for better readability (so ``a.add(b)`` can be used
to add two rbigint instances).
-.. _rbigint: ../../../../pypy/rlib/rbigint.py
-
``rrandom``
===========
-The rrandom_ module contains an implementation of the mersenne twister random
+The `pypy/rlib/rrandom.py`_ module contains an implementation of the mersenne twister random
number generator. It contains one class ``Random`` which most importantly has a
``random`` method which returns a pseudo-random floating point number between
0.0 and 1.0.
-.. _rrandom: ../../../../pypy/rlib/rrandom.py
-
``rsocket``
===========
-The rsocket_ module contains an RPython implementation of the functionality of
+The `pypy/rlib/rsocket.py`_ module contains an RPython implementation of the functionality of
the socket standard library with a slightly different interface. The
difficulty with the Python socket API is that addresses are not "well-typed"
objects: depending on the address family they are tuples, or strings, and
so on, which is not suitable for RPython. Instead, ``rsocket`` contains
a hierarchy of Address classes, in a typical static-OO-programming style.
-.. _rsocket: ../../../../pypy/rlib/rsocket.py
-
``rstack``
==========
-The rstack_ module allows an RPython program to control its own execution stack.
+The `pypy/rlib/rstack.py`_ module allows an RPython program to control its own execution stack.
This is only useful if the program is translated using stackless. An old
description of the exposed functions is below.
@@ -210,32 +196,28 @@
f()
-.. _rstack: ../../../../pypy/rlib/rstack.py
-
``streamio``
============
-The streamio_ contains an RPython stream I/O implementation (which was started
+The `pypy/rlib/streamio.py`_ contains an RPython stream I/O implementation (which was started
by Guido van Rossum as `sio.py`_ in the CPython sandbox as a prototype for the
upcoming new file implementation in Python 3000).
-.. _streamio: ../../../../pypy/rlib/streamio.py
.. _`sio.py`: http://svn.python.org/view/sandbox/trunk/sio/sio.py
``unroll``
==========
-The unroll_ module most importantly contains the function ``unrolling_iterable``
+The `pypy/rlib/unroll.py`_ module most importantly contains the function ``unrolling_iterable``
which wraps an iterator. Looping over the iterator in RPython code will not
produce a loop in the resulting flow graph but will unroll the loop instead.
-.. _unroll: ../../../../pypy/rlib/unroll.py
``parsing``
===========
-The parsing_ module is a still in-development module to generate tokenizers and
+The `pypy/rlib/parsing/`_ module is a still in-development module to generate tokenizers and
parsers in RPython. It is still highly experimental and only really used by the
`Prolog interpreter`_ (although in slightly non-standard ways). The easiest way
to specify a tokenizer/grammar is to write it down using regular expressions and
@@ -289,7 +271,7 @@
returns a object with a ``recognize(input)`` method that returns True or False
depending on whether ``input`` matches the string or not.
-.. _`re`: http://docs.python.org/lib/module-re.html
+.. _`re`: http://docs.python.org/library/re.html
EBNF
----
@@ -341,14 +323,42 @@
produces a syntax tree that follows the precedence of the operators. For example
the expression ``12 + 4 * 5`` is parsed into the following tree:
-.. graphviz:: image/parsing_example1.dot
+.. graphviz::
+
+ digraph G{
+ "-1213931828" [label="additive"];
+ "-1213931828" -> "-1213951956";
+ "-1213951956" [label="multitive"];
+ "-1213951956" -> "-1213949172";
+ "-1213949172" [label="primary"];
+ "-1213949172" -> "-1213949812";
+ "-1213949812" [shape=box,label="DECIMAL\l'12'"];
+ "-1213931828" -> "-1213935220";
+ "-1213935220" [shape=box,label="__0_+\l'+'"];
+ "-1213931828" -> "-1213951316";
+ "-1213951316" [label="additive"];
+ "-1213951316" -> "-1213948180";
+ "-1213948180" [label="multitive"];
+ "-1213948180" -> "-1213951380";
+ "-1213951380" [label="primary"];
+ "-1213951380" -> "-1213951508";
+ "-1213951508" [shape=box,label="DECIMAL\l'4'"];
+ "-1213948180" -> "-1213948788";
+ "-1213948788" [shape=box,label="__1_*\l'*'"];
+ "-1213948180" -> "-1213951060";
+ "-1213951060" [label="multitive"];
+ "-1213951060" -> "-1213948980";
+ "-1213948980" [label="primary"];
+ "-1213948980" -> "-1213950420";
+ "-1213950420" [shape=box,label="DECIMAL\l'5'"];
+ }
Parse Trees
-----------
The parsing process builds up a tree consisting of instances of ``Symbol`` and
``Nonterminal``, the former corresponding to tokens, the latter to nonterminal
-symbols. Both classes live in the `pypy.rlib.parsing.tree`_ module. You can use
+symbols. Both classes live in the `pypy/rlib/parsing/tree.py`_ module. You can use
the ``view()`` method ``Nonterminal`` instances to get a pygame view of the
parse tree.
@@ -359,13 +369,11 @@
of the nonterminal and ``children`` which is a list of the children attributes.
-.. _`pypy.rlib.parsing.tree`: ../../../../pypy/rlib/parsing/tree.py
-
Visitors
++++++++
To write tree visitors for the parse trees that are RPython, there is a special
-baseclass ``RPythonVisitor`` in ``pypy.rlib.parsing.tree``_ to use. If your
+baseclass ``RPythonVisitor`` in `pypy/rlib/parsing/tree.py`_ to use. If your
class uses this, it will grow a ``dispatch(node)`` method, that calls an
appropriate ``visit_<symbol>`` method, depending on the ``node`` argument. Here
the <symbol> is replaced by the ``symbol`` attribute of the visited node.
@@ -400,11 +408,43 @@
Parsing the string "A, A, A" gives the tree:
-.. graphviz:: image/parsing_example2.dot
+.. graphviz::
+
+ digraph G{
+ "-1213678004" [label="n"];
+ "-1213678004" -> "-1213681108";
+ "-1213681108" [shape=box,label="__0_A\n'A'"];
+ "-1213678004" -> "-1213681332";
+ "-1213681332" [shape=box,label="__1_,\n','"];
+ "-1213678004" -> "-1213837780";
+ "-1213837780" [label="n"];
+ "-1213837780" -> "-1213837716";
+ "-1213837716" [shape=box,label="__0_A\n'A'"];
+ "-1213837780" -> "-1213839476";
+ "-1213839476" [shape=box,label="__1_,\n','"];
+ "-1213837780" -> "-1213839956";
+ "-1213839956" [label="n"];
+ "-1213839956" -> "-1213840948";
+ "-1213840948" [shape=box,label="__0_A\n'A'"];
+ }
After transformation the tree has the "," nodes removed:
-.. graphviz:: image/parsing_example3.dot
+.. graphviz::
+
+ digraph G{
+ "-1219325716" [label="n"];
+ "-1219325716" -> "-1219325844";
+ "-1219325844" [shape=box,label="__0_A\n'A'"];
+ "-1219325716" -> "-1219324372";
+ "-1219324372" [label="n"];
+ "-1219324372" -> "-1219325524";
+ "-1219325524" [shape=box,label="__0_A\n'A'"];
+ "-1219324372" -> "-1219324308";
+ "-1219324308" [label="n"];
+ "-1219324308" -> "-1219325492";
+ "-1219325492" [shape=box,label="__0_A\n'A'"];
+ }
<symbol>
++++++++
@@ -421,12 +461,61 @@
Parsing the string "a b c (a b c d)" gives the tree:
-.. graphviz:: image/parsing_example4.dot
+.. graphviz::
+
+ digraph G{
+ "-1214029460" [label="n"];
+ "-1214029460" -> "-1214026452";
+ "-1214026452" [shape=box,label="__0_a\n'a'"];
+ "-1214029460" -> "-1214028276";
+ "-1214028276" [shape=box,label="__1_b\n'b'"];
+ "-1214029460" -> "-1214027316";
+ "-1214027316" [shape=box,label="__2_c\n'c'"];
+ "-1214029460" -> "-1214026868";
+ "-1214026868" [label="m"];
+ "-1214026868" -> "-1214140436";
+ "-1214140436" [shape=box,label="__3_(\n'('"];
+ "-1214026868" -> "-1214143508";
+ "-1214143508" [label="n"];
+ "-1214143508" -> "-1214141364";
+ "-1214141364" [shape=box,label="__0_a\n'a'"];
+ "-1214143508" -> "-1214141748";
+ "-1214141748" [shape=box,label="__1_b\n'b'"];
+ "-1214143508" -> "-1214140756";
+ "-1214140756" [shape=box,label="__2_c\n'c'"];
+ "-1214143508" -> "-1214144468";
+ "-1214144468" [label="m"];
+ "-1214144468" -> "-1214414868";
+ "-1214414868" [shape=box,label="__5_d\n'd'"];
+ "-1214026868" -> "-1214141492";
+ "-1214141492" [shape=box,label="__4_)\n')'"];
+ }
After transformation the tree looks like this:
-.. graphviz:: image/parsing_example5.dot
+.. graphviz::
+ digraph G{
+ "-1219949908" [label="n"];
+ "-1219949908" -> "-1214026452";
+ "-1214026452" [shape=box,label="__0_a\n'a'"];
+ "-1219949908" -> "-1214028276";
+ "-1214028276" [shape=box,label="__1_b\n'b'"];
+ "-1219949908" -> "-1214027316";
+ "-1214027316" [shape=box,label="__2_c\n'c'"];
+ "-1219949908" -> "-1219949876";
+ "-1219949876" [label="n"];
+ "-1219949876" -> "-1214141364";
+ "-1214141364" [shape=box,label="__0_a\n'a'"];
+ "-1219949876" -> "-1214141748";
+ "-1214141748" [shape=box,label="__1_b\n'b'"];
+ "-1219949876" -> "-1214140756";
+ "-1214140756" [shape=box,label="__2_c\n'c'"];
+ "-1219949876" -> "-1219949748";
+ "-1219949748" [label="m"];
+ "-1219949748" -> "-1214414868";
+ "-1214414868" [shape=box,label="__5_d\n'd'"];
+ }
>nonterminal_1 nonterminal_2 ... nonterminal_n<
+++++++++++++++++++++++++++++++++++++++++++++++
@@ -441,23 +530,76 @@
Parsing the string "1 2" gives the tree:
-.. graphviz:: image/parsing_example6.dot
-
+.. graphviz::
+
+ digraph G{
+ "-1213518708" [label="list"];
+ "-1213518708" -> "-1213518196";
+ "-1213518196" [shape=box,label="DECIMAL\n'1'"];
+ "-1213518708" -> "-1213518260";
+ "-1213518260" [label="list"];
+ "-1213518260" -> "-1213520308";
+ "-1213520308" [shape=box,label="DECIMAL\n'2'"];
+ }
+
after the transformation the tree looks like:
-.. graphviz:: image/parsing_example7.dot
+.. graphviz::
+
+ digraph G{
+ "-1219505652" [label="list"];
+ "-1219505652" -> "-1213518196";
+ "-1213518196" [shape=box,label="DECIMAL\n'1'"];
+ "-1219505652" -> "-1213520308";
+ "-1213520308" [shape=box,label="DECIMAL\n'2'"];
+ }
Note that the transformation works recursively. That means that the following
also works: if the string "1 2 3 4 5" is parsed the tree at first looks like
this:
-.. graphviz:: image/parsing_example8.dot
+.. graphviz::
+
+ digraph G{
+ "-1213611892" [label="list"];
+ "-1213611892" -> "-1213608980";
+ "-1213608980" [shape=box,label="DECIMAL\n'1'"];
+ "-1213611892" -> "-1213623476";
+ "-1213623476" [label="list"];
+ "-1213623476" -> "-1213623380";
+ "-1213623380" [shape=box,label="DECIMAL\n'2'"];
+ "-1213623476" -> "-1213442868";
+ "-1213442868" [label="list"];
+ "-1213442868" -> "-1213441652";
+ "-1213441652" [shape=box,label="DECIMAL\n'3'"];
+ "-1213442868" -> "-1213441332";
+ "-1213441332" [label="list"];
+ "-1213441332" -> "-1213441620";
+ "-1213441620" [shape=box,label="DECIMAL\n'4'"];
+ "-1213441332" -> "-1213443060";
+ "-1213443060" [label="list"];
+ "-1213443060" -> "-1213442100";
+ "-1213442100" [shape=box,label="DECIMAL\n'5'"];
+ }
But after transformation the whole thing collapses to one node with a lot of
children:
-.. graphviz:: image/parsing_example9.dot
+.. graphviz::
+ digraph G{
+ "-1219430228" [label="list"];
+ "-1219430228" -> "-1213608980";
+ "-1213608980" [shape=box,label="DECIMAL\n'1'"];
+ "-1219430228" -> "-1213623380";
+ "-1213623380" [shape=box,label="DECIMAL\n'2'"];
+ "-1219430228" -> "-1213441652";
+ "-1213441652" [shape=box,label="DECIMAL\n'3'"];
+ "-1219430228" -> "-1213441620";
+ "-1213441620" [shape=box,label="DECIMAL\n'4'"];
+ "-1219430228" -> "-1213442100";
+ "-1213442100" [shape=box,label="DECIMAL\n'5'"];
+ }
Extensions to the EBNF grammar format
-------------------------------------
@@ -526,10 +668,48 @@
looks like this:
-.. graphviz:: image/parsing_example10.dot
+.. graphviz::
+ digraph G{
+ "-1220061652" [label="object"];
+ "-1220061652" -> "-1220127636";
+ "-1220127636" [label="entry"];
+ "-1220127636" -> "-1213915636";
+ "-1213915636" [shape=box,label="STRING\n'a'"];
+ "-1220127636" -> "-1214251156";
+ "-1214251156" [shape=box,label="STRING\n'5'"];
+ "-1220061652" -> "-1220063188";
+ "-1220063188" [label="entry"];
+ "-1220063188" -> "-1214253076";
+ "-1214253076" [shape=box,label="STRING\n'b'"];
+ "-1220063188" -> "-1220059444";
+ "-1220059444" [label="array"];
+ "-1220059444" -> "-1214253364";
+ "-1214253364" [shape=box,label="NUMBER\n'1'"];
+ "-1220059444" -> "-1214254292";
+ "-1214254292" [shape=box,label="__0_null\n'null'"];
+ "-1220059444" -> "-1214253268";
+ "-1214253268" [shape=box,label="NUMBER\n'3'"];
+ "-1220059444" -> "-1214252596";
+ "-1214252596" [shape=box,label="__1_true\n'true'"];
+ "-1220059444" -> "-1220062260";
+ "-1220062260" [label="object"];
+ "-1220062260" -> "-1220060116";
+ "-1220060116" [label="entry"];
+ "-1220060116" -> "-1214211860";
+ "-1214211860" [shape=box,label="STRING\n'f'"];
+ "-1220060116" -> "-1214210132";
+ "-1214210132" [shape=box,label="STRING\n'g'"];
+ "-1220062260" -> "-1220062868";
+ "-1220062868" [label="entry"];
+ "-1220062868" -> "-1214211956";
+ "-1214211956" [shape=box,label="STRING\n'h'"];
+ "-1220062868" -> "-1214212308";
+ "-1214212308" [shape=box,label="NUMBER\n'6'"];
+ }
-.. _`Prolog interpreter`: http://codespeak.net/svn/pypy/lang/prolog/
-.. _parsing: ../../../../pypy/rlib/parsing/
+.. _`Prolog interpreter`: https://bitbucket.org/cfbolz/pyrolog/
.. _`json format`: http://www.json.org
+
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline.rst b/pypy/doc/config/translation.backendopt.profile_based_inline.txt
copy from pypy/doc/config/translation.backendopt.profile_based_inline.rst
copy to pypy/doc/config/translation.backendopt.profile_based_inline.txt
diff --git a/pypy/doc/coding-guide.rst b/pypy/doc/coding-guide.rst
--- a/pypy/doc/coding-guide.rst
+++ b/pypy/doc/coding-guide.rst
@@ -1,11 +1,9 @@
-=====================================
+====================================
Coding Guide
-=====================================
+====================================
.. contents::
-
-
This document describes coding requirements and conventions for
working with the PyPy code base. Please read it carefully and
ask back any questions you might have. The document does not talk
@@ -133,7 +131,7 @@
whether a particular function is implemented at application or
interpreter level.
-our runtime interpreter is "restricted python"
+Our runtime interpreter is "RPython"
----------------------------------------------
In order to make a C code generator feasible all code on interpreter level has
@@ -148,7 +146,7 @@
implementation must behave in a static way often referenced as
"RPythonic".
-.. _Starkiller: http://www.python.org/pycon/dc2004/papers/1/paper.pdf
+.. _Starkiller: http://people.csail.mit.edu/jrb/Projects/starkiller.pdf
.. _ShedSkin: http://shed-skin.blogspot.com/
However, when the PyPy interpreter is started as a Python program, it
@@ -174,7 +172,7 @@
enables the code generator to emit efficient machine level replacements
for pure integer objects, for instance.
-Restricted Python
+RPython
=================
RPython Definition, not
@@ -342,9 +340,8 @@
-------------------------
While implementing the integer type, we stumbled over the problem that
-integers are quite in flux in CPython right now. Starting on Python 2.2,
-integers mutate into longs on overflow. However, shifting to the left
-truncates up to 2.3 but extends to longs as well in 2.4. By contrast, we need
+integers are quite in flux in CPython right now. Starting with Python 2.4,
+integers mutate into longs on overflow. In contrast, we need
a way to perform wrap-around machine-sized arithmetic by default, while still
being able to check for overflow when we need it explicitly. Moreover, we need
a consistent behavior before and after translation.
@@ -354,9 +351,6 @@
silent wrap-around. Whenever we need more control, we use the following
helpers (which live the `pypy/rlib/rarithmetic.py`_):
-.. _`pypy/rlib/rarithmetic.py`: ../../../../pypy/rlib/rarithmetic.py
-
-
**ovfcheck()**
This special function should only be used with a single arithmetic operation
@@ -368,15 +362,6 @@
ovfcheck() as a hint: they replace the whole ``ovfcheck(x+y)`` expression
with a single overflow-checking addition in C.
-**ovfcheck_lshift()**
-
- ovfcheck_lshift(x, y) is a workaround for ovfcheck(x<<y), because the
- latter doesn't quite work in Python prior to 2.4, where the expression
- ``x<<y`` will never return a long if the input arguments are ints. There is
- a specific function ovfcheck_lshift() to use instead of some convoluted
- expression like ``x*2**y`` so that code generators can still recognize it as
- a single simple operation.
-
**intmask()**
This function is used for wrap-around arithmetic. It returns the lower bits
@@ -459,43 +444,6 @@
.. _`wrapped`:
-RPylint
--------
-
-Pylint_ is a static code checker for Python. Recent versions
-(>=0.13.0) can be run with the ``--rpython-mode`` command line option. This option
-enables the RPython checker which will checks for some of the
-restrictions RPython adds on standard Python code (and uses a
-more aggressive type inference than the one used by default by
-pylint). The full list of checks is available in the documentation of
-Pylint.
-
-RPylint can be a nice tool to get some information about how much work
-will be needed to convert a piece of Python code to RPython, or to get
-started with RPython. While this tool will not guarantee that the
-code it checks will be translate successfully, it offers a few nice
-advantages over running a translation:
-
-* it is faster and therefore provides feedback faster than ``translate.py``
-
-* it does not stop at the first problem it finds, so you can get more
- feedback on the code in one run
-
-* the messages tend to be a bit less cryptic
-
-* you can easily run it from emacs, vi, eclipse or visual studio.
-
-Note: if pylint is not prepackaged for your OS/distribution, or if
-only an older version is available, you will need to install from
-source. In that case, there are a couple of dependencies,
-logilab-common_ and astng_ that you will need to install too before
-you can use the tool.
-
-.. _Pylint: http://www.logilab.org/projects/pylint
-.. _logilab-common: http://www.logilab.org/projects/common
-.. _astng: http://www.logilab.org/projects/astng
-
-
Wrapping rules
==============
@@ -626,7 +574,7 @@
Modules visible from application programs are imported from
interpreter or application level files. PyPy reuses almost all python
-modules of CPython's standard library, currently from version 2.5.2. We
+modules of CPython's standard library, currently from version 2.7.1. We
sometimes need to `modify modules`_ and - more often - regression tests
because they rely on implementation details of CPython.
@@ -649,21 +597,19 @@
>>>> import sys
>>>> sys.__file__
- '/home/hpk/pypy-dist/pypy/module/sys/*.py'
+ '/home/hpk/pypy-dist/pypy/module/sys'
- >>>> import operator
- >>>> operator.__file__
- '/home/hpk/pypy-dist/lib_pypy/operator.py'
+ >>>> import cPickle
+ >>>> cPickle.__file__
+ '/home/hpk/pypy-dist/lib_pypy/cPickle..py'
>>>> import opcode
>>>> opcode.__file__
- '/home/hpk/pypy-dist/lib-python/modified-2.5.2/opcode.py'
+ '/home/hpk/pypy-dist/lib-python/modified-2.7/opcode.py'
>>>> import os
- faking <type 'posix.stat_result'>
- faking <type 'posix.statvfs_result'>
>>>> os.__file__
- '/home/hpk/pypy-dist/lib-python/2.5.2/os.py'
+ '/home/hpk/pypy-dist/lib-python/2.7/os.py'
>>>>
Module directories / Import order
@@ -686,11 +632,11 @@
contains pure Python reimplementation of modules.
-*lib-python/modified-2.5.2/*
+*lib-python/modified-2.7/*
The files and tests that we have modified from the CPython library.
-*lib-python/2.5.2/*
+*lib-python/2.7/*
The unmodified CPython library. **Never ever check anything in there**.
@@ -705,14 +651,14 @@
by default and CPython has a number of places where it relies
on some classes being old-style.
-If you want to change a module or test contained in ``lib-python/2.5.2``
-then make sure that you copy the file to our ``lib-python/modified-2.5.2``
-directory first. In subversion commandline terms this reads::
+If you want to change a module or test contained in ``lib-python/2.7``
+then make sure that you copy the file to our ``lib-python/modified-2.7``
+directory first. In mercurial commandline terms this reads::
- svn cp lib-python/2.5.2/somemodule.py lib-python/modified-2.5.2/
+ $ hg cp lib-python/2.7/somemodule.py lib-python/modified-2.7/
and subsequently you edit and commit
-``lib-python/modified-2.5.2/somemodule.py``. This copying operation is
+``lib-python/modified-2.7/somemodule.py``. This copying operation is
important because it keeps the original CPython tree clean and makes it
obvious what we had to change.
@@ -860,29 +806,23 @@
- write good log messages because several people
are reading the diffs.
-- if you add (text/py) files to the repository then please run
- pypy/tool/fixeol in that directory. This will make sure
- that the property 'svn:eol-style' is set to native which
- allows checkin/checkout in native line-ending format.
+- What was previously called ``trunk`` is called the ``default`` branch in
+ mercurial. Branches in mercurial are always pushed together with the rest
+ of the repository. To create a ``try1`` branch (assuming that a branch named
+ ``try1`` doesn't already exists) you should do::
-- branching (aka "svn copy") of source code should usually
- happen at ``svn/pypy/trunk`` level in order to have a full
- self-contained pypy checkout for each branch. For branching
- a ``try1`` branch you would for example do::
+ hg branch try1
+
+ The branch will be recorded in the repository only after a commit. To switch
+ back to the default branch::
+
+ hg update default
+
+ For further details use the help or refer to the `official wiki`_::
+
+ hg help branch
- svn cp http://codespeak.net/svn/pypy/trunk \
- http://codespeak.net/svn/pypy/branch/try1
-
- This allows to checkout the ``try1`` branch and receive a
- self-contained working-copy for the branch. Note that
- branching/copying is a cheap operation with subversion, as it
- takes constant time irrespective of the size of the tree.
-
-- To learn more about how to use subversion read `this document`_.
-
-.. _`this document`: svn-help.html
-
-
+.. _`official wiki`: http://mercurial.selenic.com/wiki/Branch
.. _`using development tracker`:
@@ -895,41 +835,17 @@
for the next milestone, both from an E-Mail and from a
web interface.
+.. _`development tracker`: https://codespeak.net/issue/pypy-dev/
+
use your codespeak login or register
------------------------------------
-If you already committed to the PyPy source code, chances
-are that you can simply use your codespeak login that
-you use for subversion or for shell access.
+If you have an existing codespeak account, you can use it to login within the
+tracker. Else, you can `register with the tracker`_ easily.
-If you are not a commiter then you can still `register with
-the tracker`_ easily.
-
-modifying Issues from svn commit messages
------------------------------------------
-
-If you are committing something related to
-an issue in the development tracker you
-can correlate your login message to a tracker
-item by following these rules:
-
-- put the content of ``issueN STATUS`` on a single
- new line
-
-- `N` must be an existing issue number from the `development tracker`_.
-
-- STATUS is one of::
-
- unread
- chatting
- in-progress
- testing
- duplicate
- resolved
.. _`register with the tracker`: https://codespeak.net/issue/pypy-dev/user?@template=register
-.. _`development tracker`: http://codespeak.net/issue/pypy-dev/
-.. _`roundup`: http://roundup.sf.net
+.. _`roundup`: http://roundup.sourceforge.net/
.. _`testing in PyPy`:
@@ -938,7 +854,7 @@
Testing in PyPy
===============
-Our tests are based on the new `py.test`_ tool which lets you write
+Our tests are based on the `py.test`_ tool which lets you write
unittests without boilerplate. All tests of modules
in a directory usually reside in a subdirectory **test**. There are
basically two types of unit tests:
@@ -949,15 +865,9 @@
- **Application Level tests**. They run at application level which means
that they look like straight python code but they are interpreted by PyPy.
-Both types of tests need an `objectspace`_ they can run with (the interpreter
-dispatches operations on objects to an objectspace). If you run a test you
-can usually give the '-o' switch to select an object space. E.g. '-o thunk'
-will select the thunk object space. The default is the `Standard Object Space`_
-which aims to implement unmodified Python semantics.
-
.. _`standard object space`: objspace.html#standard-object-space
.. _`objectspace`: objspace.html
-.. _`py.test`: http://codespeak.net/py/current/doc/test.html
+.. _`py.test`: http://pytest.org/
Interpreter level tests
-----------------------
@@ -967,7 +877,7 @@
def test_something(space):
# use space ...
- class TestSomething:
+ class TestSomething(object):
def test_some(self):
# use 'self.space' here
@@ -988,7 +898,7 @@
def app_test_something():
# application level test code
- class AppTestSomething:
+ class AppTestSomething(object):
def test_this(self):
# application level test code
@@ -1004,11 +914,8 @@
attached to the class there and start with ``w_`` can be accessed
via self (but without the ``w_``) in the actual test method. An example::
- from pypy.objspace.std import StdObjSpace
-
- class AppTestErrno:
- def setup_class(cls):
- cls.space = StdObjSpace()
+ class AppTestErrno(object):
+ def setup_class(cls):
cls.w_d = cls.space.wrap({"a": 1, "b", 2})
def test_dict(self):
@@ -1025,7 +932,7 @@
python test_all.py file_or_directory
which is a synonym for the general `py.test`_ utility
-located in the ``pypy`` directory. For switches to
+located in the ``py/bin/`` directory. For switches to
modify test execution pass the ``-h`` option.
Test conventions
@@ -1036,13 +943,9 @@
actually can fail.)
- All over the pypy source code there are test/ directories
- which contain unittests. Such scripts can usually be executed
+ which contain unit tests. Such scripts can usually be executed
directly or are collectively run by pypy/test_all.py
-- each test directory needs a copy of pypy/tool/autopath.py which
- upon import will make sure that sys.path contains the directory
- where 'pypy' is in.
-
.. _`change documentation and website`:
Changing documentation and website
@@ -1056,11 +959,10 @@
files. Here is a `ReST quickstart`_ but you can also just look
at the existing documentation and see how things work.
-.. _`ReST quickstart`: http://docutils.sourceforge.net/docs/rst/quickref.html
+.. _`ReST quickstart`: http://docutils.sourceforge.net/docs/user/rst/quickref.html
Note that the web site of http://pypy.org/ is maintained separately.
-For now it is in the repository https://bitbucket.org/pypy/extradoc
-in the directory ``pypy.org``.
+For now it is in the repository https://bitbucket.org/pypy/pypy.org
Automatically test documentation/website changes
------------------------------------------------
@@ -1087,4 +989,4 @@
which will check that remote URLs are reachable.
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.geninterp.rst b/pypy/doc/config/objspace.geninterp.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.geninterp.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-This option enables `geninterp`_. This will usually make the PyPy interpreter
-significantly faster (but also a bit bigger).
-
-.. _`geninterp`: ../geninterp.html
diff --git a/pypy/doc/config/objspace.usemodules.zipimport.rst b/pypy/doc/config/objspace.usemodules.zipimport.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.zipimport.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-This module implements zipimport mechanism described
-in PEP 302. It's supposed to work and translate, so it's included
-by default
\ No newline at end of file
diff --git a/pypy/doc/config/objspace.opcodes.CALL_METHOD.rst b/pypy/doc/config/objspace.opcodes.CALL_METHOD.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.opcodes.CALL_METHOD.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-Enable a pair of bytecodes that speed up method calls.
-See ``pypy.interpreter.callmethod`` for a description.
-
-The goal is to avoid creating the bound method object in the common
-case. So far, this only works for calls with no keyword, no ``*arg``
-and no ``**arg`` but it would be easy to extend.
-
-For more information, see the section in `Standard Interpreter Optimizations`_.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#lookup-method-call-method
diff --git a/pypy/doc/config/objspace.usemodules.marshal.rst b/pypy/doc/config/objspace.usemodules.marshal.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.marshal.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'marshal' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/image/parsing_example10.dot b/pypy/doc/image/parsing_example10.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example10.dot
+++ /dev/null
@@ -1,37 +0,0 @@
-digraph G{
-"-1220061652" [label="object"];
-"-1220061652" -> "-1220127636";
-"-1220127636" [label="entry"];
-"-1220127636" -> "-1213915636";
-"-1213915636" [shape=box,label="STRING\n'a'"];
-"-1220127636" -> "-1214251156";
-"-1214251156" [shape=box,label="STRING\n'5'"];
-"-1220061652" -> "-1220063188";
-"-1220063188" [label="entry"];
-"-1220063188" -> "-1214253076";
-"-1214253076" [shape=box,label="STRING\n'b'"];
-"-1220063188" -> "-1220059444";
-"-1220059444" [label="array"];
-"-1220059444" -> "-1214253364";
-"-1214253364" [shape=box,label="NUMBER\n'1'"];
-"-1220059444" -> "-1214254292";
-"-1214254292" [shape=box,label="__0_null\n'null'"];
-"-1220059444" -> "-1214253268";
-"-1214253268" [shape=box,label="NUMBER\n'3'"];
-"-1220059444" -> "-1214252596";
-"-1214252596" [shape=box,label="__1_true\n'true'"];
-"-1220059444" -> "-1220062260";
-"-1220062260" [label="object"];
-"-1220062260" -> "-1220060116";
-"-1220060116" [label="entry"];
-"-1220060116" -> "-1214211860";
-"-1214211860" [shape=box,label="STRING\n'f'"];
-"-1220060116" -> "-1214210132";
-"-1214210132" [shape=box,label="STRING\n'g'"];
-"-1220062260" -> "-1220062868";
-"-1220062868" [label="entry"];
-"-1220062868" -> "-1214211956";
-"-1214211956" [shape=box,label="STRING\n'h'"];
-"-1220062868" -> "-1214212308";
-"-1214212308" [shape=box,label="NUMBER\n'6'"];
-}
diff --git a/pypy/doc/image/parsing_example2.dot b/pypy/doc/image/parsing_example2.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example2.dot
+++ /dev/null
@@ -1,17 +0,0 @@
-digraph G{
-"-1213678004" [label="n"];
-"-1213678004" -> "-1213681108";
-"-1213681108" [shape=box,label="__0_A\n'A'"];
-"-1213678004" -> "-1213681332";
-"-1213681332" [shape=box,label="__1_,\n','"];
-"-1213678004" -> "-1213837780";
-"-1213837780" [label="n"];
-"-1213837780" -> "-1213837716";
-"-1213837716" [shape=box,label="__0_A\n'A'"];
-"-1213837780" -> "-1213839476";
-"-1213839476" [shape=box,label="__1_,\n','"];
-"-1213837780" -> "-1213839956";
-"-1213839956" [label="n"];
-"-1213839956" -> "-1213840948";
-"-1213840948" [shape=box,label="__0_A\n'A'"];
-}
diff --git a/pypy/doc/config/objspace.usemodules._codecs.rst b/pypy/doc/config/objspace.usemodules._codecs.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._codecs.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_codecs' module.
-Used by the 'codecs' standard lib module. This module is expected to be working and is included by default.
diff --git a/pypy/doc/externaltools.rst b/pypy/doc/externaltools.rst
deleted file mode 100644
--- a/pypy/doc/externaltools.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-.. include:: crufty.rst
-
- .. ^^ Incomplete and wrong, superceded elsewhere
-
-External tools&programs needed by PyPy
-======================================
-
-Tools needed for testing
-------------------------
-
-These tools are used in various ways by PyPy tests; if they are not found,
-some tests might be skipped, so they need to be installed on every buildbot
-slave to be sure we actually run all tests:
-
- - Mono (versions 1.2.1.1 and 1.9.1 known to work)
-
- - Java/JVM (preferably sun-jdk; version 1.6.0 known to work)
-
- - Jasmin >= 2.2 (copy it from wyvern, /usr/local/bin/jasmin and /usr/local/share/jasmin.jar)
-
- - gcc
-
- - make
-
- - Some libraries (these are Debian package names, adapt as needed):
-
- * ``python-dev``
- * ``python-ctypes``
- * ``libffi-dev``
- * ``libz-dev`` (for the optional ``zlib`` module)
- * ``libbz2-dev`` (for the optional ``bz2`` module)
- * ``libncurses-dev`` (for the optional ``_minimal_curses`` module)
- * ``libgc-dev`` (only when translating with `--opt=0, 1` or `size`)
diff --git a/pypy/doc/extending.rst b/pypy/doc/extending.rst
--- a/pypy/doc/extending.rst
+++ b/pypy/doc/extending.rst
@@ -1,4 +1,4 @@
-
+===================================
Writing extension modules for pypy
===================================
diff --git a/pypy/doc/config/translation.backendopt.merge_if_blocks.rst b/pypy/doc/config/translation.backendopt.merge_if_blocks.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.merge_if_blocks.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-This optimization converts parts of flow graphs that result from
-chains of ifs and elifs like this into merged blocks.
-
-By default flow graphing this kind of code::
-
- if x == 0:
- f()
- elif x == 1:
- g()
- elif x == 4:
- h()
- else:
- j()
-
-will result in a chain of blocks with two exits, somewhat like this:
-
-.. image:: unmergedblocks.png
-
-(reflecting how Python would interpret this code). Running this
-optimization will transform the block structure to contain a single
-"choice block" with four exits:
-
-.. image:: mergedblocks.png
-
-This can then be turned into a switch by the C backend, allowing the C
-compiler to produce more efficient code.
diff --git a/pypy/doc/image/parsing_example4.dot b/pypy/doc/image/parsing_example4.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example4.dot
+++ /dev/null
@@ -1,27 +0,0 @@
-digraph G{
-"-1214029460" [label="n"];
-"-1214029460" -> "-1214026452";
-"-1214026452" [shape=box,label="__0_a\n'a'"];
-"-1214029460" -> "-1214028276";
-"-1214028276" [shape=box,label="__1_b\n'b'"];
-"-1214029460" -> "-1214027316";
-"-1214027316" [shape=box,label="__2_c\n'c'"];
-"-1214029460" -> "-1214026868";
-"-1214026868" [label="m"];
-"-1214026868" -> "-1214140436";
-"-1214140436" [shape=box,label="__3_(\n'('"];
-"-1214026868" -> "-1214143508";
-"-1214143508" [label="n"];
-"-1214143508" -> "-1214141364";
-"-1214141364" [shape=box,label="__0_a\n'a'"];
-"-1214143508" -> "-1214141748";
-"-1214141748" [shape=box,label="__1_b\n'b'"];
-"-1214143508" -> "-1214140756";
-"-1214140756" [shape=box,label="__2_c\n'c'"];
-"-1214143508" -> "-1214144468";
-"-1214144468" [label="m"];
-"-1214144468" -> "-1214414868";
-"-1214414868" [shape=box,label="__5_d\n'd'"];
-"-1214026868" -> "-1214141492";
-"-1214141492" [shape=box,label="__4_)\n')'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/buildtool.rst b/pypy/doc/buildtool.rst
deleted file mode 100644
--- a/pypy/doc/buildtool.rst
+++ /dev/null
@@ -1,251 +0,0 @@
-============
-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.
-
-If a client crashes during compilation, the build is restarted, or error
-information is sent to the logs and requesting client, depending on the type of
-error. As long as no compilation error occurs (read: on disconnects, system
-errors, etc.) compilation will be retried until a build is available.
-
-Once a build is available, the server will send an email to all clients waiting
-for the build (it could be that more than one person asked for some build at
-the same time!).
-
-Configuration
-=============
-
-There are several aspects to configuration on this system. Of course, for the
-meta server, build server and startcompile components there is configuration
-for the host and port to connect to, and there is some additional configuration
-for things like which mailhost to use (only applies to the server), but also
-there is configuration data passed around to determine what client is picked,
-and what the client needs to compile exactly.
-
-Config file
------------
-
-The host/port configuration etc. can be found in the file 'config.py' in the
-build tool dir. There are several things that can be configured here, mostly
-related to what application to build, and where to build it. Please read the
-file carefully when setting up a new build network, or when participating for
-compilation, because certain items (e.g. the svnpath_to_url function, or the
-client_checkers) can make the system a lot less secure when not configured
-properly.
-
-Note that all client-related configuration is done from command-line switches,
-so the configuration file is supposed to be changed on a per-project basis:
-unless you have specific needs, use a test version of the build tool, or are
-working on another project than PyPy, you will not want to modify the it.
-
-System configuration
---------------------
-
-This information is used by the client and startcompile components. On the
-participating clients this information is retrieved by querying the system, on
-the requesting clients the system values are used by default, but may be
-overridden (so a requesting client running an x86 can still request PPC builds,
-for instance). The clients compare their own system config to that of a build
-request, and will (should) refuse a build if it can not be executed because
-of incompatibilities.
-
-Compilation configuration
--------------------------
-
-The third form of configuration is that of the to-be-built application itself,
-its compilation arguments. This configuration is only provided by the
-requesting clients, build servers can examine the information and refuse a
-compilation based on this configuration (just like with the system config, see
-'client_checkers' in 'config.py'). Compilation configuration can be controlled
-using command-line arguments (use 'bin/startcompile.py --help' for an
-overview).
-
-Build tool options
-------------------
-
-Yet another part of the configuration are the options that are used by the
-startcompile.py script itself: the user can specify what SVN path (relative to
-a certain base path) and what Subversion revision is desired. The revision can
-either be specified exactly, or as a range of versions.
-
-Installation
-============
-
-Build Server
-------------
-
-Installing the system should not be required: just run './bin/buildserver' to
-start. Note that it depends on the `py lib`_ (as does the rest of PyPy).
-
-When starting a build server with PyPy's default configuration, it will connect
-to a meta server we have running in codespeak.net.
-
-Meta Server
------------
-
-Also for the server there's no real setup required, and again there's a
-dependency on the `py lib`_. Starting it is done by running
-'./bin/metaserver'.
-
-Running a compile job
----------------------
-
-Again installation is not required, just run './bin/startcompile.py [options]
-<email>' (see --help for the options) to start. Again, you need to have the
-`py lib`_ installed.
-
-Normally the codespeak.net meta server will be used when this script is issued.
-
-.. _`py lib`: http://codespeak.net/py
-
-Using the build tool for other projects
-=======================================
-
-The code for the build tool is meant to be generic. Using it for other projects
-than PyPy (for which it was originally written) is relatively straight-forward:
-just change the configuration, and implement a build client script (probably
-highly resembling bin/buildserver.py).
-
-Note that there is a test project in 'tool/build/testproject' that can serve
-as an example.
-
-Prerequisites
---------------
-
-Your project can use the build tool if:
-
- * it can be built from Python
-
- Of course this is a rather vague requirement: theoretically _anything_ can
- be built from Python; it's just a matter of integrating it into the tool
- properly... A project that can entirely be built from Python code (like
- PyPy) is easier to integrate than something that is built from the command
- line, though (although implementing that won't be very hard either, see
- the test project for instance).
-
- * it is located in Subversion
-
- The build tool makes very little hard-coded assumptions, but having code
- in Subversion is one of them. There are several locations in the code where
- SVN is assumed: the command line options (see `build tool options`_),
- the server (which checks SVN urls for validity, and converts HEAD revision
- requests to actual revision ids) and and build client (which checks out the
- data) all make this assumption, changing to a different revision control
- system is currently not easy and unsupported (but who knows what the future
- will bring).
-
- * it uses PyPy's config mechanism
-
- PyPy has a very nice, generic configuration mechanism (essentially wrapper
- OptionParser stuff) that makes dealing with fragmented configuration
- and command-line options a lot easier. This mechanism is used by the build
- tool: it assumes configuration is provided in this format. If your project
- uses this configuration mechanism already, you can provide the root Config
- object from config.compile_config; if not it should be fairly straight-
- forward to wrap your existing configuration with the PyPy stuff.
-
-Basically that's it: if your project is stored in SVN, and you don't mind using
-Python a bit, it shouldn't be too hard to get things going (note that more
-documentation about this subject will follow in the future).
-
-Web Front-End
-=============
-
-To examine the status of the meta server, connected build servers and build
-requests, there is a web server available. This can be started using
-'./bin/webserver' and uses port 8080 by default (override in
-config.py).
-
-The web server presents a number of different pages:
-
- * / and /metaserverstatus - meta server status
-
- this displays a small list of information about the meta server, such
- as the amount of connected build servers, the amount of builds available,
- the amount of waiting clients, etc.
-
- * /buildservers - connected build servers
-
- this page contains a list of all connected build servers, system
- information and what build they're currently working on (if any)
-
- * /builds - a list of builds
-
- here you'll find a list of all builds, both done and in-progress and
- queued ones, with links to the details pages, the date they were
- requested and their status
-
- * /build/<id> - build details
-
- the 'build' (virtual) directory contains pages of information for each
- build - each of those pages displays status information, time requested,
- time started and finished (if appropriate), links to the zip and logs,
- and system and compile information
-
-There's a build tool status web server for the meta server on codespeak.net
-available at http://codespeak.net/pypy/buildstatus/.
-
-More info
-=========
-
-For more information, bug reports, patches, etc., please send an email to
-guido at merlinux.de.
-
diff --git a/pypy/doc/jit/_ref.rst b/pypy/doc/jit/_ref.txt
copy from pypy/doc/jit/_ref.rst
copy to pypy/doc/jit/_ref.txt
diff --git a/pypy/doc/config/translation.backendopt.raisingop2direct_call.rst b/pypy/doc/config/translation.backendopt.raisingop2direct_call.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.raisingop2direct_call.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option. Transformation required by the LLVM backend.
-
-.. internal
diff --git a/pypy/doc/config/translation.log.rst b/pypy/doc/config/translation.log.txt
copy from pypy/doc/config/translation.log.rst
copy to pypy/doc/config/translation.log.txt
diff --git a/pypy/doc/jit/_ref.rst b/pypy/doc/jit/_ref.rst
deleted file mode 100644
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline_threshold.rst b/pypy/doc/config/translation.backendopt.profile_based_inline_threshold.txt
copy from pypy/doc/config/translation.backendopt.profile_based_inline_threshold.rst
copy to pypy/doc/config/translation.backendopt.profile_based_inline_threshold.txt
diff --git a/pypy/doc/image/parsing_example7.dot b/pypy/doc/image/parsing_example7.dot
deleted file mode 100644
--- a/pypy/doc/image/parsing_example7.dot
+++ /dev/null
@@ -1,7 +0,0 @@
-digraph G{
-"-1219505652" [label="list"];
-"-1219505652" -> "-1213518196";
-"-1213518196" [shape=box,label="DECIMAL\n'1'"];
-"-1219505652" -> "-1213520308";
-"-1213520308" [shape=box,label="DECIMAL\n'2'"];
-}
\ No newline at end of file
diff --git a/pypy/doc/translation-aspects.rst b/pypy/doc/translation-aspects.rst
deleted file mode 100644
--- a/pypy/doc/translation-aspects.rst
+++ /dev/null
@@ -1,482 +0,0 @@
-.. include:: crufty.rst
-.. ^^ old and needs updating
-
-==========================================================================================
-Memory management and threading models as translation aspects -- solutions and challenges
-==========================================================================================
-
-.. contents::
-
-
-Introduction
-=============
-
-One of the goals of the PyPy project is to have the memory and concurrency
-models flexible and changeable without having to reimplement the
-interpreter manually. In fact, PyPy, by the time of the 0.8 release contains code for memory
-management and concurrency models which allows experimentation without
-requiring early design decisions. This document describes many of the more
-technical details of the current state of the implementation of the memory
-object model, automatic memory management and concurrency models and describes
-possible future developments.
-
-
-The low level object model
-===========================
-
-One important part of the translation process is *rtyping* [DLT]_, [TR]_.
-Before that step all objects in our flow graphs are annotated with types at the
-level of the RPython type system which is still quite high-level and
-target-independent. During rtyping they are transformed into objects that
-match the model of the specific target platform. For C or C-like targets this
-model consists of a set of C-like types like structures, arrays and functions
-in addition to primitive types (integers, characters, floating point numbers).
-This multi-stage approach gives a lot of flexibility in how a given object is
-represented at the target's level. The RPython process can decide what
-representation to use based on the type annotation and on the way the object is
-used.
-
-In the following the structures used to represent RPython classes are described.
-There is one "vtable" per RPython class, with the following structure: The root
-class "object" has a vtable of the following type (expressed in a C-like
-syntax)::
-
- struct object_vtable {
- struct object_vtable* parenttypeptr;
- RuntimeTypeInfo * rtti;
- Signed subclassrange_min;
- Signed subclassrange_max;
- array { char } * name;
- struct object * instantiate();
- }
-
-The structure members ``subclassrange_min`` and ``subclassrange_max`` are used
-for subclass checking (see below). Every other class X, with parent Y, has the
-structure::
-
- struct vtable_X {
- struct vtable_Y super; // inlined
- ... // extra class attributes
- }
-
-The extra class attributes usually contain function pointers to the methods
-of that class, although the data class attributes (which are supported by the
-RPython object model) are stored there.
-
-The type of the instances is::
-
- struct object { // for instances of the root class
- struct object_vtable* typeptr;
- }
-
- struct X { // for instances of every other class
- struct Y super; // inlined
- ... // extra instance attributes
- }
-
-The extra instance attributes are all the attributes of an instance.
-
-These structure layouts are quite similar to how classes are usually
-implemented in C++.
-
-Subclass checking
------------------
-
-The way we do subclass checking is a good example of the flexibility provided
-by our approach: in the beginning we were using a naive linear lookup
-algorithm. Since subclass checking is quite a common operation (it is also used
-to check whether an object is an instance of a certain class), we wanted to
-replace it with the more efficient relative numbering algorithm (see [PVE]_ for
-an overview of techniques). This was a matter of changing just the appropriate
-code of the rtyping process to calculate the class-ids during rtyping and
-insert the necessary fields into the class structure. It would be similarly
-easy to switch to another implementation.
-
-Identity hashes
----------------
-
-In the RPython type system, class instances can be used as dictionary keys using
-a default hash implementation based on identity, which in practice is
-implemented using the memory address. This is similar to CPython's behavior
-when no user-defined hash function is present. The annotator keeps track of the
-classes for which this hashing is ever used.
-
-One of the peculiarities of PyPy's approach is that live objects are analyzed
-by our translation toolchain. This leads to the presence of instances of RPython
-classes that were built before the translation started. These are called
-"pre-built constants" (PBCs for short). During rtyping, these instances must be
-converted to the low level model. One of the problems with doing this is that
-the standard hash implementation of Python is to take the id of an object, which
-
-is just the memory address. If the RPython program explicitly captures the
-hash of a PBC by storing it (for example in the implementation of a data
-structure) then the stored hash value will not match the value of the object's
-address after translation.
-
-To prevent this the following strategy is used: for every class whose instances
-are hashed somewhere in the program (either when storing them in a
-dictionary or by calling the hash function) an extra field is introduced in the
-structure used for the instances of that class. For PBCs of such a class this
-field is used to store the memory address of the original object and new objects
-have this field initialized to zero. The hash function for instances of such a
-class stores the object's memory address in this field if it is zero. The
-return value of the hash function is the content of the field. This means that
-instances of such a class that are converted PBCs retain the hash values they
-had before the conversion whereas new objects of the class have their memory
-address as hash values. A strategy along these lines would in any case have been
-required if we ever switch to using a copying garbage collector.
-
-Cached functions with PBC arguments
-------------------------------------
-
-As explained in [DLT]_ the annotated code can contain
-functions from a finite set of PBCs to something else. The set itself has to be
-finite but its content does not need to be provided explicitly but is discovered
-as the annotation of the input argument by the annotator itself. This kind of
-function is translated by recording the input-result relationship by calling
-the function concretely at annotation time, and adding a field to the PBCs in
-the set and emitting code reading that field instead of the function call.
-
-Changing the representation of an object
-----------------------------------------
-
-One example of the flexibility the RTyper provides is how we deal with lists.
-Based on information gathered by the annotator the RTyper chooses between two
-different list implementations. If a list never changes its size after creation,
-a low-level array is used directly. For lists which might be resized, a
-representation consisting of a structure with a pointer to an array is used,
-together with over-allocation.
-
-We plan to use similar techniques to use tagged pointers instead of using boxing
-to represent builtin types of the PyPy interpreter such as integers. This would
-require attaching explicit hints to the involved classes. Field access would
-then be translated to the corresponding masking operations.
-
-
-Automatic Memory Management Implementations
-============================================
-
-The whole implementation of the PyPy interpreter assumes automatic memory
-management, e.g. automatic reclamation of memory that is no longer used. The
-whole analysis toolchain also assumes that memory management is being taken
-care of -- only the backends have to concern themselves with that issue. For
-backends that target environments that have their own garbage collector, like
-.NET or Java, this is not an issue. For other targets like C
-the backend has to produce code that uses some sort of garbage collection.
-
-This approach has several advantages. It makes it possible to target different
-platforms, with and without integrated garbage collection. Furthermore, the
-interpreter implementation is not complicated by the need to do explicit memory
-management everywhere. Even more important the backend can optimize the memory
-handling to fit a certain situation (like a machine with very restricted
-memory) or completely replace the memory management technique or memory model
-with a different one without the need to change source code. Additionally,
-the backend can use information that was inferred by the rest of the toolchain
-to improve the quality of memory management.
-
-Using the Boehm garbage collector
------------------------------------
-
-Currently there are two different garbage collectors implemented in the C
-backend (which is the most complete backend right now). One of them uses the
-existing Boehm-Demers-Weiser garbage collector [BOEHM]_. For every memory
-allocating operation in a low level flow graph the C backend introduces a call
-to a function of the boehm collector which returns a suitable amount of memory.
-Since the C backend has a lot of information available about the data structure
-being allocated it can choose the memory allocation function out of the Boehm
-API that fits best. For example, for objects that do not contain references to
-other objects (e.g. strings) there is a special allocation function which
-signals to the collector that it does not need to consider this memory when
-tracing pointers.
-
-Using the Boehm collector has disadvantages as well. The problems stem from the
-fact that the Boehm collector is conservative which means that it has to
-consider every word in memory as a potential pointer. Since PyPy's toolchain
-has complete knowledge of the placement of data in memory we can generate an
-exact garbage collector that considers only genuine pointers.
-
-Using a simple reference counting garbage collector
------------------------------------------------------
-
-The other implemented garbage collector is a simple reference counting scheme.
-The C backend inserts a reference count field into every structure that has to be
-handled by the garbage collector and puts increment and decrement operations
-for this reference count into suitable places in the resulting C code. After
-every reference decrement operations a check is performed whether the reference
-count has dropped to zero. If this is the case the memory of the object will be
-reclaimed after the references counts of the objects the original object
-refers to are decremented as well.
-
-The current placement of reference counter updates is far from optimal: The
-reference counts are updated much more often than theoretically necessary (e.g.
-sometimes a counter is increased and then immediately decreased again).
-Objects passed into a function as arguments can almost always use a "trusted reference",
-because the call-site is responsible to create a valid reference.
-Furthermore some more analysis could show that some objects don't need a
-reference counter at all because they either have a very short, foreseeable
-life-time or because they live exactly as long as another object.
-
-Another drawback of the current reference counting implementation is that it
-cannot deal with circular references, which is a fundamental flaw of reference
-counting memory management schemes in general. CPython solves this problem by
-having special code that handles circular garbage which PyPy lacks at the
-moment. This problem has to be addressed in the future to make the reference
-counting scheme a viable garbage collector. Since reference counting is quite
-successfully used by CPython it will be interesting to see how far it can be
-optimized for PyPy.
-
-Simple escape analysis to remove memory allocation
----------------------------------------------------
-
-We also implemented a technique to reduce the amount of memory allocation.
-Sometimes it is possible to deduce from the flow graphs that an object lives
-exactly as long as the stack frame of the function it is allocated in.
-This happens if no pointer to the object is stored into another object and if
-no pointer to the object is returned from the function. If this is the case and
-if the size of the object is known in advance the object can be allocated on
-the stack. To achieve this, the object is "exploded", that means that for every
-element of the structure a new variable is generated that is handed around in
-the graph. Reads from elements of the structure are removed and just replaced
-by one of the variables, writes by assignments to same.
-
-Since quite a lot of objects are allocated in small helper functions, this
-simple approach which does not track objects across function boundaries only
-works well in the presence of function inlining.
-
-A general garbage collection framework
---------------------------------------
-
-In addition to the garbage collectors implemented in the C backend we have also
-started writing a more general toolkit for implementing exact garbage
-collectors in Python. The general idea is to express the garbage collection
-algorithms in Python as well and translate them as part of the translation
-process to C code (or whatever the intended platform is).
-
-To be able to access memory in a low level manner there are special ``Address``
-objects that behave like pointers to memory and can be manipulated accordingly:
-it is possible to read/write to the location they point to a variety of data
-types and to do pointer arithmetic. These objects are translated to real
-pointers and the appropriate operations. When run on top of CPython there is a
-*memory simulator* that makes the address objects behave like they were
-accessing real memory. In addition the memory simulator contains a number of
-consistency checks that expose common memory handling errors like dangling
-pointers, uninitialized memory, etc.
-
-At the moment we have three simple garbage collectors implemented for this
-framework: a simple copying collector, a mark-and-sweep collector and a
-deferred reference counting collector. These garbage collectors are work when run on
-top of the memory simulator, but at the moment it is not yet possible to translate
-PyPy to C with them. This is because it is not easy to
-find the root pointers that reside on the C stack -- both because the C stack layout is
-heavily platform dependent, and also due to the possibility of roots that are not
-only on the stack but also hiding in registers (which would give a problem for *moving
-garbage collectors*).
-
-There are several possible solutions for this problem: One
-of them is to not use C compilers to generate machine code, so that the stack
-frame layout gets into our control. This is one of the tasks that need to be
-tackled in phase 2, as directly generating assembly is needed anyway for a
-just-in-time compiler. The other possibility (which would be much easier to
-implement) is to move all the data away from the stack to the heap
-before collecting garbage, as described in section "Stackless C code" below.
-
-Concurrency Model Implementations
-============================================
-
-At the moment we have implemented two different concurrency models, and the
-option to not support concurrency at all
-(another proof of the modularity of our approach):
-threading with a global interpreter lock and a "stackless" model.
-
-No threading
--------------
-
-By default, multi-threading is not supported at all, which gives some small
-benefits for single-threaded applications since even in the single-threaded
-case there is some overhead if threading capabilities are built into
-the interpreter.
-
-Threading with a Global Interpreter Lock
-------------------------------------------
-
-Right now, there is one non-trivial threading model implemented. It follows
-the threading implementation of CPython and thus uses a global interpreter
-lock. This lock prevents any two threads from interpreting python code at
-the same time. The global interpreter lock is released around calls to blocking I/O
-functions. This approach has a number of advantages: it gives very little
-runtime penalty for single-threaded applications, makes many of the common uses
-for threading possible, and it is relatively easy to implement and maintain. It has
-the disadvantage that multiple threads cannot be distributed across multiple
-processors.
-
-To make this threading-model usable for I/O-bound applications, the global
-interpreter lock should be released around blocking external function calls
-(which is also what CPython does). This has been partially implemented.
-
-
-Stackless C code
------------------
-
-"Stackless" C code is C code that only uses a bounded amount of
-space in the C stack, and that can generally obtain explicit
-control of its own stack. This is commonly known as "continuations",
-or "continuation-passing style" code, although in our case we will limit
-ourselves to single-shot continuations, i.e. continuations that are
-captured and subsequently will be resumed exactly once.
-
-The technique we have implemented is based on the recurring idea
-of emulating this style via exceptions: a specific program point can
-generate a pseudo-exception whose purpose is to unwind the whole C stack
-in a restartable way. More precisely, the "unwind" exception causes
-the C stack to be saved into the heap in a compact and explicit
-format, as described below. It is then possible to resume only the
-innermost (most recent) frame of the saved stack -- allowing unlimited
-recursion on OSes that limit the size of the C stack -- or to resume a
-different previously-saved C stack altogether, thus implementing
-coroutines or light-weight threads.
-
-In our case, exception handling is always explicit in the generated code:
-the C backend puts a cheap check
-after each call site to detect if the callee exited
-normally or generated an exception. So when compiling functions in
-stackless mode, the generated exception handling code special-cases the
-new "unwind" exception. This exception causes the current function to
-respond by saving its local variables to a heap structure (a linked list
-of records, one per stack frame) and then propagating the exception
-outwards. Eventually, at the end of the frame chain, the outermost
-function is a manually-written dispatcher that catches the "unwind"
-exception.
-
-At this point, the whole C stack is stored away in the heap. This is a
-very interesting state in itself, because precisely there is no C stack
-below the dispatcher
-left. It is this which will allow us to write all the algorithms
-in a portable way, that
-normally require machine-specific code to inspect the stack,
-in particular garbage collectors.
-
-To continue execution, the dispatcher can resume either the freshly saved or a
-completely different stack. Moreover, it can resume directly the innermost
-(most recent) saved frame in the heap chain, without having to resume all
-intermediate frames first. This not only makes stack switches fast, but it
-also allows the frame to continue to run on top of a clean C stack. When that
-frame eventually exits normally, it returns to the dispatcher, which then
-invokes the previous (parent) saved frame, and so on. We insert stack checks
-before calls that can lead to recursion by detecting cycles in the call graph.
-These stack checks copy the stack to the heap (by raising the special
-exception) if it is about to grow deeper than a certain level.
-As a different point of view, the C stack can also be considered as a cache
-for the heap-based saved frames in this model. When we run out
-of C stack space, we flush the cache. When the cache is empty, we fill it with
-the next item from the heap.
-
-To give the translated program some amount of control over the
-heap-based stack structures and over the top-level dispatcher that jumps
-between them, there are a few "external" functions directly implemented
-in C. These functions provide an elementary interface, on top of which
-useful abstractions can be implemented, like:
-
-* coroutines: explicitly switching code, similar to Greenlets [GREENLET]_.
-
-* "tasklets": cooperatively-scheduled microthreads, as introduced in
- Stackless Python [STK]_.
-
-* implicitly-scheduled (preemptive) microthreads, also known as green threads.
-
-An important property of the changes in all the generated C functions is
-that they are written in a way that does only minimally degrade their performance in
-the non-exceptional case. Most optimizations performed by C compilers,
-like register allocation, continue to work...
-
-The following picture shows a graph function together with the modifications
-necessary for the stackless style: the check whether the stack is too big and
-should be unwound, the check whether we are in the process of currently storing
-away the stack and the check whether the call to the function is not a regular
-call but a reentry call.
-
-.. graphviz:: image/stackless_informal.dot
- :scale: 70
-
-
-Future work
-================
-
-open challenges for phase 2:
-
-Garbage collection
-------------------
-
-One of the biggest missing features of our current garbage collectors is
-finalization. At present finalizers are simply not invoked if an object is
-freed by the garbage collector. Along the same lines weak references are not
-supported yet. It should be possible to implement these with a reasonable
-amount of effort for reference counting as well as the Boehm collector (which
-provides the necessary hooks).
-
-Integrating the now simulated-only GC framework into the rtyping process and
-the code generation will require considerable effort. It requires being able to
-keep track of the GC roots which is hard to do with portable C code. One
-solution would be to use the "stackless" code since it can move the stack
-completely to the heap. We expect that we can implement GC read and write
-barriers as function calls and rely on inlining to make them more efficient.
-
-We may also spend some time on improving the existing reference counting
-implementation by removing unnecessary incref-decref pairs and identifying
-trustworthy references. A bigger task would
-be to add support for detecting circular references.
-
-
-Threading model
----------------
-
-One of the interesting possibilities that stackless offers is to implement *green
-threading*. This would involve writing a scheduler and some preemption logic.
-
-We should also investigate other threading models based on operating system
-threads with various granularities of locking for access of shared objects.
-
-Object model
-------------
-
-We also might want to experiment with more sophisticated structure inlining.
-Sometimes it is possible to find out that one structure object
-allocated on the heap lives exactly as long as another structure object on the
-heap pointing to it. If this is the case it is possible to inline the first
-object into the second. This saves the space of one pointer and avoids
-pointer-chasing.
-
-
-Conclusion
-===========
-
-As concretely shown with various detailed examples, our approach gives us
-flexibility and lets us choose various aspects at translation time instead
-of encoding them into the implementation itself.
-
-References
-===========
-
-.. [BOEHM] `Boehm-Demers-Weiser garbage collector`_, a garbage collector
- for C and C++, Hans Boehm, 1988-2004
-.. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
-
-.. [GREENLET] `Lightweight concurrent programming`_, py-lib Documentation 2003-2005
-.. _`Lightweight concurrent programming`: http://codespeak.net/svn/greenlet/trunk/doc/greenlet.txt
-
-.. [STK] `Stackless Python`_, a Python implementation that does not use
- the C stack, Christian Tismer, 1999-2004
-.. _`Stackless Python`: http://www.stackless.com
-
-.. [TR] `Translation`_, PyPy documentation, 2003-2005
-.. _`Translation`: translation.html
-
-.. [LE] `Encapsulating low-level implementation aspects`_,
- PyPy documentation (and EU deliverable D05.4), 2005
-.. _`Encapsulating low-level implementation aspects`: low-level-encapsulation.html
-
-.. [DLT] `Compiling dynamic language implementations`_,
- PyPy documentation (and EU deliverable D05.1), 2005
-.. _`Compiling dynamic language implementations`: http://codespeak.net/svn/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
-
-.. [PVE] `Simple and Efficient Subclass Tests`_, Jonathan Bachrach, Draft submission to ECOOP-02, 2001
-.. _`Simple and Efficient Subclass Tests`: http://people.csail.mit.edu/jrb/pve/pve.pdf
diff --git a/pypy/doc/navlist b/pypy/doc/navlist
deleted file mode 100644
--- a/pypy/doc/navlist
+++ /dev/null
@@ -1,9 +0,0 @@
-[
- 'architecture.html',
- 'getting-started.html',
- 'coding-guide.html',
- 'objspace.html',
- 'translation.html',
-# 'misc.html',
- 'theory.html',
-]
diff --git a/pypy/doc/config/objspace.usemodules.pypyjit.rst b/pypy/doc/config/objspace.usemodules.pypyjit.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.pypyjit.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the 'pypyjit' module.
diff --git a/pypy/doc/config/translation.secondaryentrypoints.rst b/pypy/doc/config/translation.secondaryentrypoints.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.secondaryentrypoints.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Enable secondary entrypoints support list. Needed for cpyext module.
diff --git a/pypy/doc/config/objspace.std.getattributeshortcut.rst b/pypy/doc/config/objspace.std.getattributeshortcut.txt
copy from pypy/doc/config/objspace.std.getattributeshortcut.rst
copy to pypy/doc/config/objspace.std.getattributeshortcut.txt
diff --git a/pypy/doc/config/objspace.usemodules.zlib.rst b/pypy/doc/config/objspace.usemodules.zlib.txt
copy from pypy/doc/config/objspace.usemodules.zlib.rst
copy to pypy/doc/config/objspace.usemodules.zlib.txt
diff --git a/pypy/doc/config/translation.backendopt.inline_heuristic.rst b/pypy/doc/config/translation.backendopt.inline_heuristic.txt
copy from pypy/doc/config/translation.backendopt.inline_heuristic.rst
copy to pypy/doc/config/translation.backendopt.inline_heuristic.txt
diff --git a/pypy/doc/config/objspace.usemodules.symbol.rst b/pypy/doc/config/objspace.usemodules.symbol.txt
copy from pypy/doc/config/objspace.usemodules.symbol.rst
copy to pypy/doc/config/objspace.usemodules.symbol.txt
diff --git a/pypy/doc/config/translation.instrument.rst b/pypy/doc/config/translation.instrument.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.instrument.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/config/translation.make_jobs.rst b/pypy/doc/config/translation.make_jobs.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.make_jobs.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Specify number of make jobs for make command.
diff --git a/pypy/doc/config/objspace.rst b/pypy/doc/config/objspace.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-.. intentionally empty
diff --git a/pypy/doc/config/objspace.usemodules.rctime.rst b/pypy/doc/config/objspace.usemodules.rctime.txt
copy from pypy/doc/config/objspace.usemodules.rctime.rst
copy to pypy/doc/config/objspace.usemodules.rctime.txt
diff --git a/pypy/doc/config/objspace.usemodules._sre.rst b/pypy/doc/config/objspace.usemodules._sre.txt
copy from pypy/doc/config/objspace.usemodules._sre.rst
copy to pypy/doc/config/objspace.usemodules._sre.txt
diff --git a/pypy/doc/discussion/thoughts_string_interning.rst b/pypy/doc/discussion/thoughts_string_interning.rst
deleted file mode 100644
--- a/pypy/doc/discussion/thoughts_string_interning.rst
+++ /dev/null
@@ -1,211 +0,0 @@
-String Interning in PyPy
-========================
-
-A few thoughts about string interning. CPython gets a remarkable
-speed-up by interning strings. Interned are all builtin string
-objects and all strings used as names. The effect is that when
-a string lookup is done during instance attribute access,
-the dict lookup method will find the string always by identity,
-saving the need to do a string comparison.
-
-Interned Strings in CPython
----------------------------
-
-CPython keeps an internal dictionary named ``interned`` for all of these
-strings. It contains the string both as key and as value, which means
-there are two extra references in principle. Upto Version 2.2, interned
-strings were considered immortal. Once they entered the ``interned`` dict,
-nothing could revert this memory usage.
-
-Starting with Python 2.3, interned strings became mortal by default.
-The reason was less memory usage for strings that have no external
-reference any longer. This seems to be a worthwhile enhancement.
-Interned strings that are really needed always have a real reference.
-Strings which are interned for temporary reasons get a big speed up
-and can be freed after they are no longer in use.
-
-This was implemented by making the ``interned`` dictionary a weak dict,
-by lowering the refcount of interned strings by 2. The string deallocator
-got extra handling to look into the ``interned`` dict when a string is deallocated.
-This is supported by the state variable on string objects which tells
-whether the string is not interned, immortal or mortal.
-
-Implementation problems for PyPy
---------------------------------
-
-- The CPython implementation makes explicit use of the refcount to handle
- the weak-dict behavior of ``interned``. PyPy does not expose the implementation
- of object aliveness. Special handling would be needed to simulate mortal
- behavior. A possible but expensive solution would be to use a real
- weak dictionary. Another way is to add a special interface to the backend
- that allows either the two extra references to be reset, or for the
- boehm collector to exclude the ``interned`` dict from reference tracking.
-
-- PyPy implements quite complete internal strings, as opposed to CPython
- which always uses its "applevel" strings. It also supports low-level
- dictionaries. This adds some complication to the issue of interning.
- Additionally, the interpreter currently handles attribute access
- by calling wrap(str) on the low-level attribute string when executing
- frames. This implies that we have to primarily intern low-level strings
- and cache the created string objects on top of them.
- A possible implementation would use a dict with ll string keys and the
- string objects as values. In order to save the extra dict lookup, we also
- could consider to cache the string object directly on a field of the rstr,
- which of course adds some extra cost. Alternatively, a fast id-indexed
- extra dictionary can provide the mapping from rstr to interned string object.
- But for efficiency reasons, it is anyway necessary to put an extra flag about
- interning on the strings. Flagging this by putting the string object itself
- as the flag might be acceptable. A dummyobject can be used if the interned
- rstr is not exposed as an interned string object.
-
-Update: a reasonably simple implementation
--------------------------------------------
-
-Instead of the complications using the stringobject as a property of an rstr
-instance, I propose to special case this kind of dictionary (mapping rstr
-to stringobject) and to put an integer ``interned`` field into the rstr. The
-default is -1 for not interned. Non-negative values are the direct index
-of this string into the interning dict. That is, we grow an extra function
-that indexes the dict by slot number of the dict table and gives direct
-access to its value. The dictionary gets special handling on dict_resize,
-to recompute the slot numbers of the interned strings. ATM I'd say we leave
-the strings immortal and support mortality later when we have a cheap
-way to express this (less refcount, exclusion from Boehm, whatever).
-
-A prototype brute-force patch
------------------------------
-
-In order to get some idea how efficient string interning is at the moment,
-I implemented a quite crude version of interning. I patched space.wrap
-to call this intern_string instead of W_StringObject::
-
- def intern_string(space, str):
- if we_are_translated():
- _intern_ids = W_StringObject._intern_ids
- str_id = id(str)
- w_ret = _intern_ids.get(str_id, None)
- if w_ret is not None:
- return w_ret
- _intern = W_StringObject._intern
- if str not in _intern:
- _intern[str] = W_StringObject(space, str)
- W_StringObject._intern_keep[str_id] = str
- _intern_ids[str_id] = w_ret = _intern[str]
- return w_ret
- else:
- return W_StringObject(space, str)
-
-This is no general solution at all, since it a) does not provide
-interning of rstr and b) interns every app-level string. The
-implementation is also by far not as efficient as it could be,
-because it utilizes an extra dict _intern_ids which maps the
-id of the rstr to the string object, and a dict _intern_keep to
-keep these ids alive.
-
-With just a single _intern dict from rstr to string object, the
-overall performance degraded slightly instead of an advantage.
-The triple dict patch accelerates richards by about 12 percent.
-Since it still has the overhead of handling the extra dicts,
-I guess we can expect twice the acceleration if we add proper
-interning support.
-
-The resulting estimated 24 % acceleration is still not enough
-to justify an implementation right now.
-
-Here the results of the richards benchmark::
-
- D:\pypy\dist\pypy\translator\goal>pypy-c-17516.exe -c "from richards import *;Richards.iterations=1;main()"
- debug: entry point starting
- debug: argv -> pypy-c-17516.exe
- debug: argv -> -c
- debug: argv -> from richards import *;Richards.iterations=1;main()
- Richards benchmark (Python) starting... [<function entry_point at 0xeae060>]
- finished.
- Total time for 1 iterations: 38 secs
- Average time for iterations: 38885 ms
-
- D:\pypy\dist\pypy\translator\goal>pypy-c.exe -c "from richards import *;Richards.iterations=1;main()"
- debug: entry point starting
- debug: argv -> pypy-c.exe
- debug: argv -> -c
- debug: argv -> from richards import *;Richards.iterations=1;main()
- Richards benchmark (Python) starting... [<function entry_point at 0xead810>]
- finished.
- Total time for 1 iterations: 34 secs
- Average time for iterations: 34388 ms
-
- D:\pypy\dist\pypy\translator\goal>
-
-
-This was just an exercise to get an idea. For sure this is not to be checked in.
-Instead, I'm attaching the simple patch here for reference.
-::
-
- Index: objspace/std/objspace.py
- ===================================================================
- --- objspace/std/objspace.py (revision 17526)
- +++ objspace/std/objspace.py (working copy)
- @@ -243,6 +243,9 @@
- return self.newbool(x)
- return W_IntObject(self, x)
- if isinstance(x, str):
- + # XXX quick speed testing hack
- + from pypy.objspace.std.stringobject import intern_string
- + return intern_string(self, x)
- return W_StringObject(self, x)
- if isinstance(x, unicode):
- return W_UnicodeObject(self, [unichr(ord(u)) for u in x]) # xxx
- Index: objspace/std/stringobject.py
- ===================================================================
- --- objspace/std/stringobject.py (revision 17526)
- +++ objspace/std/stringobject.py (working copy)
- @@ -18,6 +18,10 @@
- class W_StringObject(W_Object):
- from pypy.objspace.std.stringtype import str_typedef as typedef
-
- + _intern_ids = {}
- + _intern_keep = {}
- + _intern = {}
- +
- def __init__(w_self, space, str):
- W_Object.__init__(w_self, space)
- w_self._value = str
- @@ -32,6 +36,21 @@
-
- registerimplementation(W_StringObject)
-
- +def intern_string(space, str):
- + if we_are_translated():
- + _intern_ids = W_StringObject._intern_ids
- + str_id = id(str)
- + w_ret = _intern_ids.get(str_id, None)
- + if w_ret is not None:
- + return w_ret
- + _intern = W_StringObject._intern
- + if str not in _intern:
- + _intern[str] = W_StringObject(space, str)
- + W_StringObject._intern_keep[str_id] = str
- + _intern_ids[str_id] = w_ret = _intern[str]
- + return w_ret
- + else:
- + return W_StringObject(space, str)
-
- def _isspace(ch):
- return ord(ch) in (9, 10, 11, 12, 13, 32)
- Index: objspace/std/stringtype.py
- ===================================================================
- --- objspace/std/stringtype.py (revision 17526)
- +++ objspace/std/stringtype.py (working copy)
- @@ -47,6 +47,10 @@
- if space.is_true(space.is_(w_stringtype, space.w_str)):
- return w_obj # XXX might be reworked when space.str() typechecks
- value = space.str_w(w_obj)
- + # XXX quick hack to check interning effect
- + w_obj = W_StringObject._intern.get(value, None)
- + if w_obj is not None:
- + return w_obj
- w_obj = space.allocate_instance(W_StringObject, w_stringtype)
- W_StringObject.__init__(w_obj, space, value)
- return w_obj
-
-ciao - chris
diff --git a/pypy/doc/contributor.rst b/pypy/doc/contributor.rst
--- a/pypy/doc/contributor.rst
+++ b/pypy/doc/contributor.rst
@@ -6,100 +6,155 @@
code base, ordered by number of commits (which is certainly not a very
appropriate measure but it's something)::
-
Armin Rigo
Maciej Fijalkowski
Carl Friedrich Bolz
+ Amaury Forgeot d'Arc
+ Antonio Cuni
Samuele Pedroni
- Antonio Cuni
Michael Hudson
+ Holger Krekel
Christian Tismer
- Holger Krekel
+ Benjamin Peterson
Eric van Riet Paap
+ Anders Chrigström
+ Håkan Ardö
Richard Emslie
- Anders Chrigstrom
- Amaury Forgeot d Arc
- Aurelien Campeas
+ Dan Villiom Podlaski Christiansen
+ Alexander Schremmer
+ Alex Gaynor
+ David Schneider
+ Aurelién Campeas
Anders Lehmann
+ Camillo Bruni
Niklaus Haldimann
+ Leonardo Santagada
+ Toon Verwaest
Seo Sanghyeon
- Leonardo Santagada
Lawrence Oluyede
+ Bartosz Skowron
Jakub Gustak
Guido Wesdorp
- Benjamin Peterson
- Alexander Schremmer
+ Adrien Di Mascio
+ Laura Creighton
+ Ludovic Aubry
Niko Matsakis
- Ludovic Aubry
+ Daniel Roberts
+ Jason Creighton
+ Jacob Hallén
Alex Martelli
- Toon Verwaest
+ Anders Hammarquist
+ Jan de Mooij
Stephan Diehl
- Adrien Di Mascio
+ Michael Foord
Stefan Schwarzer
Tomek Meka
Patrick Maupin
- Jacob Hallen
- Laura Creighton
Bob Ippolito
- Camillo Bruni
- Simon Burton
Bruno Gola
Alexandre Fayolle
Marius Gedminas
+ Simon Burton
+ Jean-Paul Calderone
+ John Witulski
+ Wim Lavrijsen
+ Andreas Stührk
+ Jean-Philippe St. Pierre
Guido van Rossum
+ Pavel Vinogradov
Valentino Volonghi
+ Paul deGrandis
Adrian Kuhn
- Paul deGrandis
+ tav
+ Georg Brandl
Gerald Klix
Wanja Saatkamp
- Anders Hammarquist
+ Boris Feigin
Oscar Nierstrasz
+ Dario Bertini
+ David Malcolm
Eugene Oden
+ Henry Mason
Lukas Renggli
Guenter Jantzen
+ Ronny Pfannschmidt
+ Bert Freudenberg
+ Amit Regmi
+ Ben Young
+ Nicolas Chauvat
+ Andrew Durdin
+ Michael Schneider
+ Nicholas Riley
+ Rocco Moretti
+ Gintautas Miliauskas
+ Michael Twomey
+ Igor Trindade Oliveira
+ Lucian Branescu Mihaila
+ Olivier Dormond
+ Jared Grubb
+ Karl Bartel
+ Gabriel Lavoie
+ Brian Dorsey
+ Victor Stinner
+ Stuart Williams
+ Toby Watson
+ Antoine Pitrou
+ Justas Sadzevicius
+ Neil Shepperd
+ Mikael Schönenberg
+ Gasper Zejn
+ Jonathan David Riehl
+ Elmo Mäntynen
+ Anders Qvist
+ Beatrice Düring
+ Alexander Sedov
+ Vincent Legoll
+ Alan McIntyre
+ Romain Guillebert
+ Alex Perry
+ Jens-Uwe Mager
+ Dan Stromberg
+ Lukas Diekmann
+ Carl Meyer
+ Pieter Zieschang
+ Alejandro J. Cura
+ Sylvain Thenault
+ Travis Francis Athougies
+ Henrik Vendelbo
+ Lutz Paelike
+ Jacob Oscarson
+ Martin Blais
+ Lucio Torre
+ Lene Wagner
+ Miguel de Val Borro
+ Ignas Mikalajunas
+ Artur Lisiecki
+ Joshua Gilbert
+ Godefroid Chappelle
+ Yusei Tahara
+ Christopher Armstrong
+ Stephan Busemann
+ Gustavo Niemeyer
+ William Leslie
+ Akira Li
+ Kristján Valur Jonsson
+ Bobby Impollonia
+ Andrew Thompson
+ Anders Sigfridsson
+ Jacek Generowicz
+ Dan Colish
+ Sven Hager
+ Zooko Wilcox-O Hearn
+ Anders Hammarquist
Dinu Gherman
- Bartosz Skowron
- Georg Brandl
- Ben Young
- Jean-Paul Calderone
- Nicolas Chauvat
- Rocco Moretti
- Michael Twomey
- 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
- Jacob Oscarson
- Lutz Paelike
- Michael Schneider
- Artur Lisiecki
- Lene Wagner
- Christopher Armstrong
- Jan de Mooij
- Jacek Generowicz
- Gasper Zejn
- Stephan Busemann
- Yusei Tahara
- Godefroid Chappelle
- Toby Watson
- Andrew Thompson
- Joshua Gilbert
- Anders Sigfridsson
- David Schneider
+ Dan Colish
+ Daniel Neuhäuser
Michael Chermside
- tav
- Martin Blais
- Victor Stinner
+ Konrad Delong
+ Anna Ravencroft
+ Greg Price
+ Armin Ronacher
+ Jim Baker
+ Philip Jenvey
+ Rodrigo Araújo
+
diff --git a/pypy/doc/config/objspace.nofaking.rst b/pypy/doc/config/objspace.nofaking.txt
copy from pypy/doc/config/objspace.nofaking.rst
copy to pypy/doc/config/objspace.nofaking.txt
diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal.rst b/pypy/doc/config/translation.backendopt.clever_malloc_removal.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.clever_malloc_removal.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-Try to inline flowgraphs based on whether doing so would enable malloc
-removal (:config:`translation.backendopt.mallocs`.) by eliminating
-calls that result in escaping. This is an experimental optimization,
-also right now some eager inlining is necessary for helpers doing
-malloc itself to be inlined first for this to be effective.
-This option enable also an extra subsequent malloc removal phase.
-
-Callee flowgraphs are considered candidates based on a weight heuristic like
-for basic inlining. (see :config:`translation.backendopt.inline`,
-:config:`translation.backendopt.clever_malloc_removal_threshold` ).
diff --git a/pypy/doc/config/objspace.usemodules.sys.rst b/pypy/doc/config/objspace.usemodules.sys.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.sys.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'sys' module.
-This module is essential, included by default and should not be removed.
diff --git a/pypy/doc/project-ideas.rst b/pypy/doc/project-ideas.rst
deleted file mode 100644
--- a/pypy/doc/project-ideas.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-Independent project ideas relating to PyPy
-==========================================
-
-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
-of experiments that the core developers have not had time to perform
-yet and also do not require too much in depth knowledge to get started
-with.
-
-Feel free to suggest new ideas and discuss them in #pypy on the freenode IRC
-network or the pypy-dev mailing list (see the home_ page).
-
------------
-
-.. contents::
-
-
-
-JIT back-ends
---------------------------------
-
-PyPy's Just-In-Time compiler relies on backends for actual code
-generation. We have so far a 32-bit Intel backend, and a CLI one. There is
-Summer of Code project for 64bit (x86_64) backend, but other options
-(ARM, llvm) remain open.
-
-.. _distribution:
-.. _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
-direction; now all that remains is to implement the interesting bits :-)
-
-An example project might be to implement functionality akin to the `ZODB's
-Persistent class`_, without the need for the _p_changed hacks, and in pure
-Python code (should be relatively easy on top of transparent proxy).
-
-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
-
-
-Other languages
----------------
-
-Improve one of the `existing interpreters`__, or start a new one.
-Experiment with the JIT compiler generator.
-
-.. __: http://codespeak.net/svn/pypy/lang/
-
-
-Or else...
-----------
-
-...or whatever else interests you!
-
-Feel free to mention your interest and discuss these ideas on the `pypy-dev
-mailing list`_ or on the #pypy channel on irc.freenode.net.
-You can also have a look around our documentation_.
-
-
-.. _`efficient propagators for specialized finite domains`: http://codespeak.net/svn/pypy/extradoc/soc-2006/constraints.txt
-.. _`object spaces`: objspace.html
-.. _`code templating solution`: http://codespeak.net/svn/pypy/extradoc/soc-2006/code-templating.txt
-
-.. _documentation: docindex.html
-.. _home: index.html
-.. _`pypy-dev mailing list`: http://codespeak.net/mailman/listinfo/pypy-dev
-.. _`ZODB's Persistent class`: http://www.zope.org/Documentation/Books/ZDG/current/Persistence.stx
-.. _`transparent proxy`: objspace-proxies.html#tproxy
diff --git a/pypy/doc/config/objspace.usemodules._collections.rst b/pypy/doc/config/objspace.usemodules._collections.txt
copy from pypy/doc/config/objspace.usemodules._collections.rst
copy to pypy/doc/config/objspace.usemodules._collections.txt
diff --git a/pypy/doc/getting-started-python.rst b/pypy/doc/getting-started-python.rst
--- a/pypy/doc/getting-started-python.rst
+++ b/pypy/doc/getting-started-python.rst
@@ -10,19 +10,18 @@
`CPythons core language regression tests`_ and comes with many of the extension
modules included in the standard library including ``ctypes``. It can run large
libraries such as Django_ and Twisted_. There are some small behavioral
-differences to CPython and some missing extensions, for details see `CPython
+differences with CPython and some missing extensions, for details see `CPython
differences`_.
-.. _Django: http://djangoproject.org
+.. _Django: http://djangoproject.com
.. _Twisted: http://twistedmatrix.com
.. _`CPython differences`: cpython_differences.html
-To actually use PyPy's Python interpreter, the first thing you typically do is
-translate it to get a reasonably performing interpreter. This is described in
-the next section. If you just want to play around a bit, you can also try
-untranslated `py.py interpreter`_ (which is extremely slow, but still fast
-enough for tiny examples).
+To actually use PyPy's Python interpreter, the first thing to do is to
+`download a pre-built PyPy`_ for your architecture.
+
+.. _`download a pre-built PyPy`: http://pypy.org/download.html
Translating the PyPy Python interpreter
---------------------------------------
@@ -33,9 +32,15 @@
.. _`windows document`: windows.html
You can translate the whole of PyPy's Python interpreter to low level C code,
-`CLI code`_, or `JVM code`_.
+or `CLI code`_.
-1. Install build-time dependencies. On a Debian box these are::
+1. First `download a pre-built PyPy`_ for your architecture which you will
+ use to translate your Python interpreter. It is, of course, possible to
+ translate with a CPython 2.6 or later, but this is not the preferred way,
+ because it will take a lot longer to run -- depending on your architecture,
+ between two and three times as long.
+
+2. Install build-time dependencies. On a Debian box these are::
[user at debian-box ~]$ sudo apt-get install \
gcc make python-dev libffi-dev pkg-config \
@@ -58,29 +63,33 @@
* ``libexpat1-dev`` (for the optional ``pyexpat`` module)
* ``libssl-dev`` (for the optional ``_ssl`` module)
* ``libgc-dev`` (for the Boehm garbage collector: only needed when translating with `--opt=0, 1` or `size`)
- * ``python-sphinx`` (for the optional documentation build)
+ * ``python-sphinx`` (for the optional documentation build. You need version 1.0.7 or later)
* ``python-greenlet`` (for the optional stackless support in interpreted mode/testing)
-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
+
+3. Translation is time-consuming -- 45 minutes on a very fast machine --
+ and RAM-hungry. As of March 2011, you will need **at least** 2 GB of
+ memory on a
+ 32-bit machine and 4GB on a 64-bit machine. If your memory resources
+ are constrained, or your machine is slow you might want to pick the
`optimization level`_ `1` in the next step. A level of
- `2` or `3` or `jit` gives much better results, though.
+ `2` or `3` or `jit` gives much better results, though. But if all
+ you want to do is to test that some new feature that you just wrote
+ translates, level 1 is enough.
- Let me stress this another time: at ``--opt=1`` you get the Boehm
+ Let me stress this again: 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.
+ You really do not want to pick it for a program you intend to use.
+ The resulting ``pypy-c`` is slow.
-3. Run::
+4. Run::
cd pypy/translator/goal
python translate.py --opt=jit targetpypystandalone.py
possibly replacing ``--opt=jit`` with another `optimization level`_
- of your choice like ``--opt=2`` if you do not want the included JIT
- compiler. As of March 2011, Intel 32-bit environment needs **at
- least** 2GB, and 64-bit needs 4GB.
+ of your choice like ``--opt=2`` if you do not want to include the JIT
+ compiler, which makes the Python interpreter much slower.
.. _`optimization level`: config/opt.html
@@ -92,22 +101,20 @@
executable. The executable behaves mostly like a normal Python interpreter::
$ ./pypy-c
- Python 2.5.2 (64177, Apr 16 2009, 16:33:13)
- [PyPy 1.1.0] on linux2
+ Python 2.7.0 (61ef2a11b56a, Mar 02 2011, 03:00:11)
+ [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``this sentence is false''
>>>> 46 - 4
42
>>>> from test import pystone
>>>> pystone.main()
- Pystone(1.1) time for 50000 passes = 2.57
- This machine benchmarks at 19455.3 pystones/second
+ Pystone(1.1) time for 50000 passes = 0.280017
+ This machine benchmarks at 178561 pystones/second
>>>>
This executable can be moved around or copied on other machines; see
-Installation_ below. For now a JIT-enabled ``pypy-c`` always produces
-debugging output to stderr when it exits, unless translated with
-``--jit-debug=off``.
+Installation_ below.
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
@@ -134,7 +141,7 @@
++++++++++++++++++++++++++++++++++++++++
It is possible to have non-standard features enabled for translation,
-but they are not really tested any more. Look for example at the
+but they are not really tested any more. Look, for example, at the
`objspace proxies`_ document.
.. _`objspace proxies`: objspace-proxies.html
@@ -148,22 +155,14 @@
./translate.py --backend=cli targetpypystandalone.py
-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::
$ ./pypy-cli
- Python 2.5.2 (64219, Apr 17 2009, 13:54:38)
- [PyPy 1.1.0] on linux2
+ Python 2.7.0 (61ef2a11b56a, Mar 02 2011, 03:00:11)
+ [PyPy 1.5.0-alpha0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``distopian and utopian chairs''
>>>>
@@ -183,29 +182,31 @@
To try out the experimental .NET integration, check the documentation of the
clr_ module.
-.. _`JVM code`:
+.. not working now:
-Translating using the JVM backend
-+++++++++++++++++++++++++++++++++
+ .. _`JVM code`:
-To create a standalone JVM executable::
+ Translating using the JVM backend
+ +++++++++++++++++++++++++++++++++
- ./translate.py --backend=jvm targetpypystandalone.py
+ To create a standalone JVM executable::
-This will create a jar file ``pypy-jvm.jar`` as well as a convenience
-script ``pypy-jvm`` for executing it. To try it out, simply run
-``./pypy-jvm``::
+ ./translate.py --backend=jvm targetpypystandalone.py
- $ ./pypy-jvm
- Python 2.5.2 (64214, Apr 17 2009, 08:11:23)
- [PyPy 1.1.0] on darwin
- Type "help", "copyright", "credits" or "license" for more information.
- And now for something completely different: ``# assert did not crash''
- >>>>
+ This will create a jar file ``pypy-jvm.jar`` as well as a convenience
+ script ``pypy-jvm`` for executing it. To try it out, simply run
+ ``./pypy-jvm``::
-Alternatively, you can run it using ``java -jar pypy-jvm.jar``. At the moment
-the executable does not provide any interesting features, like integration with
-Java.
+ $ ./pypy-jvm
+ Python 2.7.0 (61ef2a11b56a, Mar 02 2011, 03:00:11)
+ [PyPy 1.5.0-alpha0] on linux2
+ Type "help", "copyright", "credits" or "license" for more information.
+ And now for something completely different: ``# assert did not crash''
+ >>>>
+
+ Alternatively, you can run it using ``java -jar pypy-jvm.jar``. At the moment
+ the executable does not provide any interesting features, like integration with
+ Java.
Installation
++++++++++++
@@ -218,19 +219,19 @@
For installation purposes, note that the executable needs to be able to
find its version of the Python standard library in the following three
-directories: ``lib-python/2.5.2``, ``lib-python/modified-2.5.2`` and
+directories: ``lib-python/2.7``, ``lib-python/modified-2.7`` and
``lib_pypy``. They are located by "looking around" starting from the
directory in which the executable resides. The current logic is to try
to find a ``PREFIX`` from which the directories
-``PREFIX/lib-python/2.5.2`` and ``PREFIX/lib-python/modified.2.5.2`` and
+``PREFIX/lib-python/2.7`` and ``PREFIX/lib-python/modified.2.7`` and
``PREFIX/lib_pypy`` can all be found. The prefixes that are tried are::
.
- ./lib/pypy1.2
+ ./lib/pypy1.5
..
- ../lib/pypy1.2
+ ../lib/pypy1.5
../..
- ../../lib/pypy-1.2
+ ../../lib/pypy-1.5
../../..
etc.
@@ -240,22 +241,6 @@
most code will be fine. However, the ``sys.prefix`` will be unset
and some existing libraries assume that this is never the case.
-In order to use ``distutils`` or ``setuptools`` a directory ``PREFIX/site-packages`` needs to be created. Here's an example session setting up and using ``easy_install``::
-
- $ cd PREFIX
- $ mkdir site-packages
- $ curl -sO http://peak.telecommunity.com/dist/ez_setup.py
- $ bin/pypy-c ez_setup.py
- ...
- $ bin/easy_install WebOb
- $ bin/pypy-c
- Python 2.5.2 (64714, Apr 27 2009, 08:16:13)
- [PyPy 1.1.0] on linux2
- Type "help", "copyright", "credits" or "license" for more information.
- And now for something completely different: ``PyPy doesn't have copolyvariadic dependently-monomorphed hyperfluxads''
- >>>> import webob
- >>>>
-
.. _`py.py interpreter`:
Running the Python Interpreter Without Translation
@@ -265,7 +250,7 @@
+++++++++++++++++++++
To start interpreting Python with PyPy, install a C compiler that is
-supported by distutils and use Python 2.4 or greater to run PyPy::
+supported by distutils and use Python 2.5 or greater to run PyPy::
cd pypy
python bin/py.py
@@ -305,7 +290,7 @@
Alternatively, as with regular Python, you can simply give a
script name on the command line::
- python py.py ../../lib-python/2.5.2/test/pystone.py 10
+ python py.py ../../lib-python/2.7/test/pystone.py 10
See our `configuration sections`_ for details about what all the commandline
options do.
@@ -317,4 +302,4 @@
.. _clr: clr-module.html
.. _`CPythons core language regression tests`: http://codespeak.net:8099/summary?category=applevel&branch=%3Ctrunk%3E
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.noprofopt.rst b/pypy/doc/config/translation.noprofopt.rst
deleted file mode 100644
diff --git a/pypy/doc/discussion/ctypes_modules.rst b/pypy/doc/discussion/ctypes_modules.rst
deleted file mode 100644
--- a/pypy/doc/discussion/ctypes_modules.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-what is needed for various ctypes-based modules and how feasible they are
-==========================================================================
-
-Quick recap for module evaluation:
-
-1. does the module use callbacks?
-
-2. how sophisticated ctypes usage is (accessing of _objects?)
-
-3. any specific tricks
-
-4. does it have tests?
-
-5. dependencies
-
-6. does it depend on cpython c-api over ctypes?
-
-Pygame
-======
-
-1. yes, for various things, but basic functionality can be achieved without
-
-2. probably not
-
-3. not that I know of
-
-4. yes for tests, no for unittests
-
-5. numpy, but can live without, besides only C-level dependencies. On OS/X
- it requires PyObjC.
-
-6. no
-
-
-PyOpenGL
-========
-
-1. yes, for GLX, but not for the core functionality
-
-2. probably not
-
-3. all the code is auto-generated
-
-4. it has example programs, no tests
-
-5. numpy, but can live without it. can use various surfaces (including pygame) to draw on
-
-6. no
-
-
-Sqlite
-======
-
-1. yes, but I think it's not necessary
-
-2. no
-
-3. no
-
-4. yes
-
-5. datetime
-
-6. it passes py_object around in few places, not sure why (probably as an
- opaque argument).
diff --git a/pypy/doc/config/objspace.std.prebuiltintfrom.rst b/pypy/doc/config/objspace.std.prebuiltintfrom.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.prebuiltintfrom.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-see :config:`objspace.std.withprebuiltint`.
diff --git a/pypy/doc/config/translation.countmallocs.rst b/pypy/doc/config/translation.countmallocs.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.countmallocs.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Internal; used by some of the C backend tests to check that the number of
-allocations matches the number of frees.
-
-.. internal
diff --git a/pypy/doc/config/objspace.usemodules._io.rst b/pypy/doc/config/objspace.usemodules._io.txt
copy from pypy/doc/config/objspace.usemodules._io.rst
copy to pypy/doc/config/objspace.usemodules._io.txt
diff --git a/pypy/doc/config/translation.output.rst b/pypy/doc/config/translation.output.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.output.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Specify file name that the produced executable gets.
diff --git a/pypy/doc/config/objspace.usemodules._winreg.rst b/pypy/doc/config/objspace.usemodules._winreg.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._winreg.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the built-in '_winreg' module, provides access to the Windows registry.
-This module is expected to be working and is included by default on Windows.
diff --git a/pypy/doc/config/objspace.usemodules.clr.rst b/pypy/doc/config/objspace.usemodules.clr.txt
copy from pypy/doc/config/objspace.usemodules.clr.rst
copy to pypy/doc/config/objspace.usemodules.clr.txt
diff --git a/pypy/doc/config/translation.jit_ffi.rst b/pypy/doc/config/translation.jit_ffi.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.jit_ffi.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Internal option: enable OptFfiCall in the jit optimizations.
diff --git a/pypy/doc/config/objspace.usemodules._pickle_support.rst b/pypy/doc/config/objspace.usemodules._pickle_support.txt
copy from pypy/doc/config/objspace.usemodules._pickle_support.rst
copy to pypy/doc/config/objspace.usemodules._pickle_support.txt
diff --git a/pypy/doc/config/translation.verbose.rst b/pypy/doc/config/translation.verbose.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.verbose.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Print some more information during translation.
diff --git a/pypy/doc/config/translation.taggedpointers.rst b/pypy/doc/config/translation.taggedpointers.txt
copy from pypy/doc/config/translation.taggedpointers.rst
copy to pypy/doc/config/translation.taggedpointers.txt
diff --git a/pypy/doc/config/translation.compilerflags.rst b/pypy/doc/config/translation.compilerflags.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.compilerflags.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Experimental. Specify extra flags to pass to the C compiler.
diff --git a/pypy/doc/discussion/removing-stable-compiler.rst b/pypy/doc/discussion/removing-stable-compiler.rst
deleted file mode 100644
--- a/pypy/doc/discussion/removing-stable-compiler.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-February 28th, 2006
-
-While implementing conditional expressions from 2.5 we had to change
-the stable compiler in order to keep tests from breaking. While using
-stable compiler as a baseline made sense when the ast compiler was
-new, it is less and less true as new grammar changes are introduced.
-
-Options include
-
-1. Freezing the stable compiler at grammar 2.4.
-
-2. Capture AST output from the stable compiler and use that explicitly
-in current tests instead of regenerating them every time, primarily
-because it allows us to change the grammar without changing the stable
-compiler.
-
-
-In either case, AST production tests for new grammar changes could be
-written manually, which is less effort than fixing the stable
-compiler (which itself isn't really tested anyway).
-
-Discussion by Arre, Anders L., Stuart Williams
diff --git a/pypy/translator/cli/test/test_carbonpython.py b/pypy/translator/cli/test/test_carbonpython.py
deleted file mode 100644
--- a/pypy/translator/cli/test/test_carbonpython.py
+++ /dev/null
@@ -1,175 +0,0 @@
-import py
-py.test.skip("it passes usually, but fails on buildbot, no clue why")
-
-import os
-import os.path
-from pypy.tool import udir
-from pypy.translator.cli.rte import Target
-from pypy.translator.cli.carbonpython import DllDef, export, collect_entrypoints,\
- collect_class_entrypoints, compile_dll
-from pypy.translator.cli.test.runtest import CliFunctionWrapper, CliTest
-
-TEMPLATE = """
-using System;
-using System.Collections;
-class CarbonPytonTest {
- public static void Main() {
- %s
- }
-}
-"""
-
-class TestCarbonPython(CliTest):
-
- def _csharp(self, source, references=[], netmodules=[]):
- tmpfile = udir.udir.join('tmp.cs')
- tmpfile.write(TEMPLATE % source)
- flags = ['/r:%s' % ref for ref in references]
- flags += ['/addmodule:%s' % mod for mod in netmodules]
-
- class MyTarget(Target):
- SOURCES = [str(tmpfile)]
- FLAGS = flags
- OUTPUT = 'tmp.exe'
- SRC_DIR = str(udir.udir)
-
- func = CliFunctionWrapper(MyTarget.get())
- return func()
-
- def test_compilation(self):
- res = self._csharp('Console.WriteLine(42);')
- assert res == 42
-
- def test_func_namespace(self):
- def foo(x):
- return x+1
- def bar(x):
- return foo(x)
- foo._namespace_ = 'MyNamespace.MyClass'
- bar._namespace_ = 'MyClass'
- res = self.interpret(bar, [41], backendopt=False)
- assert res == 42
-
- def test_simple_functions(self):
- def foo(x):
- return x+1
- def bar(x):
- return x*2
- dll = DllDef('test', 'Test', [(foo, [int]),
- (bar, [int])])
- dll.compile()
- res = self._csharp('Console.WriteLine("{0}, {1}", Test.foo(42), Test.bar(42));', ['test'])
- assert res == (43, 84)
-
- def test_export(self):
- @export(int, float)
- def foo(x, y):
- pass
- @export(int, float, namespace='test')
- def bar(x, y):
- pass
- @export
- def baz():
- pass
-
- assert foo._inputtypes_ == (int, float)
- assert not hasattr(foo, '_namespace_')
- assert bar._inputtypes_ == (int, float)
- assert bar._namespace_ == 'test'
- assert baz._inputtypes_ == ()
-
- def test_collect_entrypoints(self):
- @export(int, float)
- def foo(x, y):
- pass
- def bar(x, y):
- pass
- mydict = dict(foo=foo, bar=bar, x=42)
- entrypoints = collect_entrypoints(mydict)
- assert entrypoints == [(foo, (int, float))]
-
- def test_collect_class_entrypoints(self):
- class NotExported:
- def __init__(self):
- pass
-
- class MyClass:
- @export
- def __init__(self):
- pass
- @export(int)
- def foo(self, x):
- return x
-
- assert collect_class_entrypoints(NotExported) == []
- entrypoints = collect_class_entrypoints(MyClass)
- assert len(entrypoints) == 2
- assert entrypoints[0][1] == () # __init__ inputtypes
- assert entrypoints[1][1] == (MyClass, int) # foo inputtypes
-
- def test_compile_class(self):
- py.test.skip('This test fails every other day. No clue why :-(')
- class MyClass:
- @export(int)
- def __init__(self, x):
- self.x = x
- @export(int, int)
- def add(self, y, z):
- return self.x + y + z
- MyClass.__module__ = 'Test' # put the class in the Test namespace
-
- entrypoints = collect_entrypoints({'MyClass': MyClass})
- dll = DllDef('test', 'Test', entrypoints)
- dll.compile()
- res = self._csharp("""
- Test.MyClass obj = new Test.MyClass();
- obj.__init__(39);
- Console.WriteLine(obj.add(1, 2));
- """, ['test'])
- assert res == 42
-
- def test_export_cliclass(self):
- py.test.skip('it fails every other day on builbot, no clue why')
- from pypy.translator.cli.dotnet import CLR
-
- @export(CLR.System.Collections.ArrayList, int)
- def getitem(obj, i):
- return obj.get_Item(i)
-
- entrypoints = collect_entrypoints({'getitem': getitem})
- dll = DllDef('test', 'Test', entrypoints)
- dll.compile()
- res = self._csharp("""
- ArrayList obj = new ArrayList();
- obj.Add(42);
- Console.WriteLine(Test.getitem(obj, 0));
- """, ['test'])
- assert res == 42
-
- def test_compile_dll(self):
- py.test.skip('This test fails every other day. No clue why :-(')
- cwd, _ = os.path.split(__file__)
- mylib_py = os.path.join(cwd, 'mylib.py')
- compile_dll(mylib_py, copy_dll=False)
- res = self._csharp("""
- Console.WriteLine(mylib.sum(20, 22));
- """, ['mylib'])
- assert res == 42
-
- def test_compile_dll_alternative_name(self):
- cwd, _ = os.path.split(__file__)
- mylib_py = os.path.join(cwd, 'mylib.py')
- compile_dll(mylib_py, 'mylibxxx.dll', copy_dll=False)
- res = self._csharp("""
- Console.WriteLine(mylibxxx.sum(20, 22));
- """, ['mylibxxx'])
- assert res == 42
-
- def test_compile_netmodule(self):
- def foo(x):
- return x+1
- dll = DllDef('mymodule', 'Test', [(foo, [int])], isnetmodule=True)
- dll.compile()
- res = self._csharp('Console.WriteLine("{0}", Test.foo(41));',
- netmodules = ['mymodule'])
-
diff --git a/pypy/doc/config/objspace.std.withsmallint.rst b/pypy/doc/config/objspace.std.withsmallint.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withsmallint.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-Use "tagged pointers" to represent small enough integer values: Integers that
-fit into 31 bits (respective 63 bits on 64 bit machines) are not represented by
-boxing them in an instance of ``W_IntObject``. Instead they are represented as a
-pointer having the lowest bit set and the rest of the bits used to store the
-value of the integer. This gives a small speedup for integer operations as well
-as better memory behaviour.
diff --git a/pypy/tool/rest/rst.py b/pypy/tool/rest/rst.py
--- a/pypy/tool/rest/rst.py
+++ b/pypy/tool/rest/rst.py
@@ -389,18 +389,14 @@
indent = ' '
def __init__(self, name, *args, **options):
self.name = name
- self.content = options.pop('content', [])
- children = list(args)
- super(Directive, self).__init__(*children)
+ self.content = args
+ super(Directive, self).__init__()
self.options = options
def text(self):
# XXX not very pretty...
- namechunksize = len(self.name) + 2
- self.children.insert(0, Text('X' * namechunksize))
- txt = super(Directive, self).text()
- txt = '.. %s::%s' % (self.name, txt[namechunksize + 3:],)
- options = '\n'.join([' :%s: %s' % (k, v) for (k, v) in
+ txt = '.. %s::' % (self.name,)
+ options = '\n'.join([' :%s: %s' % (k, v) for (k, v) in
self.options.iteritems()])
if options:
txt += '\n%s' % (options,)
@@ -408,10 +404,7 @@
if self.content:
txt += '\n'
for item in self.content:
- assert item.parentclass == Rest, 'only top-level items allowed'
- assert not item.indent
- item.indent = ' '
- txt += '\n' + item.text()
+ txt += '\n ' + item
return txt
diff --git a/pypy/doc/stackless.rst b/pypy/doc/stackless.rst
--- a/pypy/doc/stackless.rst
+++ b/pypy/doc/stackless.rst
@@ -7,10 +7,6 @@
Introduction
================
-.. include:: crufty.rst
-
- .. apparently this still works; needs JIT integration; hasn't been maintained for years
-
PyPy can expose to its user language features similar to the ones
present in `Stackless Python`_: **no recursion depth limit**, and the
ability to write code in a **massively concurrent style**. It actually
@@ -142,6 +138,11 @@
will come from any call to ``coro.switch()`` and can be caught. If the
exception isn't caught, it will be propagated to the parent coroutine.
+When a coroutine is garbage-collected, it gets the ``.kill()`` method sent to
+it. This happens at the point the next ``.switch`` method is called, so the
+target coroutine of this call will be executed only after the ``.kill`` has
+finished.
+
Example
~~~~~~~
@@ -430,32 +431,6 @@
These cases are not supported yet.
-Coroutine Cloning
-+++++++++++++++++
-
-In theory, coroutine pickling is general enough to allow coroutines to
-be *cloned* within a process; i.e. from one suspended coroutine, a copy
-can be made - simply by pickling and immediately unpickling it. Both
-the original and the copy can then continue execution from the same
-point on. Cloning gives much of the expressive power of full
-*continuations*.
-
-However, pickling has several problems in practice (besides a relatively
-high overhead). It is not a completely general solution because not all
-kinds of objects can be pickled; moreover, which objects are pickled by
-value or by reference only depends on the type of the object. For the
-purpose of cloning, this means that coroutines cannot be
-pickled/unpickled in all situations, and even when they can, the user
-does not have full control over which of the objects currently reachable
-from a coroutine will be duplicated, and which will be shared with the
-original coroutine.
-
-For this reason, we implemented a direct cloning operation. It has been
-deprecated for some time, however, as it was slightly buggy and relied
-on a specific (and deprecated) garbage collector. It is not available
-out of the box right now, so we will not talk any more about this.
-
-
Composability
+++++++++++++
@@ -622,7 +597,7 @@
.. _`Stackless Python`: http://www.stackless.com
-.. _`documentation of the greenlets`: http://codespeak.net/svn/greenlet/trunk/doc/greenlet.txt
+.. _`documentation of the greenlets`: http://packages.python.org/greenlet/
.. _`Stackless Transform`: translation.html#the-stackless-transform
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/translation.sandbox.rst b/pypy/doc/config/translation.sandbox.txt
copy from pypy/doc/config/translation.sandbox.rst
copy to pypy/doc/config/translation.sandbox.txt
diff --git a/pypy/doc/sprint-reports.rst b/pypy/doc/sprint-reports.rst
--- a/pypy/doc/sprint-reports.rst
+++ b/pypy/doc/sprint-reports.rst
@@ -78,6 +78,4 @@
.. _`CERN (July 2010)`: http://morepypy.blogspot.com/2010/07/cern-sprint-report-wrapping-c-libraries.html
.. _`Düsseldorf (October 2010)`: http://morepypy.blogspot.com/2010/10/dusseldorf-sprint-report-2010.html
-Further event notes:
-* :ref:`eventhistory.rst`
diff --git a/pypy/doc/config/translation.gctransformer.rst b/pypy/doc/config/translation.gctransformer.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.gctransformer.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-internal option
diff --git a/pypy/doc/low-level-encapsulation.rst b/pypy/doc/low-level-encapsulation.rst
deleted file mode 100644
--- a/pypy/doc/low-level-encapsulation.rst
+++ /dev/null
@@ -1,343 +0,0 @@
-============================================================
- Encapsulating low-level implementation aspects
-============================================================
-
-.. contents::
-
-
-
-Abstract
-========
-
-It has always been a major goal of PyPy to not force implementation
-decisions. This means that even after the implementation of the
-standard interpreter [#]_ has been written we are still able to experiment
-with different approaches to memory management or concurrency and to
-target wildly different platforms such as the Java Virtual Machine or
-a very memory-limited embedded environment.
-
-We do this by allowing the encapsulation of these low level aspects as
-well defined parts of the translation process.
-
-In the following document, we give examples of aspects that have been
-successfully encapsulated in more detail and contrast the potential of
-our approach with CPython.
-
-.. [#] `standard interpreter`_ is our term for the code which
- implements the Python language, i.e. the interpreter and the
- standard object space.
-
-
-Background
-==========
-
-One of the better known significant modifications to CPython are
-Christian Tismer's "stackless" patches [STK]_, which allow for far more
-flexible control flow than the typical function call/return supported by
-CPython. Originally implemented as a series of invasive patches,
-Christian found that maintaining these patches as CPython itself was
-further developed was time consuming to the point of no longer being
-able to work on the new functionality that was the point of the
-exercise.
-
-One solution would have been for the patches to become part of core
-CPython but this was not done partly because the code that fully
-enabled stackless required widespread modifications that made the code
-harder to understand (as the "stackless" model contains control flow
-that is not easily expressable in C, the implementation became much
-less "natural" in some sense).
-
-With PyPy, however, it is possible to obtain this flexible control
-flow whilst retaining transparent implementation code as the necessary
-modifications can be implemented as a localized translation aspect,
-and indeed this was done at the Paris sprint in a couple of days (as
-compared to around six months for the original stackless patches).
-
-Of course, this is not the only aspect that can be so decided a
-posteriori, during translation.
-
-
-Translation aspects
-===================
-
-Our standard interpreter is implemented at a very high level of
-abstraction. This has a number of happy consequences, among which is
-enabling the encapsulation of language aspects as described in this
-document. For example, the implementation code simply makes no
-reference to memory management, which clearly gives the translator
-complete freedom to decide about this aspect. This contrasts with
-CPython where the decision to use reference counting is reflected tens
-or even hundreds of times in each C source file in the codebase.
-
-As described in [ARCH]_, producing a Python implementation from the
-source of our standard interpreter involves various stages: the
-initialization code is run, the resulting code is annotated, typed and
-finally translated. By the nature of the task, the encapsulation of
-*low-level aspects* mainly affects the typer and the translation
-process. At the coarsest level, the selection of target platform
-involves writing a new backend -- still a significant task, but much
-much easier than writing a complete implementation of Python!
-
-Other aspects affect different levels, as their needs require. The
-remainder of this section describes a few aspects that we have
-successfully encapsulated.
-
-An advantage of our approach is that any combination of aspects can be
-freely selected, avoiding the problem of combinatorial explosion of
-variants seen in manually written interpreters.
-
-
-Stacklessness
--------------
-
-The stackless modifications are mostly implemented in the C backend,
-with a single extra flow graph operation to influence some details of
-the generated C code. The total changes only required about 300 lines
-of source, vindicating our abstract approach.
-
-In stackless mode, the C backend generates functions that are
-systematically extended with a small amount of bookkeeping code. This
-allows the C code to save its own stack to the heap on demand, where it
-can then be inspected, manipulated and eventually resumed. This is
-described in more detail in [TA]_. In this way, unlimited (or more
-precisely heap-limited) recursion is possible, even on operating systems
-that limit the size of the C stack. Alternatively, a different saved
-stack can be resumed, thus implementing soft context switches -
-coroutines, or green threads with an appropriate scheduler. We reobtain
-in this way all the major benefits of the original "stackless" patches.
-
-This effect requires a number of changes in each and every C function
-that would be extremely tedious to write by hand: checking for the
-signal triggering the saving of the stack, actually saving precisely the
-currently active local variables, and when re-entering the function
-check which variables are being restored and which call site is resumed.
-In addition, a couple of global tables must be maintained to drive the
-process. The key point is that we can fine-tune all these interactions
-freely, without having to rewrite the whole code all the time but only
-modifying the C backend (in addition, of course, to being able to change
-at any time the high-level code that is the input of the translation
-process). So far, this allowed us to find a style that does not hinder
-the optimizations performed by the C compiler and so has only a minor
-impact on performance in the normal case.
-
-Also note that the fact that the C stack can be fully saved into the
-heap can tremendously simplify the portable implementation of garbage
-collection: after the stack has been completely transferred to the heap,
-there are no roots left on the stack.
-
-
-Multiple Interpreters
----------------------
-
-Another implementation detail that causes tension between functionality
-and both code clarity and memory consumption in CPython is the issue of
-multiple independent interpreters in the same process. In CPython there
-is a partial implementation of this idea in the "interpreter state" API,
-but the interpreters produced by this are not truly independent -- for
-instance the dictionary that contains interned strings is implemented as
-file-level static object, and is thus shared between the interpreters.
-A full implementation of this idea would entirely eschew the use of file
-level statics and place all interpreter-global data in some large
-structure, which would hamper readability and maintainability. In
-addition, in many situations it is necessary to determine which
-interpreter a given object is "from" -- and this is not possible in
-CPython largely because of the memory overhead that adding a 'interp'
-pointer to all Python objects would create.
-
-In PyPy, all of our implementation code manipulates an explicit object
-space instance, as described in [CODG]_. The situation of multiple
-interpreters is thus handled automatically: if there is only one space
-instance, it is regarded as a pre-constructed constant and the space
-object pointer (though not its non-constant contents) disappears from
-the produced source, i.e. from function arguments, local variables and
-instance fields. If there are two or more such instances, a 'space'
-attribute will be automatically added to all application objects (or
-more precisely, it will not be removed by the translation process), the
-best of both worlds.
-
-
-Memory Management
------------------
-
-As mentioned above, CPython's decision to use a garbage collector based
-on reference counting is reflected throughout its source. In the
-implementation code of PyPy, it is not, and in fact the standard
-interpreter can currently be compiled to use a reference counted scheme
-or the Boehm GC [BOEHM]_. Again, more details are in [TA]_. We also
-have an experimental framework for developing custom exact GCs [GC]_,
-but it is not yet integrated with the low-level translation back-ends.
-
-Another advantage of the aspect oriented approach shows itself most
-clearly with this memory management aspect: that of correctness.
-Although reference counting is a fairly simple scheme, writing code for
-CPython requires that the programmer make a large number of
-not-quite-trivial decisions about the refcounting code. Experience
-suggests that mistakes will always creep in, leading to crashes or
-leaks. While tools exist to help find these mistakes, it is surely
-better to not write the reference count manipulations at all and this is
-what PyPy's approach allows. Writing the code that emits the correct
-reference count manipulations is surely harder than writing any one
-piece of explicit refcounting code, but once it is done and tested, it
-just works without further effort.
-
-
-Concurrency
------------
-
-The aspect of CPython's implementation that has probably caused more
-discussion than any other mentioned here is that of the threading
-model. Python has supported threads since version 1.5 with what is
-commonly referred to as the "Global Interpreter Lock" or GIL; the
-execution of bytecodes is serialized such that only one thread can be
-executing Python code at one time. This has the benefit of being
-relatively unintrusive and not too complex, but has the disadvantage
-that multi-threaded, computation-bound Python code does not gain
-performance on multi-processor machines.
-
-PyPy will offer the opportunity to experiment with different models,
-although currently we only offer a version with no thread support and
-another with a GIL-like model [TA]_. (We also plan to support soon
-"green" software-only threads in the Stackless model described above,
-but obviously this would not solve the multi-processor scalability
-issue.)
-
-The future work in this direction is to collect the numerous possible
-approaches that have between thought out along the years and
-e.g. presented on the CPython development mailing list. Most of them
-have never been tried out in CPython, for lack of necessary resources.
-A number of them are clearly easy to try out in PyPy, at least in an
-experimental version that would allow its costs to be assessed -- for
-example, various forms of object-level locking.
-
-
-Evaluation Strategy
--------------------
-
-Possibly the most radical aspect to tinker with is the evaluation
-strategy. The thunk object space [OBJS]_ wraps the standard object
-space to allow the production of "lazily computed objects", i.e. objects
-whose values are only calculated when needed. It also allows global and
-total replacement of one object with another.
-
-The thunk object space is mostly meant as an example of what our
-approach can achieve -- the combination of side-effects and lazy
-evaluation is not easy to understand. This demonstration is important
-because this level of flexibility will be required to implement future
-features along the lines of Prolog-style logic variables, transparent
-persistency, object distribution across several machines, or
-object-level security.
-
-
-Experimental results
-====================
-
-All the aspects described in the previous chapter have been successfully
-implemented and are available since the release 0.7 or 0.8 of PyPy.
-
-We have conducted preliminary experimental measures of the performance
-impact of enabling each of these features in the compiled PyPy
-interpreter. We present below the current results as of October 2005.
-Most figures appear to vary from machine to machine. Given that the
-generated code is large (it produce a binary of 5.6MB on a Linux
-Pentium), there might be locality and code ordering issues that cause
-important cache effects.
-
-We have not particularly optimized any of these aspects yet. Our goal
-is primarily to prove that the whole approach is worthwhile, and rely on
-future work and push for external contributions to implement
-state-of-the-art techniques in each of these domains.
-
-Stacklessness
-
- Producing Stackless-style C code means that all the functions of the
- PyPy interpreter that can be involved in recursions contain stack
- bookkeeping code (leaf functions, functions calling only leaves,
- etc. do not need to use this style). The current performance impact
- is to make PyPy slower by about 8%. A couple of minor pending
- optimizations could reduce this figure a bit. We expect the rest of
- the performance impact to be mainly caused by the increase of size
- of the generated executable (+28%).
-
-Multiple Interpreters
-
- A binary that allowed selection between two copies of the standard
- object space with a command line switch was about 10% slower and
- about 40% larger than the default. Most of the extra size is
- likely accounted for by the duplication of the large amount of
- prebuilt data involved in an instance of the standard object
- space.
-
-Memory Management
-
- The [Boehm] GC is well-optimized and produces excellent results. By
- comparison, using reference counting instead makes the interpreter
- twice as slow. This is almost certainly due to the naive approach
- to reference counting used so far, which updates the counter far
- more often than strictly necessary; we also still have a lot of
- objects that would theoretically not need a reference counter,
- either because they are short-lived or because we can prove that
- they are "owned" by another object and can share its lifetime. In
- the long run, it will be interesting to see how far this figure can
- be reduced, given past experiences with CPython which seem to show
- that reference counting is a viable idea for Python interpreters.
-
-Concurrency
-
- No experimental data available so far. Just enabling threads
- currently creates an overhead that hides the real costs of locking.
-
-Evaluation Strategy
-
- When translated to C code, the Thunk object space has a global
- performance impact of 6%. The executable is 13% bigger (probably
- due to the arguably excessive inlining we perform).
-
-We have described five aspects in this document, each currently with
-two implementation choices, leading to 32 possible translations. We
-have not measured the performance of each variant, but the few we have
-tried suggests that the performance impacts are what one would expect,
-e.g. a translated stackless binary using the thunk object space would
-be expected to be about 1.06 x 1.08 ~= 1.14 times slower than the
-default and was found to be 1.15 times slower.
-
-
-Conclusion
-==========
-
-Although still a work in progress, we believe that the successes we
-have had in encapsulating implementation aspects justifies the
-approach we have taken. In particular, the relative ease of
-implementing the translation aspects described in this paper -- as
-mentioned above, the stackless modifications took only a few days --
-means we are confident that it will be easily possible to encapsulate
-implementation aspects we have not yet considered.
-
-
-References
-==========
-
-.. [ARCH] `Architecture Overview`_, PyPy documentation, 2003-2005
-
-.. [BOEHM] `Boehm-Demers-Weiser garbage collector`_, a garbage collector
- for C and C++, Hans Boehm, 1988-2004
-
-.. [CODG] `Coding Guide`_, PyPy documentation, 2003-2005
-
-.. [GC] `Garbage Collection`_, PyPy documentation, 2005
-
-.. [OBJS] `Object Spaces`_, PyPy documentation, 2003-2005
-
-.. [STK] `Stackless Python`_, a Python implementation that does not use
- the C stack, Christian Tismer, 1999-2004
-
-.. [TA] `Memory management and threading models as translation aspects`_,
- PyPy documentation (and EU Deliverable D05.3), 2005
-
-.. _`standard interpreter`: architecture.html#standard-interpreter
-.. _`Architecture Overview`: architecture.html
-.. _`Coding Guide`: coding-guide.html
-.. _`Garbage Collection`: garbage_collection.html
-.. _`Object Spaces`: objspace.html
-.. _`Stackless Python`: http://www.stackless.com
-.. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
-.. _`Memory management and threading models as translation aspects`: translation-aspects.html
diff --git a/pypy/doc/config/objspace.usemodules.binascii.rst b/pypy/doc/config/objspace.usemodules.binascii.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.binascii.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the RPython 'binascii' module.
diff --git a/pypy/doc/ctypes-implementation.rst b/pypy/doc/ctypes-implementation.rst
--- a/pypy/doc/ctypes-implementation.rst
+++ b/pypy/doc/ctypes-implementation.rst
@@ -1,5 +1,3 @@
-.. include:: crufty.rst
-
=============================
PyPy's ctypes implementation
=============================
@@ -71,8 +69,6 @@
interface require more object allocations and copying than strictly
necessary; this too could be improved.
-The implementation was developed and has only been tested on x86-32 Linux.
-
Here is a list of the limitations and missing features of the
current implementation:
@@ -94,53 +90,15 @@
between its primitive types and user subclasses
of its primitive types
-Getting the code and test suites
-=================================
-
-A stable revision of PyPy containing the ctypes implementation can be checked out with subversion from the tag:
-
-http://codespeak.net/svn/pypy/tag/ctypes-stable
-
-The various tests and later examples can be run on x86-32 Linux. We tried them
-on an up-to-date Ubuntu 7.10 x86-32 system.
-
-If one goes inside the checkout it is possible to run ``_rawffi`` tests with::
-
- $ cd pypy
- $ python test_all.py module/_rawffi/
-
-The ctypes implementation test suite is derived from the tests for
-ctypes 1.0.2, we have skipped some tests corresponding to not
-implemented features or implementation details, we have also added
-some tests.
-
-To run the test suite a compiled pypy-c is required with the proper configuration. To build the required pypy-c one should inside the checkout::
-
- $ cd pypy/translator/goal
- $ ./translate.py --text --batch --gc=generation targetpypystandalone.py
- --withmod-_rawffi --allworkingmodules
-
-this should produce a pypy-c executable in the ``goal`` directory.
-
-To run the tests then::
-
- $ cd ../../.. # back to pypy-trunk
- $ ./pypy/translator/goal/pypy-c pypy/test_all.py lib/pypy1.2/lib_pypy/pypy_test/ctypes_tests
-
-There should be 36 skipped tests and all other tests should pass.
-
Running application examples
==============================
-`pyglet`_ is known to run. We had some success also with pygame-ctypes which is not maintained anymore and with a snapshot of the experimental pysqlite-ctypes. We will only describe how to run the pyglet examples.
+`pyglet`_ is known to run. We also had some success with pygame-ctypes (which is no longer maintained) and with a snapshot of the experimental pysqlite-ctypes. We will only describe how to run the pyglet examples.
pyglet
-------
We tried pyglet checking it out from its repository at revision 1984.
-For convenience a tarball of the checkout can also be found at:
-
-http://codespeak.net/~pedronis/pyglet-r1984.tgz
From pyglet, the following examples are known to work:
diff --git a/pypy/doc/rffi.rst b/pypy/doc/rffi.rst
--- a/pypy/doc/rffi.rst
+++ b/pypy/doc/rffi.rst
@@ -43,7 +43,7 @@
See cbuild_ for more info on ExternalCompilationInfo.
.. _`low level types`: rtyper.html#low-level-type
-.. _cbuild: http://codespeak.net/svn/pypy/trunk/pypy/translator/tool/cbuild.py
+.. _cbuild: https://bitbucket.org/pypy/pypy/src/tip/pypy/translator/tool/cbuild.py
Types
@@ -56,7 +56,7 @@
flavor='raw'. There are several helpers like string -> char*
converter, refer to the source for details.
-.. _rffi: http://codespeak.net/svn/pypy/trunk/pypy/rpython/lltypesystem/rffi.py
+.. _rffi: https://bitbucket.org/pypy/pypy/src/tip/pypy/rpython/lltypesystem/rffi.py
Registering function as external
---------------------------------
@@ -68,7 +68,7 @@
functions, passing llimpl as an argument and eventually llfakeimpl
as a fake low-level implementation for tests performed by an llinterp.
-.. _`extfunc.py`: http://codespeak.net/svn/pypy/trunk/pypy/rpython/extfunc.py
+.. _`extfunc.py`: https://bitbucket.org/pypy/pypy/src/tip/pypy/rpython/extfunc.py
OO backends
diff --git a/pypy/doc/config/objspace.usemodules.zlib.rst b/pypy/doc/config/objspace.usemodules.zlib.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.zlib.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'zlib' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/commandline.rst b/pypy/doc/config/commandline.rst
deleted file mode 100644
--- a/pypy/doc/config/commandline.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-
-.. contents::
-
-
-.. _objspace:
-.. _`overview-of-command-line-options-for-objspace`:
-
--------------------------------
-PyPy Python interpreter options
--------------------------------
-
-The following options can be used after ``translate.py
-targetpypystandalone`` or as options to ``py.py``.
-
-.. GENERATE: objspace
-
-
-.. _translation:
-.. _`overview-of-command-line-options-for-translation`:
-
----------------------------
-General translation options
----------------------------
-
-The following are options of ``translate.py``. They must be
-given before the ``targetxxx`` on the command line.
-
-* `--opt -O:`__ set the optimization level `[0, 1, size, mem, 2, 3]`
-
-.. __: opt.html
-
-.. GENERATE: translation
-
diff --git a/pypy/doc/config/objspace.std.rst b/pypy/doc/config/objspace.std.txt
copy from pypy/doc/config/objspace.std.rst
copy to pypy/doc/config/objspace.std.txt
diff --git a/pypy/doc/config/objspace.usemodules.micronumpy.rst b/pypy/doc/config/objspace.usemodules.micronumpy.txt
copy from pypy/doc/config/objspace.usemodules.micronumpy.rst
copy to pypy/doc/config/objspace.usemodules.micronumpy.txt
diff --git a/pypy/doc/config/objspace.usemodules.thread.rst b/pypy/doc/config/objspace.usemodules.thread.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.thread.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the 'thread' module.
diff --git a/pypy/doc/config/objspace.usemodules.mmap.rst b/pypy/doc/config/objspace.usemodules.mmap.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.mmap.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'mmap' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/objspace.rst b/pypy/doc/objspace.rst
--- a/pypy/doc/objspace.rst
+++ b/pypy/doc/objspace.rst
@@ -56,7 +56,7 @@
The present document gives a description of the above object spaces.
The sources of PyPy contain the various object spaces in the directory
-`objspace/`_.
+`pypy/objspace/`_.
To choose which object space to use, use the :config:`objspace.name` option.
@@ -297,7 +297,7 @@
Introduction
------------
-The Standard Object Space (StdObjSpace_) is the direct equivalent of CPython's
+The Standard Object Space (`pypy/objspace/std/`_) is the direct equivalent of CPython's
object library (the "Objects/" subdirectory in the distribution). It is an
implementation of the common Python types in a lower-level language.
@@ -341,13 +341,11 @@
using plain integers instead is the complex path, not the other way
around.
-.. _StdObjSpace: ../../../../pypy/objspace/std/
-
Object types
------------
-The larger part of the `StdObjSpace`_ package defines and implements the
+The larger part of the `pypy/objspace/std/`_ package defines and implements the
library of Python's standard built-in object types. Each type (int, float,
list, tuple, str, type, etc.) is typically implemented by two modules:
@@ -356,17 +354,17 @@
* the *implementation* module, called ``xxxobject.py``.
The ``xxxtype.py`` module basically defines the type object itself. For
-example, `listtype.py`_ contains the specification of the object you get when
-you type ``list`` in a PyPy prompt. `listtype.py`_ enumerates the methods
+example, `pypy/objspace/std/listtype.py`_ contains the specification of the object you get when
+you type ``list`` in a PyPy prompt. `pypy/objspace/std/listtype.py`_ enumerates the methods
specific to lists, like ``append()``.
A particular method implemented by all types is the ``__new__()`` special
method, which in Python's new-style-classes world is responsible for creating
an instance of the type. In PyPy, ``__new__()`` locates and imports the module
implementing *instances* of the type, and creates such an instance based on the
-arguments the user supplied to the constructor. For example, `tupletype.py`_
+arguments the user supplied to the constructor. For example, `pypy/objspace/std/tupletype.py`_
defines ``__new__()`` to import the class ``W_TupleObject`` from
-`tupleobject.py`_ and instantiate it. The `tupleobject.py`_ then contains a
+`pypy/objspace/std/tupleobject.py`_ and instantiate it. The `pypy/objspace/std/tupleobject.py`_ then contains a
"real" implementation of tuples: the way the data is stored in the
``W_TupleObject`` class, how the operations work, etc.
@@ -387,18 +385,13 @@
same Python type. PyPy knows that (e.g.) the application-level type of
its interpreter-level ``W_StringObject`` instances is str because
there is a ``typedef`` class attribute in ``W_StringObject`` which
-points back to the string type specification from `stringtype.py`_; all
+points back to the string type specification from `pypy/objspace/std/stringtype.py`_; all
other implementations of strings use the same ``typedef`` from
-`stringtype.py`_.
+`pypy/objspace/std/stringtype.py`_.
For other examples of multiple implementations of the same Python type,
see `Standard Interpreter Optimizations`_.
-.. _`listtype.py`: ../../../../pypy/objspace/std/listtype.py
-.. _`stringtype.py`: ../../../../pypy/objspace/std/stringtype.py
-.. _`tupletype.py`: ../../../../pypy/objspace/std/tupletype.py
-.. _`tupleobject.py`: ../../../../pypy/objspace/std/tupleobject.py
-
.. _`Standard Interpreter Optimizations`: interpreter-optimizations.html
@@ -408,12 +401,10 @@
The Standard Object Space allows multiple object implementations per
Python type - this is based on multimethods_. For a description of the
multimethod variant that we implemented and which features it supports,
-see the comment at the start of the source__. However, multimethods
+see the comment at the start of `pypy/objspace/std/multimethod.py`_. However, multimethods
alone are not enough for the Standard Object Space: the complete picture
spans several levels in order to emulate the exact Python semantics.
-.. __: ../../../../pypy/objspace/std/multimethod.py
-
Consider the example of the ``space.getitem(w_a, w_b)`` operation,
corresponding to the application-level syntax ``a[b]``. The Standard
Object Space contains a corresponding ``getitem`` multimethod and a
@@ -469,7 +460,7 @@
resulting pair of basic strings. This is similar to the C++ method
overloading resolution mechanism (but occurs at runtime).
-.. _multimethods: theory.html#multimethods
+.. _multimethods: http://en.wikipedia.org/wiki/Multimethods
Multimethod slicing
@@ -552,13 +543,11 @@
operations are usually shown.
A quick introduction on how to use the trace object space can be `found here`_.
-A number of options for configuration is here in `traceconfig.py`_.
+A number of options for configuration is here in `pypy/tool/traceconfig.py`_.
.. _`found here` : getting-started-dev.html#tracing-bytecode-and-operations-on-objects
-.. _`Abstract Interpretation`: theory.html#abstract-interpretation
-.. _`traceconfig.py`: ../tool/traceconfig.py
-
+.. _`Abstract Interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
.. _`Flow Object Space`:
@@ -568,7 +557,7 @@
Introduction
------------
-The task of the FlowObjSpace_ is to generate a control-flow graph from a
+The task of the FlowObjSpace (the source is at `pypy/objspace/flow/`_) is to generate a control-flow graph from a
function. This graph will also contain a trace of the individual operations, so
that it is actually just an alternate representation for the function.
@@ -588,7 +577,7 @@
appear in some next operation. This technique is an example of `Abstract
Interpretation`_.
-.. _`Abstract Interpretation`: theory.html#abstract-interpretation
+.. _`Abstract Interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
For example, if the placeholder ``v1`` is given as the argument to the above
function, the bytecode interpreter will call ``v2 = space.mul(space.wrap(3),
@@ -600,8 +589,6 @@
v3 = add(v2, Constant(2))
-.. _FlowObjSpace: ../../../../pypy/objspace/flow/
-
The Flow model
--------------
@@ -650,4 +637,4 @@
.. _`What PyPy can do for your objects`: objspace-proxies.html
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.std.withstrbuf.rst b/pypy/doc/config/objspace.std.withstrbuf.txt
copy from pypy/doc/config/objspace.std.withstrbuf.rst
copy to pypy/doc/config/objspace.std.withstrbuf.txt
diff --git a/pypy/doc/discussion/outline-external-ootype.rst b/pypy/doc/discussion/outline-external-ootype.rst
--- a/pypy/doc/discussion/outline-external-ootype.rst
+++ b/pypy/doc/discussion/outline-external-ootype.rst
@@ -1,22 +1,10 @@
Some discussion about external objects in ootype
================================================
-Current approaches:
-
-* BasicExternal, used for js backend
+Current approach:
* SomeCliXxx for .NET backend
-BasicExternal
--------------
-
-* Is using types to make rpython happy (ie, every single method or field
- is hardcoded)
-
-* Supports callbacks by SomeGenericCallable
-
-* Supports fields, also with callable fields
-
SomeCliXxx
----------
@@ -26,11 +14,11 @@
* Supports static methods
-Would be extremely cool to have just one approach instead of two,
-so here are some notes:
+Would be extremely cool to generalize the approach to be useful also for the
+JVM backend. Here are some notes:
* There should be one mechanism, factored out nicely out of any backend,
- to support any possible backend (cli, js, jvm for now).
+ to support any possible backend (cli, jvm for now).
* This approach might be eventually extended by a backend itself, but
as much as possible code should be factored out.
@@ -46,24 +34,22 @@
================================
The goal of the task is to let RPython program access "external
-objects" which are available in the target platform; these include:
+entities" which are available in the target platform; these include:
- external classes (e.g. for .NET: System.Collections.ArrayList)
- - external instances (e.g. for js: window, window.document)
+ - external prebuilt instances (e.g. for .NET: typeof(System.Console))
- - external functions? (they are not needed for .NET and JVM, maybe
- for js?)
-
-External objects should behave as much as possible as "internal
-objects".
+External entities should behave as much as possible as "internal
+entities".
Moreover, we want to preserve the possibility of *testing* RPython
programs on top of CPython if possible. For example, it should be
possible to RPython programs using .NET external objects using
-PythonNet; probably there is something similar for JVM, but not for
-JS as I know.
+PythonNet; for JVM, there are JPype_ and JTool_, to be investigated:
+.. _JPype: http://jpype.sourceforge.net/
+.. _JTool: http://wiki.europython.eu/Talks/Jtool%20Java%20In%20The%20Python%20Vm
How to represent types
----------------------
@@ -124,11 +110,6 @@
and JVM the job can be easily automatized, since the objects have got
precise signatures.
-For JS, signatures must be written by hand, so we must provide a
-convenient syntax for it; I think it should be possible to use the
-current syntax and write a tool which translates it to low-level
-types.
-
RPython interface
-----------------
@@ -146,9 +127,8 @@
- access to static methods: return an object which will be annotated
as SomeExternalStaticMeth.
-Instances are annotated as SomeExternalInstance. Prebuilt external
-objects (such as JS's window.document) are annotated as
-SomeExternalInstance(const=...).
+Instances are annotated as SomeExternalInstance. Prebuilt external objects are
+annotated as SomeExternalInstance(const=...).
Open issues
-----------
@@ -179,18 +159,12 @@
It would be nice to allow programmers to inherit from an external
class. Not sure about the implications, though.
-Callbacks
-~~~~~~~~~
-
-I know that they are an issue for JS, but I don't know how they are
-currently implemented.
-
Special methods/properties
~~~~~~~~~~~~~~~~~~~~~~~~~~
In .NET there are special methods that can be accessed using a special
syntax, for example indexer or properties. It would be nice to have in
-RPython the same syntax as C#.
+RPython the same syntax as C#, although we can live without that.
Implementation details
diff --git a/pypy/doc/config/translation.backendopt.rst b/pypy/doc/config/translation.backendopt.txt
copy from pypy/doc/config/translation.backendopt.rst
copy to pypy/doc/config/translation.backendopt.txt
diff --git a/pypy/doc/config/objspace.std.withmethodcachecounter.rst b/pypy/doc/config/objspace.std.withmethodcachecounter.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withmethodcachecounter.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Testing/debug option for :config:`objspace.std.withmethodcache`.
diff --git a/pypy/doc/extradoc.rst b/pypy/doc/extradoc.rst
--- a/pypy/doc/extradoc.rst
+++ b/pypy/doc/extradoc.rst
@@ -64,21 +64,21 @@
for Python`_, A. Rigo
-.. _bibtex: http://codespeak.net/svn/pypy/extradoc/talk/bibtex.bib
+.. _bibtex: https://bitbucket.org/pypy/extradoc/raw/tip/talk/bibtex.bib
.. _`Allocation Removal by Partial Evaluation in a Tracing JIT`: http://codespeak.net/svn/pypy/extradoc/talk/pepm2011/bolz-allocation-removal.pdf
.. _`Towards a Jitting VM for Prolog Execution`: http://www.stups.uni-duesseldorf.de/publications/bolz-prolog-jit.pdf
.. _`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
-.. _`Automatic JIT Compiler Generation with Runtime Partial Evaluation`: http://codespeak.net/svn/user/cfbolz/jitpl/thesis/final-master.pdf
+.. _`How to *not* write Virtual Machines for Dynamic Languages`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dyla2007/dyla.pdf
+.. _`Tracing the Meta-Level: PyPy's Tracing JIT Compiler`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/icooolps2009/bolz-tracing-jit.pdf
+.. _`Faster than C#: Efficient Implementation of Dynamic Languages on .NET`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/icooolps2009-dotnet/cli-jit.pdf
+.. _`Automatic JIT Compiler Generation with Runtime Partial Evaluation`: http://www.stups.uni-duesseldorf.de/thesis/final-master.pdf
.. _`RPython: A Step towards Reconciling Dynamically and Statically Typed OO Languages`: http://www.disi.unige.it/person/AnconaD/papers/Recent_abstracts.html#AACM-DLS07
.. _`EU Reports`: index-report.html
-.. _`PyGirl: Generating Whole-System VMs from High-Level Prototypes using PyPy`: http://www.iam.unibe.ch/~verwaest/pygirl.pdf
+.. _`PyGirl: Generating Whole-System VMs from High-Level Prototypes using PyPy`: http://scg.unibe.ch/archive/papers/Brun09cPyGirl.pdf
.. _`Representation-Based Just-in-Time Specialization and the Psyco Prototype for Python`: http://psyco.sourceforge.net/psyco-pepm-a.ps.gz
.. _`Back to the Future in One Week -- Implementing a Smalltalk VM in PyPy`: http://dx.doi.org/10.1007/978-3-540-89275-5_7
-.. _`Automatic generation of JIT compilers for dynamic languages in .NET`: http://codespeak.net/svn/pypy/extradoc/talk/ecoop2009/main.pdf
-.. _`Core Object Optimization Results`: http://codespeak.net/svn/pypy/extradoc/eu-report/D06.1_Core_Optimizations-2007-04-30.pdf
+.. _`Automatic generation of JIT compilers for dynamic languages in .NET`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ecoop2009/main.pdf
+.. _`Core Object Optimization Results`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D06.1_Core_Optimizations-2007-04-30.pdf
.. _`Compiling Dynamic Language Implementations`: http://codespeak.net/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
@@ -131,7 +131,7 @@
* `PyCon 2008`_.
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/s3-2008/talk.pdf
+.. __: https://bitbucket.org/pypy/extradoc/raw/tip/talk/s3-2008/talk.pdf
Talks in 2007
@@ -166,9 +166,9 @@
* `Warsaw 2007`_.
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/roadshow-ibm/
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/roadshow-google/Pypy_architecture.pdf
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/dls2007/rpython-talk.pdf
+.. __: https://bitbucket.org/pypy/extradoc/raw/tip/talk/roadshow-ibm/
+.. __: https://bitbucket.org/pypy/extradoc/raw/tip/talk/roadshow-google/Pypy_architecture.pdf
+.. __: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dls2007/rpython-talk.pdf
Talks in 2006
@@ -266,36 +266,36 @@
.. _`Kill -1`: http://codespeak.net/pypy/extradoc/talk/ep2006/kill_1_agiletalk.pdf
.. _`Open Source, EU-Funding and Agile Methods`: http://codespeak.net/pypy/extradoc/talk/22c3/agility.pdf
.. _`PyPy Status`: http://codespeak.net/pypy/extradoc/talk/vancouver/talk.html
-.. _`Sprinting the PyPy way`: http://codespeak.net/svn/pypy/extradoc/talk/ep2005/pypy_sprinttalk_ep2005bd.pdf
+.. _`Sprinting the PyPy way`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2005/pypy_sprinttalk_ep2005bd.pdf
.. _`PyPy's VM Approach`: http://codespeak.net/pypy/extradoc/talk/dls2006/talk.html
-.. _`PyPy's approach to virtual machine construction`: http://codespeak.net/svn/pypy/extradoc/talk/dls2006/pypy-vm-construction.pdf
-.. _`EuroPython talks 2009`: http://codespeak.net/svn/pypy/extradoc/talk/ep2009/
-.. _`PyCon talks 2009`: http://codespeak.net/svn/pypy/extradoc/talk/pycon2009/
-.. _`Wroclaw (Poland) presentation`: http://codespeak.net/svn/pypy/extradoc/talk/wroclaw2009/talk.pdf
+.. _`PyPy's approach to virtual machine construction`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dls2006/pypy-vm-construction.pdf
+.. _`EuroPython talks 2009`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2009/
+.. _`PyCon talks 2009`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon2009/
+.. _`Wroclaw (Poland) presentation`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/wroclaw2009/talk.pdf
.. _`PyPy talk at OpenBossa 09`: http://morepypy.blogspot.com/2009/03/pypy-talk-at-openbossa-09.html
-.. _`at SFI 08`: http://codespeak.net/svn/pypy/extradoc/talk/sfi2008/
-.. _`at PyCon Poland 08`: http://codespeak.net/svn/pypy/extradoc/talk/pyconpl-2008/talk.pdf
-.. _`The PyPy Project and You`: http://codespeak.net/svn/pypy/extradoc/talk/osdc2008/osdc08.pdf
-.. _`EuroPython talks 2008`: http://codespeak.net/svn/pypy/extradoc/talk/ep2008/
+.. _`at SFI 08`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/sfi2008/
+.. _`at PyCon Poland 08`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pyconpl-2008/talk.pdf
+.. _`The PyPy Project and You`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/osdc2008/osdc08.pdf
+.. _`EuroPython talks 2008`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2008/
.. _`Maemo summit`: http://morepypy.blogspot.com/2008/09/pypypython-at-maemo-summit.html
-.. _`PyCon UK 2008 - JIT`: http://codespeak.net/svn/pypy/extradoc/talk/pycon-uk-2008/jit/pypy-vm.pdf
-.. _`PyCon UK 2008 - Status`: http://codespeak.net/svn/pypy/extradoc/talk/pycon-uk-2008/status/status.pdf
-.. _`PyCon Italy 2008`: http://codespeak.net/svn/pypy/extradoc/talk/pycon-italy-2008/pypy-vm.pdf
-.. _`RuPy 2008`: http://codespeak.net/svn/pypy/extradoc/talk/rupy2008/
-.. _`RuPy 2007`: http://codespeak.net/svn/pypy/extradoc/talk/rupy2007/
-.. _`PyCon 2008`: http://codespeak.net/svn/pypy/extradoc/talk/pycon2008/
-.. _`ESUG 2007`: http://codespeak.net/svn/pypy/extradoc/talk/esug2007/
-.. _`Bern (Switzerland) 2007`: http://codespeak.net/svn/pypy/extradoc/talk/bern2007/
-.. _`PyCon UK 2007`: http://codespeak.net/svn/pypy/extradoc/talk/pyconuk07/
-.. _Dresden: http://codespeak.net/svn/pypy/extradoc/talk/dresden/
-.. _`EuroPython 2007`: http://codespeak.net/svn/pypy/extradoc/talk/ep2007/
-.. _`Bad Honnef 2007`: http://codespeak.net/svn/pypy/extradoc/talk/badhonnef2007/talk.pdf
-.. _`Dzug talk`: http://codespeak.net/svn/pypy/extradoc/talk/dzug2007/dzug2007.txt
-.. _`PyCon 2007`: http://codespeak.net/svn/pypy/extradoc/talk/pycon2007/
-.. _`PyCon - Uno 2007`: http://codespeak.net/svn/pypy/extradoc/talk/pycon-uno2007/pycon07.pdf
-.. _`Warsaw 2007`: http://codespeak.net/svn/pypy/extradoc/talk/warsaw2007/
-.. _`Warsaw 2006`: http://codespeak.net/svn/pypy/extradoc/talk/warsaw2006/
-.. _`Tokyo 2006`: http://codespeak.net/svn/pypy/extradoc/talk/tokyo/
+.. _`PyCon UK 2008 - JIT`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon-uk-2008/jit/pypy-vm.pdf
+.. _`PyCon UK 2008 - Status`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon-uk-2008/status/status.pdf
+.. _`PyCon Italy 2008`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon-italy-2008/pypy-vm.pdf
+.. _`RuPy 2008`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/rupy2008/
+.. _`RuPy 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/rupy2007/
+.. _`PyCon 2008`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon2008/
+.. _`ESUG 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/esug2007/
+.. _`Bern (Switzerland) 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/bern2007/
+.. _`PyCon UK 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pyconuk07/
+.. _Dresden: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dresden/
+.. _`EuroPython 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2007/
+.. _`Bad Honnef 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/badhonnef2007/talk.pdf
+.. _`Dzug talk`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dzug2007/dzug2007.txt
+.. _`PyCon 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon2007/
+.. _`PyCon - Uno 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon-uno2007/pycon07.pdf
+.. _`Warsaw 2007`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/warsaw2007/
+.. _`Warsaw 2006`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/warsaw2006/
+.. _`Tokyo 2006`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/tokyo/
Related projects
@@ -351,8 +351,8 @@
.. _feasible: http://codespeak.net/pipermail/pypy-dev/2004q2/001289.html
.. _rock: http://codespeak.net/pipermail/pypy-dev/2004q1/001255.html
.. _LLVM: http://llvm.org/
-.. _IronPython: http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython
-.. _`Dynamic Native Optimization of Native Interpreters`: http://www.ai.mit.edu/~gregs/dynamorio.html
-.. _JikesRVM: http://jikesrvm.sf.net
+.. _IronPython: http://ironpython.codeplex.com/
+.. _`Dynamic Native Optimization of Native Interpreters`: http://people.csail.mit.edu/gregs/dynamorio.html
+.. _JikesRVM: http://jikesrvm.org/
.. _Tunes: http://tunes.org
.. _`old Tunes Wiki`: http://codespeak.net/cliki.tunes.org/
diff --git a/pypy/doc/config/objspace.usemodules.rctime.rst b/pypy/doc/config/objspace.usemodules.rctime.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.rctime.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Use the 'rctime' module.
-
-'rctime' is our `rffi`_ based implementation of the builtin 'time' module.
-It supersedes the less complete :config:`objspace.usemodules.time`,
-at least for C-like targets (the C and LLVM backends).
-
-.. _`rffi`: ../rffi.html
diff --git a/pypy/doc/tool/makeref.py b/pypy/doc/tool/makeref.py
--- a/pypy/doc/tool/makeref.py
+++ b/pypy/doc/tool/makeref.py
@@ -5,18 +5,11 @@
pypydir = py.path.local(pypy.__file__).dirpath()
distdir = pypydir.dirpath()
issue_url = 'http://codespeak.net/issue/pypy-dev/'
+bitbucket_url = 'https://bitbucket.org/pypy/pypy/src/default/'
import urllib2, posixpath
-possible_start_dirs = [
- distdir,
- distdir.join('pypy'),
- # for now, let the jit links point to the oo-jit branch
- 'http://codespeak.net/svn/pypy/branch/oo-jit',
- 'http://codespeak.net/svn/pypy/branch/oo-jit/pypy',
- ]
-
def makeref(docdir):
reffile = docdir.join('_ref.txt')
@@ -30,36 +23,24 @@
return
name2target.setdefault(linktarget, []).append(linkname)
- for textfile in docdir.listdir(): # for subdirs, see below
- if textfile.ext != '.txt':
+ for textfile in sorted(docdir.listdir()): # for subdirs, see below
+ if textfile.ext != '.rst':
continue
- for linkname in linkrex.findall(textfile.read()):
- if '/' in linkname:
- for startdir in possible_start_dirs:
- if isinstance(startdir, str):
- assert startdir.startswith('http://')
- target = posixpath.join(startdir, linkname)
- try:
- urllib2.urlopen(target).close()
- except urllib2.HTTPError:
- continue
- else:
- cand = startdir.join(linkname)
- if not cand.check():
- continue
- assert cand.relto(distdir)
- dotdots = 0
- p = docdir
- while p != distdir:
- p = p.dirpath()
- dotdots += 1
- target = '../' * dotdots + cand.relto(distdir)
- addlink(linkname, target)
- break
- else:
- print "WARNING %s: link %r may be bogus" %(textfile, linkname)
+ content = textfile.read()
+ found = False
+ for linkname in linkrex.findall(content):
+ if '/' in linkname:
+ found = True
+ assert distdir.join(linkname).check(), "link %s in %s is dead" % (linkname, textfile)
+ url = bitbucket_url + linkname
+ if not linkname.endswith("/") and distdir.join(linkname).check(dir=1):
+ url += "/"
+ addlink(linkname, url)
elif linkname.startswith('issue'):
+ found = True
addlink(linkname, issue_url+linkname)
+ if found:
+ assert ".. include:: _ref.txt" in content, "you need to include _ref.txt in %s" % (textfile, )
items = name2target.items()
items.sort()
diff --git a/pypy/doc/config/commandline.rst b/pypy/doc/config/commandline.txt
copy from pypy/doc/config/commandline.rst
copy to pypy/doc/config/commandline.txt
--- a/pypy/doc/config/commandline.rst
+++ b/pypy/doc/config/commandline.txt
@@ -1,6 +1,6 @@
.. contents::
-
+
.. _objspace:
.. _`overview-of-command-line-options-for-objspace`:
diff --git a/pypy/doc/config/objspace.usemodules._sha.rst b/pypy/doc/config/objspace.usemodules._sha.txt
copy from pypy/doc/config/objspace.usemodules._sha.rst
copy to pypy/doc/config/objspace.usemodules._sha.txt
diff --git a/pypy/doc/config/objspace.usemodules.time.rst b/pypy/doc/config/objspace.usemodules.time.txt
copy from pypy/doc/config/objspace.usemodules.time.rst
copy to pypy/doc/config/objspace.usemodules.time.txt
diff --git a/pypy/doc/config/objspace.translationmodules.rst b/pypy/doc/config/objspace.translationmodules.txt
copy from pypy/doc/config/objspace.translationmodules.rst
copy to pypy/doc/config/objspace.translationmodules.txt
diff --git a/pypy/doc/config/translation.backendopt.inline_threshold.rst b/pypy/doc/config/translation.backendopt.inline_threshold.txt
copy from pypy/doc/config/translation.backendopt.inline_threshold.rst
copy to pypy/doc/config/translation.backendopt.inline_threshold.txt
diff --git a/pypy/doc/config/translation.backendopt.inline_heuristic.rst b/pypy/doc/config/translation.backendopt.inline_heuristic.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.inline_heuristic.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Internal option. Switch to a different weight heuristic for inlining.
-This is for basic inlining (:config:`translation.backendopt.inline`).
-
-.. internal
diff --git a/pypy/doc/config/translation.countmallocs.rst b/pypy/doc/config/translation.countmallocs.txt
copy from pypy/doc/config/translation.countmallocs.rst
copy to pypy/doc/config/translation.countmallocs.txt
diff --git a/pypy/doc/config/translation.verbose.rst b/pypy/doc/config/translation.verbose.txt
copy from pypy/doc/config/translation.verbose.rst
copy to pypy/doc/config/translation.verbose.txt
diff --git a/pypy/doc/config/objspace.usemodules._pickle_support.rst b/pypy/doc/config/objspace.usemodules._pickle_support.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._pickle_support.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-Use the '_pickle_support' module.
-Internal helpers for pickling runtime builtin types (frames, cells, etc)
-for `stackless`_ tasklet pickling support.
-.. _`stackless`: ../stackless.html
-
-.. internal
diff --git a/pypy/doc/config/translation.secondaryentrypoints.rst b/pypy/doc/config/translation.secondaryentrypoints.txt
copy from pypy/doc/config/translation.secondaryentrypoints.rst
copy to pypy/doc/config/translation.secondaryentrypoints.txt
diff --git a/pypy/doc/config/objspace.lonepycfiles.rst b/pypy/doc/config/objspace.lonepycfiles.txt
copy from pypy/doc/config/objspace.lonepycfiles.rst
copy to pypy/doc/config/objspace.lonepycfiles.txt
diff --git a/pypy/doc/config/objspace.usemodules.oracle.rst b/pypy/doc/config/objspace.usemodules.oracle.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.oracle.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'oracle' module.
-This module is off by default, requires oracle client installed.
diff --git a/pypy/doc/config/translation.cli.trace_calls.rst b/pypy/doc/config/translation.cli.trace_calls.txt
copy from pypy/doc/config/translation.cli.trace_calls.rst
copy to pypy/doc/config/translation.cli.trace_calls.txt
diff --git a/pypy/doc/config/objspace.usemodules.struct.rst b/pypy/doc/config/objspace.usemodules.struct.txt
copy from pypy/doc/config/objspace.usemodules.struct.rst
copy to pypy/doc/config/objspace.usemodules.struct.txt
diff --git a/pypy/tool/rest/rest.py b/pypy/tool/rest/rest.py
--- a/pypy/tool/rest/rest.py
+++ b/pypy/tool/rest/rest.py
@@ -10,14 +10,12 @@
pass
def convert_rest_html(source, source_path, stylesheet=None, encoding='latin1'):
- from pypy.tool.rest import directive
""" return html latin1-encoded document for the given input.
source a ReST-string
sourcepath where to look for includes (basically)
stylesheet path (to be used if any)
"""
from docutils.core import publish_string
- directive.set_backend_and_register_directives("html")
kwargs = {
'stylesheet' : stylesheet,
'stylesheet_path': None,
diff --git a/pypy/doc/config/objspace.usemodules._collections.rst b/pypy/doc/config/objspace.usemodules._collections.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._collections.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '_collections' module.
-Used by the 'collections' standard lib module. This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/objspace.usemodules._testing.rst b/pypy/doc/config/objspace.usemodules._testing.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._testing.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Use the '_testing' module. This module exists only for PyPy own testing purposes.
-
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/config/generate.py b/pypy/doc/config/generate.py
--- a/pypy/doc/config/generate.py
+++ b/pypy/doc/config/generate.py
@@ -1,15 +1,62 @@
import autopath
import py
-from pypy.config import pypyoption, translationoption, config
+from pypy.config import pypyoption, translationoption, config, makerestdoc
from pypy.doc.config.confrest import all_optiondescrs
+all_optiondescrs = [pypyoption.pypy_optiondescription,
+ translationoption.translation_optiondescription,
+ ]
+start_to_descr = dict([(descr._name, descr) for descr in all_optiondescrs])
+
+def make_cmdline_overview():
+ result = []
+ txtpath = thisdir.join("commandline.txt")
+ for line in txtpath.read().splitlines():
+ if line.startswith('.. GENERATE:'):
+ start = line[len('.. GENERATE:'):].strip()
+ descr = start_to_descr[start]
+ line = makerestdoc.make_cmdline_overview(descr, title=False).text()
+ result.append(line)
+ rstpath = txtpath.new(ext=".rst")
+ rstpath.write("\n".join(result))
+
+def make_rst(basename):
+ txtpath = thisdir.join(basename)
+ txtpath.ensure()
+ rstpath = txtpath.new(ext=".rst")
+
+ fullpath = txtpath.purebasename
+ start = fullpath.split(".")[0]
+ path = fullpath.rsplit(".", 1)[0]
+ basedescr = start_to_descr.get(start)
+ if basedescr is None:
+ return
+ if fullpath.count(".") == 0:
+ descr = basedescr
+ path = ""
+ else:
+ conf = config.Config(basedescr)
+ subconf, step = conf._cfgimpl_get_home_by_path(
+ fullpath.split(".", 1)[1])
+ descr = getattr(subconf._cfgimpl_descr, step)
+ text = unicode(descr.make_rest_doc(path).text())
+ if txtpath.check(file=True):
+ content = txtpath.read()
+ if content:
+ text += "\n\n"
+ text = u"%s\n\n%s" % (text, unicode(txtpath.read(), "utf-8"))
+ rstpath.write(text.encode("utf-8"))
+
+
thisdir = py.path.local(__file__).dirpath()
for descr in all_optiondescrs:
prefix = descr._name
c = config.Config(descr)
- thisdir.join(prefix + ".rst").ensure()
+ thisdir.join(prefix + ".txt").ensure()
+ make_rst(prefix + ".txt")
for p in c.getpaths(include_groups=True):
- basename = prefix + "." + p + ".rst"
- f = thisdir.join(basename)
- f.ensure()
+ basename = prefix + "." + p + ".txt"
+ make_rst(basename)
+
+make_cmdline_overview()
diff --git a/pypy/doc/config/objspace.usemodules._weakref.rst b/pypy/doc/config/objspace.usemodules._weakref.txt
copy from pypy/doc/config/objspace.usemodules._weakref.rst
copy to pypy/doc/config/objspace.usemodules._weakref.txt
diff --git a/pypy/doc/config/objspace.usemodules.struct.rst b/pypy/doc/config/objspace.usemodules.struct.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.struct.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Use the built-in 'struct' module.
-This module is expected to be working and is included by default.
-There is also a pure Python version in lib_pypy which is used
-if the built-in is disabled, but it is several orders of magnitude
-slower.
diff --git a/pypy/doc/config/translation.cli.trace_calls.rst b/pypy/doc/config/translation.cli.trace_calls.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.cli.trace_calls.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal. Debugging aid for the CLI backend.
-
-.. internal
diff --git a/pypy/doc/garbage_collection.rst b/pypy/doc/garbage_collection.rst
--- a/pypy/doc/garbage_collection.rst
+++ b/pypy/doc/garbage_collection.rst
@@ -20,8 +20,6 @@
Garbage collectors currently written for the GC framework
=========================================================
-(Very rough sketch only for now.)
-
Reminder: to select which GC you want to include in a translated
RPython program, use the ``--gc=NAME`` option of ``translate.py``.
For more details, see the `overview of command line options for
@@ -36,7 +34,7 @@
--------------
Classical Mark and Sweep collector. Also contains a lot of experimental
-and half-unmaintained features. See `rpython/memory/gc/marksweep.py`_.
+and half-unmaintained features. See `pypy/rpython/memory/gc/marksweep.py`_.
Semispace copying collector
---------------------------
@@ -44,7 +42,7 @@
Two arenas of equal size, with only one arena in use and getting filled
with new objects. When the arena is full, the live objects are copied
into the other arena using Cheney's algorithm. The old arena is then
-cleared. See `rpython/memory/gc/semispace.py`_.
+cleared. See `pypy/rpython/memory/gc/semispace.py`_.
On Unix the clearing is done by reading ``/dev/zero`` into the arena,
which is extremely memory efficient at least on Linux: it lets the
@@ -57,7 +55,7 @@
Generational GC
---------------
-This is a two-generations GC. See `rpython/memory/gc/generation.py`_.
+This is a two-generations GC. See `pypy/rpython/memory/gc/generation.py`_.
It is implemented as a subclass of the Semispace copying collector. It
adds a nursery, which is a chunk of the current semispace. Its size is
@@ -88,7 +86,7 @@
Each generation is collected much less often than the previous one. The
division of the generations is slightly more complicated than just
nursery / semispace / external; see the diagram at the start of the
-source code, in `rpython/memory/gc/hybrid.py`_.
+source code, in `pypy/rpython/memory/gc/hybrid.py`_.
Mark & Compact GC
-----------------
@@ -126,7 +124,7 @@
information in the regular headers.
More details are available as comments at the start of the source
-in `rpython/memory/gc/markcompact.py`_.
+in `pypy/rpython/memory/gc/markcompact.py`_.
Minimark GC
-----------
@@ -214,4 +212,90 @@
becomes free garbage, to be collected at the next major collection.
-.. include:: _ref.rst
+Minimark GC
+-----------
+
+This is a simplification and rewrite of the ideas from the Hybrid GC.
+It uses a nursery for the young objects, and mark-and-sweep for the old
+objects. This is a moving GC, but objects may only move once (from
+the nursery to the old stage).
+
+The main difference with the Hybrid GC is that the mark-and-sweep
+objects (the "old stage") are directly handled by the GC's custom
+allocator, instead of being handled by malloc() calls. The gain is that
+it is then possible, during a major collection, to walk through all old
+generation objects without needing to store a list of pointers to them.
+So as a first approximation, when compared to the Hybrid GC, the
+Minimark GC saves one word of memory per old object.
+
+There are a number of environment variables that can be tweaked to
+influence the GC. (Their default value should be ok for most usages.)
+You can read more about them at the start of
+`pypy/rpython/memory/gc/minimark.py`_.
+
+In more details:
+
+- The small newly malloced objects are allocated in the nursery (case 1).
+ All objects living in the nursery are "young".
+
+- The big objects are always handled directly by the system malloc().
+ But the big newly malloced objects are still "young" when they are
+ allocated (case 2), even though they don't live in the nursery.
+
+- When the nursery is full, we do a minor collection, i.e. we find
+ which "young" objects are still alive (from cases 1 and 2). The
+ "young" flag is then removed. The surviving case 1 objects are moved
+ to the old stage. The dying case 2 objects are immediately freed.
+
+- The old stage is an area of memory containing old (small) objects. It
+ is handled by `pypy/rpython/memory/gc/minimarkpage.py`_. It is organized
+ as "arenas" of 256KB or 512KB, subdivided into "pages" of 4KB or 8KB.
+ Each page can either be free, or contain small objects of all the same
+ size. Furthermore at any point in time each object location can be
+ either allocated or freed. The basic design comes from ``obmalloc.c``
+ from CPython (which itself comes from the same source as the Linux
+ system malloc()).
+
+- New objects are added to the old stage at every minor collection.
+ Immediately after a minor collection, when we reach some threshold, we
+ trigger a major collection. This is the mark-and-sweep step. It walks
+ over *all* objects (mark), and then frees some fraction of them (sweep).
+ This means that the only time when we want to free objects is while
+ walking over all of them; we never ask to free an object given just its
+ address. This allows some simplifications and memory savings when
+ compared to ``obmalloc.c``.
+
+- As with all generational collectors, this GC needs a write barrier to
+ record which old objects have a reference to young objects.
+
+- Additionally, we found out that it is useful to handle the case of
+ big arrays specially: when we allocate a big array (with the system
+ malloc()), we reserve a small number of bytes before. When the array
+ grows old, we use the extra bytes as a set of bits. Each bit
+ represents 128 entries in the array. Whenever the write barrier is
+ called to record a reference from the Nth entry of the array to some
+ young object, we set the bit number ``(N/128)`` to 1. This can
+ considerably speed up minor collections, because we then only have to
+ scan 128 entries of the array instead of all of them.
+
+- As usual, we need special care about weak references, and objects with
+ finalizers. Weak references are allocated in the nursery, and if they
+ survive they move to the old stage, as usual for all objects; the
+ difference is that the reference they contain must either follow the
+ object, or be set to NULL if the object dies. And the objects with
+ finalizers, considered rare enough, are immediately allocated old to
+ simplify the design. In particular their ``__del__`` method can only
+ be called just after a major collection.
+
+- The objects move once only, so we can use a trick to implement id()
+ and hash(). If the object is not in the nursery, it won't move any
+ more, so its id() and hash() are the object's address, cast to an
+ integer. If the object is in the nursery, and we ask for its id()
+ or its hash(), then we pre-reserve a location in the old stage, and
+ return the address of that location. If the object survives the
+ next minor collection, we move it there, and so its id() and hash()
+ are preserved. If the object dies then the pre-reserved location
+ becomes free garbage, to be collected at the next major collection.
+
+
+.. include:: _ref.txt
diff --git a/pypy/doc/config/objspace.std.withstrslice.rst b/pypy/doc/config/objspace.std.withstrslice.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.std.withstrslice.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-Enable "string slice" objects.
-
-See the page about `Standard Interpreter Optimizations`_ for more details.
-
-.. _`Standard Interpreter Optimizations`: ../interpreter-optimizations.html#string-slice-objects
-
-
diff --git a/pypy/doc/config/translation.dump_static_data_info.rst b/pypy/doc/config/translation.dump_static_data_info.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.dump_static_data_info.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Dump information about static prebuilt constants, to the file
-TARGETNAME.staticdata.info in the /tmp/usession-... directory. This file can
-be later inspected using the script ``bin/reportstaticdata.py``.
diff --git a/pypy/doc/config/objspace.allworkingmodules.rst b/pypy/doc/config/objspace.allworkingmodules.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.allworkingmodules.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-This option enables the usage of all modules that are known to be working well
-and that translate without problems.
-
-Note that this option defaults to True (except when running
-``py.py`` because it takes a long time to start). To force it
-to False, use ``--no-allworkingmodules``.
diff --git a/pypy/doc/config/objspace.opcodes.CALL_METHOD.rst b/pypy/doc/config/objspace.opcodes.CALL_METHOD.txt
copy from pypy/doc/config/objspace.opcodes.CALL_METHOD.rst
copy to pypy/doc/config/objspace.opcodes.CALL_METHOD.txt
diff --git a/pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.rst b/pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.txt
copy from pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.rst
copy to pypy/doc/config/objspace.opcodes.CALL_LIKELY_BUILTIN.txt
diff --git a/pypy/doc/config/translation.sandbox.rst b/pypy/doc/config/translation.sandbox.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.sandbox.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-Generate a special fully-sandboxed executable.
-
-The fully-sandboxed executable cannot be run directly, but
-only as a subprocess of an outer "controlling" process. The
-sandboxed process is "safe" in the sense that it doesn't do
-any library or system call - instead, whenever it would like
-to perform such an operation, it marshals the operation name
-and the arguments to its stdout and it waits for the
-marshalled result on its stdin. This controller process must
-handle these operation requests, in any way it likes, allowing
-full virtualization.
-
-For examples of controller processes, see
-``pypy/translator/sandbox/interact.py`` and
-``pypy/translator/sandbox/pypy_interact.py``.
diff --git a/pypy/doc/config/translation.rweakref.rst b/pypy/doc/config/translation.rweakref.txt
copy from pypy/doc/config/translation.rweakref.rst
copy to pypy/doc/config/translation.rweakref.txt
diff --git a/pypy/doc/theory.rst b/pypy/doc/theory.rst
deleted file mode 100644
--- a/pypy/doc/theory.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-.. include:: crufty.rst
-
- .. ^^ old ideas; we're not doing it this way any more
-
-===================================
-Techniques used in PyPy
-===================================
-
-.. contents::
-
-
-.. _`abstract interpretation`:
-
-Abstract Interpretation
-=======================
-
-Abstract Interpretation is a general technique which consists of an
-interpreter that follows the bytecode instructions of a user program, just
-like a normal interpreter does, but with abstract objects instead of concrete
-ones. Remember that in PyPy this is done by using alternate object spaces with
-the same bytecode interpreter main loop.
-
-As a theoretical example, the most abstract object space would be the one manipulating the most abstract objects that you could imagine: they are all equivalent, because we have abstracted away any information about the object. There is actually only one of them left, and we could call it "the object". In Python terms, an AbstractObjectSpace could use None for all its wrapped objects. Any operation between wrapped objects gives None again as the wrapped result -- there is nothing else it could give anyway. So when you have said that the add method of AbstractObjectSpace takes None and None and returns None you have said everything.
-
-The point of such an object space is for example to check the bytecode. The
-bytecode interpreter will really run your bytecode, just with completely
-abstract arguments. If there is no problem then you are sure that the bytecode
-is valid. You could also record, during this abstract interpretation, how much
-the stack ever grows; that would give you a fool-proof method of computing or
-checking the co_stacksize argument of a code object. (There are subtleties
-which I won't describe here, but that's the basic idea.)
-
-Typically, however, abstract object spaces are a (little) bit less abstract, still maintaining a minimal amount of information about the objects. For example, a wrapped object could be represented by its type. You then define the object space's add to return int when the two arguments are int and int. That way, you abstractedly call a function with the input argument's types and what the interpreter will do is a type inference. (Here also there are subtle problems, even besides the remark that integer operations can overflow and actually return longs in a real Python implementation.)
-
-As an example of more abstract object spaces you have the ones with finite domain, i.e. with a finite number of different possible wrapped objects. For example, you can use True and False as wrapped values to denote the fact that the object is, respectively, a non-negative integer or anything else. In this way you are doing another kind of type inference that just tells you which variables will only ever contain non-negative integers.
-
-In PyPy, the FlowObjSpace_ uses the abstract interpretation technique to generate a control flow graph of the functions of RPython_ programs.
-
-In its `more formal definition`_, Abstract Interpretation typically
-considers abstract objects that are organized in a lattice_: some of
-these objects are more (or less) abstract than others, in the sense that
-they represent less (or more) known information; to say that this forms
-a lattice essentially means that any two abstract objects have
-well-defined unions and intersections (which are again abstract
-objects).
-
-.. _FlowObjSpace: objspace.html#the-flow-object-space
-.. _RPython: coding-guide.html#restricted-python
-.. _`more formal definition`: http://en.wikipedia.org/wiki/Abstract_interpretation
-.. _lattice: http://en.wikipedia.org/wiki/Lattice_%28order%29
-
-
-Multimethods
-============
-
-A "multimethod" is the generalization of the OOP notion of "method".
-Theoretically, a method is a "message name" and signature attached to a
-particular base class, which is implemented in the class or its subclasses.
-To do a "method call" means to send a message to an object, using a message
-name and actual arguments. We call "message dispatch" the operation of
-finding which actual implementation is suitable for a particular call. For
-methods, a message is dispatched by looking up the class of the "self" object,
-and finding an implementation in that class, or in its base classes, in a
-certain order.
-
-A multimethod is a message name and signature that can have implementations
-that depend not only on the class of the first "self" argument, but on the
-class of several arguments. Because of this we cannot use Python's nice model
-of storing method implementations as functions, in the attributes of the
-class.
-
-Here is a common implementation of multimethods: they are instances of a
-specific MultiMethod class, and the instances are callable (there is a
-__call__ operator on MultiMethod). When a MultiMethod is called, a dispatch
-algorithm is used to find which, among the registered implementations, is the
-one that should be called; this implementation is then immediately called. The
-most important difference with normal methods is that the MultiMethod object
-to call is no longer syntactically attached to classes. In other words,
-whereas a method is called with ``obj.somemethod(args)``, a multimethod is
-called much like a function, e.g. ``dosomething(obj1, obj2, obj3...)``. You
-have to find the MultiMethod object ``dosomething`` in some namespace; it is
-no longer implicitly looked up in the namespace of the "self" object.
-
-PyPy contains two different implementations of multimethods: a `quite general
-one`_ written in RPython_ for the purposes of the StdObjSpace_, and a `short
-two-arguments-dispatching one`_ used internally by the annotator_.
-
-.. _`quite general one`: http://codespeak.net/svn/pypy/dist/pypy/objspace/std/multimethod.py
-.. _StdObjSpace: objspace.html#the-standard-object-space
-.. _`short two-arguments-dispatching one`: http://codespeak.net/svn/pypy/dist/pypy/tool/pairtype.py
-.. _annotator: translation.html#annotator
diff --git a/pypy/doc/config/objspace.std.withprebuiltint.rst b/pypy/doc/config/objspace.std.withprebuiltint.txt
copy from pypy/doc/config/objspace.std.withprebuiltint.rst
copy to pypy/doc/config/objspace.std.withprebuiltint.txt
diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline_threshold.rst b/pypy/doc/config/translation.backendopt.profile_based_inline_threshold.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.profile_based_inline_threshold.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Weight threshold used to decide whether to inline flowgraphs.
-This is for profile-based inlining (:config:`translation.backendopt.profile_based_inline`).
diff --git a/pypy/doc/config/translation.withsmallfuncsets.rst b/pypy/doc/config/translation.withsmallfuncsets.txt
copy from pypy/doc/config/translation.withsmallfuncsets.rst
copy to pypy/doc/config/translation.withsmallfuncsets.txt
diff --git a/pypy/doc/discussion/pypy_metaclasses_in_cl.rst b/pypy/doc/discussion/pypy_metaclasses_in_cl.rst
deleted file mode 100644
--- a/pypy/doc/discussion/pypy_metaclasses_in_cl.rst
+++ /dev/null
@@ -1,139 +0,0 @@
-IRC log
-=======
-
-::
-
- [09:41] <dialtone> arigo: is it possible to ask the backendoptimizer to completely remove all the oogetfield('meta', obj)?
- [09:42] <dialtone> and at the same time to change all the oogetfield('somefield', meta) into oogetfield('somefield', obj)
- [09:42] <dialtone> because then we wouldn't need the metaclass hierarchy anymore
- [09:42] <dialtone> (at least in common lisp)
- [09:42] <arigo> as far as I know the idea was indeed to be able to do this kind of things
- [09:43] <arigo> but not necessarily in the existing backendopt
- [09:44] <dialtone> uhmmm
- [09:44] <dialtone> I have no idea how to do this stuff
- [09:44] <arigo> if I understand it correctly, as a first step you can just tweak gencl to recognize oogetfield('meta', obj)
- [09:44] <dialtone> I'll think about it on the plane maybe
- [09:44] <arigo> and produce a same_as equivalent instead
- [09:44] <arigo> (do I make any sense at all?)
- [09:44] <dialtone> yes
- [09:45] <dialtone> same_as(meta, obj)
- [09:45] <dialtone> so that the next oogetfield() will still work on meta which in reality is the obj
- [09:45] <arigo> yes
- [09:45] <dialtone> thus you obtained the same thing without removing anything
- [09:45] <dialtone> cool
- [09:46] <antocuni> dialtone: can you explain me better what are you trying to do?
- [09:46] <dialtone> it looks kinda simple
- [09:46] <dialtone> am I a fool?
- [09:46] <dialtone> antocuni: I want to get rid of the metaclass stuff in common lisp
- [09:47] <dialtone> since common lisp supports class variables
- [09:47] <dialtone> (DEFCLASS foo () ((bar :allocate :class)))
- [09:47] <antocuni> cool
- [09:47] <dialtone> but to do that I also have to get rid of the opcodes that work on the object model
- [09:48] <dialtone> at first I thought about removing the metaclass related operations (or change them) but armin got a great idea about using same_as
- [09:48] idnar (i=mithrand at unaffiliated/idnar) left irc: Remote closed the connection
- [09:48] <arigo> there might be a few problems, though
- [09:48] <dialtone> and here comes the part I feared
- [09:48] <arigo> I'm not sure if the meta object is used for more than oogetfields
- [09:49] <arigo> and also, let's see if there are name clashes in the fields
- [09:49] <antocuni> I can't understand a thing: are you trying to lookup some fields in the obj directly, instead of in the metclass, right?
- [09:49] <dialtone> antocuni: yes
- [09:50] <antocuni> why an object should have fields that belongs to its metaclass?
- [09:50] <dialtone> arigo: uhmmm you can have both a class variable and an instance variable named in the same way?
- [09:50] <dialtone> metaclass is not a real metaclass
- [09:50] <arigo> I don't know
- [09:50] <braintone> arigo - r26566 - Support geterrno() from rctypes to genc.
- [09:50] <antocuni> dialtone: ah, now I understand
- [09:50] <arigo> I would expect it not to be the case, as the names come from RPython names
- [09:51] <dialtone> arigo: indeed
- [09:51] <dialtone> but I guess I can set different accessors maybe for class level things and for instance level things
- [09:51] <dialtone> let's try
- [09:51] <dialtone> no...
- [09:52] <dialtone> so a name clash would break stuff
- [09:52] <dialtone> but... how do you recognize an access to a class variable and one to an instance variable from RPython?
- [09:53] <arigo> dialtone: I think we don't have name clashes, because there is some mangling anyway
- [09:53] <dialtone> cool
- [09:53] <arigo> if I see it correctly, class variable names start with 'pbc' and instance ones with 'o'
- [09:53] <dialtone> that's what we've done in gencl yes
- [09:54] <arigo> ? that's what the ootyping is doing
- [09:54] <dialtone> yes yes
- [09:54] <arigo> :-)
- [09:54] <dialtone> I mean that I see the distinction in gencl :)
- [09:54] <dialtone> sooooooo
- [09:55] <dialtone> if I have a getfield where the first argument is meta and I simply emit the same code that I emit for the same_as I should be safe removing all the meta stuff... maybe
- [09:55] <dialtone> seems like a tiny change in gencl
- [09:55] <arigo> dialtone: in RPython, the annotator says that attributes are instance fields as soon as they are written to instances, otherwise they are class attributes
- [09:56] <arigo> yes, it should work
- [09:56] Palats (n=Pierre at izumi.palats.com) left irc: Read error: 104 (Connection reset by peer)
- [09:56] <dialtone> unless of course metaclasses are used for something else than class variables
- [09:56] <arigo> ideally, you should not look for the name 'meta' but for some other hint
- [09:57] <arigo> I'm not completely at ease with the various levels of ootype
- [09:57] <dialtone> neither am I\
- [09:57] <nikh> all field names other than those defined by ootype (like "meta") will be mangled, so i guess checking for "meta" is good enough
- [09:57] <dialtone> and I also have to ignore the setfield opcode that deals with metaclasses
- [09:58] <dialtone> or make it a same_as as well
- [09:59] <arigo> apparently, the meta instances are used as the ootype of RPython classes
- [10:00] <arigo> so they can be manipulated by RPython code that passes classes around
- [10:01] <arigo> I guess you can also pass classes around in CL, read attributes from them, and instantiate them
- [10:01] <dialtone> yes
- [10:01] <arigo> so a saner approach might be to try to have gencl use CL classes instead of these meta instances
- [10:03] <dialtone> uhmmmmm
- [10:03] <arigo> which means: recognize if an ootype.Instance is actually representing an RPython class (by using a hint)
- [10:03] <dialtone> I also have to deal with the Class_
- [10:03] <dialtone> but that can probably be set to standard-class
- [10:03] <arigo> yes, I think it's saner to make, basically, oogetfield('class_') be a same_as
- [10:04] <dialtone> cool
- [10:04] <dialtone> I think I'll save this irc log to put it in the svn tree for sanxiyn
- [10:04] <nikh> to recognize RPython class represenations: if the ootype.Instance has the superclass ootypesystem.rclass.CLASSTYPE, then it's a "metaclass"
- [10:04] <dialtone> he is thinking about this in the plane (at least this is what he told)
- [10:05] <arigo> :-)
- [10:05] <arigo> nikh: yes
- [10:05] <arigo> ootype is indeed rather complicated, level-wise, to support limited languages like Java
- [10:05] <nikh> unfortunately, yes
- [10:05] <nikh> well, in a way it's very convenient for the backends
- [10:05] <nikh> but if you want to use more native constructs, it gets hairy quickly
- [10:05] <dialtone> I dunno
- [10:05] <dialtone> depends on the backend
- [10:06] <arigo> hum, there is still an information missing that gencl would need here
- [10:06] <dialtone> I think if the language of the backend is powerful enough it could use an higher abstraction
- [10:07] <arigo> dialtone: yes, there is also the (hairly to implement) idea of producing slightly different things for different back-ends too
- [10:07] <dialtone> using backendopts?
- [10:08] <dialtone> would it make sense to have a kind of backend_supports=['metaclasses', 'classvariables', 'first_class_functions'...]
- [10:08] <arigo> maybe, but I was thinking about doing different things in ootypesystem/rclass already
- [10:08] <arigo> yes, such a backend_supports would be great
- [10:09] <nikh> dialtone: there is still an hour left to sprint, so go go go ;)
- [10:09] <nikh> you can do it, if you want it ;)
- [10:09] <arigo> what is missing is the link from the concrete Instance types, and which Instance corresponds to its meta-instance
- [10:10] idnar (i=mithrand at unaffiliated/idnar) joined #pypy.
- [10:10] <arigo> dialtone: it's not as simple as making an oogetfield be a same_as
- [10:10] <dialtone> KnowledgeUnboundError, Missing documentation in slot brain
- [10:10] <arigo> right now for CL the goal would be to generate for a normal Instance, a DEFCLASS whose :allocate :class attributes are the attributes of the meta-Instance
- [10:11] <nikh> we could optionally have class fields in Instances, and then operations like ooget/setclassfield
- [10:11] <dialtone> the reason why I ask is that if we manage to do this then we could also use default Condition as Exception
- [10:11] <dialtone> and we could map the Conditions in common lisp to exceptions in python transparently
- [10:12] <dialtone> since the object systems will then match (and they are vaguely similar anyway)
- [10:12] <arigo> nice
- [10:12] <dialtone> at least I think
- [10:18] <arigo> I'm still rather confused by ootypesystem/rclass
- [10:18] <arigo> although I think that blame would show my name on quite some bits :-)
- [10:19] <arigo> there are no class attributes read through instances
- [10:19] <arigo> they are turned into method calls
- [10:19] <arigo> accessor methods
- [10:20] <arigo> it's a bit organically grown
- [10:20] <arigo> accessor methods were introduced at one point, and the meta-Instance later
- [10:21] <dialtone> uhmmm
- [10:22] <nikh> what was the reason for having accessor methods?
- [10:22] <nikh> they seem to be only generated for class vars that are overriden in subclasses.
- [10:22] <arigo> yes
- [10:22] <arigo> before we had the meta-Instance trick, it was the only way to avoid storing the value in all instances
- [10:22] <nikh> aha
- [10:23] <nikh> we could possibly get rid of these accessors
- [10:23] <arigo> now, yes, by storing the values in the meta-Instance
- [10:23] <nikh> they are alway anyway stored in the meta-Instance, I think
- [10:23] <arigo> no, I think that other values are stored in the meta-Instance right now
- [10:24] <arigo> it's the values that are only ever accessed with a syntax 'ClassName.attr', i.e. not through an instance
- [10:24] <arigo> ...more precisely, with 'x = ClassName or OtherClassName; x.attr'
- [10:25] <nikh> hm, i'm still trying to read this out of the code ...
- [10:28] <arigo> it's in ClassRepr._setup_repr()
- [10:28] <arigo> there is no clsfields here, just pbcfields
- [10:28] <arigo> # attributes showing up in getattrs done on the class as a PBC
- [10:28] <nikh> i see
diff --git a/pypy/bin/carbonpython.py b/pypy/bin/carbonpython.py
deleted file mode 100755
--- a/pypy/bin/carbonpython.py
+++ /dev/null
@@ -1,5 +0,0 @@
-#! /usr/bin/env python
-import autopath, sys
-from pypy.translator.cli.carbonpython import main
-
-main(sys.argv)
diff --git a/pypy/doc/config/objspace.usemodules._stackless.rst b/pypy/doc/config/objspace.usemodules._stackless.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._stackless.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-Use the '_stackless' module.
-
-Exposes the `stackless` primitives, and also implies a stackless build.
-See also :config:`translation.stackless`.
-
-.. _`stackless`: ../stackless.html
diff --git a/pypy/doc/sandbox.rst b/pypy/doc/sandbox.rst
--- a/pypy/doc/sandbox.rst
+++ b/pypy/doc/sandbox.rst
@@ -1,7 +1,3 @@
-.. include:: crufty.rst
-
- .. ^^ it continues to work, but is unmaintained
-
PyPy's sandboxing features
==========================
diff --git a/pypy/doc/config/translation.gc.rst b/pypy/doc/config/translation.gc.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.gc.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-Choose the Garbage Collector used by the translated program:
-
- - "ref": reference counting. Takes very long to translate and the result is
- slow.
-
- - "marksweep": naive mark & sweep.
-
- - "semispace": a copying semi-space GC.
-
- - "generation": a generational GC using the semi-space GC for the
- older generation.
-
- - "boehm": use the Boehm conservative GC.
diff --git a/pypy/doc/config/translation.gc.rst b/pypy/doc/config/translation.gc.txt
copy from pypy/doc/config/translation.gc.rst
copy to pypy/doc/config/translation.gc.txt
diff --git a/pypy/doc/config/objspace.usemodules.imp.rst b/pypy/doc/config/objspace.usemodules.imp.txt
copy from pypy/doc/config/objspace.usemodules.imp.rst
copy to pypy/doc/config/objspace.usemodules.imp.txt
diff --git a/pypy/doc/config/objspace.usemodules.bz2.rst b/pypy/doc/config/objspace.usemodules.bz2.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.bz2.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'bz2' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/discussion/distribution-roadmap.rst b/pypy/doc/discussion/distribution-roadmap.rst
deleted file mode 100644
--- a/pypy/doc/discussion/distribution-roadmap.rst
+++ /dev/null
@@ -1,72 +0,0 @@
-Distribution:
-=============
-
-Some random thoughts about automatic (or not) distribution layer.
-
-What I want to achieve is to make clean approach to perform
-distribution mechanism with virtually any distribution heuristic.
-
-First step - RPython level:
----------------------------
-
-First (simplest) step is to allow user to write RPython programs with
-some kind of remote control over program execution. For start I would
-suggest using RMI (Remote Method Invocation) and remote object access
-(in case of low level it would be struct access). For the simplicity
-it will make some sense to target high-level platform at the beginning
-(CLI platform seems like obvious choice), which provides more primitives
-for performing such operations. To make attempt easier, I'll provide
-some subset of type system to be serializable which can go as parameters
-to such a call.
-
-I take advantage of several assumptions:
-
-* globals are constants - this allows us to just run multiple instances
- of the same program on multiple machines and perform RMI.
-
-* I/O is explicit - this makes GIL problem not that important. XXX: I've got
- to read more about GIL to notice if this is true.
-
-Second step - doing it a little bit more automatically:
--------------------------------------------------------
-
-The second step is to allow some heuristic to live and change
-calls to RMI calls. This should follow some assumptions (which may vary,
-regarding implementation):
-
-* Not to move I/O to different machine (we can track I/O and side-effects
- in RPython code).
-
-* Make sure all C calls are safe to transfer if we want to do that (this
- depends on probably static API declaration from programmer "I'm sure this
- C call has no side-effects", we don't want to check it in C) or not transfer
- them at all.
-
-* Perform it all statically, at the time of program compilation.
-
-* We have to generate serialization methods for some classes, which
- we want to transfer (Same engine might be used to allow JSON calls in JS
- backend to transfer arbitrary python object).
-
-Third step - Just-in-time distribution:
----------------------------------------
-
-The biggest step here is to provide JIT integration into distribution
-system. This should allow to make it really useful (probably compile-time
-distribution will not work for example for whole Python interpreter, because
-of too huge granularity). This is quite unclear for me how to do that
-(JIT is not complete and I don't know too much about it). Probably we
-take JIT information about graphs and try to feed it to heuristic in some way
-to change the calls into RMI.
-
-Problems to fight with:
------------------------
-
-Most problems are to make mechanism working efficiently, so:
-
-* Avoid too much granularity (copying a lot of objects in both directions
- all the time)
-
-* Make heuristic not eat too much CPU time/memory and all of that.
-
-* ...
diff --git a/pypy/doc/config/objspace.usemodules.pypyjit.rst b/pypy/doc/config/objspace.usemodules.pypyjit.txt
copy from pypy/doc/config/objspace.usemodules.pypyjit.rst
copy to pypy/doc/config/objspace.usemodules.pypyjit.txt
diff --git a/pypy/doc/config/objspace.usemodules._file.rst b/pypy/doc/config/objspace.usemodules._file.txt
copy from pypy/doc/config/objspace.usemodules._file.rst
copy to pypy/doc/config/objspace.usemodules._file.txt
diff --git a/pypy/doc/discussion/summer-of-pypy-pytest.rst b/pypy/doc/discussion/summer-of-pypy-pytest.rst
deleted file mode 100644
--- a/pypy/doc/discussion/summer-of-pypy-pytest.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-============================================
-Summer of PyPy proposal: Distributed py.test
-============================================
-
-
-Purpose:
-========
-
-The main purpose of distributing py.test is to speedup tests
-of actual applications (running all pypy tests already takes
-ages).
-
-Method:
-=======
-
-Remote imports:
----------------
-
-On the beginning of communication, master server sends to client
-import hook code, which then can import all needed libraries.
-
-Libraries are uploaded server -> client if they're needed (when
-__import__ is called). Possible extension is to add some kind of
-checksum (md5?) and store files in some directory.
-
-Previous experiments:
----------------------
-
-Previous experiments tried to run on the lowest level - when function/
-method is called. This is pretty clear (you run as few code on client
-side as possible), but has got some drawbacks:
-
-- You must simulate *everything* and transform it to server side in
- case of need of absolutely anything (tracebacks, short and long,
- source code etc.)
-- It's sometimes hard to catch exceptions.
-- Top level code in testing module does not work at all.
-
-Possible approach:
-------------------
-
-On client side (side really running tests) run some kind of cut-down
-session, which is imported by remote import at the very beginning and
-after that, we run desired tests (probably by importing whole test
-file which allows us to have top-level imports).
-
-Then we transfer output data to server as string, possibly tweaking
-file names (which is quite easy).
-
-Deliverables:
-=============
-
-- better use of testing machines
-- cut down test time
-- possible extension to run distributed code testing, by running and
- controlling several distributed parts on different machines.
diff --git a/pypy/doc/config/objspace.usemodules.unicodedata.rst b/pypy/doc/config/objspace.usemodules.unicodedata.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.unicodedata.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'unicodedata' module.
-This module is expected to be fully working.
diff --git a/pypy/doc/dot-net.rst b/pypy/doc/dot-net.rst
--- a/pypy/doc/dot-net.rst
+++ b/pypy/doc/dot-net.rst
@@ -9,4 +9,3 @@
cli-backend.rst
clr-module.rst
- carbonpython.rst
diff --git a/pypy/doc/tool/makecontributor.py b/pypy/doc/tool/makecontributor.py
--- a/pypy/doc/tool/makecontributor.py
+++ b/pypy/doc/tool/makecontributor.py
@@ -5,6 +5,9 @@
"""
import py
+# this file is useless, use the following commandline instead:
+# hg churn -c -t "{author}" | sed -e 's/ <.*//'
+
try:
path = py.std.sys.argv[1]
except IndexError:
diff --git a/pypy/doc/config/translation.type_system.rst b/pypy/doc/config/translation.type_system.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.type_system.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Which type system to use when rtyping_. This option should not be set
-explicitly.
-
-.. _rtyping: ../rtyper.html
diff --git a/pypy/doc/_ref.rst b/pypy/doc/_ref.txt
copy from pypy/doc/_ref.rst
copy to pypy/doc/_ref.txt
--- a/pypy/doc/_ref.rst
+++ b/pypy/doc/_ref.txt
@@ -1,107 +1,125 @@
-.. _`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/`:
+.. _`demo/`: https://bitbucket.org/pypy/pypy/src/default/demo/
+.. _`demo/pickle_coroutine.py`: https://bitbucket.org/pypy/pypy/src/default/demo/pickle_coroutine.py
+.. _`lib-python/`: https://bitbucket.org/pypy/pypy/src/default/lib-python/
+.. _`lib-python/2.7.0/dis.py`: https://bitbucket.org/pypy/pypy/src/default/lib-python/2.7.0/dis.py
+.. _`lib_pypy/`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/
+.. _`lib_pypy/pypy_test/`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/pypy_test/
+.. _`lib_pypy/stackless.py`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/stackless.py
+.. _`lib_pypy/tputil.py`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/tputil.py
+.. _`pypy/annotation`:
+.. _`pypy/annotation/`: https://bitbucket.org/pypy/pypy/src/default/pypy/annotation/
+.. _`pypy/annotation/annrpython.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/annotation/annrpython.py
+.. _`pypy/annotation/binaryop.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/annotation/binaryop.py
+.. _`pypy/annotation/builtin.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/annotation/builtin.py
+.. _`pypy/bin/`: https://bitbucket.org/pypy/pypy/src/default/pypy/bin/
+.. _`pypy/bin/translatorshell.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/bin/translatorshell.py
+.. _`pypy/config/`: https://bitbucket.org/pypy/pypy/src/default/pypy/config/
+.. _`pypy/config/pypyoption.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/config/pypyoption.py
+.. _`pypy/config/translationoption.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/config/translationoption.py
+.. _`pypy/doc/`: https://bitbucket.org/pypy/pypy/src/default/pypy/doc/
+.. _`pypy/doc/config/`: https://bitbucket.org/pypy/pypy/src/default/pypy/doc/config/
+.. _`pypy/doc/discussion/`: https://bitbucket.org/pypy/pypy/src/default/pypy/doc/discussion/
+.. _`pypy/interpreter`:
+.. _`pypy/interpreter/`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/
+.. _`pypy/interpreter/argument.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/argument.py
+.. _`pypy/interpreter/astcompiler`:
+.. _`pypy/interpreter/astcompiler/`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/
+.. _`pypy/interpreter/astcompiler/assemble.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/assemble.py
+.. _`pypy/interpreter/astcompiler/ast.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/ast.py
+.. _`pypy/interpreter/astcompiler/astbuilder.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/astbuilder.py
+.. _`pypy/interpreter/astcompiler/asthelpers.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/asthelpers.py
+.. _`pypy/interpreter/astcompiler/codegen.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/codegen.py
+.. _`pypy/interpreter/astcompiler/optimize.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/optimize.py
+.. _`pypy/interpreter/astcompiler/symtable.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/symtable.py
+.. _`pypy/interpreter/astcompiler/tools/Python.asdl`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/tools/Python.asdl
+.. _`pypy/interpreter/astcompiler/tools/asdl_py.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/tools/asdl_py.py
+.. _`pypy/interpreter/baseobjspace.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/baseobjspace.py
+.. _`pypy/interpreter/eval.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/eval.py
+.. _`pypy/interpreter/executioncontext.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/executioncontext.py
+.. _`pypy/interpreter/function.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/function.py
+.. _`pypy/interpreter/gateway.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/gateway.py
+.. _`pypy/interpreter/generator.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/generator.py
+.. _`pypy/interpreter/mixedmodule.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/mixedmodule.py
+.. _`pypy/interpreter/module.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/module.py
+.. _`pypy/interpreter/nestedscope.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/nestedscope.py
+.. _`pypy/interpreter/pyframe.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyframe.py
+.. _`pypy/interpreter/pyopcode.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyopcode.py
+.. _`pypy/interpreter/pyparser`:
+.. _`pypy/interpreter/pyparser/`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/
+.. _`pypy/interpreter/pyparser/future.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/future.py
+.. _`pypy/interpreter/pyparser/metaparser.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/metaparser.py
+.. _`pypy/interpreter/pyparser/parser.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/parser.py
+.. _`pypy/interpreter/pyparser/pyparse.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/pyparse.py
+.. _`pypy/interpreter/pyparser/pytokenizer.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyparser/pytokenizer.py
+.. _`pypy/interpreter/typedef.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/typedef.py
.. _`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/module/`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/
+.. _`pypy/module/__builtin__/__init__.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/__builtin__/__init__.py
+.. _`pypy/module/_stackless/test/test_composable_coroutine.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/_stackless/test/test_composable_coroutine.py
+.. _`pypy/objspace`:
+.. _`pypy/objspace/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/
+.. _`pypy/objspace/dump.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/dump.py
+.. _`pypy/objspace/flow`:
+.. _`pypy/objspace/flow/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/flow/
+.. _`pypy/objspace/flow/model.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/flow/model.py
+.. _`pypy/objspace/std`:
+.. _`pypy/objspace/std/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/
+.. _`pypy/objspace/std/listtype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/listtype.py
+.. _`pypy/objspace/std/multimethod.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/multimethod.py
+.. _`pypy/objspace/std/objspace.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/objspace.py
+.. _`pypy/objspace/std/proxy_helpers.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/proxy_helpers.py
+.. _`pypy/objspace/std/proxyobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/proxyobject.py
+.. _`pypy/objspace/std/stringtype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/stringtype.py
+.. _`pypy/objspace/std/transparent.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/transparent.py
+.. _`pypy/objspace/std/tupleobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/tupleobject.py
+.. _`pypy/objspace/std/tupletype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/tupletype.py
+.. _`pypy/objspace/taint.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/taint.py
+.. _`pypy/objspace/thunk.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/thunk.py
+.. _`pypy/objspace/trace.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/trace.py
.. _`pypy/rlib`:
-.. _`rlib/`: ../../../../pypy/rlib
-.. _`pypy/rlib/rarithmetic.py`: ../../../../pypy/rlib/rarithmetic.py
-.. _`pypy/rlib/test`: ../../../../pypy/rlib/test
+.. _`pypy/rlib/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/
+.. _`pypy/rlib/listsort.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/listsort.py
+.. _`pypy/rlib/nonconst.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/nonconst.py
+.. _`pypy/rlib/objectmodel.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/objectmodel.py
+.. _`pypy/rlib/parsing/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/parsing/
+.. _`pypy/rlib/parsing/tree.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/parsing/tree.py
+.. _`pypy/rlib/rarithmetic.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rarithmetic.py
+.. _`pypy/rlib/rbigint.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rbigint.py
+.. _`pypy/rlib/rrandom.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rrandom.py
+.. _`pypy/rlib/rsocket.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rsocket.py
+.. _`pypy/rlib/rstack.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rstack.py
+.. _`pypy/rlib/streamio.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/streamio.py
+.. _`pypy/rlib/test`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/test/
+.. _`pypy/rlib/unroll.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/unroll.py
.. _`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/rpython/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/
+.. _`pypy/rpython/lltypesystem/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/
+.. _`pypy/rpython/lltypesystem/lltype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/lltype.py
+.. _`pypy/rpython/memory/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/
+.. _`pypy/rpython/memory/gc/generation.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/generation.py
+.. _`pypy/rpython/memory/gc/hybrid.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/hybrid.py
+.. _`pypy/rpython/memory/gc/markcompact.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/markcompact.py
+.. _`pypy/rpython/memory/gc/marksweep.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/marksweep.py
+.. _`pypy/rpython/memory/gc/minimark.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/minimark.py
+.. _`pypy/rpython/memory/gc/minimarkpage.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/minimarkpage.py
+.. _`pypy/rpython/memory/gc/semispace.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/memory/gc/semispace.py
+.. _`pypy/rpython/ootypesystem/`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/ootypesystem/
+.. _`pypy/rpython/ootypesystem/ootype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/ootypesystem/ootype.py
+.. _`pypy/rpython/rint.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/rint.py
+.. _`pypy/rpython/rlist.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/rlist.py
+.. _`pypy/rpython/rmodel.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/rmodel.py
+.. _`pypy/rpython/rtyper.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/rtyper.py
+.. _`pypy/rpython/test/test_llinterp.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/test/test_llinterp.py
+.. _`pypy/tool/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/
+.. _`pypy/tool/algo/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/algo/
+.. _`pypy/tool/pytest/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/pytest/
+.. _`pypy/tool/traceconfig.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/traceconfig.py
.. _`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/
+.. _`pypy/translator/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/
+.. _`pypy/translator/backendopt/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/backendopt/
+.. _`pypy/translator/c/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/c/
+.. _`pypy/translator/cli/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/cli/
+.. _`pypy/translator/goal/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/goal/
+.. _`pypy/translator/jvm/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/jvm/
+.. _`pypy/translator/stackless/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/stackless/
+.. _`pypy/translator/tool/`: https://bitbucket.org/pypy/pypy/src/default/pypy/translator/tool/
diff --git a/pypy/doc/config/objspace.usemodules._ffi.rst b/pypy/doc/config/objspace.usemodules._ffi.txt
copy from pypy/doc/config/objspace.usemodules._ffi.rst
copy to pypy/doc/config/objspace.usemodules._ffi.txt
diff --git a/pypy/doc/config/translation.jit.rst b/pypy/doc/config/translation.jit.txt
copy from pypy/doc/config/translation.jit.rst
copy to pypy/doc/config/translation.jit.txt
diff --git a/pypy/doc/cleanup-todo.rst b/pypy/doc/cleanup-todo.rst
deleted file mode 100644
--- a/pypy/doc/cleanup-todo.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-
-PyPy cleanup areas
-==================
-
-This is a todo list that lists various areas of PyPy that should be cleaned up
-(for whatever reason: less mess, less code duplication, etc).
-
-translation toolchain
----------------------
-
- - low level backends should share more code
- - all backends should have more consistent interfaces
- - geninterp is a hack
- - delegate finding type stuff like vtables etc to GC, cleaner interface for rtti,
- simplify translator/c/gc.py
- - clean up the tangle of including headers in the C backend
- - make approach for loading modules more sane, mixedmodule capture
- too many platform dependencies especially for pypy-cli
- - review pdbplus, especially the graph commands, also in the light of
- https://codespeak.net/issue/pypy-dev/issue303 and the fact that
- we can have more than one translator/annotator around (with the
- timeshifter)
-
-interpreter
------------
-
- - review the things implemented at applevel whether they are performance-
- critical
-
- - review CPython regression test suite, enable running tests, fix bugs
diff --git a/pypy/doc/config/objspace.logbytecodes.rst b/pypy/doc/config/objspace.logbytecodes.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.logbytecodes.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal option.
-
-.. internal
diff --git a/pypy/doc/discussion/translation-swamp.rst b/pypy/doc/discussion/translation-swamp.rst
deleted file mode 100644
--- a/pypy/doc/discussion/translation-swamp.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-===================================================================
-List of things that need to be improved for translation to be saner
-===================================================================
-
-
- * understand nondeterminism after rtyping
-
- * experiment with different heuristics:
-
- * weigh backedges more (TESTING)
- * consider size of outer function
- * consider number of arguments (TESTING)
-
- * find a more deterministic inlining order (TESTING using number of callers)
-
- * experiment with using a base inlining threshold and then drive inlining by
- malloc removal possibilities (using escape analysis)
-
- * move the inlining of gc helpers just before emitting the code.
- throw the graph away (TESTING, need to do a new framework translation)
-
- * for gcc: use just one implement file (TRIED: turns out to be a bad idea,
- because gcc uses too much ram). Need to experiment more now that
- inlining should at least be more deterministic!
-
-things to improve the framework gc
-==================================
-
- * find out whether a function can collect
-
diff --git a/pypy/doc/config/objspace.usemodules.__builtin__.rst b/pypy/doc/config/objspace.usemodules.__builtin__.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.__builtin__.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the '__builtin__' module.
-This module is essential, included by default and should not be removed.
diff --git a/pypy/doc/config/objspace.usemodules._bisect.rst b/pypy/doc/config/objspace.usemodules._bisect.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._bisect.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Use the '_bisect' module.
-Used, optionally, by the 'bisect' standard lib module. This module is expected to be working and is included by default.
-
-
diff --git a/pypy/doc/config/translation.insist.rst b/pypy/doc/config/translation.insist.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.insist.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Don't stop on the first `rtyping`_ error. Instead, try to rtype as much as
-possible and show the collected error messages in the end.
-
-.. _`rtyping`: ../rtyper.html
diff --git a/pypy/translator/cli/carbonpython.py b/pypy/translator/cli/carbonpython.py
deleted file mode 100644
--- a/pypy/translator/cli/carbonpython.py
+++ /dev/null
@@ -1,160 +0,0 @@
-#! /usr/bin/env python
-"""
-Usage: carbonpython.py <module-name> [dll-name]
-
-Compiles an RPython module into a .NET dll.
-"""
-
-import sys
-import new
-import types
-import os.path
-import inspect
-
-from pypy.translator.driver import TranslationDriver
-from pypy.translator.cli.entrypoint import DllEntryPoint
-
-class DllDef:
- def __init__(self, name, namespace, functions=[], dontmangle=True, isnetmodule=False):
- self.name = name
- self.namespace = namespace
- self.functions = functions # [(function, annotation), ...]
- self.isnetmodule = isnetmodule
- self.driver = TranslationDriver()
- if dontmangle:
- self.driver.config.translation.ootype.mangle = False
- self.driver.setup_library(self)
-
- def add_function(self, func, inputtypes):
- self.functions.append((func, inputtypes))
-
- def get_entrypoint(self, bk):
- graphs = [bk.getdesc(f).cachedgraph(None) for f, _ in self.functions]
- return DllEntryPoint(self.name, graphs, self.isnetmodule)
-
- def compile(self):
- # add all functions to the appropriate namespace
- if self.namespace:
- for func, _ in self.functions:
- if not hasattr(func, '_namespace_'):
- func._namespace_ = self.namespace
- self.driver.proceed(['compile_cli'])
-
-class export(object):
- def __new__(self, *args, **kwds):
- if len(args) == 1 and isinstance(args[0], types.FunctionType):
- func = args[0]
- func._inputtypes_ = ()
- return func
- return object.__new__(self, *args, **kwds)
-
- def __init__(self, *args, **kwds):
- self.inputtypes = args
- self.namespace = kwds.pop('namespace', None)
- if len(kwds) > 0:
- raise TypeError, "unexpected keyword argument: '%s'" % kwds.keys()[0]
-
- def __call__(self, func):
- func._inputtypes_ = self.inputtypes
- if self.namespace is not None:
- func._namespace_ = self.namespace
- return func
-
-def is_exported(obj):
- return isinstance(obj, (types.FunctionType, types.UnboundMethodType)) \
- and hasattr(obj, '_inputtypes_')
-
-def collect_entrypoints(dic):
- entrypoints = []
- for item in dic.itervalues():
- if is_exported(item):
- entrypoints.append((item, item._inputtypes_))
- elif isinstance(item, types.ClassType) or isinstance(item, type):
- entrypoints += collect_class_entrypoints(item)
- return entrypoints
-
-def collect_class_entrypoints(cls):
- try:
- __init__ = cls.__init__
- if not is_exported(__init__):
- return []
- except AttributeError:
- return []
-
- entrypoints = [(wrap_init(cls, __init__), __init__._inputtypes_)]
- for item in cls.__dict__.itervalues():
- if item is not __init__.im_func and is_exported(item):
- inputtypes = (cls,) + item._inputtypes_
- entrypoints.append((wrap_method(item), inputtypes))
- return entrypoints
-
-def getarglist(meth):
- arglist, starargs, kwargs, defaults = inspect.getargspec(meth)
- assert starargs is None, '*args not supported yet'
- assert kwargs is None, '**kwds not supported yet'
- assert defaults is None, 'default values not supported yet'
- return arglist
-
-def wrap_init(cls, meth):
- arglist = getarglist(meth)[1:] # discard self
- args = ', '.join(arglist)
- source = 'def __internal__ctor(%s): return %s(%s)' % (
- args, cls.__name__, args)
- mydict = {cls.__name__: cls}
- print source
- exec source in mydict
- return mydict['__internal__ctor']
-
-def wrap_method(meth, is_init=False):
- arglist = getarglist(meth)
- name = '__internal__%s' % meth.func_name
- selfvar = arglist[0]
- args = ', '.join(arglist)
- params = ', '.join(arglist[1:])
- source = 'def %s(%s): return %s.%s(%s)' % (
- name, args, selfvar, meth.func_name, params)
- mydict = {}
- print source
- exec source in mydict
- return mydict[name]
-
-
-def compile_dll(filename, dllname=None, copy_dll=True):
- dirname, name = os.path.split(filename)
- if dllname is None:
- dllname, _ = os.path.splitext(name)
- elif dllname.endswith('.dll'):
- dllname, _ = os.path.splitext(dllname)
- module = new.module(dllname)
- namespace = module.__dict__.get('_namespace_', dllname)
- sys.path.insert(0, dirname)
- execfile(filename, module.__dict__)
- sys.path.pop(0)
-
- dll = DllDef(dllname, namespace)
- dll.functions = collect_entrypoints(module.__dict__)
- dll.compile()
- if copy_dll:
- dll.driver.copy_cli_dll()
-
-def main(argv):
- if len(argv) == 2:
- filename = argv[1]
- dllname = None
- elif len(argv) == 3:
- filename = argv[1]
- dllname = argv[2]
- else:
- print >> sys.stderr, __doc__
- sys.exit(2)
-
- if not filename.endswith('.py'):
- filename += '.py'
- if not os.path.exists(filename):
- print >> sys.stderr, "Cannot find file %s" % filename
- sys.exit(1)
- compile_dll(filename, dllname)
-
-if __name__ == '__main__':
- main(sys.argv)
-
diff --git a/pypy/doc/config/objspace.usemodules.exceptions.rst b/pypy/doc/config/objspace.usemodules.exceptions.txt
copy from pypy/doc/config/objspace.usemodules.exceptions.rst
copy to pypy/doc/config/objspace.usemodules.exceptions.txt
diff --git a/pypy/doc/config/objspace.usepycfiles.rst b/pypy/doc/config/objspace.usepycfiles.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usepycfiles.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-If this option is used, then PyPy imports and generates "pyc" files in the
-same way as CPython. This is true by default and there is not much reason
-to turn it off nowadays. If off, PyPy never produces "pyc" files and
-ignores any "pyc" file that might already be present.
diff --git a/pypy/doc/config/objspace.usemodules.cpyext.rst b/pypy/doc/config/objspace.usemodules.cpyext.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.cpyext.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Use (experimental) cpyext module, that tries to load and run CPython extension modules
diff --git a/pypy/doc/config/objspace.usemodules.cmath.rst b/pypy/doc/config/objspace.usemodules.cmath.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.cmath.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Use the 'cmath' module.
-This module is expected to be working and is included by default.
diff --git a/pypy/doc/_ref.rst b/pypy/doc/_ref.rst
deleted file mode 100644
--- a/pypy/doc/_ref.rst
+++ /dev/null
@@ -1,107 +0,0 @@
-.. _`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/
diff --git a/pypy/doc/config/translation.profopt.rst b/pypy/doc/config/translation.profopt.txt
copy from pypy/doc/config/translation.profopt.rst
copy to pypy/doc/config/translation.profopt.txt
diff --git a/pypy/tool/rest/convert.py b/pypy/tool/rest/convert.py
deleted file mode 100644
--- a/pypy/tool/rest/convert.py
+++ /dev/null
@@ -1,163 +0,0 @@
-import py
-
-ExecutionFailed = py.process.cmdexec.Error
-# utility functions to convert between various formats
-
-format_to_dotargument = {"png": "png",
- "eps": "ps",
- "ps": "ps",
- "pdf": "ps",
- }
-
-def ps2eps(ps):
- # XXX write a pure python version
- if not py.path.local.sysfind("ps2epsi") and \
- not py.path.local.sysfind("ps2eps"):
- raise SystemExit("neither ps2eps nor ps2epsi found")
- try:
- eps = ps.new(ext=".eps")
- py.process.cmdexec('ps2epsi "%s" "%s"' % (ps, eps))
- except ExecutionFailed:
- py.process.cmdexec('ps2eps -l -f "%s"' % ps)
-
-def ps2pdf(ps, compat_level="1.2"):
- if not py.path.local.sysfind("gs"):
- raise SystemExit("ERROR: gs not found")
- pdf = ps.new(ext=".pdf")
- options = dict(OPTIONS="-dSAFER -dCompatibilityLevel=%s" % compat_level,
- infile=ps, outfile=pdf)
- cmd = ('gs %(OPTIONS)s -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite '
- '"-sOutputFile=%(outfile)s" %(OPTIONS)s -c .setpdfwrite '
- '-f "%(infile)s"') % options
- py.process.cmdexec(cmd)
- return pdf
-
-def eps2pdf(eps):
- # XXX write a pure python version
- if not py.path.local.sysfind("epstopdf"):
- raise SystemExit("ERROR: epstopdf not found")
- py.process.cmdexec('epstopdf "%s"' % eps)
-
-def dvi2eps(dvi, dest=None):
- if dest is None:
- dest = eps.new(ext=".eps")
- command = 'dvips -q -E -n 1 -D 600 -p 1 -o "%s" "%s"' % (dest, dvi)
- if not py.path.local.sysfind("dvips"):
- raise SystemExit("ERROR: dvips not found")
- py.process.cmdexec(command)
-
-def convert_dot(fn, new_extension):
- if not py.path.local.sysfind("dot"):
- raise SystemExit("ERROR: dot not found")
- result = fn.new(ext=new_extension)
- print result
- arg = "-T%s" % (format_to_dotargument[new_extension], )
- py.std.os.system('dot "%s" "%s" > "%s"' % (arg, fn, result))
- if new_extension == "eps":
- ps = result.new(ext="ps")
- result.move(ps)
- ps2eps(ps)
- ps.remove()
- elif new_extension == "pdf":
- # convert to eps file first, to get the bounding box right
- eps = result.new(ext="eps")
- ps = result.new(ext="ps")
- result.move(ps)
- ps2eps(ps)
- eps2pdf(eps)
- ps.remove()
- eps.remove()
- return result
-
-
-class latexformula2png(object):
- def __init__(self, formula, dest, temp=None):
- self.formula = formula
- try:
- import Image
- self.Image = Image
- self.scale = 2 # create a larger image
- self.upscale = 5 # create the image upscale times larger, then scale it down
- except ImportError:
- self.scale = 2
- self.upscale = 1
- self.Image = None
- self.output_format = ('pngmono', 'pnggray', 'pngalpha')[2]
- if temp is None:
- temp = py.test.ensuretemp("latexformula")
- self.temp = temp
- self.latex = self.temp.join('formula.tex')
- self.dvi = self.temp.join('formula.dvi')
- self.eps = self.temp.join('formula.eps')
- self.png = self.temp.join('formula.png')
- self.saveas(dest)
-
- def saveas(self, dest):
- self.gen_latex()
- self.gen_dvi()
- dvi2eps(self.dvi, self.eps)
- self.gen_png()
- self.scale_image()
- self.png.copy(dest)
-
- def gen_latex(self):
- self.latex.write ("""
- \\documentclass{article}
- \\pagestyle{empty}
- \\begin{document}
-
- %s
- \\pagebreak
-
- \\end{document}
- """ % (self.formula))
-
- def gen_dvi(self):
- origdir = py.path.local()
- self.temp.chdir()
- py.process.cmdexec('latex "%s"' % (self.latex))
- origdir.chdir()
-
- def gen_png(self):
- tempdir = py.path.local.mkdtemp()
-
- re_bbox = py.std.re.compile('%%BoundingBox:\s*(\d+) (\d+) (\d+) (\d+)')
- eps = self.eps.read()
- x1, y1, x2, y2 = [int(i) for i in re_bbox.search(eps).groups()]
- X = x2 - x1 + 2
- Y = y2 - y1 + 2
- mx = -x1
- my = -y1
- ps = self.temp.join('temp.ps')
- source = self.eps
- ps.write("""
- 1 1 1 setrgbcolor
- newpath
- -1 -1 moveto
- %(X)d -1 lineto
- %(X)d %(Y)d lineto
- -1 %(Y)d lineto
- closepath
- fill
- %(mx)d %(my)d translate
- 0 0 0 setrgbcolor
- (%(source)s) run
-
- """ % locals())
-
- sx = int((x2 - x1) * self.scale * self.upscale)
- sy = int((y2 - y1) * self.scale * self.upscale)
- res = 72 * self.scale * self.upscale
- command = ('gs -q -g%dx%d -r%dx%d -sDEVICE=%s -sOutputFile="%s" '
- '-dNOPAUSE -dBATCH "%s"') % (
- sx, sy, res, res, self.output_format, self.png, ps)
- py.process.cmdexec(command)
-
- def scale_image(self):
- if self.Image is None:
- return
- image = self.Image.open(str(self.png))
- image.resize((image.size[0] / self.upscale,
- image.size[1] / self.upscale),
- self.Image.ANTIALIAS).save(str(self.png))
-
diff --git a/pypy/doc/config/objspace.usemodules._ffi.rst b/pypy/doc/config/objspace.usemodules._ffi.rst
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules._ffi.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Applevel interface to libffi. It is more high level than _rawffi, and most importantly it is JIT friendly
diff --git a/pypy/doc/config/translation.backendopt.inline_threshold.rst b/pypy/doc/config/translation.backendopt.inline_threshold.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.inline_threshold.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Weight threshold used to decide whether to inline flowgraphs.
-This is for basic inlining (:config:`translation.backendopt.inline`).
diff --git a/pypy/doc/config/objspace.std.withdictmeasurement.rst b/pypy/doc/config/objspace.std.withdictmeasurement.txt
copy from pypy/doc/config/objspace.std.withdictmeasurement.rst
copy to pypy/doc/config/objspace.std.withdictmeasurement.txt
diff --git a/pypy/doc/config/translation.backendopt.stack_optimization.rst b/pypy/doc/config/translation.backendopt.stack_optimization.txt
copy from pypy/doc/config/translation.backendopt.stack_optimization.rst
copy to pypy/doc/config/translation.backendopt.stack_optimization.txt
diff --git a/pypy/doc/config/translation.make_jobs.rst b/pypy/doc/config/translation.make_jobs.txt
copy from pypy/doc/config/translation.make_jobs.rst
copy to pypy/doc/config/translation.make_jobs.txt
diff --git a/pypy/doc/svn-help.rst b/pypy/doc/svn-help.rst
deleted file mode 100644
--- a/pypy/doc/svn-help.rst
+++ /dev/null
@@ -1,153 +0,0 @@
-
-Installing subversion for PyPy
-==============================
-
-Jens-Uwe Mager has prepared some installation files which should
-help you to install subversion on your computer.
-
-+ Download Unix source tarball or prepackaged versions_ for MacOS, Windows, FreeBSD and Linux
-
-+ Additional information for Windows users:
-
- * See Microsoft website_ if you have .DLL issues.
-
- * Windows Installer file for Tortoise SVN (like Tortoise CVS) GUI_
- (Pick the UNICODE version for Windows 2000 and XP and
- see Win_ 2000, NT if you have problems loading it.)
-
-+ Local copy of MacOS_ X binary tar ball
- (This requires at least OS X 10.3)
-
-+ Debian instructions below...
-
-Getting started
------------------
-
-If you're just getting started with subversion, here's a simple how-to.
-For complete information, you can go read the subversion guide_.
-
-**Download and install the appropriate installation file of subversion above.**
-
-For linux:
-
-download the tarball. unzip and untar it. Then type *./configure*. Then, as root, *make* followed by *make install*. Voila ... a subversion client.
-
-For Debian users::
-
- $ apt-get install subversion-tools
-
-People using Debian *stable* first need to add the following line to ``/etc/apt/sources.list`` (thanks backports_!)::
-
- deb http://fs.cs.fhm.edu/mirror/backports.org/debian stable subversion
-
-Note that you can always go look at the files online_ with your browser, located at: http://codespeak.net/svn/pypy/trunk
-But, you'll want to check out your own local copies to work on.
-
-Check out and Check in
-----------------------------
-
-In order to get the sourcecode and docs downloaded onto your drive, open a shell or commandline and type::
-
- $ svn co http://codespeak.net/svn/pypy/trunk
-
-If you are behind a dump proxy this may or may not work; see below.
-
-Once you've got the files checked out to your own system, you can use your favorite text editor to change to files. Be sure to read the coding-guide_ and other documentation files before doing a lot of work on the source code. Before doing any work, make sure you're using the most recent update with::
-
- $ svn up
-
-this will update whichever subdirectory you're in (doc or src).
-
-When you're ready to **check in** a file,
-
-cd to your local checked out sourcecode directory, and if necessary, copy the file over from wherever you worked on it::
-
- $ cp ~/mydir/filename.ext filename.ext
-
-If you're adding a brand-new file::
-
- $ svn add filename.ext
-
-Then, to **commit** it::
-
- $ svn ci -m "your comments about what changes your committing"
- $ your password: (this may not be necessary)
-
-You'll see something like the following::
-
- Adding goals/stringcomp.py
- Transmitting file data .
- Committed revision 578.
-
-or::
-
- Sending coding-guide.txt
- Transmitting file data .
- Committed revision 631.
-
-Check online on the `svn-commit archives`_ and you'll see your revision. Feel free to add a documentation file on any major changes you've made!
-
-.. _`svn-commit archives`: http://codespeak.net/pipermail/pypy-svn/
-
-Some other useful subversion tricks:
---------------------------------------
-
-**Be sure to remember ``svn`` in the commandline in the following commands.**
-
-``$ svn mv filename.ext``
- to move or rename a file
-
-``$ svn rm filename.ext``
- to remove (delete) a file
-
-``$ svn status``
- will let you know what changes you've made compared to the current repository version
-
-``$ svn revert filename.ext``
- will fix problems if you deleted or moved a file without telling svn.
-
-``$ svn cleanup``
- last resort to fix it if you've got a totally messed up local copy.
- Use this if you see error messages about ``locked`` files that you can't fix otherwise.
-
-Circumventing proxies
-----------------------------
-
-Some proxies don't let extended HTTP commands through. If you have an
-error complaining about a bad request, you should use https: instead of
-http: in the subversion URL. This will make use of SSL encryption, which
-cannot be intercepted by proxies.
-
-Alternatively, if you want to change your proxy configuration, see the
-subversion FAQ: http://subversion.tigris.org/faq.html#proxy
-
-How to Avoid Line-ending Hell
------------------------------
-
-We will assume that whenever you create a .txt or a .py file, you would
-like other people to be able to read it with the line endings their
-OS prefers, even if that is different from the one your OS likes. This
-could occasionally be wrong -- say when you are specifically testing
-that code you are writing handles line endings properly -- but this is
-what you want by default. Binary files, on the other hand, should be
-stored exactly as is. This has to be set on every client. Here is how:
-
-In your home directory edit .subversion/config and comment in ::
-
- [miscellany]
- enable-auto-props = yes
-
- [auto-props]
- *.txt = svn:eol-style=native
- *.py = svn:eol-style=native
-
-
-.. _website: http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B259403
-.. _GUI: http://tortoisesvn.tigris.org/servlets/ProjectDocumentList?folderID=616
-.. _MacOS: http://codespeak.net/~jum/svn-1.4.0-darwin-ppc.tar.gz
-.. _versions: http://subversion.tigris.org/project_packages.html
-.. _Win: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4B6140F9-2D36-4977-8FA1-6F8A0F5DCA8F
-.. _guide: http://svnbook.red-bean.com/book.html#svn-ch-1
-.. _backports: http://www.backports.org
-.. _online: http://codespeak.net/svn/pypy/trunk/
-.. _coding-guide: coding-guide.html
diff --git a/pypy/doc/config/translation.backendopt.storesink.rst b/pypy/doc/config/translation.backendopt.storesink.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.backendopt.storesink.rst
+++ /dev/null
@@ -1,1 +0,0 @@
-Store sinking optimization. On by default.
diff --git a/pypy/doc/discussion/distribution-newattempt.rst b/pypy/doc/discussion/distribution-newattempt.rst
deleted file mode 100644
--- a/pypy/doc/discussion/distribution-newattempt.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-Distribution:
-=============
-
-This is outcome of Armin's and Samuele's ideas and our discussion,
-kept together by fijal.
-
-The communication layer:
-========================
-
-Communication layer is the layer which takes care of explicit
-communication. Suppose we do have two (or more) running interpreters
-on different machines or in different processes. Let's call it *local side*
-(the one on which we're operating) and *remote side*.
-
-What we want to achieve is to have a transparent enough layer on local
-side, which does not allow user to tell the objects local and remote apart
-(despite __pypy__.internal_repr, which I would consider cheating).
-
-Because in pypy we have possibility to have different implementations
-for types (even builtin ones), we can use that mechanism to implement
-our simple RMI.
-
-The idea is to provide thin layer for accessing remote object, lays as
-different implementation for any possible object. So if you perform any
-operation on an object locally, which is really a remote object, you
-perform all method lookup and do a call on it. Than proxy object
-redirects the call to app-level code (socket, execnet, whatever) which
-calls remote interpreter with given parameters. It's important that we
-can always perform such a call, even if types are not marshallable, because
-we can provide remote proxies of local objects to remote side in that case.
-
-XXX: Need to explain in a bit more informative way.
-
-Example:
---------
-
-Suppose we do have ``class A`` and instance ``a = A()`` on remote side
-and we want to access this from a local side. We make an object of type
-``object`` and we do copy
-``__dict__`` keys with values, which correspond to objects on the remote
-side (have the same type to user) but they've got different implementation.
-(Ie. method calling will look like quite different).
-
-Even cooler example:
---------------------
-
-Reminding hpk's example of 5-liner remote file server. With this we make::
-
- f = remote_side.import(open)
- f("file_name").read()
-
-Implementation plans:
----------------------
-
-We need:
-
-* app-level primitives for having 'remote proxy' accessible
-
-* some "serialiser" which is not truly serialising stuff, but making
- sure communication will go.
-
-* interp-level proxy object which emulates every possible object which
- delegates operations to app-level primitive proxy.
-
-* to make it work....
diff --git a/pypy/doc/config/translation.thread.rst b/pypy/doc/config/translation.thread.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.thread.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Enable threading. The only target where this has visible effect is PyPy (this
-also enables the ``thread`` module then).
diff --git a/pypy/doc/config/translation.no__thread.rst b/pypy/doc/config/translation.no__thread.rst
deleted file mode 100644
--- a/pypy/doc/config/translation.no__thread.rst
+++ /dev/null
@@ -1,4 +0,0 @@
-Don't use gcc __thread attribute for fast thread local storage
-implementation . Increases the chance that moving the resulting
-executable to another same processor Linux machine will work. (see
-:config:`translation.vanilla`).
diff --git a/pypy/doc/parser.rst b/pypy/doc/parser.rst
--- a/pypy/doc/parser.rst
+++ b/pypy/doc/parser.rst
@@ -100,4 +100,4 @@
information like the line number table and stack depth are computed. Finally,
everything is passed to a brand new ``PyCode`` object.
-.. include:: _ref.rst
+.. include:: _ref.txt
diff --git a/pypy/doc/conf.py b/pypy/doc/conf.py
--- a/pypy/doc/conf.py
+++ b/pypy/doc/conf.py
@@ -16,13 +16,13 @@
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.append(os.path.abspath('.'))
+sys.path.append(os.path.abspath('.'))
# -- General configuration -----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx.ext.ifconfig']
+extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx.ext.ifconfig', 'sphinx.ext.graphviz', 'pypyconfig']
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
@@ -120,7 +120,7 @@
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+# html_static_path = ['_static']
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
@@ -138,7 +138,7 @@
#html_additional_pages = {}
# If false, no module index is generated.
-#html_use_modindex = True
+html_use_modindex = False
# If false, no index is generated.
#html_use_index = True
@@ -191,8 +191,9 @@
#latex_appendices = []
# If false, no module index is generated.
-#latex_use_modindex = True
+latex_use_modindex = False
# Example configuration for intersphinx: refer to the Python standard library.
intersphinx_mapping = {'http://docs.python.org/': None}
+
More information about the Pypy-commit
mailing list