[pypy-svn] r34320 - pypy/dist/pypy/doc
cfbolz at codespeak.net
cfbolz at codespeak.net
Tue Nov 7 13:39:11 CET 2006
Author: cfbolz
Date: Tue Nov 7 13:39:10 2006
New Revision: 34320
Modified:
pypy/dist/pypy/doc/project-ideas.txt
Log:
(cfbolz, mwh, maciek, ?):
update project ideas a bit
Modified: pypy/dist/pypy/doc/project-ideas.txt
==============================================================================
--- pypy/dist/pypy/doc/project-ideas.txt (original)
+++ pypy/dist/pypy/doc/project-ideas.txt Tue Nov 7 13:39:10 2006
@@ -1,70 +1,22 @@
Independent project ideas in PyPy
=================================
-PyPy allows experimentation in many directions. This page is meant to
-collect some ideas of things to try. If you are a student you can
-also get inspired for a proposal for our new `Summer of PyPy`_ campaign:
-you get a mentor and good funding of travel and accomodation for our
-sprints.
+PyPy allows experimentation in many directions -- indeed facilitating
+experimentation in language implementation was one of the main motivations for
+the project. This page is meant to collect some ideas of things to try.
+
+If you are a student, maybe you will be inspired to make a proposal for our
+`Summer of PyPy`_ campaign: you will have an experienced PyPy developer as a
+mentor and be invited to attend one or two of our sprints, with travel and
+accomodation costs refunded.
-Feel free to suggest new ideas and discuss them on IRC or the pypy-dev
-list (see the contact_ page).
+Feel free to suggest new ideas and discuss them in #pypy on the freenode IRC
+network or the pypy-dev mailing list (see the contact_ page).
-----------
.. contents::
-Extension modules
------------------
-
-Rewrite one or several CPython extension modules to be based on **ctypes**
-(newly integrated in Python 2.5): this is generally useful for Python
-developers, and it is now the best path to write extension modules that are
-compatible with both CPython and PyPy. This is done with the `extension
-compiler`_ component of PyPy, which will likely require some attention as
-well.
-
-Modules where some work is already done:
-
-* ``_socket``, ``os``, ``select`` (unfinished yet, feel free to help;
- see e.g. http://codespeak.net/svn/pypy/dist/pypy/module/_socket/).
-
-* SSL for socket, ``bz2``, ``fcntl``, ``mmap`` and ``time``: part of the
- Summer of Code project of Lawrence Oluyede
- (http://codespeak.net/svn/user/rhymes/).
-
-You are free to pick any other CPython module, either standard or third-party
-(if relatively well-known). Note that some modules exist in a ctypes version
-already, which would be a good start for porting them to PyPy's extension
-compiler. We'd particularly appreciate ``readline`` :-)
-
-Numeric/NumPy/numarray support
-------------------------------
-
-At the EuroPython sprint, some work was done on making RPython's annotator
-recognise Numeric arrays, with the goal of allowing programs using them to be
-efficiently translated. It would be a reasonably sized project to finish this
-work, i.e. allow RPython programs to use some Numeric facilities.
-Additionally, these facilities could be exposed to applications interpreted by
-the translated PyPy interpreter.
-
-Start or improve a back-end
----------------------------
-
-PyPy has complete, or nearly so, back-ends for C, LLVM and CLI/.NET and
-partial backends for Common Lisp and Squeak. It would be an interesting
-project to improve either of these partial backends, or start one for another
-platform -- the most obvious of which would be the **Java** Virtual Machine.
-
-Write a new front end
----------------------
-
-Write an interpreter for **another dynamic language** in the PyPy framework.
-For example, a Javascript interpreter would be suitable. Ruby too (though
-the latter is probably more than two months of work). Or Scheme, or... etc.
-
-We have a prototype `Prolog interpreter`_ :-)
-
Experiment with optimizations
-----------------------------
@@ -86,6 +38,38 @@
* dictionaries specialized for string-only keys.
+
+
+
+Start or improve a back-end
+---------------------------
+
+PyPy has complete, or nearly so, back-ends for C, LLVM and CLI/.NET and
+partial backends for Common Lisp, Squeak and the JVM. It would be an
+interesting project to improve either of these partial backends, or start one
+for another platform (objective C comes to mind).
+
+Improve one of the JIT back-ends
+--------------------------------
+
+PyPy's Just-In-Time compiler relies on two assembler backends for actual code
+generation: One for PowerPC and one for i386. Those two backends so far are
+mostly working, but nearly no effort was made to make them produce good
+assembler. This is an area where quite some improvements could be made.
+Another idea in a similar vein would be to use LLVM to re-compile functions
+that are particularly often used (LLVM cannot be used for *all* code
+generation, since it can only work on function at a time).
+
+Write a new front end
+---------------------
+
+Write an interpreter for **another dynamic language** in the PyPy framework.
+For example, a Scheme interpreter would be suitable. Ruby too (though
+the latter is probably more than two months of work), or Lua, or ...
+
+We have a somewhat useable `Prolog interpreter`_ and the beginnings of a
+`JavaScript interpreter`_
+
Investigate restricted execution models
---------------------------------------
@@ -101,14 +85,59 @@
objects to be tagged and tracked. The translation of PyPy would also be a
good place to insert e.g. systematic checks around all system calls.
-Write a new object space
-------------------------
-Write **new object spaces** adding features like transparent or
-semi-transparent distribution of a program across several machines, and/or
-persistence (pickling of program state). This could typically be based on
-"proxy" objects, behaving as transparent links to objects located on other
-machines. Read more about `object spaces`_...
+Experiment with distribution and persistence
+--------------------------------------------
+
+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, or whose implementation lives on a remote server.
+
+The recently added "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
+Persistent class`_, without the need for the _p_changed hacks, and in pure
+Python code.
+
+Numeric/NumPy/numarray support
+------------------------------
+
+At the EuroPython sprint, some work was done on making RPython's annotator
+recognise Numeric arrays, with the goal of allowing programs using them to be
+efficiently translated. It would be a reasonably sized project to finish this
+work, i.e. allow RPython programs to use some Numeric facilities.
+Additionally, these facilities could be exposed to applications interpreted by
+the translated PyPy interpreter.
+
+
+
+Extension modules
+-----------------
+
+Rewrite one or several CPython extension modules to be based on **ctypes**
+(newly integrated in Python 2.5): this is generally useful for Python
+developers, and it is now the best path to write extension modules that are
+compatible with both CPython and PyPy. This is done with the `extension
+compiler`_ component of PyPy, which will likely require some attention as
+well.
+
+Modules where some work is already done:
+
+* ``_socket``, ``os``, ``select`` (unfinished yet, feel free to help;
+ see e.g. http://codespeak.net/svn/pypy/dist/pypy/module/_socket/).
+
+* SSL for socket, ``bz2``, ``fcntl``, ``mmap`` and ``time``: part of the
+ Summer of Code project of Lawrence Oluyede
+ (http://codespeak.net/svn/user/rhymes/).
+
+You are free to pick any other CPython module, either standard or third-party
+(if relatively well-known). Note that some modules exist in a ctypes version
+already, which would be a good start for porting them to PyPy's extension
+compiler. We'd particularly appreciate ``readline`` :-)
+
+
Extend py.execnet to a peer-to-peer model
-----------------------------------------
@@ -146,6 +175,7 @@
.. _`py.test`: http://codespeak.net/py/current/doc/test.html
.. _`py.execnet`: http://codespeak.net/py/current/doc/execnet.html
.. _`Prolog interpreter`: http://codespeak.net/svn/user/cfbolz/hack/prolog/interpreter
+.. _`JavaScript interpreter`: ../../../pypy/lang/js
.. _`extension compiler`: extcompiler.html
.. _`object spaces`: objspace.html
.. _`code templating solution`: http://codespeak.net/svn/pypy/extradoc/soc-2006/code-templating.txt
@@ -154,3 +184,4 @@
.. _contact: contact.html
.. _`pypy-dev mailing list`: http://codespeak.net/mailman/listinfo/pypy-dev
.. _`Summer of PyPy`: summer-of-pypy.html
+.. _`ZODB's Persistent class`: http://www.zope.org/Documentation/Books/ZDG/current/Persistence.stx
More information about the Pypy-commit
mailing list