[pypy-svn] r71641 - pypy/trunk/pypy/doc

[arigo at codespeak.net]

Author: arigo
Date: Tue Mar  2 16:10:36 2010
New Revision: 71641

Modified:
   pypy/trunk/pypy/doc/faq.txt
   pypy/trunk/pypy/doc/project-ideas.txt
Log:
Updates.


Modified: pypy/trunk/pypy/doc/faq.txt
==============================================================================
--- pypy/trunk/pypy/doc/faq.txt	(original)
+++ pypy/trunk/pypy/doc/faq.txt	Tue Mar  2 16:10:36 2010
@@ -56,10 +56,12 @@
 OS X and mostly works under Windows too (but is tested there less
 extensively). PyPy needs a CPython running on the target platform to
 bootstrap, as cross compilation is not really meant to work yet.
-At the moment you need CPython 2.4 (with ctypes 0.9.9.6 or newer) or
-CPython 2.5 for the translation process.
+At the moment you need CPython 2.4 (with ctypes) or CPython 2.5 or 2.6
+for the translation process.
 
-PyPy also basically works in a 64-bit Linux environment.
+PyPy also basically works in a 64-bit Linux environment, but
+*it requires a 32-bit Intel CPU* for the JIT right now.  (It works
+fine in a 32-bit chroot of an Intel 64.)
 
 ------------------------------------------------
 Which Python version (2.x?) does PyPy implement?

Modified: pypy/trunk/pypy/doc/project-ideas.txt
==============================================================================
--- pypy/trunk/pypy/doc/project-ideas.txt	(original)
+++ pypy/trunk/pypy/doc/project-ideas.txt	Tue Mar  2 16:10:36 2010
@@ -23,35 +23,41 @@
 --------------------------------
 
 PyPy's Just-In-Time compiler relies on backends for actual code
-generation.  Right now we are working on the ``pyjitpl5`` branch, which
-is not stable.  Working on the JIT backends should be soon possible.
-Open ideas are to write a backend for AMD64 (Intel 64); or .NET or
-Java (requires porting the JIT frontend to ootype too, which is not too
-hard); or trying to use LLVM-JIT.
+generation.  We have so far a 32-bit Intel backend, and a CLI one.  Open
+ideas are to write a backend for **Intel 64** (AMD64); or a backend for
+Java; or trying again to use LLVM-JIT (which I do not really recommend).
 
 CTypes
 ------
 
 Support ctypes on more backends.  Right now ctypes is supported only
-when compiling PyPy to C.  A nice project would be to support it when
+when compiling PyPy to C, and there is a bit of unfinished work to
+support it on **Intel 64.**  A nice project would be to support it when
 compiling to .NET or the JVM. That's not too hard, the only thing needed
 is to port a small module that does the actual invocation of external
-libraries (a related project would be to port this module to Jython or
-IronPython to get support for ctypes there).
+libraries (a related project is to port this module to Jython or
+IronPython to get support for ctypes there, which is something that was
+tried but not finished as far as I know).
 
 
 .. _distribution:
 .. _persistence:
 
-Experiment with distribution and persistence
---------------------------------------------
+Extensions of the Python language
+---------------------------------
+
++----------------------------------------------------------------------+
+| :NOTE:                                                               |
+|                                                                      |
+|   The ideas in this paragraph are marked as "experimental".  We may  |
+|   or may not be interested in helping you out.  You are warned :-)   |
+|                                                                      |
++----------------------------------------------------------------------+
 
 One of the advantages of PyPy's implementation is that the Python-level type
 of an object and its implementation are completely independent.  This should
 allow a much more intuitive interface to, for example, objects that are backed
-by a persistent store.
-
-The `transparent proxy`_ objects are a key step in this
+by a persistent store.  The `transparent proxy`_ objects are a key step in this
 direction; now all that remains is to implement the interesting bits :-)
 
 An example project might be to implement functionality akin to the `ZODB's
@@ -61,15 +67,22 @@
 Another example would be to implement a multi-CPU extension that internally
 uses several processes and uses transparent proxies to share object views.
 
+Other ideas are to do something interesting with sandboxing_; or to
+work more on the Stackless_ features (e.g. integrate it with the JIT);
+or revive the logic object space, which tried to bring unification-like
+features to Python.
+
+.. _sandboxing: sandbox.html
+.. _Stackless: stackless.html
+
 
-Various Ideas
--------------
+Other languages
+---------------
 
-- improve one of the existing interpreters (e.g. the Prolog, the Scheme or
-  the JavaScript interpreter or the Smalltalk VM), or start a new one
+Improve one of the `existing interpreters`__, or start a new one.
+Experiment with the JIT compiler generator.
 
-- revive the logic object space, which tried to bring unification-like
-  features to Python
+.. __: http://codespeak.net/svn/pypy/lang/
 
 
 Or else...