[pypy-svn] r55620 - pypy/dist/pypy/doc

[arigo at codespeak.net]

Author: arigo
Date: Fri Jun  6 09:38:14 2008
New Revision: 55620

Modified:
   pypy/dist/pypy/doc/_ref.txt
   pypy/dist/pypy/doc/faq.txt
Log:
Update some entries of the FAQ.


Modified: pypy/dist/pypy/doc/_ref.txt
==============================================================================
--- pypy/dist/pypy/doc/_ref.txt	(original)
+++ pypy/dist/pypy/doc/_ref.txt	Fri Jun  6 09:38:14 2008
@@ -10,6 +10,7 @@
 .. _`pypy/annotation/model.py`: ../../pypy/annotation/model.py
 .. _`bin/`: ../../pypy/bin
 .. _`config/`: ../../pypy/config
+.. _`pypy/config/pypyoption.py`: ../../pypy/config/pypyoption.py
 .. _`doc/`: ../../pypy/doc
 .. _`doc/config/`: ../../pypy/doc/config
 .. _`doc/discussion/`: ../../pypy/doc/discussion

Modified: pypy/dist/pypy/doc/faq.txt
==============================================================================
--- pypy/dist/pypy/doc/faq.txt	(original)
+++ pypy/dist/pypy/doc/faq.txt	Fri Jun  6 09:38:14 2008
@@ -54,9 +54,7 @@
 At the moment you need CPython 2.4 (with ctypes 0.9.9.6 or newer) or
 CPython 2.5 for the translation process.
 
-Currently (due to time restrictions) we are not trying hard to support
-PyPy in a 64 bit environment.  While things seem to mostly work, a few
-modules won't work on 64 bit machines, such as ``bz2``.
+PyPy also basically works in a 64-bit Linux environment.
 
 ------------------------------------------------
 Which Python version (2.x?) does PyPy implement?
@@ -64,10 +62,8 @@
 
 PyPy currently aims to be fully compatible with Python 2.4. That means that
 it contains the standard library of Python 2.4 and that it supports 2.4
-features (such as decorators) but not the 2.5 features (with statement, the ternary
-operator).  The 2.5 features will probably be eventually supported, the most
-important reason why nobody is working on them is that we did not promise this
-to the EU and have currently enough other tasks.
+features (such as decorators).  The 2.5 features (e.g. the ``with`` statement,
+the ternary operator) are in progress.
 
 .. _threading:
 
@@ -75,26 +71,24 @@
 Do threads work?  What are the modules that work?
 -------------------------------------------------
 
-Operating system-level threads work in a limited way. If you enable the ``thread``
-module then PyPy will get support for GIL based threading. One limitation is
-that not that many IO operations actually release the GIL, which reduces the
-usefulness of threads. On the other hand, PyPy fully supports `stackless-like
+Operating system-level threads basically work. If you enable the ``thread``
+module then PyPy will get support for GIL based threading.
+Note that PyPy also fully supports `stackless-like
 microthreads`_ (although both cannot be mixed yet).
 
 As for other modules: The general rule of thumb is that pure-Python modules
-work, C extension modules don't. Some of the C extension modules of the standard
+work, C extension modules don't. However, many of the C extension modules
+of the standard
 library have been re-implemented in pure Python or as a mixed module (for some
-there were also older pure-Python versions available). A (probably incomplete)
-list:
+there were also older pure-Python versions available). The list of supported
+modules can be found as follows:
 
- * pure Python implementations: binascii, cmath, collections, cPickle,
-   cStringIO, datetime, functional, imp, itertools, md5, operator,
-   sha, struct
-
- * mixed module implementations: exceptions, sys, __builtin__, posix
-   _codecs, gc, _weakref, array, marshal, errno, math, _sre,  parser, symbol,
-   _random, socket, unicodedata, mmap, fcntl, time, select, bz2, crypt,
-   signal, readline (incomplete)
+ * pure Python implementations: all the modules found in the `pypy/lib/`_
+   directory
+
+ * mixed module implementations: all the modules listed in
+   ``essential_modules``, ``default_modules`` and ``working_modules``
+   in `pypy/config/pypyoption.py`_.
 
 
 .. _`stackless-like microthreads`: stackless.html
@@ -110,8 +104,7 @@
 rely heavily on CPython's C API which contains a lot of implementation details
 like reference counting, exact C-level object implementation and layout etc.
 
-Although if your module uses ctypes rather than C-level code, there is
-a hope -- you can try to write a mixed module (see next question).
+A module based on ctypes is a different matter -- we support these nowadays.
 
 The long-term answer might be different.  In principle, it should be possible
 for PyPy to support the CPython C API (or at least a large subset of its
@@ -122,11 +115,10 @@
 How do I write extension modules for PyPy?
 ------------------------------------------
 
-PyPy extension modules are written in the form of `mixed modules`_, so
-called because they can contain a mixture of compiled and interpreted
-Python code.  At the moment they all need to be translated together with the rest of PyPy.
+See `Writing extension modules for PyPy`__.
+
+.. __: extending.html
 
-.. _`mixed modules`: coding-guide.html#mixed-module-mechanism
 
 .. _`slower than CPython`:
 .. _`how fast is pypy`:
@@ -141,17 +133,16 @@
 CPython, the version of PyPy that still runs on top of CPython is slower
 by a factor of 2000. The first translated version was roughly 300 times
 slower than CPython, a number which we decreased release after release
-to the current point, where PyPy is only between 1.7 and 4 times slower
-than CPython.  Note that the speed heavily depends on the options
-enabled at compile time.
+to the current point, where PyPy is somewhere between 1 and 2, i.e. it
+is as fast as CPython in some cases, and up to twice as slow in other
+cases.  Note that the speed heavily depends on the options enabled at
+compile time.
 
 The integration of the work on the Just-In-Time compiler has just
-started; it can be `manually enabled`_ and gives good results on
-functions doing integer arithmetic (60 times faster than CPython,
-i.e. within 20% of recoding the function in C and compiling with ``gcc``
-without optimizations).
+started; it is not yet ready enough to give useful speed-ups.  See
+status__.
 
-.. _`manually enabled`: jit/status.html
+.. __: jit/status.html
 
 
 .. _`prolog and javascript`: