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

[hpk at codespeak.net]

Author: hpk
Date: Wed Nov 30 20:41:23 2005
New Revision: 20451

Added:
   pypy/extradoc/talk/22c3/translation-greyscale-small.pdf
      - copied unchanged from r20445, pypy/dist/pypy/doc/image/translation-greyscale-small.pdf
   pypy/extradoc/talk/22c3/translation-greyscale-small.png
      - copied unchanged from r20445, pypy/dist/pypy/doc/image/translation-greyscale-small.png
Modified:
   pypy/extradoc/talk/22c3/techpaper.txt
Log:
removed some references, substituted some with
full URL links ... but am not sure yet.  Typing
long URLs from a book is not really common ... 



Modified: pypy/extradoc/talk/22c3/techpaper.txt
==============================================================================
--- pypy/extradoc/talk/22c3/techpaper.txt	(original)
+++ pypy/extradoc/talk/22c3/techpaper.txt	Wed Nov 30 20:41:23 2005
@@ -128,10 +128,10 @@
 The *standard interpreter* is the subsystem implementing the Python language.
 It is divided into two components:
 
-- the `bytecode interpreter`_ which is responsible for interpreting 
+- the bytecode interpreter which is responsible for interpreting 
   code objects and implementing bytecodes,
 
-- the `standard object space`_ which implements creating, accessing and
+- the standard object space which implements creating, accessing and
   modifying application level objects.
 
 Note that the *standard interpreter* can run fine on top of CPython if one
@@ -150,14 +150,10 @@
 
 This division between bytecode interpreter and object space is very
 important, as it gives a lot of flexibility. It is possible to use
-different `object spaces`_ to get different behaviours of the Python
+different object spaces to get different behaviours of the Python
 objects.  Using a special object space is also an important technique
 for our translation process.
 
-.. _`bytecode interpreter`: interpreter.html
-.. _`standard object space`: objspace.html#the-standard-object-space
-.. _`object spaces`: objspace.html
-
 The Translation Process
 -----------------------
 
@@ -166,7 +162,7 @@
 is done in four steps:
 
 - producing a *flow graph* representation of the standard interpreter. 
-  A combination of the `bytecode interpreter`_ and a *flow object space*
+  A combination of the bytecode interpreter and a *flow object space*
   performs *abstract interpretation* to record the flow of objects
   and execution throughout a python program into such a *flow graph*;
 
@@ -200,7 +196,7 @@
 when the initialization phase (mainly, the function
 ``objspace.initialize()``) finishes, all code objects involved need to
 adhere to a more static subset of Python:
-Restricted Python, also known as `RPython`_. 
+Restricted Python, also known as RPython. 
 
 The Flow Object Space then, with the help of our bytecode interpreter,
 works through those initialized RPython code objects.  The result of
@@ -213,7 +209,7 @@
 
 The flow graphs are fed as input into the Annotator.  The Annotator,
 given entry point types, infers the types of values that flow through
-the program variables.  This is the core of the definition of `RPython`_:
+the program variables.  This is the core of the definition of RPython:
 RPython code is restricted in such a way that the
 Annotator is able to infer consistent types.  How much
 dynamism we allow in RPython depends on, and is restricted by, the Flow
@@ -238,9 +234,9 @@
 uses them to modify the flow graph in-place to replace its operations with
 low-level ones, directly manipulating C-like values and data structures.
 
-Here is an overview of the whole process (`PDF color version`_):
+Here is an overview of the whole process. 
 
-    .. image:: image/translation-greyscale-small.png
+    .. image:: translation-greyscale-small.png
 
 The complete translation process is described in more details in the
 `translation document`_.  You might also be interested in reading the
@@ -269,8 +265,8 @@
 will come from our Just-In-Time compiler work, which we have barely started
 at the moment.
 
-With the 0.8.0 release the "thunk" object space can also be translated
-(see `getting started`_), obtaining a self-contained version of PyPy
+With the 0.8.0 release the "thunk" object space can also be translated, 
+obtaining a self-contained version of PyPy
 with its features (and some speed degradation), show-casing at a small
 scale how our whole tool-chain supports flexibility from the interpreter
 written in Python to the resulting self-contained executable.
@@ -312,12 +308,8 @@
 .. _`statistics web page`: http://codespeak.net/~hpk/pypy-stat/
 .. _`very compliant`: http://codespeak.net/~hpk/pypy-testresult/
 .. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
-.. _`RPython`: coding-guide.html#rpython
-.. _`abstract interpretation`: theory.html#abstract-interpretation
-.. _`Compiling dynamic language implementations`: dynamic-language-translation.html
-.. _`translation document`: translation.html
+.. _`abstract interpretation`: http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation
+.. _`Compiling dynamic language implementations`: http://codespeak.net/pypy/dist/pypy/doc/dynamic-language-translation.html
+.. _`translation document`: http://codespeak.net/pypy/dist/pypy/doc/translation.html
 .. _LLVM: http://llvm.cs.uiuc.edu/
-.. _`PDF color version`: image/translation.pdf
-.. _`getting started`: getting-started.html
 
-.. include:: _ref.txt