[pypy-svn] rev 1779 - in pypy/trunk/doc/funding: . makedoc

[tismer at codespeak.net]

Author: tismer
Date: Sun Oct 12 17:14:56 2003
New Revision: 1779

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
   pypy/trunk/doc/funding/makedoc/part_b.pdf
   pypy/trunk/doc/funding/makedoc/part_b.sxw
Log:
corrected bullets in B6. New PDF.

Modified: pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
==============================================================================
--- pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	(original)
+++ pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	Sun Oct 12 17:14:56 2003
@@ -16,11 +16,11 @@
 
 The PyPy project can be roughly divided into three phases, the last two of which are somewhat independent from each other:
 
-o Phase 1: The core of PyPy itself must first be developed.
+- Phase 1: The core of PyPy itself must first be developed.
 
-o Phase 2: This code base can be used as an research/integration platform of choice.
+- Phase 2: This code base can be used as an research/integration platform of choice.
 
-o Phase 3: Specific applications can be implemented and disseminated.
+- Phase 3: Specific applications can be implemented and disseminated.
 
 Moreover, several project-long infrastructure tasks are of paramount importance. In particular, coordination is assured by the project coordinator in workpackage WP01_, with the help of the management and technical boards, as described in section B5. It involves the collection and monitoring of monthly status reports, reporting to the EU, organising sprints and maintaining an internal web site in collaboration with the maintenance workpackage.
 
@@ -41,11 +41,11 @@
 
 The first goal is to develop a reasonably complete Python interpreter written in Python. It must be entierely compatible with the language specification. It consists of the following major parts:
 
-o A *bytecode compiler,* which translates Python source code into an internal intermediate representation, the *bytecode.*
+- A *bytecode compiler,* which translates Python source code into an internal intermediate representation, the *bytecode.*
 
-o A *bytecode interpreter,* which interprets bytecodes and manages the supporting internal structures (frames, exception tracebacks...). It considers objects as black boxes and delegates all individual operations on them to a library of built-in types, the *Object Space.*
+- A *bytecode interpreter,* which interprets bytecodes and manages the supporting internal structures (frames, exception tracebacks...). It considers objects as black boxes and delegates all individual operations on them to a library of built-in types, the *Object Space.*
 
-o An *Object Space,* which captures the semantics of the various types of the language.
+- An *Object Space,* which captures the semantics of the various types of the language.
 
 This subdivision is common among interpreter implementations, although we place special emphasis on the library and its separation from the bytecode interpreter. The implementation will closely follow the current reference C implementation (CPython). It is thus expected to be relatively straightforward, changing only a few design decisions (mainly with respect to the Object Space separation of concerns), and changing strictly nothing to the Python language itself.
 
@@ -83,15 +83,15 @@
 
 The flexibility in PyPy allows a number of designs to be reconsidered; better yet, it allows different design decisions to coexist. Indeed, most "hard" issues in interpreters have no obvious best solution; they are all depend in complicated ways to the specific details of the runtime environment and on the particular application considered and its possibly evolving context. PyPy will provide a good platform to experiment with and compare empirically several different implementations for many of these issues. For example:
 
-o The language's core object types can have several implementations with different trade-offs. To experimented with this, we will write a collection of alternatives in the "standard" Object Space implementation and heuristics to select between them. This kind of research effort is common, but PyPy can provide a good platform for real-world comparisons, and to help isolate which particular choices have which effects in an otherwise unchanged environment. Such data is notoriously hard to obtain in monolithic interpreters. This is the focus of WP06_.
+- The language's core object types can have several implementations with different trade-offs. To experimented with this, we will write a collection of alternatives in the "standard" Object Space implementation and heuristics to select between them. This kind of research effort is common, but PyPy can provide a good platform for real-world comparisons, and to help isolate which particular choices have which effects in an otherwise unchanged environment. Such data is notoriously hard to obtain in monolithic interpreters. This is the focus of WP06_.
 
-o Similarily, as described above, pervasive design decisions can be experimented with by tailoring the translator. This is the focus of WP07_.
+- Similarily, as described above, pervasive design decisions can be experimented with by tailoring the translator. This is the focus of WP07_.
 
 We will in particular investigate in detail two specific ways to customize the translator:
 
-o Generating Continuation Passing Style (CPS) low-level code. This makes the advanced notion of continuation available for the programmer; but -- most importantly in our case -- it allows the development, with the help of an appropriate runtime system, to support massive parallelism. Indeed, in almost any OS, native threads are not appropriate for massive usage. Applications (e.g. web servers handling thousands of connections) have to somehow emulate parallelism explicitely. Soft-threads are an ideal target for language integration. This work (also part of WP07_) would consist of exploiting this idea, which has been first tried for Python in the Stackless project.
+- Generating Continuation Passing Style (CPS) low-level code. This makes the advanced notion of continuation available for the programmer; but -- most importantly in our case -- it allows the development, with the help of an appropriate runtime system, to support massive parallelism. Indeed, in almost any OS, native threads are not appropriate for massive usage. Applications (e.g. web servers handling thousands of connections) have to somehow emulate parallelism explicitely. Soft-threads are an ideal target for language integration. This work (also part of WP07_) would consist of exploiting this idea, which has been first tried for Python in the Stackless project.
 
-o Generating a JIT compiler. Existing work in the Psyco project has shown that it would actually be possible to mostly generate a JIT compiler instead of having to write it from scratch. The basic idea is again abstract interpretation: instead of actually performing any operation between two objects, we *generate* machine code that can perform the required operation. Again, no change to the bytecode interpreter is needed; all we need is to translate individual operations to processor instructions, together with a supporting runtime systems. This is defined by WP08_.
+- Generating a JIT compiler. Existing work in the Psyco project has shown that it would actually be possible to mostly generate a JIT compiler instead of having to write it from scratch. The basic idea is again abstract interpretation: instead of actually performing any operation between two objects, we *generate* machine code that can perform the required operation. Again, no change to the bytecode interpreter is needed; all we need is to translate individual operations to processor instructions, together with a supporting runtime systems. This is defined by WP08_.
 
 In dynamic languges, the truth behind JIT compiling is a bit more involved than the above paragraph suggests. All the "standard" operations in Python, including the intuitively simple ones, are actually relatively complex because they depend heavily on the runtime type of the involved objects. This complex code is already written in detail in the "standard" Object Space. Thus the JIT compiler will work by abstract interpretation of RPython code, i.e. abstract interpretation of the interpreter itself (as opposed to user application code). This is similar to the ideas behind the translator, which operates on the RPython source (i.e. the bytecode interpreter and the standard Object Space). We plan to write the dynamic part of the JIT as a plug-in to the translator: instead of generating C code that is the direct translation of PyPy, we will generate C code that itself generates machine code. This extra indirection has large benefits: the operations the JIT need to be taught about are only the ones allowed in RPython. The resulting piece of C code would thus be the JIT-enabled version of PyPy.
 
@@ -103,9 +103,9 @@
 
 In the context of the PyPy project, we will not replace the interpreter altogether, but experiment with extensions:
 
-o involving feedback from the Python community, we will experiment with the proposed language extensions that are deemed worthy by the CPython developers. Numerous PEPs (Python Extension Proposals), for example, need an experimental implementation for testing before they can be accepted or rejected for integration into CPython; not only is PyPy a good platform to test them on, but this would give PyPy an active part in the effort of keeping synchronised with the development of CPython. (The role of WP03_ is to keep track of the ongoing development of the Python language and its CPython implementation, for which we will also look for existing solutions to automate the "passive" part of this effort at least partially.)
+- involving feedback from the Python community, we will experiment with the proposed language extensions that are deemed worthy by the CPython developers. Numerous PEPs (Python Extension Proposals), for example, need an experimental implementation for testing before they can be accepted or rejected for integration into CPython; not only is PyPy a good platform to test them on, but this would give PyPy an active part in the effort of keeping synchronised with the development of CPython. (The role of WP03_ is to keep track of the ongoing development of the Python language and its CPython implementation, for which we will also look for existing solutions to automate the "passive" part of this effort at least partially.)
 
-o WP09_ involves the research and development of techniques inspired from logic programming. An inference engine already exists in the python-logic libraries. Successful integration of these concepts, far from regular imperative programming, would provide a validation of the level of flexibility we achieved in Phase 1. It would also provide an essential starting point for WP10_, described below.
+- WP09_ involves the research and development of techniques inspired from logic programming. An inference engine already exists in the python-logic libraries. Successful integration of these concepts, far from regular imperative programming, would provide a validation of the level of flexibility we achieved in Phase 1. It would also provide an essential starting point for WP10_, described below.
 
 
 Phase 3
@@ -117,11 +117,11 @@
 
 The applications we have selected can be categorized into the following categories:
 
-o Language-level object models;
+- Language-level object models;
 
-o Language-level extensions;
+- Language-level extensions;
 
-o Interpreter adaptations.
+- Interpreter adaptations.
 
 This is also where we expect third-parties to build on top of our platform.
 
@@ -133,9 +133,9 @@
 
 **Security** is an important and difficult aspect that requires knowledge and support at a wide number of levels to be effective. Programming languages can help contribute to security at their level. Different object security models are possible:
 
-o The language can be artificially restricted, with dangerous operations taken out and thus impossible to achieve by interpreted programs. In effect, this amount to building a stripped-down interpreter.
+- The language can be artificially restricted, with dangerous operations taken out and thus impossible to achieve by interpreted programs. In effect, this amount to building a stripped-down interpreter.
 
-o Access to some objects can be denied to only some (untrusted) parts of the interpreted program; or access can go though proxies performing some kind of access checks. This is a more flexible solution, but it is more difficult to implement efficiently. Explicit checks for each access consume time. In PyPy this could be implemented as an Object Space checking and delegating operations to another Object Space.
+- Access to some objects can be denied to only some (untrusted) parts of the interpreted program; or access can go though proxies performing some kind of access checks. This is a more flexible solution, but it is more difficult to implement efficiently. Explicit checks for each access consume time. In PyPy this could be implemented as an Object Space checking and delegating operations to another Object Space.
 
 For comparison, CPython used to implement security-by-absence-of-reference: untrusted parts of a program could supposedly not obtain a reference to a dangerous object. This model, called "RExec", has been recognized as fragile and hard to maintain. It has been removed from CPython.
 
@@ -214,25 +214,25 @@
 
 Other tasks include:
 
-o Subversion maintenance (e.g. notification hooks and pre/post-commit restrictions);
+- Subversion maintenance (e.g. notification hooks and pre/post-commit restrictions);
 
-o providing access over http/https and ssh server;
+- providing access over http/https and ssh server;
 
-o building extensions for automatic document extraction;
+- building extensions for automatic document extraction;
 
-o maintenance or setup of mailing lists;
+- maintenance or setup of mailing lists;
 
-o implementing a search facility over all content;
+- implementing a search facility over all content;
 
-o maintaining or extending the issue tracker;
+- maintaining or extending the issue tracker;
 
-o maintaining and enhancing the website infrastructure;
+- maintaining and enhancing the website infrastructure;
 
-o performing backups for all relevant information/code;
+- performing backups for all relevant information/code;
 
-o setting up a mirror repository which is kept up-to-date and which can be used readonly in case of failure of the main repository;
+- setting up a mirror repository which is kept up-to-date and which can be used readonly in case of failure of the main repository;
   
-o taking care of regular repository backups, designing a strict backup policy suitable for the project, and adhering to it.
+- taking care of regular repository backups, designing a strict backup policy suitable for the project, and adhering to it.
 
 
 :DELETE:BEGIN
@@ -253,13 +253,13 @@
 
 The initial design decisions have already been discussed during the young history of the project and its first 4 sprints, and a basic working prototype has already been written as a proof of concept. We thus take for granted that the risks associated with the following decisions are almost non-existent at this point:
 
-o writing a Python interpreter in Python is not only possible but it is done much faster and easily than in C.
+- writing a Python interpreter in Python is not only possible but it is done much faster and easily than in C.
 
-o following some basic design decisions of CPython (the internals of whom most of us are intimately familiar with) leads to fast development and good results.
+- following some basic design decisions of CPython (the internals of whom most of us are intimately familiar with) leads to fast development and good results.
 
-o pluggable Object Spaces do work. Several proof-of-concept Object Spaces have been successfully tried.
+- pluggable Object Spaces do work. Several proof-of-concept Object Spaces have been successfully tried.
 
-o Object Spaces are really a suitable abstraction for abstract/symbolic interpretation. Control flow of simple functions have been derived using an Object Space.
+- Object Spaces are really a suitable abstraction for abstract/symbolic interpretation. Control flow of simple functions have been derived using an Object Space.
 
 Moreover, simple type analysis and generation of low-level code from a low-level representation is common in a variety of contexts, so we don't expect particular problems from there either.
 

Modified: pypy/trunk/doc/funding/makedoc/part_b.pdf
==============================================================================
Binary files. No diff available.

Modified: pypy/trunk/doc/funding/makedoc/part_b.sxw
==============================================================================
Binary files. No diff available.