[pypy-commit] pypy default: Merged in cpher/pypy (pull request #128)

[fijal]

Author: Maciej Fijalkowski <fijall at gmail.com>
Branch: 
Changeset: r61676:572046a663a0
Date: 2013-02-23 15:38 +0200
http://bitbucket.org/pypy/pypy/changeset/572046a663a0/

Log:	Merged in cpher/pypy (pull request #128)

	Minor doc fixes

diff --git a/pypy/doc/cpython_differences.rst b/pypy/doc/cpython_differences.rst
--- a/pypy/doc/cpython_differences.rst
+++ b/pypy/doc/cpython_differences.rst
@@ -134,7 +134,7 @@
 ``ReferenceError`` at any place that uses them.  (Or, better yet, don't use
 ``weakref.proxy()`` at all; use ``weakref.ref()``.)
 
-There are a few extra implications for the difference in the GC.  Most
+There are a few extra implications from the difference in the GC.  Most
 notably, if an object has a ``__del__``, the ``__del__`` is never called more
 than once in PyPy; but CPython will call the same ``__del__`` several times
 if the object is resurrected and dies again.  The ``__del__`` methods are
@@ -156,7 +156,7 @@
 
 .. __: http://bugs.pypy.org/issue736
 
-Using the default GC called ``minimark``, the built-in function ``id()``
+Using the default GC (called ``minimark``), the built-in function ``id()``
 works like it does in CPython.  With other GCs it returns numbers that
 are not real addresses (because an object can move around several times)
 and calling it a lot can lead to performance problem.
@@ -286,7 +286,7 @@
 -------------
 
 * Hash randomization (``-R``) is ignored in PyPy.  As documented in
-  http://bugs.python.org/issue14621 , some of us believe it has no
+  http://bugs.python.org/issue14621, some of us believe it has no
   purpose in CPython either.
 
 * ``sys.setrecursionlimit(n)`` sets the limit only approximately,
diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -202,20 +202,20 @@
 Be sure to enable it again if you need it!
 
 
-The PyPy translation tool chain
-===============================
+The RPython translation tool chain
+===================================
 
----------------------------------------------
-Can PyPy compile normal Python programs to C?
----------------------------------------------
+------------------------------------------------
+Can RPython compile normal Python programs to C?
+------------------------------------------------
 
-No, PyPy is not a Python compiler.
+No, RPython is not a Python compiler.
 
 In Python, it is mostly impossible to *prove* anything about the types
 that a program will manipulate by doing a static analysis.  It should be
 clear if you are familiar with Python, but if in doubt see [BRETT]_.
 
-If you want a fast Python program, please use our JIT_ instead.
+If you want a fast Python program, please use the PyPy JIT_ instead.
 
 .. _JIT: jit/index.html
 
@@ -300,8 +300,8 @@
 Do I have to rewrite my programs in RPython?
 --------------------------------------------
 
-No.  And you shouldn't try.  First and foremost, RPython is a language
-that is designed to write interpreters in.  It is a restricted subset of
+No, and you shouldn't try.  First and foremost, RPython is a language
+designed for writing interpreters. It is a restricted subset of
 Python.  If you program is not an interpreter but tries to do "real
 things", like use *any* part of the standard Python library or *any*
 3rd-party library, then it is not RPython to start with.  You should
@@ -381,8 +381,8 @@
 
 No, you have to rebuild the entire interpreter.  This means two things:
 
-* It is imperative to use test-driven development.  You have to test
-  exhaustively your module in pure Python, before even attempting to
+* It is imperative to use test-driven development.  You have to exhaustively
+  test your module in pure Python, before even attempting to
   translate it.  Once you translate it, you should have only a few typing
   issues left to fix, but otherwise the result should work out of the box.
 
diff --git a/pypy/doc/getting-started-dev.rst b/pypy/doc/getting-started-dev.rst
--- a/pypy/doc/getting-started-dev.rst
+++ b/pypy/doc/getting-started-dev.rst
@@ -20,7 +20,7 @@
 
 To start the interactive translator shell do::
 
-    cd pypy
+    cd rpython
     python bin/translatorshell.py
 
 Test snippets of translatable code are provided in the file
diff --git a/pypy/doc/interpreter.rst b/pypy/doc/interpreter.rst
--- a/pypy/doc/interpreter.rst
+++ b/pypy/doc/interpreter.rst
@@ -25,7 +25,7 @@
 compact bytecode format as CPython 2.7, with minor differences in the bytecode
 set.  Our bytecode compiler is
 implemented as a chain of flexible passes (tokenizer, lexer, parser,
-abstract syntax tree builder, bytecode generator).  The latter passes
+abstract syntax tree builder and bytecode generator).  The latter passes
 are based on the ``compiler`` package from the standard library of
 CPython, with various improvements and bug fixes. The bytecode compiler
 (living under `pypy/interpreter/astcompiler/`_) is now integrated and is
@@ -38,8 +38,8 @@
 calling its ``frame.eval()`` method.  This main entry point 
 initialize appropriate namespaces and then interprets each 
 bytecode instruction.  Python's standard library contains
-the `lib-python/2.7/dis.py`_ module which allows to view
-the Virtual's machine bytecode instructions:: 
+the `lib-python/2.7/dis.py`_ module which allows to inspection 
+of the virtual machine's bytecode instructions:: 
 
     >>> import dis
     >>> def f(x):
@@ -50,10 +50,10 @@
               6 BINARY_ADD          
               7 RETURN_VALUE        
 
-CPython as well as PyPy are stack-based virtual machines, i.e.
-they don't have registers but put object to and pull objects
+CPython and PyPy are stack-based virtual machines, i.e.
+they don't have registers but instead push object to and pull objects
 from a stack.  The bytecode interpreter is only responsible
-for implementing control flow and putting and pulling black
+for implementing control flow and pushing and pulling black
 box objects to and from this value stack.  The bytecode interpreter 
 does not know how to perform operations on those black box
 (`wrapped`_) objects for which it delegates to the `object
@@ -75,8 +75,8 @@
 on ``OperationErrors``. 
 
 The interpreter implementation offers mechanisms to allow a
-caller to be unaware if a particular function invocation leads
-to bytecode interpretation or is executed directly at
+caller to be unaware of whether a particular function invocation 
+leads to bytecode interpretation or is executed directly at
 interpreter-level.  The two basic kinds of `Gateway classes`_
 expose either an interpreter-level function to
 application-level execution (``interp2app``) or allow