[pypy-svn] r10791 - pypy/dist/pypy/documentation
hpk at codespeak.net
hpk at codespeak.net
Sun Apr 17 22:08:23 CEST 2005
Author: hpk
Date: Sun Apr 17 22:08:23 2005
New Revision: 10791
Added:
pypy/dist/pypy/documentation/future.txt
Removed:
pypy/dist/pypy/documentation/goals.txt
pypy/dist/pypy/documentation/newrepolayout.txt
Modified:
pypy/dist/pypy/documentation/redirections
Log:
fourth refactoring according to newstructure
Added: pypy/dist/pypy/documentation/future.txt
==============================================================================
--- (empty file)
+++ pypy/dist/pypy/documentation/future.txt Sun Apr 17 22:08:23 2005
@@ -0,0 +1,475 @@
+============
+Future plans
+============
+
+.. contents::
+.. sectnum::
+
+This document contains a loose collection of future plans.
+
+.. _newrepolayout:
+
+Improving Repo layout
+=====================
+
+Motivation
+----------
+
+We want to move our subversion tree to the following structure:
+
+- `dist`_: source code + documentation (for developer needs)
+
+- `extradoc`_: talks, papers, newsletters and EU-related information
+ that are useful for not-only-developers
+
+- `eu-tracking`: eu-tracking details that involve internal
+ budget/cost/audit preparations and documentations (not
+ available to anonymous checkouts)
+
+.. _`extradoc`: http://codespeak.net/svn/pypy/extradoc
+.. _`dist`: http://codespeak.net/svn/pypy/dist
+
+More detailed layout (work in progress)
+---------------------------------------
+
+(starting at /svn/pypy)::
+
+ branch # holds branches
+ tag # holds tagged dist-versions
+
+ dist # holds current development
+ pypy # current dist/pypy
+ documentation # developer documentation (inside pypy!)
+ py # and other 'externals'
+ setup.py # should be there at some point
+ README.txt # tell how to run PyPy, the translator, tests
+ LICENSE.txt # copyright notices for tree parts including pypy
+
+ extradoc # non-dist documentations (papers etc.pp.)
+ talk # various pypy-talks
+ paper # various pypy-related papers (including our own)
+ sprint # sprint related information (reports etc.pp.)
+ irclog # IRC logs (snipped appropriately)
+ eu-info # legal guidelines/rules partcipation
+ eu-forms # Accession forms (empty)
+ proposal # several versions
+ newsletter # ...
+ press # ...
+
+ eu-tracking # strong focus on eu-internal details
+ timesheets # monthly timesheets
+ monthly-reports
+ deliverables # deliverable/documents
+ minutes # meeting protocols
+ budget.sxc
+ calendar.sxc
+ ...
+ www # website-related stuff (needs its own reconsideration)
+
+
+The idea is that developers can use a simple url::
+
+ svn co https://codespeak.net/svn/pypy/dist dist-pypy
+
+in order to get everything neccessary for sourcecode, documentation
+and test development. Obviously, if you care about the EU-funding
+or web site application/contents you can do an appropriate checkout
+as well. The extradoc contains information interesting to
+developers and other open source projects (seeking funding or not).
+
+Note, that having documentation inside the source tree will help
+with keeping a closer eye on documentation - especially when we
+have special ref-integrity tests for the documentation (which itself
+should reference real source-code/functions at some point). For
+example, the refactoring of unitest.py-style tests to `py.test`_ based ones
+"forgot" to modify our test-documentation in the too-far-away doc-folder.
+We should move to a scheme where such an omission will raise real
+test errors.
+
+.. _`py.test`: http://codespeak.net/py/current/doc/test.html
+
+.. _goals:
+
+Brainstorming of goals
+=========================
+
+This is a loose collection of goals we brainstormed at
+some earlier point.
+
+**Infrastructure and tools**
+
+Supporting the PyPy project by producing and enhancing the tools.
+
+Support the development process with reusing existing or developing
+new debugging opensource tools.
+
+- provide access over http/https and ssh server
+
+- build extensions for automatic document extraction
+
+- implement a search facility over all content
+
+- maintain and enhance website infrastructure
+
+- setup a mirror repository which is kept up-to-date and which
+ can be used readonly in case of failure of the main repository.
+
+- Design a strict backup policy.
+
+- help with automated testing
+
+ XXX add what more do we want to do?
+
+- http-server to present runtime/introspection information aiding
+ debugging and understanding of PyPy internals
+
+- automated (unit-)testing framework with html/pdf reports
+
+**Synchronisation with Standard Python**
+
+- Keeping PyPy in sync with potential changes to Standard Python.
+
+- Support a subset of the CPython API for compatibility with extension modules.
+
+- Facilitate porting of extension modules to PyPy.
+
+- What's new since 2.2? see http://www.python.org/doc/2.3.3/whatsnew -- Thank you amk!
+
+**PEPS**
+
++ PEP 218: A Standard Set Datatype -- set module --
+
++ PEP 263 defining Python Source Code encodings
+
++ PEP 273 Importing Modules from Zip Archives -- zipimport module --
+
++ PEP 277: Unicode file name support for Windows NT
+
++ PEP 278: Universal Newline Support
+
++ PEP 279: enumerate()
+
++ PEP 282: The logging Package
+
++ PEP 285: A Boolean Type
+
++ PEP 293: Codec Error Handling Callbacks
+
++ PEP 301: Package Index and Metadata for Distutils
+
++ PEP 302: New Import Hooks
+
++ PEP 307: Pickle Enhancements
+
+**Check and see we have implemented these**
+
+* Extended Slices
+
+* The yield statement is now always a keyword
+
+* new built-in function enumerate()
+
+* Two new constants, True and False
+
+* The int() type constructor will now return a long integer instead of
+ raising an OverflowError when a string or floating-point number is too
+ large to fit into an integer. This can lead to the paradoxical result
+ that isinstance(int(expression), int) is false.
+
+* Built-in types now support the extended slicing syntax
+
+* A new built-in function, sum(iterable, start=0), adds up the numeric
+ items in the iterable object and returns their sum. sum() only accepts
+ numbers, meaning that you can't use it to concatenate a bunch of strings.
+
+does it handle mixed floats and ints?
+
+* list.insert(pos, value) used to insert value at the front of the list
+ when pos was negative. The behaviour has now been changed to be consistent
+ with slice indexing, so when pos is -1 the value will be inserted before
+ the last element, and so forth.
+
+so to insert at the front?
+
+* list.index(value), which searches for value within the list and
+ returns its index, now takes optional start and stop arguments to limit
+ the search to only part of the list.
+
+* Dictionaries have a new method, pop(key[, default]), that returns the
+ value corresponding to key and removes that key/value pair from the
+ dictionary. If the requested key isn't present in the dictionary,
+ default is returned if it's specified and KeyError raised if it isn't.
+
+* There's also a new class method, dict.fromkeys(iterable, value), that
+ creates a dictionary with keys taken from the supplied iterator iterable
+ and all values set to value, defaulting to None.
+
+ Also, the dict() constructor now accepts keyword arguments to simplify
+ creating small dictionaries:
+
+ >>> dict(red=1, blue=2, green=3, black=4)
+ {'blue': 2, 'black': 4, 'green': 3, 'red': 1}
+
+
+* The assert statement no longer checks the __debug__ flag, so you can no
+ longer disable assertions by assigning to __debug__. Running Python with
+ the -O switch will still generate code that doesn't execute any assertions.
+
+So what if you want to disable assertions just within one module?
+
+* Most type objects are now callable, so you can use them to create new
+ objects such as functions, classes, and modules. (This means that the
+ new module can be deprecated in a future Python version, because you
+ can now use the type objects available in the types module.) For example,
+ you can create a new module object with the following code:
+
+ >>> import types
+ >>> m = types.ModuleType('abc','docstring')
+ >>> m
+ <module 'abc' (built-in)>
+ >>> m.__doc__
+ 'docstring'
+
+* A new warning, PendingDeprecationWarning was added to indicate features
+ which are in the process of being deprecated. The warning will not be
+ printed by default. To check for use of features that will be deprecated
+ in the future, supply -Walways::PendingDeprecationWarning:: on the
+ command line or use warnings.filterwarnings().
+
+* The process of deprecating string-based exceptions, as in
+ raise "Error occurred", has begun. Raising a string will now trigger
+ PendingDeprecationWarning.
+
+* Using None as a variable name will now result in a SyntaxWarning warning.
+ In a future version of Python, None may finally become a keyword.
+
+* The xreadlines() method of file objects, introduced in Python 2.1,
+ is no longer necessary because files now behave as their own
+ iterator. xreadlines() was originally introduced as a faster way to
+ loop over all the lines in a file, but now you can simply write
+ for line in file_obj. File objects also have a new read-only encoding
+ attribute that gives the encoding used by the file; Unicode strings
+ written to the file will be automatically converted to bytes using
+ the given encoding.
+
+* The method resolution order used by new-style classes has changed,
+ though you'll only notice the difference if you have a really
+ complicated inheritance hierarchy. Classic classes are unaffected by
+ this change. Python 2.2 originally used a topological sort of a
+ class's ancestors, but 2.3 now uses the C3 algorithm as described in
+ the paper *A Monotonic Superclass Linearization for Dylan*. To
+ understand the motivation for this change, read Michele Simionato's
+ article *Python 2.3 Method Resolution Order*, or read the thread
+ on python-dev starting with the message at
+ http://mail.python.org/pipermail/python-dev/2002-October/029035.html.
+ Samuele Pedroni first pointed out the problem and also implemented the fix
+ by coding the C3 algorithm.
+
+* Python runs multithreaded programs by switching between threads
+ after executing N bytecodes. The default value for N has been
+ increased from 10 to 100 bytecodes, speeding up single-threaded
+ applications by reducing the switching overhead. Some multithreaded
+ applications may suffer slower response time, but that's easily
+ fixed by setting the limit back to a lower number using
+ sys.setcheckinterval(N). The limit can be retrieved with the new
+ sys.getcheckinterval() function.
+
+* One minor but far-reaching change is that the names of extension
+ types defined by the modules included with Python now contain the
+ module and a "." in front of the type name. For example, in Python
+ 2.2, if you created a socket and printed its __class__, you'd get
+ this output:
+
+ >>> s = socket.socket()
+ >>> s.__class__
+ <type 'socket'>
+
+ In 2.3, you get this:
+
+ >>> s.__class__
+ <type '_socket.socket'>
+
+* One of the noted incompatibilities between old- and new-style
+ classes has been removed: you can now assign to the __name__ and
+ __bases__ attributes of new-style classes. There are some
+ restrictions on what can be assigned to __bases__ along the lines of
+ those relating to assigning to an instance's __class__ attribute.
+
+**String Changes**
+
+* The in operator now works differently for strings. Previously, when
+ evaluating X in Y where X and Y are strings, X could only be a
+ single character. That's now changed; X can be a string of any
+ length, and X in Y will return True if X is a substring of Y. If X
+ is the empty string, the result is always True.
+
+ >>> 'ab' in 'abcd'
+ True
+ >>> 'ad' in 'abcd'
+ False
+ >>> '' in 'abcd'
+ True
+
+* The strip(), lstrip(), and rstrip() string methods now have an
+ optional argument for specifying the characters to strip. The
+ default is still to remove all whitespace characters:
+
+* The startswith() and endswith() string methods now accept negative
+ numbers for the start and end parameters.
+
+* Another new string method is zfill(), originally a function in the
+ string module. zfill() pads a numeric string with zeros on the left
+ until it's the specified width. Note that the % operator is still
+ more flexible and powerful than zfill().
+
+* A new type object, basestring, has been added. Both 8-bit strings
+ and Unicode strings inherit from this type, so isinstance(obj, basestring)
+ will return True for either kind of string. It's a completely abstract
+ type, so you can't create basestring instances.
+
+* Interned strings are no longer immortal and will now be
+ garbage-collected in the usual way when the only reference to them
+ is from the internal dictionary of interned strings.
+
+**Replace PyPy Core**
+
+Building a complete Python interpreter written in Python,
+using a subset of Python that avoids dynamic featureslll
+which would impair the objectives of RPython.
+
+- Design and implement the PyPy bytecode interpreter and
+ build an object space library in RPython.
+ The resulting interpreter must cover the complete Python
+ language specification. -- mostly done, test coverage.
+
+- Port the built-in Python library to PyPy (functions, types and
+ modules currently implemented in C) -- types needs refactoring,
+ the rest is mostly done. Anthony Baxter has given us a very useful
+ list of the cmodules_ we need to consider porting.
+
+- Decide on a case-by-case basis which features are to
+ be implemented using RPython or just general Python. -- moving target.
+
+- Implement a Python parser and bytecode compiler in Python.
+ -- we have something, but it is not well integrated.
+
+- A partial Python implementation that passses 75% of the official
+ Python test suite that don't depend on extension modules.
+ -- write this test and then pass it.
+
+**The PyPy Translation**
+
+- Analysis and translation of the PyPy core into efficient low-level code
+ (C, Pyrex, Java, others). - moving target
+
+- Provide a Runtime Library for the translated versions
+ of PyPy. - not even started
+
+- Create a code analysis tool for a subset of the Python
+ language (RPython). Coordinate the definition of RPython
+ being the implementation language of the core.
+
+ - we can analyse functions, but not classes, modules, spaces etc.
+
+- Complete implementation of Python, conforming to the language
+ definition and passing all relevant tests of the official Python
+ test suite. -- global goal, which we will think more about when
+ it is very close to being done.
+
+**Stackless Integration + More Performance Hacks**
+
+- Identification and Implementation of Optimisations through modifications
+ of the Translator.
+
+- Enable Massive Parallelism in a Single Thread.
+
+- Provide support for real-time parallelism.
+
+- Allow Pickling of a Running Program.
+
+- Enhance the translator to support continuation passing
+ style by integrating technology from the Stackless project.
+
+- Implement the necessary runtime system to support massive parallelism.
+
+- Implement a single-threaded, pre-emptive scheduler with
+ priorities, complementing the OS threads.
+
+- Study approaches concerning code size vs. speed trade-offs.
+
+- Implement and compare different object layout and memory management
+ strategy or strategies.
+
+- Enhance multimethod dispatching.
+
+- Implement schemes of pointer tagging.
+
+- Create reports and merge the results back into the optimization effort.
+
+**Psyco Integration**
+
+- Outperform the state-of-the art (Psyco, Stackless).
+
+- Enhance PyPy to dynamically adapt to its run-time environment and
+ to the characteristics of the running program. Dramatically
+ increase speed by enabling Just-In-Time compilation and
+ specialization.
+
+- Address multiple processor architectures.
+
+- Apply and enhance techniques from the Psyco project. Promote parts
+ of the static translator to be used for run-time specialization.
+
+- Design and implement a back-end component for dynamically emitting
+ machine code for multiple processor architectures. Enable dynamic
+ foreign function calls.
+
+- Research optimisation heuristics for the Just-In-Time compiler.
+
+- A Just-In-Time compiler for PyPy !!! Outperform the
+ state-of-the art (Psyco, Stackless).
+
+**Embed in Specialized Hardware**
+
+if we get funding.
+
+**Implement Security, Distribution and Persistence**
+
+- Research and validate the flexibility of PyPy by building key middleware
+ features into the language itself.
+
+- Analyze and implement security models at the language level.
+
+- Implement the "RExec" restricted execution model. (It was removed
+ from the official Python implementation because it is false security.)
+
+- Analyze and implement distributed execution models at the language level.
+
+- Implement network-transparent execution of Python programs. (Typical
+ libraries require programs to be aware of the remote execution model.)
+
+- Analyze and implement persistence at the language level. -- talk to
+ Patrick O'Brien who is really hot for the idea.
+
+- Implement an orthogonally persistent object space for Python programs.
+ (Persistence is never fully orthogonal without advanced language support.)
+
+**PyPy A la Carte**
+
+- Develop tools that will allow to chose from available features and runtime
+ restrictions to build a custom PyPy version.
+
+- Analyse and integrate all results from the results of other workpackages.
+ This involves identifying and resolving conflicts which could prevent
+ a combintation of desired optimization goals.
+
+- Implement user interfaces to select features and runtime restrictions.
+ Provide a way to automatically build a PyPy custom version for different
+ memory, performance and extension requirements.
+
+- Make a build- and configuration tool that allows to build custom PyPy
+ versions suitable for specialized environments such as small or very large
+ computing devices.
+
+.. _cmodules: http://codespeak.net/pypy/index.cgi?doc/cmodules.html
+
Deleted: /pypy/dist/pypy/documentation/goals.txt
==============================================================================
--- /pypy/dist/pypy/documentation/goals.txt Sun Apr 17 22:08:23 2005
+++ (empty file)
@@ -1,376 +0,0 @@
-**Infrastructure and tools**
-
-Supporting the PyPy project by producing and enhancing the tools.
-
-Support the development process with reusing existing or developing
-new debugging opensource tools.
-
-- provide access over http/https and ssh server
-
-- build extensions for automatic document extraction
-
-- implement a search facility over all content
-
-- maintain and enhance website infrastructure
-
-- setup a mirror repository which is kept up-to-date and which
- can be used readonly in case of failure of the main repository.
-
-- Design a strict backup policy.
-
-- help with automated testing
-
- XXX add what more do we want to do?
-
-- http-server to present runtime/introspection information aiding
- debugging and understanding of PyPy internals
-
-- automated (unit-)testing framework with html/pdf reports
-
-**Synchronisation with Standard Python**
-
-- Keeping PyPy in sync with potential changes to Standard Python.
-
-- Support a subset of the CPython API for compatibility with extension modules.
-
-- Facilitate porting of extension modules to PyPy.
-
-- What's new since 2.2? see http://www.python.org/doc/2.3.3/whatsnew -- Thank you amk!
-
-**PEPS**
-
-+ PEP 218: A Standard Set Datatype -- set module --
-
-+ PEP 263 defining Python Source Code encodings
-
-+ PEP 273 Importing Modules from Zip Archives -- zipimport module --
-
-+ PEP 277: Unicode file name support for Windows NT
-
-+ PEP 278: Universal Newline Support
-
-+ PEP 279: enumerate()
-
-+ PEP 282: The logging Package
-
-+ PEP 285: A Boolean Type
-
-+ PEP 293: Codec Error Handling Callbacks
-
-+ PEP 301: Package Index and Metadata for Distutils
-
-+ PEP 302: New Import Hooks
-
-+ PEP 307: Pickle Enhancements
-
-**Check and see we have implemented these**
-
-* Extended Slices
-
-* The yield statement is now always a keyword
-
-* new built-in function enumerate()
-
-* Two new constants, True and False
-
-* The int() type constructor will now return a long integer instead of
- raising an OverflowError when a string or floating-point number is too
- large to fit into an integer. This can lead to the paradoxical result
- that isinstance(int(expression), int) is false.
-
-* Built-in types now support the extended slicing syntax
-
-* A new built-in function, sum(iterable, start=0), adds up the numeric
- items in the iterable object and returns their sum. sum() only accepts
- numbers, meaning that you can't use it to concatenate a bunch of strings.
-
-does it handle mixed floats and ints?
-
-* list.insert(pos, value) used to insert value at the front of the list
- when pos was negative. The behaviour has now been changed to be consistent
- with slice indexing, so when pos is -1 the value will be inserted before
- the last element, and so forth.
-
-so to insert at the front?
-
-* list.index(value), which searches for value within the list and
- returns its index, now takes optional start and stop arguments to limit
- the search to only part of the list.
-
-* Dictionaries have a new method, pop(key[, default]), that returns the
- value corresponding to key and removes that key/value pair from the
- dictionary. If the requested key isn't present in the dictionary,
- default is returned if it's specified and KeyError raised if it isn't.
-
-* There's also a new class method, dict.fromkeys(iterable, value), that
- creates a dictionary with keys taken from the supplied iterator iterable
- and all values set to value, defaulting to None.
-
- Also, the dict() constructor now accepts keyword arguments to simplify
- creating small dictionaries:
-
- >>> dict(red=1, blue=2, green=3, black=4)
- {'blue': 2, 'black': 4, 'green': 3, 'red': 1}
-
-
-* The assert statement no longer checks the __debug__ flag, so you can no
- longer disable assertions by assigning to __debug__. Running Python with
- the -O switch will still generate code that doesn't execute any assertions.
-
-So what if you want to disable assertions just within one module?
-
-* Most type objects are now callable, so you can use them to create new
- objects such as functions, classes, and modules. (This means that the
- new module can be deprecated in a future Python version, because you
- can now use the type objects available in the types module.) For example,
- you can create a new module object with the following code:
-
- >>> import types
- >>> m = types.ModuleType('abc','docstring')
- >>> m
- <module 'abc' (built-in)>
- >>> m.__doc__
- 'docstring'
-
-* A new warning, PendingDeprecationWarning was added to indicate features
- which are in the process of being deprecated. The warning will not be
- printed by default. To check for use of features that will be deprecated
- in the future, supply -Walways::PendingDeprecationWarning:: on the
- command line or use warnings.filterwarnings().
-
-* The process of deprecating string-based exceptions, as in
- raise "Error occurred", has begun. Raising a string will now trigger
- PendingDeprecationWarning.
-
-* Using None as a variable name will now result in a SyntaxWarning warning.
- In a future version of Python, None may finally become a keyword.
-
-* The xreadlines() method of file objects, introduced in Python 2.1,
- is no longer necessary because files now behave as their own
- iterator. xreadlines() was originally introduced as a faster way to
- loop over all the lines in a file, but now you can simply write
- for line in file_obj. File objects also have a new read-only encoding
- attribute that gives the encoding used by the file; Unicode strings
- written to the file will be automatically converted to bytes using
- the given encoding.
-
-* The method resolution order used by new-style classes has changed,
- though you'll only notice the difference if you have a really
- complicated inheritance hierarchy. Classic classes are unaffected by
- this change. Python 2.2 originally used a topological sort of a
- class's ancestors, but 2.3 now uses the C3 algorithm as described in
- the paper *A Monotonic Superclass Linearization for Dylan*. To
- understand the motivation for this change, read Michele Simionato's
- article *Python 2.3 Method Resolution Order*, or read the thread
- on python-dev starting with the message at
- http://mail.python.org/pipermail/python-dev/2002-October/029035.html.
- Samuele Pedroni first pointed out the problem and also implemented the fix
- by coding the C3 algorithm.
-
-* Python runs multithreaded programs by switching between threads
- after executing N bytecodes. The default value for N has been
- increased from 10 to 100 bytecodes, speeding up single-threaded
- applications by reducing the switching overhead. Some multithreaded
- applications may suffer slower response time, but that's easily
- fixed by setting the limit back to a lower number using
- sys.setcheckinterval(N). The limit can be retrieved with the new
- sys.getcheckinterval() function.
-
-* One minor but far-reaching change is that the names of extension
- types defined by the modules included with Python now contain the
- module and a "." in front of the type name. For example, in Python
- 2.2, if you created a socket and printed its __class__, you'd get
- this output:
-
- >>> s = socket.socket()
- >>> s.__class__
- <type 'socket'>
-
- In 2.3, you get this:
-
- >>> s.__class__
- <type '_socket.socket'>
-
-* One of the noted incompatibilities between old- and new-style
- classes has been removed: you can now assign to the __name__ and
- __bases__ attributes of new-style classes. There are some
- restrictions on what can be assigned to __bases__ along the lines of
- those relating to assigning to an instance's __class__ attribute.
-
-**String Changes**
-
-* The in operator now works differently for strings. Previously, when
- evaluating X in Y where X and Y are strings, X could only be a
- single character. That's now changed; X can be a string of any
- length, and X in Y will return True if X is a substring of Y. If X
- is the empty string, the result is always True.
-
- >>> 'ab' in 'abcd'
- True
- >>> 'ad' in 'abcd'
- False
- >>> '' in 'abcd'
- True
-
-* The strip(), lstrip(), and rstrip() string methods now have an
- optional argument for specifying the characters to strip. The
- default is still to remove all whitespace characters:
-
-* The startswith() and endswith() string methods now accept negative
- numbers for the start and end parameters.
-
-* Another new string method is zfill(), originally a function in the
- string module. zfill() pads a numeric string with zeros on the left
- until it's the specified width. Note that the % operator is still
- more flexible and powerful than zfill().
-
-* A new type object, basestring, has been added. Both 8-bit strings
- and Unicode strings inherit from this type, so isinstance(obj, basestring)
- will return True for either kind of string. It's a completely abstract
- type, so you can't create basestring instances.
-
-* Interned strings are no longer immortal and will now be
- garbage-collected in the usual way when the only reference to them
- is from the internal dictionary of interned strings.
-
-**Replace PyPy Core**
-
-Building a complete Python interpreter written in Python,
-using a subset of Python that avoids dynamic featureslll
-which would impair the objectives of RPython.
-
-- Design and implement the PyPy bytecode interpreter and
- build an object space library in RPython.
- The resulting interpreter must cover the complete Python
- language specification. -- mostly done, test coverage.
-
-- Port the built-in Python library to PyPy (functions, types and
- modules currently implemented in C) -- types needs refactoring,
- the rest is mostly done. Anthony Baxter has given us a very useful
- list of the cmodules_ we need to consider porting.
-
-- Decide on a case-by-case basis which features are to
- be implemented using RPython or just general Python. -- moving target.
-
-- Implement a Python parser and bytecode compiler in Python.
- -- we have something, but it is not well integrated.
-
-- A partial Python implementation that passses 75% of the official
- Python test suite that don't depend on extension modules.
- -- write this test and then pass it.
-
-**The PyPy Translation**
-
-- Analysis and translation of the PyPy core into efficient low-level code
- (C, Pyrex, Java, others). - moving target
-
-- Provide a Runtime Library for the translated versions
- of PyPy. - not even started
-
-- Create a code analysis tool for a subset of the Python
- language (RPython). Coordinate the definition of RPython
- being the implementation language of the core.
-
- - we can analyse functions, but not classes, modules, spaces etc.
-
-- Complete implementation of Python, conforming to the language
- definition and passing all relevant tests of the official Python
- test suite. -- global goal, which we will think more about when
- it is very close to being done.
-
-**Stackless Integration + More Performance Hacks**
-
-- Identification and Implementation of Optimisations through modifications
- of the Translator.
-
-- Enable Massive Parallelism in a Single Thread.
-
-- Provide support for real-time parallelism.
-
-- Allow Pickling of a Running Program.
-
-- Enhance the translator to support continuation passing
- style by integrating technology from the Stackless project.
-
-- Implement the necessary runtime system to support massive parallelism.
-
-- Implement a single-threaded, pre-emptive scheduler with
- priorities, complementing the OS threads.
-
-- Study approaches concerning code size vs. speed trade-offs.
-
-- Implement and compare different object layout and memory management
- strategy or strategies.
-
-- Enhance multimethod dispatching.
-
-- Implement schemes of pointer tagging.
-
-- Create reports and merge the results back into the optimization effort.
-
-**Psyco Integration**
-
-- Outperform the state-of-the art (Psyco, Stackless).
-
-- Enhance PyPy to dynamically adapt to its run-time environment and
- to the characteristics of the running program. Dramatically
- increase speed by enabling Just-In-Time compilation and
- specialization.
-
-- Address multiple processor architectures.
-
-- Apply and enhance techniques from the Psyco project. Promote parts
- of the static translator to be used for run-time specialization.
-
-- Design and implement a back-end component for dynamically emitting
- machine code for multiple processor architectures. Enable dynamic
- foreign function calls.
-
-- Research optimisation heuristics for the Just-In-Time compiler.
-
-- A Just-In-Time compiler for PyPy !!! Outperform the
- state-of-the art (Psyco, Stackless).
-
-**Embed in Specialized Hardware**
-
-if we get funding.
-
-**Implement Security, Distribution and Persistence**
-
-- Research and validate the flexibility of PyPy by building key middleware
- features into the language itself.
-
-- Analyze and implement security models at the language level.
-
-- Implement the "RExec" restricted execution model. (It was removed
- from the official Python implementation because it is false security.)
-
-- Analyze and implement distributed execution models at the language level.
-
-- Implement network-transparent execution of Python programs. (Typical
- libraries require programs to be aware of the remote execution model.)
-
-- Analyze and implement persistence at the language level. -- talk to
- Patrick O'Brien who is really hot for the idea.
-
-- Implement an orthogonally persistent object space for Python programs.
- (Persistence is never fully orthogonal without advanced language support.)
-
-**PyPy A la Carte**
-
-- Develop tools that will allow to chose from available features and runtime
- restrictions to build a custom PyPy version.
-
-- Analyse and integrate all results from the results of other workpackages.
- This involves identifying and resolving conflicts which could prevent
- a combintation of desired optimization goals.
-
-- Implement user interfaces to select features and runtime restrictions.
- Provide a way to automatically build a PyPy custom version for different
- memory, performance and extension requirements.
-
-- Make a build- and configuration tool that allows to build custom PyPy
- versions suitable for specialized environments such as small or very large
- computing devices.
-
-.. _cmodules: http://codespeak.net/pypy/index.cgi?doc/cmodules.html
\ No newline at end of file
Deleted: /pypy/dist/pypy/documentation/newrepolayout.txt
==============================================================================
--- /pypy/dist/pypy/documentation/newrepolayout.txt Sun Apr 17 22:08:23 2005
+++ (empty file)
@@ -1,80 +0,0 @@
-===========================================
-Proposition: new svn repository layout
-===========================================
-
-Motivation
-----------
-
-We want to move to the following structure:
-
-- `dist`_: source code + documentation (for developer needs)
-
-- `extradoc`_: talks, papers, newsletters and EU-related information
- that are useful for not-only-developers
-
-- `eu-tracking`: eu-tracking details that involve internal
- budget/cost/audit preparations and documentations (not
- available to anonymous checkouts)
-
-.. _`extradoc`: http://codespeak.net/svn/pypy/extradoc
-.. _`dist`: http://codespeak.net/svn/pypy/dist
-
-More detailed layout (work in progress)
----------------------------------------
-
-(starting at /svn/pypy)::
-
- branch # holds branches
- tag # holds tagged dist-versions
-
- dist # holds current development
- pypy # current dist/pypy
- documentation # developer documentation (inside pypy!)
- py # and other 'externals'
- setup.py # should be there at some point
- README.txt # tell how to run PyPy, the translator, tests
- LICENSE.txt # copyright notices for tree parts including pypy
-
- extradoc # non-dist documentations (papers etc.pp.)
- talk # various pypy-talks
- paper # various pypy-related papers (including our own)
- sprint # sprint related information (reports etc.pp.)
- irclog # IRC logs (snipped appropriately)
- eu-info # legal guidelines/rules partcipation
- eu-forms # Accession forms (empty)
- proposal # several versions
- newsletter # ...
- press # ...
-
- eu-tracking # strong focus on eu-internal details
- timesheets # monthly timesheets
- monthly-reports
- deliverables # deliverable/documents
- minutes # meeting protocols
- budget.sxc
- calendar.sxc
- ...
- www # website-related stuff (needs its own reconsideration)
-
-
-The idea is that developers can use a simple url::
-
- svn co https://codespeak.net/svn/pypy/dist dist-pypy
-
-in order to get everything neccessary for sourcecode, documentation
-and test development. Obviously, if you care about the EU-funding
-or web site application/contents you can do an appropriate checkout
-as well. The extradoc contains information interesting to
-developers and other open source projects (seeking funding or not).
-
-Note, that having documentation inside the source tree will help
-with keeping a closer eye on documentation - especially when we
-have special ref-integrity tests for the documentation (which itself
-should reference real source-code/functions at some point). For
-example, the refactoring of unitest.py-style tests to `py.test`_ based ones
-"forgot" to modify our test-documentation in the too-far-away doc-folder.
-We should move to a scheme where such an omission will raise real
-test errors.
-
-.. _`py.test`: http://codespeak.net/py/current/doc/test.html
-
Modified: pypy/dist/pypy/documentation/redirections
==============================================================================
--- pypy/dist/pypy/documentation/redirections (original)
+++ pypy/dist/pypy/documentation/redirections Sun Apr 17 22:08:23 2005
@@ -14,5 +14,8 @@
'howtosvn.html' : 'getting_started.html#howtosvn',
'checking_ReST.html' : 'coding-style.html#pypy-documentation',
'optionaltools.html' : 'coding-style.html#optionaltool',
+
+ 'newrepolayout.html' : 'future.html#newrepolayout',
+ 'goals.html' : 'future.html#goals',
}
More information about the Pypy-commit
mailing list