[pypy-commit] pypy default: Develop and use other potential ideas
arigo
noreply at buildbot.pypy.org
Wed Aug 21 13:19:08 CEST 2013
Author: Armin Rigo <arigo at tunes.org>
Branch:
Changeset: r66278:c6dd660901e1
Date: 2013-08-21 13:18 +0200
http://bitbucket.org/pypy/pypy/changeset/c6dd660901e1/
Log: Develop and use other potential ideas
diff --git a/pypy/doc/windows.rst b/pypy/doc/windows.rst
--- a/pypy/doc/windows.rst
+++ b/pypy/doc/windows.rst
@@ -262,10 +262,9 @@
casted to one type or the other really have 32 and 64 bits respectively,
on Win64.
-Once these basic tests work, you need to review ``pypy/module/*/`` for
-usages of ``rffi.LONG`` versus ``lltype.Signed``. Some other places
-might need a similar review too, like ``rpython/rlib/``. Important: at
-this point the goal would not be to run the tests in these directories!
+Once these basic tests work, you need to review ``rpython/rlib/`` for
+usages of ``rffi.LONG`` versus ``lltype.Signed``. Important: at this
+point the goal would not be to run the tests in these directories!
Doing so would create more confusion to work around. Instead, the goal
would be to fix some ``LONG-versus-Signed`` issues, and if necessary
make sure that the tests still run fine e.g. on Win32. There was some
@@ -274,9 +273,27 @@
again, we should only make sure that the tests work on Win32, and that
PyPy translates on Win64 and then run the (standard lib-python) tests.
-This should get you a translation of PyPy with ``-O2``, i.e. without the
-JIT. Check carefully the warnings of the C compiler at the end. I
-think that MSVC is "nice" in the sense that by default a lot of
-mismatches of integer sizes are reported as warnings.
+The goal here is to get a translation of PyPy with ``-O2`` with a
+minimal set of modules, starting with ``--no-allworkingmodules``. Check
+carefully the warnings of the C compiler at the end. I think that MSVC
+is "nice" in the sense that by default a lot of mismatches of integer
+sizes are reported as warnings.
-This should be your first long-term goal. Happy hacking :-)
+Why first try to translate when the modules ``pypy/module/*/`` may need
+fixes too? The idea is that you really need to get a minimal translated
+PyPy, with the minimal amount of modules (this used to be with the
+``--translationmodules`` option, if it still works). Then we have a
+Python interpreter, namely this minimal PyPy, which can run a full
+translation and which has the "correct" setting of ``sys.maxint`` and
+64-bit integers. So once we get this minimal PyPy we can use it to
+translate a complete PyPy with less troubles. (We still need to review
+e.g. ``rffi.LONG`` / ``lltype.Signed`` issues, obviously.)
+
+Alternatively, you might try to hack CPython to have ints store a 64-bit
+number and ``sys.maxint`` be 2**63-1. This might be easier, and work as
+long as you don't try too hard to crash it because of the precision loss
+that undoubtedly occurs everywhere. Running the translation with such a
+hacked CPython would give the same effect as running it on top of the
+minimal PyPy described above.
+
+Happy hacking :-)
More information about the pypy-commit
mailing list