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: 
-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:
-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:
 License for 'pypy/module/unicodedata/'


 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 (


 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


      "termios", "_minimal_curses",
-working_oo_modules = default_modules.copy()
-    ["_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:
-    # 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':
 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


-The CLI backend
-The goal of GenCLI is to compile RPython programs to the CLI virtual
-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
-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
-  - 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
-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
-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
-=================== ===========================================
-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",
-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
-The code that implements the mapping is in the modules
-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
-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
-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
-The related code is located in the module class\  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:
-    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="" os="!windows"/>
-  </configuration>
-The installation should be complete now. To run Python for .NET,
-simply type ``mono python.exe``.
-.. _`Standard Ecma 335`:
-.. _`flow graph`: translation.html#the-flow-model
-.. _`rtyper`: rtyper.html
-.. _`Python for .NET`:


-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
-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.


-Use the 'clr' module. 


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


-    clr


                                    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
 .. _``:
 .. _``: getting-started-dev.html#try-out-the-translator
 .. _JIT: jit/index.html


-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
-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.
-  ::
-    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
-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)
-  ::
-    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)
-    }
- 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
-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)
-  ::
-    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)
-    }
- 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
-    }
-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.


-Some discussion about external objects in ootype
-Current approach:
-* SomeCliXxx for .NET backend
-* 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
-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:
-.. _JTool:
-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
-.NET and JVM users want to catch external exceptions in a natural way;
-    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.
-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
-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


-.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


    >>> f(6)
-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:
-    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.
-    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/`_, frame and code objects in `pypy/interpreter/`_ and `pypy/interpreter/`_,
    function objects and argument passing in `pypy/interpreter/`_ and `pypy/interpreter/`_,
    the object space interface definition in `pypy/interpreter/`_, modules in
-   `pypy/interpreter/`_ and `pypy/interpreter/`_.  Core types supporting the bytecode 
+   `pypy/interpreter/`_ and `pypy/interpreter/`_.  Core types supporting the bytecode
    interpreter are defined in `pypy/interpreter/`_.
 *  `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`:
-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: 
+	graphviz:
-py.test and the py lib 
+py.test and the py lib
 The `py.test testing tool`_ drives all our testing needs.