[pypy-commit] pypy default: merge heads
bivab
noreply at buildbot.pypy.org
Tue Apr 30 10:51:08 CEST 2013
Author: David Schneider <david.schneider at picle.org>
Branch:
Changeset: r63766:c770cb4118f9
Date: 2013-04-30 08:46 +0000
http://bitbucket.org/pypy/pypy/changeset/c770cb4118f9/
Log: merge heads
diff too long, truncating to 2000 out of 24414 lines
diff --git a/Makefile b/Makefile
new file mode 100644
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,7 @@
+
+all: pypy-c
+
+pypy-c:
+ @echo "Building PyPy with JIT, it'll take about 40 minutes and 4G of RAM"
+ @sleep 3
+ rpython/bin/rpython -Ojit pypy/goal/targetpypystandalone.py
diff --git a/README.rst b/README.rst
--- a/README.rst
+++ b/README.rst
@@ -13,12 +13,25 @@
http://pypy.org/
-The getting-started document will help guide you:
+If you want to help developing PyPy, this document might help you:
- http://doc.pypy.org/en/latest/getting-started.html
+ http://doc.pypy.org/
It will also point you to the rest of the documentation which is generated
from files in the pypy/doc directory within the source repositories. Enjoy
and send us feedback!
the pypy-dev team <pypy-dev at python.org>
+
+Building
+========
+
+build with::
+
+ rpython/bin/rpython -Ojit pypy/goal/targetpypystandalone.py
+
+This ends up with ``pypy-c`` binary in the main pypy directory. We suggest
+to use virtualenv with the resulting pypy-c as the interpreter, you can
+find more details about various installation schemes here:
+
+http://doc.pypy.org/en/latest/getting-started.html#installing-pypy
diff --git a/lib-python/2.7/json/decoder.py b/lib-python/2.7/json/decoder.py
--- a/lib-python/2.7/json/decoder.py
+++ b/lib-python/2.7/json/decoder.py
@@ -162,7 +162,7 @@
if nextchar == '}':
if object_pairs_hook is not None:
result = object_pairs_hook(pairs)
- return result, end
+ return result, end + 1
pairs = {}
if object_hook is not None:
pairs = object_hook(pairs)
diff --git a/lib-python/2.7/json/tests/test_decode.py b/lib-python/2.7/json/tests/test_decode.py
--- a/lib-python/2.7/json/tests/test_decode.py
+++ b/lib-python/2.7/json/tests/test_decode.py
@@ -44,6 +44,7 @@
object_pairs_hook=OrderedDict,
object_hook=lambda x: None),
OrderedDict(p))
+ self.assertEqual(self.loads("{}", object_pairs_hook=list), [])
class TestPyDecode(TestDecode, PyTest): pass
diff --git a/lib-python/2.7/pydoc.py b/lib-python/2.7/pydoc.py
--- a/lib-python/2.7/pydoc.py
+++ b/lib-python/2.7/pydoc.py
@@ -1953,7 +1953,11 @@
if key is None:
callback(None, modname, '')
else:
- desc = split(__import__(modname).__doc__ or '', '\n')[0]
+ try:
+ module_doc = __import__(modname).__doc__
+ except ImportError:
+ module_doc = None
+ desc = split(module_doc or '', '\n')[0]
if find(lower(modname + ' - ' + desc), key) >= 0:
callback(None, modname, desc)
diff --git a/lib-python/2.7/test/test_descr.py b/lib-python/2.7/test/test_descr.py
--- a/lib-python/2.7/test/test_descr.py
+++ b/lib-python/2.7/test/test_descr.py
@@ -3592,6 +3592,9 @@
list.__init__(a, sequence=[0, 1, 2])
self.assertEqual(a, [0, 1, 2])
+ @unittest.skipIf(test_support.check_impl_detail(pypy=True) and
+ sys.platform == 'win32',
+ "XXX: https://bugs.pypy.org/issue1461")
def test_recursive_call(self):
# Testing recursive __call__() by setting to instance of class...
class A(object):
diff --git a/lib-python/2.7/test/test_fileio.py b/lib-python/2.7/test/test_fileio.py
--- a/lib-python/2.7/test/test_fileio.py
+++ b/lib-python/2.7/test/test_fileio.py
@@ -318,7 +318,6 @@
self.assertRaises(ValueError, _FileIO, -10)
self.assertRaises(OSError, _FileIO, make_bad_fd())
if sys.platform == 'win32':
- raise unittest.SkipTest('Set _invalid_parameter_handler for low level io')
import msvcrt
self.assertRaises(IOError, msvcrt.get_osfhandle, make_bad_fd())
diff --git a/lib_pypy/_curses.py b/lib_pypy/_curses.py
--- a/lib_pypy/_curses.py
+++ b/lib_pypy/_curses.py
@@ -364,7 +364,9 @@
key_n = ffi.string(key_n)
if key_n == b"UNKNOWN KEY":
continue
- key_n = key_n.decode().replace('(', '').replace(')', '')
+ if not isinstance(key_n, str): # python 3
+ key_n = key_n.decode()
+ key_n = key_n.replace('(', '').replace(')', '')
globals()[key_n] = key
_setup()
diff --git a/lib_pypy/_functools.py b/lib_pypy/_functools.py
--- a/lib_pypy/_functools.py
+++ b/lib_pypy/_functools.py
@@ -20,3 +20,16 @@
if self.keywords is not None:
fkeywords = dict(self.keywords, **fkeywords)
return self.func(*(self.args + fargs), **fkeywords)
+
+ def __reduce__(self):
+ d = dict((k, v) for k, v in self.__dict__.iteritems() if k not in
+ ('func', 'args', 'keywords'))
+ if len(d) == 0:
+ d = None
+ return (type(self), (self.func,),
+ (self.func, self.args, self.keywords, d))
+
+ def __setstate__(self, state):
+ self.func, self.args, self.keywords, d = state
+ if d is not None:
+ self.__dict__.update(d)
diff --git a/lib_pypy/_pypy_interact.py b/lib_pypy/_pypy_interact.py
--- a/lib_pypy/_pypy_interact.py
+++ b/lib_pypy/_pypy_interact.py
@@ -44,7 +44,7 @@
import code
if mainmodule is None:
import __main__ as mainmodule
- console = code.InteractiveConsole(mainmodule.__dict__)
+ console = code.InteractiveConsole(mainmodule.__dict__, filename='<stdin>')
# some parts of code.py are copied here because it seems to be impossible
# to start an interactive console without printing at least one line
# of banner
diff --git a/lib_pypy/_sqlite3.py b/lib_pypy/_sqlite3.py
--- a/lib_pypy/_sqlite3.py
+++ b/lib_pypy/_sqlite3.py
@@ -256,7 +256,13 @@
typedef ... sqlite3;
int sqlite3_enable_load_extension(sqlite3 *db, int onoff);
""")
- unverified_lib = unverified_ffi.dlopen('sqlite3')
+ libname = 'sqlite3'
+ if sys.platform == 'win32':
+ import os
+ _libname = os.path.join(os.path.dirname(sys.executable), libname)
+ if os.path.exists(_libname + '.dll'):
+ libname = _libname
+ unverified_lib = unverified_ffi.dlopen(libname)
return hasattr(unverified_lib, 'sqlite3_enable_load_extension')
if _has_load_extension():
@@ -759,9 +765,9 @@
if isinstance(name, unicode):
name = name.encode('utf-8')
ret = _lib.sqlite3_create_collation(self._db, name,
- _lib.SQLITE_UTF8,
- _ffi.NULL,
- collation_callback)
+ _lib.SQLITE_UTF8,
+ _ffi.NULL,
+ collation_callback)
if ret != _lib.SQLITE_OK:
raise self._get_exception(ret)
@@ -780,9 +786,7 @@
return _lib.SQLITE_DENY
self.__func_cache[callback] = authorizer
- ret = _lib.sqlite3_set_authorizer(self._db,
- authorizer,
- _ffi.NULL)
+ ret = _lib.sqlite3_set_authorizer(self._db, authorizer, _ffi.NULL)
if ret != _lib.SQLITE_OK:
raise self._get_exception(ret)
@@ -798,15 +802,13 @@
@_ffi.callback("int(void*)")
def progress_handler(userdata):
try:
- ret = callable()
- return bool(ret)
+ return bool(callable())
except Exception:
# abort query if error occurred
return 1
self.__func_cache[callable] = progress_handler
- _lib.sqlite3_progress_handler(self._db, nsteps,
- progress_handler,
- _ffi.NULL)
+ _lib.sqlite3_progress_handler(self._db, nsteps, progress_handler,
+ _ffi.NULL)
if sys.version_info[0] >= 3:
def __get_in_transaction(self):
@@ -888,8 +890,8 @@
def __check_reset(self):
if self._reset:
raise InterfaceError(
- "Cursor needed to be reset because of commit/rollback "
- "and can no longer be fetched from.")
+ "Cursor needed to be reset because of commit/rollback "
+ "and can no longer be fetched from.")
def __build_row_cast_map(self):
if not self.__connection._detect_types:
@@ -996,17 +998,18 @@
# Actually execute the SQL statement
ret = _lib.sqlite3_step(self.__statement._statement)
- if ret not in (_lib.SQLITE_DONE, _lib.SQLITE_ROW):
- self.__statement._reset()
- raise self.__connection._get_exception(ret)
if ret == _lib.SQLITE_ROW:
if multiple:
raise ProgrammingError("executemany() can only execute DML statements.")
self.__build_row_cast_map()
self.__next_row = self.__fetch_one_row()
- elif ret == _lib.SQLITE_DONE and not multiple:
+ elif ret == _lib.SQLITE_DONE:
+ if not multiple:
+ self.__statement._reset()
+ else:
self.__statement._reset()
+ raise self.__connection._get_exception(ret)
if self.__statement._type in ("UPDATE", "DELETE", "INSERT", "REPLACE"):
if self.__rowcount == -1:
@@ -1087,7 +1090,6 @@
try:
next_row = self.__next_row
except AttributeError:
- self.__statement._reset()
raise StopIteration
del self.__next_row
@@ -1095,11 +1097,12 @@
next_row = self.row_factory(self, next_row)
ret = _lib.sqlite3_step(self.__statement._statement)
- if ret not in (_lib.SQLITE_DONE, _lib.SQLITE_ROW):
+ if ret == _lib.SQLITE_ROW:
+ self.__next_row = self.__fetch_one_row()
+ else:
self.__statement._reset()
- raise self.__connection._get_exception(ret)
- elif ret == _lib.SQLITE_ROW:
- self.__next_row = self.__fetch_one_row()
+ if ret != _lib.SQLITE_DONE:
+ raise self.__connection._get_exception(ret)
return next_row
if sys.version_info[0] < 3:
diff --git a/lib_pypy/cffi/api.py b/lib_pypy/cffi/api.py
--- a/lib_pypy/cffi/api.py
+++ b/lib_pypy/cffi/api.py
@@ -370,7 +370,10 @@
if key in ffi._parser._declarations:
tp = ffi._parser._declarations[key]
BType = ffi._get_cached_btype(tp)
- value = backendlib.load_function(BType, name)
+ try:
+ value = backendlib.load_function(BType, name)
+ except KeyError:
+ raise AttributeError(name)
library.__dict__[name] = value
return
#
diff --git a/lib_pypy/msvcrt.py b/lib_pypy/msvcrt.py
--- a/lib_pypy/msvcrt.py
+++ b/lib_pypy/msvcrt.py
@@ -8,25 +8,37 @@
# PAC: 2010/08 added MS locking for Whoosh
import ctypes
+import errno
from ctypes_support import standard_c_lib as _c
from ctypes_support import get_errno
-import errno
try:
open_osfhandle = _c._open_osfhandle
except AttributeError: # we are not on windows
raise ImportError
-try: from __pypy__ import builtinify
-except ImportError: builtinify = lambda f: f
+try: from __pypy__ import builtinify, validate_fd
+except ImportError: builtinify = validate_fd = lambda f: f
open_osfhandle.argtypes = [ctypes.c_int, ctypes.c_int]
open_osfhandle.restype = ctypes.c_int
-get_osfhandle = _c._get_osfhandle
-get_osfhandle.argtypes = [ctypes.c_int]
-get_osfhandle.restype = ctypes.c_int
+_get_osfhandle = _c._get_osfhandle
+_get_osfhandle.argtypes = [ctypes.c_int]
+_get_osfhandle.restype = ctypes.c_int
+
+ at builtinify
+def get_osfhandle(fd):
+ """"get_osfhandle(fd) -> file handle
+
+ Return the file handle for the file descriptor fd. Raises IOError if
+ fd is not recognized."""
+ try:
+ validate_fd(fd)
+ except OSError as e:
+ raise IOError(*e.args)
+ return _get_osfhandle(fd)
setmode = _c._setmode
setmode.argtypes = [ctypes.c_int, ctypes.c_int]
diff --git a/lib_pypy/pyrepl/python_reader.py b/lib_pypy/pyrepl/python_reader.py
--- a/lib_pypy/pyrepl/python_reader.py
+++ b/lib_pypy/pyrepl/python_reader.py
@@ -171,11 +171,11 @@
def execute(self, text):
try:
- # ooh, look at the hack:
+ # ooh, look at the hack:
code = self.compile("# coding:utf8\n"+text.encode('utf-8'),
- '<input>', 'single')
+ '<stdin>', 'single')
except (OverflowError, SyntaxError, ValueError):
- self.showsyntaxerror("<input>")
+ self.showsyntaxerror('<stdin>')
else:
self.runcode(code)
if sys.stdout and not sys.stdout.closed:
diff --git a/lib_pypy/pyrepl/simple_interact.py b/lib_pypy/pyrepl/simple_interact.py
--- a/lib_pypy/pyrepl/simple_interact.py
+++ b/lib_pypy/pyrepl/simple_interact.py
@@ -37,13 +37,13 @@
import code
if mainmodule is None:
import __main__ as mainmodule
- console = code.InteractiveConsole(mainmodule.__dict__)
+ console = code.InteractiveConsole(mainmodule.__dict__, filename='<stdin>')
def more_lines(unicodetext):
# ooh, look at the hack:
src = "#coding:utf-8\n"+unicodetext.encode('utf-8')
try:
- code = console.compile(src, '<input>', 'single')
+ code = console.compile(src, '<stdin>', 'single')
except (OverflowError, SyntaxError, ValueError):
return False
else:
diff --git a/py/_path/local.py b/py/_path/local.py
--- a/py/_path/local.py
+++ b/py/_path/local.py
@@ -655,7 +655,8 @@
mkdtemp = classmethod(mkdtemp)
def make_numbered_dir(cls, prefix='session-', rootdir=None, keep=3,
- lock_timeout = 172800): # two days
+ lock_timeout = 172800, # two days
+ min_timeout = 300): # five minutes
""" return unique directory with a number greater than the current
maximum one. The number is assumed to start directly after prefix.
if keep is true directories with a number less than (maxnum-keep)
@@ -723,6 +724,20 @@
for path in rootdir.listdir():
num = parse_num(path)
if num is not None and num <= (maxnum - keep):
+ if min_timeout:
+ # NB: doing this is needed to prevent (or reduce
+ # a lot the chance of) the following situation:
+ # 'keep+1' processes call make_numbered_dir() at
+ # the same time, they create dirs, but then the
+ # last process notices the first dir doesn't have
+ # (yet) a .lock in it and kills it.
+ try:
+ t1 = path.lstat().mtime
+ t2 = lockfile.lstat().mtime
+ if abs(t2-t1) < min_timeout:
+ continue # skip directories too recent
+ except py.error.Error:
+ continue # failure to get a time, better skip
lf = path.join('.lock')
try:
t1 = lf.lstat().mtime
diff --git a/pypy/config/pypyoption.py b/pypy/config/pypyoption.py
--- a/pypy/config/pypyoption.py
+++ b/pypy/config/pypyoption.py
@@ -35,7 +35,7 @@
"thread", "itertools", "pyexpat", "_ssl", "cpyext", "array",
"binascii", "_multiprocessing", '_warnings',
"_collections", "_multibytecodec", "micronumpy", "_ffi",
- "_continuation", "_cffi_backend", "_csv"]
+ "_continuation", "_cffi_backend", "_csv", "cppyy"]
))
translation_modules = default_modules.copy()
@@ -64,6 +64,8 @@
del working_modules["termios"]
del working_modules["_minimal_curses"]
+ del working_modules["cppyy"] # not tested on win32
+
# The _locale module is needed by site.py on Windows
default_modules["_locale"] = None
@@ -75,7 +77,7 @@
del working_modules["_minimal_curses"]
del working_modules["termios"]
del working_modules["_multiprocessing"] # depends on rctime
-
+ del working_modules["cppyy"] # depends on ctypes
module_dependencies = {
diff --git a/pypy/doc/arm.rst b/pypy/doc/arm.rst
--- a/pypy/doc/arm.rst
+++ b/pypy/doc/arm.rst
@@ -153,7 +153,7 @@
::
- pypy <path to rpython>/rpython/bin/rpython -Ojit --platform=arm --gcrootfinder=shadowstack --jit-backend=armv7 targetpypystandalone.py
+ pypy <path to rpython>/rpython/bin/rpython -Ojit --platform=arm --gcrootfinder=shadowstack --jit-backend=arm targetpypystandalone.py
The gcrootfinder option is needed to work around `issue 1377`_ and the jit-backend works around `issue 1376`_
diff --git a/pypy/doc/config/translation.gcrootfinder.txt b/pypy/doc/config/translation.gcrootfinder.txt
--- a/pypy/doc/config/translation.gcrootfinder.txt
+++ b/pypy/doc/config/translation.gcrootfinder.txt
@@ -9,7 +9,9 @@
- ``--gcrootfinder=asmgcc``: use assembler hackery to find the
roots directly from the normal stack. This is a bit faster,
but platform specific. It works so far with GCC or MSVC,
- on i386 and x86-64.
+ on i386 and x86-64. It is tested only on Linux (where it is
+ the default) so other platforms (as well as MSVC) may need
+ various fixes before they can be used.
You may have to force the use of the shadowstack root finder if
you are running into troubles or if you insist on translating
diff --git a/pypy/doc/cppyy.rst b/pypy/doc/cppyy.rst
--- a/pypy/doc/cppyy.rst
+++ b/pypy/doc/cppyy.rst
@@ -2,94 +2,128 @@
cppyy: C++ bindings for PyPy
============================
-The cppyy module provides C++ bindings for PyPy by using the reflection
-information extracted from C++ header files by means of the
-`Reflex package`_.
-For this to work, you have to both install Reflex and build PyPy from source,
-as the cppyy module is not enabled by default.
-Note that the development version of cppyy lives in the reflex-support
-branch.
-As indicated by this being a branch, support for Reflex is still
-experimental.
-However, it is functional enough to put it in the hands of those who want
-to give it a try.
-In the medium term, cppyy will move away from Reflex and instead use
-`cling`_ as its backend, which is based on `llvm`_.
-Although that will change the logistics on the generation of reflection
-information, it will not change the python-side interface.
+The cppyy module creates, at run-time, Python-side classes and functions for
+C++, by querying a C++ reflection system.
+The default system used is `Reflex`_, which extracts the needed information
+from C++ header files.
+Another current backend is based on `CINT`_, and yet another, more important
+one for the medium- to long-term will be based on `cling`_.
+The latter sits on top of `llvm`_'s `clang`_, and will therefore allow the use
+of C++11.
+The work on the cling backend has so far been done only for CPython, but
+bringing it to PyPy is a lot less work than developing it in the first place.
-.. _`Reflex package`: http://root.cern.ch/drupal/content/reflex
+.. _`Reflex`: http://root.cern.ch/drupal/content/reflex
+.. _`CINT`: http://root.cern.ch/drupal/content/cint
.. _`cling`: http://root.cern.ch/drupal/content/cling
.. _`llvm`: http://llvm.org/
+.. _`clang`: http://clang.llvm.org/
+
+This document describes the version of cppyy that lives in the main branch of
+PyPy.
+The development of cppyy happens in the "reflex-support" branch.
Motivation
==========
-The cppyy module offers two unique features, which result in great
-performance as well as better functionality and cross-language integration
-than would otherwise be possible.
-First, cppyy is written in RPython and therefore open to optimizations by the
-JIT up until the actual point of call into C++.
-This means that there are no conversions necessary between a garbage collected
-and a reference counted environment, as is needed for the use of existing
-extension modules written or generated for CPython.
-It also means that if variables are already unboxed by the JIT, they can be
-passed through directly to C++.
-Second, Reflex (and cling far more so) adds dynamic features to C++, thus
-greatly reducing impedance mismatches between the two languages.
-In fact, Reflex is dynamic enough that you could write the runtime bindings
+To provide bindings to another language in CPython, you program to a
+generic C-API that exposes many of the interpreter features.
+With PyPy, however, there is no such generic C-API, because several of the
+interpreter features (e.g. the memory model) are pluggable and therefore
+subject to change.
+Furthermore, a generic API does not allow any assumptions about the calls
+into another language, forcing the JIT to behave conservatively around these
+calls and with the objects that cross language boundaries.
+In contrast, cppyy does not expose an API, but expects one to be implemented
+by a backend.
+It makes strong assumptions about the semantics of the API that it uses and
+that in turn allows the JIT to make equally strong assumptions.
+This is possible, because the expected API is only for providing C++ language
+bindings, and does not provide generic programmability.
+
+The cppyy module further offers two features, which result in improved
+performance as well as better functionality and cross-language integration.
+First, cppyy itself is written in RPython and therefore open to optimizations
+by the JIT up until the actual point of call into C++.
+This means for example, that if variables are already unboxed by the JIT, they
+can be passed through directly to C++.
+Second, a backend such as Reflex (and cling far more so) adds dynamic features
+to C++, thus greatly reducing impedance mismatches between the two languages.
+For example, Reflex is dynamic enough to allow writing runtime bindings
generation in python (as opposed to RPython) and this is used to create very
natural "pythonizations" of the bound code.
+As another example, cling allows automatic instantiations of templates.
+
+See this description of the `cppyy architecture`_ for further details.
+
+.. _`cppyy architecture`: http://morepypy.blogspot.com/2012/06/architecture-of-cppyy.html
Installation
============
-For now, the easiest way of getting the latest version of Reflex, is by
-installing the ROOT package.
-Besides getting the latest version of Reflex, another advantage is that with
-the full ROOT package, you can also use your Reflex-bound code on `CPython`_.
-`Download`_ a binary or install from `source`_.
-Some Linux and Mac systems may have ROOT provided in the list of scientific
-software of their packager.
-If, however, you prefer a standalone version of Reflex, the best is to get
-this `recent snapshot`_, and install like so::
+There are two ways of using cppyy, and the choice depends on how pypy-c was
+built: the backend can be builtin, or dynamically loadable.
+The former has the disadvantage of requiring pypy-c to be linked with external
+C++ libraries (e.g. libReflex.so), but has the advantage of being faster in
+some cases.
+That advantage will disappear over time, however, with improvements in the
+JIT.
+Therefore, this document assumes that the dynamically loadable backend is
+chosen (it is, by default).
+See the `backend documentation`_.
- $ tar jxf reflex-2012-05-02.tar.bz2
- $ cd reflex-2012-05-02
- $ build/autogen
+.. _`backend documentation`: cppyy_backend.html
+
+A standalone version of Reflex that also provides the dynamically loadable
+backend is available for `download`_.
+That version, as well as any other distribution of Reflex (e.g. the one that
+comes with `ROOT`_, which may be part of your Linux distribution as part of
+the selection of scientific software) will also work for a build with the
+builtin backend.
+
+.. _`download`: http://cern.ch/wlav/reflex-2013-04-23.tar.bz2
+.. _`ROOT`: http://root.cern.ch/
+
+Besides Reflex, you probably need a version of `gccxml`_ installed, which is
+most easily provided by the packager of your system.
+If you read up on gccxml, you will probably notice that it is no longer being
+developed and hence will not provide C++11 support.
+That's why the medium term plan is to move to cling.
+Note that gccxml is only needed to generate reflection libraries.
+It is not needed to use them.
+
+.. _`gccxml`: http://www.gccxml.org
+
+To install the standalone version of Reflex, after download::
+
+ $ tar jxf reflex-2013-04-23.tar.bz2
+ $ cd reflex-2013-04-23
+ $ ./build/autogen
$ ./configure <usual set of options such as --prefix>
$ make && make install
-Also, make sure you have a version of `gccxml`_ installed, which is most
-easily provided by the packager of your system.
-If you read up on gccxml, you'll probably notice that it is no longer being
-developed and hence will not provide C++11 support.
-That's why the medium term plan is to move to `cling`_.
+The usual rules apply: <prefix>/bin needs to be added to the ``PATH`` and
+<prefix>/lib to the ``LD_LIBRARY_PATH`` environment variable.
+For convenience, this document will assume that there is a ``REFLEXHOME``
+variable that points to <prefix>.
+If you downloaded or built the whole of ROOT, ``REFLEXHOME`` should be equal
+to ``ROOTSYS``.
-.. _`Download`: http://root.cern.ch/drupal/content/downloading-root
-.. _`source`: http://root.cern.ch/drupal/content/installing-root-source
-.. _`recent snapshot`: http://cern.ch/wlav/reflex-2012-05-02.tar.bz2
-.. _`gccxml`: http://www.gccxml.org
+The following is optional, and is only to show how pypy-c can be build
+`from source`_, for example to get at the main development branch of cppyy.
+The `backend documentation`_ has more details on the backend-specific
+prerequisites.
-Next, get the `PyPy sources`_, optionally select the reflex-support branch,
-and build it.
-For the build to succeed, the ``$ROOTSYS`` environment variable must point to
-the location of your ROOT (or standalone Reflex) installation, or the
-``root-config`` utility must be accessible through ``PATH`` (e.g. by adding
-``$ROOTSYS/bin`` to ``PATH``).
-In case of the former, include files are expected under ``$ROOTSYS/include``
-and libraries under ``$ROOTSYS/lib``.
Then run the translation to build ``pypy-c``::
$ hg clone https://bitbucket.org/pypy/pypy
$ cd pypy
$ hg up reflex-support # optional
- $ cd pypy/goal
# This example shows python, but using pypy-c is faster and uses less memory
- $ python ../../rpython/bin/rpython.py -O jit --gcrootfinder=shadowstack targetpypystandalone.py --withmod-cppyy
+ $ python rpython/translator/goal/translate.py --opt=jit pypy/goal/targetpypystandalone --withmod-cppyy
This will build a ``pypy-c`` that includes the cppyy module, and through that,
Reflex support.
@@ -98,12 +132,12 @@
If not, you may want `to obtain a binary distribution`_ to speed up the
translation step.
-.. _`PyPy sources`: https://bitbucket.org/pypy/pypy/overview
+.. _`from source`: https://bitbucket.org/pypy/pypy/overview
.. _`to obtain a binary distribution`: http://doc.pypy.org/en/latest/getting-started.html#download-a-pre-built-pypy
-Basic example
-=============
+Basic bindings example
+======================
Now test with a trivial example whether all packages are properly installed
and functional.
@@ -127,7 +161,7 @@
code::
$ genreflex MyClass.h
- $ g++ -fPIC -rdynamic -O2 -shared -I$ROOTSYS/include MyClass_rflx.cpp -o libMyClassDict.so -L$ROOTSYS/lib -lReflex
+ $ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include MyClass_rflx.cpp -o libMyClassDict.so -L$REFLEXHOME/lib -lReflex
Now you're ready to use the bindings.
Since the bindings are designed to look pythonistic, it should be
@@ -176,7 +210,7 @@
For example::
$ genreflex MyClass.h --rootmap=libMyClassDict.rootmap --rootmap-lib=libMyClassDict.so
- $ g++ -fPIC -rdynamic -O2 -shared -I$ROOTSYS/include MyClass_rflx.cpp -o libMyClassDict.so -L$ROOTSYS/lib -lReflex
+ $ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include MyClass_rflx.cpp -o libMyClassDict.so -L$REFLEXHOME/lib -lReflex
where the first option (``--rootmap``) specifies the output file name, and the
second option (``--rootmap-lib``) the name of the reflection library where
@@ -277,7 +311,7 @@
Now the reflection info can be generated and compiled::
$ genreflex MyAdvanced.h --selection=MyAdvanced.xml
- $ g++ -fPIC -rdynamic -O2 -shared -I$ROOTSYS/include MyAdvanced_rflx.cpp -o libAdvExDict.so -L$ROOTSYS/lib -lReflex
+ $ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include MyAdvanced_rflx.cpp -o libAdvExDict.so -L$REFLEXHOME/lib -lReflex
and subsequently be used from PyPy::
@@ -336,7 +370,7 @@
bound using::
$ genreflex example.h --deep --rootmap=libexampleDict.rootmap --rootmap-lib=libexampleDict.so
- $ g++ -fPIC -rdynamic -O2 -shared -I$ROOTSYS/include example_rflx.cpp -o libexampleDict.so -L$ROOTSYS/lib -lReflex
+ $ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include example_rflx.cpp -o libexampleDict.so -L$REFLEXHOME/lib -lReflex
.. _`example code`: cppyy_example.html
@@ -595,6 +629,16 @@
All template classes must already exist in the loaded reflection info, they
do not work (yet) with the class loader.
+ For compatibility with other bindings generators, use of square brackets
+ instead of parenthesis to instantiate templates is supported as well.
+
+* **templated functions**: Automatically participate in overloading and are
+ used in the same way as other global functions.
+
+* **templated methods**: For now, require an explicit selection of the
+ template parameters.
+ This will be changed to allow them to participate in overloads as expected.
+
* **typedefs**: Are simple python references to the actual classes to which
they refer.
@@ -692,7 +736,7 @@
Run the normal ``genreflex`` and compilation steps::
$ genreflex MyTemplate.h --selection=MyTemplate.xml
- $ g++ -fPIC -rdynamic -O2 -shared -I$ROOTSYS/include MyTemplate_rflx.cpp -o libTemplateDict.so -L$ROOTSYS/lib -lReflex
+ $ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include MyTemplate_rflx.cpp -o libTemplateDict.so -L$REFLEXHOME/lib -lReflex
Note: this is a dirty corner that clearly could do with some automation,
even if the macro already helps.
@@ -727,18 +771,18 @@
The fast lane
=============
-The following is an experimental feature of cppyy, and that makes it doubly
-experimental, so caveat emptor.
+The following is an experimental feature of cppyy.
+It mostly works, but there are some known issues (e.g. with return-by-value).
+Soon it should be the default mode, however.
+
With a slight modification of Reflex, it can provide function pointers for
C++ methods, and hence allow PyPy to call those pointers directly, rather than
calling C++ through a Reflex stub.
-This results in a rather significant speed-up.
-Mind you, the normal stub path is not exactly slow, so for now only use this
-out of curiosity or if you really need it.
-To install this patch of Reflex, locate the file genreflex-methptrgetter.patch
-in pypy/module/cppyy and apply it to the genreflex python scripts found in
-``$ROOTSYS/lib``::
+The standalone version of Reflex `provided`_ has been patched, but if you get
+Reflex from another source (most likely with a ROOT distribution), locate the
+file `genreflex-methptrgetter.patch`_ in pypy/module/cppyy and apply it to
+the genreflex python scripts found in ``$ROOTSYS/lib``::
$ cd $ROOTSYS/lib
$ patch -p2 < genreflex-methptrgetter.patch
@@ -749,8 +793,10 @@
``-Wno-pmf-conversions`` option to ``g++`` when compiling.
The rest works the same way: the fast path will be used transparently (which
also means that you can't actually find out whether it is in use, other than
-by running a micro-benchmark).
+by running a micro-benchmark or a JIT test).
+.. _`provided`: http://cern.ch/wlav/reflex-2013-04-23.tar.bz2
+.. _`genreflex-methptrgetter.patch`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/genreflex-methptrgetter.patch
CPython
=======
diff --git a/pypy/doc/cppyy_backend.rst b/pypy/doc/cppyy_backend.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/cppyy_backend.rst
@@ -0,0 +1,53 @@
+==================
+Backends for cppyy
+==================
+
+The cppyy module needs a backend to provide the C++ reflection information on
+which the Python bindings are build.
+The backend is called through a C-API, which can be found in the PyPy sources
+in: `pypy/module/cppyy/include/capi.h`_.
+There are two kinds of API calls: querying about reflection information, which
+are used during the creation of Python-side constructs, and making the actual
+calls into C++.
+The objects passed around are all opaque: cppyy does not make any assumptions
+about them, other than that the opaque handles can be copied.
+Their definition, however, appears in two places: in the C code (in capi.h),
+and on the RPython side (in `capi_types.py`_), so if they are changed, they
+need to be changed on both sides.
+
+.. _`pypy/module/cppyy/include/capi.h`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/include/capi.h
+.. _`capi_types.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/capi/capi_types.py
+
+There are two places where selections in the RPython code affect the choice
+(and use) of the backend.
+The first is in `pypy/module/cppyy/capi/__init__.py`_::
+
+ # choose C-API access method:
+ from pypy.module.cppyy.capi.loadable_capi import *
+ #from pypy.module.cppyy.capi.builtin_capi import *
+
+The default is the loadable C-API.
+Comment it and uncomment the builtin C-API line, to use the builtin version.
+
+.. _`pypy/module/cppyy/capi/__init__.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/capi/__init__.py
+
+Next, if the builtin C-API is chosen, the specific backend needs to be set as
+well (default is Reflex).
+This second choice is in `pypy/module/cppyy/capi/builtin_capi.py`_::
+
+ import reflex_capi as backend
+ #import cint_capi as backend
+
+After those choices have been made, built pypy-c as usual.
+
+.. _`pypy/module/cppyy/capi/builtin_capi.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/capi/builtin_capi.py
+
+When building pypy-c from source, keep the following in mind.
+If the loadable_capi is chosen, no further prerequisites are needed.
+However, for the build of the builtin_capi to succeed, the ``ROOTSYS``
+environment variable must point to the location of your ROOT (or standalone
+Reflex in the case of the Reflex backend) installation, or the ``root-config``
+utility must be accessible through ``$PATH`` (e.g. by adding ``$ROOTSYS/bin``
+to ``PATH``).
+In case of the former, include files are expected under ``$ROOTSYS/include``
+and libraries under ``$ROOTSYS/lib``.
diff --git a/pypy/doc/dir-reference.rst b/pypy/doc/dir-reference.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/dir-reference.rst
@@ -0,0 +1,140 @@
+PyPy directory cross-reference
+------------------------------
+
+Here is a fully referenced alphabetical two-level deep
+directory overview of PyPy:
+
+================================= ============================================
+Directory explanation/links
+================================= ============================================
+`pypy/bin/`_ command-line scripts, mainly
+ `pypy/bin/pyinteractive.py`_
+
+`pypy/config/`_ handles the numerous options for building
+ and running PyPy
+
+`pypy/doc/`_ text versions of PyPy developer
+ documentation
+
+`pypy/doc/config/`_ documentation for the numerous translation
+ options
+
+`pypy/doc/discussion/`_ drafts of ideas and documentation
+
+``doc/*/`` other specific documentation topics or tools
+
+`pypy/interpreter/`_ `bytecode interpreter`_ and related objects
+ (frames, functions, modules,...)
+
+`pypy/interpreter/pyparser/`_ interpreter-level Python source parser
+
+`pypy/interpreter/astcompiler/`_ interpreter-level bytecode compiler,
+ via an AST representation
+
+`pypy/module/`_ contains `mixed modules`_
+ implementing core modules with
+ both application and interpreter level code.
+ Not all are finished and working. Use
+ the ``--withmod-xxx``
+ or ``--allworkingmodules`` translation
+ options.
+
+`pypy/objspace/`_ `object space`_ implementations
+
+`pypy/objspace/std/`_ the StdObjSpace_ implementing CPython's
+ objects and types
+
+`pypy/tool/`_ various utilities and hacks used
+ from various places
+
+`pypy/tool/algo/`_ general-purpose algorithmic and mathematic
+ tools
+
+`pypy/tool/pytest/`_ support code for our `testing methods`_
+
+
+`rpython/annotator/`_ `type inferencing code`_ for
+ `RPython`_ programs
+
+`rpython/config/`_ handles the numerous options for RPython
+
+
+`rpython/flowspace/`_ the FlowObjSpace_ implementing
+ `abstract interpretation`_
+
+`rpython/rlib/`_ a `"standard library"`_ for RPython_
+ programs
+
+`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
+ 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`_)
+
+``_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
+.. _`basil`: http://people.cs.uchicago.edu/~jriehl/BasilTalk.pdf
+.. _`object space`: objspace.html
+.. _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
+.. _`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
+.. _`testing methods`: coding-guide.html#testing-in-pypy
+.. _`translation`: translation.html
+.. _`GenC backend`: translation.html#genc
+.. _`CLI backend`: cli-backend.html
+.. _`py.py`: getting-started-python.html#the-py.py-interpreter
+.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
+.. _JIT: jit/index.html
+.. _`JIT Generation in PyPy`: jit/index.html
+.. _`just-in-time compiler generator`: jit/index.html
+.. _rtyper: rtyper.html
+.. _`low-level type system`: rtyper.html#low-level-type
+.. _`object-oriented type system`: rtyper.html#oo-type
+.. _`garbage collector`: garbage_collection.html
+.. _`main PyPy-translation scripts`: getting-started-python.html#translating-the-pypy-python-interpreter
+.. _`.NET`: http://www.microsoft.com/net/
+.. _Mono: http://www.mono-project.com/
+.. _`"standard library"`: rlib.html
+.. _`graph viewer`: getting-started-dev.html#try-out-the-translator
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
@@ -1,13 +1,58 @@
-===============================================================================
-Getting Started with the Translation Toolchain and Development Process
-===============================================================================
+============================
+Getting Started with RPython
+============================
.. contents::
+RPython is a subset of Python that can be statically compiled. The PyPy
+interpreter is written mostly in RPython (with pieces in Python), while
+the RPython compiler is written in Python. The hard to understand part
+is that Python is a meta-programming language for RPython, that is,
+RPython is considered from live objects **after** the imports are done.
+This might require more explanation. You start writing RPython from
+``entry_point``, a good starting point is
+``rpython/translator/goal/targetnopstandalone.py``. This does not do all that
+much, but is a start. Now if code analyzed (in this case ``entry_point``)
+calls some functions, those calls will be followed. Those followed calls
+have to be RPython themselves (and everything they call etc.), however not
+entire module files. To show how you can use metaprogramming, we can do
+a silly example (note that closures are not RPython)::
+
+ def generator(operation):
+ if operation == 'add':
+ def f(a, b):
+ return a + b
+ else:
+ def f(a, b):
+ return a - b
+ return f
+
+ add = generator('add')
+ sub = generator('sub')
+
+ def entry_point(argv):
+ print add(sub(int(argv[1]), 3) 4)
+ return 0
+
+In this example ``entry_point`` is RPython, ``add`` and ``sub`` are RPython,
+however, ``generator`` is not.
+
+A good introductory level articles are available:
+
+* Laurence Tratt -- `Fast Enough VMs in Fast Enough Time`_.
+
+* `How to write interpreters in RPython`_ and `part 2`_ by Andrew Brown.
+
+.. _`Fast Enough VMs in Fast Enough Time`: http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time
+
+.. _`How to write interpreters in RPython`: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
+
+.. _`part 2`: http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html
+
.. _`try out the translator`:
Trying out the translator
--------------------------
+-------------------------
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
@@ -28,7 +73,7 @@
>>> t = Translation(snippet.is_perfect_number, [int])
>>> t.view()
-
+
After that, the graph viewer pops up, that lets you interactively inspect the
flow graph. To move around, click on something that you want to inspect.
To get help about how to use it, press 'H'. To close it again, press 'Q'.
@@ -83,10 +128,10 @@
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.
+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 directly from the shell. You will find the
executable in one of the ``/tmp/usession-*`` directories::
# For CLI:
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 Python. When translated to C, 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
@@ -46,7 +46,7 @@
2. Install build-time dependencies. On a Debian box these are::
[user at debian-box ~]$ sudo apt-get install \
- gcc make python-dev libffi-dev lib-sqlite3-dev pkg-config \
+ gcc make python-dev libffi-dev libsqlite3-dev pkg-config \
libz-dev libbz2-dev libncurses-dev libexpat1-dev \
libssl-dev libgc-dev python-sphinx python-greenlet
@@ -147,6 +147,8 @@
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
diff --git a/pypy/doc/how-to-contribute.rst b/pypy/doc/how-to-contribute.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/how-to-contribute.rst
@@ -0,0 +1,78 @@
+How to contribute to PyPy
+-------------------------
+
+This page describes how to contribute to the PyPy project. The first thing
+to remember is that PyPy project is very different than most projects out there.
+It's also different from a classic compiler project, so academic courses
+about compilers often don't apply or lead in the wrong direction.
+
+Don't just hack
+---------------
+
+The first and most important rule how not to contribute to PyPy is
+"just hacking". This won't work. There are two major reasons why not
+-- build times are large and PyPy has very thick layer separation which
+make it harder to "just hack a feature".
+
+Test driven development
+-----------------------
+
+Instead, we practice a lot of test driven development. This is partly because
+of very high quality requirements for compilers and partly because there is
+simply no other way to get around such complex project, that will keep you sane.
+There are probably people out there who are smart enough not to need it, we're
+not one of those. You may consider familiarizing yourself with `pytest`_,
+since this is a tool we use for tests.
+This leads to the next issue:
+
+Layers
+------
+
+PyPy has layers. Those layers help us keep the respective parts separated enough
+to be worked on independently and make the complexity manageable. This is,
+again, just a sanity requirement for such a complex project. For example writing
+a new optimization for the JIT usually does **not** involve touching a Python
+interpreter at all or the JIT assembler backend or the garbage collector.
+Instead it requires writing small tests in
+``rpython/jit/metainterp/optimizeopt/test/test_*`` and fixing files there.
+After that, you can just compile PyPy and things should just work.
+
+The short list of layers for further reading. For each of those layers, a good
+entry point is a test subdirectory in respective directories. It usually
+describes (better or worse) the interfaces between the submodules. For the
+``pypy`` subdirectory, most tests are small snippets of python programs that
+check for correctness (calls ``AppTestXxx``) that will call the appropriate
+part of the interpreter. For the ``rpython`` directory, most tests are small
+RPython interpreters that perform certain tasks. To see how they translate
+to low-level graphs, run them with ``--view``. To see small interpreters
+with a JIT compiler, use ``--viewloops`` option.
+
+* **python interpreter** - it's the part implemented in the ``pypy/`` directory.
+ It's implemented in RPython, which is a high level static language with
+ classes, garbage collection, just-in-time compiler generation and the ability
+ to call C. A cool part about it is that it can be run untranslated, so all
+ the tests are runnable without translating PyPy.
+
+ **interpreter** contains the interpreter core
+
+ **objspace** contains implementations of various objects exported to
+ the Python layer
+
+ **module** directory contains extension modules written in RPython
+
+* **rpython compiler** that resides in ``rpython/annotator`` and
+ ``rpython/rtyper`` directories. Consult `introduction to RPython`_ for
+ further reading
+
+* **JIT generator** lives in ``rpython/jit`` directory. optimizations live
+ in ``rpython/jit/metainterp/optimizeopt``, the main JIT in
+ ``rpython/jit/metainterp`` (runtime part) and
+ ``rpython/jit/codewriter`` (translation-time part). Backends live in
+ ``rpython/jit/backend``.
+
+* **garbage collection** lives in ``rpython/memory``
+
+The rest of directories serve specific niche goal and are unlikely a good
+entry point.
+
+.. _`introduction to RPython`: getting-started-dev.rst
diff --git a/pypy/doc/index.rst b/pypy/doc/index.rst
--- a/pypy/doc/index.rst
+++ b/pypy/doc/index.rst
@@ -1,15 +1,40 @@
-Welcome to PyPy Development
-=============================================
+Welcome to PyPy
+===============
-The PyPy project aims at producing a flexible and fast Python_
-implementation. The guiding idea is to translate a Python-level
-description of the Python language itself to lower level languages.
-Rumors have it that the secret goal is being faster-than-C which is
-nonsense, isn't it? `more...`_
+The PyPy project aims to produce a flexible and fast Python_
+implementation. This page documents the development of the PyPy
+project itself. If you don't know what PyPy is, consult the `PyPy
+website`_. If you just want to use PyPy, consult the `download`_ page
+and the `getting started with pypy`_ documents. If you want to help
+develop PyPy -- keep reading!
-Getting into PyPy ...
-=============================================
+PyPy is written in a language called `RPython`_, which is suitable for
+writing dynamic language interpreters (and not much else). RPython is
+a subset of Python and is itself written in Python. If you'd like to
+learn more about RPython, `Starting with RPython`_ should provide a
+reasonable overview.
+
+**If you would like to contribute to PyPy**, please read `how to
+contribute`_ first. PyPy's development style is somewhat different to
+that of many other software projects and it often surprises
+newcomers. What is **not** necessary is an academic background from
+university in writing compilers -- much of it does not apply to PyPy
+any way.
+
+All of the documentation and source code is available under the MIT license,
+unless otherwise specified. Consult `LICENSE`_
+
+.. _`download`: http://pypy.org/download.html
+.. _`getting started with pypy`: getting-started-python.html
+.. _`RPython`: coding-guide.html#RPython
+.. _`Starting with RPython`: getting-started-dev.html
+.. _`how to contribute`: how-to-contribute.html
+.. _`PyPy website`: http://pypy.org
+.. _`LICENSE`: https://bitbucket.org/pypy/pypy/src/default/LICENSE
+
+Index of various topics:
+========================
* `Getting started`_: how to install and run the PyPy Python interpreter
@@ -25,20 +50,30 @@
* `potential project ideas`_: In case you want to get your feet wet...
+* `more stuff`_: this is a collection of documentation that's there, but not
+ particularly organized
+
Documentation for the PyPy Python Interpreter
-===============================================
+=============================================
New features of PyPy's Python Interpreter and
Translation Framework:
* `Differences between PyPy and CPython`_
- * `What PyPy can do for your objects`_
- * `Continulets and greenlets`_
+ * `What PyPy can do for your objects`_ - transparent proxy documentation
+ * `Continulets and greenlets`_ - documentation about stackless features
* `JIT Generation in PyPy`_
+ * `JIT hooks`_
* `Sandboxing Python code`_
+ * `Garbage collection environment variables`_
-Status_ of the project.
-
+.. _`Differences between PyPy and CPython`: cpython_differences.html
+.. _`What PyPy can do for your objects`: objspace-proxies.html
+.. _`Continulets and greenlets`: stackless.html
+.. _`JIT Generation in PyPy`: jit/index.html
+.. _`JIT hooks`: jit-hooks.html
+.. _`Sandboxing Python code`: sandbox.html
+.. _`Garbage collection environment variables`: gc_info.html
Mailing lists, bug tracker, IRC channel
=============================================
@@ -79,354 +114,6 @@
.. _`speed.pypy.org`: http://speed.pypy.org
.. _`RPython toolchain`: translation.html
.. _`potential project ideas`: project-ideas.html
-
-Project Documentation
-=====================================
-
-PyPy was funded by the EU for several years. See the `web site of the EU
-project`_ for more details.
-
-.. _`web site of the EU project`: http://pypy.org
-
-architecture_ gives a complete view of PyPy's basic design.
-
-`coding guide`_ helps you to write code for PyPy (especially also describes
-coding in RPython a bit).
-
-`sprint reports`_ lists reports written at most of our sprints, from
-2003 to the present.
-
-`papers, talks and related projects`_ lists presentations
-and related projects as well as our published papers.
-
-`PyPy video documentation`_ is a page linking to the videos (e.g. of talks and
-introductions) that are available.
-
-`Technical reports`_ is a page that contains links to the
-reports that we submitted to the European Union.
-
-`development methodology`_ describes our sprint-driven approach.
-
-`LICENSE`_ contains licensing details (basically a straight MIT-license).
-
-`Glossary`_ of PyPy words to help you align your inner self with
-the PyPy universe.
-
-
-Status
-===================================
-
-PyPy can be used to run Python programs on Linux, OS/X,
-Windows, on top of .NET, and on top of Java.
-To dig into PyPy it is recommended to try out the current
-Mercurial default branch, which is always working or mostly working,
-instead of the latest release, which is `2.0 beta1`__.
-
-.. __: release-2.0.0-beta1.html
-
-PyPy is mainly developed on Linux and Mac OS X. Windows is supported,
-but platform-specific bugs tend to take longer before we notice and fix
-them. Linux 64-bit machines are supported (though it may also take some
-time before we notice and fix bugs).
-
-PyPy's own tests `summary`_, daily updated, run through BuildBot infrastructure.
-You can also find CPython's compliance tests run with compiled ``pypy-c``
-executables there.
-
-
-Source Code Documentation
-===============================================
-
-`object spaces`_ discusses the object space interface
-and several implementations.
-
-`bytecode interpreter`_ explains the basic mechanisms
-of the bytecode interpreter and virtual machine.
-
-`interpreter optimizations`_ describes our various strategies for
-improving the performance of our interpreter, including alternative
-object implementations (for strings, dictionaries and lists) in the
-standard object space.
-
-`translation`_ is a detailed overview of our translation process. The
-rtyper_ is the largest component of our translation process.
-
-`dynamic-language translation`_ is a paper that describes
-the translation process, especially the flow object space
-and the annotator in detail. (This document is one
-of the `EU reports`_.)
-
-`low-level encapsulation`_ describes how our approach hides
-away a lot of low level details. This document is also part
-of the `EU reports`_.
-
-`translation aspects`_ describes how we weave different
-properties into our interpreter during the translation
-process. This document is also part of the `EU reports`_.
-
-`garbage collector`_ strategies that can be used by the virtual
-machines produced by the translation process.
-
-`parser`_ contains (outdated, unfinished) documentation about
-the parser.
-
-`rlib`_ describes some modules that can be used when implementing programs in
-RPython.
-
-`configuration documentation`_ describes the various configuration options that
-allow you to customize PyPy.
-
-`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.
-
-
-
-.. _`FAQ`: faq.html
-.. _Glossary: glossary.html
-.. _`PyPy video documentation`: video-index.html
-.. _parser: parser.html
-.. _`development methodology`: dev_method.html
-.. _`sprint reports`: sprint-reports.html
-.. _`papers, talks and related projects`: extradoc.html
-.. _`object spaces`: objspace.html
-.. _`interpreter optimizations`: interpreter-optimizations.html
-.. _`translation`: translation.html
-.. _`dynamic-language translation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
-.. _`low-level encapsulation`: low-level-encapsulation.html
-.. _`translation aspects`: translation-aspects.html
-.. _`configuration documentation`: config/
-.. _`coding guide`: coding-guide.html
-.. _`architecture`: architecture.html
-.. _`getting started`: getting-started.html
-.. _`bytecode interpreter`: interpreter.html
-.. _`EU reports`: index-report.html
-.. _`Technical reports`: index-report.html
-.. _`summary`: http://buildbot.pypy.org/summary
-.. _`ideas for PyPy related projects`: project-ideas.html
-.. _`Nightly builds and benchmarks`: http://tuatara.cs.uni-duesseldorf.de/benchmark.html
-.. _`directory reference`:
-.. _`rlib`: rlib.html
-.. _`Sandboxing Python code`: sandbox.html
-.. _`LICENSE`: https://bitbucket.org/pypy/pypy/src/default/LICENSE
-
-PyPy directory cross-reference
-------------------------------
-
-Here is a fully referenced alphabetical two-level deep
-directory overview of PyPy:
-
-================================= ============================================
-Directory explanation/links
-================================= ============================================
-`pypy/bin/`_ command-line scripts, mainly
- `pypy/bin/pyinteractive.py`_
-
-`pypy/config/`_ handles the numerous options for building
- and running PyPy
-
-`pypy/doc/`_ text versions of PyPy developer
- documentation
-
-`pypy/doc/config/`_ documentation for the numerous translation
- options
-
-`pypy/doc/discussion/`_ drafts of ideas and documentation
-
-``doc/*/`` other specific documentation topics or tools
-
-`pypy/interpreter/`_ `bytecode interpreter`_ and related objects
- (frames, functions, modules,...)
-
-`pypy/interpreter/pyparser/`_ interpreter-level Python source parser
-
-`pypy/interpreter/astcompiler/`_ interpreter-level bytecode compiler,
- via an AST representation
-
-`pypy/module/`_ contains `mixed modules`_
- implementing core modules with
- both application and interpreter level code.
- Not all are finished and working. Use
- the ``--withmod-xxx``
- or ``--allworkingmodules`` translation
- options.
-
-`pypy/objspace/`_ `object space`_ implementations
-
-`pypy/objspace/std/`_ the StdObjSpace_ implementing CPython's
- objects and types
-
-`pypy/tool/`_ various utilities and hacks used
- from various places
-
-`pypy/tool/algo/`_ general-purpose algorithmic and mathematic
- tools
-
-`pypy/tool/pytest/`_ support code for our `testing methods`_
-
-
-`rpython/annotator/`_ `type inferencing code`_ for
- `RPython`_ programs
-
-`rpython/config/`_ handles the numerous options for RPython
-
-
-`rpython/flowspace/`_ the FlowObjSpace_ implementing
- `abstract interpretation`_
-
-`rpython/rlib/`_ a `"standard library"`_ for RPython_
- programs
-
-`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
- 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`_)
-
-``_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
-.. _`basil`: http://people.cs.uchicago.edu/~jriehl/BasilTalk.pdf
-.. _`object space`: objspace.html
-.. _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
-.. _`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
-.. _`testing methods`: coding-guide.html#testing-in-pypy
-.. _`translation`: translation.html
-.. _`GenC backend`: translation.html#genc
-.. _`CLI backend`: cli-backend.html
-.. _`py.py`: getting-started-python.html#the-py.py-interpreter
-.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
-.. _JIT: jit/index.html
-.. _`JIT Generation in PyPy`: jit/index.html
-.. _`just-in-time compiler generator`: jit/index.html
-.. _rtyper: rtyper.html
-.. _`low-level type system`: rtyper.html#low-level-type
-.. _`object-oriented type system`: rtyper.html#oo-type
-.. _`garbage collector`: garbage_collection.html
-.. _`main PyPy-translation scripts`: getting-started-python.html#translating-the-pypy-python-interpreter
-.. _`.NET`: http://www.microsoft.com/net/
-.. _Mono: http://www.mono-project.com/
-.. _`"standard library"`: rlib.html
-.. _`graph viewer`: getting-started-dev.html#try-out-the-translator
-
-
-.. The following documentation is important and reasonably up-to-date:
-
-.. extradoc: should this be integrated one level up: dcolish?
-
-
-.. toctree::
- :maxdepth: 1
- :hidden:
-
- getting-started.rst
- getting-started-python.rst
- getting-started-dev.rst
- windows.rst
- faq.rst
- commandline_ref.rst
- architecture.rst
- coding-guide.rst
- cpython_differences.rst
- garbage_collection.rst
- gc_info.rst
- interpreter.rst
- objspace.rst
- __pypy__-module.rst
- objspace-proxies.rst
- config/index.rst
-
- dev_method.rst
- extending.rst
-
- extradoc.rst
- video-index.rst
-
- glossary.rst
-
- contributor.rst
-
- interpreter-optimizations.rst
- configuration.rst
- parser.rst
- rlib.rst
- rtyper.rst
- rffi.rst
-
- translation.rst
- jit/index.rst
- jit/overview.rst
- jit/pyjitpl5.rst
-
- index-of-release-notes.rst
-
- ctypes-implementation.rst
-
- how-to-release.rst
-
- index-report.rst
-
- stackless.rst
- sandbox.rst
-
- discussions.rst
-
- cleanup.rst
-
- sprint-reports.rst
-
- eventhistory.rst
- statistic/index.rst
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`search`
-* :ref:`glossary`
-
+.. _`more stuff`: project-documentation.html
.. include:: _ref.txt
diff --git a/pypy/doc/needswork.txt b/pypy/doc/needswork.txt
deleted file mode 100644
--- a/pypy/doc/needswork.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-.. warning::
-
- This documentation needs work (as discussed during the Gothenburg sprint in 2011)
diff --git a/pypy/doc/objspace-proxies.rst b/pypy/doc/objspace-proxies.rst
--- a/pypy/doc/objspace-proxies.rst
+++ b/pypy/doc/objspace-proxies.rst
@@ -5,7 +5,6 @@
.. contents::
-
Thanks to the `Object Space`_ architecture, any feature that is
based on proxying, extending, changing or otherwise controlling the
behavior of all objects in a running program is easy to implement on
diff --git a/pypy/doc/project-documentation.rst b/pypy/doc/project-documentation.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/project-documentation.rst
@@ -0,0 +1,177 @@
+
+Project Documentation
+=====================================
+
+`architecture`_ gives a complete view of PyPy's basic design.
+
+`coding guide`_ helps you to write code for PyPy (especially also describes
+coding in RPython a bit).
+
+`sprint reports`_ lists reports written at most of our sprints, from
+2003 to the present.
+
+`papers, talks and related projects`_ lists presentations
+and related projects as well as our published papers.
+
+`PyPy video documentation`_ is a page linking to the videos (e.g. of talks and
+introductions) that are available.
+
+`Technical reports`_ is a page that contains links to the
+reports that we submitted to the European Union.
+
+`development methodology`_ describes our sprint-driven approach.
+
+`LICENSE`_ contains licensing details (basically a straight MIT-license).
+
+`Glossary`_ of PyPy words to help you align your inner self with
+the PyPy universe.
+
+Source Code Documentation
+===============================================
+
+`object spaces`_ discusses the object space interface
+and several implementations.
+
+`bytecode interpreter`_ explains the basic mechanisms
+of the bytecode interpreter and virtual machine.
+
+`interpreter optimizations`_ describes our various strategies for
+improving the performance of our interpreter, including alternative
+object implementations (for strings, dictionaries and lists) in the
+standard object space.
+
+`translation`_ is a detailed overview of our translation process. The
+rtyper_ is the largest component of our translation process.
+
+`dynamic-language translation`_ is a paper that describes
+the translation process, especially the flow object space
+and the annotator in detail. (This document is one
+of the `EU reports`_.)
+
+`low-level encapsulation`_ describes how our approach hides
+away a lot of low level details. This document is also part
+of the `EU reports`_.
+
+`translation aspects`_ describes how we weave different
+properties into our interpreter during the translation
+process. This document is also part of the `EU reports`_.
+
+`garbage collector`_ strategies that can be used by the virtual
+machines produced by the translation process.
+
+`parser`_ contains (outdated, unfinished) documentation about
+the parser.
+
+`rlib`_ describes some modules that can be used when implementing programs in
+RPython.
+
+`configuration documentation`_ describes the various configuration options that
+allow you to customize PyPy.
+
+`pypy on windows`_
+
+`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.
+
+`directory cross-reference`_
+
+.. _`garbage collector`: garbage_collection.html
+.. _`directory cross-reference`: dir-reference.html
+.. _`pypy on windows`: windows.html
+.. _`command line reference`: commandline_ref.html
+.. _`FAQ`: faq.html
+.. _Glossary: glossary.html
+.. _`PyPy video documentation`: video-index.html
+.. _parser: parser.html
+.. _`development methodology`: dev_method.html
+.. _`sprint reports`: sprint-reports.html
+.. _`papers, talks and related projects`: extradoc.html
+.. _`object spaces`: objspace.html
+.. _`interpreter optimizations`: interpreter-optimizations.html
+.. _`translation`: translation.html
+.. _`dynamic-language translation`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`low-level encapsulation`: low-level-encapsulation.html
+.. _`translation aspects`: translation-aspects.html
+.. _`configuration documentation`: config/
+.. _`coding guide`: coding-guide.html
+.. _`Architecture`: architecture.html
+.. _`getting started`: getting-started.html
+.. _`bytecode interpreter`: interpreter.html
+.. _`EU reports`: index-report.html
+.. _`Technical reports`: index-report.html
+.. _`summary`: http://buildbot.pypy.org/summary
+.. _`ideas for PyPy related projects`: project-ideas.html
+.. _`Nightly builds and benchmarks`: http://tuatara.cs.uni-duesseldorf.de/benchmark.html
+.. _`directory reference`:
+.. _`rlib`: rlib.html
+.. _`Sandboxing Python code`: sandbox.html
+.. _`LICENSE`: https://bitbucket.org/pypy/pypy/src/default/LICENSE
+
+.. The following documentation is important and reasonably up-to-date:
+
+.. extradoc: should this be integrated one level up: dcolish?
+
+.. toctree::
+ :maxdepth: 1
+ :hidden:
+
+ interpreter.rst
+ objspace.rst
+ __pypy__-module.rst
+ objspace-proxies.rst
+ config/index.rst
+
+ dev_method.rst
+ extending.rst
+
+ extradoc.rst
+ video-index.rst
+
+ glossary.rst
+
+ contributor.rst
+
+ interpreter-optimizations.rst
+ configuration.rst
+ parser.rst
+ rlib.rst
+ rtyper.rst
+ rffi.rst
+
+ translation.rst
+ jit/index.rst
+ jit/overview.rst
+ jit/pyjitpl5.rst
+
+ index-of-release-notes.rst
+
+ ctypes-implementation.rst
+
+ how-to-release.rst
+
+ index-report.rst
+
+ stackless.rst
+ sandbox.rst
+
+ discussions.rst
+
+ cleanup.rst
+
+ sprint-reports.rst
+
+ eventhistory.rst
+ statistic/index.rst
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`search`
+* :ref:`glossary`
+
+.. include:: _ref.txt
diff --git a/pypy/doc/release-2.0.0-beta2.rst b/pypy/doc/release-2.0.0-beta2.rst
--- a/pypy/doc/release-2.0.0-beta2.rst
+++ b/pypy/doc/release-2.0.0-beta2.rst
@@ -82,3 +82,13 @@
* we now have special strategies for ``dict``/``set``/``list`` which contain
unicode strings, which means that now such collections will be both faster
and more compact.
+
+.. _`eventlet`: http://eventlet.net/
+.. _`gevent`: http://www.gevent.org/
+.. _`cffi`: http://cffi.readthedocs.org/en/release-0.6/
+.. _`JIT hooks`: http://doc.pypy.org/en/latest/jit-hooks.html
+.. _`pypycore`: https://github.com/gevent-on-pypy/pypycore
+.. _`pypy-hacks`: https://github.com/schmir/gevent/tree/pypy-hacks
+.. _`_curses.py`: https://bitbucket.org/pypy/pypy/src/aefddd47f224e3c12e2ea74f5c796d76f4355bdb/lib_pypy/_curses.py?at=default
+.. _`_sqlite3.py`: https://bitbucket.org/pypy/pypy/src/aefddd47f224e3c12e2ea74f5c796d76f4355bdb/lib_pypy/_sqlite3.py?at=default
+
diff --git a/pypy/doc/stackless.rst b/pypy/doc/stackless.rst
--- a/pypy/doc/stackless.rst
+++ b/pypy/doc/stackless.rst
@@ -17,8 +17,8 @@
Continulets can be directly used by application code, or it is possible
to write (entirely at app-level) more user-friendly interfaces.
-Currently PyPy implements greenlets_ on top of continulets. It would be
-easy to implement tasklets and channels as well, emulating the model
+Currently PyPy implements greenlets_ on top of continulets. It also
+implements (an approximation of) tasklets and channels, emulating the model
of `Stackless Python`_.
Continulets are extremely light-weight, which means that PyPy should be
diff --git a/pypy/doc/whatsnew-head.rst b/pypy/doc/whatsnew-head.rst
--- a/pypy/doc/whatsnew-head.rst
+++ b/pypy/doc/whatsnew-head.rst
@@ -43,12 +43,26 @@
Rudimentary support for bytearray in RPython
.. branch: refactor-call_release_gil
-Fix a bug which casused cffi to return the wrong result when calling a C
+Fix a bug which caused cffi to return the wrong result when calling a C
function which calls a Python callback which forces the frames
+.. branch: virtual-raw-mallocs
+JIT optimizations which make cffi calls even faster, by removing the need to
+allocate a temporary buffer where to store the arguments.
+
+.. branch: improve-docs-2
+Improve documents and straighten out links
+
+.. branch: fast-newarray
+Inline the fast path of newarray in the assembler.
+Disabled on ARM until we fix issues.
+
+.. branch: reflex-support
+Allow dynamic loading of a (Reflex) backend that implements the C-API needed
+to provide reflection information
+
.. branches we don't care about
.. branch: autoreds
-.. branch: reflex-support
.. branch: kill-faking
.. branch: improved_ebnfparse_error
.. branch: task-decorator
@@ -121,3 +135,6 @@
cffi implementation of sqlite3
.. branch: release-2.0-beta2
+.. branch: unbreak-freebsd
+
+.. branch: virtualref-virtualizable
diff --git a/pypy/goal/getnightly.py b/pypy/goal/getnightly.py
--- a/pypy/goal/getnightly.py
+++ b/pypy/goal/getnightly.py
@@ -13,8 +13,13 @@
if sys.maxint == 2**63 - 1:
arch += '64'
+hg = py.path.local.sysfind('hg')
+branch = hg.sysexec('branch').strip()
+if branch == 'default':
+ branch = 'trunk'
+
filename = 'pypy-c-jit-latest-%s.tar.bz2' % arch
-url = 'http://buildbot.pypy.org/nightly/trunk/%s' % filename
+url = 'http://buildbot.pypy.org/nightly/%s/%s' % (branch, filename)
tmp = py.path.local.mkdtemp()
mydir = tmp.chdir()
print 'Downloading pypy to', tmp
diff --git a/pypy/interpreter/astcompiler/consts.py b/pypy/interpreter/astcompiler/consts.py
--- a/pypy/interpreter/astcompiler/consts.py
+++ b/pypy/interpreter/astcompiler/consts.py
@@ -15,8 +15,6 @@
CO_FUTURE_WITH_STATEMENT = 0x8000
CO_FUTURE_PRINT_FUNCTION = 0x10000
CO_FUTURE_UNICODE_LITERALS = 0x20000
-CO_CONTAINSGLOBALS = 0x80000 # pypy-specific: need to check that it's not used
- # by any other flag
PyCF_SOURCE_IS_UTF8 = 0x0100
PyCF_DONT_IMPLY_DEDENT = 0x0200
diff --git a/pypy/interpreter/baseobjspace.py b/pypy/interpreter/baseobjspace.py
--- a/pypy/interpreter/baseobjspace.py
+++ b/pypy/interpreter/baseobjspace.py
@@ -709,6 +709,8 @@
def new_interned_w_str(self, w_s):
s = self.str_w(w_s)
+ if not we_are_translated():
+ assert type(s) is str
try:
return self.interned_strings[s]
except KeyError:
@@ -717,6 +719,8 @@
return w_s
def new_interned_str(self, s):
+ if not we_are_translated():
+ assert type(s) is str
try:
return self.interned_strings[s]
except KeyError:
diff --git a/pypy/interpreter/pycode.py b/pypy/interpreter/pycode.py
--- a/pypy/interpreter/pycode.py
+++ b/pypy/interpreter/pycode.py
@@ -12,7 +12,7 @@
from pypy.interpreter.gateway import unwrap_spec
from pypy.interpreter.astcompiler.consts import (
CO_OPTIMIZED, CO_NEWLOCALS, CO_VARARGS, CO_VARKEYWORDS, CO_NESTED,
- CO_GENERATOR, CO_CONTAINSGLOBALS)
+ CO_GENERATOR)
from pypy.tool.stdlib_opcode import opcodedesc, HAVE_ARGUMENT
from rpython.rlib.rarithmetic import intmask
from rpython.rlib.objectmodel import compute_hash
@@ -88,8 +88,6 @@
self._initialize()
def _initialize(self):
- self._init_flags()
-
if self.co_cellvars:
argcount = self.co_argcount
assert argcount >= 0 # annotator hint
@@ -134,22 +132,6 @@
'__pypy__' not in sys.builtin_module_names):
raise Exception("CPython host codes should not be rendered")
- def _init_flags(self):
- co_code = self.co_code
- next_instr = 0
- while next_instr < len(co_code):
- opcode = ord(co_code[next_instr])
- next_instr += 1
- if opcode >= HAVE_ARGUMENT:
- next_instr += 2
- while opcode == opcodedesc.EXTENDED_ARG.index:
- opcode = ord(co_code[next_instr])
- next_instr += 3
- if opcode == opcodedesc.LOAD_GLOBAL.index:
- self.co_flags |= CO_CONTAINSGLOBALS
- elif opcode == opcodedesc.LOAD_NAME.index:
- self.co_flags |= CO_CONTAINSGLOBALS
-
co_names = property(lambda self: [self.space.unwrap(w_name) for w_name in self.co_names_w]) # for trace
def signature(self):
diff --git a/pypy/interpreter/pyopcode.py b/pypy/interpreter/pyopcode.py
--- a/pypy/interpreter/pyopcode.py
+++ b/pypy/interpreter/pyopcode.py
@@ -255,19 +255,7 @@
"code=%d, name=%s" %
(self.last_instr, opcode,
methodname))
- try:
- res = meth(oparg, next_instr)
- except Exception:
- if 0:
- import dis, sys
- print "*** %s at offset %d (%s)" % (sys.exc_info()[0],
- self.last_instr,
- methodname)
More information about the pypy-commit
mailing list