[pypy-svn] r20464 - pypy/extradoc/talk/22c3
mwh at codespeak.net
mwh at codespeak.net
Wed Nov 30 22:40:18 CET 2005
Date: Wed Nov 30 22:40:17 2005
New Revision: 20464
small tweaks and anglicizations.
--- pypy/extradoc/talk/22c3/techpaper.txt (original)
+++ pypy/extradoc/talk/22c3/techpaper.txt Wed Nov 30 22:40:17 2005
@@ -14,7 +14,7 @@
Eventually, dynamic optimization techniques - implemented as another
translation aspect - should become robust against language changes.
-.. [#] http://www.python.org/doc/current/ref/ref.html
+.. [#] http://docs.python.org/ref
PyPy - an implementation of Python in Python
@@ -31,7 +31,7 @@
written in C (referred to throughout the PyPy documentation and source as
-.. [#] http://python.org
+.. [#] http://www.python.org
Another central idea in PyPy is building the implementation in the form
of a number of independent modules with clearly defined and well tested API's.
@@ -51,7 +51,7 @@
PyPy is not only about writing another Python interpreter.
-Traditionally, interpreters are written in some target platform language
+Traditionally, interpreters are written in a target platform language
like C/Posix, Java or C#. Each such interpreter provides a "mapping"
from application source code to the target environment. One of the
goals of the "all-encompassing" environments, like the .NET framework
@@ -64,20 +64,20 @@
Python interpreter for a specific target platform. We have written a
Python interpreter in Python, without many references to low-level
details. (Because of the nature of Python, this is already a
-complicated task, although not as much as writing it - say - in C.)
+complicated task, although not as much as writing it in - say - C.)
Then we use this as a "language specification" and manipulate it to
produce the more traditional interpreters that we want. In the above
sense, we are generating the concrete "mappings" of Python into
lower-level target platforms.
-So far (fall 2005), we have already succeeded in turning this "language
+So far (autumn 2005), we have already succeeded in turning this "language
specification" into reasonably efficient C-level code that performs
basically the same job as CPython. Memory management is inserted during
-this "translation" process. It can be configured to use reference
+this *translation* process. It can be configured to use reference
counting or not; thus we have already achieved two very different
-"mappings" of application Python code over C/Posix. We have
-successfully translated our Python interpreter to the LLVM [#]_ target as
-well, and we are working on targeting higher-level environments like
+mappings of application Python code over C/Posix. We have
+successfully also translated our Python interpreter into the LLVM [#]_ code,
+and we are working on targeting higher-level environments like
Java and Squeak.
In some senses, PyPy project's central component is not its
@@ -103,9 +103,9 @@
as far as language implementation is concerned - showing an approach
to the ``n * m * o`` problem that does not rely on standardization.
-This is the "meta-goal"; a more concrete goal worth mentioning at this
+This is the *meta-goal*; a more concrete goal worth mentioning at this
point is that language specifications can be used to generate cool stuff
-in addition to traditional interpreters -- e.g. Just-In-Time Compilers.
+in addition to traditional interpreters -- e.g. Just-In-Time compilers.
.. [#] http://llvm.cs.uiuc.edu/
@@ -167,7 +167,7 @@
- the *annotator* which performs type inference on the flow graph;
- the *typer* which, based on the type annotations, turns the flow graph
- into one using only low-level, operations that fit the model of the
+ into one using only low-level operations that fit the model of the
- the *code generator* which translates the resulting flow graph into
@@ -189,8 +189,7 @@
Python code at some point. However, in the start-up phase, we are
completely free to use all kinds of powerful python constructs, including
metaclasses and execution of dynamically constructed strings. However,
-when the initialization phase (mainly, the function
-``objspace.initialize()``) finishes, all code objects involved need to
+when the initialization phase finishes, all code objects involved need to
adhere to a more static subset of Python:
Restricted Python, also known as RPython.
@@ -234,7 +233,7 @@
- overview over the translation process
+ overview of the translation process
The complete translation process is described in more detail in the
@@ -271,12 +270,12 @@
written in Python to the resulting self-contained executable.
Our rather complete and Python 2.4-compliant interpreter consists
-of about 30'000-50'000 lines of code (depending on the way you
+of about 30,000-50,000 lines of code (depending on the way you
count code borrowed and adapted from other sources), with
-another 14'000 lines of unit tests. If we include the tools,
+another 14,000 lines of unit tests. If we include the tools,
the parts related to code analysis and generation, and the
-standard library modules ported from C, PyPy is now 138'000
-lines of code and 32'000 lines of tests. Refer to
+standard library modules ported from C, PyPy is now 138,000
+lines of code and 32,000 lines of tests. Refer to
the statistics web page [#]_ for more detailed information.
.. [#] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
More information about the Pypy-commit