Source

pypy / pypy / doc / rtyper.rst

Diff from to

File pypy/doc/rtyper.rst

 .. contents::
 
 
-The RPython Typer lives in the directory `pypy/rpython/`_.
+The RPython Typer lives in the directory `rpython/rtyper/`_.
 
 
 Overview
 where -- in C notation -- all three variables v1, v2 and v3 are typed ``int``.
 This is done by attaching an attribute ``concretetype`` to v1, v2 and v3
 (which might be instances of Variable or possibly Constant).  In our model,
-this ``concretetype`` is ``pypy.rpython.lltypesystem.lltype.Signed``.  Of
+this ``concretetype`` is ``rpython.rtyper.lltypesystem.lltype.Signed``.  Of
 course, the purpose of replacing the operation called ``add`` with
 ``int_add`` is that code generators no longer have to worry about what kind
 of addition (or concatenation maybe?) it means.
 each operation.  In both cases the analysis of an operation depends on the
 annotations of its input arguments.  This is reflected in the usage of the same
 ``__extend__`` syntax in the source files (compare e.g.
-`pypy/annotation/binaryop.py`_ and `pypy/rpython/rint.py`_).
+`rpython/annotator/binaryop.py`_ and `rpython/rtyper/rint.py`_).
 
 The analogy stops here, though: while it runs, the Annotator is in the middle
 of computing the annotations, so it might need to reflow and generalize until
 implementations for the same high-level operations.  This is the reason for
 turning representations into explicit objects.
 
-The base Repr class is defined in `pypy/rpython/rmodel.py`_.  Most of the
+The base Repr class is defined in `rpython/rtyper/rmodel.py`_.  Most of the
 ``rpython/r*.py`` files define one or a few subclasses of Repr.  The method
 getrepr() of the RTyper will build and cache a single Repr instance per
 SomeXxx() instance; moreover, two SomeXxx() instances that are equal get the
 The RPython Typer uses a standard low-level model which we believe can
 correspond rather directly to various target languages such as C.
 This model is implemented in the first part of
-`pypy/rpython/lltypesystem/lltype.py`_.
+`rpython/rtyper/lltypesystem/lltype.py`_.
 
-The second part of `pypy/rpython/lltypesystem/lltype.py`_ is a runnable
+The second part of `rpython/rtyper/lltypesystem/lltype.py`_ is a runnable
 implementation of these types, for testing purposes.  It allows us to write
 and test plain Python code using a malloc() function to obtain and manipulate
 structures and arrays.  This is useful for example to implement and test
 
 Here is a quick tour:
 
-    >>> from pypy.rpython.lltypesystem.lltype import *
+    >>> from rpython.rtyper.lltypesystem.lltype import *
 
 Here are a few primitive low-level types, and the typeOf() function to figure
 them out:
 types like list in this elementary world.  The ``malloc()`` function is a kind
 of placeholder, which must eventually be provided by the code generator for the
 target platform; but as we have just seen its Python implementation in
-`pypy/rpython/lltypesystem/lltype.py`_ works too, which is primarily useful for
+`rpython/rtyper/lltypesystem/lltype.py`_ works too, which is primarily useful for
 testing, interactive exploring, etc.
 
 The argument to ``malloc()`` is the structure type directly, but it returns a
 +++++++++++++++
 
 Structure types are built as instances of 
-``pypy.rpython.lltypesystem.lltype.Struct``::
+``rpython.rtyper.lltypesystem.lltype.Struct``::
 
     MyStructType = Struct('somename',  ('field1', Type1), ('field2', Type2)...)
     MyStructType = GcStruct('somename',  ('field1', Type1), ('field2', Type2)...)
 +++++++++++
 
 An array type is built as an instance of 
-``pypy.rpython.lltypesystem.lltype.Array``::
+``rpython.rtyper.lltypesystem.lltype.Array``::
 
     MyIntArray = Array(Signed)
     MyOtherArray = Array(MyItemType)
 with care: the bigger structure of which they are part of could be freed while
 the Ptr to the substructure is still in use.  In general, it is a good idea to
 avoid passing around pointers to inlined substructures of malloc()ed structures.
-(The testing implementation of `pypy/rpython/lltypesystem/lltype.py`_ checks to some
+(The testing implementation of `rpython/rtyper/lltypesystem/lltype.py`_ checks to some
 extent that you are not trying to use a pointer to a structure after its
 container has been freed, using weak references.  But pointers to non-GC
 structures are not officially meant to be weak references: using them after what
 change needed to the Annotator to allow it to perform type inference of our
 very-low-level snippets of code.
 
-See for example `pypy/rpython/rlist.py`_.
+See for example `rpython/rtyper/rlist.py`_.
 
 
 .. _`oo type`:
 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 `pypy/rpython/ootypesystem/ootype.py`_.
+implemented in the first part of `rpython/rtyper/ootypesystem/ootype.py`_.
 
 As for the low-level typesystem, the second part of
-`pypy/rpython/ootypesystem/ootype.py`_ is a runnable implementation of
+`rpython/rtyper/ootypesystem/ootype.py`_ is a runnable implementation of
 these types, for testing purposes.
 
 
 The LLInterpreter is a simple piece of code that is able to interpret flow
 graphs. This is very useful for testing purposes, especially if you work on
 the RPython Typer. The most useful interface for it is the ``interpret``
-function in the file `pypy/rpython/test/test_llinterp.py`_. It takes as
+function in the file `rpython/rtyper/test/test_llinterp.py`_. It takes as
 arguments a function and a list of arguments with which the function is
 supposed to be called. Then it generates the flow graph, annotates it
 according to the types of the arguments you passed to it and runs the