[pypy-svn] rev 1252 - in pypy/trunk/doc: . devel objspace sprintinfo

hpk at codespeak.net hpk at codespeak.net
Fri Aug 1 01:07:03 CEST 2003


Author: hpk
Date: Fri Aug  1 01:07:00 2003
New Revision: 1252

Added:
   pypy/trunk/doc/sprintinfo/Hildesheim.txt
Removed:
   pypy/trunk/doc/devel/builtins.txt
   pypy/trunk/doc/devel/using-testsupport.txt
   pypy/trunk/doc/sprintinfo/hildesheim.txt
   pypy/trunk/doc/sprintinfo/llnsprint-brainstorming.txt
Modified:
   pypy/trunk/doc/devel/coding-style.txt
   pypy/trunk/doc/devel/testdesign.txt
   pypy/trunk/doc/objspace/abstractobjspace.txt
   pypy/trunk/doc/objspace/annotateobjspace.txt
   pypy/trunk/doc/objspace/stdobjspace.txt
   pypy/trunk/doc/objspace/trivialobjspace.txt
   pypy/trunk/doc/readme.txt
   pypy/trunk/doc/sprintinfo/LouvainLaNeuveReport.txt
   pypy/trunk/doc/sprintinfo/sprint-planning.txt
Log:
- fixed various documentation issues

- removed 'builtins.txt' because it's horribly outdated and i doubt
  that anybody consults it instead of pypy/module/builtin.py 

- changed the focus of 'sprint-planning' to the spurious past. 

- removed bogus 'using-testsupport' "documentation". 

- removed llnsprint-brainstorming.txt into Hildesheim.txt where
  it belonged (it's an old brainstorm :-)



Deleted: /pypy/trunk/doc/devel/builtins.txt
==============================================================================
--- /pypy/trunk/doc/devel/builtins.txt	Fri Aug  1 01:07:00 2003
+++ (empty file)
@@ -1,152 +0,0 @@
-# this is just a list of the builtins from 2.2.3c1
-# we expect to annotate the file with comments about ease of 
-# implementation & implemented-ness of each builtin
-
-annotations: status/difficulty/strategy/urgency
-
-d == done
-p == written, but the are problems
-w == it works, but has not the full functionality
-n == need to be done
-
-e == easy
-h == hard
-
-o == essentially implemented by the objectspace
-p == just write it in python
-v == variable
-t == type
-m == messy
-
-u == urgent
-i == important
-n == normal
-d == really don't care
-r == resolved, done
-U == unsupported
-
-For now, all exception names are synonyms (until inheritance happens).
-
-+ ArithmeticError
-+ AssertionError
-+ AttributeError
-++DeprecationWarning
-+ EOFError
-+ EnvironmentError
-+ Exception
-+ FloatingPointError
-+ IOError
-+ ImportError
-+ IndentationError
-+ IndexError
-+ KeyError
-+ KeyboardInterrupt
-+ LookupError
-+ MemoryError
-+ NameError
-+ NotImplementedError
-+ OSError
-+ OverflowError
-++OverflowWarning
-+ ReferenceError
-+ RuntimeError
-++RuntimeWarning
-+ StandardError
-+ StopIteration
-+ SyntaxError
-++SyntaxWarning
-+ SystemError
-+ SystemExit
-+ TabError
-+ TypeError
-+ UnboundLocalError
-+ UnicodeError
-++UserWarning
-+ ValueError
-++Warning
-+ ZeroDivisionError
-
-Ellipsis
-False
-None
-NotImplemented
-True
-
- -- all singletons.
-
-ev __debug__
-ev __doc__
-
-
-whmu __import__
-nevd __name__
-deon abs
-deon apply
-n ti bool
-nhtd buffer
-nhpn callable
-deon chr
-nhtn classmethod
-n pn cmp
-nhmd coerce
-nemn compile -- will need to become hard later
-n pn complex
-nepv copyright
-nepv credits
-deon delattr
-n tn dict
-nhpn dir
-nepn divmod -- maybe should do more later
-n pi eval
-n pn execfile
-n v  exit
-nhtu file -- ouch.  maybe use Guido's sio stuff?
-          -- also, can probably escape to the host impl. for now
-n pn filter
-n tn float
-deoi getattr
-nepn globals
-depn hasattr -- err, maybe not easy if all exceptions are the same
-deon hash
-nepn help
-deon hex
-deon id
-nepd input
-n t  int
-n md intern
-dhpi isinstance
-phoi issubclass
-p oi iter
-deoi len
-n v  license
-n ti list
-nemn locals -- maybe will become harder later
-n t  long
-d pn map
-n pn max
-n pn min
-n t  object
-neon oct
-nhtu open -- see file, they're the same
-deon ord -- chr
-deon pow
-n t  property
-n v  quit -- (see exit)
-d pi range
-nepn raw_input
-n pn reduce
-nhpn reload
-deon repr
-nepn round
-deoi setattr
-n t  slice
-n t  staticmethod
-d t  str
-n t  super
-n t  tuple
-n t  type
-neon unichr
-n t  unicode
-nepn vars
-n t  xrange -- alias to range for now?
-nepn zip

Modified: pypy/trunk/doc/devel/coding-style.txt
==============================================================================
--- pypy/trunk/doc/devel/coding-style.txt	(original)
+++ pypy/trunk/doc/devel/coding-style.txt	Fri Aug  1 01:07:00 2003
@@ -97,18 +97,10 @@
 
 - every non-test file is forbidden to start with "t"
 
-- each test directory needs a copy of testsupport.py. see using-testsupport_ for more information.
+- each test directory needs a copy of pypy/tool/autopath.py.
 
-- see information at test-design_
-
-Miscellaneous stuff
----------------------
-
-To edit wiki pages do:
-
-``svn co http://codespeak.net/svn/pypy/trunk/www/moininstance/data/text wiki-pages``
+- see some more information about tests at the test-design_ document. 
 
 ------------------------------------------------------------------------------------------
 
 .. _test-design: ../devel/testdesign.html
-.. _using-testsupport: ../devel/using-testsupport.html
\ No newline at end of file

Modified: pypy/trunk/doc/devel/testdesign.txt
==============================================================================
--- pypy/trunk/doc/devel/testdesign.txt	(original)
+++ pypy/trunk/doc/devel/testdesign.txt	Fri Aug  1 01:07:00 2003
@@ -2,26 +2,46 @@
 Test Design
 =============
 
-Our tests are based on the unittest framework. Tests for modules usually reside in a subdirectory called "test".
+Our tests are based on the unittest framework.  All tests of modules in a directory usually reside 
+in a subdirectory **test**.  There are basically two types of unit tests:
 
-If you write a test, then you usually have the following lines at the start of your test::
+- **Interpreter Level tests**. They run at the same level as PyPy's interpreter. 
+
+- **Application Level tests**. They run at application level which means
+  that they look like straight python code but they are interpreted by PyPy.
+
+Both types of tests need an object-space they can run with (the interpreter
+dispatches operations on objects to an objectspace).  If you run a test you
+can usually give the '-S', '-T' or '-A' switch for using the Standard, Trivial
+or Ann-ObjectSpace respectively. 
+
+
+Writing a test 
+--------------
+
+The best reference is to go to some test files and look how they are done. 
+Almost all tests start with the following lines::
 
  import autopath
  from pypy.tool import test
 
-For the time being, please refer to a pypy-dev mail_ for more info.
+of which the first line determines the package path automatically by searching
+for 'pypy' among the parents of the test-file's directory.  The second
+line imports PyPy's test-hook of which ''test.main()'' is the most important
+and is usually the last line of the testfile. 
+For more  info please refer to a pypy-dev mail_ where the current testing
+framework was introduced. 
 
 
 Command line tool test_all
 ---------------------------
 
-PyPy's current testing framework (since revision 831) is driven by the command line src/pypy/test_all.py tool. Simply change to the pypy root directory and issue::
-
+You can run almost all of PyPy's tests by invoking::
 
   python test_all.py
 
-
-which will run all tests against the Trivial Object Space. If you want to test against the StandardObjectSpace then issue::
+which will run all tests against the Trivial Object Space. If you want 
+to test against the StandardObjectSpace then issue::
 
 
   python test_all.py -S

Deleted: /pypy/trunk/doc/devel/using-testsupport.txt
==============================================================================
--- /pypy/trunk/doc/devel/using-testsupport.txt	Fri Aug  1 01:07:00 2003
+++ (empty file)
@@ -1,23 +0,0 @@
-=======================
-Using testsupport
-=======================
-
-file ``testsupport.py`` should be copied into every test subdirectory.
-The main copy lives in ``pypy/testsupport.py`` Use::
-
-  import testsupport
-
-to fix the path so that all 'import pypy.something' should work.
-
-Module testsupport also exposes the following:
-+    main       a function just like unittest.main
-+    TestCase   a class just like unittest.TestCase but with extra methods
-+    objspace   the object space class to be used in this test
-
-``testsupport.objspace`` is normally the trivial object space, but you
-can set it (via an environment variable set before running Python)
-to be the standard object space instead.  Specifically::
-
-   set OBJSPACE=pypy.objspace.std.objspace.StdObjSpace
-
-(or equivalent syntax depending on your shell) does the job.
\ No newline at end of file

Modified: pypy/trunk/doc/objspace/abstractobjspace.txt
==============================================================================
--- pypy/trunk/doc/objspace/abstractobjspace.txt	(original)
+++ pypy/trunk/doc/objspace/abstractobjspace.txt	Fri Aug  1 01:07:00 2003
@@ -2,10 +2,8 @@
 AbstractObjectSpace
 =======================
 
-User History
-------------------------
-
-This is an example of abstract interpretation, i.e. following the bytecode instructions of a program like an interpreter does but with abstract objects instead of concrete ones. Remember that in PyPy this is done by using alternate object spaces with the same interpreter main loop.
+We currently don't really have an AbstractObjSpace but an AnnotateObjSpace_ (or AnnSpace for short)
+which comes close to it.  Abstract Interpretation means to the bytecode instructions of a program like an interpreter does but with abstract objects instead of concrete ones. Remember that in PyPy this is done by using alternate object spaces with the same interpreter main loop.
 
 The most abstract object space is the one manipulating the most abstract objects that you could imagine: they are all equivalent, because we have abstracted away any information about the object. There is actually only one of them left, and we can call it "the object". In Python terms, our AbstractObjectSpace uses None for all its wrapped objects. Any operation between wrapped objects gives None again as the wrapped result -- there is nothing else it could give anyway. So when you have said that the add method of AbstractObjectSpace takes None and None and returns None you have said everything.
 
@@ -14,3 +12,5 @@
 Typically, however, abstract object spaces are a (little) bit less abstract, still maintaining a minimal amount of information about the objects. For example, a wrapped object could be represented by its type. You then define the object space's add to return int when the two arguments are int and int. That way, you abstractedly call a function with the input argument's types and what the interpreter will do is a type inference. (Here also there are subtle problems, even besides the remark that integer operations can overflow and actually return longs in a real Python implementation.)
 
 As an example of more abstract object spaces you have the ones with finite domain, i.e. with a finite number of different possible wrapped objects. For example, you can use True and False as wrapped values to denote the fact that the object is, respectively, a non-negative integer or anything else. In this way you are doing another kind of type inference that just tells you which variables will only ever contain non-negative integers.
+
+.. _AnnotatedObjSpace: annotateobjspace.html

Modified: pypy/trunk/doc/objspace/annotateobjspace.txt
==============================================================================
--- pypy/trunk/doc/objspace/annotateobjspace.txt	(original)
+++ pypy/trunk/doc/objspace/annotateobjspace.txt	Fri Aug  1 01:07:00 2003
@@ -4,10 +4,7 @@
 
 was TranslateObjectSpace
 -------------------------
-This has been renamed and is currently being re-written. Old information follows:
-
-User History
-------------------
+This has been renamed and is currently being re-written. Older information follows:
 
 This is an example of an ObjectSpace that differs a lot from StandardObjectSpace_.
 

Modified: pypy/trunk/doc/objspace/stdobjspace.txt
==============================================================================
--- pypy/trunk/doc/objspace/stdobjspace.txt	(original)
+++ pypy/trunk/doc/objspace/stdobjspace.txt	Fri Aug  1 01:07:00 2003
@@ -2,9 +2,6 @@
 StandardObjectSpace
 =========================
 
-User History
----------------
-
 The StandardObjectSpace is the direct equivalent of CPython's object library (the "Objects/" subdirectory in the distribution). It is an implementation of the common Python types in a lower-level language.
 
 The StandardObjectSpace defines an abstract parent class, W_Object, and a bunch of subclasses like W_IntObject, W_ListObject, and so on. A wrapped object (a "black box" for the interpreter main loop) is thus an instance of one of these classes. When the main loop invokes an operation, say the addition, between two wrapped objects w1 and w2, the StandardObjectSpace does some internal dispatching (similar to "Object/ abstract.c" in CPython) and invokes a method of the proper W_XyzObject class that can do the operation. The operation itself is done with the primitives allowed by RestrictedPython. The result is constructed as a wrapped object again. For example, compare the following implementation of integer addition with the function "int_add()" in "Object/intobject.c": ::
@@ -28,4 +25,4 @@
 ---------------------------------------------------------------------------
 
 .. _StandardObjectSpace: stdobjspace.html
-.. _MultiMethod: multimethod.html
\ No newline at end of file
+.. _MultiMethod: multimethod.html

Modified: pypy/trunk/doc/objspace/trivialobjspace.txt
==============================================================================
--- pypy/trunk/doc/objspace/trivialobjspace.txt	(original)
+++ pypy/trunk/doc/objspace/trivialobjspace.txt	Fri Aug  1 01:07:00 2003
@@ -2,9 +2,6 @@
 PyPython Trivial Object Space
 =================================
 
-User History
-----------------
-
 The easiest way to implement an Object Space is to represent a Python object with itself.
 
 A PyPy interpreter using the Trivial Object Space is an interpreter with its own main loop (written in Python), but this main loop manipulates real Python objects and all operations are done directly on the Python objects. For example, "1" really means "1" and when the interpreter encounters the BINARY_ADD bytecode instructions the TrivialObjectSpace will just add two real Python objects together using Python's "+". The same for lists, dictionaries, classes... We just use Python's own.

Modified: pypy/trunk/doc/readme.txt
==============================================================================
--- pypy/trunk/doc/readme.txt	(original)
+++ pypy/trunk/doc/readme.txt	Fri Aug  1 01:07:00 2003
@@ -2,19 +2,21 @@
 PyPy Documentation
 =====================
 
-PyPy documentation generally is generated from reST textfiles in the /doc directory of
+PyPy documentation is generated from reST textfiles in the /doc directory of
 our pypy-subversion repository.  On the pypy home page you'll find a "doc" link that
 shows you a list of recently modified documents.  While in "doc-view" you also have
 a navigation area on the left side which maps all documentation. 
 
-Please add new or updated documentation by checking it in to the appropriate directory in subversion, usually under http://codespeak.net/svn/pypy/trunk/doc/.
+Please add new or updated documentation by checking it in to the appropriate 
+directory in subversion, usually under http://codespeak.net/svn/pypy/trunk/doc/.  
 
 + Remember to run ``svn up`` **before** doing any commit.
 + All filenames should be lowercase, and documentation should be .txt files.
 + Mark-up the documentation with reST so it can generate a pretty html version.
 + On the server side a commit on the doc-subtree will immediately update the webpage. 
 
-*Note*  If you don't markup the textfile, it'll still be checked in, but when docutils runs the parser, it'll look ugly on the website. So run docutils yourself before you commit it. 
+*Note*  If you don't markup the textfile, it'll still be checked in, but when docutils 
+runs the parser, it'll look ugly on the website. So run docutils yourself before you commit it. 
 
 Some reST basics:
 ------------------

Added: pypy/trunk/doc/sprintinfo/Hildesheim.txt
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/sprintinfo/Hildesheim.txt	Fri Aug  1 01:07:00 2003
@@ -0,0 +1,113 @@
+Hildesheim Sprint Report
+========================
+
+The Hildesheim Sprint provided a chance to meet and decide several crucial design considerations. 
+A #pypy irc channel provided communication among participants between sprints. The sourcecode 
+was loaded into subversion and participants given commit rights.
+
+At the Sprint:
+Some folks did lots of handwaving and created really kewl concepts. Other pairs concentrated on coding, testing, builtin functions etc etc. We gathered for goalsetting meetings several times during the sprint, then split up to work on tasks. Half of the work was done by pair programming. Pairs were informal, developing and changing as tasks were discovered and completed. Sprints varied in amount of "discuss as a group" and "just do it" time. We spent lots of intense time together, not just coding but also social time, (meals, spending a day playing tourist, etc), which enhanced the building of relationships and understanding among sprinters.
+
+Some discoveries: Plan on the first morning for hardware setup and fixing system issues, (wireless is great!) Built-in private time is necessary for the sprint. Whiteboards and projectors are both necessary, as is coffee and tea. Bringing in/providing food is fine but getting people away for lunch is good to clear their minds. Leadership varied throughout the sprints and throughout the day.
+
+
+
+Brainstorming about what PyPy might be
+--------------------------------------
+
+The following was written down at the first Sprint to understand
+each other's motivations and ideas.  It's not very sorted but
+might still be interesting to skim. 
+
+- Python interpreter written in python
+    - loads bytecode
+    - delegates/dispatches to ObjectSpaces to implement operations
+      on the objects
+    - there can be more than one ObjectSpace
+        - for example: BorrowingObjectSpace (from CPython)
+    - define/implement a class that emulates the Python 
+      Execution Frame
+
+- use the main-loop of the interpreter to do a lot of
+  things (e.g. do type inference during running the bytecode 
+  or not even run the bytecodes, but interpret various attributes of the code) 
+
+- working together, producing something real
+
+- saving interpreter state to an image (following the smalltalk model)
+  process-migration / persistence
+
+- looking at the entire code base (living in an image), browsing 
+  objects interactively 
+
+- interactive environment, trying code snippets, introspection
+
+- deploying python made easy, integrate version control systems
+
+- integrate the various technologies on the web site, issue tracking,
+  Wiki...
+
+- seperate exception handling from the mainline code, avoid peppering
+  your code with try :-), put exception handling into objects.
+
+- import python code from the version control store directly, give
+  imported code also a time dimension 
+
+- combining python interpreters from multiple machines (cluster) into a
+  virtual sandbox (agent space?) 
+
+- get a smaller (maybe faster) python with very few C-code
+
+- (hoping for Psyc) to render fast code from Python code (instead of
+  hard-c)
+
+- go to a higher level python core (and write out/generate interpreters
+  in different languages), e.g. the former P-to-C resolved the evalframe-loop
+  but still called into the Python-C-library which is statically coded
+
+- very far fetched: PyPython becomes a/the reference implementation
+ 
+- have enough flexibility to make a separate stackless obsolete
+
+- have a language that is high-level/easy enough to program
+  but with the same performance as statically compiled languages
+  (e.g. C++)
+
+
+what is the difference between a compiler and an interpreter
+------------------------------------------------------------
+
+f = bytecode interpreter
+p = program
+a = arguments
+
+c = compiler
+
+assert f(p, a) == c(p)(a) == r
+
+
+-  architecture overview
+    * byte code interp loop
+      plan how the interp loop should look like from a hi level
+      map that structure in descriptions that can be used to generate interpreters/compilers
+      define the frame structure
+
+    * define a object/type model that maps into python data structures
+      wrap cpython objects into the new object model so we can continue
+      to use cpython modules
+    
+    * rewrite c python modules and the builtin object library in python
+      optimzation for a potential global python optimizer, until that
+      exists it will be slower than the corresponding cpython implementation
+
+- import the cpython distribution so we can use parts of it in our
+  repository, make it easy to follow the cpython development
+
+- finish the python to byte code compiler in python project (this is
+  already part of the cpython distribution, needs a python lexer)
+
+- doing other things than interpreting byte code from the python interp
+  loop, for example generate C code, implement other object spaces in our
+  terminlogy other far fetched things with execution
+
+- how to enter c ysystem calls into the python object space (ctypes)

Modified: pypy/trunk/doc/sprintinfo/LouvainLaNeuveReport.txt
==============================================================================
--- pypy/trunk/doc/sprintinfo/LouvainLaNeuveReport.txt	(original)
+++ pypy/trunk/doc/sprintinfo/LouvainLaNeuveReport.txt	Fri Aug  1 01:07:00 2003
@@ -63,7 +63,7 @@
 
 - bugfixes, refactorings and adding tests all over the place 
   (everybody)
-  
+
 ---------------------------------------------------------------
 
 .. _boolobject: http://codespeak.net/pipermail/pypy-svn/2003-June/000381.html

Deleted: /pypy/trunk/doc/sprintinfo/hildesheim.txt
==============================================================================
--- /pypy/trunk/doc/sprintinfo/hildesheim.txt	Fri Aug  1 01:07:00 2003
+++ (empty file)
@@ -1,11 +0,0 @@
-Hildesheim Sprint Report
-========================
-
-The Hildesheim Sprint provided a chance to meet and decide several crucial design considerations. 
-A #pypy irc channel provided communication among participants between sprints. The sourcecode 
-was loaded into subversion and participants given commit rights.
-
-At the Sprint:
-Some folks did lots of handwaving and created really kewl concepts. Other pairs concentrated on coding, testing, builtin functions etc etc. We gathered for goalsetting meetings several times during the sprint, then split up to work on tasks. Half of the work was done by pair programming. Pairs were informal, developing and changing as tasks were discovered and completed. Sprints varied in amount of "discuss as a group" and "just do it" time. We spent lots of intense time together, not just coding but also social time, (meals, spending a day playing tourist, etc), which enhanced the building of relationships and understanding among sprinters.
-
-Some discoveries: Plan on the first morning for hardware setup and fixing system issues, (wireless is great!) Built-in private time is necessary for the sprint. Whiteboards and projectors are both necessary, as is coffee and tea. Bringing in/providing food is fine but getting people away for lunch is good to clear their minds. Leadership varied throughout the sprints and throughout the day.

Deleted: /pypy/trunk/doc/sprintinfo/llnsprint-brainstorming.txt
==============================================================================
--- /pypy/trunk/doc/sprintinfo/llnsprint-brainstorming.txt	Fri Aug  1 01:07:00 2003
+++ (empty file)
@@ -1,95 +0,0 @@
-
-General ideas of what PyPy should achieve for us
-
-- Python interpreter written in python
-    - loads bytecode
-    - delegates/dispatches to ObjectSpaces to implement operations
-      on the objects
-    - there can be more than one ObjectSpace
-        - for example: BorrowingObjectSpace (from CPython)
-    - define/implement a class that emulates the Python 
-      Execution Frame
-
-- use the main-loop of the interpreter to do a lot of
-  things (e.g. do type inference during running the bytecode 
-  or not even run the bytecodes, but interpret various attributes of the code) 
-
-- working together, producing something real
-
-- saving interpreter state to an image (following the smalltalk model)
-  process-migration / persistence
-
-- looking at the entire code base (living in an image), browsing 
-  objects interactively 
-
-- interactive environment, trying code snippets, introspection
-
-- deploying python made easy, integrate version control systems
-
-- integrate the various technologies on the web site, issue tracking,
-  Wiki...
-
-- seperate exception handling from the mainline code, avoid peppering
-  your code with try :-), put exception handling into objects.
-
-- import python code from the version control store directly, give
-  imported code also a time dimension 
-
-- combining python interpreters from multiple machines (cluster) into a
-  virtual sandbox (agent space?) 
-
-- get a smaller (maybe faster) python with very few C-code
-
-- (hoping for Psyc) to render fast code from Python code (instead of
-  hard-c)
-
-- go to a higher level python core (and write out/generate interpreters
-  in different languages), e.g. the former P-to-C resolved the evalframe-loop
-  but still called into the Python-C-library which is statically coded
-
-- very far fetched: PyPython becomes a/the reference implementation
- 
-- have enough flexibility to make a separate stackless obsolete
-
-- have a language that is high-level/easy enough to program
-  but with the same performance as statically compiled languages
-  (e.g. C++)
-
-
-what is the difference between a compiler and an interpreter
-------------------------------------------------------------
-
-f = bytecode interpreter
-p = program
-a = arguments
-
-c = compiler
-
-assert f(p, a) == c(p)(a) == r
-
-
--  architecture overview
-    * byte code interp loop
-      plan how the interp loop should look like from a hi level
-      map that structure in descriptions that can be used to generate interpreters/compilers
-      define the frame structure
-
-    * define a object/type model that maps into python data structures
-      wrap cpython objects into the new object model so we can continue
-      to use cpython modules
-    
-    * rewrite c python modules and the builtin object library in python
-      optimzation for a potential global python optimizer, until that
-      exists it will be slower than the corresponding cpython implementation
-
-- import the cpython distribution so we can use parts of it in our
-  repository, make it easy to follow the cpython development
-
-- finish the python to byte code compiler in python project (this is
-  already part of the cpython distribution, needs a python lexer)
-
-- doing other things than interpreting byte code from the python interp
-  loop, for example generate C code, implement other object spaces in our
-  terminlogy other far fetched things with execution
-
-- how to enter c ysystem calls into the python object space (ctypes)

Modified: pypy/trunk/doc/sprintinfo/sprint-planning.txt
==============================================================================
--- pypy/trunk/doc/sprintinfo/sprint-planning.txt	(original)
+++ pypy/trunk/doc/sprintinfo/sprint-planning.txt	Fri Aug  1 01:07:00 2003
@@ -1,77 +1,30 @@
-LouvainLaNeuveSprint planning
+Sprint Planning
+---------------
 
---> join this screen: ssh codespeak.net "and" screen -x hpk/hpk
+Here is a list of things we might want to do at one of the next sprints.  
+Currently it's roughly what is left over from the last sprints. 
 
-eternal goals:
 - do more tests (eternal goal)
-- Fix XXX-marked things 
+
+- Fix XXX-marked things  (eternal goal)
 
 - enhance StdObjSpace, define goals and achieve them
   http://codespeak.net/svn/pypy/trunk/src/goals/
 
-  - Being able to run main.py dis.dis(dis.dis)
-  - Unbound methods.
   - support the objects we see falling back to CPython.
   - more builtins.
   - more things from sys.
   - dict object/type 
     - Hash table based implementation of dictionaries?
   - list object/type   
-  - check all other type implementation and document their state:
-
-    alex, christian
-
--       boolobject       review done boolobject_
--       cpythonobject    review done cpythonobj_
--	instmethobject   review done instmethod_
--	longobject       review done removed long_
--	sliceobject      review done sliceobject_
--	userobject       review done userobject_
--	dictobject       review done dictobject_
--	iterobject       review done iterobject_
--	tupleobject
--	listobject
--	intobject inprocess intobject_
--	floatobject
-
-    tomek, holger, guenter
-
-        moduleobject     review done
-        stringobject
-        noneobject
-
   - write a small tool that checks a type's methods of
     CPython against PyPy
     (Jacob, Laura)  done
 
-- improve "main.py" tool and rename it to "py.py" :-)
-  with a subset of the options of "python". This
-  should allow executing commands (-c), going
-  interactive (-i) and executing files (argv[1])
-
-  -  Fix the way an OBJECTSPACE is selected. ?
-  -  main.py doesn't handle exceptions very well.
-
-  (michael)
-
-- move design documentation from wiki to subversion
-  (doc/design) to make it locally editable (instead
-  of html-textfields) and keep everyone up-to-date
-  maybe rearrange the doc-directory to be into src/pypy
-
-  (Anna, Laura)
-
 - go through the wiki and clean up "stale" or old pages
 
-- implement AnnotationObjSpace and the beginnings
-  of a C code generator. the basic idea is "abstract
-  interpretation"....
-
-  - getting the translator to understand RPython, handling the
-    constructions it can and delegating the things it doesn't
-    understand to CPython (Mimicking Python2C)
-
-  (Armin, Guido)
+- implement the beginnings of a C code generator. the basic idea 
+  is "abstract interpretation"....
 
 - discuss funding and future organization issues
 


More information about the Pypy-commit mailing list