Commits

Armin Rigo committed 864d702 Merge

hg merge default

Comments (0)

Files changed (462)

 under the Python Software License of which you can find a copy here:
 http://www.python.org/doc/Copyright.html 
 
-License for 'rpython/translator/jvm/src/jna.jar'
-=============================================
-
-The file 'rpyhton/translator/jvm/src/jna.jar' is licensed under the GNU
-Lesser General Public License of which you can find a copy here:
-http://www.gnu.org/licenses/lgpl.html
-
-License for 'rpython/translator/jvm/src/jasmin.jar'
-================================================
-
-The file 'rpyhton/translator/jvm/src/jasmin.jar' is copyright (c) 1996-2004 Jon Meyer
-and distributed with permission.  The use of Jasmin by PyPy does not imply
-that PyPy is endorsed by Jon Meyer nor any of Jasmin's contributors.  Furthermore,
-the following disclaimer applies to Jasmin:
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
-WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
-ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
-TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
-ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
 License for 'pypy/module/unicodedata/'
 ======================================
 

lib-python/2.7/distutils/sysconfig_pypy.py

 
 import sys
 import os
+import shlex
 
 from distutils.errors import DistutilsPlatformError
 
     g['SOABI'] = g['SO'].rsplit('.')[0]
     g['LIBDIR'] = os.path.join(sys.prefix, 'lib')
     g['CC'] = "gcc -pthread" # -pthread might not be valid on OS/X, check
-    g['OPT'] = ""
-    g['CFLAGS'] = ""
-    g['CPPFLAGS'] = ""
-    g['CCSHARED'] = '-shared -O2 -fPIC -Wimplicit'
-    g['LDSHARED'] = g['CC'] + ' -shared'
 
     global _config_vars
     _config_vars = g
     optional C speedup components.
     """
     if compiler.compiler_type == "unix":
-        cc, opt, cflags, ccshared, ldshared = get_config_vars(
-            'CC', 'OPT', 'CFLAGS', 'CCSHARED', 'LDSHARED')
-
+        compiler.compiler_so.extend(['-O2', '-fPIC', '-Wimplicit'])
         compiler.shared_lib_extension = get_config_var('SO')
-
-        if 'LDSHARED' in os.environ:
-            ldshared = os.environ['LDSHARED']
-        if 'CPP' in os.environ:
-            cpp = os.environ['CPP']
-        else:
-            cpp = cc + " -E"           # not always
-        if 'LDFLAGS' in os.environ:
-            ldshared = ldshared + ' ' + os.environ['LDFLAGS']
-        if 'CFLAGS' in os.environ:
-            cflags = opt + ' ' + os.environ['CFLAGS']
-            ldshared = ldshared + ' ' + os.environ['CFLAGS']
-        if 'CPPFLAGS' in os.environ:
-            cpp = cpp + ' ' + os.environ['CPPFLAGS']
-            cflags = cflags + ' ' + os.environ['CPPFLAGS']
-            ldshared = ldshared + ' ' + os.environ['CPPFLAGS']
-
-        cc_cmd = cc + ' ' + cflags
-
-        compiler.set_executables(
-            preprocessor=cpp,
-            compiler=cc_cmd,
-            compiler_so=cc_cmd + ' ' + ccshared,
-            linker_so=ldshared)
+        if "CPPFLAGS" in os.environ:
+            cppflags = shlex.split(os.environ["CPPFLAGS"])
+            compiler.compiler.extend(cppflags)
+            compiler.compiler_so.extend(cppflags)
+            compiler.linker_so.extend(cppflags)
+        if "CFLAGS" in os.environ:
+            cflags = shlex.split(os.environ["CFLAGS"])
+            compiler.compiler.extend(cflags)
+            compiler.compiler_so.extend(cflags)
+            compiler.linker_so.extend(cflags)
+        if "LDFLAGS" in os.environ:
+            ldflags = shlex.split(os.environ["LDFLAGS"])
+            compiler.linker_so.extend(ldflags)
 
 
 from sysconfig_cpython import (

lib_pypy/_pypy_irc_topic.py

 Nyy rkprcgoybpxf frrz fnar.
 N cvax tyvggrel ebgngvat ynzoqn
 "vg'f yvxryl grzcbenel hagvy sberire" nevtb
+"Lbh xabj jung'f avpr nobhg EClguba?  Ybatre fjbeq svtugf."
+nccneragyl pbashfvba vf n srngher
+nccneragyl pbashfvba vf n srngher... be vf vg?
+ClCl 1.7 eryrnfrq
+vs lbh jnag gb or penml, lbh qba'g unir gb sbepr vg
+vs lbh jnag vg gb or iveghny, lbh fubhyq abg sbepr vg
+<Nyrk_Tnlabe> svwny: V whfg... fgnegrq pbqvat naq fhqqragyl... nobzvangvba
+fabj, fabj! :-)
+fabj, fabj, fabj, fabj
+clcl 1.8 eryrnfrq
+vg jnf srj lnxf gbb yngr
+ClCl vf n enpr orgjrra hf funivat lnxf, naq gur havirefr gelvat gb cebqhpr zber naq zber lnxf
+Jevgvat na SC7 nabalzbhf cebcbfny sbe ClCl vf yvxr znxvat n gi nq sbe n uvtu cresbeznapr fcbegf pne jvgubhg orvat noyr gb zragvba vgf zbqry be znahsnpghere
+Fabj, fabj (ntnva)
+Fgvyy fabjvat
+thrff jung, fabj
+"lbh haqrerfgvzngr gur vzcbegnapr bs zvpebnepuvgrpgher" "ab, vg'f zber gung jr ner fgvyy unccvyl va gur ynaq bs ernpunoyr sehvg"
+Jub nz V?  Naq vs lrf, ubj znal?
+ClCl vf nyjnlf n cynfzn
+"genafyngvba gbbypunva" = "EClgure"?  gb jevgr vagrEClguref va
+"sberire" va clcl grezf zrnaf yvxr srj zbaguf :)
+"Onu.  PClguba bofphevgl. - Nezva Evtb"
+svwny: pna V vavgvngr lbh ba gur (rnfl ohg) aba-gevivny gbcvp bs jevgvat P shapgvba glcrf? :-)
+nyy fbsgjner vzcebirzragf unccra ol n ovg
+gur genprf qba'g yvr
+:-) be engure ":-/" bss-ol-bar-xrl reebe
+Be Nezva Evtb. V guvax ur'f noyr gb haqrefgnaq k86 gur jnl Plcure pna frr jbzra va gur zngevk.
+V zvtug, ohg abobql erfcrpgf zr
+cerohvyg vafgnapr Ryyvcfvf unf ab nggevohgr 'reeab'
+guvf frnfba'f svefg "fabj! fabj!" vf urer
+ClCl 2.0 orgn1 eryrnfrq - orggre yngr guna arire
+Fjvgreynaq 2012: zber fabj va Qrprzore guna rire fvapr clcl fgnegrq
+Fjvgmreynaq 2012: zber fabj va Qrprzore guna rire fvapr clcl fgnegrq
+<nevtngb> n sngny reebe, ol qrsvavgvba, vf sngny
+<nagbphav> V'z tynq gung jr cebtenz va Clguba naq jr qba'g qrny jvgu gubfr vffhrf rirel qnl. Ncneg gur snpg gung jr unir gb qrny jvgu gurz naljnl, vg frrzf
+unccl arj lrne!
+"zrffl" vf abg n whqtrzrag, ohg whfg n snpg bs pbzcyvpngrqarff
+n ybg bs fabj
+qb lbh xabj nobhg n gbnfgre jvgu 8XO bs ENZ naq 64XO bs EBZ?
+vg'f orra fabjvat rirelqnl sbe n juvyr, V pna'g whfg chg "fabj, fabj" hc urer rirel qnl
+fabjonyy svtugf!
+sbejneq pbzcngvovyvgl jvgu bcgvzvmngvbaf gung unira'g orra vairagrq lrg
+jr fgvyy unir gb jevgr fbsgjner jvgu n zrgnfcnpr ohooyr va vg
+cebonoyl gur ynfg gvzr va gur frnfba, ohg: fabj, fabj!
+ClCl 2.0-orgn2 eryrnfrq
+Gur ceboyrz vf gung sbe nyzbfg nal aba-gevivny cebtenz, vg'f abg pyrne jung 'pbeerpg' zrnaf.
+ClCl 2.0 nyzbfg eryrnfrq
+ClCl 2.0 eryrnfrq
+WVG pbzcvyref fubhyq or jevggra ol crbcyr jub npghnyyl unir snvgu va WVG pbzcvyref' novyvgl gb znxrf guvatf tb fpernzvat snfg
+ClCl 2.0.1 eryrnfrq
+arire haqrerfgvzngr gur vzcebonoyr jura lbh qb fbzrguvat ng 2TUm
+ClCl 2.0.2 eryrnfrq
+nyy jr arrq vf n angvir Cebybt znpuvar
+V haqrefgnaq ubj qravnyvfz vf n onq qrohttvat grpuavdhr
+rirel IZ fubhyq pbzr jvgu arheny argjbex genvarq gb erpbtavmr zvpeborapuznexf naq enaqbzyl syhpghngr gurz +/-9000%
+lbh qvq abg nccebnpu clcl sebz gur rnfl raq: fgz, gura wvg. vg'f n ovg gur Abegu snpr
+va ClCl orvat bayl zbqrengryl zntvp vf n tbbq guvat <psobym>
 """
 
 from string import ascii_uppercase, ascii_lowercase

pypy/config/pypyoption.py

      "termios", "_minimal_curses",
      ]))
 
-working_oo_modules = default_modules.copy()
-working_oo_modules.update(dict.fromkeys(
-    ["_md5", "_sha", "cStringIO", "itertools"]
-))
-
 # XXX this should move somewhere else, maybe to platform ("is this posixish"
 #     check or something)
 if sys.platform == "win32":
         if not IS_64_BITS:
             config.objspace.std.suggest(withsmalllong=True)
 
-    # some optimizations have different effects depending on the typesystem
-    if type_system == 'ootype':
-        config.objspace.std.suggest(multimethods="doubledispatch")
-
     # extra optimizations with the JIT
     if level == 'jit':
         config.objspace.std.suggest(withcelldict=True)
 
 
 def enable_allworkingmodules(config):
-    if config.translation.type_system == 'ootype':
-        modules = working_oo_modules
-    else:
-        modules = working_modules
+    modules = working_modules
     if config.translation.sandbox:
         modules = default_modules
     # ignore names from 'essential_modules', notably 'exceptions', which

pypy/doc/cli-backend.rst

-===============
-The CLI backend
-===============
-
-The goal of GenCLI is to compile RPython programs to the CLI virtual
-machine.
-
-
-Target environment and language
-===============================
-
-The target of GenCLI is the Common Language Infrastructure environment
-as defined by the `Standard Ecma 335`_.
-
-While in an ideal world we might suppose GenCLI to run fine with
-every implementation conforming to that standard, we know the world we
-live in is far from ideal, so extra efforts can be needed to maintain
-compatibility with more than one implementation.
-
-At the moment of writing the two most popular implementations of the
-standard are supported: Microsoft Common Language Runtime (CLR) and
-Mono.
-
-Then we have to choose how to generate the real executables. There are
-two main alternatives: generating source files in some high level
-language (such as C#) or generating assembly level code in
-Intermediate Language (IL).
-
-The IL approach is much faster during the code generation
-phase, because it doesn't need to call a compiler. By contrast the
-high level approach has two main advantages:
-
-  - the code generation part could be easier because the target
-    language supports high level control structures such as
-    structured loops;
-  
-  - the generated executables take advantage of compiler's
-    optimizations.
-
-In reality the first point is not an advantage in the PyPy context,
-because the `flow graph`_ we start from is quite low level and Python
-loops are already expressed in terms of branches (i.e., gotos).
-
-About the compiler optimizations we must remember that the flow graph
-we receive from earlier stages is already optimized: PyPy implements
-a number of optimizations such a constant propagation and
-dead code removal, so it's not obvious if the compiler could
-do more.
-
-Moreover by emitting IL instruction we are not constrained to rely on
-compiler choices but can directly choose how to map CLI opcodes: since
-the backend often know more than the compiler about the context, we
-might expect to produce more efficient code by selecting the most
-appropriate instruction; e.g., we can check for arithmetic overflow
-only when strictly necessary.
-
-The last but not least reason for choosing the low level approach is
-flexibility in how to get an executable starting from the IL code we
-generate:
-
-  - write IL code to a file, then call the ilasm assembler;
-  
-  - directly generate code on the fly by accessing the facilities
-    exposed by the System.Reflection.Emit API.
-
-
-Handling platform differences
-=============================
-
-Since our goal is to support both Microsoft CLR we have to handle the
-differences between the twos; in particular the main differences are
-in the name of the helper tools we need to call:
-
-=============== ======== ======
-Tool            CLR      Mono
-=============== ======== ======
-IL assembler    ilasm    ilasm2
-C# compiler     csc      gmcs
-Runtime         ...      mono
-=============== ======== ======
-
-The code that handles these differences is located in the sdk.py
-module: it defines an abstract class which exposes some methods
-returning the name of the helpers and one subclass for each of the two
-supported platforms.
-
-Since Microsoft ``ilasm`` is not capable of compiling the PyPy
-standard interpreter due to its size, on Windows machines we also look
-for an existing Mono installation: if present, we use CLR for
-everything except the assembling phase, for which we use Mono's
-``ilasm2``.
-
-
-Targeting the CLI Virtual Machine
-=================================
-
-In order to write a CLI backend we have to take a number of decisions.
-First, we have to choose the typesystem to use: given that CLI
-natively supports primitives like classes and instances,
-ootypesystem is the most natural choice.
-
-Once the typesystem has been chosen there is a number of steps we have
-to do for completing the backend:
-
-  - map ootypesystem's types to CLI Common Type System's
-    types;
-  
-  - map ootypesystem's low level operation to CLI instructions;
-  
-  - map Python exceptions to CLI exceptions;
-  
-  - write a code generator that translates a flow graph
-    into a list of CLI instructions;
-  
-  - write a class generator that translates ootypesystem
-    classes into CLI classes.
-
-
-Mapping primitive types
------------------------
-
-The `rtyper`_ give us a flow graph annotated with types belonging to
-ootypesystem: in order to produce CLI code we need to translate these
-types into their Common Type System equivalents.
-
-For numeric types the conversion is straightforward, since
-there is a one-to-one mapping between the two typesystems, so that
-e.g. Float maps to float64.
-
-For character types the choice is more difficult: RPython has two
-distinct types for plain ASCII and Unicode characters (named UniChar),
-while .NET only supports Unicode with the char type. There are at
-least two ways to map plain Char to CTS:
-
-  - map UniChar to char, thus maintaining the original distinction
-    between the two types: this has the advantage of being a
-    one-to-one translation, but has the disadvantage that RPython
-    strings will not be recognized as .NET strings, since they only
-    would be sequences of bytes;
-  
-  - map both char, so that Python strings will be treated as strings
-    also by .NET: in this case there could be problems with existing
-    Python modules that use strings as sequences of byte, such as the
-    built-in struct module, so we need to pay special attention.
-
-We think that mapping Python strings to .NET strings is
-fundamental, so we chose the second option.
-
-Mapping built-in types
-----------------------
-
-As we saw in section ootypesystem defines a set of types that take
-advantage of built-in types offered by the platform.
-
-For the sake of simplicity we decided to write wrappers
-around .NET classes in order to match the signatures required by
-pypylib.dll:
-
-=================== ===========================================
-ootype              CLI
-=================== ===========================================
-String              System.String
-StringBuilder       System.Text.StringBuilder
-List                System.Collections.Generic.List<T>
-Dict                System.Collections.Generic.Dictionary<K, V>
-CustomDict          pypy.runtime.Dict
-DictItemsIterator   pypy.runtime.DictItemsIterator
-=================== ===========================================
-
-Wrappers exploit inheritance for wrapping the original classes, so,
-for example, pypy.runtime.List<T> is a subclass of
-System.Collections.Generic.List<T> that provides methods whose names
-match those found in the _GENERIC_METHODS of ootype.List
-
-The only exception to this rule is the String class, which is not
-wrapped since in .NET we can not subclass System.String.  Instead, we
-provide a bunch of static methods in pypylib.dll that implement the
-methods declared by ootype.String._GENERIC_METHODS, then we call them
-by explicitly passing the string object in the argument list.
-
-
-Mapping instructions
---------------------
-
-PyPy's low level operations are expressed in Static Single Information
-(SSI) form, such as this::
-
-    v2 = int_add(v0, v1)
-
-By contrast the CLI virtual machine is stack based, which means the
-each operation pops its arguments from the top of the stacks and
-pushes its result there. The most straightforward way to translate SSI
-operations into stack based operations is to explicitly load the
-arguments and store the result into the appropriate places::
-
-    LOAD v0
-    LOAD v1
-    int_add
-    STORE v2
-
-The code produced works correctly but has some inefficiency issues that
-can be addressed during the optimization phase.
-
-The CLI Virtual Machine is fairly expressive, so the conversion
-between PyPy's low level operations and CLI instruction is relatively
-simple: many operations maps directly to the corresponding
-instruction, e.g int_add and sub.
-
-By contrast some instructions do not have a direct correspondent and
-have to be rendered as a sequence of CLI instructions: this is the
-case of the "less-equal" and "greater-equal" family of instructions,
-that are rendered as "greater" or "less" followed by a boolean "not",
-respectively.
-
-Finally, there are some instructions that cannot be rendered directly
-without increasing the complexity of the code generator, such as
-int_abs (which returns the absolute value of its argument).  These
-operations are translated by calling some helper function written in
-C#.
-
-The code that implements the mapping is in the modules opcodes.py.
-
-Mapping exceptions
-------------------
-
-Both RPython and CLI have their own set of exception classes: some of
-these are pretty similar; e.g., we have OverflowError,
-ZeroDivisionError and IndexError on the first side and
-OverflowException, DivideByZeroException and IndexOutOfRangeException
-on the other side.
-
-The first attempt was to map RPython classes to their corresponding
-CLI ones: this worked for simple cases, but it would have triggered
-subtle bugs in more complex ones, because the two exception
-hierarchies don't completely overlap.
-
-At the moment we've chosen to build an RPython exception hierarchy
-completely independent from the CLI one, but this means that we can't
-rely on exceptions raised by built-in operations.  The currently
-implemented solution is to do an exception translation on-the-fly.
-
-As an example consider the RPython int_add_ovf operation, that sums
-two integers and raises an OverflowError exception in case of
-overflow. For implementing it we can use the built-in add.ovf CLI
-instruction that raises System.OverflowException when the result
-overflows, catch that exception and throw a new one::
-
-    .try 
-    { 
-        ldarg 'x_0'
-        ldarg 'y_0'
-        add.ovf 
-        stloc 'v1'
-        leave __check_block_2 
-    } 
-    catch [mscorlib]System.OverflowException 
-    { 
-        newobj instance void class OverflowError::.ctor() 
-        throw 
-    } 
-
-
-Translating flow graphs
------------------------
-
-As we saw previously in PyPy function and method bodies are
-represented by flow graphs that we need to translate CLI IL code. Flow
-graphs are expressed in a format that is very suitable for being
-translated to low level code, so that phase is quite straightforward,
-though the code is a bit involved because we need to take care of three
-different types of blocks.
-
-The code doing this work is located in the Function.render
-method in the file function.py.
-
-First of all it searches for variable names and types used by
-each block; once they are collected it emits a .local IL
-statement used for indicating the virtual machine the number and type
-of local variables used.
-
-Then it sequentially renders all blocks in the graph, starting from the
-start block; special care is taken for the return block which is
-always rendered at last to meet CLI requirements.
-
-Each block starts with an unique label that is used for jumping
-across, followed by the low level instructions the block is composed
-of; finally there is some code that jumps to the appropriate next
-block.
-
-Conditional and unconditional jumps are rendered with their
-corresponding IL instructions: brtrue, brfalse.
-
-Blocks that needs to catch exceptions use the native facilities
-offered by the CLI virtual machine: the entire block is surrounded by
-a .try statement followed by as many catch as needed: each catching
-sub-block then branches to the appropriate block::
-
-
-  # RPython
-  try:
-      # block0
-      ...
-  except ValueError:
-      # block1
-      ...
-  except TypeError:
-      # block2
-      ...
-
-  // IL
-  block0: 
-    .try {
-        ...
-        leave block3
-     }
-     catch ValueError {
-        ...
-        leave block1
-      }
-      catch TypeError {
-        ...
-        leave block2
-      }
-  block1:
-      ...
-      br block3
-  block2:
-      ...
-      br block3
-  block3:
-      ...
-
-There is also an experimental feature that makes GenCLI to use its own
-exception handling mechanism instead of relying on the .NET
-one. Surprisingly enough, benchmarks are about 40% faster with our own
-exception handling machinery.
-
-
-Translating classes
--------------------
-
-As we saw previously, the semantic of ootypesystem classes
-is very similar to the .NET one, so the translation is mostly
-straightforward.
-
-The related code is located in the module class\_.py.  Rendered classes
-are composed of four parts:
-
-  - fields;
-  - user defined methods;
-  - default constructor;
-  - the ToString method, mainly for testing purposes
-
-Since ootype implicitly assumes all method calls to be late bound, as
-an optimization before rendering the classes we search for methods
-that are not overridden in subclasses, and declare as "virtual" only
-the one that needs to.
-
-The constructor does nothing more than calling the base class
-constructor and initializing class fields to their default value.
-
-Inheritance is straightforward too, as it is natively supported by
-CLI. The only noticeable thing is that we map ootypesystem's ROOT
-class to the CLI equivalent System.Object.
-
-The Runtime Environment
------------------------
-
-The runtime environment is a collection of helper classes and
-functions used and referenced by many of the GenCLI submodules. It is
-written in C#, compiled to a DLL (Dynamic Link Library), then linked
-to generated code at compile-time.
-
-The DLL is called pypylib and is composed of three parts:
-
-  - a set of helper functions used to implements complex RPython
-    low-level instructions such as runtimenew and ooparse_int;
-
-  - a set of helper classes wrapping built-in types
-
-  - a set of helpers used by the test framework
-
-
-The first two parts are contained in the pypy.runtime namespace, while
-the third is in the pypy.test one.
-
-
-Testing GenCLI
-==============
-
-As the rest of PyPy, GenCLI is a test-driven project: there is at
-least one unit test for almost each single feature of the
-backend. This development methodology allowed us to early discover
-many subtle bugs and to do some big refactoring of the code with the
-confidence not to break anything.
-
-The core of the testing framework is in the module
-rpython.translator.cli.test.runtest; one of the most important function
-of this module is compile_function(): it takes a Python function,
-compiles it to CLI and returns a Python object that runs the just
-created executable when called.
-
-This way we can test GenCLI generated code just as if it were a simple
-Python function; we can also directly run the generated executable,
-whose default name is main.exe, from a shell: the function parameters
-are passed as command line arguments, and the return value is printed
-on the standard output::
-
-    # Python source: foo.py
-    from rpython.translator.cli.test.runtest import compile_function
-
-    def foo(x, y):
-        return x+y, x*y
-
-    f = compile_function(foo, [int, int])
-    assert f(3, 4) == (7, 12)
-
-
-    # shell
-    $ mono main.exe 3 4
-    (7, 12)
-
-GenCLI supports only few RPython types as parameters: int, r_uint,
-r_longlong, r_ulonglong, bool, float and one-length strings (i.e.,
-chars). By contrast, most types are fine for being returned: these
-include all primitive types, list, tuples and instances.
-
-Installing Python for .NET on Linux
-===================================
-
-With the CLI backend, you can access .NET libraries from RPython;
-programs using .NET libraries will always run when translated, but you
-might also want to test them on top of CPython.
-
-To do so, you can install `Python for .NET`_. Unfortunately, it does
-not work out of the box under Linux.
-
-To make it work, download and unpack the source package of Python
-for .NET; the only version tested with PyPy is the 1.0-rc2, but it
-might work also with others. Then, you need to create a file named
-Python.Runtime.dll.config at the root of the unpacked archive; put the
-following lines inside the file (assuming you are using Python 2.7)::
-
-  <configuration>
-    <dllmap dll="python27" target="libpython2.7.so.1.0" os="!windows"/>
-  </configuration>
-
-The installation should be complete now. To run Python for .NET,
-simply type ``mono python.exe``.
-
-
-.. _`Standard Ecma 335`: http://www.ecma-international.org/publications/standards/Ecma-335.htm
-.. _`flow graph`: translation.html#the-flow-model
-.. _`rtyper`: rtyper.html
-.. _`Python for .NET`: http://pythonnet.sourceforge.net/

pypy/doc/clr-module.rst

-===============================
-The ``clr`` module for PyPy.NET
-===============================
-
-PyPy.NET give you access to the surrounding .NET environment via the
-``clr`` module. This module is still experimental: some features are
-still missing and its interface might change in next versions, but
-it's still useful to experiment a bit with PyPy.NET.
-
-PyPy.NET provides an import hook that lets you to import .NET namespaces
-seamlessly as they were normal Python modules.  Then, 
-
-PyPY.NET native classes try to behave as much as possible in the
-"expected" way both for the developers used to .NET and for the ones
-used to Python.
-
-In particular, the following features are mapped one to one because
-they exist in both worlds:
-
-  - .NET constructors are mapped to the Python __init__ method;
-
-  - .NET instance methods are mapped to Python methods;
-
-  - .NET static methods are mapped to Python static methods (belonging
-    to the class);
-
-  - .NET properties are mapped to property-like Python objects (very
-    similar to the Python ``property`` built-in);
-
-  - .NET indexers are mapped to Python __getitem__ and __setitem__;
-
-  - .NET enumerators are mapped to Python iterators.
-
-Moreover, all the usual Python features such as bound and unbound
-methods are available as well.
-
-Example of usage
-================
-
-Here is an example of interactive session using the ``clr`` module::
-
-    >>>> from System.Collections import ArrayList
-    >>>> obj = ArrayList()
-    >>>> obj.Add(1)
-    0
-    >>>> obj.Add(2)
-    1
-    >>>> obj.Add("foo")
-    2
-    >>>> print obj[0], obj[1], obj[2]
-    1 2 foo
-    >>>> print obj.Count
-    3
-
-Conversion of parameters
-========================
-
-When calling a .NET method Python objects are converted to .NET
-objects.  Lots of effort have been taken to make the conversion as
-much transparent as possible; in particular, all the primitive types
-such as int, float and string are converted to the corresponding .NET
-types (e.g., ``System.Int32``, ``System.Float64`` and
-``System.String``).
-
-Python objects without a corresponding .NET types (e.g., instances of
-user classes) are passed as "black boxes", for example to be stored in
-some sort of collection.
-
-The opposite .NET to Python conversions happens for the values returned
-by the methods. Again, primitive types are converted in a
-straightforward way; non-primitive types are wrapped in a Python object, 
-so that they can be treated as usual.
-
-Overload resolution
-===================
-
-When calling an overloaded method, PyPy.NET tries to find the best
-overload for the given arguments; for example, consider the
-``System.Math.Abs`` method::
-
-
-    >>>> from System import Math
-    >>>> Math.Abs(-42)
-    42
-    >>>> Math.Abs(-42.0)
-    42.0
-
-``System.Math.Abs`` has got overloadings both for integers and floats:
-in the first case we call the method ``System.Math.Abs(int32)``, while
-in the second one we call the method ``System.Math.Abs(float64)``.
-
-If the system can't find a best overload for the given parameters, a
-TypeError exception is raised.
-
-
-Generic classes
-================
-
-Generic classes are fully supported.  To instantiate a generic class, you need
-to use the ``[]`` notation::
-
-    >>>> from System.Collections.Generic import List
-    >>>> mylist = List[int]()
-    >>>> mylist.Add(42)
-    >>>> mylist.Add(43)
-    >>>> mylist.Add("foo")
-    Traceback (most recent call last):
-      File "<console>", line 1, in <interactive>
-    TypeError: No overloads for Add could match
-    >>>> mylist[0]
-    42
-    >>>> for item in mylist: print item
-    42
-    43
-
-
-External assemblies and Windows Forms
-=====================================
-
-By default, you can only import .NET namespaces that belongs to already loaded
-assemblies.  To load additional .NET assemblies, you can use
-``clr.AddReferenceByPartialName``.  The following example loads
-``System.Windows.Forms`` and ``System.Drawing`` to display a simple Windows
-Form displaying the usual "Hello World" message::
-
-    >>>> import clr
-    >>>> clr.AddReferenceByPartialName("System.Windows.Forms")
-    >>>> clr.AddReferenceByPartialName("System.Drawing")
-    >>>> from System.Windows.Forms import Application, Form, Label
-    >>>> from System.Drawing import Point
-    >>>>
-    >>>> frm = Form()
-    >>>> frm.Text = "The first pypy-cli Windows Forms app ever"
-    >>>> lbl = Label()
-    >>>> lbl.Text = "Hello World!"
-    >>>> lbl.AutoSize = True
-    >>>> lbl.Location = Point(100, 100)
-    >>>> frm.Controls.Add(lbl)
-    >>>> Application.Run(frm)
-
-Unfortunately at the moment you can't do much more than this with Windows
-Forms, because we still miss support for delegates and so it's not possible
-to handle events.

pypy/doc/config/objspace.usemodules.clr.txt

-Use the 'clr' module. 

pypy/doc/config/translation.cli.trace_calls.txt

-Internal. Debugging aid for the CLI backend.
-
-.. internal

pypy/doc/cpython_differences.rst

     binascii
     bz2
     cStringIO
-    clr
     cmath
     `cpyext`_
     crypt

pypy/doc/dir-reference.rst

                                    from an
                                    RPython program (generally via the rtyper_)
 
-`rpython/translator/cli/`_         the `CLI backend`_ for `.NET`_
-                                   (Microsoft CLR or Mono_)
-
 `pypy/goal/`_                      our `main PyPy-translation scripts`_
                                    live here
 
-`rpython/translator/jvm/`_         the Java backend
-
 `rpython/translator/tool/`_        helper tools for translation
 
 `dotviewer/`_                      `graph viewer`_
 .. _`testing methods`: coding-guide.html#testing-in-pypy
 .. _`translation`: translation.html 
 .. _`GenC backend`: translation.html#genc 
-.. _`CLI backend`: cli-backend.html
 .. _`py.py`: getting-started-python.html#the-py.py-interpreter
 .. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
 .. _JIT: jit/index.html

pypy/doc/discussion/VM-integration.rst

-==============================================
-Integration of PyPy with host Virtual Machines
-==============================================
-
-This document is based on the discussion I had with Samuele during the
-Duesseldorf sprint. It's not much more than random thoughts -- to be
-reviewed!
-
-Terminology disclaimer: both PyPy and .NET have the concept of
-"wrapped" or "boxed" objects. To avoid confusion I will use "wrapping"
-on the PyPy side and "boxing" on the .NET side.
-
-General idea
-============
-
-The goal is to find a way to efficiently integrate the PyPy
-interpreter with the hosting environment such as .NET. What we would
-like to do includes but it's not limited to:
-
-  - calling .NET methods and instantiate .NET classes from Python
-
-  - subclass a .NET class from Python
-
-  - handle native .NET objects as transparently as possible
-
-  - automatically apply obvious Python <--> .NET conversions when
-    crossing the borders (e.g. integers, string, etc.)
-
-One possible solution is the "proxy" approach, in which we manually
-(un)wrap/(un)box all the objects when they cross the border.
-
-Example
--------
-
-  ::
-
-    public static int foo(int x) { return x}
-
-    >>>> from somewhere import foo
-    >>>> print foo(42)
-
-In this case we need to take the intval field of W_IntObject, box it
-to .NET System.Int32, call foo using reflection, then unbox the return
-value and reconstruct a new (or reuse an existing one) W_IntObject.
-
-The other approach
-------------------
-
-The general idea to solve handle this problem is to split the
-"stateful" and "behavioral" parts of wrapped objects, and use already
-boxed values for storing the state.
-
-This way when we cross the Python --> .NET border we can just throw
-away the behavioral part; when crossing .NET --> Python we have to
-find the correct behavioral part for that kind of boxed object and
-reconstruct the pair.
-
-
-Split state and behaviour in the flowgraphs
-===========================================
-
-The idea is to write a graph transformation that takes an usual
-ootyped flowgraph and split the classes and objects we want into a
-stateful part and a behavioral part.
-
-We need to introduce the new ootypesystem type ``Pair``: it acts like
-a Record but it hasn't its own identity: the id of the Pair is the id
-of its first member.
-
-  XXX about ``Pair``: I'm not sure this is totally right. It means
-  that an object can change identity simply by changing the value of a
-  field???  Maybe we could add the constraint that the "id" field
-  can't be modified after initialization (but it's not easy to
-  enforce).
-
-  XXX-2 about ``Pair``: how to implement it in the backends? One
-  possibility is to use "struct-like" types if available (as in
-  .NET). But in this case it's hard to implement methods/functions
-  that modify the state of the object (such as __init__, usually). The
-  other possibility is to use a reference type (i.e., a class), but in
-  this case there will be a gap between the RPython identity (in which
-  two Pairs with the same state are indistinguishable) and the .NET
-  identity (in which the two objects will have a different identity,
-  of course).
-
-Step 1: RPython source code
----------------------------
-
-  ::
-
-    class W_IntObject:
-        def __init__(self, intval):
-            self.intval = intval
-    
-        def foo(self, x):
-            return self.intval + x
-
-    def bar():
-        x = W_IntObject(41)
-        return x.foo(1)
-
-
-Step 2: RTyping
----------------
-
-Sometimes the following examples are not 100% accurate for the sake of
-simplicity (e.g: we directly list the type of methods instead of the
-ootype._meth instances that contains it).
-
-Low level types
-
-  ::
-
-    W_IntObject = Instance(
-        "W_IntObject",                   # name
-        ootype.OBJECT,                   # base class
-        {"intval": (Signed, 0)},         # attributes
-        {"foo": Meth([Signed], Signed)}  # methods
-    )
-
-
-Prebuilt constants (referred by name in the flowgraphs)
-
-  ::
-
-    W_IntObject_meta_pbc = (...)
-    W_IntObject.__init__ = (static method pbc - see below for the graph)
-
-
-Flowgraphs
-
-  ::
-
-    bar() {
-      1.    x = new(W_IntObject)
-      2.    oosetfield(x, "meta", W_IntObject_meta_pbc)
-      3.    direct_call(W_IntObject.__init__, x, 41)
-      4.    result = oosend("foo", x, 1)
-      5.    return result
-    }
-
-    W_IntObject.__init__(W_IntObject self, Signed intval) {
-      1.    oosetfield(self, "intval", intval)
-    }
-
-    W_IntObject.foo(W_IntObject self, Signed x) {
-      1.    value = oogetfield(self, "value")
-      2.    result = int_add(value, x)
-      3.    return result
-    }
-
-Step 3: Transformation
-----------------------
-
-This step is done before the backend plays any role, but it's still
-driven by its need, because at this time we want a mapping that tell
-us what classes to split and how (i.e., which boxed value we want to
-use).
-
-Let's suppose we want to map W_IntObject.intvalue to the .NET boxed
-``System.Int32``. This is possible just because W_IntObject contains
-only one field. Note that the "meta" field inherited from
-ootype.OBJECT is special-cased because we know that it will never
-change, so we can store it in the behaviour.
-
-
-Low level types
-
-  ::
-
-    W_IntObject_bhvr = Instance(
-        "W_IntObject_bhvr",
-        ootype.OBJECT,
-        {},                                               # no more fields!
-        {"foo": Meth([W_IntObject_pair, Signed], Signed)} # the Pair is also explicitly passed
-    )
-
-    W_IntObject_pair = Pair(
-        ("value", (System.Int32, 0)),  # (name, (TYPE, default))
-        ("behaviour", (W_IntObject_bhvr, W_IntObject_bhvr_pbc))
-    )
-
-
-Prebuilt constants
-
-  ::
-
-    W_IntObject_meta_pbc = (...)
-    W_IntObject.__init__ = (static method pbc - see below for the graph)
-    W_IntObject_bhvr_pbc = new(W_IntObject_bhvr); W_IntObject_bhvr_pbc.meta = W_IntObject_meta_pbc
-    W_IntObject_value_default = new System.Int32(0)
-
-
-Flowgraphs
-
-  ::
-
-    bar() {
-      1.    x = new(W_IntObject_pair) # the behaviour has been already set because
-                                      # it's the default value of the field
-
-      2.    # skipped (meta is already set in the W_IntObject_bhvr_pbc)
-
-      3.    direct_call(W_IntObject.__init__, x, 41)
-
-      4.    bhvr = oogetfield(x, "behaviour")
-            result = oosend("foo", bhvr, x, 1) # note that "x" is explicitly passed to foo
-
-      5.    return result
-    }
-
-    W_IntObject.__init__(W_IntObjectPair self, Signed value) {
-      1.    boxed = clibox(value)             # boxed is of type System.Int32
-            oosetfield(self, "value", boxed)
-    }
-
-    W_IntObject.foo(W_IntObject_bhvr bhvr, W_IntObject_pair self, Signed x) {
-      1.    boxed = oogetfield(self, "value")
-            value = unbox(boxed, Signed)
-
-      2.    result = int_add(value, x)
-
-      3.    return result
-    }
-
-
-Inheritance
------------
-
-Apply the transformation to a whole class (sub)hierarchy is a bit more
-complex. Basically we want to mimic the same hierarchy also on the
-``Pair``\s, but we have to fight the VM limitations. In .NET for
-example, we can't have "covariant fields"::
-
-  class Base {
-        public Base field;
-  }
-
-  class Derived: Base {
-        public Derived field;
-  }
-
-A solution is to use only kind of ``Pair``, whose ``value`` and
-``behaviour`` type are of the most precise type that can hold all the
-values needed by the subclasses::
-
-   class W_Object: pass
-   class W_IntObject(W_Object): ...
-   class W_StringObject(W_Object): ...
-
-   ...
-
-   W_Object_pair = Pair(System.Object, W_Object_bhvr)
-
-Where ``System.Object`` is of course the most precise type that can
-hold both ``System.Int32`` and ``System.String``.
-
-This means that the low level type of all the ``W_Object`` subclasses
-will be ``W_Object_pair``, but it also means that we will need to
-insert the appropriate downcasts every time we want to access its
-fields. I'm not sure how much this can impact performances.
-
-

pypy/doc/discussion/outline-external-ootype.rst

-Some discussion about external objects in ootype
-================================================
-
-Current approach:
-
-* SomeCliXxx for .NET backend
-
-SomeCliXxx
-----------
-
-* Supports method overloading
-
-* Supports inheritance in a better way
-
-* Supports static methods
-
-Would be extremely cool to generalize the approach to be useful also for the
-JVM backend.  Here are some notes:
-
-* There should be one mechanism, factored out nicely out of any backend,
-  to support any possible backend (cli, jvm for now).
-
-* This approach might be eventually extended by a backend itself, but
-  as much as possible code should be factored out.
-
-* Backend should take care itself about creating such classes, either
-  manually or automatically.
-
-* Should support superset of needs of all backends (ie callbacks,
-  method overloading, etc.)
-
-
-Proposal of alternative approach
-================================
-
-The goal of the task is to let RPython program access "external
-entities" which are available in the target platform; these include:
-
-  - external classes (e.g. for .NET: System.Collections.ArrayList)
-
-  - external prebuilt instances (e.g. for .NET: typeof(System.Console))
-
-External entities should behave as much as possible as "internal
-entities".
-
-Moreover, we want to preserve the possibility of *testing* RPython
-programs on top of CPython if possible. For example, it should be
-possible to RPython programs using .NET external objects using
-PythonNet; for JVM, there are JPype_ and JTool_, to be investigated:
-
-.. _JPype: http://jpype.sourceforge.net/
-.. _JTool: http://wiki.europython.eu/Talks/Jtool%20Java%20In%20The%20Python%20Vm
-
-How to represent types
-----------------------
-
-First, some definitions: 
-
-  - high-level types are the types used by the annotator
-    (SomeInteger() & co.)
-
-  - low-level types are the types used by the rtyper (Signed & co.)
-
-  - platform-level types are the types used by the backends (e.g. int32 for
-    .NET)
-
-Usually, RPython types are described "top-down": we start from the
-annotation, then the rtyper transforms the high-level types into
-low-level types, then the backend transforms low-level types into
-platform-level types. E.g. for .NET, SomeInteger() -> Signed -> int32.
-
-External objects are different: we *already* know the platform-level
-types of our objects and we can't modify them. What we need to do is
-to specify an annotation that after the high-level -> low-level ->
-platform-level transformation will give us the correct types.
-
-For primitive types it is usually easy to find the correct annotation;
-if we have an int32, we know that it's ootype is Signed and the
-corresponding annotation is SomeInteger().
-
-For non-primitive types such as classes, we must use a "bottom-up"
-approach: first, we need a description of platform-level interface of
-the class; then we construct the corresponding low-level type and
-teach the backends how to treat such "external types". Finally, we
-wrap the low-level types into special "external annotation".
-
-For example, consider a simple existing .NET class::
-
-    class Foo {
-        public float bar(int x, int y) { ... }
-    }
-
-The corresponding low-level type could be something like this::
-
-    Foo = ootype.ExternalInstance({'bar': ([Signed, Signed], Float)})
-
-Then, the annotation for Foo's instances is SomeExternalInstance(Foo).
-This way, the transformation from high-level types to platform-level
-types is straightforward and correct.
-
-Finally, we need support for static methods: similarly for classes, we
-can define an ExternalStaticMeth low-level type and a
-SomeExternalStaticMeth annotation.
-
-
-How to describe types
----------------------
-
-To handle external objects we must specify their signatures. For CLI
-and JVM the job can be easily automatized, since the objects have got
-precise signatures.
-
-
-RPython interface
------------------
-
-External objects are exposed as special Python objects that gets
-annotated as SomeExternalXXX. Each backend can choose its own way to
-provide these objects to the RPython programmer.
-
-External classes will be annotated as SomeExternalClass; two
-operations are allowed:
-
-  - call: used to instantiate the class, return an object which will
-    be annotated as SomeExternalInstance.
-
-  - access to static methods: return an object which will be annotated
-    as SomeExternalStaticMeth.
-
-Instances are annotated as SomeExternalInstance. Prebuilt external objects are
-annotated as SomeExternalInstance(const=...).
-
-Open issues
------------
-
-Exceptions
-~~~~~~~~~~
-
-.NET and JVM users want to catch external exceptions in a natural way;
-e.g.::
-
-    try:
-        ...
-    except System.OverflowException:
-        ...
-
-This is not straightforward because to make the flow objspace happy the
-object which represent System.OverflowException must be a real Python
-class that inherits from Exception.
-
-This means that the Python objects which represent external classes
-must be Python classes itself, and that classes representing
-exceptions must be special cased and made subclasses of Exception.
-
-
-Inheritance
-~~~~~~~~~~~
-
-It would be nice to allow programmers to inherit from an external
-class. Not sure about the implications, though.
-
-Special methods/properties
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In .NET there are special methods that can be accessed using a special
-syntax, for example indexer or properties. It would be nice to have in
-RPython the same syntax as C#, although we can live without that.
-
-
-Implementation details
-----------------------
-
-The CLI backend use a similar approach right now, but it could be
-necessary to rewrite a part of it.
-
-To represent low-level types, it uses NativeInstance, a subclass of
-ootype.Instance that contains all the information needed by the
-backend to reference the class (e.g., the namespace). It also supports
-overloading.
-
-For annotations, it reuses SomeOOInstance, which is also a wrapper
-around a low-level type but it has been designed for low-level
-helpers. It might be saner to use another annotation not to mix apples
-and oranges, maybe factoring out common code.
-
-I don't know whether and how much code can be reused from the existing
-bltregistry.

pypy/doc/dot-net.rst

-.NET support
-============
-
-   .. warning::
-   
-      The .NET backend within PyPy is unmaintained.  This documentation may be out-of-date.  We welcome contributors who are interested in doing the work to get this into shape.
-
-.. toctree::
-
-   cli-backend.rst
-   clr-module.rst
 Which backends are there for the RPython toolchain?
 ---------------------------------------------------
 
-Currently, there are backends for C_, the CLI_, and the JVM_.
-All of these can translate the entire PyPy interpreter.
+Currently, there only backends is C_.
+It can translate the entire PyPy interpreter.
 To learn more about backends take a look at the `translation document`_.
 
 .. _C: translation.html#the-c-back-end
-.. _CLI: cli-backend.html
-.. _JVM: translation.html#genjvm
 .. _`translation document`: translation.html
 
 ------------------

pypy/doc/getting-started-dev.rst

    >>> f(6)
    1
 
-Translating the flow graph to CLI or JVM code
-+++++++++++++++++++++++++++++++++++++++++++++
-
-PyPy also contains a `CLI backend`_ and JVM backend which
-can translate flow graphs into .NET executables or a JVM jar
-file respectively.  Both are able to translate the entire
-interpreter.  You can try out the CLI and JVM backends
-from the interactive translator shells as follows::
-
-    >>> def myfunc(a, b): return a+b
-    ... 
-    >>> t = Translation(myfunc, [int, int])
-    >>> t.annotate()
-    >>> f = t.compile_cli() # or compile_jvm()
-    >>> f(4, 5)
-    9
-
-The object returned by ``compile_cli`` or ``compile_jvm``
-is a wrapper around the real
-executable: the parameters are passed as command line arguments, and
-the returned value is read from the standard output.
-
-Once you have compiled the snippet, you can also try to launch the
-executable directly from the shell. You will find the
-executable in one of the ``/tmp/usession-*`` directories::
-
-    # For CLI:
-    $ mono /tmp/usession-trunk-<username>/main.exe 4 5
-    9
-
-    # For JVM:
-    $ java -cp /tmp/usession-trunk-<username>/pypy pypy.Main 4 5
-    9
-
-To translate and run for the CLI you must have the SDK installed: Windows
-users need the `.NET Framework SDK`_, while Linux and Mac users
-can use Mono_.  To translate and run for the JVM you must have a JDK 
-installed (at least version 6) and ``java``/``javac`` on your path.
-
 A slightly larger example
 +++++++++++++++++++++++++
 
 There are several environment variables you can find useful while playing with the RPython:
 
 ``PYPY_USESSION_DIR``
-    RPython uses temporary session directories to store files that are generated during the 
+    RPython uses temporary session directories to store files that are generated during the
     translation process(e.g., translated C files). ``PYPY_USESSION_DIR`` serves as a base directory for these session
     dirs. The default value for this variable is the system's temporary dir.
 
 ``PYPY_USESSION_KEEP``
-    By default RPython keeps only the last ``PYPY_USESSION_KEEP`` (defaults to 3) session dirs inside ``PYPY_USESSION_DIR``. 
+    By default RPython keeps only the last ``PYPY_USESSION_KEEP`` (defaults to 3) session dirs inside ``PYPY_USESSION_DIR``.
     Increase this value if you want to preserve C files longer (useful when producing lots of lldebug builds).
 
 .. _`your own interpreters`: faq.html#how-do-i-compile-my-own-interpreters
 
-.. _`start reading sources`: 
+.. _`start reading sources`:
 
 Where to start reading the sources
----------------------------------- 
+----------------------------------
 
 PyPy is made from parts that are relatively independent of each other.
 You should start looking at the part that attracts you most (all paths are
-relative to the PyPy top level directory).  You may look at our `directory reference`_ 
+relative to the PyPy top level directory).  You may look at our `directory reference`_
 or start off at one of the following points:
 
 *  `pypy/interpreter`_ contains the bytecode interpreter: bytecode dispatcher
    in `pypy/interpreter/pyopcode.py`_, frame and code objects in `pypy/interpreter/eval.py`_ and `pypy/interpreter/pyframe.py`_,
    function objects and argument passing in `pypy/interpreter/function.py`_ and `pypy/interpreter/argument.py`_,
    the object space interface definition in `pypy/interpreter/baseobjspace.py`_, modules in
-   `pypy/interpreter/module.py`_ and `pypy/interpreter/mixedmodule.py`_.  Core types supporting the bytecode 
+   `pypy/interpreter/module.py`_ and `pypy/interpreter/mixedmodule.py`_.  Core types supporting the bytecode
    interpreter are defined in `pypy/interpreter/typedef.py`_.
 
 *  `pypy/interpreter/pyparser`_ contains a recursive descent parser,
 
 .. _`RPython standard library`: rlib.html
 
-.. _optionaltool: 
+.. _optionaltool:
 
 
 Running PyPy's unit tests
     # or for running tests of a whole subdirectory
     py.test pypy/interpreter/
 
-See `py.test usage and invocations`_ for some more generic info 
+See `py.test usage and invocations`_ for some more generic info
 on how you can run tests.
 
 Beware trying to run "all" pypy tests by pointing to the root
 
 .. _`interpreter-level and app-level`: coding-guide.html#interpreter-level
 
-.. _`trace example`: 
+.. _`trace example`:
 
 Tracing bytecode and operations on objects
-++++++++++++++++++++++++++++++++++++++++++ 
+++++++++++++++++++++++++++++++++++++++++++
 
 You can use the trace object space to monitor the interpretation
-of bytecodes in connection with object space operations.  To enable 
-it, set ``__pytrace__=1`` on the interactive PyPy console:: 
+of bytecodes in connection with object space operations.  To enable
+it, set ``__pytrace__=1`` on the interactive PyPy console::
 
     >>>> __pytrace__ = 1
     Tracing enabled
 
 .. _`example-interpreter`: https://bitbucket.org/pypy/example-interpreter
 
-Additional Tools for running (and hacking) PyPy 
+Additional Tools for running (and hacking) PyPy
 -----------------------------------------------
 
-We use some optional tools for developing PyPy. They are not required to run 
+We use some optional tools for developing PyPy. They are not required to run
 the basic tests or to get an interactive PyPy prompt but they help to
-understand  and debug PyPy especially for the translation process.  
+understand  and debug PyPy especially for the translation process.
 
 graphviz & pygame for flow graph viewing (highly recommended)
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 graphviz and pygame are both necessary if you
-want to look at generated flow graphs: 
+want to look at generated flow graphs:
 
-	graphviz: http://www.graphviz.org/Download.php 
+	graphviz: http://www.graphviz.org/Download.php
 
 	pygame: http://www.pygame.org/download.shtml
 
-py.test and the py lib 
+py.test and the py lib
 +++++++++++++++++++++++
 
 The `py.test testing tool`_ drives all our testing needs.