[pypy-svn] rev 1944 - pypy/trunk/doc/funding

[pedronis at codespeak.net]

Author: pedronis
Date: Wed Oct 15 00:26:27 2003
New Revision: 1944

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
Log:
typos.


Modified: pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
==============================================================================
--- pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	(original)
+++ pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	Wed Oct 15 00:26:27 2003
@@ -50,7 +50,7 @@
 -------
 
 The first goal is to develop a reasonably complete Python interpreter written
-in Python. It must be entierely compatible with the language specification. It
+in Python. It must be entirely compatible with the language specification. It
 consists of the following major parts:
 
 - A *bytecode compiler,* which inputs Python source code and outputs an internal
@@ -141,7 +141,7 @@
 usual sense of the word. The net result is that we can actually analyse
 RPython source code without writing any code specific to the language (!),
 given that we already have a bytecode interpreter which is flexible enough to
-accomodate a non-standard Object Space. In other words, the combination of
+accommodate a non-standard Object Space. In other words, the combination of
 PyPy and an "abstract" Object Space performs as the front-end of the
 translator, and can be used to translate (for example) the regular PyPy
 interpreter and its standard Object Space. Note the two different roles played
@@ -194,7 +194,7 @@
   environment. Such data is notoriously hard to obtain in monolithic
   interpreters. This is the focus of WP06_.
 
-- Similarily, as described above, pervasive design decisions can be
+- Similarly, as described above, pervasive design decisions can be
   experimented with by tailoring the translator. This is the focus of WP07_.
 
 We will in particular investigate in detail two specific ways to customize the
@@ -219,7 +219,7 @@
   turn individual operation orders into processor instructions, together with a
   supporting runtime systems. This is defined by WP08_.
 
-In dynamic languges, the truth behind JIT compiling is a bit more involved
+In dynamic languages, the truth behind JIT compiling is a bit more involved
 than the above paragraph suggests. All the "standard" operations in Python,
 including intuitively simple ones, are in fact relatively complex because
 they depend heavily on the runtime type of the objects involved. This complex
@@ -328,9 +328,9 @@
 feature that would benefit from being implemented at the language level. This
 is a vast subject which has been studied extensively. There are several
 implementations already available in Python, with varying degrees of
-transparence. None however can be fully transparent by definition of the
+transparency. None however can be fully transparent by definition of the
 language itself, which allows introspection -- a program using introspection
-features could thus defeat the delicate mecanisms introduced by a network
+features could thus defeat the delicate mechanisms introduced by a network
 distribution library. Moreover, such libraries typically impose additional
 constrains, e.g. are only able to move objects over a network if they are of a
 class inheriting from a particular class.
@@ -358,7 +358,7 @@
 already expressed high interest in PyPy. Indeed, they would benefit
 from better language integration; they currently put non-natural
 constrains on the programmer in terms of what he is allowed to do for
-persistence to actually work transparenty. Typically, it is not
+persistence to actually work transparently. Typically, it is not
 possible for a library to detect changes such as adding elements to
 lists, so that list objects cannot be automatically marked as "dirty"
 (as needed to ensure they will transparently be saved when
@@ -493,7 +493,7 @@
 - performing backups for all relevant information/code;
 
 - setting up a mirror repository which is kept up-to-date and which can be
-  used readonly in case of failure of the main repository;
+  used read-only in case of failure of the main repository;
   
 - taking care of regular repository backups, designing a strict backup policy
   suitable for the project, and adhering to it.