[pypy-commit] pypy pypy3-release-2.1.x: merge py3k
pjenvey
noreply at buildbot.pypy.org
Tue Jul 30 09:02:08 CEST 2013
Author: Philip Jenvey <pjenvey at underboss.org>
Branch: pypy3-release-2.1.x
Changeset: r65808:f2ffcfcdbe0b
Date: 2013-07-29 23:54 -0700
http://bitbucket.org/pypy/pypy/changeset/f2ffcfcdbe0b/
Log: merge py3k
diff too long, truncating to 2000 out of 49976 lines
diff --git a/LICENSE b/LICENSE
--- a/LICENSE
+++ b/LICENSE
@@ -297,30 +297,6 @@
under the Python Software License of which you can find a copy here:
http://www.python.org/doc/Copyright.html
-License for 'rpython/translator/jvm/src/jna.jar'
-=============================================
-
-The file 'rpyhton/translator/jvm/src/jna.jar' is licensed under the GNU
-Lesser General Public License of which you can find a copy here:
-http://www.gnu.org/licenses/lgpl.html
-
-License for 'rpython/translator/jvm/src/jasmin.jar'
-================================================
-
-The file 'rpyhton/translator/jvm/src/jasmin.jar' is copyright (c) 1996-2004 Jon Meyer
-and distributed with permission. The use of Jasmin by PyPy does not imply
-that PyPy is endorsed by Jon Meyer nor any of Jasmin's contributors. Furthermore,
-the following disclaimer applies to Jasmin:
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
-WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
-ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
-TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
-ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
License for 'pypy/module/unicodedata/'
======================================
diff --git a/lib-python/2.7/distutils/sysconfig_pypy.py b/lib-python/2.7/distutils/sysconfig_pypy.py
--- a/lib-python/2.7/distutils/sysconfig_pypy.py
+++ b/lib-python/2.7/distutils/sysconfig_pypy.py
@@ -12,6 +12,7 @@
import sys
import os
+import shlex
from distutils.errors import DistutilsPlatformError
@@ -65,11 +66,6 @@
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
@@ -127,34 +123,21 @@
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 (
diff --git a/lib-python/3/distutils/sysconfig_pypy.py b/lib-python/3/distutils/sysconfig_pypy.py
--- a/lib-python/3/distutils/sysconfig_pypy.py
+++ b/lib-python/3/distutils/sysconfig_pypy.py
@@ -12,6 +12,7 @@
import sys
import os
+import shlex
from distutils.errors import DistutilsPlatformError
@@ -124,11 +125,19 @@
if compiler.compiler_type == "unix":
compiler.compiler_so.extend(['-O2', '-fPIC', '-Wimplicit'])
compiler.shared_lib_extension = get_config_var('SO')
+ 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 = os.environ["CFLAGS"].split()
+ 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 (
diff --git a/lib_pypy/_pypy_irc_topic.py b/lib_pypy/_pypy_irc_topic.py
--- a/lib_pypy/_pypy_irc_topic.py
+++ b/lib_pypy/_pypy_irc_topic.py
@@ -165,6 +165,63 @@
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
diff --git a/pypy/config/pypyoption.py b/pypy/config/pypyoption.py
--- a/pypy/config/pypyoption.py
+++ b/pypy/config/pypyoption.py
@@ -50,11 +50,6 @@
"termios", "_minimal_curses",
]))
-working_oo_modules = default_modules.copy()
-working_oo_modules.update(dict.fromkeys(
- ["_md5", "itertools"]
-))
-
# XXX this should move somewhere else, maybe to platform ("is this posixish"
# check or something)
if sys.platform == "win32":
@@ -332,10 +327,6 @@
if not IS_64_BITS:
config.objspace.std.suggest(withsmalllong=True)
- # some optimizations have different effects depending on the typesystem
- if type_system == 'ootype':
- config.objspace.std.suggest(multimethods="doubledispatch")
-
# extra optimizations with the JIT
if level == 'jit':
config.objspace.std.suggest(withcelldict=True)
@@ -343,10 +334,7 @@
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
diff --git a/pypy/doc/cli-backend.rst b/pypy/doc/cli-backend.rst
deleted file mode 100644
--- a/pypy/doc/cli-backend.rst
+++ /dev/null
@@ -1,455 +0,0 @@
-===============
-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/
diff --git a/pypy/doc/clr-module.rst b/pypy/doc/clr-module.rst
deleted file mode 100644
--- a/pypy/doc/clr-module.rst
+++ /dev/null
@@ -1,143 +0,0 @@
-===============================
-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.
diff --git a/pypy/doc/config/objspace.usemodules.clr.txt b/pypy/doc/config/objspace.usemodules.clr.txt
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.clr.txt
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the 'clr' module.
diff --git a/pypy/doc/config/translation.cli.trace_calls.txt b/pypy/doc/config/translation.cli.trace_calls.txt
deleted file mode 100644
--- a/pypy/doc/config/translation.cli.trace_calls.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal. Debugging aid for the CLI backend.
-
-.. internal
diff --git a/pypy/doc/config/translation.ootype.mangle.txt b/pypy/doc/config/translation.ootype.mangle.txt
deleted file mode 100644
--- a/pypy/doc/config/translation.ootype.mangle.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-Mangle the names of user defined attributes of the classes, in order
-to ensure that every name is unique. Default is true, and it should
-not be turned off unless you know what you are doing.
diff --git a/pypy/doc/config/translation.ootype.txt b/pypy/doc/config/translation.ootype.txt
deleted file mode 100644
--- a/pypy/doc/config/translation.ootype.txt
+++ /dev/null
@@ -1,1 +0,0 @@
-This group contains options specific for ootypesystem.
diff --git a/pypy/doc/cpython_differences.rst b/pypy/doc/cpython_differences.rst
--- a/pypy/doc/cpython_differences.rst
+++ b/pypy/doc/cpython_differences.rst
@@ -45,7 +45,6 @@
binascii
bz2
cStringIO
- clr
cmath
`cpyext`_
crypt
diff --git a/pypy/doc/dir-reference.rst b/pypy/doc/dir-reference.rst
--- a/pypy/doc/dir-reference.rst
+++ b/pypy/doc/dir-reference.rst
@@ -1,8 +1,8 @@
-PyPy directory cross-reference
+PyPy directory cross-reference
------------------------------
-Here is a fully referenced alphabetical two-level deep
-directory overview of PyPy:
+Here is a fully referenced alphabetical two-level deep
+directory overview of PyPy:
================================= ============================================
Directory explanation/links
@@ -24,7 +24,7 @@
``doc/*/`` other specific documentation topics or tools
`pypy/interpreter/`_ `bytecode interpreter`_ and related objects
- (frames, functions, modules,...)
+ (frames, functions, modules,...)
`pypy/interpreter/pyparser/`_ interpreter-level Python source parser
@@ -32,7 +32,7 @@
via an AST representation
`pypy/module/`_ contains `mixed modules`_
- implementing core modules with
+ implementing core modules with
both application and interpreter level code.
Not all are finished and working. Use
the ``--withmod-xxx``
@@ -45,7 +45,7 @@
objects and types
`pypy/tool/`_ various utilities and hacks used
- from various places
+ from various places
`pypy/tool/algo/`_ general-purpose algorithmic and mathematic
tools
@@ -54,7 +54,7 @@
`rpython/annotator/`_ `type inferencing code`_ for
- `RPython`_ programs
+ `RPython`_ programs
`rpython/config/`_ handles the numerous options for RPython
@@ -65,65 +65,56 @@
`rpython/rlib/`_ a `"standard library"`_ for RPython_
programs
-`rpython/rtyper/`_ the `RPython Typer`_
+`rpython/rtyper/`_ the `RPython Typer`_
`rpython/rtyper/lltypesystem/`_ the `low-level type system`_ for
C-like backends
-`rpython/rtyper/ootypesystem/`_ the `object-oriented type system`_
- for OO backends
-
`rpython/memory/`_ the `garbage collector`_ construction
framework
`rpython/translator/`_ translation_ backends and support code
-`rpython/translator/backendopt/`_ general optimizations that run before a
+`rpython/translator/backendopt/`_ general optimizations that run before a
backend generates code
`rpython/translator/c/`_ the `GenC backend`_, producing C code
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`_
``*/test/`` many directories have a test subdirectory
- containing test
- modules (see `Testing in PyPy`_)
+ containing test
+ modules (see `Testing in PyPy`_)
``_cache/`` holds cache files from various purposes
================================= ============================================
.. _`bytecode interpreter`: interpreter.html
-.. _`Testing in PyPy`: coding-guide.html#testing-in-pypy
-.. _`mixed modules`: coding-guide.html#mixed-modules
-.. _`modules`: coding-guide.html#modules
+.. _`Testing in PyPy`: coding-guide.html#testing-in-pypy
+.. _`mixed modules`: coding-guide.html#mixed-modules
+.. _`modules`: coding-guide.html#modules
.. _`basil`: http://people.cs.uchicago.edu/~jriehl/BasilTalk.pdf
.. _`object space`: objspace.html
-.. _FlowObjSpace: objspace.html#the-flow-object-space
+.. _FlowObjSpace: objspace.html#the-flow-object-space
.. _`transparent proxies`: objspace-proxies.html#tproxy
.. _`Differences between PyPy and CPython`: cpython_differences.html
.. _`What PyPy can do for your objects`: objspace-proxies.html
.. _`Continulets and greenlets`: stackless.html
-.. _StdObjSpace: objspace.html#the-standard-object-space
+.. _StdObjSpace: objspace.html#the-standard-object-space
.. _`abstract interpretation`: http://en.wikipedia.org/wiki/Abstract_interpretation
-.. _`rpython`: coding-guide.html#rpython
-.. _`type inferencing code`: translation.html#the-annotation-pass
-.. _`RPython Typer`: translation.html#rpython-typer
+.. _`rpython`: coding-guide.html#rpython
+.. _`type inferencing code`: translation.html#the-annotation-pass
+.. _`RPython Typer`: translation.html#rpython-typer
.. _`testing methods`: coding-guide.html#testing-in-pypy
-.. _`translation`: translation.html
-.. _`GenC backend`: translation.html#genc
-.. _`CLI backend`: cli-backend.html
+.. _`translation`: translation.html
+.. _`GenC backend`: translation.html#genc
.. _`py.py`: getting-started-python.html#the-py.py-interpreter
.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
.. _JIT: jit/index.html
diff --git a/pypy/doc/discussion/VM-integration.rst b/pypy/doc/discussion/VM-integration.rst
deleted file mode 100644
--- a/pypy/doc/discussion/VM-integration.rst
+++ /dev/null
@@ -1,263 +0,0 @@
-==============================================
-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.
-
-
diff --git a/pypy/doc/discussion/outline-external-ootype.rst b/pypy/doc/discussion/outline-external-ootype.rst
deleted file mode 100644
--- a/pypy/doc/discussion/outline-external-ootype.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-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.
diff --git a/pypy/doc/discussions.rst b/pypy/doc/discussions.rst
--- a/pypy/doc/discussions.rst
+++ b/pypy/doc/discussions.rst
@@ -7,7 +7,7 @@
.. toctree::
-
+
discussion/finalizer-order.rst
discussion/howtoimplementpickling.rst
discussion/improve-rpython.rst
diff --git a/pypy/doc/dot-net.rst b/pypy/doc/dot-net.rst
deleted file mode 100644
--- a/pypy/doc/dot-net.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.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
diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -369,13 +369,11 @@
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
------------------
diff --git a/pypy/doc/getting-started-dev.rst b/pypy/doc/getting-started-dev.rst
--- a/pypy/doc/getting-started-dev.rst
+++ b/pypy/doc/getting-started-dev.rst
@@ -115,45 +115,6 @@
>>> f(6)
1
-Translating the flow graph to CLI or JVM code
-+++++++++++++++++++++++++++++++++++++++++++++
-
-PyPy also contains a `CLI backend`_ and JVM backend which
-can translate flow graphs into .NET executables or a JVM jar
-file respectively. Both are able to translate the entire
-interpreter. You can try out the CLI and JVM backends
-from the interactive translator shells as follows::
-
- >>> def myfunc(a, b): return a+b
- ...
- >>> t = Translation(myfunc, [int, int])
- >>> t.annotate()
- >>> f = t.compile_cli() # or compile_jvm()
- >>> f(4, 5)
- 9
-
-The object returned by ``compile_cli`` or ``compile_jvm``
-is a wrapper around the real
-executable: the parameters are passed as command line arguments, and
-the returned value is read from the standard output.
-
-Once you have compiled the snippet, you can also try to launch the
-executable directly from the shell. You will find the
-executable in one of the ``/tmp/usession-*`` directories::
-
- # For CLI:
- $ mono /tmp/usession-trunk-<username>/main.exe 4 5
- 9
-
- # For JVM:
- $ java -cp /tmp/usession-trunk-<username>/pypy pypy.Main 4 5
- 9
-
-To translate and run for the CLI you must have the SDK installed: Windows
-users need the `.NET Framework SDK`_, while Linux and Mac users
-can use Mono_. To translate and run for the JVM you must have a JDK
-installed (at least version 6) and ``java``/``javac`` on your path.
-
A slightly larger example
+++++++++++++++++++++++++
@@ -191,31 +152,31 @@
There are several environment variables you can find useful while playing with the RPython:
``PYPY_USESSION_DIR``
- RPython uses temporary session directories to store files that are generated during the
+ RPython uses temporary session directories to store files that are generated during the
translation process(e.g., translated C files). ``PYPY_USESSION_DIR`` serves as a base directory for these session
dirs. The default value for this variable is the system's temporary dir.
``PYPY_USESSION_KEEP``
- By default RPython keeps only the last ``PYPY_USESSION_KEEP`` (defaults to 3) session dirs inside ``PYPY_USESSION_DIR``.
+ By default RPython keeps only the last ``PYPY_USESSION_KEEP`` (defaults to 3) session dirs inside ``PYPY_USESSION_DIR``.
Increase this value if you want to preserve C files longer (useful when producing lots of lldebug builds).
.. _`your own interpreters`: faq.html#how-do-i-compile-my-own-interpreters
-.. _`start reading sources`:
+.. _`start reading sources`:
Where to start reading the sources
-----------------------------------
+----------------------------------
PyPy is made from parts that are relatively independent of each other.
You should start looking at the part that attracts you most (all paths are
-relative to the PyPy top level directory). You may look at our `directory reference`_
+relative to the PyPy top level directory). You may look at our `directory reference`_
or start off at one of the following points:
* `pypy/interpreter`_ contains the bytecode interpreter: bytecode dispatcher
in `pypy/interpreter/pyopcode.py`_, frame and code objects in `pypy/interpreter/eval.py`_ and `pypy/interpreter/pyframe.py`_,
function objects and argument passing in `pypy/interpreter/function.py`_ and `pypy/interpreter/argument.py`_,
the object space interface definition in `pypy/interpreter/baseobjspace.py`_, modules in
- `pypy/interpreter/module.py`_ and `pypy/interpreter/mixedmodule.py`_. Core types supporting the bytecode
+ `pypy/interpreter/module.py`_ and `pypy/interpreter/mixedmodule.py`_. Core types supporting the bytecode
interpreter are defined in `pypy/interpreter/typedef.py`_.
* `pypy/interpreter/pyparser`_ contains a recursive descent parser,
@@ -253,7 +214,7 @@
.. _`RPython standard library`: rlib.html
-.. _optionaltool:
+.. _optionaltool:
Running PyPy's unit tests
@@ -284,7 +245,7 @@
# 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
@@ -352,14 +313,14 @@
.. _`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
@@ -384,24 +345,24 @@
.. _`example-interpreter`: https://bitbucket.org/pypy/example-interpreter
-Additional Tools for running (and hacking) PyPy
+Additional Tools for running (and hacking) PyPy
-----------------------------------------------
-We use some optional tools for developing PyPy. They are not required to run
+We use some optional tools for developing PyPy. They are not required to run
the basic tests or to get an interactive PyPy prompt but they help to
-understand and debug PyPy especially for the translation process.
+understand and debug PyPy especially for the translation process.
graphviz & pygame for flow graph viewing (highly recommended)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
graphviz and pygame are both necessary if you
-want to look at generated flow graphs:
+want to look at generated flow graphs:
- graphviz: http://www.graphviz.org/Download.php
+ graphviz: http://www.graphviz.org/Download.php
pygame: http://www.pygame.org/download.shtml
-py.test and the py lib
+py.test and the py lib
+++++++++++++++++++++++
The `py.test testing tool`_ drives all our testing needs.
@@ -412,7 +373,7 @@
You don't necessarily need to install these two libraries because
we also ship them inlined in the PyPy source tree.
-Getting involved
+Getting involved
-----------------
PyPy employs an open development process. You are invited to join our
diff --git a/pypy/doc/getting-started-python.rst b/pypy/doc/getting-started-python.rst
--- a/pypy/doc/getting-started-python.rst
+++ b/pypy/doc/getting-started-python.rst
@@ -6,7 +6,7 @@
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
@@ -18,8 +18,8 @@
.. _`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
@@ -31,8 +31,8 @@
.. _`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
@@ -71,9 +71,9 @@
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
@@ -82,7 +82,7 @@
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::
@@ -91,8 +91,8 @@
python ../../rpython/bin/rpython --opt=jit targetpypystandalone.py
possibly replacing ``--opt=jit`` with another `optimization level`_
- of your choice like ``--opt=2`` if you do not want to include the JIT
- compiler, which makes the Python interpreter much slower.
+ of your choice. Typical example: ``--opt=2`` gives a good (but of
+ course slower) Python interpreter without the JIT.
.. _`optimization level`: config/opt.html
@@ -119,7 +119,7 @@
>>>> 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
@@ -142,70 +142,6 @@
.. _`objspace proxies`: objspace-proxies.html
-.. _`CLI code`:
-
-Translating using the CLI backend
-+++++++++++++++++++++++++++++++++
-
-**Note: the CLI backend is no longer maintained**
-
-To create a standalone .NET executable using the `CLI backend`_::
-
- ./translate.py --backend=cli targetpypystandalone.py
-
-The executable and all its dependencies will be stored in the
-./pypy-cli-data directory. To run pypy.NET, you can run
-./pypy-cli-data/main.exe. If you are using Linux or Mac, you can use
-the convenience ./pypy-cli script::
-
- $ ./pypy-cli
- Python 2.7.0 (61ef2a11b56a, Mar 02 2011, 03:00:11)
- [PyPy 1.6.0] on linux2
- Type "help", "copyright", "credits" or "license" for more information.
- And now for something completely different: ``distopian and utopian chairs''
- >>>>
-
-Moreover, at the moment it's not possible to do the full translation
-using only the tools provided by the Microsoft .NET SDK, since
-``ilasm`` crashes when trying to assemble the pypy-cli code due to its
-size. Microsoft .NET SDK 2.0.50727.42 is affected by this bug; other
-versions could be affected as well: if you find a version of the SDK
-that works, please tell us.
-
-Windows users that want to compile their own pypy-cli can install
-Mono_: if a Mono installation is detected the translation toolchain
-will automatically use its ``ilasm2`` tool to assemble the
-executables.
-
-To try out the experimental .NET integration, check the documentation of the
-clr_ module.
-
-.. not working now:
-
- .. _`JVM code`:
-
- Translating using the JVM backend
- +++++++++++++++++++++++++++++++++
-
- To create a standalone JVM executable::
-
- ./translate.py --backend=jvm targetpypystandalone.py
-
- This will create a jar file ``pypy-jvm.jar`` as well as a convenience
- script ``pypy-jvm`` for executing it. To try it out, simply run
- ``./pypy-jvm``::
-
- $ ./pypy-jvm
- Python 2.7.0 (61ef2a11b56a, Mar 02 2011, 03:00:11)
- [PyPy 1.6.0] on linux2
- Type "help", "copyright", "credits" or "license" for more information.
- And now for something completely different: ``# assert did not crash''
- >>>>
-
- Alternatively, you can run it using ``java -jar pypy-jvm.jar``. At the moment
- the executable does not provide any interesting features, like integration with
- Java.
-
Installation
++++++++++++
@@ -258,22 +194,22 @@
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
@@ -300,9 +236,7 @@
.. _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
diff --git a/pypy/doc/glossary.rst b/pypy/doc/glossary.rst
--- a/pypy/doc/glossary.rst
+++ b/pypy/doc/glossary.rst
@@ -26,8 +26,7 @@
backend
Code generator that converts an `RPython
<coding-guide.html#restricted-python>`__ program to a `target
- language`_ using the :term:`RPython toolchain`. A backend uses either the
- :term:`lltypesystem` or the :term:`ootypesystem`.
+ language`_ using the :term:`RPython toolchain`.
compile-time
In the context of the :term:`JIT`, compile time is when the JIT is
@@ -84,12 +83,6 @@
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
diff --git a/pypy/doc/project-documentation.rst b/pypy/doc/project-documentation.rst
--- a/pypy/doc/project-documentation.rst
+++ b/pypy/doc/project-documentation.rst
@@ -72,8 +72,6 @@
`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.
diff --git a/pypy/doc/release-2.1.0-beta2.rst b/pypy/doc/release-2.1.0-beta2.rst
--- a/pypy/doc/release-2.1.0-beta2.rst
+++ b/pypy/doc/release-2.1.0-beta2.rst
@@ -5,6 +5,10 @@
We're pleased to announce the second beta of the upcoming 2.1 release of PyPy.
This beta adds one new feature to the 2.1 release and contains several bugfixes listed below.
+You can download the PyPy 2.1 beta 1 release here:
+
+ http://pypy.org/download.html
+
Highlights
==========
diff --git a/pypy/doc/rtyper.rst b/pypy/doc/rtyper.rst
--- a/pypy/doc/rtyper.rst
+++ b/pypy/doc/rtyper.rst
@@ -432,226 +432,6 @@
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.
More information about the pypy-commit
mailing list