[pypy-svn] rev 1862 - pypy/trunk/doc/funding

[alex at codespeak.net]

Author: alex
Date: Mon Oct 13 18:56:30 2003
New Revision: 1862

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
Log:
finished first proofreading/copyedit/polish



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	Mon Oct 13 18:56:30 2003
@@ -413,40 +413,49 @@
 The documentational aspect of the dissemination goal is handled by one of the
 few workpackages that run for the whole duration of the project.
 
-Each sprint, as well as the regular progress of non-sprint development, will 
-produce technical novelties, some of which may afford immediate use and adoption 
-of the novel technologies being developed.  We expect all developers and participants 
-to openly report to and discuss with their appropriate communities.  Reports and summaries 
-will be posted to the relevant mailing lists as well as archived on both the PyPy and 
-the Python Business Forum website for universal availability.  WP14_ is to support 
-this process at all levels.
-
-Python community members will be encouraged to keep current and get involved 
-with the project, while community involvement and feedback on technical 
-developments will effect design and implementation decisions.  Feedback and
-suggestions will be gathered on the website and mailing lists to be used by the 
-appropriate project areas to further enhance the project's development efforts, in true 
-Open Source spirit.
-
-In addition to supporting the communication process, WP14_ will on occasion 
-present longer, detailed reports to the Commission, and to scientific committees 
-advising the Commission on technical issues. Technical papers and talks will be 
-submitted to scientific conferences which deal with the subject matters covered 
-by the project. When the advancement of the project warrants it, WP14_ will also 
-publish "popularization" articles and tutorial materials to help other 
-practitioners of software development to make practical use of the project's 
-results. Diagrams and schematics will be provided to illustrate fundamental 
-concepts, as appropriate to the audience and the subject matter. 
+Each sprint, as well as the regular progress of non-sprint development, will
+produce technical novelties, some of which may afford immediate use and
+adoption of the novel technologies being developed.  We expect all developers
+and participants to openly report to and discuss with their appropriate
+communities.  Reports and summaries will be posted to the relevant mailing
+lists as well as archived on both the PyPy and the Python Business Forum
+website for universal availability.  WP14_ is to support this process at all
+levels.
+
+Python community members will be encouraged to keep current and get involved
+with the project, while community involvement and feedback on technical
+developments will affect design and implementation decisions.  Feedback and
+suggestions will be gathered on the website and mailing lists and used by the
+appropriate project areas to further enhance the project's development
+efforts, in true Open Source spirit.
+
+In addition to supporting the communication process, WP14_ will on occasion
+present longer, detailed reports to the Commission, and to scientific
+committees advising the Commission on technical issues. Technical papers and
+talks will be submitted to scientific conferences which deal with the subject
+matters covered by the project. When the advancement of the project warrants
+it, WP14_ will also publish "popularization" articles and tutorial materials
+to help other practitioners of software development to make practical use of
+the project's results. Diagrams and schematics will be provided to illustrate
+fundamental concepts, as appropriate to the audience and the subject matter. 
 
 
 Management
 ----------
 
-PyPy's own development needs an infrastructure that must continuously be kept up-to-date and further developed. The role of WP02_ is decisive in choosing and adopting modern development environments. The main source repository is placed under control of Subversion, a Concurrent Versioning System. This workpackage also includes maintaining and possibly redesigning frameworks for unit-testing -- unit-tests are essential in the development process in sprints. The website makes heavy use of collaborative tools like Wiki pages, a content management system, and issue trackers.
+PyPy's own development needs an infrastructure that must continuously be kept
+up-to-date and further developed. The role of WP02_ is decisive in choosing
+and adopting modern development environments. The main source repository is
+placed under control of Subversion, a Concurrent Versioning System. This
+workpackage also includes maintaining and possibly redesigning frameworks for
+unit-testing -- unit-tests are essential in the development process in
+sprints. The website makes heavy use of collaborative tools like Wiki pages, a
+content management system, and issue trackers.
 
 Other tasks include:
 
-- Subversion maintenance (e.g. notification hooks and pre/post-commit restrictions);
+- Subversion maintenance (e.g. notification hooks and pre/post-commit
+  restrictions);
 
 - providing access over http/https and ssh server;
 
@@ -462,9 +471,11 @@
 
 - performing backups for all relevant information/code;
 
-- 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;
   
-- 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
@@ -473,42 +484,93 @@
 
 :DELETE:END
 
-Risks in the Project and Steps to Minimise
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Risks in the Project and Steps to Minimise Them
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 
-The success of the project depends on the success of Phase 1. When the corresponding milestone is reached -- a complete Python interpreter in Python and a translator for it -- the project branches. The Phase 2 and Phase 3 workpackages are not tightly interconnected. So let us first focus on the Phase 1.
+The success of the whole project depends on the success of Phase 1. When the
+corresponding milestone is reached -- a complete Python interpreter in Python
+and a translator for it -- the project will branch. Phase 2 and Phase 3
+workpackages are not tightly interconnected. So we will examine project risks
+with our main focus on Phase 1.
 
 
 Phase 1
 -------
 
-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:
-
-- writing a Python interpreter in Python is not only possible but it is done much faster and easily than in C.
-
-- 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.
-
-- pluggable Object Spaces do work. Several proof-of-concept Object Spaces have been successfully tried.
-
-- 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.
-
-As a fall-back solution, we are aware of the more common way to do the translator analysis: if the abstract Object Space should fail to scale as expected we will revert to a classical bytecode-based analysis, adapting tools that are already available for this task. We will however pursue the abstract interpretation solution as far as possible because it leads to more language-independence and thus a single place where knowledge about the details of the bytecode needs to be written.
+The initial design decisions have already been discussed during the young
+history of the project and its first four 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:
+
+- writing a Python interpreter in Python is not only possible -- it is, in
+  proven fact, markedly faster and easier than in C.
+
+- following some of the basic design decisions of CPython (the internals of
+  whom most of us are intimately familiar with) leads to fast development and
+  good results.
+
+- pluggable Object Spaces do work. Several proof-of-concept Object Spaces have
+  been successfully tried.
+
+- Object Spaces are a remarkably suitable abstraction for abstract/symbolic
+  interpretation. Control flow of simple functions has 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 any particular problem from that issue either.
+
+As a fall-back solution, we are aware of the more common way to do the
+translator analysis: if the abstract Object Space should fail to scale as
+expected, we will revert to classic bytecode-based analysis, adapting tools
+that are already available for this task. We will, however, pursue the
+abstract interpretation solution as far as possible, because it leads to more
+language-independence and particularly to a single place where all knowledge
+about the details of the actual bytecode needs to be represented.
 
 
 Phase 2
 -------
 
-The Phase 2 is mainly research-oriented. It is by definition more difficult to predict the involved risks and fall-backs.
-
-Let us simply note that the performance goals of Phase 2 are backed by the prototypes Stackless and Psyco, whose authors are among the PyPy members. Also note that the described performance goals, while very interesting to widen the application area of the language, are not essential to the other applications we have planned. Phase 1 (including translation) already produces a level of performance that can reasonably be expected to be comparable to the existing CPython interpreter.
+Phase 2 is mainly research-oriented. It is by definition more difficult to
+predict the involved risks, and fall-back strategies if risks materialize,
+for this Phase than for the others.
+
+However, a risk-mitigating factor is that the performance goals of Phase 2 are
+backed by the existing and working prototypes Stackless and Psyco, whose
+authors are among the PyPy members. Further, it is also important to note that
+the described performance goals, while very interesting and important in order
+to widen the application area of the language, are not essential to the other
+applications we have planned. Phase 1 (including translation) already produces
+a level of performance that can reasonably be expected to be comparable to the
+existing CPython interpreter.
 
 
 Phase 3
 -------
 
-Phase 3 consists of a number of independent applications. Consequently, a failure in one of them would almost certainly not influence the others. Of course, appropriate effort has nevertheless been taken to avoid failure in each of the mentionned application: all of them are to some extent already existing as middleware libraries, and people fluent in the corresponding domains generally appreciate the advantages a better language integration would bring.
+Phase 3 consists of a number of independent applications. Consequently, a
+failure in one of them would almost certainly not influence the others. Of
+course, appropriate effort has nevertheless been taken to avoid failure in
+each of the mentioned applications: all of them are to some extent already
+existing as middleware libraries, and people fluent in the corresponding
+domains generally appreciate the advantages a better language integration
+would bring.
+
+The project concludes with an Integration and Configuration workpackage;
+should one of the previous applications fail, the final configurable tool will
+still be able to integrate the others. The only risk involved there would
+involve difficulties (technical or others) to integrate the work done by the
+various partners. As a fall-back solution we may have to keep some successful
+but hard to integrate applications out of the mainstream full-featured release
+or even configuration tool. It is a tendency inherent in open source projects
+to sometimes fork, in order to explore alternative possibilities, and later,
+when consensus is reached, merge again. We will try to minimize the
+corresponding risk (of divergence, i.e., a fork not followed by a later
+merge), but we also think that it is inherently very low, as long as the
+different applications are kept as non-overlapping as possible.  This risk
+minimization strategy in application-structuring is already reflected in
+the work-packages presented for Phase 3.
 
-The project concludes with an Integration and Configuration workpackage; should one of the previous applications fail, the final configurable tool will still be able to integrate the others. The only risk involved there would involve difficulties (technical or others) to integrate the work done by the various partners. As a fall-back solution we may have to keep some successful but hard to integrate applications out of the mainstream full-featured release or even configuration tool. It is a tendency about open source projects to sometimes fork and later, when concensus is reached, merge again. We will try to minimize the corresponding risk, and think that it is indeed minimal if the different applications can be kept as non-overlapping as possible.