Commits

wlav committed 6dddd0f Merge

merge default into branch

  • Participants
  • Parent commits 7351885, 1a3d9bf
  • Branches reflex-support

Comments (0)

Files changed (540)

File _pytest/pdb.py

File contents unchanged.

File lib-python/2/collections.py

 import heapq as _heapq
 from itertools import repeat as _repeat, chain as _chain, starmap as _starmap
 from itertools import imap as _imap
+try:
+    from __pypy__ import newdict
+except ImportError:
+    assert '__pypy__' not in _sys.builtin_module_names
+    newdict = lambda _ : {}
 
 try:
     from thread import get_ident as _get_ident
 
     # Execute the template string in a temporary namespace and
     # support tracing utilities by setting a value for frame.f_globals['__name__']
-    namespace = dict(__name__='namedtuple_%s' % typename,
-                     OrderedDict=OrderedDict, _property=property, _tuple=tuple)
+    namespace = newdict('module')
+    namespace['OrderedDict'] = OrderedDict
+    namespace['_property'] = property
+    namespace['_tuple'] = tuple
+    namespace['__name__'] = 'namedtuple_%s' % typename
     try:
         exec template in namespace
     except SyntaxError, e:

File lib-python/2/distutils/sysconfig_pypy.py

     leaving off the patchlevel.  Sample return values could be '1.5'
     or '2.2'.
     """
-    return sys.version[0]
+    return sys.version[:3]
 
 
 def get_python_lib(plat_specific=0, standard_lib=0, prefix=None):
     if prefix is None:
         prefix = PREFIX
     if standard_lib:
-        return os.path.join(prefix, "lib-python", get_python_version())
+        return os.path.join(prefix, "lib-python", sys.version[0])
     return os.path.join(prefix, 'site-packages')
 
 
     g['SO'] = _get_so_extension() or ".so"
     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
 
     global _config_vars
     _config_vars = g

File lib-python/2/pickle.py

 except ImportError:
     from StringIO import StringIO
 
+try:
+    from __pypy__.builders import StringBuilder
+except ImportError:
+    assert '__pypy__' not in sys.builtin_module_names
+    StringBuilderFile = StringIO
+else:
+    class StringBuilderFile(object):
+        ''' pickle uses only file.write - provide this method,
+        use StringBuilder for speed
+        '''
+        def __init__(self):
+            self.builder = StringBuilder()
+            self.write = self.builder.append
+            self.getvalue = self.builder.build
+
 def dump(obj, file, protocol=None):
     Pickler(file, protocol).dump(obj)
 
 def dumps(obj, protocol=None):
-    file = StringIO()
+    file = StringBuilderFile()
     Pickler(file, protocol).dump(obj)
     return file.getvalue()
 

File lib-python/2/sre_parse.py

 try:
     from __pypy__ import newdict
 except ImportError:
-    def newdict(tp):
-        return {}
+    assert '__pypy__' not in sys.builtin_module_names
+    newdict = lambda _ : {}
 
 SPECIAL_CHARS = ".\\[{()*+?^$|"
 REPEAT_CHARS = "*+?{"

File lib_pypy/_marshal.py

 # the "sandboxed" process.  It must work for Python2 as well.
 
 import types
-from _codecs import utf_8_decode, utf_8_encode
 
 try:
     intern
 
     def dump_unicode(self, x):
         self._write(TYPE_UNICODE)
-        #s = x.encode('utf8')
-        s, len_s = utf_8_encode(x)
-        self.w_long(len_s)
+        s = x.encode('utf8')
+        self.w_long(len(s))
         self._write(s)
     try:
         unicode
     def load_unicode(self):
         n = self.r_long()
         s = self._read(n)
-        #ret = s.decode('utf8')
-        ret, len_ret = utf_8_decode(s)
+        ret = s.decode('utf8')
         return ret
     dispatch[TYPE_UNICODE] = load_unicode
 

File lib_pypy/_sqlite3.py

         self._in_transaction = False
         self.isolation_level = isolation_level
 
-        self._cursors = []
+        self.__cursors = []
+        self.__cursors_counter = 0
         self.__statements = []
-        self.__statement_counter = 0
+        self.__statements_counter = 0
         self._statement_cache = _StatementCache(self, cached_statements)
 
         self.__func_cache = {}
     def close(self):
         self._check_thread()
 
-        for statement in self.__statements:
-            obj = statement()
-            if obj is not None:
-                obj._finalize()
+        self.__do_all_statements(Statement._finalize, True)
 
         if self._db:
             ret = _lib.sqlite3_close(self._db)
         exc.error_code = error_code
         return exc
 
+    def _remember_cursor(self, cursor):
+        self.__cursors.append(weakref.ref(cursor))
+        self.__cursors_counter += 1
+        if self.__cursors_counter < 200:
+            return
+        self.__cursors_counter = 0
+        self.__cursors = [r for r in self.__cursors if r() is not None]
+
     def _remember_statement(self, statement):
         self.__statements.append(weakref.ref(statement))
-        self.__statement_counter += 1
+        self.__statements_counter += 1
+        if self.__statements_counter < 200:
+            return
+        self.__statements_counter = 0
+        self.__statements = [r for r in self.__statements if r() is not None]
 
-        if self.__statement_counter % 100 == 0:
-            self.__statements = [ref for ref in self.__statements
-                                 if ref() is not None]
+    def __do_all_statements(self, action, reset_cursors):
+        for weakref in self.__statements:
+            statement = weakref()
+            if statement is not None:
+                action(statement)
+
+        if reset_cursors:
+            for weakref in self.__cursors:
+                cursor = weakref()
+                if cursor is not None:
+                    cursor._reset = True
 
     @_check_thread_wrap
     @_check_closed_wrap
         if not self._in_transaction:
             return
 
-        for statement in self.__statements:
-            obj = statement()
-            if obj is not None:
-                obj._reset()
+        self.__do_all_statements(Statement._reset, False)
 
         statement = c_void_p()
         ret = _lib.sqlite3_prepare_v2(self._db, b"COMMIT", -1,
         if not self._in_transaction:
             return
 
-        for statement in self.__statements:
-            obj = statement()
-            if obj is not None:
-                obj._reset()
-
-        for cursor_ref in self._cursors:
-            cursor = cursor_ref()
-            if cursor:
-                cursor._reset = True
+        self.__do_all_statements(Statement._reset, True)
 
         statement = c_void_p()
         ret = _lib.sqlite3_prepare_v2(self._db, b"ROLLBACK", -1,
     __statement = None
 
     def __init__(self, con):
-        self.__initialized = True
-        self.__connection = con
-
         if not isinstance(con, Connection):
             raise TypeError
-        con._check_thread()
-        con._check_closed()
-        con._cursors.append(weakref.ref(self))
+        self.__connection = con
 
         self.arraysize = 1
         self.row_factory = None
         self.__description = None
         self.__rowcount = -1
 
+        con._check_thread()
+        con._remember_cursor(self)
+
+        self.__initialized = True
+
     def __del__(self):
-        try:
-            self.__connection._cursors.remove(weakref.ref(self))
-        except (AttributeError, ValueError):
-            pass
         if self.__statement:
             self.__statement._reset()
 
                     self.__rowcount += _lib.sqlite3_changes(self.__connection._db)
         finally:
             self.__locked = False
-
         return self
 
     @__check_cursor_wrap
             if rc != _lib.SQLITE_DONE:
                 _lib.sqlite3_finalize(statement)
                 if rc == _lib.SQLITE_OK:
-                    return self
+                    break
                 else:
                     raise self.__connection._get_exception(rc)
+
             rc = _lib.sqlite3_finalize(statement)
             if rc != _lib.SQLITE_OK:
                 raise self.__connection._get_exception(rc)
 
     def __init__(self, connection, sql):
         self.__con = connection
+        self.__con._remember_statement(self)
 
         if not isinstance(sql, basestring):
             raise Warning("SQL is of wrong type. Must be string or unicode.")
             ret = _lib.sqlite3_prepare_v2(self.__con._db, sql, -1,
                                           byref(self._statement), byref(sql))
             self._kind = Statement._DQL
-
         if ret != _lib.SQLITE_OK:
             raise self.__con._get_exception(ret)
-        self.__con._remember_statement(self)
+
         sql = sql.value.decode('utf-8')
         if _check_remaining_sql(sql):
             raise Warning("You can only execute one statement at a time.")

File lib_pypy/cPickle.py

 
 from pickle import StringIO
 
+try:
+    from pickle import StringBuilderFile
+except ImportError:
+    assert '__pypy__' not in sys.builtin_module_names
+    StringBuilderFile = StringIO
+
 PythonPickler = Pickler
 class Pickler(PythonPickler):
     def __init__(self, *args, **kw):
         self.__f = None
         if len(args) == 1 and isinstance(args[0], int):
-            self.__f = StringIO()
+            self.__f = StringBuilderFile()
             PythonPickler.__init__(self, self.__f, args[0], **kw)
         else:
             PythonPickler.__init__(self, *args, **kw)
 
 @builtinify
 def dumps(obj, protocol=None):
-    file = StringIO()
+    file = StringBuilderFile()
     Pickler(file, protocol).dump(obj)
     return file.getvalue()
 

File lib_pypy/numpypy/core/numeric.py

            'array_repr', 'array_str', 'set_string_function',
            'array_equal', 'outer', 'vdot', 'identity', 'little_endian',
            'Inf', 'inf', 'infty', 'Infinity', 'nan', 'NaN', 'False_', 'True_',
+           'seterr',
           ]
 
 import sys

File lib_pypy/tputil.py

 """
 
-application level support module for transparent proxies. 
+application level support module for transparent proxies.
 
 """
-from __pypy__ import tproxy 
+from __pypy__ import tproxy
 from types import MethodType
 
 _dummy = object()
 origtype = type
 
-def make_proxy(controller, type=_dummy, obj=_dummy): 
-    """ return a tranparent proxy controlled by the given 
-        'controller' callable.  The proxy will appear 
-        as a completely regular instance of the given 
-        type but all operations on it are send to the 
-        specified controller - which receives on 
-        ProxyOperation instance on each such call.  
-        A non-specified type will default to type(obj) 
-        if obj is specified. 
+def make_proxy(controller, type=_dummy, obj=_dummy):
+    """ return a tranparent proxy controlled by the given
+        'controller' callable.  The proxy will appear
+        as a completely regular instance of the given
+        type but all operations on it are send to the
+        specified controller - which receives on
+        ProxyOperation instance on each such call.
+        A non-specified type will default to type(obj)
+        if obj is specified.
     """
-    if type is _dummy: 
-        if obj is _dummy: 
-            raise TypeError("you must specify a type or an instance obj of it") 
-        type = origtype(obj) 
+    if type is _dummy:
+        if obj is _dummy:
+            raise TypeError("you must specify a type or an instance obj of it")
+        type = origtype(obj)
     def perform(opname, *args, **kwargs):
         operation = ProxyOperation(tp, obj, opname, args, kwargs)
-        return controller(operation) 
-    tp = tproxy(type, perform) 
-    return tp 
+        return controller(operation)
+    tp = tproxy(type, perform)
+    return tp
 
 class ProxyOperation(object):
     def __init__(self, proxyobj, obj, opname, args, kwargs):
         self.proxyobj = proxyobj
-        self.opname = opname 
+        self.opname = opname
         self.args = args
         self.kwargs = kwargs
-        if obj is not _dummy: 
-            self.obj = obj 
+        if obj is not _dummy:
+            self.obj = obj
 
     def delegate(self):
-        """ return result from delegating this operation to the 
-            underyling self.obj - which must exist and is usually 
-            provided through the initial make_proxy(..., obj=...) 
-            creation. 
-        """ 
+        """ return result from delegating this operation to the
+            underyling self.obj - which must exist and is usually
+            provided through the initial make_proxy(..., obj=...)
+            creation.
+        """
         try:
             obj = getattr(self, 'obj')
-        except AttributeError: 
+        except AttributeError:
             raise TypeError("proxy does not have an underlying 'obj', "
                             "cannot delegate")
-        objattr = getattr(obj, self.opname) 
-        res = objattr(*self.args, **self.kwargs) 
-        if self.opname == "__getattribute__": 
+        objattr = getattr(obj, self.opname)
+        res = objattr(*self.args, **self.kwargs)
+        if self.opname == "__getattribute__":
             if (isinstance(res, MethodType) and
                 res.im_self is self.instance):
                 res = MethodType(res.im_func, self.proxyobj, res.im_class)
-        if res is self.obj: 
+        if res is self.obj:
             res = self.proxyobj
-        return res 
+        return res
 
     def __repr__(self):
         args = ", ".join([repr(x) for x in self.args])
-        args = "<0x%x>, " % id(self.proxyobj) + args 
+        args = "<0x%x>, " % id(self.proxyobj) + args
         if self.kwargs:
-            args += ", ".join(["%s=%r" % item 
+            args += ", ".join(["%s=%r" % item
                                   for item in self.kwargs.items()])
         return "<ProxyOperation %s.%s(%s)>" %(
                     type(self.proxyobj).__name__, self.opname, args)
+
+* ARM

File pypy/bin/checkmodule.py

         modname = os.path.basename(modname)
     try:
         checkmodule(modname)
-    except Exception, e:
+    except Exception:
         import traceback, pdb
         traceback.print_exc()
         pdb.post_mortem(sys.exc_info()[2])

File pypy/bin/dotviewer.py

 Run with no arguments for help.
 """
 
+import os
 import sys
 sys.path.insert(0, os.path.realpath(os.path.join(os.path.dirname(__file__), '..', '..')))
 from dotviewer.dotviewer import main

File pypy/bin/pyinteractive.py

 
 """
 
-import os, sys
+import os
+import sys
 import time
 
 sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..', '..'))
 
-import pypy
 from pypy.tool import option
-from optparse import make_option
 from pypy.interpreter import main, interactive, error, gateway
 from rpython.config.config import OptionDescription, BoolOption, StrOption
 from rpython.config.config import Config, to_optparse

File pypy/bin/reportstaticdata.py

 
 
 def main():
-    import sys
     try:
         kwds = parse_options(sys.argv[1:])
     except AssertionError:

File pypy/config/test/test_makerestdoc.py

+import py
+
 from rpython.config.config import *
 from pypy.config.makerestdoc import make_cmdline_overview
-
 from pypy.tool.rest.rest import process as restcheck
 
 tempdir = py.test.ensuretemp('config')
 def generate_html(descr):
     config = Config(descr)
     txt = descr.make_rest_doc().text()
-    
+
     result = {"": txt}
     for path in config.getpaths(include_groups=True):
         subconf, step = config._cfgimpl_get_home_by_path(path)

File pypy/doc/architecture.rst

 
  * a compliant, flexible and fast implementation of the Python_ Language 
    which uses the above toolchain to enable new advanced high-level features 
-   without having to encode the low-level details.
+   without having to encode the low-level details.  We call this PyPy.
 
 By separating concerns in this way, our implementation
 of Python - and other dynamic languages - is able to automatically
 High Level Goals
 =============================
 
-PyPy - the Translation Framework 
+RPython - the Translation Toolchain
 -----------------------------------------------
 
 Traditionally, language interpreters are written in a target platform language
 very challenging because of the involved complexity.
 
 
-PyPy - the Python Interpreter 
+PyPy - the Python Interpreter
 --------------------------------------------
 
 Our main motivation for developing the translation framework is to
 of `Extreme Programming`_, the architecture of PyPy has evolved over time
 and continues to evolve.  Nevertheless, the high level architecture is 
 stable. As described above, there are two rather independent basic
-subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
+subsystems: the `PyPy Python Interpreter`_ and the `RPython Translation Toolchain`_.
 
 .. _`translation framework`:
 
-The Translation Framework
+RPython Translation Toolchain
 -------------------------
 
 The job of the RPython toolchain is to translate RPython_ programs
 
 * Optionally, `various transformations`_ can then be applied which, for
   example, perform optimizations such as inlining, add capabilities
-  such as stackless-style concurrency (deprecated), or insert code for the
+  such as stackless-style concurrency, or insert code for the
   `garbage collector`_.
 
 * Then, the graphs are converted to source code for the target platform
 .. _`standard interpreter`: 
 .. _`python interpreter`: 
 
-The Python Interpreter
+PyPy Python Interpreter
 -------------------------------------
 
 PyPy's *Python Interpreter* is written in RPython and implements the

File pypy/doc/discussion/improve-rpython.rst

   implement a pypy module. A typical rpython file is likely to contain many
   `import` statements::
 
-    from pypy.interpreter.baseobjspace import Wrappable
+    from pypy.interpreter.baseobjspace import W_Root
     from pypy.interpreter.gateway import ObjSpace, W_Root
     from pypy.interpreter.argument import Arguments
     from pypy.interpreter.typedef import TypeDef, GetSetProperty
 
 - A more direct declarative way to write Typedef::
 
-    class W_Socket(Wrappable):
+    class W_Socket(W_Root):
         _typedef_name_ = 'socket'
         _typedef_base_ = W_EventualBaseClass
 

File pypy/doc/faq.rst

 CPython extension and replace it with a pure python version that the
 JIT can see.
 
-We fully support ctypes-based extensions.
+We fully support ctypes-based extensions. But for best performance, we
+recommend that you use the cffi_ module to interface with C code.
 
 For information on which third party extensions work (or do not work) 
 with PyPy see the `compatibility wiki`_.
 
 .. _`extension modules`: cpython_differences.html#extension-modules
 .. _`cpython differences`: cpython_differences.html
-.. _`compatibility wiki`: https://bitbucket.org/pypy/compatibility/wiki/Home
+.. _`compatibility wiki`:
+.. https://bitbucket.org/pypy/compatibility/wiki/Home
+.. _cffi: http://cffi.readthedocs.org/
 
 ---------------------------------
 On which platforms does PyPy run?
 bootstrap, as cross compilation is not really meant to work yet.
 At the moment you need CPython 2.5 - 2.7
 for the translation process. PyPy's JIT requires an x86 or x86_64 CPU.
+(There has also been good progress on getting the JIT working for ARMv7.)
 
 ------------------------------------------------
 Which Python version (2.x?) does PyPy implement?
 * Second, and perhaps most important: do you have a really good reason
   for writing the module in RPython in the first place?  Nowadays you
   should really look at alternatives, like writing it in pure Python,
-  using ctypes if it needs to call C code.  Other alternatives are being
-  developed too (as of summer 2011), like a Cython binding.
+  using cffi_ if it needs to call C code.
 
 In this context it is not that important to be able to translate
 RPython modules independently of translating the complete interpreter.

File pypy/doc/getting-started-dev.rst

 The translator is a tool based on the PyPy interpreter which can translate
 sufficiently static RPython programs into low-level code (in particular it can
 be used to translate the `full Python interpreter`_). To be able to experiment with it
-you need to:
+you need to download and install the usual (CPython) version of:
 
-  * Download and install Pygame_.
-
-  * Download and install `Dot Graphviz`_ 
+  * Pygame_
+  * `Dot Graphviz`_
 
 To start the interactive translator shell do::
 
 
 There is a small-to-medium demo showing the translator and the annotator::
 
-    cd demo
-    ../rpython/translator/goal/translate.py --view --annotate bpnn.py
+    python bin/rpython --view --annotate translator/goal/bpnn.py
 
 This causes ``bpnn.py`` to display itself as a call graph and class
 hierarchy.  Clicking on functions shows the flow graph of the particular
 To turn this example to C code (compiled to the executable ``bpnn-c``),
 type simply::
 
-    ../rpython/translator/goal/translate.py bpnn.py
+    python bin/rpython translator/goal/bpnn.py
 
 
 Translating Full Programs
 ``rpython/translator/goal``. Examples for this are a slightly changed version of
 Pystone::
 
-    cd rpython/translator/goal
-    python translate.py targetrpystonedalone
+    python bin/rpython translator/goal/targetrpystonedalone
 
 This will produce the executable "targetrpystonedalone-c".
 
 interpreter`_. There is also an FAQ about how to set up this process for `your
 own interpreters`_.
 
+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 
+    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``. 
+    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`: 

File pypy/doc/interpreter.rst

 ===================================
-Bytecode Interpreter 
+Bytecode Interpreter
 ===================================
 
 .. contents::
 Introduction and Overview
 ===============================
 
-This document describes the implementation of PyPy's 
-Bytecode Interpreter and related Virtual Machine functionalities. 
+This document describes the implementation of PyPy's
+Bytecode Interpreter and related Virtual Machine functionalities.
 
 PyPy's bytecode interpreter has a structure reminiscent of CPython's
 Virtual Machine: It processes code objects parsed and compiled from
 translated with the rest of PyPy.
 
 Code objects contain
-condensed information about their respective functions, class and 
+condensed information about their respective functions, class and
 module body source codes.  Interpreting such code objects means
 instantiating and initializing a `Frame class`_ and then
-calling its ``frame.eval()`` method.  This main entry point 
-initialize appropriate namespaces and then interprets each 
+calling its ``frame.eval()`` method.  This main entry point
+initialize appropriate namespaces and then interprets each
 bytecode instruction.  Python's standard library contains
-the `lib-python/2.7/dis.py`_ module which allows to inspection 
-of the virtual machine's bytecode instructions:: 
+the `lib-python/2.7/dis.py`_ module which allows to inspection
+of the virtual machine's bytecode instructions::
 
     >>> import dis
     >>> def f(x):
     >>> dis.dis(f)
     2         0 LOAD_FAST                0 (x)
               3 LOAD_CONST               1 (1)
-              6 BINARY_ADD          
-              7 RETURN_VALUE        
+              6 BINARY_ADD
+              7 RETURN_VALUE
 
 CPython and PyPy are stack-based virtual machines, i.e.
 they don't have registers but instead push object to and pull objects
 from a stack.  The bytecode interpreter is only responsible
 for implementing control flow and pushing and pulling black
-box objects to and from this value stack.  The bytecode interpreter 
+box objects to and from this value stack.  The bytecode interpreter
 does not know how to perform operations on those black box
 (`wrapped`_) objects for which it delegates to the `object
 space`_.  In order to implement a conditional branch in a program's
 execution, however, it needs to gain minimal knowledge about a
 wrapped object.  Thus, each object space has to offer a
 ``is_true(w_obj)`` operation which returns an
-interpreter-level boolean value.  
+interpreter-level boolean value.
 
 For the understanding of the interpreter's inner workings it
 is crucial to recognize the concepts of `interpreter-level and
 application-level`_ code.  In short, interpreter-level is executed
-directly on the machine and invoking application-level functions 
-leads to an bytecode interpretation indirection. However, 
+directly on the machine and invoking application-level functions
+leads to an bytecode interpretation indirection. However,
 special care must be taken regarding exceptions because
-application level exceptions are wrapped into ``OperationErrors`` 
-which are thus distinguished from plain interpreter-level exceptions. 
+application level exceptions are wrapped into ``OperationErrors``
+which are thus distinguished from plain interpreter-level exceptions.
 See `application level exceptions`_ for some more information
-on ``OperationErrors``. 
+on ``OperationErrors``.
 
 The interpreter implementation offers mechanisms to allow a
-caller to be unaware of whether a particular function invocation 
+caller to be unaware of whether a particular function invocation
 leads to bytecode interpretation or is executed directly at
 interpreter-level.  The two basic kinds of `Gateway classes`_
 expose either an interpreter-level function to
 application-level execution (``interp2app``) or allow
 transparent invocation of application-level helpers
-(``app2interp``) at interpreter-level. 
+(``app2interp``) at interpreter-level.
 
-Another task of the bytecode interpreter is to care for exposing its 
-basic code, frame, module and function objects to application-level 
-code.  Such runtime introspection and modification abilities are 
-implemented via `interpreter descriptors`_ (also see Raymond Hettingers 
-`how-to guide for descriptors`_ in Python, PyPy uses this model extensively). 
+Another task of the bytecode interpreter is to care for exposing its
+basic code, frame, module and function objects to application-level
+code.  Such runtime introspection and modification abilities are
+implemented via `interpreter descriptors`_ (also see Raymond Hettingers
+`how-to guide for descriptors`_ in Python, PyPy uses this model extensively).
 
-A significant complexity lies in `function argument parsing`_.  Python as a 
-language offers flexible ways of providing and receiving arguments 
-for a particular function invocation.  Not only does it take special care 
+A significant complexity lies in `function argument parsing`_.  Python as a
+language offers flexible ways of providing and receiving arguments
+for a particular function invocation.  Not only does it take special care
 to get this right, it also presents difficulties for the `annotation
 pass`_ which performs a whole-program analysis on the
 bytecode interpreter, argument parsing and gatewaying code
 in order to infer the types of all values flowing across function
-calls. 
+calls.
 
 It is for this reason that PyPy resorts to generate
 specialized frame classes and functions at `initialization
-time`_ in order to let the annotator only see rather static 
-program flows with homogeneous name-value assignments on 
-function invocations. 
+time`_ in order to let the annotator only see rather static
+program flows with homogeneous name-value assignments on
+function invocations.
 
 .. _`how-to guide for descriptors`: http://users.rcn.com/python/download/Descriptor.htm
 .. _`annotation pass`: translation.html#the-annotation-pass
 .. _`initialization time`: translation.html#initialization-time
-.. _`interpreter-level and application-level`: coding-guide.html#interpreter-level 
+.. _`interpreter-level and application-level`: coding-guide.html#interpreter-level
 .. _`wrapped`: coding-guide.html#wrapping-rules
 .. _`object space`: objspace.html
 .. _`application level exceptions`: coding-guide.html#applevel-exceptions
 .. _`here`: coding-guide.html#modules
 
 
-Bytecode Interpreter Implementation Classes  
+Bytecode Interpreter Implementation Classes
 ================================================
 
-.. _`Frame class`: 
-.. _`Frame`: 
+.. _`Frame class`:
+.. _`Frame`:
 
 Frame classes
 -----------------
 
-The concept of Frames is pervasive in executing programs and 
+The concept of Frames is pervasive in executing programs and
 on virtual machines in particular. They are sometimes called
 *execution frame* because they hold crucial information
 regarding the execution of a Code_ object, which in turn is
 often directly related to a Python `Function`_.  Frame
-instances hold the following state: 
+instances hold the following state:
 
-- the local scope holding name-value bindings, usually implemented 
+- the local scope holding name-value bindings, usually implemented
   via a "fast scope" which is an array of wrapped objects
 
 - a blockstack containing (nested) information regarding the
-  control flow of a function (such as ``while`` and ``try`` constructs) 
+  control flow of a function (such as ``while`` and ``try`` constructs)
 
 - a value stack where bytecode interpretation pulls object
   from and puts results on.
 
 - a reference to the *globals* dictionary, containing
-  module-level name-value bindings 
+  module-level name-value bindings
 
-- debugging information from which a current line-number and 
-  file location can be constructed for tracebacks 
+- debugging information from which a current line-number and
+  file location can be constructed for tracebacks
 
 Moreover the Frame class itself has a number of methods which implement
 the actual bytecodes found in a code object.  The methods of the ``PyFrame``
 - nested scope support is added to the ``PyFrame`` class in
   `pypy/interpreter/nestedscope.py`_.
 
-.. _Code: 
+.. _Code:
 
-Code Class 
------------- 
+Code Class
+------------
 
-PyPy's code objects contain the same information found in CPython's code objects. 
-They differ from Function_ objects in that they are only immutable representations 
+PyPy's code objects contain the same information found in CPython's code objects.
+They differ from Function_ objects in that they are only immutable representations
 of source code and don't contain execution state or references to the execution
-environment found in `Frames`.  Frames and Functions have references 
+environment found in `Frames`.  Frames and Functions have references
 to a code object. Here is a list of Code attributes:
 
-* ``co_flags`` flags if this code object has nested scopes/generators 
+* ``co_flags`` flags if this code object has nested scopes/generators
 * ``co_stacksize`` the maximum depth the stack can reach while executing the code
-* ``co_code`` the actual bytecode string 
- 
-* ``co_argcount`` number of arguments this code object expects 
+* ``co_code`` the actual bytecode string
+
+* ``co_argcount`` number of arguments this code object expects
 * ``co_varnames`` a tuple of all argument names pass to this code object
-* ``co_nlocals`` number of local variables 
+* ``co_nlocals`` number of local variables
 * ``co_names`` a tuple of all names used in the code object
-* ``co_consts`` a tuple of prebuilt constant objects ("literals") used in the code object 
-* ``co_cellvars`` a tuple of Cells containing values for access from nested scopes 
-* ``co_freevars`` a tuple of Cell names from "above" scopes 
- 
-* ``co_filename`` source file this code object was compiled from 
-* ``co_firstlineno`` the first linenumber of the code object in its source file 
-* ``co_name`` name of the code object (often the function name) 
-* ``co_lnotab`` a helper table to compute the line-numbers corresponding to bytecodes 
+* ``co_consts`` a tuple of prebuilt constant objects ("literals") used in the code object
+* ``co_cellvars`` a tuple of Cells containing values for access from nested scopes
+* ``co_freevars`` a tuple of Cell names from "above" scopes
+
+* ``co_filename`` source file this code object was compiled from
+* ``co_firstlineno`` the first linenumber of the code object in its source file
+* ``co_name`` name of the code object (often the function name)
+* ``co_lnotab`` a helper table to compute the line-numbers corresponding to bytecodes
 
 In PyPy, code objects also have the responsibility of creating their Frame_ objects
 via the `'create_frame()`` method.  With proper parser and compiler support this would
 allow to create custom Frame objects extending the execution of functions
 in various ways.  The several Frame_ classes already utilize this flexibility
-in order to implement Generators and Nested Scopes. 
+in order to implement Generators and Nested Scopes.
 
-.. _Function: 
+.. _Function:
 
 Function and Method classes
 ----------------------------
 
-The PyPy ``Function`` class (in `pypy/interpreter/function.py`_) 
-represents a Python function.  A ``Function`` carries the following 
-main attributes: 
+The PyPy ``Function`` class (in `pypy/interpreter/function.py`_)
+represents a Python function.  A ``Function`` carries the following
+main attributes:
 
-* ``func_doc`` the docstring (or None) 
-* ``func_name`` the name of the function 
-* ``func_code`` the Code_ object representing the function source code 
+* ``func_doc`` the docstring (or None)
+* ``func_name`` the name of the function
+* ``func_code`` the Code_ object representing the function source code
 * ``func_defaults`` default values for the function (built at function definition time)
-* ``func_dict`` dictionary for additional (user-defined) function attributes 
-* ``func_globals`` reference to the globals dictionary 
-* ``func_closure`` a tuple of Cell references  
+* ``func_dict`` dictionary for additional (user-defined) function attributes
+* ``func_globals`` reference to the globals dictionary
+* ``func_closure`` a tuple of Cell references
 
 ``Functions`` classes also provide a ``__get__`` descriptor which creates a Method
 object holding a binding to an instance or a class.  Finally, ``Functions``
-and ``Methods`` both offer a ``call_args()`` method which executes 
-the function given an `Arguments`_ class instance. 
+and ``Methods`` both offer a ``call_args()`` method which executes
+the function given an `Arguments`_ class instance.
 
-.. _Arguments: 
-.. _`function argument parsing`: 
+.. _Arguments:
+.. _`function argument parsing`:
 
-Arguments Class 
--------------------- 
+Arguments Class
+--------------------
 
 The Argument class (in `pypy/interpreter/argument.py`_) is
-responsible for parsing arguments passed to functions.  
+responsible for parsing arguments passed to functions.
 Python has rather complex argument-passing concepts:
 
-- positional arguments 
+- positional arguments
 
-- keyword arguments specified by name 
+- keyword arguments specified by name
 
 - default values for positional arguments, defined at function
-  definition time 
+  definition time
 
 - "star args" allowing a function to accept remaining
-  positional arguments 
+  positional arguments
 
-- "star keyword args" allow a function to accept additional 
-  arbitrary name-value bindings 
+- "star keyword args" allow a function to accept additional
+  arbitrary name-value bindings
 
-Moreover, a Function_ object can get bound to a class or instance 
+Moreover, a Function_ object can get bound to a class or instance
 in which case the first argument to the underlying function becomes
-the bound object.  The ``Arguments`` provides means to allow all 
-this argument parsing and also cares for error reporting. 
+the bound object.  The ``Arguments`` provides means to allow all
+this argument parsing and also cares for error reporting.
 
 
-.. _`Module`: 
+.. _`Module`:
 
-Module Class 
-------------------- 
+Module Class
+-------------------
 
-A ``Module`` instance represents execution state usually constructed 
+A ``Module`` instance represents execution state usually constructed
 from executing the module's source file.  In addition to such a module's
-global ``__dict__`` dictionary it has the following application level 
-attributes: 
+global ``__dict__`` dictionary it has the following application level
+attributes:
 
 * ``__doc__`` the docstring of the module
-* ``__file__`` the source filename from which this module was instantiated 
-* ``__path__`` state used for relative imports 
+* ``__file__`` the source filename from which this module was instantiated
+* ``__path__`` state used for relative imports
 
 Apart from the basic Module used for importing
 application-level files there is a more refined
 level and at interpreter level.  See the ``__builtin__``
 module's `pypy/module/__builtin__/__init__.py`_ file for an
 example and the higher level `chapter on Modules in the coding
-guide`_. 
+guide`_.
 
 .. _`__builtin__ module`: https://bitbucket.org/pypy/pypy/src/tip/pypy/module/__builtin__/
-.. _`chapter on Modules in the coding guide`: coding-guide.html#modules 
+.. _`chapter on Modules in the coding guide`: coding-guide.html#modules
 
-.. _`Gateway classes`: 
+.. _`Gateway classes`:
 
-Gateway classes 
----------------------- 
+Gateway classes
+----------------------
 
 A unique PyPy property is the ability to easily cross the barrier
 between interpreted and machine-level code (often referred to as
-the difference between `interpreter-level and application-level`_). 
-Be aware that the according code (in `pypy/interpreter/gateway.py`_) 
+the difference between `interpreter-level and application-level`_).
+Be aware that the according code (in `pypy/interpreter/gateway.py`_)
 for crossing the barrier in both directions is somewhat
 involved, mostly due to the fact that the type-inferring
 annotator needs to keep track of the types of objects flowing
-across those barriers. 
+across those barriers.
 
 .. _typedefs:
 
 Making interpreter-level functions available at application-level
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-In order to make an interpreter-level function available at 
-application level, one invokes ``pypy.interpreter.gateway.interp2app(func)``. 
-Such a function usually takes a ``space`` argument and any number 
+In order to make an interpreter-level function available at
+application level, one invokes ``pypy.interpreter.gateway.interp2app(func)``.
+Such a function usually takes a ``space`` argument and any number
 of positional arguments. Additionally, such functions can define
 an ``unwrap_spec`` telling the ``interp2app`` logic how
 application-level provided arguments should be unwrapped
-before the actual interpreter-level function is invoked. 
-For example, `interpreter descriptors`_ such as the ``Module.__new__`` 
-method for allocating and constructing a Module instance are 
-defined with such code:: 
+before the actual interpreter-level function is invoked.
+For example, `interpreter descriptors`_ such as the ``Module.__new__``
+method for allocating and constructing a Module instance are
+defined with such code::
 
     Module.typedef = TypeDef("module",
         __new__ = interp2app(Module.descr_module__new__.im_func,
                              unwrap_spec=[ObjSpace, W_Root, Arguments]),
         __init__ = interp2app(Module.descr_module__init__),
                         # module dictionaries are readonly attributes
-        __dict__ = GetSetProperty(descr_get_dict, cls=Module), 
-        __doc__ = 'module(name[, doc])\n\nCreate a module object...' 
+        __dict__ = GetSetProperty(descr_get_dict, cls=Module),
+        __doc__ = 'module(name[, doc])\n\nCreate a module object...'
         )
 
-The actual ``Module.descr_module__new__`` interpreter-level method 
-referenced from the ``__new__`` keyword argument above is defined 
-like this:: 
+The actual ``Module.descr_module__new__`` interpreter-level method
+referenced from the ``__new__`` keyword argument above is defined
+like this::
 
     def descr_module__new__(space, w_subtype, __args__):
         module = space.allocate_instance(Module, w_subtype)
         Module.__init__(module, space, None)
         return space.wrap(module)
 
-Summarizing, the ``interp2app`` mechanism takes care to route 
-an application level access or call to an internal interpreter-level 
+Summarizing, the ``interp2app`` mechanism takes care to route
+an application level access or call to an internal interpreter-level
 object appropriately to the descriptor, providing enough precision
-and hints to keep the type-inferring annotator happy. 
+and hints to keep the type-inferring annotator happy.
 
 
-Calling into application level code from interpreter-level 
+Calling into application level code from interpreter-level
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-Application level code is `often preferable`_. Therefore, 
-we often like to invoke application level code from interpreter-level. 
+Application level code is `often preferable`_. Therefore,
+we often like to invoke application level code from interpreter-level.
 This is done via the Gateway's ``app2interp`` mechanism
-which we usually invoke at definition time in a module. 
-It generates a hook which looks like an interpreter-level 
-function accepting a space and an arbitrary number of arguments. 
-When calling a function at interpreter-level the caller side 
+which we usually invoke at definition time in a module.
+It generates a hook which looks like an interpreter-level
+function accepting a space and an arbitrary number of arguments.
+When calling a function at interpreter-level the caller side
 does usually not need to be aware if its invoked function
 is run through the PyPy interpreter or if it will directly
-execute on the machine (after translation). 
+execute on the machine (after translation).
 
-Here is an example showing how we implement the Metaclass 
+Here is an example showing how we implement the Metaclass
 finding algorithm of the Python language in PyPy::
 
     app = gateway.applevel(r'''
 
     find_metaclass  = app.interphook('find_metaclass')
 
-The ``find_metaclass`` interpreter-level hook is invoked 
+The ``find_metaclass`` interpreter-level hook is invoked
 with five arguments from the ``BUILD_CLASS`` opcode implementation
-in `pypy/interpreter/pyopcode.py`_:: 
+in `pypy/interpreter/pyopcode.py`_::
 
     def BUILD_CLASS(f):
         w_methodsdict = f.valuestack.pop()
                                            w_bases, w_methodsdict)
         f.valuestack.push(w_newclass)
 
-Note that at a later point we can rewrite the ``find_metaclass`` 
-implementation at interpreter-level and we would not have 
-to modify the calling side at all. 
+Note that at a later point we can rewrite the ``find_metaclass``
+implementation at interpreter-level and we would not have
+to modify the calling side at all.
 
 .. _`often preferable`: coding-guide.html#app-preferable
-.. _`interpreter descriptors`: 
+.. _`interpreter descriptors`:
 
-Introspection and Descriptors 
+Introspection and Descriptors
 ------------------------------
 
-Python traditionally has a very far-reaching introspection model 
+Python traditionally has a very far-reaching introspection model
 for bytecode interpreter related objects. In PyPy and in CPython read
-and write accesses to such objects are routed to descriptors. 
+and write accesses to such objects are routed to descriptors.
 Of course, in CPython those are implemented in ``C`` while in
-PyPy they are implemented in interpreter-level Python code. 
+PyPy they are implemented in interpreter-level Python code.
 
 All instances of a Function_, Code_, Frame_ or Module_ classes
-are also ``Wrappable`` instances which means they can be represented 
+are also ``W_Root`` instances which means they can be represented
 at application level.  These days, a PyPy object space needs to
 work with a basic descriptor lookup when it encounters
 accesses to an interpreter-level object:  an object space asks
-a wrapped object for its type via a ``getclass`` method and then 
-calls the type's ``lookup(name)`` function in order to receive a descriptor 
+a wrapped object for its type via a ``getclass`` method and then
+calls the type's ``lookup(name)`` function in order to receive a descriptor
 function.  Most of PyPy's internal object descriptors are defined at the
-end of `pypy/interpreter/typedef.py`_.  You can use these definitions 
-as a reference for the exact attributes of interpreter classes visible 
-at application level. 
+end of `pypy/interpreter/typedef.py`_.  You can use these definitions
+as a reference for the exact attributes of interpreter classes visible
+at application level.
 
 .. include:: _ref.txt

File pypy/doc/jit/pyjitpl5.rst

 implemented.  It's helpful to have an understanding of how the `RPython translation
 toolchain`_ works before digging into the sources.
 
-Almost all JIT specific code is found in pypy/jit subdirectories.  Translation
+Almost all JIT specific code is found in rpython/jit subdirectories.  Translation
 time code is in the codewriter directory.  The metainterp directory holds
 platform independent code including the the tracer and the optimizer.  Code in
 the backend directory is responsible for generating machine code.
 
 * `Tracing the Meta-Level: PyPy's Tracing JIT Compiler`__
 
-.. __: http://codespeak.net/svn/pypy/extradoc/talk/icooolps2009/bolz-tracing-jit-final.pdf
+.. __: https://bitbucket.org/pypy/extradoc/src/tip/talk/icooolps2009/bolz-tracing-jit-final.pdf
 
 as well as the `blog posts with the JIT tag.`__
 

File pypy/doc/objspace.rst

 ``wrap(x):``
   Returns a wrapped object that is a reference to the interpreter-level object
   x. This can be used either on simple immutable objects (integers,
-  strings...) to create a new wrapped object, or on instances of ``Wrappable``
+  strings...) to create a new wrapped object, or on instances of ``W_Root``
   to obtain an application-level-visible reference to them.  For example,
-  most classes of the bytecode interpreter subclass ``Wrappable`` and can
+  most classes of the bytecode interpreter subclass ``W_Root`` and can
   be directly exposed to app-level in this way - functions, frames, code
   objects, etc.
 

File pypy/doc/test/test_whatsnew.py

 import py
 import pypy
-from commands import getoutput
+from commands import getoutput, getstatusoutput
 ROOT = py.path.local(pypy.__file__).dirpath().dirpath()
 
 
     return startrev, branches
 
 def get_merged_branches(path, startrev, endrev):
+    if getstatusoutput('hg root')[0]:
+        py.test.skip('no Mercurial repo')
+
     # X = take all the merges which are descendants of startrev and are on default
     # revset = all the parents of X which are not on default
     # ===>

File pypy/doc/whatsnew-head.rst

 .. branch: callback-jit
 Callbacks from C are now better JITted
 
+.. branch: fix-jit-logs
+
 .. branch: remove-globals-in-jit
 
 .. branch: length-hint
 
 .. branch: numpypy-longdouble
 Long double support for numpypy
+
 .. branch: numpypy-disable-longdouble
 Since r_longdouble support is missing, disable all longdouble and derivative
 dtypes using ENABLED_LONG_DOUBLE = False
+
 .. branch: numpypy-real-as-view
 Convert real, imag from ufuncs to views. This involves the beginning of
 view() functionality
 
+.. branch: indexing-by-array
+Adds indexing by scalar, adds int conversion from scalar and single element array,
+fixes compress, indexing by an array with a smaller shape and the indexed object.
+
+.. branch: str-dtype-improvement
+Allow concatenation of str and numeric arrays
+
 .. branch: signatures
 Improved RPython typing
 
 .. branch: numpy-unify-methods
 .. branch: fix-version-tool
 .. branch: popen2-removal
+.. branch: pickle-dumps
+.. branch: scalar_get_set
 
 .. branch: release-2.0-beta1
 
 
 .. branch: vendor-rename
 Remove minor verison number from lib-python dirs to simplify stdlib upgrades.
+
+.. branch: jitframe-on-heap
+Moves optimized JIT frames from stack to heap. As a side effect it enables
+stackless to work well with the JIT on PyPy. Also removes a bunch of code from
+the GC which fixes cannot find gc roots.
+
+.. branch: pycon2013-doc-fixes
+Documentation fixes after going through the docs at PyCon 2013 sprint.
+
+.. branch: extregistry-refactor
+
+.. branch: remove-list-smm