Alex Gaynor avatar Alex Gaynor committed 66ce9bd

Removed a ton of documenation about ootypesystem.

Comments (0)

Files changed (15)

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

 
 
 PyPy's Python interpreter is a very compliant Python
-interpreter implemented in RPython.  When compiled, it passes most of 
+interpreter implemented in RPython.  When compiled, it passes most of
 `CPythons core language regression tests`_ and comes with many of the extension
 modules included in the standard library including ``ctypes``. It can run large
 libraries such as Django_ and Twisted_. There are some small behavioral
 
 .. _`CPython differences`: cpython_differences.html
 
-To actually use PyPy's Python interpreter, the first thing to do is to 
-`download a pre-built PyPy`_ for your architecture.  
+To actually use PyPy's Python interpreter, the first thing to do is to
+`download a pre-built PyPy`_ for your architecture.
 
 .. _`download a pre-built PyPy`:  http://pypy.org/download.html
 
 
 .. _`windows document`: windows.html
 
-You can translate the whole of PyPy's Python interpreter to low level C code,
-or `CLI code`_.  If you intend to build using gcc, check to make sure that
+You can translate the whole of PyPy's Python interpreter to low level C code.
+If you intend to build using gcc, check to make sure that
 the version you have is not 4.2 or you will run into `this bug`_.
 
 .. _`this bug`: https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/187391
 
 
 3. Translation is time-consuming -- 45 minutes on a very fast machine --
-   and RAM-hungry.  As of March 2011, you will need **at least** 2 GB of 
-   memory on a 
-   32-bit machine and 4GB on a 64-bit machine.  If your memory resources 
+   and RAM-hungry.  As of March 2011, you will need **at least** 2 GB of
+   memory on a
+   32-bit machine and 4GB on a 64-bit machine.  If your memory resources
    are constrained, or your machine is slow you might want to pick the
    `optimization level`_ `1` in the next step.  A level of
    `2` or `3` or `jit` gives much better results, though.  But if all
 
    Let me stress this again: at ``--opt=1`` you get the Boehm
    GC, which is here mostly for historical and for testing reasons.
-   You really do not want to pick it for a program you intend to use.  
+   You really do not want to pick it for a program you intend to use.
    The resulting ``pypy-c`` is slow.
 
 4. Run::
     >>>> pystone.main()
     Pystone(1.1) time for 50000 passes = 0.060004
     This machine benchmarks at 833278 pystones/second
-    >>>> 
+    >>>>
 
 Note that pystone gets faster as the JIT kicks in.
 This executable can be moved around or copied on other machines; see
     cd pypy
     python bin/pyinteractive.py
 
-After a few seconds (remember: this is running on top of CPython), 
-you should be at the PyPy prompt, which is the same as the Python 
+After a few seconds (remember: this is running on top of CPython),
+you should be at the PyPy prompt, which is the same as the Python
 prompt, but with an extra ">".
 
 Now you are ready to start running Python code.  Most Python
-modules should work if they don't involve CPython extension 
+modules should work if they don't involve CPython extension
 modules.  **This is slow, and most C modules are not present by
 default even if they are standard!**  Here is an example of
-determining PyPy's performance in pystones:: 
+determining PyPy's performance in pystones::
 
-    >>>> from test import pystone 
+    >>>> from test import pystone
     >>>> pystone.main(10)
 
 The parameter is the number of loops to run through the test. The
 default is 50000, which is far too many to run in a non-translated
-PyPy version (i.e. when PyPy's interpreter itself is being interpreted 
+PyPy version (i.e. when PyPy's interpreter itself is being interpreted
 by CPython).
 
 pyinteractive.py options
 
 
 .. _Mono: http://www.mono-project.com/Main_Page
-.. _`CLI backend`: cli-backend.html
 .. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
-.. _clr: clr-module.html
 .. _`CPythons core language regression tests`: http://buildbot.pypy.org/summary?category=applevel&branch=%3Ctrunk%3E
 
 .. include:: _ref.txt

pypy/doc/glossary.rst

        extend or twist these semantics, or c) serve whole-program analysis
        purposes.
 
-    ootypesystem
-       An `object oriented type model <rtyper.html#object-oriented-types>`__
-       containing classes and instances.  A :term:`backend` that uses this type system
-       is also called a high-level backend.  The JVM and CLI backends
-       all use this typesystem.
-
     prebuilt constant
        In :term:`RPython` module globals are considered constants.  Moreover,
        global (i.e. prebuilt) lists and dictionaries are supposed to be

pypy/doc/project-documentation.rst

 
 `command line reference`_
 
-`CLI backend`_ describes the details of the .NET backend.
-
 `JIT Generation in PyPy`_ describes how we produce the Python Just-in-time Compiler
 from our Python interpreter.
 

pypy/doc/rtyper.rst

 See for example `rpython/rtyper/rlist.py`_.
 
 
-.. _`oo type`:
-
-Object Oriented Types
----------------------
-
-The standard `low-level type` model described above is fine for
-targeting low level backends such as C, but it is not good
-enough for targeting higher level backends such as .NET CLI or Java
-JVM, so a new object oriented model has been introduced. This model is
-implemented in the first part of `rpython/rtyper/ootypesystem/ootype.py`_.
-
-As for the low-level typesystem, the second part of
-`rpython/rtyper/ootypesystem/ootype.py`_ is a runnable implementation of
-these types, for testing purposes.
-
-
-The target platform
-+++++++++++++++++++
-
-There are plenty of object oriented languages and platforms around,
-each one with its own native features: they could be statically or
-dynamically typed, they could support or not things like multiple
-inheritance, classes and functions as first class order objects,
-generics, and so on.
-
-The goal of *ootypesystem* is to define a trade-off between all
-the potential backends that let them to use the native facilities when
-available while not preventing other backends to work when they
-aren't.
-
-
-Types and classes
-+++++++++++++++++
-
-Most of the primitive types defined in *ootypesystem* are the very
-same of those found in *lltypesystem*: ``Bool``, ``Signed``,
-``Unsigned``, ``Float``, ``Char``, ``UniChar`` and ``Void``.
-
-The target platform is supposed to support classes and instances with
-**single inheritance**. Instances of user-defined classes are mapped
-to the ``Instance`` type, whose ``_superclass`` attribute indicates
-the base class of the instance. At the very beginning of the
-inheritance hierarchy there is the ``Root`` object, i.e. the common
-base class between all instances; if the target platform has the
-notion of a common base class too, the backend can choose to map the
-``Root`` class to its native equivalent.
-
-Object of ``Instance`` type can have attributes and methods:
-attributes are got and set by the ``oogetfield`` and ``oosetfield``
-operations, while method calls are expressed by the ``oosend``
-operation.
-
-Classes are passed around using the ``Class`` type: this is a first
-order class type whose only goal is to allow **runtime instantiation**
-of the class. Backends that don't support this feature natively, such
-as Java, may need to use some sort of placeholder instead.
-
-
-Static vs. dynamic typing
-+++++++++++++++++++++++++
-
-The target platform is assumed to be **statically typed**, i.e.  the
-type of each object is known at compile time.
-
-As usual, it is possible to convert an object from type to type only
-under certain conditions; there is a number of predefined conversions
-between primitive types such as from ``Bool`` to ``Signed`` or from
-``Signed`` to ``Float``. For each one of these conversions there is a
-corresponding low level operation, such as ``cast_bool_to_int`` and
-``cast_int_to_float``.
-
-Moreover it is possible to cast instances of a class up and down the
-inheritance hierarchy with the ``ooupcast`` and ``oodowncast`` low
-level operations. Implicit upcasting is not allowed, so you really
-need to do a ``ooupcast`` for converting from a subclass to a
-superclass.
-
-With this design statically typed backends can trivially insert
-appropriate casts when needed, while dynamically typed backends can
-simply ignore some of the operation such as ``ooupcast`` and
-``oodowncast``. Backends that supports implicit upcasting, such as CLI
-and Java, can simply ignore only ``ooupcast``.
-
-Object model
-++++++++++++
-
-The object model implemented by ootype is quite Java-like. The
-following is a list of key features of the ootype object model which
-have a direct correspondence in the Java or .NET object model:
-
-  - classes have a static set of strongly typed methods and
-    attributes;
-
-  - methods can be overriden in subclasses; every method is "virtual"
-    (i.e., can be overridden); methods can be "abstract" (i.e., need
-    to be overridden in subclasses);
-
-  - classes support single inheritance; all classes inherit directly
-    or indirectly from the ROOT class;
-
-  - there is some support for method overloading. This feature is not
-    used by the RTyper itself because RPython doesn't support method
-    overloading, but it is used by the GenCLI backend for offering
-    access to the native .NET libraries (see XXX);
-
-  - all classes, attributes and methods are public: ootype is only
-    used internally by the translator, so there is no need to enforce
-    accessibility rules;
-
-  - classes and functions are first-class order objects: this feature
-    can be easily simulated by backends for platforms on which it is not
-    a native feature;
-
-  - there is a set of `built-in types`_ offering standard features.
-
-Exception handling
-++++++++++++++++++
-
-Since flow graphs are meant to be used also for very low level
-backends such as C, they are quite unstructured: this means that the
-target platform doesn't need to have a native exception handling
-mechanism, since at the very least the backend can handle exceptions
-just like ``genc`` does.
-
-By contrast we know that most of high level platforms natively support
-exception handling, so *ootypesystem* is designed to let them to use
-it. In particular the exception instances are typed with the
-``Instance`` type, so the usual inheritance exception hierarchy is
-preserved and the native way to catch exception should just work.
-
-.. `built-in types`_
-
-Built-in types
-++++++++++++++
-
-It seems reasonable to assume high level platforms to provide built-in
-facilities for common types such as *lists* or *hashtables*.
-
-RPython standard types such as ``List`` and ``Dict`` are implemented
-on top of these common types; at the moment of writing there are six
-built-in types:
-
-  - **String**: self-descriptive
-
-  - **StringBuilder**: used for dynamic building of string
-
-  - **List**: a variable-sized, homogeneous list of object
-
-  - **Dict**: a hashtable of homogeneous keys and values
-
-  - **CustomDict**: same as dict, but with custom equal and hash
-    functions
-
-  - **DictItemsIterator**: a helper class for iterating over the
-    elements of a ``Dict``
-
-
-Each of these types is a subtype of ``BuiltinADTType`` and has set of
-ADT (Abstract Data Type) methods (hence the name of the base class)
-for being manipulated. Examples of ADT methods are ``ll_length`` for
-``List`` and ``ll_get`` for ``Dict``.
-
-From the backend point of view an instance of a built-in types is
-treated exactly as a plain ``Instance``, so usually no special-casing
-is needed. The backend is supposed to provide a bunch of classes
-wrapping the native ones in order to provide the right signature and
-semantic for the ADT methods.
-
-As an alternative, backends can special-case the ADT types to map them
-directly to the native equivalent, translating the method names
-on-the-fly at compile time.
-
-Generics
-++++++++
-
-Some target platforms offer native support for **generics**, i.e.
-classes that can be parametrized on types, not only values. For
-example, if one wanted to create a list using generics, a possible
-declaration would be to say ``List<T>``, where ``T`` represented the
-type.  When instantiated, one could create ``List<Integer>`` or
-``List<Animal>``. The list is then treated as a list of whichever type
-is specified.
-
-Each subclass of ``BuiltinADTTypes`` defines a bunch of type
-parameters by creating some class level placeholder in the form of
-``PARAMNAME_T``; then it fills up the ``_GENERIC_METHODS`` attribute
-by defining the signature of each of the ADT methods using those
-placeholders in the appropriate places. As an example, here is an
-extract of *ootypesystem*'s List type::
-
-    class List(BuiltinADTType):
-        # placeholders for types
-        SELFTYPE_T = object()
-        ITEMTYPE_T = object()
-
-        ...
-
-        def _init_methods(self):
-            # 'ITEMTYPE_T' is used as a placeholder for indicating
-            # arguments that should have ITEMTYPE type. 'SELFTYPE_T' indicates 'self'
-
-            self._GENERIC_METHODS = frozendict({
-                "ll_length": Meth([], Signed),
-                "ll_getitem_fast": Meth([Signed], self.ITEMTYPE_T),
-                "ll_setitem_fast": Meth([Signed, self.ITEMTYPE_T], Void),
-                "_ll_resize_ge": Meth([Signed], Void),
-                "_ll_resize_le": Meth([Signed], Void),
-                "_ll_resize": Meth([Signed], Void),
-            })
-
-        ...
-
-Thus backends that support generics can simply look for placeholders
-for discovering where the type parameters are used. Backends that
-don't support generics can simply use the ``Root`` class instead and
-insert the appropriate casts where needed. Note that placeholders
-might also stand for primitive types, which typically require more
-involved casts: e.g. in Java, making wrapper objects around ints.
-
-
 HighLevelOp interface
 ---------------------
 

pypy/doc/translation.rst

 this task into several steps, and the purpose of this document is to
 introduce them.
 
-As of the 1.2 release, RPython_ programs can be translated into the following
-languages/platforms: C/POSIX, CLI/.NET
-and Java/JVM.
-
 .. _`application-level`: coding-guide.html#application-level
 .. _`interpreter-level`: coding-guide.html#interpreter-level
 
-The choice of the target platform affects the process somewhat, but to
-start with we describe the process of translating an RPython_ program into
+To start with we describe the process of translating an RPython_ program into
 C (which is the default and original target).
 
 .. _`initialization time`:
 Use the :config:`translation.backend` option to choose which backend to use.
 
 
-
-The Object-Oriented Backends
-----------------------------
-
-The Object-Oriented backends target platforms that are less C-like and support
-classes, instance etc. If such a platform is targeted, the `OO type system` is
-used while rtyping. Of the OO backends, both gencli and genjava can translate
-the full Python interpreter.
-
-.. _`oo type system`: rtyper.html#oo-type
-
-.. mention that pretty much all these backends are done by volunteers?
-
-GenCLI
-++++++
-
-GenCLI_ targets the `Common Language Infrastructure`_, the most famous
-implementations of which are Microsoft's `.NET`_ and Mono_.
-
-It is the most advanced of the object oriented backends -- it can
-compile the PyPy interpreter as well as our two standard benchmarks,
-RPyStone (CPython's PyStone benchmark modified slightly to be RPython)
-and a RPython version of the common Richards benchmark.
-
-It is almost entirely the work of Antonio Cuni, who started this
-backend as part of his `Master's thesis`_, the Google's Summer of Code
-2006 program and the Summer of PyPy program.
-
-.. _`Common Language Infrastructure`: http://www.ecma-international.org/publications/standards/Ecma-335.htm
-.. _`.NET`: http://www.microsoft.com/net/
-.. _Mono: http://www.mono-project.com/
-.. _`Master's thesis`: http://buildbot.pypy.org/misc/Implementing%20Python%20in%20.NET.pdf
-.. _GenCLI: cli-backend.html
-
-GenJVM
-++++++
-
-GenJVM targets the Java Virtual Machine: it translates RPython
-programs directly into Java bytecode, similarly to what GenCLI does.
-
-So far it is the second most mature high level backend after GenCLI:
-it still can't translate the full Standard Interpreter, but after the
-Leysin sprint we were able to compile and run the rpystone and
-richards benchmarks.
-
-GenJVM is almost entirely the work of Niko Matsakis, who worked on it
-also as part of the Summer of PyPy program.
-
 .. _extfunccalls:
 
 External Function Calls
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.