[pypy-svn] r29083 - pypy/dist/pypy/doc

[mwh at codespeak.net]

Author: mwh
Date: Wed Jun 21 17:51:46 2006
New Revision: 29083

Modified:
   pypy/dist/pypy/doc/translation.txt
Log:
some kind of speel-check


Modified: pypy/dist/pypy/doc/translation.txt
==============================================================================
--- pypy/dist/pypy/doc/translation.txt	(original)
+++ pypy/dist/pypy/doc/translation.txt	Wed Jun 21 17:51:46 2006
@@ -21,8 +21,8 @@
 Overview
 ========
 
-The job of translation tool-chain is to translate RPython_ progams into an
-efficient version of that progam for one of various target platforms,
+The job of translation tool-chain is to translate RPython_ programs into an
+efficient version of that program for one of various target platforms,
 generally one that is considerably lower-level than Python.  It divides
 this task into several steps, and the purpose of this document is to
 introduce them.
@@ -181,7 +181,7 @@
 
 Mutable objects need special treatment during annotation, because
 the annotation of contained values needs to be possibly updated to account
-for mutation operations, and consequentely the annotation information
+for mutation operations, and consequently the annotation information
 reflown through the relevant parts of the flow the graphs.
 
 * ``SomeList`` stands for a list of homogeneous type (i.e. all the
@@ -264,11 +264,11 @@
 
 In theory, this step is optional; a code generator might be able to read
 directly the high-level types.  Our experience, however, suggests that this is
-very unlikely to be pratical.  "Compiling" high-level types into low-level
+very unlikely to be practical.  "Compiling" high-level types into low-level
 ones is rather more messy than one would expect and this was the motivation
 for making this step explicit and isolated in a single place.  After RTyping,
 the graphs only contain operations that already live on the level of the
-target langiage, which makes the job of the code generators much simpler.
+target language, which makes the job of the code generators much simpler.
 
 For more detailed information, see the `documentation for the RTyper`_.
 
@@ -367,7 +367,7 @@
 http://codespeak.net/pypy/dist/pypy/translator/c/
 
 GenC is not really documented at the moment.  The basic principle of creating
-code from flowgraphs is similar to the `Python back-end`_.  See also
+code from flow graphs is similar to the `Python back-end`_.  See also
 `Generating C code`_ in another draft.
 
 GenC is usually the most actively maintained backend -- everyone working on
@@ -429,7 +429,7 @@
 version based on the new `RPython Typer`_ flow graph. Significant progress was
 made during the Gothenburg sprint - and then the following 6 weeks Eric and
 Richard worked on it, achieving a standalone executable just prior to the
-Heidelberg sprint.  During the Heildelberg sprint Eric and Richard mainly
+Heidelberg sprint.  During the Heidelberg sprint Eric and Richard mainly
 worked on sharing the backend external code with GenC.
 
 .. _`low level virtual machine`: http://llvm.org/
@@ -458,7 +458,7 @@
 ++++++
 
 GenCLI targets the `Common Language Infrastructure`_, the most famous
-implementations of which are Mircrosoft's `.NET`_ and Mono_.
+implementations of which are Microsoft's `.NET`_ and Mono_.
 
 .. _`Common Language Infrastructure`: http://www.ecma-international.org/publications/standards/Ecma-335.htm
 .. _`.NET`: http://www.microsoft.com/net/
@@ -543,7 +543,7 @@
 implemented by writing backend code by hand that either implements the
 functionality itself or calls appropriate libraries.
 
-Of course the annotator does not know what types these funtions return so we
+Of course the annotator does not know what types these functions return so we
 need a way to attach fixed annotations to such functions. Additionally for
 every such function we need a low level helper function that behaves like the
 hand-written backend code so that we can still test a call to such an external
@@ -560,7 +560,7 @@
 
     declare(funct, annotation_factory, lowlevel_dummy)
 
-Here ``funct`` is the funtion that is supposed to be implemented in the
+Here ``funct`` is the function that is supposed to be implemented in the
 backend, ``annotation_factory`` is a function that returns an appropriate
 annotation of the return value (an instance of a primitive type is also ok, so
 you can do ``declare(func, int...)``), lowlevel_dummy is a string of the form
@@ -575,14 +575,14 @@
 ``module.ll_function``. The backend is supposed to replace calls to functions
 to ``module.ll_function`` by whatever code it finds appropriate.
 
-Implementating low level replacement functions in Python
+Implementing low level replacement functions in Python
 ---------------------------------------------------------
 
 The dummy low level replacement functions are there to implement the external
 function on the low level. In contrast to the original function they should
 take arguments that are of `low-level type`_. Most of the times they are
 implemented by calling appropriate low level to high level conversion
-functions and then calling the original funtion again.
+functions and then calling the original function again.
 
 .. _`low-level type`: rtyper.html#low-level-type
 
@@ -610,10 +610,10 @@
 the functionality of the ``module.ll_function``. These C implementation are
 found in the directory `pypy/translator/c/src/`_.
 
-It sometimes neccessary to access a certain function or type that is written
+It sometimes necessary to access a certain function or type that is written
 in Python from the C code you write by hand (for example for constructing the
 return value in the correct low level type). This can be a problem because the
-C backend mangels names to prevent clashes. To get a certain low level type
+C backend mangles names to prevent clashes. To get a certain low level type
 under a fixed name the function ``predeclare_common_types`` needs to be
 changed. This function is a generator that yields tuples of the form
 ``('c_name', LLTYPE)``. This makes the genc assign the name ``c_name`` to the