[pypy-commit] pypy refactor-buffer-api: merge default
bdkearns
noreply at buildbot.pypy.org
Tue Apr 22 20:34:14 CEST 2014
Author: Brian Kearns <bdkearns at gmail.com>
Branch: refactor-buffer-api
Changeset: r70866:586ce9aec76d
Date: 2014-04-22 14:11 -0400
http://bitbucket.org/pypy/pypy/changeset/586ce9aec76d/
Log: merge default
diff too long, truncating to 2000 out of 15033 lines
diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -64,6 +64,7 @@
^pypy/goal/pypy-jvm.jar
^pypy/goal/.+\.exe$
^pypy/goal/.+\.dll$
+^pypy/goal/.+\.lib$
^pypy/_cache$
^pypy/doc/statistic/.+\.html$
^pypy/doc/statistic/.+\.eps$
diff --git a/lib-python/2.7/ctypes/util.py b/lib-python/2.7/ctypes/util.py
--- a/lib-python/2.7/ctypes/util.py
+++ b/lib-python/2.7/ctypes/util.py
@@ -86,9 +86,10 @@
elif os.name == "posix":
# Andreas Degert's find functions, using gcc, /sbin/ldconfig, objdump
- import re, tempfile, errno
+ import re, errno
def _findLib_gcc(name):
+ import tempfile
expr = r'[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
fdout, ccout = tempfile.mkstemp()
os.close(fdout)
diff --git a/lib-python/2.7/test/test_argparse.py b/lib-python/2.7/test/test_argparse.py
--- a/lib-python/2.7/test/test_argparse.py
+++ b/lib-python/2.7/test/test_argparse.py
@@ -10,6 +10,7 @@
import tempfile
import unittest
import argparse
+import gc
from StringIO import StringIO
@@ -47,6 +48,9 @@
def tearDown(self):
os.chdir(self.old_dir)
+ for root, dirs, files in os.walk(self.temp_dir, topdown=False):
+ for name in files:
+ os.chmod(os.path.join(self.temp_dir, name), stat.S_IWRITE)
shutil.rmtree(self.temp_dir, True)
def create_readonly_file(self, filename):
diff --git a/lib-python/2.7/test/test_file.py b/lib-python/2.7/test/test_file.py
--- a/lib-python/2.7/test/test_file.py
+++ b/lib-python/2.7/test/test_file.py
@@ -301,6 +301,7 @@
self.fail("readlines() after next() with empty buffer "
"failed. Got %r, expected %r" % (line, testline))
# Reading after iteration hit EOF shouldn't hurt either
+ f.close()
f = self.open(TESTFN, 'rb')
try:
for line in f:
diff --git a/lib-python/2.7/test/test_file2k.py b/lib-python/2.7/test/test_file2k.py
--- a/lib-python/2.7/test/test_file2k.py
+++ b/lib-python/2.7/test/test_file2k.py
@@ -162,6 +162,7 @@
# Remark: Do not perform more than one test per open file,
# since that does NOT catch the readline error on Windows.
data = 'xxx'
+ self.f.close()
for mode in ['w', 'wb', 'a', 'ab']:
for attr in ['read', 'readline', 'readlines']:
self.f = open(TESTFN, mode)
diff --git a/lib-python/2.7/test/test_genericpath.py b/lib-python/2.7/test/test_genericpath.py
--- a/lib-python/2.7/test/test_genericpath.py
+++ b/lib-python/2.7/test/test_genericpath.py
@@ -231,9 +231,14 @@
unicwd = u'\xe7w\xf0'
try:
fsencoding = test_support.TESTFN_ENCODING or "ascii"
- unicwd.encode(fsencoding)
+ asciival = unicwd.encode(fsencoding)
+ if fsencoding == "mbcs":
+ # http://bugs.python.org/issue850997
+ v = asciival.find('?')
+ if v >= 0:
+ raise UnicodeEncodeError(fsencoding, unicwd, v, v, asciival)
except (AttributeError, UnicodeEncodeError):
- # FS encoding is probably ASCII
+ # FS encoding is probably ASCII or windows and codepage is non-Latin1
pass
else:
with test_support.temp_cwd(unicwd):
diff --git a/lib-python/2.7/test/test_httpservers.py b/lib-python/2.7/test/test_httpservers.py
--- a/lib-python/2.7/test/test_httpservers.py
+++ b/lib-python/2.7/test/test_httpservers.py
@@ -335,6 +335,7 @@
response = self.request(self.tempdir_name + '/')
self.check_status_and_reason(response, 404)
os.chmod(self.tempdir, 0755)
+ f.close()
def test_head(self):
response = self.request(
diff --git a/lib_pypy/_ctypes_test.py b/lib_pypy/_ctypes_test.py
--- a/lib_pypy/_ctypes_test.py
+++ b/lib_pypy/_ctypes_test.py
@@ -1,3 +1,5 @@
+import imp, os
+
try:
import cpyext
except ImportError:
@@ -10,4 +12,12 @@
pass # obscure condition of _ctypes_test.py being imported by py.test
else:
import _pypy_testcapi
- _pypy_testcapi.compile_shared('_ctypes_test.c', '_ctypes_test')
+ cfile = '_ctypes_test.c'
+ thisdir = os.path.dirname(__file__)
+ output_dir = _pypy_testcapi.get_hashed_dir(os.path.join(thisdir, cfile))
+ try:
+ fp, filename, description = imp.find_module('_ctypes_test', path=[output_dir])
+ imp.load_module('_ctypes_test', fp, filename, description)
+ except ImportError:
+ print('could not find _ctypes_test in %s' % output_dir)
+ _pypy_testcapi.compile_shared('_ctypes_test.c', '_ctypes_test', output_dir)
diff --git a/lib_pypy/_pypy_testcapi.py b/lib_pypy/_pypy_testcapi.py
--- a/lib_pypy/_pypy_testcapi.py
+++ b/lib_pypy/_pypy_testcapi.py
@@ -1,5 +1,23 @@
import os, sys, imp
-import tempfile
+import tempfile, binascii
+
+
+def get_hashed_dir(cfile):
+ with open(cfile,'r') as fid:
+ content = fid.read()
+ # from cffi's Verifier()
+ key = '\x00'.join([sys.version[:3], content])
+ if sys.version_info >= (3,):
+ key = key.encode('utf-8')
+ k1 = hex(binascii.crc32(key[0::2]) & 0xffffffff)
+ k1 = k1.lstrip('0x').rstrip('L')
+ k2 = hex(binascii.crc32(key[1::2]) & 0xffffffff)
+ k2 = k2.lstrip('0').rstrip('L')
+ output_dir = tempfile.gettempdir() + os.path.sep + 'tmp_%s%s' %(k1, k2)
+ if not os.path.exists(output_dir):
+ os.mkdir(output_dir)
+ return output_dir
+
def _get_c_extension_suffix():
for ext, mod, typ in imp.get_suffixes():
@@ -7,12 +25,13 @@
return ext
-def compile_shared(csource, modulename):
+def compile_shared(csource, modulename, output_dir=None):
"""Compile '_testcapi.c' or '_ctypes_test.c' into an extension module,
and import it.
"""
thisdir = os.path.dirname(__file__)
- output_dir = tempfile.mkdtemp()
+ if output_dir is None:
+ output_dir = tempfile.mkdtemp()
from distutils.ccompiler import new_compiler
diff --git a/lib_pypy/_testcapi.py b/lib_pypy/_testcapi.py
--- a/lib_pypy/_testcapi.py
+++ b/lib_pypy/_testcapi.py
@@ -1,7 +1,17 @@
+import imp, os
+
try:
import cpyext
except ImportError:
raise ImportError("No module named '_testcapi'")
-else:
- import _pypy_testcapi
- _pypy_testcapi.compile_shared('_testcapimodule.c', '_testcapi')
+
+import _pypy_testcapi
+cfile = '_testcapimodule.c'
+thisdir = os.path.dirname(__file__)
+output_dir = _pypy_testcapi.get_hashed_dir(os.path.join(thisdir, cfile))
+
+try:
+ fp, filename, description = imp.find_module('_testcapi', path=[output_dir])
+ imp.load_module('_testcapi', fp, filename, description)
+except ImportError:
+ _pypy_testcapi.compile_shared(cfile, '_testcapi', output_dir)
diff --git a/lib_pypy/ctypes_support.py b/lib_pypy/ctypes_support.py
--- a/lib_pypy/ctypes_support.py
+++ b/lib_pypy/ctypes_support.py
@@ -1,4 +1,3 @@
-
""" This file provides some support for things like standard_c_lib and
errno access, as portable as possible
"""
@@ -22,7 +21,7 @@
standard_c_lib._errno.argtypes = None
def _where_is_errno():
return standard_c_lib._errno()
-
+
elif sys.platform in ('linux2', 'freebsd6'):
standard_c_lib.__errno_location.restype = ctypes.POINTER(ctypes.c_int)
standard_c_lib.__errno_location.argtypes = None
@@ -42,5 +41,3 @@
def set_errno(value):
errno_p = _where_is_errno()
errno_p.contents.value = value
-
-
diff --git a/pypy/config/pypyoption.py b/pypy/config/pypyoption.py
--- a/pypy/config/pypyoption.py
+++ b/pypy/config/pypyoption.py
@@ -217,7 +217,7 @@
"make instances really small but slow without the JIT",
default=False,
requires=[("objspace.std.getattributeshortcut", True),
- ("objspace.std.withmethodcache", True),
+ ("objspace.std.withtypeversion", True),
]),
BoolOption("withrangelist",
diff --git a/pypy/config/test/test_pypyoption.py b/pypy/config/test/test_pypyoption.py
--- a/pypy/config/test/test_pypyoption.py
+++ b/pypy/config/test/test_pypyoption.py
@@ -12,9 +12,9 @@
assert conf.objspace.usemodules.gc
conf.objspace.std.withmapdict = True
- assert conf.objspace.std.withmethodcache
+ assert conf.objspace.std.withtypeversion
conf = get_pypy_config()
- conf.objspace.std.withmethodcache = False
+ conf.objspace.std.withtypeversion = False
py.test.raises(ConfigError, "conf.objspace.std.withmapdict = True")
def test_conflicting_gcrootfinder():
diff --git a/pypy/doc/_ref.txt b/pypy/doc/_ref.txt
--- a/pypy/doc/_ref.txt
+++ b/pypy/doc/_ref.txt
@@ -1,10 +1,12 @@
+.. This file is generated automatically by makeref.py script,
+ which in turn is run manually.
+
.. _`ctypes_configure/doc/sample.py`: https://bitbucket.org/pypy/pypy/src/default/ctypes_configure/doc/sample.py
.. _`dotviewer/`: https://bitbucket.org/pypy/pypy/src/default/dotviewer/
.. _`lib-python/`: https://bitbucket.org/pypy/pypy/src/default/lib-python/
.. _`lib-python/2.7/dis.py`: https://bitbucket.org/pypy/pypy/src/default/lib-python/2.7/dis.py
.. _`lib_pypy/`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/
.. _`lib_pypy/greenlet.py`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/greenlet.py
-.. _`lib_pypy/pypy_test/`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/pypy_test/
.. _`lib_pypy/tputil.py`: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/tputil.py
.. _`pypy/bin/`: https://bitbucket.org/pypy/pypy/src/default/pypy/bin/
.. _`pypy/bin/pyinteractive.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/bin/pyinteractive.py
@@ -35,7 +37,6 @@
.. _`pypy/interpreter/gateway.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/gateway.py
.. _`pypy/interpreter/mixedmodule.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/mixedmodule.py
.. _`pypy/interpreter/module.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/module.py
-.. _`pypy/interpreter/nestedscope.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/nestedscope.py
.. _`pypy/interpreter/pyframe.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyframe.py
.. _`pypy/interpreter/pyopcode.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/pyopcode.py
.. _`pypy/interpreter/pyparser`:
@@ -49,21 +50,21 @@
.. _`pypy/module`:
.. _`pypy/module/`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/
.. _`pypy/module/__builtin__/__init__.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/__builtin__/__init__.py
+.. _`pypy/module/cppyy/capi/__init__.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/capi/__init__.py
+.. _`pypy/module/cppyy/capi/builtin_capi.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/capi/builtin_capi.py
+.. _`pypy/module/cppyy/include/capi.h`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/cppyy/include/capi.h
+.. _`pypy/module/test_lib_pypy/`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/test_lib_pypy/
.. _`pypy/objspace/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/
-.. _`pypy/objspace/flow/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/flow/
.. _`pypy/objspace/std`:
.. _`pypy/objspace/std/`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/
-.. _`pypy/objspace/std/listtype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/listtype.py
+.. _`pypy/objspace/std/bytesobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/bytesobject.py
.. _`pypy/objspace/std/multimethod.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/multimethod.py
.. _`pypy/objspace/std/objspace.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/objspace.py
.. _`pypy/objspace/std/proxy_helpers.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/proxy_helpers.py
.. _`pypy/objspace/std/proxyobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/proxyobject.py
-.. _`pypy/objspace/std/stringtype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/stringtype.py
+.. _`pypy/objspace/std/strbufobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/strbufobject.py
.. _`pypy/objspace/std/transparent.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/transparent.py
-.. _`pypy/objspace/std/tupleobject.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/tupleobject.py
-.. _`pypy/objspace/std/tupletype.py`: https://bitbucket.org/pypy/pypy/src/default/pypy/objspace/std/tupletype.py
.. _`pypy/tool/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/
-.. _`pypy/tool/algo/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/algo/
.. _`pypy/tool/pytest/`: https://bitbucket.org/pypy/pypy/src/default/pypy/tool/pytest/
.. _`rpython/annotator`:
.. _`rpython/annotator/`: https://bitbucket.org/pypy/pypy/src/default/rpython/annotator/
@@ -75,6 +76,11 @@
.. _`rpython/config/translationoption.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/config/translationoption.py
.. _`rpython/flowspace/`: https://bitbucket.org/pypy/pypy/src/default/rpython/flowspace/
.. _`rpython/flowspace/model.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/flowspace/model.py
+.. _`rpython/memory/`: https://bitbucket.org/pypy/pypy/src/default/rpython/memory/
+.. _`rpython/memory/gc/generation.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/memory/gc/generation.py
+.. _`rpython/memory/gc/hybrid.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/memory/gc/hybrid.py
+.. _`rpython/memory/gc/minimarkpage.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/memory/gc/minimarkpage.py
+.. _`rpython/memory/gc/semispace.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/memory/gc/semispace.py
.. _`rpython/rlib`:
.. _`rpython/rlib/`: https://bitbucket.org/pypy/pypy/src/default/rpython/rlib/
.. _`rpython/rlib/listsort.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rlib/listsort.py
@@ -93,16 +99,12 @@
.. _`rpython/rtyper/`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/
.. _`rpython/rtyper/lltypesystem/`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/lltypesystem/
.. _`rpython/rtyper/lltypesystem/lltype.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/lltypesystem/lltype.py
-.. _`rpython/rtyper/memory/`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/memory/
-.. _`rpython/rtyper/memory/gc/generation.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/memory/gc/generation.py
-.. _`rpython/rtyper/memory/gc/hybrid.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/memory/gc/hybrid.py
-.. _`rpython/rtyper/memory/gc/minimarkpage.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/memory/gc/minimarkpage.py
-.. _`rpython/rtyper/memory/gc/semispace.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/memory/gc/semispace.py
.. _`rpython/rtyper/rint.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/rint.py
.. _`rpython/rtyper/rlist.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/rlist.py
.. _`rpython/rtyper/rmodel.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/rmodel.py
.. _`rpython/rtyper/rtyper.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/rtyper.py
.. _`rpython/rtyper/test/test_llinterp.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/test/test_llinterp.py
+.. _`rpython/tool/algo/`: https://bitbucket.org/pypy/pypy/src/default/rpython/tool/algo/
.. _`rpython/translator`:
.. _`rpython/translator/`: https://bitbucket.org/pypy/pypy/src/default/rpython/translator/
.. _`rpython/translator/backendopt/`: https://bitbucket.org/pypy/pypy/src/default/rpython/translator/backendopt/
diff --git a/pypy/doc/cleanup.rst b/pypy/doc/cleanup.rst
--- a/pypy/doc/cleanup.rst
+++ b/pypy/doc/cleanup.rst
@@ -9,9 +9,3 @@
distribution.rst
- dot-net.rst
-
-
-
-
-
diff --git a/pypy/doc/coding-guide.rst b/pypy/doc/coding-guide.rst
--- a/pypy/doc/coding-guide.rst
+++ b/pypy/doc/coding-guide.rst
@@ -742,9 +742,9 @@
Testing modules in ``lib_pypy/``
--------------------------------
-You can go to the `lib_pypy/pypy_test/`_ directory and invoke the testing tool
+You can go to the `pypy/module/test_lib_pypy/`_ directory and invoke the testing tool
("py.test" or "python ../../pypy/test_all.py") to run tests against the
-lib_pypy hierarchy. Note, that tests in `lib_pypy/pypy_test/`_ are allowed
+lib_pypy hierarchy. Note, that tests in `pypy/module/test_lib_pypy/`_ are allowed
and encouraged to let their tests run at interpreter level although
`lib_pypy/`_ modules eventually live at PyPy's application level.
This allows us to quickly test our python-coded reimplementations
@@ -835,15 +835,6 @@
web interface.
.. _`development tracker`: https://bugs.pypy.org/
-
-use your codespeak login or register
-------------------------------------
-
-If you have an existing codespeak account, you can use it to login within the
-tracker. Else, you can `register with the tracker`_ easily.
-
-
-.. _`register with the tracker`: https://bugs.pypy.org/user?@template=register
.. _`roundup`: http://roundup.sourceforge.net/
diff --git a/pypy/doc/config/opt.rst b/pypy/doc/config/opt.rst
--- a/pypy/doc/config/opt.rst
+++ b/pypy/doc/config/opt.rst
@@ -46,5 +46,5 @@
The default level is `2`.
-.. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
+.. _`Boehm-Demers-Weiser garbage collector`: http://hboehm.info/gc/
.. _`custom garbage collectors`: ../garbage_collection.html
diff --git a/pypy/doc/config/translation.backendopt.txt b/pypy/doc/config/translation.backendopt.txt
--- a/pypy/doc/config/translation.backendopt.txt
+++ b/pypy/doc/config/translation.backendopt.txt
@@ -1,5 +1,5 @@
This group contains options about various backend optimization passes. Most of
them are described in the `EU report about optimization`_
-.. _`EU report about optimization`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
+.. _`EU report about optimization`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
diff --git a/pypy/doc/contributor.rst b/pypy/doc/contributor.rst
--- a/pypy/doc/contributor.rst
+++ b/pypy/doc/contributor.rst
@@ -15,21 +15,21 @@
Alex Gaynor
Michael Hudson
David Schneider
+ Matti Picus
+ Brian Kearns
+ Philip Jenvey
Holger Krekel
Christian Tismer
- Matti Picus
Hakan Ardo
Benjamin Peterson
- Philip Jenvey
+ Manuel Jacob
Anders Chrigstrom
- Brian Kearns
- Manuel Jacob
Eric van Riet Paap
Wim Lavrijsen
+ Ronan Lamy
Richard Emslie
Alexander Schremmer
Dan Villiom Podlaski Christiansen
- Ronan Lamy
Lukas Diekmann
Sven Hager
Anders Lehmann
@@ -38,23 +38,23 @@
Camillo Bruni
Laura Creighton
Toon Verwaest
+ Remi Meier
Leonardo Santagada
Seo Sanghyeon
+ Romain Guillebert
Justin Peel
Ronny Pfannschmidt
David Edelsohn
Anders Hammarquist
Jakub Gustak
- Romain Guillebert
Guido Wesdorp
Lawrence Oluyede
- Remi Meier
Bartosz Skowron
Daniel Roberts
Niko Matsakis
Adrien Di Mascio
+ Alexander Hesse
Ludovic Aubry
- Alexander Hesse
Jacob Hallen
Jason Creighton
Alex Martelli
@@ -71,6 +71,7 @@
Bruno Gola
Jean-Paul Calderone
Timo Paulssen
+ Squeaky
Alexandre Fayolle
Simon Burton
Marius Gedminas
@@ -87,6 +88,7 @@
Paweł Piotr Przeradowski
Paul deGrandis
Ilya Osadchiy
+ Tobias Oberstein
Adrian Kuhn
Boris Feigin
Stefano Rivera
@@ -95,13 +97,17 @@
Georg Brandl
Bert Freudenberg
Stian Andreassen
+ Laurence Tratt
Wanja Saatkamp
Gerald Klix
Mike Blume
Oscar Nierstrasz
Stefan H. Muller
- Laurence Tratt
+ Jeremy Thurgood
+ Gregor Wegberg
Rami Chowdhury
+ Tobias Pape
+ Edd Barrett
David Malcolm
Eugene Oden
Henry Mason
@@ -110,9 +116,7 @@
David Ripton
Dusty Phillips
Lukas Renggli
- Edd Barrett
Guenter Jantzen
- Tobias Oberstein
Ned Batchelder
Amit Regmi
Ben Young
@@ -123,7 +127,6 @@
Nicholas Riley
Jason Chu
Igor Trindade Oliveira
- Jeremy Thurgood
Rocco Moretti
Gintautas Miliauskas
Michael Twomey
@@ -134,7 +137,6 @@
Olivier Dormond
Jared Grubb
Karl Bartel
- Tobias Pape
Brian Dorsey
Victor Stinner
Andrews Medina
@@ -146,9 +148,9 @@
Aaron Iles
Michael Cheng
Justas Sadzevicius
+ Mikael Schönenberg
Gasper Zejn
Neil Shepperd
- Mikael Schönenberg
Elmo Mäntynen
Jonathan David Riehl
Stanislaw Halik
@@ -161,7 +163,9 @@
Alexander Sedov
Corbin Simpson
Christopher Pope
+ wenzhuman
Christian Tismer
+ Marc Abramowitz
Dan Stromberg
Stefano Parmesan
Alexis Daboville
@@ -170,6 +174,7 @@
Karl Ramm
Pieter Zieschang
Gabriel
+ Lukas Vacek
Andrew Dalke
Sylvain Thenault
Nathan Taylor
@@ -180,6 +185,7 @@
Travis Francis Athougies
Kristjan Valur Jonsson
Neil Blakey-Milner
+ anatoly techtonik
Lutz Paelike
Lucio Torre
Lars Wassermann
@@ -200,7 +206,6 @@
Bobby Impollonia
timo at eistee.fritz.box
Andrew Thompson
- Yusei Tahara
Ben Darnell
Roberto De Ioris
Juan Francisco Cantero Hurtado
@@ -212,28 +217,35 @@
Anders Sigfridsson
Yasir Suhail
Floris Bruynooghe
+ Laurens Van Houtven
Akira Li
Gustavo Niemeyer
Stephan Busemann
Rafał Gałczyński
+ Yusei Tahara
Christian Muirhead
James Lan
shoma hosaka
- Daniel Neuhäuser
+ Daniel Neuh?user
+ Matthew Miller
Buck Golemon
Konrad Delong
Dinu Gherman
Chris Lambacher
coolbutuseless at gmail.com
+ Rodrigo Araújo
w31rd0
Jim Baker
- Rodrigo Araújo
+ James Robert
Armin Ronacher
Brett Cannon
yrttyr
+ aliceinwire
+ OlivierBlanvillain
Zooko Wilcox-O Hearn
Tomer Chachamu
Christopher Groskopf
+ jiaaro
opassembler.py
Antony Lee
Jim Hunziker
@@ -241,6 +253,7 @@
Even Wiik Thomassen
jbs
soareschen
+ Kurt Griffiths
Mike Bayer
Flavio Percoco
Kristoffer Kleine
diff --git a/pypy/doc/cppyy_backend.rst b/pypy/doc/cppyy_backend.rst
--- a/pypy/doc/cppyy_backend.rst
+++ b/pypy/doc/cppyy_backend.rst
@@ -51,3 +51,6 @@
to ``PATH``).
In case of the former, include files are expected under ``$ROOTSYS/include``
and libraries under ``$ROOTSYS/lib``.
+
+
+.. include:: _ref.txt
diff --git a/pypy/doc/cpython_differences.rst b/pypy/doc/cpython_differences.rst
--- a/pypy/doc/cpython_differences.rst
+++ b/pypy/doc/cpython_differences.rst
@@ -106,23 +106,43 @@
Differences related to garbage collection strategies
----------------------------------------------------
-Most of the garbage collectors used or implemented by PyPy are not based on
+The garbage collectors used or implemented by PyPy are not based on
reference counting, so the objects are not freed instantly when they are no
longer reachable. The most obvious effect of this is that files are not
promptly closed when they go out of scope. For files that are opened for
writing, data can be left sitting in their output buffers for a while, making
-the on-disk file appear empty or truncated.
+the on-disk file appear empty or truncated. Moreover, you might reach your
+OS's limit on the number of concurrently opened files.
-Fixing this is essentially not possible without forcing a
+Fixing this is essentially impossible without forcing a
reference-counting approach to garbage collection. The effect that you
get in CPython has clearly been described as a side-effect of the
implementation and not a language design decision: programs relying on
this are basically bogus. It would anyway be insane to try to enforce
CPython's behavior in a language spec, given that it has no chance to be
adopted by Jython or IronPython (or any other port of Python to Java or
-.NET, like PyPy itself).
+.NET).
-This affects the precise time at which ``__del__`` methods are called, which
+Even the naive idea of forcing a full GC when we're getting dangerously
+close to the OS's limit can be very bad in some cases. If your program
+leaks open files heavily, then it would work, but force a complete GC
+cycle every n'th leaked file. The value of n is a constant, but the
+program can take an arbitrary amount of memory, which makes a complete
+GC cycle arbitrarily long. The end result is that PyPy would spend an
+arbitrarily large fraction of its run time in the GC --- slowing down
+the actual execution, not by 10% nor 100% nor 1000% but by essentially
+any factor.
+
+To the best of our knowledge this problem has no better solution than
+fixing the programs. If it occurs in 3rd-party code, this means going
+to the authors and explaining the problem to them: they need to close
+their open files in order to run on any non-CPython-based implementation
+of Python.
+
+---------------------------------
+
+Here are some more technical details. This issue affects the precise
+time at which ``__del__`` methods are called, which
is not reliable in PyPy (nor Jython nor IronPython). It also means that
weak references may stay alive for a bit longer than expected. This
makes "weak proxies" (as returned by ``weakref.proxy()``) somewhat less
@@ -315,6 +335,15 @@
implementation detail that shows up because of internal C-level slots
that PyPy does not have.
+* on CPython, ``[].__add__`` is a ``method-wrapper``, and
+ ``list.__add__`` is a ``slot wrapper``. On PyPy these are normal
+ bound or unbound method objects. This can occasionally confuse some
+ tools that inspect built-in types. For example, the standard
+ library ``inspect`` module has a function ``ismethod()`` that returns
+ True on unbound method objects but False on method-wrappers or slot
+ wrappers. On PyPy we can't tell the difference, so
+ ``ismethod([].__add__) == ismethod(list.__add__) == True``.
+
* the ``__dict__`` attribute of new-style classes returns a normal dict, as
opposed to a dict proxy like in CPython. Mutating the dict will change the
type and vice versa. For builtin types, a dictionary will be returned that
diff --git a/pypy/doc/dir-reference.rst b/pypy/doc/dir-reference.rst
--- a/pypy/doc/dir-reference.rst
+++ b/pypy/doc/dir-reference.rst
@@ -47,7 +47,7 @@
`pypy/tool/`_ various utilities and hacks used
from various places
-`pypy/tool/algo/`_ general-purpose algorithmic and mathematic
+`rpython/tool/algo/`_ general-purpose algorithmic and mathematic
tools
`pypy/tool/pytest/`_ support code for our `testing methods`_
@@ -129,3 +129,4 @@
.. _Mono: http://www.mono-project.com/
.. _`"standard library"`: rlib.html
.. _`graph viewer`: getting-started-dev.html#try-out-the-translator
+.. include:: _ref.txt
diff --git a/pypy/doc/discussions.rst b/pypy/doc/discussions.rst
--- a/pypy/doc/discussions.rst
+++ b/pypy/doc/discussions.rst
@@ -11,7 +11,5 @@
discussion/finalizer-order.rst
discussion/howtoimplementpickling.rst
discussion/improve-rpython.rst
- discussion/outline-external-ootype.rst
- discussion/VM-integration.rst
diff --git a/pypy/doc/distribution.rst b/pypy/doc/distribution.rst
--- a/pypy/doc/distribution.rst
+++ b/pypy/doc/distribution.rst
@@ -1,5 +1,3 @@
-.. include:: needswork.txt
-
=============================
lib_pypy/distributed features
=============================
diff --git a/pypy/doc/embedding.rst b/pypy/doc/embedding.rst
--- a/pypy/doc/embedding.rst
+++ b/pypy/doc/embedding.rst
@@ -51,6 +51,8 @@
.. function:: int pypy_execute_source_ptr(char* source, void* ptr);
+ .. note:: Not available in PyPy <= 2.2.1
+
Just like the above, except it registers a magic argument in the source
scope as ``c_argument``, where ``void*`` is encoded as Python int.
@@ -100,9 +102,29 @@
Worked!
+.. note:: If the compilation fails because of missing PyPy.h header file,
+ you are running PyPy <= 2.2.1, please see the section `Missing PyPy.h`_.
+
+Missing PyPy.h
+--------------
+
+.. note:: PyPy.h is in the nightly builds and goes to new PyPy releases (>2.2.1).
+
+For PyPy <= 2.2.1, you can download PyPy.h from PyPy repository (it has been added in commit c4cd6ec):
+
+.. code-block:: bash
+
+ cd /opt/pypy/include
+ wget https://bitbucket.org/pypy/pypy/raw/c4cd6eca9358066571500ac82aaacfdaa3889e8c/include/PyPy.h
+
+
More advanced example
---------------------
+.. note:: This example depends on pypy_execute_source_ptr which is not available
+ in PyPy <= 2.2.1. You might want to see the alternative example
+ below.
+
Typically we need something more to do than simply execute source. The following
is a fully fledged example, please consult cffi documentation for details.
It's a bit longish, but it captures a gist what can be done with the PyPy
@@ -161,6 +183,97 @@
is that we would pass a struct full of callbacks to ``pypy_execute_source_ptr``
and fill the structure from Python side for the future use.
+Alternative example
+-------------------
+
+As ``pypy_execute_source_ptr`` is not available in PyPy 2.2.1, you might want to try
+an alternative approach which relies on -export-dynamic flag to the GNU linker.
+The downside to this approach is that it is platform dependent.
+
+.. code-block:: c
+
+ #include "include/PyPy.h"
+ #include <stdio.h>
+
+ char source[] = "from cffi import FFI\n\
+ ffi = FFI()\n\
+ @ffi.callback('int(int)')\n\
+ def func(a):\n\
+ print 'Got from C %d' % a\n\
+ return a * 2\n\
+ ffi.cdef('int callback(int (*func)(int));')\n\
+ lib = ffi.verify('int callback(int (*func)(int));')\n\
+ lib.callback(func)\n\
+ print 'finished the Python part'\n\
+ ";
+
+ int callback(int (*func)(int))
+ {
+ printf("Calling to Python, result: %d\n", func(3));
+ }
+
+ int main()
+ {
+ int res;
+ void *lib, *func;
+
+ rpython_startup_code();
+ res = pypy_setup_home("/opt/pypy/bin/libpypy-c.so", 1);
+ if (res) {
+ printf("Error setting pypy home!\n");
+ return 1;
+ }
+ res = pypy_execute_source(source);
+ if (res) {
+ printf("Error calling pypy_execute_source!\n");
+ }
+ return res;
+ }
+
+
+Make sure to pass -export-dynamic flag when compiling::
+
+ $ gcc -g -o x x.c -lpypy-c -L. -export-dynamic
+ $ LD_LIBRARY_PATH=. ./x
+ Got from C 3
+ Calling to Python, result: 6
+ finished the Python part
+
+Finding pypy_home
+-----------------
+
+Function pypy_setup_home takes one parameter - the path to libpypy. There's
+currently no "clean" way (pkg-config comes to mind) how to find this path. You
+can try the following (GNU-specific) hack (don't forget to link against *dl*):
+
+.. code-block:: c
+
+ #if !(_GNU_SOURCE)
+ #define _GNU_SOURCE
+ #endif
+
+ #include <dlfcn.h>
+ #include <limits.h>
+ #include <stdlib.h>
+
+ // caller should free returned pointer to avoid memleaks
+ // returns NULL on error
+ char* guess_pypyhome() {
+ // glibc-only (dladdr is why we #define _GNU_SOURCE)
+ Dl_info info;
+ void *_rpython_startup_code = dlsym(0,"rpython_startup_code");
+ if (_rpython_startup_code == 0) {
+ return 0;
+ }
+ if (dladdr(_rpython_startup_code, &info) != 0) {
+ const char* lib_path = info.dli_fname;
+ char* lib_realpath = realpath(lib_path, 0);
+ return lib_realpath;
+ }
+ return 0;
+ }
+
+
Threading
---------
diff --git a/pypy/doc/eventhistory.rst b/pypy/doc/eventhistory.rst
--- a/pypy/doc/eventhistory.rst
+++ b/pypy/doc/eventhistory.rst
@@ -17,7 +17,7 @@
Read more in the `EuroPython 2006 sprint report`_.
-.. _`EuroPython 2006 sprint report`: http://codespeak.net/pypy/extradoc/sprintinfo/post-ep2006/report.txt
+.. _`EuroPython 2006 sprint report`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/post-ep2006/report.txt
PyPy at XP 2006 and Agile 2006
==================================================================
@@ -41,8 +41,8 @@
Read more in `the sprint announcement`_, see who is planning to attend
on the `people page`_.
-.. _`the sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006/announce.html
-.. _`people page`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006/people.html
+.. _`the sprint announcement`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006/announce.html
+.. _`people page`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006/people.txt
PyPy sprint at Akihabara (Tokyo, Japan)
==================================================================
@@ -84,8 +84,8 @@
Read the report_ and the original announcement_.
-.. _report: http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.html
-.. _announcement: http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/sprint-announcement.html
+.. _report: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/louvain-la-neuve-2006/report.txt
+.. _announcement: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/louvain-la-neuve-2006/sprint-announcement.txt
PyCon Sprint 2006 (Dallas, Texas, USA)
==================================================================
@@ -114,7 +114,7 @@
said they were interested in the outcome and would keep an eye on its
progress. Read the `talk slides`_.
-.. _`talk slides`: http://codespeak.net/pypy/extradoc/talk/solutions-linux-paris-2006.html
+.. _`talk slides`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/solutions-linux-paris-2006.html
PyPy Sprint in Palma De Mallorca 23rd - 29th January 2006
@@ -129,9 +129,9 @@
for the first three days and `one for the rest of the sprint`_.
-.. _`the announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/mallorca/sprint-announcement.html
-.. _`sprint report`: http://codespeak.net/pipermail/pypy-dev/2006q1/002746.html
-.. _`one for the rest of the sprint`: http://codespeak.net/pipermail/pypy-dev/2006q1/002749.html
+.. _`the announcement`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/mallorca/sprint-announcement.txt
+.. _`sprint report`: https://mail.python.org/pipermail/pypy-dev/2006-January/002746.html
+.. _`one for the rest of the sprint`: https://mail.python.org/pipermail/pypy-dev/2006-January/002749.html
Preliminary EU reports released
===============================
@@ -155,8 +155,8 @@
Michael and Carl have written a `report about the first half`_ and `one about
the second half`_ of the sprint. *(12/18/2005)*
-.. _`report about the first half`: http://codespeak.net/pipermail/pypy-dev/2005q4/002656.html
-.. _`one about the second half`: http://codespeak.net/pipermail/pypy-dev/2005q4/002660.html
+.. _`report about the first half`: https://mail.python.org/pipermail/pypy-dev/2005-December/002656.html
+.. _`one about the second half`: https://mail.python.org/pipermail/pypy-dev/2005-December/002660.html
PyPy release 0.8.0
===================
@@ -187,12 +187,12 @@
way back.
*(10/18/2005)*
-.. _`Logilab offices in Paris`: http://codespeak.net/pypy/extradoc/sprintinfo/paris-2005-sprint.html
+.. _`Logilab offices in Paris`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/paris-2005-sprint.txt
.. _JIT: http://en.wikipedia.org/wiki/Just-in-time_compilation
.. _`continuation-passing`: http://en.wikipedia.org/wiki/Continuation_passing_style
-.. _`report about day one`: http://codespeak.net/pipermail/pypy-dev/2005q4/002510.html
-.. _`one about day two and three`: http://codespeak.net/pipermail/pypy-dev/2005q4/002512.html
-.. _`the rest of the sprint`: http://codespeak.net/pipermail/pypy-dev/2005q4/002514.html
+.. _`report about day one`: https://mail.python.org/pipermail/pypy-dev/2005-October/002510.html
+.. _`one about day two and three`: https://mail.python.org/pipermail/pypy-dev/2005-October/002512.html
+.. _`the rest of the sprint`: https://mail.python.org/pipermail/pypy-dev/2005-October/002514.html
PyPy release 0.7.0
===================
@@ -217,15 +217,13 @@
Its main focus is translation of the whole PyPy interpreter
to a low level language and reaching 2.4.1 Python compliance.
The goal of the sprint is to release a first self-contained
-PyPy-0.7 version. Carl has written a report about `day 1 - 3`_,
-there are `some pictures`_ online and a `heidelberg summary report`_
-detailing some of the works that led to the successful release
-of `pypy-0.7.0`_!
+PyPy-0.7 version. Carl has written a report about `day 1 - 3`_
+and a `heidelberg summary report`_ detailing some of the works
+that led to the successful release of `pypy-0.7.0`_!
-.. _`heidelberg summary report`: http://codespeak.net/pypy/extradoc/sprintinfo/Heidelberg-report.html
-.. _`PyPy sprint`: http://codespeak.net/pypy/extradoc/sprintinfo/Heidelberg-sprint.html
-.. _`day 1 - 3`: http://codespeak.net/pipermail/pypy-dev/2005q3/002287.html
-.. _`some pictures`: http://codespeak.net/~hpk/heidelberg-sprint/
+.. _`heidelberg summary report`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/Heidelberg-report.txt
+.. _`PyPy sprint`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/Heidelberg-sprint.txt
+.. _`day 1 - 3`: https://mail.python.org/pipermail/pypy-dev/2005-August/002287.html
PyPy Hildesheim2 finished: first self-contained PyPy run!
===========================================================
@@ -233,20 +231,16 @@
Up until 31st August we were in a PyPy sprint at `Trillke-Gut`_.
Carl has written a `report about day 1`_, Holger
about `day 2 and day 3`_ and Carl again about `day 4 and day 5`_,
-On `day 6`_ Holger reports the `breakthrough`_: PyPy runs
-on its own! Hurray_!. And Carl finally reports about the winding
+On `day 6`_ Holger reports the breakthrough: PyPy runs
+on its own! Hurray!. And Carl finally reports about the winding
down of `day 7`_ which saw us relaxing, discussing and generally
-having a good time. You might want to look at the selected
-`pictures from the sprint`_.
+having a good time.
-.. _`report about day 1`: http://codespeak.net/pipermail/pypy-dev/2005q3/002217.html
-.. _`day 2 and day 3`: http://codespeak.net/pipermail/pypy-dev/2005q3/002220.html
-.. _`day 4 and day 5`: http://codespeak.net/pipermail/pypy-dev/2005q3/002234.html
-.. _`day 6`: http://codespeak.net/pipermail/pypy-dev/2005q3/002239.html
-.. _`day 7`: http://codespeak.net/pipermail/pypy-dev/2005q3/002245.html
-.. _`breakthrough`: http://codespeak.net/~hpk/hildesheim2-sprint-www/hildesheim2-sprint-www-Thumbnails/36.jpg
-.. _`hurray`: http://codespeak.net/~hpk/hildesheim2-sprint-www/hildesheim2-sprint-www-Pages/Image37.html
-.. _`pictures from the sprint`: http://codespeak.net/~hpk/hildesheim2-sprint-www/
+.. _`report about day 1`: https://mail.python.org/pipermail/pypy-dev/2005-July/002217.html
+.. _`day 2 and day 3`: https://mail.python.org/pipermail/pypy-dev/2005-July/002220.html
+.. _`day 4 and day 5`: https://mail.python.org/pipermail/pypy-dev/2005-July/002234.html
+.. _`day 6`: https://mail.python.org/pipermail/pypy-dev/2005-July/002239.html
+.. _`day 7`: https://mail.python.org/pipermail/pypy-dev/2005-August/002245.html
.. _`Trillke-Gut`: http://www.trillke.net
EuroPython 2005 sprints finished
@@ -264,15 +258,15 @@
the LLVM backends and type inference in general.
*(07/13/2005)*
-.. _`day 1`: http://codespeak.net/pipermail/pypy-dev/2005q2/002169.html
-.. _`day 2`: http://codespeak.net/pipermail/pypy-dev/2005q2/002171.html
-.. _`day 3`: http://codespeak.net/pipermail/pypy-dev/2005q2/002172.html
-.. _`pypy-dev`: http://mail.python.org/mailman/listinfo/pypy-dev
+.. _`day 1`: https://mail.python.org/pipermail/pypy-dev/2005-June/002169.html
+.. _`day 2`: https://mail.python.org/pipermail/pypy-dev/2005-June/002171.html
+.. _`day 3`: https://mail.python.org/pipermail/pypy-dev/2005-June/002172.html
+.. _`pypy-dev`: https://mail.python.org/mailman/listinfo/pypy-dev
.. _EuroPython: http://europython.org
.. _`translation`: translation.html
-.. _`sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/EP2005-announcement.html
-.. _`list of people coming`: http://codespeak.net/pypy/extradoc/sprintinfo/EP2005-people.html
+.. _`sprint announcement`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/EP2005-announcement.html
+.. _`list of people coming`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/EP2005-people.html
Duesseldorf PyPy sprint 2-9 June 2006
==================================================================
@@ -285,8 +279,8 @@
Read more in `the sprint announcement`_, see who is planning to attend
on the `people page`_.
-.. _`the sprint announcement`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006/announce.html
-.. _`people page`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006/people.html
+.. _`the sprint announcement`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006/announce.txt
+.. _`people page`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006/people.txt
PyPy at XP 2006 and Agile 2006
diff --git a/pypy/doc/extradoc.rst b/pypy/doc/extradoc.rst
--- a/pypy/doc/extradoc.rst
+++ b/pypy/doc/extradoc.rst
@@ -79,7 +79,7 @@
.. _`Tracing the Meta-Level: PyPy's Tracing JIT Compiler`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/icooolps2009/bolz-tracing-jit.pdf
.. _`Faster than C#: Efficient Implementation of Dynamic Languages on .NET`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/icooolps2009-dotnet/cli-jit.pdf
.. _`Automatic JIT Compiler Generation with Runtime Partial Evaluation`: http://wwwold.cobra.cs.uni-duesseldorf.de/thesis/final-master.pdf
-.. _`RPython: A Step towards Reconciling Dynamically and Statically Typed OO Languages`: http://www.disi.unige.it/person/AnconaD/papers/Recent_abstracts.html#AACM-DLS07
+.. _`RPython: A Step towards Reconciling Dynamically and Statically Typed OO Languages`: http://www.disi.unige.it/person/AnconaD/papers/DynamicLanguages_abstracts.html#AACM-DLS07
.. _`EU Reports`: index-report.html
.. _`Hardware Transactional Memory Support for Lightweight Dynamic Language Evolution`: http://sabi.net/nriley/pubs/dls6-riley.pdf
.. _`PyGirl: Generating Whole-System VMs from High-Level Prototypes using PyPy`: http://scg.unibe.ch/archive/papers/Brun09cPyGirl.pdf
@@ -87,7 +87,7 @@
.. _`Back to the Future in One Week -- Implementing a Smalltalk VM in PyPy`: http://dx.doi.org/10.1007/978-3-540-89275-5_7
.. _`Automatic generation of JIT compilers for dynamic languages in .NET`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ecoop2009/main.pdf
.. _`Core Object Optimization Results`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D06.1_Core_Optimizations-2007-04-30.pdf
-.. _`Compiling Dynamic Language Implementations`: http://codespeak.net/pypy/extradoc/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
+.. _`Compiling Dynamic Language Implementations`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D05.1_Publish_on_translating_a_very-high-level_description.pdf
Talks and Presentations
@@ -258,24 +258,24 @@
.. _`PyCon 2010`: http://morepypy.blogspot.com/2010/02/pycon-2010-report.html
.. _`RuPy 2009`: http://morepypy.blogspot.com/2009/11/pypy-on-rupy-2009.html
-.. _`PyPy 3000`: http://codespeak.net/pypy/extradoc/talk/ep2006/pypy3000.txt
-.. _`What can PyPy do for you`: http://codespeak.net/pypy/extradoc/talk/ep2006/usecases-slides.html
-.. _`PyPy introduction at EuroPython 2006`: http://codespeak.net/pypy/extradoc/talk/ep2006/intro.pdf
-.. _`PyPy - the new Python implementation on the block`: http://codespeak.net/pypy/extradoc/talk/22c3/hpk-tech.html
-.. _`PyPy development method`: http://codespeak.net/pypy/extradoc/talk/pycon2006/method_talk.html
-.. _`PyPy intro`: http://codespeak.net/pypy/extradoc/talk/accu2006/accu-2006.pdf
-.. _oscon2003-paper: http://codespeak.net/pypy/extradoc/talk/oscon2003-paper.html
-.. _`Architecture introduction slides`: http://codespeak.net/pypy/extradoc/talk/amsterdam-sprint-intro.pdf
-.. _`EU funding for FOSS`: http://codespeak.net/pypy/extradoc/talk/2004-21C3-pypy-EU-hpk.pdf
-.. _`py lib slides`: http://codespeak.net/pypy/extradoc/talk/2005-pycon-py.pdf
-.. _`PyCon 2005`: http://codespeak.net/pypy/extradoc/talk/pypy-talk-pycon2005/README.html
-.. _`Trouble in Paradise`: http://codespeak.net/pypy/extradoc/talk/agile2006/during-oss-sprints_talk.pdf
-.. _`Sprint Driven Development`: http://codespeak.net/pypy/extradoc/talk/xp2006/during-xp2006-sprints.pdf
-.. _`Kill -1`: http://codespeak.net/pypy/extradoc/talk/ep2006/kill_1_agiletalk.pdf
-.. _`Open Source, EU-Funding and Agile Methods`: http://codespeak.net/pypy/extradoc/talk/22c3/agility.pdf
-.. _`PyPy Status`: http://codespeak.net/pypy/extradoc/talk/vancouver/talk.html
+.. _`PyPy 3000`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2006/pypy3000.txt
+.. _`What can PyPy do for you`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2006/usecases-slides.txt
+.. _`PyPy introduction at EuroPython 2006`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2006/intro.pdf
+.. _`PyPy - the new Python implementation on the block`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/22c3/hpk-tech.txt
+.. _`PyPy development method`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon2006/method_talk.txt
+.. _`PyPy intro`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/accu2006/accu-2006.pdf
+.. _oscon2003-paper: https://bitbucket.org/pypy/extradoc/raw/tip/talk/oscon2003-paper.txt
+.. _`Architecture introduction slides`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/amsterdam-sprint-intro.pdf
+.. _`EU funding for FOSS`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/2004-21C3-pypy-EU-hpk.pdf
+.. _`py lib slides`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/2005-pycon-py.pdf
+.. _`PyCon 2005`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pypy-talk-pycon2005/README.txt
+.. _`Trouble in Paradise`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/agile2006/during-oss-sprints_talk.pdf
+.. _`Sprint Driven Development`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/xp2006/during-xp2006-sprints.pdf
+.. _`Kill -1`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2006/kill_1_agiletalk.pdf
+.. _`Open Source, EU-Funding and Agile Methods`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/22c3/agility.pdf
+.. _`PyPy Status`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/vancouver/
.. _`Sprinting the PyPy way`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2005/pypy_sprinttalk_ep2005bd.pdf
-.. _`PyPy's VM Approach`: http://codespeak.net/pypy/extradoc/talk/dls2006/talk.html
+.. _`PyPy's VM Approach`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dls2006/
.. _`PyPy's approach to virtual machine construction`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/dls2006/pypy-vm-construction.pdf
.. _`EuroPython talks 2009`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/ep2009/
.. _`PyCon talks 2009`: https://bitbucket.org/pypy/extradoc/raw/tip/talk/pycon2009/
@@ -356,8 +356,6 @@
.. _`transparent dynamic optimization`: http://www.hpl.hp.com/techreports/1999/HPL-1999-77.pdf
.. _Dynamo: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf
.. _testdesign: coding-guide.html#test-design
-.. _feasible: http://codespeak.net/pipermail/pypy-dev/2004q2/001289.html
-.. _rock: http://codespeak.net/pipermail/pypy-dev/2004q1/001255.html
.. _LLVM: http://llvm.org/
.. _IronPython: http://ironpython.codeplex.com/
.. _`Dynamic Native Optimization of Native Interpreters`: http://people.csail.mit.edu/gregs/dynamorio.html
diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -318,7 +318,7 @@
To read more about the RPython limitations read the `RPython description`_.
-.. _`RPython description`: coding-guide.html#restricted-python
+.. _`RPython description`: coding-guide.html#rpython-definition
---------------------------------------------------------------
Does RPython have anything to do with Zope's Restricted Python?
@@ -429,12 +429,27 @@
Could we use LLVM?
------------------
-There is a (static) translation backend using LLVM in the branch
-``llvm-translation-backend``. It can translate PyPy with or without the JIT on
-Linux.
+In theory yes. But we tried to use it 5 or 6 times already, as a
+translation backend or as a JIT backend --- and failed each time.
-Using LLVM as our JIT backend looks interesting as well -- we made an attempt,
-but it failed: LLVM has no way to patch the generated machine code.
+In more details: using LLVM as a (static) translation backend is
+pointless nowadays because you can generate C code and compile it with
+clang. (Note that compiling PyPy with clang gives a result that is not
+faster than compiling it with gcc.) We might in theory get extra
+benefits from LLVM's GC integration, but this requires more work on the
+LLVM side before it would be remotely useful. Anyway, it could be
+interfaced via a custom primitive in the C code. (The latest such
+experimental backend is in the branch ``llvm-translation-backend``,
+which can translate PyPy with or without the JIT on Linux.)
+
+On the other hand, using LLVM as our JIT backend looks interesting as
+well --- but again we made an attempt, and it failed: LLVM has no way to
+patch the generated machine code.
+
+So the position of the core PyPy developers is that if anyone wants to
+make an N+1'th attempt with LLVM, they are welcome, and will be happy to
+provide help in the IRC channel, but they are left with the burden of proof
+that (a) it works and (b) it gives important benefits.
----------------------
How do I compile PyPy?
@@ -444,6 +459,19 @@
.. _`getting-started`: getting-started-python.html
+------------------------------------------
+Compiling PyPy swaps or runs out of memory
+------------------------------------------
+
+This is documented (here__ and here__). It needs 4 GB of RAM to run
+"rpython targetpypystandalone" on top of PyPy, a bit more when running
+on CPython. If you have less than 4 GB it will just swap forever (or
+fail if you don't have enough swap). On 32-bit, divide the numbers by
+two.
+
+.. __: http://pypy.org/download.html#building-from-source
+.. __: https://pypy.readthedocs.org/en/latest/getting-started-python.html#translating-the-pypy-python-interpreter
+
.. _`how do I compile my own interpreters`:
-------------------------------------
diff --git a/pypy/doc/garbage_collection.rst b/pypy/doc/garbage_collection.rst
--- a/pypy/doc/garbage_collection.rst
+++ b/pypy/doc/garbage_collection.rst
@@ -14,7 +14,7 @@
The present document describes the specific garbage collectors that we
wrote in our framework.
-.. _`EU-report on this topic`: http://codespeak.net/pypy/extradoc/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
+.. _`EU-report on this topic`: https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D07.1_Massive_Parallelism_and_Translation_Aspects-2007-02-28.pdf
Garbage collectors currently written for the GC framework
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
@@ -222,7 +222,7 @@
PyPy development always was and is still thoroughly test-driven.
We use the flexible `py.test testing tool`_ which you can `install independently
-<http://pytest.org/getting-started.html>`_ and use for other projects.
+<http://pytest.org/latest/getting-started.html#getstarted>`_ and use for other projects.
The PyPy source tree comes with an inlined version of ``py.test``
which you can invoke by typing::
@@ -264,7 +264,7 @@
interpreter.
.. _`py.test testing tool`: http://pytest.org
-.. _`py.test usage and invocations`: http://pytest.org/usage.html#usage
+.. _`py.test usage and invocations`: http://pytest.org/latest/usage.html#usage
Special Introspection Features of the Untranslated Python Interpreter
---------------------------------------------------------------------
@@ -389,7 +389,7 @@
.. _`pypy-dev mailing list`: http://mail.python.org/mailman/listinfo/pypy-dev
.. _`contact possibilities`: index.html
-.. _`py library`: http://pylib.org
+.. _`py library`: http://pylib.readthedocs.org/
.. _`Spidermonkey`: http://www.mozilla.org/js/spidermonkey/
diff --git a/pypy/doc/glossary.rst b/pypy/doc/glossary.rst
--- a/pypy/doc/glossary.rst
+++ b/pypy/doc/glossary.rst
@@ -1,5 +1,3 @@
-.. include:: needswork.txt
-
.. _glossary:
********
diff --git a/pypy/doc/index-report.rst b/pypy/doc/index-report.rst
--- a/pypy/doc/index-report.rst
+++ b/pypy/doc/index-report.rst
@@ -92,7 +92,9 @@
`D07.1 Massive Parallelism and Translation Aspects`_ is a report about
PyPy's optimization efforts, garbage collectors and massive parallelism
(stackless) features. This report refers to the paper `PyPy's approach
-to virtual machine construction`_. *(2007-02-28)*
+to virtual machine construction`_. Extends the content previously
+available in the document "Memory management and threading models as
+translation aspects -- solutions and challenges". *(2007-02-28)*
diff --git a/pypy/doc/index.rst b/pypy/doc/index.rst
--- a/pypy/doc/index.rst
+++ b/pypy/doc/index.rst
@@ -103,7 +103,7 @@
.. _`more...`: architecture.html#mission-statement
.. _`PyPy blog`: http://morepypy.blogspot.com/
.. _`development bug/feature tracker`: https://bugs.pypy.org
-.. _here: http://tismerysoft.de/pypy/irc-logs/pypy
+.. _here: http://www.tismer.com/pypy/irc-logs/pypy/
.. _`Mercurial commit mailing list`: http://mail.python.org/mailman/listinfo/pypy-commit
.. _`development mailing list`: http://mail.python.org/mailman/listinfo/pypy-dev
.. _`FAQ`: faq.html
diff --git a/pypy/doc/interpreter.rst b/pypy/doc/interpreter.rst
--- a/pypy/doc/interpreter.rst
+++ b/pypy/doc/interpreter.rst
@@ -256,7 +256,7 @@
example and the higher level `chapter on Modules in the coding
guide`_.
-.. _`__builtin__ module`: https://bitbucket.org/pypy/pypy/src/tip/pypy/module/__builtin__/
+.. _`__builtin__ module`: https://bitbucket.org/pypy/pypy/src/default/pypy/module/__builtin__/
.. _`chapter on Modules in the coding guide`: coding-guide.html#modules
.. _`Gateway classes`:
diff --git a/pypy/doc/jit/_ref.txt b/pypy/doc/jit/_ref.txt
--- a/pypy/doc/jit/_ref.txt
+++ b/pypy/doc/jit/_ref.txt
@@ -0,0 +1,4 @@
+.. This file is generated automatically by makeref.py script,
+ which in turn is run manually.
+
+
diff --git a/pypy/doc/jit/pyjitpl5.rst b/pypy/doc/jit/pyjitpl5.rst
--- a/pypy/doc/jit/pyjitpl5.rst
+++ b/pypy/doc/jit/pyjitpl5.rst
@@ -177,6 +177,12 @@
.. __: https://bitbucket.org/pypy/extradoc/src/tip/talk/icooolps2009/bolz-tracing-jit-final.pdf
-as well as the `blog posts with the JIT tag.`__
+Chapters 5 and 6 of `Antonio Cuni's PhD thesis`__ contain an overview of how
+Tracing JITs work in general and more informations about the concrete case of
+PyPy's JIT.
+
+.. __: http://antocuni.eu/download/antocuni-phd-thesis.pdf
+
+The `blog posts with the JIT tag`__ might also contain additional information.
.. __: http://morepypy.blogspot.com/search/label/jit
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
@@ -185,6 +185,6 @@
.. _`standard object space`: objspace.html#the-standard-object-space
.. [D12.1] `High-Level Backends and Interpreter Feature Prototypes`, PyPy
- EU-Report, 2007, http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-2007-03-22.pdf
+ EU-Report, 2007, https://bitbucket.org/pypy/extradoc/raw/tip/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-2007-03-22.pdf
.. include:: _ref.txt
diff --git a/pypy/doc/objspace.rst b/pypy/doc/objspace.rst
--- a/pypy/doc/objspace.rst
+++ b/pypy/doc/objspace.rst
@@ -339,44 +339,35 @@
Object types
------------
-The larger part of the `pypy/objspace/std/`_ package defines and implements the
-library of Python's standard built-in object types. Each type (int, float,
-list, tuple, str, type, etc.) is typically implemented by two modules:
+The larger part of the `pypy/objspace/std/`_ package defines and
+implements the library of Python's standard built-in object types. Each
+type ``xxx`` (int, float, list, tuple, str, type, etc.) is typically
+implemented in the module ``xxxobject.py``.
-* the *type specification* module, which for a type ``xxx`` is called ``xxxtype.py``;
+The ``W_AbstractXxxObject`` class, when present, is the abstract base
+class, which mainly defines what appears on the Python-level type
+object. There are then actual implementations as subclasses, which are
+called ``W_XxxObject`` or some variant for the cases where we have
+several different implementations. For example,
+`pypy/objspace/std/bytesobject.py`_ defines ``W_AbstractBytesObject``,
+which contains everything needed to build the ``str`` app-level type;
+and there are subclasses ``W_BytesObject`` (the usual string) and
+``W_StringBufferObject`` (a special implementation tweaked for repeated
+additions, in `pypy/objspace/std/strbufobject.py`_). For mutable data
+types like lists and dictionaries, we have a single class
+``W_ListObject`` or ``W_DictMultiObject`` which has an indirection to
+the real data and a strategy; the strategy can change as the content of
+the object changes.
-* the *implementation* module, called ``xxxobject.py``.
-
-The ``xxxtype.py`` module basically defines the type object itself. For
-example, `pypy/objspace/std/listtype.py`_ contains the specification of the object you get when
-you type ``list`` in a PyPy prompt. `pypy/objspace/std/listtype.py`_ enumerates the methods
-specific to lists, like ``append()``.
-
-A particular method implemented by all types is the ``__new__()`` special
-method, which in Python's new-style-classes world is responsible for creating
-an instance of the type. In PyPy, ``__new__()`` locates and imports the module
-implementing *instances* of the type, and creates such an instance based on the
-arguments the user supplied to the constructor. For example, `pypy/objspace/std/tupletype.py`_
-defines ``__new__()`` to import the class ``W_TupleObject`` from
-`pypy/objspace/std/tupleobject.py`_ and instantiate it. The `pypy/objspace/std/tupleobject.py`_ then contains a
-"real" implementation of tuples: the way the data is stored in the
-``W_TupleObject`` class, how the operations work, etc.
-
-The goal of the above module layout is to cleanly separate the Python
-type object, visible to the user, and the actual implementation of its
-instances. It is possible to provide *several* implementations of the
-instances of the same Python type, by writing several ``W_XxxObject``
-classes. Every place that instantiates a new object of that Python type
-can decide which ``W_XxxObject`` class to instantiate.
-
-From the user's point of view, the multiple internal ``W_XxxObject``
-classes are not visible: they are still all instances of exactly the
-same Python type. PyPy knows that (e.g.) the application-level type of
-its interpreter-level ``W_StringObject`` instances is str because
-there is a ``typedef`` class attribute in ``W_StringObject`` which
-points back to the string type specification from `pypy/objspace/std/stringtype.py`_; all
-other implementations of strings use the same ``typedef`` from
-`pypy/objspace/std/stringtype.py`_.
+From the user's point of view, even when there are several
+``W_AbstractXxxObject`` subclasses, this is not visible: at the
+app-level, they are still all instances of exactly the same Python type.
+PyPy knows that (e.g.) the application-level type of its
+interpreter-level ``W_BytesObject`` instances is str because there is a
+``typedef`` class attribute in ``W_BytesObject`` which points back to
+the string type specification from `pypy/objspace/std/bytesobject.py`_;
+all other implementations of strings use the same ``typedef`` from
+`pypy/objspace/std/bytesobject.py`_.
For other examples of multiple implementations of the same Python type,
see `Standard Interpreter Optimizations`_.
@@ -387,6 +378,9 @@
Multimethods
------------
+*Note: multimethods are on the way out. Although they look cool,
+they failed to provide enough benefits.*
+
The Standard Object Space allows multiple object implementations per
Python type - this is based on multimethods_. For a description of the
multimethod variant that we implemented and which features it supports,
@@ -491,7 +485,7 @@
Introduction
------------
-The task of the FlowObjSpace (the source is at `pypy/objspace/flow/`_) is to generate a control-flow graph from a
+The task of the FlowObjSpace (the source is at `rpython/flowspace/`_) is to generate a control-flow graph from a
function. This graph will also contain a trace of the individual operations, so
that it is actually just an alternate representation for the function.
diff --git a/pypy/doc/rffi.rst b/pypy/doc/rffi.rst
--- a/pypy/doc/rffi.rst
+++ b/pypy/doc/rffi.rst
@@ -43,7 +43,7 @@
See cbuild_ for more info on ExternalCompilationInfo.
.. _`low level types`: rtyper.html#low-level-type
-.. _cbuild: https://bitbucket.org/pypy/pypy/src/tip/rpython/translator/tool/cbuild.py
+.. _cbuild: https://bitbucket.org/pypy/pypy/src/default/rpython/translator/tool/cbuild.py
Types
@@ -56,7 +56,7 @@
flavor='raw'. There are several helpers like string -> char*
converter, refer to the source for details.
-.. _rffi: https://bitbucket.org/pypy/pypy/src/tip/pypy/rpython/lltypesystem/rffi.py
+.. _rffi: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/lltypesystem/rffi.py
Registering function as external
---------------------------------
@@ -68,4 +68,4 @@
functions, passing llimpl as an argument and eventually llfakeimpl
as a fake low-level implementation for tests performed by an llinterp.
-.. _`extfunc.py`: https://bitbucket.org/pypy/pypy/src/tip/pypy/rpython/extfunc.py
+.. _`extfunc.py`: https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/extfunc.py
diff --git a/pypy/doc/sprint-reports.rst b/pypy/doc/sprint-reports.rst
--- a/pypy/doc/sprint-reports.rst
+++ b/pypy/doc/sprint-reports.rst
@@ -42,30 +42,30 @@
* `CERN (July 2010)`_
* `Düsseldorf (October 2010)`_
- .. _Hildesheim (Feb 2003): http://codespeak.net/pypy/extradoc/sprintinfo/HildesheimReport.html
- .. _Gothenburg (May 2003): http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2003-sprintreport.txt
- .. _LovainLaNeuve (June 2003): http://codespeak.net/pypy/extradoc/sprintinfo/LouvainLaNeuveReport.txt
- .. _Berlin (Sept 2003): http://codespeak.net/pypy/extradoc/sprintinfo/BerlinReport.txt
- .. _Amsterdam (Dec 2003): http://codespeak.net/pypy/extradoc/sprintinfo/AmsterdamReport.txt
- .. _Vilnius (Nov 2004): http://codespeak.net/pypy/extradoc/sprintinfo/vilnius-2004-sprintreport.txt
- .. _Leysin (Jan 2005): http://codespeak.net/pypy/extradoc/sprintinfo/LeysinReport.txt
- .. _PyCon/Washington (March 2005): http://codespeak.net/pypy/extradoc/sprintinfo/pycon_sprint_report.txt
- .. _Europython/Gothenburg (June 2005): http://codespeak.net/pypy/extradoc/sprintinfo/ep2005-sprintreport.txt
- .. _Hildesheim (July 2005): http://codespeak.net/pypy/extradoc/sprintinfo/hildesheim2005-sprintreport.txt
- .. _Heidelberg (Aug 2005): http://codespeak.net/pypy/extradoc/sprintinfo/Heidelberg-report.txt
- .. _Paris (Oct 2005): http://codespeak.net/pypy/extradoc/sprintinfo/paris/paris-report.txt
- .. _Gothenburg (Dec 2005): http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2005/gothenburg-dec2005-sprintreport.txt
- .. _Mallorca (Jan 2006): http://codespeak.net/pypy/extradoc/sprintinfo/mallorca/mallorca-sprintreport.txt
- .. _LouvainLaNeuve (March 2006): http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.txt
- .. _Leysin (April 2006): http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2006-sprintreport.txt
- .. _Tokyo (April 2006): http://codespeak.net/pypy/extradoc/sprintinfo/tokyo/sprint-report.txt
- .. _Düsseldorf (June 2006): http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006/report1.txt
- .. _Europython/Geneva (July 2006): http://codespeak.net/pypy/extradoc/sprintinfo/post-ep2006/report.txt
- .. _Düsseldorf (October 2006): http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2006b/report.txt
- .. _`Leysin (January 2007)`: http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2007/report.txt
- .. _Hildesheim (Feb 2007): http://codespeak.net/pypy/extradoc/sprintinfo/trillke-2007/sprint-report.txt
- .. _`EU report writing sprint`: http://codespeak.net/pypy/extradoc/sprintinfo/trillke-2007/eu-report-sprint-report.txt
- .. _`PyCon/Dallas (Feb 2006)`: http://codespeak.net/pypy/extradoc/sprintinfo/pycon06/sprint-report.txt
+ .. _Hildesheim (Feb 2003): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/HildesheimReport.txt
+ .. _Gothenburg (May 2003): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/gothenburg-2003-sprintreport.txt
+ .. _LovainLaNeuve (June 2003): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/LouvainLaNeuveReport.txt
+ .. _Berlin (Sept 2003): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/BerlinReport.txt
+ .. _Amsterdam (Dec 2003): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/AmsterdamReport.txt
+ .. _Vilnius (Nov 2004): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/vilnius-2004-sprintreport.txt
+ .. _Leysin (Jan 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/LeysinReport.txt
+ .. _PyCon/Washington (March 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/pycon_sprint_report.txt
+ .. _Europython/Gothenburg (June 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ep2005-sprintreport.txt
+ .. _Hildesheim (July 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/hildesheim2005-sprintreport.txt
+ .. _Heidelberg (Aug 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/Heidelberg-report.txt
+ .. _Paris (Oct 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/paris/paris-report.txt
+ .. _Gothenburg (Dec 2005): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/gothenburg-2005/gothenburg-dec2005-sprintreport.txt
+ .. _Mallorca (Jan 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/mallorca/mallorca-sprintreport.txt
+ .. _LouvainLaNeuve (March 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/louvain-la-neuve-2006/report.txt
+ .. _Leysin (April 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/leysin-winter-2006-sprintreport.txt
+ .. _Tokyo (April 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/tokyo/sprint-report.txt
+ .. _Düsseldorf (June 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006/report1.txt
+ .. _Europython/Geneva (July 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/post-ep2006/report.txt
+ .. _Düsseldorf (October 2006): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/ddorf2006b/report.txt
+ .. _`Leysin (January 2007)`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/leysin-winter-2007/report.txt
+ .. _Hildesheim (Feb 2007): https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/trillke-2007/sprint-report.txt
+ .. _`EU report writing sprint`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/trillke-2007/eu-report-sprint-report.txt
+ .. _`PyCon/Dallas (Feb 2006)`: https://bitbucket.org/pypy/extradoc/raw/tip/sprintinfo/pycon06/sprint-report.txt
.. _`Göteborg (November 2007)`: http://morepypy.blogspot.com/2007_11_01_archive.html
.. _`Leysin (January 2008)`: http://morepypy.blogspot.com/2008/01/leysin-winter-sport-sprint-started.html
.. _`Berlin (May 2008)`: http://morepypy.blogspot.com/2008_05_01_archive.html
diff --git a/pypy/doc/stackless.rst b/pypy/doc/stackless.rst
--- a/pypy/doc/stackless.rst
+++ b/pypy/doc/stackless.rst
@@ -211,6 +211,9 @@
.. __: `recursion depth limit`_
+We also do not include any of the recent API additions to Stackless
+Python, like ``set_atomic()``. Contributions welcome.
+
Recursion depth limit
+++++++++++++++++++++
diff --git a/pypy/doc/statistic/index.rst b/pypy/doc/statistic/index.rst
--- a/pypy/doc/statistic/index.rst
+++ b/pypy/doc/statistic/index.rst
@@ -1,3 +1,7 @@
+.. warning::
+
+ This page is no longer updated, of historical interest only.
+
=======================
PyPy Project Statistics
=======================
diff --git a/pypy/doc/stm.rst b/pypy/doc/stm.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/stm.rst
@@ -0,0 +1,284 @@
+======================
+Transactional Memory
+======================
+
+.. contents::
+
+
+This page is about ``pypy-stm``, a special in-development version of
+PyPy which can run multiple independent CPU-hungry threads in the same
+process in parallel. It is side-stepping what is known in the Python
+world as the "global interpreter lock (GIL)" problem.
+
+"STM" stands for Software Transactional Memory, the technique used
+internally. This page describes ``pypy-stm`` from the perspective of a
+user, describes work in progress, and finally gives references to more
+implementation details.
+
+This work was done mostly by Remi Meier and Armin Rigo. Thanks to all
+donors for crowd-funding the work so far! Please have a look at the
+`2nd call for donation`_.
+
+.. _`2nd call for donation`: http://pypy.org/tmdonate2.html
+
+
+Introduction
+============
+
+``pypy-stm`` is a variant of the regular PyPy interpreter. With caveats
+listed below, it should be in theory within 25%-50% slower than a
+regular PyPy, comparing the JIT version in both cases. It is called
+STM for Software Transactional Memory, which is the internal technique
+used (see `Reference to implementation details`_).
+
+What you get in exchange for this slow-down is that ``pypy-stm`` runs
+any multithreaded Python program on multiple CPUs at once. Programs
+running two threads or more in parallel should ideally run faster than
+in a regular PyPy, either now or soon as issues are fixed. In one way,
+that's all there is to it: this is a GIL-less Python, feel free to
+`download and try it`__. However, the deeper idea behind the
+``pypy-stm`` project is to improve what is so far the state-of-the-art
+for using multiple CPUs, which for cases where separate processes don't
+work is done by writing explicitly multi-threaded programs. Instead,
+``pypy-stm`` is pushing forward an approach to *hide* the threads, as
+described below in `atomic sections`_.
+
+
+.. __:
+
+Current status
+==============
+
+**pypy-stm requires 64-bit Linux for now.**
+
+Development is done in the branch `stmgc-c7`_. If you are only
+interested in trying it out, you can download a Ubuntu 12.04 binary
+here__ (``pypy-2.2.x-stm*.tar.bz2``; this version is a release mode,
+but not stripped of debug symbols). The current version supports four
+"segments", which means that it will run up to four threads in parallel,
+in other words it is running a thread pool up to 4 threads emulating normal
+threads.
+
+To build a version from sources, you first need to compile a custom
+version of clang; we recommend downloading `llvm and clang like
+described here`__, but at revision 201645 (use ``svn co -r 201645 ...``
+for all checkouts). Then apply all the patches in `this directory`__:
+they are fixes for the very extensive usage that pypy-stm does of a
+clang-only feature (without them, you get crashes of clang). Then get
+the branch `stmgc-c7`_ of PyPy and run::
+
+ rpython/bin/rpython -Ojit --stm pypy/goal/targetpypystandalone.py
+
+.. _`stmgc-c7`: https://bitbucket.org/pypy/pypy/src/stmgc-c7/
+.. __: http://cobra.cs.uni-duesseldorf.de/~buildmaster/misc/
+.. __: http://clang.llvm.org/get_started.html
+.. __: https://bitbucket.org/pypy/stmgc/src/default/c7/llvmfix/
+
+
+Caveats:
+
+* So far, small examples work fine, but there are still a number of
+ bugs. We're busy fixing them.
+
+* Currently limited to 1.5 GB of RAM (this is just a parameter in
+ `core.h`__). Memory overflows are not detected correctly, so may
+ cause segmentation faults.
+
+* The JIT warm-up time is abysmal (as opposed to the regular PyPy's,
+ which is "only" bad). Moreover, you should run it with a command like
+ ``pypy-stm --jit trace_limit=60000 args...``; the default value of
+ 6000 for ``trace_limit`` is currently too low (6000 should become
+ reasonable again as we improve). Also, in order to produce machine
+ code, the JIT needs to enter a special single-threaded mode for now.
+ This all means that you *will* get very bad performance results if
+ your program doesn't run for *many* seconds for now.
+
+* The GC is new; although clearly inspired by PyPy's regular GC, it
+ misses a number of optimizations for now. Programs allocating large
+ numbers of small objects that don't immediately die, as well as
+ programs that modify large lists or dicts, suffer from these missing
+ optimizations.
+
+* The GC has no support for destructors: the ``__del__`` method is never
+ called (including on file objects, which won't be closed for you).
+ This is of course temporary. Also, weakrefs might appear to work a
+ bit strangely for now (staying alive even though ``gc.collect()``, or
+ even dying but then un-dying for a short time before dying again).
+
+* The STM system is based on very efficient read/write barriers, which
+ are mostly done (their placement could be improved a bit in
+ JIT-generated machine code). But the overall bookkeeping logic could
+ see more improvements (see Statistics_ below).
+
+* You can use `atomic sections`_, but the most visible missing thing is
+ that you don't get reports about the "conflicts" you get. This would
+ be the first thing that you need in order to start using atomic
+ sections more extensively. Also, for now: for better results, try to
+ explicitly force a transaction break just before (and possibly after)
+ each large atomic section, with ``time.sleep(0)``.
+
+* Forking the process is slow because the complete memory needs to be
+ copied manually right now.
+
+* Very long-running processes should eventually crash on an assertion
+ error because of a non-implemented overflow of an internal 29-bit
+ number, but this requires at the very least ten hours --- more
+ probably, several days or more.
+
+.. _`report bugs`: https://bugs.pypy.org/
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/src_stm/stm/core.h
+
+
+
+Statistics
+==========
+
+When a non-main thread finishes, you get statistics printed to stderr,
+looking like that::
+
+ thread 0x7f73377fe600:
+ outside transaction 42182 0.506 s
+ run current 85466 0.000 s
+ run committed 34262 3.178 s
+ run aborted write write 6982 0.083 s
+ run aborted write read 550 0.005 s
+ run aborted inevitable 388 0.010 s
+ run aborted other 0 0.000 s
+ wait free segment 0 0.000 s
+ wait write read 78 0.027 s
+ wait inevitable 887 0.490 s
+ wait other 0 0.000 s
+ bookkeeping 51418 0.606 s
+ minor gc 162970 1.135 s
+ major gc 1 0.019 s
+ sync pause 59173 1.738 s
+ spin loop 129512 0.094 s
+
+The first number is a counter; the second number gives the associated
+time (the amount of real time that the thread was in this state; the sum
+of all the times should be equal to the total time between the thread's
+start and the thread's end). The most important points are "run
+committed", which gives the amount of useful work, and "outside
+transaction", which should give the time spent e.g. in library calls
+(right now it seems to be a bit larger than that; to investigate).
+Everything else is overhead of various forms. (Short-, medium- and
+long-term future work involves reducing this overhead :-)
+
+These statistics are not printed out for the main thread, for now.
+
+
+Atomic sections
+===============
+
+While one of the goal of pypy-stm is to give a GIL-free but otherwise
+unmodified Python, the other goal is to push for a better way to use
+multithreading. For this, you (as the Python programmer) get an API
+in the ``__pypy__.thread`` submodule:
+
+* ``__pypy__.thread.atomic``: a context manager (i.e. you use it in
+ a ``with __pypy__.thread.atomic:`` statement). It runs the whole
+ block of code without breaking the current transaction --- from
+ the point of view of a regular CPython/PyPy, this is equivalent to
+ saying that the GIL will not be released at all between the start and
+ the end of this block of code.
+
+The obvious usage is to use atomic blocks in the same way as one would
+use locks: to protect changes to some shared data, you do them in a
+``with atomic`` block, just like you would otherwise do them in a ``with
+mylock`` block after ``mylock = thread.allocate_lock()``. This allows
+you not to care about acquiring the correct locks in the correct order;
+it is equivalent to having only one global lock. This is how
+transactional memory is `generally described`__: as a way to efficiently
+execute such atomic blocks, running them in parallel while giving the
+illusion that they run in some serial order.
+
+.. __: http://en.wikipedia.org/wiki/Transactional_memory
+
+However, the less obvious intended usage of atomic sections is as a
+wide-ranging replacement of explicit threads. You can turn a program
+that is not multi-threaded at all into a program that uses threads
+internally, together with large atomic sections to keep the behavior
+unchanged. This capability can be hidden in a library or in the
+framework you use; the end user's code does not need to be explicitly
+aware of using threads. For a simple example of this, see
+`transaction.py`_ in ``lib_pypy``. The idea is that if you have a
+program where the function ``f(key, value)`` runs on every item of some
+big dictionary, you can replace the loop with::
+
+ for key, value in bigdict.items():
+ transaction.add(f, key, value)
+ transaction.run()
+
+This code runs the various calls to ``f(key, value)`` using a thread
+pool, but every single call is done in an atomic section. The end
+result is that the behavior should be exactly equivalent: you don't get
+any extra multithreading issue.
+
+This approach hides the notion of threads from the end programmer,
+including all the hard multithreading-related issues. This is not the
+first alternative approach to explicit threads; for example, OpenMP_ is
+one. However, it is one of the first ones which does not require the
+code to be organized in a particular fashion. Instead, it works on any
+Python program which has got latent, imperfect parallelism. Ideally, it
+only requires that the end programmer identifies where this parallelism
+is likely to be found, and communicates it to the system, using for
+example the ``transaction.add()`` scheme.
+
+.. _`transaction.py`: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/lib_pypy/transaction.py
+.. _OpenMP: http://en.wikipedia.org/wiki/OpenMP
+
+==================
+
+Other APIs in pypy-stm:
+
+* ``__pypy__.thread.getsegmentlimit()``: return the number of "segments"
+ in this pypy-stm. This is the limit above which more threads will not
+ be able to execute on more cores. (Right now it is limited to 4 due
+ to inter-segment overhead, but should be increased in the future. It
+ should also be settable, and the default value should depend on the
+ number of actual CPUs.)
+
+* ``__pypy__.thread.exclusive_atomic``: same as ``atomic``, but
+ raises an exception if you attempt to nest it inside another
+ ``atomic``.
+
+* ``__pypy__.thread.signals_enabled``: a context manager that runs
+ its block with signals enabled. By default, signals are only
+ enabled in the main thread; a non-main thread will not receive
+ signals (this is like CPython). Enabling signals in non-main threads
+ is useful for libraries where threads are hidden and the end user is
+ not expecting his code to run elsewhere than in the main thread.
+
+Note that all of this API is (or will be) implemented in a regular PyPy
+too: for example, ``with atomic`` will simply mean "don't release the
+GIL" and ``getsegmentlimit()`` will return 1.
+
+==================
+
+
+Reference to implementation details
+===================================
+
+The core of the implementation is in a separate C library called stmgc_,
+in the c7_ subdirectory. Please see the `README.txt`_ for more
+information. In particular, the notion of segment is discussed there.
+
+.. _stmgc: https://bitbucket.org/pypy/stmgc/src/default/
+.. _c7: https://bitbucket.org/pypy/stmgc/src/default/c7/
+.. _`README.txt`: https://bitbucket.org/pypy/stmgc/raw/default/c7/README.txt
+
+PyPy itself adds on top of it the automatic placement of read__ and write__
+barriers and of `"becomes-inevitable-now" barriers`__, the logic to
+`start/stop transactions as an RPython transformation`__ and as
+`supporting`__ `C code`__, and the support in the JIT (mostly as a
+`transformation step on the trace`__ and generation of custom assembler
+in `assembler.py`__).
+
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/readbarrier.py
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/memory/gctransform/stmframework.py
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/inevitable.py
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/jitdriver.py
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/src_stm/stmgcintf.h
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/translator/stm/src_stm/stmgcintf.c
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/jit/backend/llsupport/stmrewrite.py
+.. __: https://bitbucket.org/pypy/pypy/raw/stmgc-c7/rpython/jit/backend/x86/assembler.py
diff --git a/pypy/doc/tool/makeref.py b/pypy/doc/tool/makeref.py
--- a/pypy/doc/tool/makeref.py
+++ b/pypy/doc/tool/makeref.py
@@ -1,3 +1,12 @@
+
+# patch sys.path so that this script can be executed standalone
+import sys
+from os.path import abspath, dirname
+# this script is assumed to be at pypy/doc/tool/makeref.py
+path = dirname(abspath(__file__))
+path = dirname(dirname(dirname(path)))
+sys.path.insert(0, path)
+
import py
import pypy
@@ -51,8 +60,11 @@
lines.append(".. _`%s`:" % linkname)
lines.append(".. _`%s`: %s" %(linknamelist[-1], linktarget))
- lines.append('')
- reffile.write("\n".join(lines))
+ content = ".. This file is generated automatically by makeref.py script,\n"
+ content += " which in turn is run manually.\n\n"
+ content += "\n".join(lines) + "\n"
+ reffile.write(content, mode="wb")
+
print "wrote %d references to %r" %(len(lines), reffile)
#print "last ten lines"
#for x in lines[-10:]: print x
diff --git a/pypy/doc/translation.rst b/pypy/doc/translation.rst
--- a/pypy/doc/translation.rst
+++ b/pypy/doc/translation.rst
@@ -380,7 +380,7 @@
The RPython Typer
=================
-https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/
+https://bitbucket.org/pypy/pypy/src/default/rpython/rtyper/
The RTyper is the first place where the choice of backend makes a
difference; as outlined above we are assuming that ANSI C is the target.
@@ -603,7 +603,7 @@
- using the `Boehm-Demers-Weiser conservative garbage collector`_
- using one of our custom `exact GCs implemented in RPython`_
-.. _`Boehm-Demers-Weiser conservative garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
+.. _`Boehm-Demers-Weiser conservative garbage collector`: http://hboehm.info/gc/
.. _`exact GCs implemented in RPython`: garbage_collection.html
Almost all application-level Python code allocates objects at a very fast
@@ -621,7 +621,7 @@
The C Back-End
==============
-https://bitbucket.org/pypy/pypy/src/default/pypy/translator/c/
+https://bitbucket.org/pypy/pypy/src/default/rpython/translator/c/
GenC is usually the most actively maintained backend -- everyone working on
PyPy has a C compiler, for one thing -- and is usually where new features are
diff --git a/pypy/doc/whatsnew-2.3.0.rst b/pypy/doc/whatsnew-2.3.0.rst
new file mode 100644
--- /dev/null
+++ b/pypy/doc/whatsnew-2.3.0.rst
@@ -0,0 +1,154 @@
+=======================
+What's new in PyPy 2.2+
+=======================
+
+.. this is a revision shortly after release-2.2.x
+.. startrev: 4cd1bc8b3111
+
+.. branch: release-2.2.x
+
+.. branch: numpy-newbyteorder
+Clean up numpy types, add newbyteorder functionality
+
+.. branch: windows-packaging
+Package tk/tcl runtime with win32
+
+.. branch: armhf-singlefloat
+JIT support for singlefloats on ARM using the hardfloat ABI
+
+.. branch: voidtype_strformat
+Better support for record numpy arrays
+
+.. branch: osx-eci-frameworks-makefile
+OSX: Ensure frameworks end up in Makefile when specified in External compilation info
+
+.. branch: less-stringly-ops
+Use subclasses of SpaceOperation instead of SpaceOperator objects.
+Random cleanups in flowspace and annotator.
+
+.. branch: ndarray-buffer
+adds support for the buffer= argument to the ndarray ctor
+
+.. branch: better_ftime_detect2
+On OpenBSD do not pull in libcompat.a as it is about to be removed.
+And more generally, if you have gettimeofday(2) you will not need ftime(3).
+
+.. branch: timeb_h
+Remove dependency upon <sys/timeb.h> on OpenBSD. This will be disappearing
+along with libcompat.a.
+
+.. branch: OlivierBlanvillain/fix-3-broken-links-on-pypy-published-pap-1386250839215
+Fix 3 broken links on PyPy published papers in docs.
+
+.. branch: jit-ordereddict
+
+.. branch: refactor-str-types
+Remove multimethods on str/unicode/bytearray and make the implementations share code.
+
+.. branch: remove-del-from-generatoriterator
+Speed up generators that don't yield inside try or wait blocks by skipping
+unnecessary cleanup.
+
+.. branch: annotator
+Remove FlowObjSpace.
+Improve cohesion between rpython.flowspace and rpython.annotator.
+
+.. branch: detect-immutable-fields
+mapdicts keep track of whether or not an attribute is every assigned to
+multiple times. If it's only assigned once then an elidable lookup is used when
+possible.
+
+.. branch: precompiled-headers
+Create a Makefile using precompiled headers for MSVC platforms.
+The downside is a messy nmake-compatible Makefile. Since gcc shows minimal
+speedup, it was not implemented.
+
+.. branch: camelot
+With a properly configured 256-color terminal (TERM=...-256color), the
+Mandelbrot set shown during translation now uses a range of 50 colours.
+Essential!
+
+.. branch: NonConstant
+Simplify implementation of NonConstant.
+
+.. branch: array-propagate-len
+Kill some guards and operations in JIT traces by adding integer bounds
+propagation for getfield_(raw|gc) and getarrayitem_(raw|gc).
+
+.. branch: optimize-int-and
+Optimize away INT_AND with constant mask of 1s that fully cover the bitrange
+of other operand.
+
+.. branch: bounds-int-add-or
+Propagate appropriate bounds through INT_(OR|XOR|AND) operations if the
+operands are positive to kill some guards
+
+.. branch: remove-intlong-smm
+kills int/long/smalllong/bool multimethods
+
+.. branch: numpy-refactor
+Cleanup micronumpy module
+
+.. branch: int_w-refactor
+In a lot of places CPython allows objects with __int__ and __float__ instead of actual ints and floats, while until now pypy disallowed them. We fix it by making space.{int_w,float_w,etc.} accepting those objects by default, and disallowing conversions only when explicitly needed.
+
+.. branch: test-58c3d8552833
+Fix for getarrayitem_gc_pure optimization
+
+.. branch: simple-range-strategy
+Implements SimpleRangeListStrategy for case range(n) where n is a positive number.
+Makes some traces nicer by getting rid of multiplication for calculating loop counter
+and propagates that n > 0 further to get rid of guards.
+
+.. branch: popen-pclose
+Provide an exit status for popen'ed RFiles via pclose
+
+.. branch: stdlib-2.7.6
+Update stdlib to v2.7.6
+
+.. branch: virtual-raw-store-load
+Support for virtualizing raw_store/raw_load operations
+
+.. branch: refactor-buffer-api
+Separate the interp-level buffer API from the buffer type exposed to
+app-level. The `Buffer` class is now used by `W_MemoryView` and
+`W_Buffer`, which is not present in Python 3. Previously `W_Buffer` was
+an alias to `Buffer`, which was wrappable itself.
+
+.. branch: improve-consecutive-dict-lookups
+Improve the situation when dict lookups of the same key are performed in a chain
+
+.. branch: add_PyErr_SetFromErrnoWithFilenameObject_try_2
+.. branch: test_SetFromErrnoWithFilename_NULL
+.. branch: test_SetFromErrnoWithFilename__tweaks
+
+.. branch: refactor_PyErr_SetFromErrnoWithFilename
+Add support for PyErr_SetFromErrnoWithFilenameObject to cpyext
+
+.. branch: win32-fixes4
+fix more tests for win32
+
+.. branch: latest-improve-doc
+Fix broken links in documentation
+
+.. branch: ast-issue1673
+fix ast classes __dict__ are always empty problem and fix the ast deepcopy issue when
+there is missing field
+
+.. branch: issue1514
+Fix issues with reimporting builtin modules
+
+.. branch: numpypy-nditer
+Implement the core of nditer, without many of the fancy flags (external_loop, buffered)
+
+.. branch: numpy-speed
+Separate iterator from its state so jit can optimize better
+
+.. branch: numpy-searchsorted
+Implement searchsorted without sorter kwarg
+
+.. branch: openbsd-lib-prefix
+add 'lib' prefix to link libraries on OpenBSD
+
+.. branch: small-unroll-improvements
+Improve optimization of small allocation-heavy loops in the JIT
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
@@ -1,119 +1,11 @@
=======================
-What's new in PyPy 2.2+
+What's new in PyPy 2.3+
More information about the pypy-commit
mailing list