[pypy-svn] r49809 - pypy/extradoc/planning/roadmap

cfbolz at codespeak.net cfbolz at codespeak.net
Fri Dec 14 20:30:21 CET 2007


Author: cfbolz
Date: Fri Dec 14 20:30:19 2007
New Revision: 49809

Added:
   pypy/extradoc/planning/roadmap/goal_cpython_replacement.txt
      - copied, changed from r49806, pypy/extradoc/planning/roadmap/cpython_replacement.txt
   pypy/extradoc/planning/roadmap/task_cpython_api.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_gui_support.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_manual_optimizations.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_modules_3rdparty.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_modules_rffi.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_multi_platform.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_optimize_jit.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_parser_cleanup.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_refactor_jit.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_separate_compilation.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_wrapper_generator.txt   (contents, props changed)
Removed:
   pypy/extradoc/planning/roadmap/cpython_replacement.txt
Log:
make one file per task, to allow easier parallel working on them. Also we can
add other goals which include certain tasks.


Added: pypy/extradoc/planning/roadmap/task_cpython_api.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_cpython_api.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,7 @@
+Providing the CPython C-API
+===========================
+Separate compilation would be interesting ground work for a try to compile
+cpython modules with a pypy-supplied Python.h file and link them to pypy. This
+would require writing a lot of new functions (for the CPython API), though.
+Also it is not clear how large the expected speed impact would be (because of 
+e.g. pinning).

Added: pypy/extradoc/planning/roadmap/task_gui_support.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_gui_support.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,11 @@
+Support a GUI
+=============
+
+One of the C extension modules that we need to have in order to get
+traction is support for one of the multi-platform GUI toolkits. The
+choice is probably between gtk (in use by olpc and others), Qt (written in c++,
+using SIP to get a cpython package) and wxWindows, with Tkinter as a
+possible third. Someone with more understanding of the Python
+community than us should make the pick. Which one would bring more
+users to PyPy? Would any one of them prompt proponents of other
+GUI toolkits to make their own ports?

Added: pypy/extradoc/planning/roadmap/task_manual_optimizations.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_manual_optimizations.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,9 @@
+Hand optimizations
+==================
+
+There are still some hand optimizations of the Python interpreter that
+are well worth doing, since they can be expected to yield significant
+performance improvements. For instance, some of our mircobenchmarks
+show particularly poor performance in some areas. The use of better
+algorithms should improve our performance numbers significantly for
+some of the benchmarks.

Added: pypy/extradoc/planning/roadmap/task_modules_3rdparty.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_modules_3rdparty.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,9 @@
+Third party module support
+==========================
+
+There are some third party modules that would bring early adopters to
+PyPy. They would also serve as code coverage cases. Our time estimate
+is a guess on how much time we would need to spend to get enough
+traction in the community. Exactly what modules to support needs to
+be determined after some of the infrastructure in other tasks is
+in place.

Added: pypy/extradoc/planning/roadmap/task_modules_rffi.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_modules_rffi.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,25 @@
+Port more modules to rffi style
+===============================
+
+Some standard modules written in C have already been ported to the
+rffi style, but more remain.
+XXX Flesh out with some more details. Examples for example.
+
+
+Move modules from app to interpreter level
+==========================================
+
+Some modules are implemented in Python at application level. For
+preformance reasons, they should be implemented at interpreter level.
+
+XXX Which ones?
+
+Write new modules
+=================
+
+There are still some modules in the standard library that need writing
+before PyPy is a reasonable replacement for CPython. Exactly which
+ones needs some investigation.
+XXX Flesh out with some more details. Examples for example.
+
+XXX these tasks should be merged, I think

Added: pypy/extradoc/planning/roadmap/task_multi_platform.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_multi_platform.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,11 @@
+Multi-platform support
+======================
+
+In order to be a viable alternative to CPython, PyPy needs to be
+tested and run cleanly on more platforms than it currently does. Amd64
+with Linux is probably the most urgent one, but there are probably
+others that have some problems.
+
+It probably makes sense to put this item off until we are closer to
+having a production ready system for the i386. We also have a possible
+volunteer effort under way. It remains to be seen if it takes off.

Added: pypy/extradoc/planning/roadmap/task_optimize_jit.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_optimize_jit.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,6 @@
+Add optimizations to the JIT
+============================
+
+A base set of optimizations include common operations on floats and
+strings as well as general call optimization. Fixing bugs in the
+current JIT implementation is also needed.

Added: pypy/extradoc/planning/roadmap/task_parser_cleanup.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_parser_cleanup.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,10 @@
+Parser cleanup
+==============
+
+The parser is in a rather sorry state. Making it support various
+versions of Python is currently a rather nasty job. It needs replacing
+with a more robust design. The estimates for this are probably too low,
+since they were based on the idea of improving the existing parser.
+Subsequent attempts to improve the parser have prompted the idea of
+a rewrite. In the parser work, there is also time needed to upgrade
+the interpreter to handle all of Python 2.5.

Added: pypy/extradoc/planning/roadmap/task_refactor_jit.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_refactor_jit.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,8 @@
+Refactor the JIT
+================
+
+The JIT is the result of programming under severe time pressure. This
+means that the existing JIT framework needs a fair bit of cleanup and
+restructuring. Armin also has some ideas for a refactoring based on an
+interpreter, rather than annotated graphs. 
+XXX maybe phrase this a bit more clearly.

Added: pypy/extradoc/planning/roadmap/task_separate_compilation.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_separate_compilation.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,7 @@
+
+Separate compilation
+====================
+
+To make porting third party modules reasonable, it should not be necessary
+to recompile all of PyPy every time you want to integrate a new extension
+module. This requires supporting separate compilation.

Added: pypy/extradoc/planning/roadmap/task_wrapper_generator.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_wrapper_generator.txt	Fri Dec 14 20:30:19 2007
@@ -0,0 +1,17 @@
+Support a tool like Swig or Boost
+=================================
+
+To make it simpler to integrate C extensions with PyPy, we should support
+at least one tool that is already in use in the Python community.
+
+Google uses Swig heavily, so in a scenario where Google pays for some
+development, it would be natural to do Swig. Once PyPy gets traction
+we expect proponents of other tools to make their own ports.
+
+In addition to Swig, a PyPy version of ctypes should be implemented.
+An attempt to build a layer on top of the existing ctypes
+implementation for CPython has failed. Ctypes was not written with
+this kind of reuse in mind, and it would be harder to change it
+than to make an RPython implementation from scratch.
+
+XXX Some example use case needed here.



More information about the Pypy-commit mailing list