[pypy-svn] r20464 - pypy/extradoc/talk/22c3

[mwh at codespeak.net]

Author: mwh
Date: Wed Nov 30 22:40:17 2005
New Revision: 20464

Modified:
   pypy/extradoc/talk/22c3/techpaper.txt
Log:
small tweaks and anglicizations.


Modified: pypy/extradoc/talk/22c3/techpaper.txt
==============================================================================
--- 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
 "CPython" [#]_).
 
-.. [#] 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
   target platform;
 
 - 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 @@
 
    \begin{figure*}[htbp]\begin{center}
    \includegraphics{translation-greyscale-small.pdf}
-   overview over the translation process
+   overview of the translation process
    \end{center}\end{figure*}
 
 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/