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

antocuni at codespeak.net antocuni at codespeak.net
Mon Dec 17 16:16:25 CET 2007 

Author: antocuni
Date: Mon Dec 17 16:16:24 2007
New Revision: 49873

Added:
   pypy/extradoc/planning/roadmap/goal_jython_ironpython_replacement.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_bytecode_compiler.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_external_objects.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_integration_vm.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_jit_ootype.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_oothreading.txt   (contents, props changed)
   pypy/extradoc/planning/roadmap/task_stdlib_modules.txt   (contents, props changed)
Modified:
   pypy/extradoc/planning/roadmap/task_catch_up_with_2_x.txt
   pypy/extradoc/planning/roadmap/task_documentation.txt
   pypy/extradoc/planning/roadmap/task_pervasive_benchmarking.txt
   pypy/extradoc/planning/roadmap/task_pervasive_testing.txt
   pypy/extradoc/planning/roadmap/task_separate_compilation.txt
   pypy/extradoc/planning/roadmap/task_wrapper_generator.txt
Log:
- add a goal a the relative tasks about being a competitor to jython
  and ironpython

- use a consistent character to underline task titles



Added: pypy/extradoc/planning/roadmap/goal_jython_ironpython_replacement.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/goal_jython_ironpython_replacement.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,27 @@
+This is a roadmap for the specific target of
+
+"Making PyPy a viable replacement for Jython and/or IronPython"
+
+Currently, the biggest advantage of pypy-jvm and pypy-cli over Jython
+and IronPython is compliance to CPython, which is already better than
+their counterparts. However, a lot of work has still to be done before
+they can be used in a production environment.
+
+Speed-wise, pypy-jvm is already slightly faster than Jython; however,
+pypy-cli is about 6x-10x slower than IronPython.
+
+.. include:: task_external_objects.txt
+
+.. include:: task_integration_vm.txt
+
+.. include:: task_manual_optimizations.txt
+
+.. include:: task_jit_ootype.txt
+
+.. include:: task_bytecode_compiler.txt
+
+.. include:: task_oothreading.txt
+
+.. include:: task_separate_compilation.txt
+
+.. include:: task_stdlib_modules.txt

Added: pypy/extradoc/planning/roadmap/task_bytecode_compiler.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_bytecode_compiler.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,25 @@
+Compile Python sources into JVM/.NET bytecode
+=============================================
+
+Status: 
+
+ - pypy-jvm and pypy-cli interprets python bytecode
+
+Todo:
+
+ - make pypy-jvm and pypy-cli emitting native bytecode instead of
+   interpreting python bytecode;
+
+ - the plan is to reuse part of the JIT machinery to automatically
+   convert the Python interpreter into a compiler
+
+Expected outcome:
+
+ - compilation to native bytecode should give a speedup around 2/2.5x;
+
+ - emitting native bytecode is needed for doing some tasks that are
+   possible with Jython/IronPython (i.e., writing applets)
+
+Dependencies:
+
+ - `Port the JIT to ootype`_

Modified: pypy/extradoc/planning/roadmap/task_catch_up_with_2_x.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_catch_up_with_2_x.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_catch_up_with_2_x.txt	Mon Dec 17 16:16:24 2007
@@ -1,5 +1,5 @@
 Catch up with CPython 2.5/2.6
------------------------------
+=============================
 
 status: 
  - PyPy already implements a few features of 2.5 (PEP 309, PEP 338, PEP 341, PEP 357,

Modified: pypy/extradoc/planning/roadmap/task_documentation.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_documentation.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_documentation.txt	Mon Dec 17 16:16:24 2007
@@ -1,5 +1,5 @@
 PyPy Documentation 
------------------------
+==================
 
 status: 
 

Added: pypy/extradoc/planning/roadmap/task_external_objects.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_external_objects.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,24 @@
+Refactor RPython external objects interface
+===========================================
+
+Status: 
+
+ - RPython programs compiled with gencli can make limited use of .NET
+   classes; it is possible to test them without translation by using
+   Python for .NET.
+
+ - genjvm does not support external objects at all
+
+Todo:
+
+ - refactor the code in gencli and make it shareable with genjvm
+
+ - add support for external objects to genjvm; the idea is to make
+   programs testable by using JPype_ or something similar
+
+Expected outcome:
+
+ - ability to use JVM classes from RPython programs
+
+.. _JPype: http://jpype.sourceforge.net/
+

Added: pypy/extradoc/planning/roadmap/task_integration_vm.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_integration_vm.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,30 @@
+Integration with the hosting virtual machine
+============================================
+
+Status: 
+
+ - pypy-cli can access and use .NET classes, through the clr module,
+   but in a limited way. Advanced features such as delegates and
+   inheritance from .NET classes are not supported yet.
+
+ - pypy-jvm cannot access JVM classes.
+
+Todo:
+
+ - improve the clr module
+
+ - refactor it so that most of the code can be shared between pypy-cli
+   and pypy-jvm
+
+ - create the equivalent for the JVM
+
+
+Expected outcome:
+
+ - ability to access to JVM and .NET classes as Jython and IronPython
+   users expect
+
+
+Dependencies:
+
+ - `Refactor RPython external objects interface`_

Added: pypy/extradoc/planning/roadmap/task_jit_ootype.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_jit_ootype.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,16 @@
+Port the JIT to ootype
+======================
+
+Status: 
+
+ - The JIT works only for low level backends
+
+Todo:
+
+ - port the hintannotator/timeshifter to ootype
+
+ - add new JIT backends for the JVM and/or the CLI
+
+Expected outcome:
+
+ - pypy-jvm-jit and pypy-cli-jit

Added: pypy/extradoc/planning/roadmap/task_oothreading.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_oothreading.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,19 @@
+Make pypy-jvm and pypy-cli multithreaded
+========================================
+
+Status: 
+
+ - pypy-jvm and pypy-cli don't support multiple threads
+
+Todo:
+
+ - add the relevant locks to the Python interpreter in order to make
+   pypy-jvm and pypy-cli thread-safe;
+
+ - this task would be probably also useful for implementing a GIL-free
+   threading model for low level backends;
+
+Expected outcome:
+
+ - ability to use use free threading in pypy-jvm and pypy-cli
+

Modified: pypy/extradoc/planning/roadmap/task_pervasive_benchmarking.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_pervasive_benchmarking.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_pervasive_benchmarking.txt	Mon Dec 17 16:16:24 2007
@@ -1,6 +1,6 @@
 
 Pervasive Benchmarking
-------------------------
+======================
 
 status: 
 

Modified: pypy/extradoc/planning/roadmap/task_pervasive_testing.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_pervasive_testing.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_pervasive_testing.txt	Mon Dec 17 16:16:24 2007
@@ -1,5 +1,5 @@
 Pervasive Testing 
-------------------------
+=================
 
 status:
 - automated nightly test runs of pypy tests on 32bit linux machine (wyvern)   

Modified: pypy/extradoc/planning/roadmap/task_separate_compilation.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_separate_compilation.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_separate_compilation.txt	Mon Dec 17 16:16:24 2007
@@ -1,4 +1,3 @@
-
 Separate compilation
 ====================
 

Added: pypy/extradoc/planning/roadmap/task_stdlib_modules.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/task_stdlib_modules.txt	Mon Dec 17 16:16:24 2007
@@ -0,0 +1,34 @@
+Implementing missing standard modules
+=====================================
+
+Status: 
+
+ - A lot of standard modules such as ``socket`` don't work on top of
+   pypy-jvm and pypy-cli
+
+Todo:
+
+ - Implement relevant modules using the API offered by the hosting
+   virtual machine (either at app-level or interp-level). E.g.,
+   implement ``socket`` on top of JVM/.NET sockets.
+
+ - Maybe it would be possible to reuse existing modules from Jython_
+   and FePy_.
+
+Expected outcome:
+
+ - Having a better coverage of the Python standard library
+
+Dependencies:
+
+ - `Separate compilation`_
+
+ - `Refactor RPython external objects interface`_
+
+ - `Integration with the hosting virtual machine`_
+
+
+.. _Jython: http://www.jython.org/
+
+.. _FePy: http://fepy.sourceforge.net/
+

Modified: pypy/extradoc/planning/roadmap/task_wrapper_generator.txt
==============================================================================
--- pypy/extradoc/planning/roadmap/task_wrapper_generator.txt	(original)
+++ pypy/extradoc/planning/roadmap/task_wrapper_generator.txt	Mon Dec 17 16:16:24 2007
@@ -4,9 +4,3 @@
 To make it simpler to integrate C libraries with PyPy, we should support
 at least one of the wrapper generators that are 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.
-
-

More information about the Pypy-commit mailing list