[pypy-svn] pypy documentation-cleanup: (lac, cfbolz): kill lots of useless discussion files, add XXXs about more that could be killed.

cfbolz commits-noreply at bitbucket.org
Mon Apr 25 12:27:36 CEST 2011


Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: documentation-cleanup
Changeset: r43570:77352a4c722f
Date: 2011-04-25 12:27 +0200
http://bitbucket.org/pypy/pypy/changeset/77352a4c722f/

Log:	(lac, cfbolz): kill lots of useless discussion files, add XXXs about
	more that could be killed.

diff --git a/pypy/doc/discussion/thoughts_string_interning.rst b/pypy/doc/discussion/thoughts_string_interning.rst
deleted file mode 100644
--- a/pypy/doc/discussion/thoughts_string_interning.rst
+++ /dev/null
@@ -1,211 +0,0 @@
-String Interning in PyPy
-========================
-
-A few thoughts about string interning. CPython gets a remarkable
-speed-up by interning strings. Interned are all builtin string
-objects and all strings used as names. The effect is that when
-a string lookup is done during instance attribute access,
-the dict lookup method will find the string always by identity,
-saving the need to do a string comparison.
-
-Interned Strings in CPython
----------------------------
-
-CPython keeps an internal dictionary named ``interned`` for all of these
-strings. It contains the string both as key and as value, which means
-there are two extra references in principle. Upto Version 2.2, interned
-strings were considered immortal. Once they entered the ``interned`` dict,
-nothing could revert this memory usage.
-
-Starting with Python 2.3, interned strings became mortal by default.
-The reason was less memory usage for strings that have no external
-reference any longer. This seems to be a worthwhile enhancement.
-Interned strings that are really needed always have a real reference.
-Strings which are interned for temporary reasons get a big speed up
-and can be freed after they are no longer in use.
-
-This was implemented by making the ``interned`` dictionary a weak dict,
-by lowering the refcount of interned strings by 2. The string deallocator
-got extra handling to look into the ``interned`` dict when a string is deallocated.
-This is supported by the state variable on string objects which tells
-whether the string is not interned, immortal or mortal.
-
-Implementation problems for PyPy
---------------------------------
-
-- The CPython implementation makes explicit use of the refcount to handle
-  the weak-dict behavior of ``interned``. PyPy does not expose the implementation
-  of object aliveness. Special handling would be needed to simulate mortal
-  behavior. A possible but expensive solution would be to use a real
-  weak dictionary. Another way is to add a special interface to the backend
-  that allows either the two extra references to be reset, or for the
-  boehm collector to exclude the ``interned`` dict from reference tracking.
-
-- PyPy implements quite complete internal strings, as opposed to CPython
-  which always uses its "applevel" strings. It also supports low-level
-  dictionaries. This adds some complication to the issue of interning.
-  Additionally, the interpreter currently handles attribute access
-  by calling wrap(str) on the low-level attribute string when executing 
-  frames. This implies that we have to primarily intern low-level strings
-  and cache the created string objects on top of them.
-  A possible implementation would use a dict with ll string keys and the
-  string objects as values. In order to save the extra dict lookup, we also
-  could consider to cache the string object directly on a field of the rstr,
-  which of course adds some extra cost. Alternatively, a fast id-indexed
-  extra dictionary can provide the mapping from rstr to interned string object.
-  But for efficiency reasons, it is anyway necessary to put an extra flag about
-  interning on the strings. Flagging this by putting the string object itself
-  as the flag might be acceptable. A dummyobject can be used if the interned
-  rstr is not exposed as an interned string object.
-
-Update: a reasonably simple implementation
--------------------------------------------
-
-Instead of the complications using the stringobject as a property of an rstr
-instance, I propose to special case this kind of dictionary (mapping rstr
-to stringobject) and to put an integer ``interned`` field into the rstr. The
-default is -1 for not interned. Non-negative values are the direct index
-of this string into the interning dict. That is, we grow an extra function
-that indexes the dict by slot number of the dict table and gives direct
-access to its value. The dictionary gets special handling on dict_resize,
-to recompute the slot numbers of the interned strings. ATM I'd say we leave
-the strings immortal and support mortality later when we have a cheap
-way to express this (less refcount, exclusion from Boehm, whatever).
-
-A prototype brute-force patch
------------------------------
-
-In order to get some idea how efficient string interning is at the moment,
-I implemented a quite crude version of interning. I patched space.wrap
-to call this intern_string instead of W_StringObject::
-
- def intern_string(space, str):
-     if we_are_translated():
-         _intern_ids = W_StringObject._intern_ids
-         str_id = id(str)
-         w_ret = _intern_ids.get(str_id, None)
-         if w_ret is not None:
-             return w_ret
-         _intern = W_StringObject._intern
-         if str not in _intern:
-             _intern[str] = W_StringObject(space, str)
-         W_StringObject._intern_keep[str_id] = str
-         _intern_ids[str_id] = w_ret = _intern[str]
-         return w_ret
-     else:
-         return W_StringObject(space, str)
-
-This is no general solution at all, since it a) does not provide
-interning of rstr and b) interns every app-level string. The
-implementation is also by far not as efficient as it could be,
-because it utilizes an extra dict _intern_ids which maps the
-id of the rstr to the string object, and a dict _intern_keep to
-keep these ids alive.
-
-With just a single _intern dict from rstr to string object, the
-overall performance degraded slightly instead of an advantage.
-The triple dict patch accelerates richards by about 12 percent.
-Since it still has the overhead of handling the extra dicts,
-I guess we can expect twice the acceleration if we add proper
-interning support.
-
-The resulting estimated 24 % acceleration is still not enough
-to justify an implementation right now.
-
-Here the results of the richards benchmark::
-
-  D:\pypy\dist\pypy\translator\goal>pypy-c-17516.exe -c "from richards import *;Richards.iterations=1;main()"
-  debug: entry point starting
-  debug:  argv -> pypy-c-17516.exe
-  debug:  argv -> -c
-  debug:  argv -> from richards import *;Richards.iterations=1;main()
-  Richards benchmark (Python) starting... [<function entry_point at 0xeae060>]
-  finished.
-  Total time for 1 iterations: 38 secs
-  Average time for iterations: 38885 ms
-  
-  D:\pypy\dist\pypy\translator\goal>pypy-c.exe -c "from richards import *;Richards.iterations=1;main()"
-  debug: entry point starting
-  debug:  argv -> pypy-c.exe
-  debug:  argv -> -c
-  debug:  argv -> from richards import *;Richards.iterations=1;main()
-  Richards benchmark (Python) starting... [<function entry_point at 0xead810>]
-  finished.
-  Total time for 1 iterations: 34 secs
-  Average time for iterations: 34388 ms
-  
-  D:\pypy\dist\pypy\translator\goal>
-
-
-This was just an exercise to get an idea. For sure this is not to be checked in.
-Instead, I'm attaching the simple patch here for reference.
-::
-
-  Index: objspace/std/objspace.py
-  ===================================================================
-  --- objspace/std/objspace.py	(revision 17526)
-  +++ objspace/std/objspace.py	(working copy)
-  @@ -243,6 +243,9 @@
-                   return self.newbool(x)
-               return W_IntObject(self, x)
-           if isinstance(x, str):
-  +            # XXX quick speed testing hack
-  +            from pypy.objspace.std.stringobject import intern_string
-  +            return intern_string(self, x)
-               return W_StringObject(self, x)
-           if isinstance(x, unicode):
-               return W_UnicodeObject(self, [unichr(ord(u)) for u in x]) # xxx
-  Index: objspace/std/stringobject.py
-  ===================================================================
-  --- objspace/std/stringobject.py	(revision 17526)
-  +++ objspace/std/stringobject.py	(working copy)
-  @@ -18,6 +18,10 @@
-   class W_StringObject(W_Object):
-       from pypy.objspace.std.stringtype import str_typedef as typedef
-   
-  +    _intern_ids = {}
-  +    _intern_keep = {}
-  +    _intern = {}
-  +
-       def __init__(w_self, space, str):
-           W_Object.__init__(w_self, space)
-           w_self._value = str
-  @@ -32,6 +36,21 @@
-   
-   registerimplementation(W_StringObject)
-   
-  +def intern_string(space, str):
-  +    if we_are_translated():
-  +        _intern_ids = W_StringObject._intern_ids
-  +        str_id = id(str)
-  +        w_ret = _intern_ids.get(str_id, None)
-  +        if w_ret is not None:
-  +            return w_ret
-  +        _intern = W_StringObject._intern
-  +        if str not in _intern:
-  +            _intern[str] = W_StringObject(space, str)
-  +        W_StringObject._intern_keep[str_id] = str
-  +        _intern_ids[str_id] = w_ret = _intern[str]
-  +        return w_ret
-  +    else:
-  +        return W_StringObject(space, str)
-   
-   def _isspace(ch):
-       return ord(ch) in (9, 10, 11, 12, 13, 32)  
-  Index: objspace/std/stringtype.py
-  ===================================================================
-  --- objspace/std/stringtype.py	(revision 17526)
-  +++ objspace/std/stringtype.py	(working copy)
-  @@ -47,6 +47,10 @@
-       if space.is_true(space.is_(w_stringtype, space.w_str)):
-           return w_obj  # XXX might be reworked when space.str() typechecks
-       value = space.str_w(w_obj)
-  +    # XXX quick hack to check interning effect
-  +    w_obj = W_StringObject._intern.get(value, None)
-  +    if w_obj is not None:
-  +        return w_obj
-       w_obj = space.allocate_instance(W_StringObject, w_stringtype)
-       W_StringObject.__init__(w_obj, space, value)
-       return w_obj
-
-ciao - chris

diff --git a/pypy/doc/discussion/howtoimplementpickling.rst b/pypy/doc/discussion/howtoimplementpickling.rst
--- a/pypy/doc/discussion/howtoimplementpickling.rst
+++ b/pypy/doc/discussion/howtoimplementpickling.rst
@@ -1,3 +1,5 @@
+.. XXX think more, some of this might be useful
+
 Designing thread pickling or "the Essence of Stackless Python"
 --------------------------------------------------------------
 

diff --git a/pypy/doc/discussion/testing-zope.rst b/pypy/doc/discussion/testing-zope.rst
deleted file mode 100644
--- a/pypy/doc/discussion/testing-zope.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-Testing Zope on top of pypy-c
-=============================
-
-Getting Zope packages
----------------------
-
-If you don't have a full Zope installation, you can pick a Zope package,
-check it out via Subversion, and get all its dependencies (replace
-``$PKG`` with, for example, ``zope.interface``)::
-
-    svn co svn://svn.zope.org/repos/main/$PKG/trunk $PKG
-    cd $PKG
-    python bootstrap.py
-    bin/buildout
-    bin/test
-
-Required pypy-c version
------------------------
-
-You probably need a pypy-c built with --allworkingmodules, at least::
-
-    cd pypy/translator/goal
-    ./translate.py targetpypystandalone.py --allworkingmodules
-
-Workarounds
------------
-
-At the moment, our ``gc`` module is incomplete, making the Zope test
-runner unhappy.  Quick workaround: go to the
-``lib-python/modified-2.4.1`` directory and create a
-``sitecustomize.py`` with the following content::
-
-    print "<adding dummy stuff into the gc module>"
-    import gc
-    gc.get_threshold = lambda : (0, 0, 0)
-    gc.get_debug = lambda : 0
-    gc.garbage = []
-
-Running the tests
------------------
-
-To run the tests we need the --oldstyle option, as follows::
-
-    cd $PKG
-    pypy-c --oldstyle bin/test

diff --git a/pypy/doc/discussion/compiled-swamp.rst b/pypy/doc/discussion/compiled-swamp.rst
deleted file mode 100644
--- a/pypy/doc/discussion/compiled-swamp.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-
-We've got huge swamp of compiled pypy-c's used for:
-
-* benchmarks
-* tests
-* compliance tests
-* play1
-* downloads
-* ...
-
-We've got build tool, which we don't use, etc. etc.
-
-Idea is to formalize it more or less, so we'll have single script
-to make all of this work, upload builds to the web page etc.

diff --git a/pypy/doc/discussion/ctypes_modules.rst b/pypy/doc/discussion/ctypes_modules.rst
deleted file mode 100644
--- a/pypy/doc/discussion/ctypes_modules.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-what is needed for various ctypes-based modules and how feasible they are
-==========================================================================
-
-Quick recap for module evaluation:
-
-1. does the module use callbacks?
-
-2. how sophisticated ctypes usage is (accessing of _objects?)
-
-3. any specific tricks
-
-4. does it have tests?
-
-5. dependencies
-
-6. does it depend on cpython c-api over ctypes?
-
-Pygame
-======
-
-1. yes, for various things, but basic functionality can be achieved without
-
-2. probably not
-
-3. not that I know of
-
-4. yes for tests, no for unittests
-
-5. numpy, but can live without, besides only C-level dependencies. On OS/X
-   it requires PyObjC.
-
-6. no
-
-
-PyOpenGL
-========
-
-1. yes, for GLX, but not for the core functionality
-
-2. probably not
-
-3. all the code is auto-generated
-
-4. it has example programs, no tests
-
-5. numpy, but can live without it. can use various surfaces (including pygame) to draw on
-
-6. no
-
-
-Sqlite
-======
-
-1. yes, but I think it's not necessary
-
-2. no
-
-3. no
-
-4. yes
-
-5. datetime
-
-6. it passes py_object around in few places, not sure why (probably as an
-   opaque argument).

diff --git a/pypy/doc/discussion/oz-thread-api.rst b/pypy/doc/discussion/oz-thread-api.rst
deleted file mode 100644
--- a/pypy/doc/discussion/oz-thread-api.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-Some rough notes about the Oz threading model
-=============================================
-
-(almost verbatim from CTM)
-
-Scheduling
-----------
-
-Fair scheduling through round-robin.
-
-With priority levels : three queues exist, which manage high, medium,
-low priority threads. The time slice ratio for these is
-100:10:1. Threads inherit the priority of their parent.
-
-Mozart uses an external timer approach to implement thread preemption.
-
-Thread ops
-----------
-
-All these ops are defined in a Thread namespace/module.
-
-this()               -> current thread's name (*not* another thread's name)
-state(t)             -> return state of t in {runnable, blocked, terminated}
-suspend(t)            : suspend t
-resume(t)             : resume execution of t
-preempt(t)            : preempt t
-terminate(t)          : terminate t immediately
-injectException(t, e) : raise exception e in t
-setPriority(t, p)     : set t's priority to p
-
-Interestingly, coroutines can be build upon this thread
-API. Coroutines have two ops : spawn and resume.
-
-spawn(p)             -> creates a coroutine with procedure p, returns pid
-resume(c)             : transfers control from current coroutine to c
-
-The implementation of these ops in terms of the threads API is as
-follows :
-
-def spawn(p):
-    in_thread:
-        pid = Thread.this()
-        Thread.suspend(pid)
-        p()
-
-def resume(cid):
-    Thread.resume cid
-    Thread.suspend(Thread.this())
-

diff --git a/pypy/doc/discussion/translation-swamp.rst b/pypy/doc/discussion/translation-swamp.rst
deleted file mode 100644
--- a/pypy/doc/discussion/translation-swamp.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-===================================================================
-List of things that need to be improved for translation to be saner
-===================================================================
-
-
- * understand nondeterminism after rtyping
- 
- * experiment with different heuristics:
- 
-    * weigh backedges more (TESTING)
-    * consider size of outer function
-    * consider number of arguments (TESTING)
-
- * find a more deterministic inlining order (TESTING using number of callers)
-
- * experiment with using a base inlining threshold and then drive inlining by
-   malloc removal possibilities (using escape analysis)
-
- * move the inlining of gc helpers just before emitting the code.
-   throw the graph away (TESTING, need to do a new framework translation)
-
- * for gcc: use just one implement file (TRIED: turns out to be a bad idea,
-   because gcc uses too much ram). Need to experiment more now that
-   inlining should at least be more deterministic!
-
-things to improve the framework gc
-==================================
-
- * find out whether a function can collect
-

diff --git a/pypy/doc/discussion/cmd-prompt-translation.rst b/pypy/doc/discussion/cmd-prompt-translation.rst
deleted file mode 100644
--- a/pypy/doc/discussion/cmd-prompt-translation.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-
-t = Translation(entry_point[,<options>])
-t.annotate([<options>])
-t.rtype([<options>])
-t.backendopt[_<backend>]([<options>])
-t.source[_<backend>]([<options>])
-f = t.compile[_<backend>]([<options>])
-
-and t.view(), t.viewcg()
-
-<backend> = c|llvm (for now)
-you can skip steps
-
-<options> = argtypes (for annotation) plus 
-            keyword args:  gc=...|policy=<annpolicy> etc
-
-
-

diff --git a/pypy/doc/discussion/gc.rst b/pypy/doc/discussion/gc.rst
deleted file mode 100644
--- a/pypy/doc/discussion/gc.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-
-*Note: this things are experimental and are being implemented on the
-`io-improvements`_ branch*
-
-.. _`io-improvements`: http://codespeak.net/svn/pypy/branch/io-improvements
-
-=============
-GC operations
-=============
-
-This document tries to gather gc-related issues which are very recent
-or in-development. Also, it tries to document needed gc refactorings
-and expected performance of certain gc-related operations.
-
-Problem area
-============
-
-Since some of our gcs are moving, we at some point decided to simplify
-the issue of having care of it by always copying the contents of
-data that goes to C level. This yields a performance penalty, also
-because some gcs does not move data around anyway.
-
-So we decided to introduce new operations which will simplify issues
-regarding this.
-
-Pure gc operations
-==================
-
-(All available from rlib.rgc)
-
-* can_move(p) - returns a flag telling whether pointer p will move.
-  useful for example when you want to know whether memcopy is safe.
-
-* malloc_nonmovable(TP, n=None) - tries to allocate non-moving object.
-  if it succeeds, it return an object, otherwise (for whatever reasons)
-  returns null pointer. Does not raise! (never)
-
-Usage patterns
-==============
-
-Usually those functions are used via helpers located in rffi. For things like
-os.write - first get_nonmovingbuffer(data) that will give you a pointer
-suitable of passing to C and finally free_nonmovingbuffer.
-
-For os.read like usage - you first call alloc_buffer (that will allocate a
-buffer of desired size passable to C) and afterwards create str_from_buffer,
-finally calling keep_buffer_alive_until_here.
-
-String builder
-==============
-
-In Python strings are immutable by design. In RPython this still yields true,
-but since we cooperate with lower (C/POSIX) level, which has no notion of
-strings, we use buffers. Typical use case is to use list of characters l and
-than ''.join(l) in order to get string. This requires a lot of unnecessary
-copying, which yields performance penalty for such operations as string
-formatting. Hence the idea of string builder. String builder would be an
-object to which you can append strings or characters and afterwards build it
-to a string. Ideally, this set of operations would not contain any copying
-whatsoever.
-
-Low level gc operations for string builder
-------------------------------------------
-
-* alloc_buffer(T, size) - allocates Array(nolength=True) with possibility
-  of later becoming of shape T
-
-* realloc_buffer(buf, newsize) - tries to shrink or enlarge buffer buf. Returns
-  new pointer (since it might involve copying)
-
-* build_buffer(T, buf) - creates a type T (previously passed to alloc_buffer)
-  from buffer.
-
-Depending on a gc, those might be implemented dumb (realloc always copies)
-or using C-level realloc. Might be implemented also in whatever clever way
-comes to mind.
-

diff --git a/pypy/doc/discussion/VM-integration.rst b/pypy/doc/discussion/VM-integration.rst
--- a/pypy/doc/discussion/VM-integration.rst
+++ b/pypy/doc/discussion/VM-integration.rst
@@ -1,3 +1,5 @@
+.. XXX anto, do we still need this?
+
 ==============================================
 Integration of PyPy with host Virtual Machines
 ==============================================

diff --git a/pypy/doc/discussion/chained_getattr.rst b/pypy/doc/discussion/chained_getattr.rst
deleted file mode 100644
--- a/pypy/doc/discussion/chained_getattr.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-
-
-"chained getattr/module global lookup" optimization
-(discussion during trillke-sprint 2007, anto/holger, 
-a bit of samuele and cf earlier on)  
-
-random example: 
-
-    code: 
-        import os.path
-        normed = [os.path.normpath(p) for p in somelist]
-    bytecode: 
-        [...]
-         LOAD_GLOBAL              (os)
-         LOAD_ATTR                (path)
-         LOAD_ATTR                (normpath)
-         LOAD_FAST                (p)
-         CALL_FUNCTION            1
-
-    would be turned by pypy-compiler into: 
-
-         LOAD_CHAINED_GLOBAL      (os,path,normpath)
-         LOAD_FAST                (p)
-         CALL_FUNCTION            1
-       
-    now for the LOAD_CHAINED_GLOBAL bytecode implementation:
-
-        Module dicts have a special implementation, providing: 
-
-        - an extra "fastlookup" rpython-dict serving as a cache for
-          LOAD_CHAINED_GLOBAL places within the modules: 
-
-          * keys are e.g. ('os', 'path', 'normpath')
-
-          * values are tuples of the form: 
-            ([obj1, obj2, obj3], [ver1, ver2])
-
-             "ver1" refer to the version of the globals of "os"
-             "ver2" refer to the version of the globals of "os.path"
-             "obj3" is the resulting "normpath" function 
-
-        - upon changes to the global dict, "fastlookup.clear()" is called
-
-        - after the fastlookup entry is filled for a given
-          LOAD_CHAINED_GLOBAL index, the following checks need
-          to be performed in the bytecode implementation::
-    
-              value = f_globals.fastlookup.get(key, None)
-              if value is None:
-                 # fill entry 
-              else:
-                  # check that our cached lookups are still valid 
-                  assert isinstance(value, tuple) 
-                  objects, versions = value
-                  i = 0
-                  while i < len(versions): 
-                      lastversion = versions[i]
-                      ver = getver_for_obj(objects[i])
-                      if ver == -1 or ver != lastversion:
-                         name = key[i]
-                         objects[i] = space.getattr(curobj, name)
-                         versions[i] = ver
-                      curobj = objects[i]
-                      i += 1
-              return objects[i]
-
-            def getver_for_obj(obj):
-                if "obj is not Module":
-                    return -1
-                return obj.w_dict.version 

diff --git a/pypy/doc/discussion/finalizer-order.rst b/pypy/doc/discussion/finalizer-order.rst
--- a/pypy/doc/discussion/finalizer-order.rst
+++ b/pypy/doc/discussion/finalizer-order.rst
@@ -1,3 +1,6 @@
+.. XXX armin, what do we do with this?
+
+
 Ordering finalizers in the SemiSpace GC
 =======================================
 

diff --git a/pypy/doc/discussion/outline-external-ootype.rst b/pypy/doc/discussion/outline-external-ootype.rst
--- a/pypy/doc/discussion/outline-external-ootype.rst
+++ b/pypy/doc/discussion/outline-external-ootype.rst
@@ -1,3 +1,5 @@
+.. XXX, anto, can this be killed?
+
 Some discussion about external objects in ootype
 ================================================
 

diff --git a/pypy/doc/discussion/distribution.rst b/pypy/doc/discussion/distribution.rst
--- a/pypy/doc/discussion/distribution.rst
+++ b/pypy/doc/discussion/distribution.rst
@@ -1,3 +1,5 @@
+.. XXX fijal, can this be killed?
+
 ===================================================
 (Semi)-transparent distribution of RPython programs
 ===================================================

diff --git a/pypy/doc/discussion/pypy_metaclasses_in_cl.rst b/pypy/doc/discussion/pypy_metaclasses_in_cl.rst
deleted file mode 100644
--- a/pypy/doc/discussion/pypy_metaclasses_in_cl.rst
+++ /dev/null
@@ -1,139 +0,0 @@
-IRC log
-=======
-
-::
-
-    [09:41] <dialtone> arigo: is it possible to ask the backendoptimizer to completely remove all the oogetfield('meta', obj)?
-    [09:42] <dialtone> and at the same time to change all the oogetfield('somefield', meta) into oogetfield('somefield', obj)
-    [09:42] <dialtone> because then we wouldn't need the metaclass hierarchy anymore
-    [09:42] <dialtone> (at least in common lisp)
-    [09:42] <arigo> as far as I know the idea was indeed to be able to do this kind of things
-    [09:43] <arigo> but not necessarily in the existing backendopt
-    [09:44] <dialtone> uhmmm
-    [09:44] <dialtone> I have no idea how to do this stuff
-    [09:44] <arigo> if I understand it correctly, as a first step you can just tweak gencl to recognize oogetfield('meta', obj)
-    [09:44] <dialtone> I'll think about it on the plane maybe
-    [09:44] <arigo> and produce a same_as equivalent instead
-    [09:44] <arigo> (do I make any sense at all?)
-    [09:44] <dialtone> yes
-    [09:45] <dialtone> same_as(meta, obj)
-    [09:45] <dialtone> so that the next oogetfield() will still work on meta which in reality is the obj
-    [09:45] <arigo> yes
-    [09:45] <dialtone> thus you obtained the same thing without removing anything
-    [09:45] <dialtone> cool
-    [09:46] <antocuni> dialtone: can you explain me better what are you trying to do?
-    [09:46] <dialtone> it looks kinda simple
-    [09:46] <dialtone> am I a fool?
-    [09:46] <dialtone> antocuni: I want to get rid of the metaclass stuff in common lisp
-    [09:47] <dialtone> since common lisp supports class variables
-    [09:47] <dialtone> (DEFCLASS foo () ((bar :allocate :class)))
-    [09:47] <antocuni> cool
-    [09:47] <dialtone> but to do that I also have to get rid of the opcodes that work on the object model
-    [09:48] <dialtone> at first I thought about removing the metaclass related operations (or change them) but armin got a great idea about using same_as
-    [09:48] idnar (i=mithrand at unaffiliated/idnar) left irc: Remote closed the connection
-    [09:48] <arigo> there might be a few problems, though
-    [09:48] <dialtone> and here comes the part I feared
-    [09:48] <arigo> I'm not sure if the meta object is used for more than oogetfields
-    [09:49] <arigo> and also, let's see if there are name clashes in the fields
-    [09:49] <antocuni> I can't understand a thing: are you trying to lookup some fields in the obj directly, instead of in the metclass, right?
-    [09:49] <dialtone> antocuni: yes
-    [09:50] <antocuni> why an object should have fields that belongs to its metaclass?
-    [09:50] <dialtone> arigo: uhmmm you can have both a class variable and an instance variable named in the same way?
-    [09:50] <dialtone> metaclass is not a real metaclass
-    [09:50] <arigo> I don't know
-    [09:50] <braintone> arigo - r26566 - Support geterrno() from rctypes to genc.
-    [09:50] <antocuni> dialtone: ah, now I understand
-    [09:50] <arigo> I would expect it not to be the case, as the names come from RPython names
-    [09:51] <dialtone> arigo: indeed
-    [09:51] <dialtone> but I guess I can set different accessors maybe for class level things and for instance level things
-    [09:51] <dialtone> let's try
-    [09:51] <dialtone> no...
-    [09:52] <dialtone> so a name clash would break stuff
-    [09:52] <dialtone> but... how do you recognize an access to a class variable and one to an instance variable from RPython?
-    [09:53] <arigo> dialtone: I think we don't have name clashes, because there is some mangling anyway
-    [09:53] <dialtone> cool
-    [09:53] <arigo> if I see it correctly, class variable names start with 'pbc' and instance ones with 'o'
-    [09:53] <dialtone> that's what we've done in gencl yes
-    [09:54] <arigo> ? that's what the ootyping is doing
-    [09:54] <dialtone> yes yes
-    [09:54] <arigo> :-)
-    [09:54] <dialtone> I mean that I see the distinction in gencl :)
-    [09:54] <dialtone> sooooooo
-    [09:55] <dialtone> if I have a getfield where the first argument is meta and I simply emit the same code that I emit for the same_as I should be safe removing all the meta stuff... maybe
-    [09:55] <dialtone> seems like a tiny change in gencl
-    [09:55] <arigo> dialtone: in RPython, the annotator says that attributes are instance fields as soon as they are written to instances, otherwise they are class attributes
-    [09:56] <arigo> yes, it should work
-    [09:56] Palats (n=Pierre at izumi.palats.com) left irc: Read error: 104 (Connection reset by peer)
-    [09:56] <dialtone> unless of course metaclasses are used for something else than class variables
-    [09:56] <arigo> ideally, you should not look for the name 'meta' but for some other hint
-    [09:57] <arigo> I'm not completely at ease with the various levels of ootype
-    [09:57] <dialtone> neither am I\
-    [09:57] <nikh> all field names other than those defined by ootype (like "meta") will be mangled, so i guess checking for "meta" is good enough
-    [09:57] <dialtone> and I also have to ignore the setfield opcode that deals with metaclasses
-    [09:58] <dialtone> or make it a same_as as well
-    [09:59] <arigo> apparently, the meta instances are used as the ootype of RPython classes
-    [10:00] <arigo> so they can be manipulated by RPython code that passes classes around
-    [10:01] <arigo> I guess you can also pass classes around in CL, read attributes from them, and instantiate them
-    [10:01] <dialtone> yes
-    [10:01] <arigo> so a saner approach might be to try to have gencl use CL classes instead of these meta instances
-    [10:03] <dialtone> uhmmmmm
-    [10:03] <arigo> which means: recognize if an ootype.Instance is actually representing an RPython class (by using a hint)
-    [10:03] <dialtone> I also have to deal with the Class_
-    [10:03] <dialtone> but that can probably be set to standard-class
-    [10:03] <arigo> yes, I think it's saner to make, basically, oogetfield('class_') be a same_as
-    [10:04] <dialtone> cool
-    [10:04] <dialtone> I think I'll save this irc log to put it in the svn tree for sanxiyn
-    [10:04] <nikh> to recognize RPython class represenations: if the ootype.Instance has the superclass ootypesystem.rclass.CLASSTYPE, then it's a "metaclass"
-    [10:04] <dialtone> he is thinking about this in the plane (at least this is what he told)
-    [10:05] <arigo> :-)
-    [10:05] <arigo> nikh: yes
-    [10:05] <arigo> ootype is indeed rather complicated, level-wise, to support limited languages like Java
-    [10:05] <nikh> unfortunately, yes
-    [10:05] <nikh> well, in a way it's very convenient for the backends
-    [10:05] <nikh> but if you want to use more native constructs, it gets hairy quickly
-    [10:05] <dialtone> I dunno
-    [10:05] <dialtone> depends on the backend
-    [10:06] <arigo> hum, there is still an information missing that gencl would need here
-    [10:06] <dialtone> I think if the language of the backend is powerful enough it could use an higher abstraction
-    [10:07] <arigo> dialtone: yes, there is also the (hairly to implement) idea of producing slightly different things for different back-ends too
-    [10:07] <dialtone> using backendopts?
-    [10:08] <dialtone> would it make sense to have a kind of backend_supports=['metaclasses', 'classvariables', 'first_class_functions'...]
-    [10:08] <arigo> maybe, but I was thinking about doing different things in ootypesystem/rclass already
-    [10:08] <arigo> yes, such a backend_supports would be great
-    [10:09] <nikh> dialtone: there is still an hour left to sprint, so go go go ;)
-    [10:09] <nikh> you can do it, if you want it ;)
-    [10:09] <arigo> what is missing is the link from the concrete Instance types, and which Instance corresponds to its meta-instance
-    [10:10] idnar (i=mithrand at unaffiliated/idnar) joined #pypy.
-    [10:10] <arigo> dialtone: it's not as simple as making an oogetfield be a same_as
-    [10:10] <dialtone> KnowledgeUnboundError, Missing documentation in slot brain
-    [10:10] <arigo> right now for CL the goal would be to generate for a normal Instance, a DEFCLASS whose :allocate :class attributes are the attributes of the meta-Instance
-    [10:11] <nikh> we could optionally have class fields in Instances, and then operations like ooget/setclassfield
-    [10:11] <dialtone> the reason why I ask is that if we manage to do this then we could also use default Condition as Exception
-    [10:11] <dialtone> and we could map the Conditions in common lisp to exceptions in python transparently
-    [10:12] <dialtone> since the object systems will then match (and they are vaguely similar anyway)
-    [10:12] <arigo> nice
-    [10:12] <dialtone> at least I think
-    [10:18] <arigo> I'm still rather confused by ootypesystem/rclass
-    [10:18] <arigo> although I think that blame would show my name on quite some bits :-)
-    [10:19] <arigo> there are no class attributes read through instances
-    [10:19] <arigo> they are turned into method calls
-    [10:19] <arigo> accessor methods
-    [10:20] <arigo> it's a bit organically grown
-    [10:20] <arigo> accessor methods were introduced at one point, and the meta-Instance later
-    [10:21] <dialtone> uhmmm
-    [10:22] <nikh> what was the reason for having accessor methods?
-    [10:22] <nikh> they seem to be only generated for class vars that are overriden in subclasses.
-    [10:22] <arigo> yes
-    [10:22] <arigo> before we had the meta-Instance trick, it was the only way to avoid storing the value in all instances
-    [10:22] <nikh> aha
-    [10:23] <nikh> we could possibly get rid of these accessors
-    [10:23] <arigo> now, yes, by storing the values in the meta-Instance
-    [10:23] <nikh> they are alway anyway stored in the meta-Instance, I think
-    [10:23] <arigo> no, I think that other values are stored in the meta-Instance right now
-    [10:24] <arigo> it's the values that are only ever accessed with a syntax 'ClassName.attr', i.e. not through an instance
-    [10:24] <arigo> ...more precisely, with 'x = ClassName or OtherClassName; x.attr'
-    [10:25] <nikh> hm, i'm still trying to read this out of the code ...
-    [10:28] <arigo> it's in ClassRepr._setup_repr()
-    [10:28] <arigo> there is no clsfields here, just pbcfields
-    [10:28] <arigo> # attributes showing up in getattrs done on the class as a PBC
-    [10:28] <nikh> i see

diff --git a/pypy/doc/discussion/GC-performance.rst b/pypy/doc/discussion/GC-performance.rst
deleted file mode 100644
--- a/pypy/doc/discussion/GC-performance.rst
+++ /dev/null
@@ -1,118 +0,0 @@
-StartHeapsize# is the framework GC as of revision 31586 with initial
-bytes_malloced_threshold of 2-512 MB
-
-NewHeuristics is the framework GC with a new heuristics for adjusting
-the bytes_malloced_threshold
-
-::
-
- Pystone
- StartHeapsize2:
- This machine benchmarks at 5426.92 pystones/second
- This machine benchmarks at 5193.91 pystones/second
- This machine benchmarks at 5403.46 pystones/second
- StartHeapsize8:
- This machine benchmarks at 6075.33 pystones/second
- This machine benchmarks at 6007.21 pystones/second
- This machine benchmarks at 6122.45 pystones/second
- StartHeapsize32:
- This machine benchmarks at 6643.05 pystones/second
- This machine benchmarks at 6590.51 pystones/second
- This machine benchmarks at 6593.41 pystones/second
- StartHeapsize128:
- This machine benchmarks at 7065.47 pystones/second
- This machine benchmarks at 7102.27 pystones/second
- This machine benchmarks at 7082.15 pystones/second
- StartHeapsize512:
- This machine benchmarks at 7208.07 pystones/second
- This machine benchmarks at 7197.7 pystones/second
- This machine benchmarks at 7246.38 pystones/second
- NewHeuristics:
- This machine benchmarks at 6821.28 pystones/second
- This machine benchmarks at 6858.71 pystones/second
- This machine benchmarks at 6902.9 pystones/second
-
-
- Richards
- StartHeapSize2:
- Average time per iteration: 5456.21 ms
- Average time per iteration: 5529.31 ms
- Average time per iteration: 5398.82 ms
- StartHeapsize8:
- Average time per iteration: 4775.43 ms
- Average time per iteration: 4753.25 ms
- Average time per iteration: 4781.37 ms
- StartHeapsize32:
- Average time per iteration: 4554.84 ms
- Average time per iteration: 4501.86 ms
- Average time per iteration: 4531.59 ms
- StartHeapsize128:
- Average time per iteration: 4329.42 ms
- Average time per iteration: 4360.87 ms
- Average time per iteration: 4392.81 ms
- StartHeapsize512:
- Average time per iteration: 4371.72 ms
- Average time per iteration: 4399.70 ms
- Average time per iteration: 4354.66 ms
- NewHeuristics:
- Average time per iteration: 4763.56 ms
- Average time per iteration: 4803.49 ms
- Average time per iteration: 4840.68 ms
-
-
- translate rpystone
-   time pypy-c translate --text --batch --backendopt --no-compile targetrpystonedalone.py
- StartHeapSize2:
- real    1m38.459s
- user    1m35.582s
- sys     0m0.440s
- StartHeapsize8:
- real    1m35.398s
- user    1m33.878s
- sys     0m0.376s
- StartHeapsize32:
- real    1m5.475s
- user    1m5.108s
- sys     0m0.180s
- StartHeapsize128:
- real    0m52.941s
- user    0m52.395s
- sys     0m0.328s
- StartHeapsize512:
- real    1m3.727s
- user    0m50.031s
- sys     0m1.240s
- NewHeuristics:
- real    0m53.449s
- user    0m52.771s
- sys     0m0.356s
-
-
- docutils
-   time pypy-c rst2html doc/coding-guide.txt
- StartHeapSize2:
- real    0m36.125s
- user    0m35.562s
- sys     0m0.088s
- StartHeapsize8:
- real    0m32.678s
- user    0m31.106s
- sys     0m0.084s
- StartHeapsize32:
- real    0m22.041s
- user    0m21.085s
- sys     0m0.132s
- StartHeapsize128:
- real    0m19.350s
- user    0m18.653s
- sys     0m0.324s
- StartHeapsize512:
- real    0m19.116s
- user    0m17.517s
- sys     0m0.620s
- NewHeuristics:
- real    0m20.990s
- user    0m20.109s
- sys     0m0.196s
-
-

diff --git a/pypy/doc/discussion/use_case_of_logic.rst b/pypy/doc/discussion/use_case_of_logic.rst
deleted file mode 100644
--- a/pypy/doc/discussion/use_case_of_logic.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-Use cases for a combination of Logic and Object Oriented programming approach
--------------------------------------------------------------------------------
-
-Workflows
-=========
-
-Defining the next state by solving certain constraints. The more
-general term might be State machines.
-
-Business Logic
-==============
-
-We define Business Logic as expressing consistency (as an example) on
-a set of objects in a business application.
-
-For example checking the consistency of a calculation before
-committing the changes.
-
-The domain is quite rich in example of uses of Business Logic.
-
-Datamining
-===========
-
-An example is Genetic sequence matching.
-
-Databases
-=========
-
-Validity constraints for the data can be expressed as constraints.
-
-Constraints can be used to perform type inference when querying the
-database.
-
-Semantic web
-=============
-
-The use case is like the database case, except the ontology language
-it self is born out of Descriptive Logic
-
-
-User Interfaces
-===============
-
-We use rules to describe the layout and visibility constraints of
-elements that are to be displayed on screen. The rule can also help
-describing how an element is to be displayed depending on its state
-(for instance, out of bound values can be displayed in a different
-colour).
-
-Configuration
-==============
-
-User configuration can use information inferred from : the current
-user, current platforms , version requirements, ...
-
-The validity of the configuration can be checked with the constraints.
-
-
-Scheduling and planning
-========================
-
-Timetables, process scheduling, task scheduling.
-
-Use rules to determine when to execute tasks (only start batch, if load
-is low, and previous batch is finished.
-
-Load sharing.
-
-Route optimization. Planning the routes of a technician based on tools
-needed and such
-
-An example is scheduling a conference like Europython see:
-
-http://lists.logilab.org/pipermail/python-logic/2005-May/000107.html
-

diff --git a/pypy/doc/discussion/ctypes_todo.rst b/pypy/doc/discussion/ctypes_todo.rst
deleted file mode 100644
--- a/pypy/doc/discussion/ctypes_todo.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-Few ctypes-related todo points:
-
-* Write down missing parts and port all tests, eventually adding
-  additional tests.
-
-  - for unions and structs, late assignment of _fields_ is somewhat buggy.
-    Tests about behavior of getattr working properly on instances
-    are missing or not comprehensive. Some tests are skipped because I didn't
-    understand the details.
-
-  - _fields_ can be tuples too as well as lists
-
-  - restype being a function is not working.
-
-  - there are features, which we don't support like buffer() and
-    array() protocols.
-
-  - are the _CData_value return lifetime/gc semantics correct?
-
-  - for some ABIs we will need completely filled ffitypes to do the
-    right thing for passing structures by value, we are now passing enough
-    information to rawffi that it should be possible to construct such precise
-    ffitypes in most cases
-
-  - bitfields are not implemented
-
-  - byteorder is not implemented
-
-* as all stuff is applevel, we cannot have it really fast right now.
-
-* we shall at least try to approach ctypes from the point of the jit
-  backends (at least on platforms that we support). The thing is that
-  we need a lot broader support of jit backends for different argument
-  passing in order to do it.

diff --git a/pypy/doc/discussion/security-ideas.rst b/pypy/doc/discussion/security-ideas.rst
deleted file mode 100644
--- a/pypy/doc/discussion/security-ideas.rst
+++ /dev/null
@@ -1,312 +0,0 @@
-==============
-Security ideas
-==============
-
-These are some notes I (Armin) took after a talk at Chalmers by Steve
-Zdancewic: "Encoding Information Flow in Haskell".  That talk was
-presenting a pure Haskell approach with monad-like constructions; I
-think that the approach translates well to PyPy at the level of RPython.
-
-
-The problem
------------
-
-The problem that we try to solve here is: how to give the programmer a
-way to write programs that are easily checked to be "secure", in the
-sense that bugs shouldn't allow confidential information to be
-unexpectedly leaked.  This is not security as in defeating actively
-malicious attackers.
-
-
-Example
--------
-
-Let's suppose that we want to write a telnet-based application for a
-bidding system.  We want normal users to be able to log in with their
-username and password, and place bids (i.e. type in an amount of money).
-The server should record the highest bid so far but not allow users to
-see that number.  Additionally, the administrator should be able to log
-in with his own password and see the highest bid.  The basic program::
-
-    def mainloop():
-        while True:
-            username = raw_input()
-            password = raw_input()
-            user = authenticate(username, password)
-            if user == 'guest':
-                serve_guest()
-            elif user == 'admin':
-                serve_admin()
-
-    def serve_guest():
-        global highest_bid
-        print "Enter your bid:"
-        n = int(raw_input())
-        if n > highest_bid:     #
-            highest_bid = n     #
-        print "Thank you"
-
-    def serve_admin():
-        print "Highest big is:", highest_bid
-
-The goal is to make this program more secure by declaring and enforcing
-the following properties: first, the guest code is allowed to manipulate
-the highest_bid, as in the lines marked with ``#``, but these lines must
-not leak back the highest_bid in a form visible to the guest user;
-second, the printing in serve_admin() must only be allowed if the user
-that logged in is really the administrator (e.g. catch bugs like
-accidentally swapping the serve_guest() and serve_admin() calls in
-mainloop()).
-
-
-Preventing leak of information in guest code: 1st try
------------------------------------------------------
-
-The basic technique to prevent leaks is to attach "confidentiality
-level" tags to objects.  In this example, the highest_bid int object
-would be tagged with label="secret", e.g. by being initialized as::
-
-    highest_bid = tag(0, label="secret")
-
-At first, we can think about an object space where all objects have such
-a label, and the label propagates to operations between objects: for
-example, code like ``highest_bid += 1`` would produce a new int object
-with again label="secret".
-
-Where this approach doesn't work is with if/else or loops.  In the above
-example, we do::
-
-        if n > highest_bid:
-            ...
-
-However, by the object space rules introduced above, the result of the
-comparison is a "secret" bool objects.  This means that the guest code
-cannot know if it is True or False, and so the PyPy interpreter has no
-clue if it must following the ``then`` or ``else`` branch of the ``if``.
-So the guest code could do ``highest_bid += 1`` and probably even
-``highest_bid = max(highest_bid, n)`` if max() is a clever enough
-built-in function, but clearly this approach doesn't work well for more
-complicated computations that we would like to perform at this point.
-
-There might be very cool possible ideas to solve this with doing some
-kind of just-in-time flow object space analysis.  However, here is a
-possibly more practical approach.  Let's forget about the object space
-tricks and start again.  (See `Related work`_ for why the object space
-approach doesn't work too well.)
-
-
-Preventing leak of information in guest code with the annotator instead
------------------------------------------------------------------------
-
-Suppose that the program runs on top of CPython and not necessarily
-PyPy.  We will only need PyPy's annotator.  The idea is to mark the code
-that manipulates highest_bid explicitly, and make it RPython in the
-sense that we can take its flow space and follow the calls (we don't
-care about the precise types here -- we will use different annotations).
-Note that only the bits that manipulates the secret values needs to be
-RPython.  Example::
-
-    # on top of CPython, 'hidden' is a type that hides a value without
-    # giving any way to normal programs to access it, so the program
-    # cannot do anything with 'highest_bid'
-
-    highest_bid = hidden(0, label="secure")
-
-    def enter_bid(n):
-        if n > highest_bid.value:
-            highest_bid.value = n
-
-    enter_bid = secure(enter_bid)
-
-    def serve_guest():
-        print "Enter your bid:"
-        n = int(raw_input())
-        enter_bid(n)
-        print "Thank you"
-
-The point is that the expression ``highest_bid.value`` raises a
-SecurityException when run normally: it is not allowed to read this
-value.  The secure() decorator uses the annotator on the enter_bid()
-function, with special annotations that I will describe shortly.  Then
-secure() returns a "compiled" version of enter_bid.  The compiled
-version is checked to satisfy the security constrains, and it contains
-special code that then enables the ``highest_bid.value`` to work.
-
-The annotations propagated by secure() are ``SomeSecurityLevel``
-annotations.  Normal constants are propagated as
-SomeSecurityLevel("public").  The ``highest_bid.value`` returns the
-annotation SomeSecurityLevel("secret"), which is the label of the
-constant ``highest_bid`` hidden object.  We define operations between
-two SomeSecurityLevels to return a SomeSecurityLevel which is the max of
-the secret levels of the operands.
-
-The key point is that secure() checks that the return value is
-SomeSecurityLevel("public").  It also checks that only
-SomeSecurityLevel("public") values are stored e.g. in global data
-structures.
-
-In this way, any CPython code like serve_guest() can safely call
-``enter_bid(n)``.  There is no way to leak information about the current
-highest bid back out of the compiled enter_bid().
-
-
-Declassification
-----------------
-
-Now there must be a controlled way to leak the highest_bid value,
-otherwise it is impossible even for the admin to read it.  Note that
-serve_admin(), which prints highest_bid, is considered to "leak" this
-value because it is an input-output, i.e. it escapes the program.  This
-is a leak that we actually want -- the terminology is that serve_admin()
-must "declassify" the value.
-
-To do this, there is a capability-like model that is easy to implement
-for us.  Let us modify the main loop as follows::
-
-    def mainloop():
-        while True:
-            username = raw_input()
-            password = raw_input()
-            user, priviledge_token = authenticate(username, password)
-            if user == 'guest':
-                serve_guest()
-            elif user == 'admin':
-                serve_admin(priviledge_token)
-            del priviledge_token   # make sure nobody else uses it
-
-The idea is that the authenticate() function (shown later) also returns
-a "token" object.  This is a normal Python object, but it should not be
-possible for normal Python code to instantiate such an object manually.
-In this example, authenticate() returns a ``priviledge("public")`` for
-guests, and a ``priviledge("secret")`` for admins.  Now -- and this is
-the insecure part of this scheme, but it is relatively easy to control
--- the programmer must make sure that these priviledge_token objects
-don't go to unexpected places, particularly the "secret" one.  They work
-like capabilities: having a reference to them allows parts of the
-program to see secret information, of a confidentiality level up to the
-one corresponding to the token.
-
-Now we modify serve_admin() as follows:
-
-    def serve_admin(token):
-        print "Highest big is:", declassify(highest_bid, token=token)
-
-The declassify() function reads the value if the "token" is privileged
-enough, and raises an exception otherwise.
-
-What are we protecting here?  The fact that we need the administrator
-token in order to see the highest bid.  If by mistake we swap the
-serve_guest() and serve_admin() lines in mainloop(), then what occurs is
-that serve_admin() would be called with the guest token.  Then
-declassify() would fail.  If we assume that authenticate() is not buggy,
-then the rest of the program is safe from leak bugs.
-
-There are another variants of declassify() that are convenient.  For
-example, in the RPython parts of the code, declassify() can be used to
-control more precisely at which confidentiality levels we want which
-values, if there are more than just two such levels.  The "token"
-argument could also be implicit in RPython parts, meaning "use the
-current level"; normal non-RPython code always runs at "public" level,
-but RPython functions could run with higher current levels, e.g. if they
-are called with a "token=..." argument.
-
-(Do not confuse this with what enter_bid() does: enter_bid() runs at the
-public level all along.  It is ok for it to compute with, and even
-modify, the highest_bid.value.  The point of enter_bid() was that by
-being an RPython function the annotator can make sure that the value, or
-even anything that gives a hint about the value, cannot possibly escape
-from the function.)
-
-It is also useful to have "globally trusted" administrator-level RPython
-functions that always run at a higher level than the caller, a bit like
-Unix programs with the "suid" bit.  If we set aside the consideration
-that it should not be possible to make new "suid" functions too easily,
-then we could define the authenticate() function of our server example
-as follows::
-
-    def authenticate(username, password):
-        database = {('guest', 'abc'): priviledge("public"),
-                    ('admin', '123'): priviledge("secret")}
-        token_obj = database[username, password]
-        return username, declassify(token_obj, target_level="public")
-
-    authenticate = secure(authenticate, suid="secret")
-
-The "suid" argument makes the compiled function run on level "secret"
-even if the caller is "public" or plain CPython code.  The declassify()
-in the function is allowed because of the current level of "secret".
-Note that the function returns a "public" tuple -- the username is
-public, and the token_obj is declassified to public.  This is the
-property that allows CPython code to call it.
-
-Of course, like a Unix suid program the authenticate() function could be
-buggy and leak information, but like suid programs it is small enough
-for us to feel that it is secure just by staring at the code.
-
-An alternative to the suid approach is to play with closures, e.g.::
-
-    def setup():
-        #initialize new levels -- this cannot be used to access existing levels
-        public_level = create_new_priviledge("public")
-        secret_level = create_new_priviledge("secret")
-
-        database = {('guest', 'abc'): public_level,
-                    ('admin', '123'): secret_level}
-
-        def authenticate(username, password):
-            token_obj = database[username, password]
-            return username, declassify(token_obj, target_level="public",
-                                                   token=secret_level)
-
-        return secure(authenticate)
-
-    authenticate = setup()
-
-In this approach, declassify() works because it has access to the
-secret_level token.  We still need to make authenticate() a secure()
-compiled function to hide the database and the secret_level more
-carefully; otherwise, code could accidentally find them by inspecting
-the traceback of the KeyError exception if the username or password is
-invalid.  Also, secure() will check for us that authenticate() indeed
-returns a "public" tuple.
-
-This basic model is easy to extend in various directions.  For example
-secure() RPython functions should be allowed to return non-public
-results -- but then they have to be called either with an appropriate
-"token=..."  keyword, or else they return hidden objects again.  They
-could also be used directly from other RPython functions, in which the
-level of what they return is propagated.
-
-
-Related work
-------------
-
-What I'm describing here is nothing more than an adaptation of existing
-techniques to RPython.
-
-It is noteworthy to mention at this point why the object space approach
-doesn't work as well as we could first expect.  The distinction between
-static checking and dynamic checking (with labels only attached to
-values) seems to be well known; also, it seems to be well known that the
-latter is too coarse in practice.  The problem is about branching and
-looping.  From the object space' point of view it is quite hard to know
-what a newly computed value really depends on.  Basically, it is
-difficult to do better than: after is_true() has been called on a secret
-object, then we must assume that all objects created are also secret
-because they could depend in some way on the truth-value of the previous
-secret object.
-
-The idea to dynamically use static analysis is the key new idea
-presented by Steve Zdancewic in his talk.  You can have small controlled
-RPython parts of the program that must pass through a static analysis,
-and we only need to check dynamically that some input conditions are
-satisfied when other parts of the program call the RPython parts.
-Previous research was mostly about designing languages that are
-completely statically checked at compile-time.  The delicate part is to
-get the static/dynamic mixture right so that even indirect leaks are not
-possible -- e.g. leaks that would occur from calling functions with
-strange arguments to provoke exceptions, and where the presence of the
-exception or not would be information in itself.  This approach seems to
-do that reliably.  (Of course, at the talk many people including the
-speaker were wondering about ways to move more of the checking at
-compile-time, but Python people won't have such worries :-)

diff --git a/pypy/doc/discussion/removing-stable-compiler.rst b/pypy/doc/discussion/removing-stable-compiler.rst
deleted file mode 100644
--- a/pypy/doc/discussion/removing-stable-compiler.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-February 28th, 2006
-
-While implementing conditional expressions from 2.5 we had to change
-the stable compiler in order to keep tests from breaking.  While using
-stable compiler as a baseline made sense when the ast compiler was
-new, it is less and less true as new grammar changes are introduced.
-
-Options include
-
-1. Freezing the stable compiler at grammar 2.4.
-
-2. Capture AST output from the stable compiler and use that explicitly
-in current tests instead of regenerating them every time, primarily
-because it allows us to change the grammar without changing the stable
-compiler.
-
-
-In either case, AST production tests for new grammar changes could be
-written manually, which is less effort than fixing the stable
-compiler (which itself isn't really tested anyway).
-
-Discussion by Arre, Anders L., Stuart Williams

diff --git a/pypy/doc/discussion/somepbc-refactoring-plan.rst b/pypy/doc/discussion/somepbc-refactoring-plan.rst
deleted file mode 100644
--- a/pypy/doc/discussion/somepbc-refactoring-plan.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-==========================
-   Refactoring SomePBCs
-==========================
-
-Motivation
-==========
-
-Some parts of the annotator, and especially specialization, are quite obscure
-and hackish.  One cause for this is the need to manipulate Python objects like
-functions directly.  This makes it hard to attach additional information directly
-to the objects.  It makes specialization messy because it has to create new dummy
-function objects just to represent the various specialized versions of the function.
-
-
-Plan
-====
-
-Let's introduce nice wrapper objects.  This refactoring is oriented towards
-the following goal: replacing the content of SomePBC() with a plain set of
-"description" wrapper objects.  We shall probably also remove the possibility
-for None to explicitly be in the set and add a can_be_None flag (this is
-closer to what the other SomeXxx classes do).
-
-
-XxxDesc classes
-===============
-
-To be declared in module pypy.annotator.desc, with a mapping
-annotator.bookkeeper.descs = {<python object>: <XxxDesc instance>}
-accessed with bookkeeper.getdesc(<python object>).
-
-Maybe later the module should be moved out of pypy.annotation but for now I
-suppose that it's the best place.
-
-The goal is to have a single Desc wrapper even for functions and classes that
-are specialized.
-
-FunctionDesc
-
-    Describes (usually) a Python function object.  Contains flow graphs: one
-    in the common case, zero for external functions, more than one if there
-    are several specialized versions.  Also describes the signature of the
-    function in a nice format (i.e. not by relying on func_code inspection).
-
-ClassDesc
-
-    Describes a Python class object.  Generally just maps to a ClassDef, but
-    could map to more than one in the presence of specialization.  So we get
-    SomePBC({<ClassDesc>}) annotations for the class, and when it's
-    instantiated it becomes SomeInstance(classdef=...) for the particular
-    selected classdef.
-
-MethodDesc
-
-    Describes a bound method.  Just references a FunctionDesc and a ClassDef
-    (not a ClassDesc, because it's read out of a SomeInstance).
-
-FrozenDesc
-
-    Describes a frozen pre-built instance.  That's also a good place to store
-    some information currently in dictionaries of the bookkeeper.
-
-MethodOfFrozenDesc
-
-    Describes a method of a FrozenDesc.  Just references a FunctionDesc and a
-    FrozenDesc.
-
-NB: unbound method objects are the same as function for our purposes, so they
-become the same FunctionDesc as their im_func.
-
-These XxxDesc classes should share some common interface, as we'll see during
-the refactoring.  A common base class might be a good idea (at least I don't
-see why it would be a bad idea :-)
-
-
-Implementation plan
-===================
-
-* make a branch (/branch/somepbc-refactoring/)
-
-* change the definition of SomePBC, start pypy.annotation.desc
-
-* fix all places that use SomePBC :-)
-
-* turn Translator.flowgraphs into a plain list of flow graphs,
-  and make the FunctionDescs responsible for computing their own flow graphs
-
-* move external function functionality into the FunctionDescs too
-
-
-Status
-======
-
-Done, branch merged.
-
-
-RTyping PBCs of functions
-=========================
-
-The FuncDesc.specialize() method takes an args_s and return a
-corresponding graph.  The caller of specialize() parses the actual
-arguments provided by the simple_call or call_args operation, so that
-args_s is a flat parsed list.  The returned graph must have the same
-number and order of input variables.
-
-For each call family, we compute a table like this (after annotation
-finished)::
-
-          call_shape   FuncDesc1   FuncDesc2   FuncDesc3   ...
-  ----------------------------------------------------------
-   call0    shape1       graph1
-   call1    shape1       graph1      graph2
-   call2    shape1                   graph3     graph4            
-   call3    shape2                   graph5     graph6
-
-
-We then need to merge some of the lines if they look similar enough,
-e.g. call0 and call1.  Precisely, we can merge two lines if they only
-differ in having more or less holes.  In theory, the same graph could
-appear in two lines that are still not mergeable because of other
-graphs.  For sanity of implementation, we should check that at the end
-each graph only appears once in the table (unless there is only one
-*column*, in which case all problems can be dealt with at call sites).
-
-(Note that before this refactoring, the code was essentially requiring
-that the table ended up with either one single row or one single
-column.)
-
-The table is computed when the annotation is complete, in
-compute_at_fixpoint(), which calls the FuncDesc's consider_call_site()
-for each call site.  The latter merges lines as soon as possible.  The
-table is attached to the call family, grouped by call shape.
-
-During RTyping, compute_at_fixpoint() is called after each new ll
-helper is annotated.  Normally, this should not modify existing tables
-too much, but in some situations it will.  So the rule is that
-consider_call_site() should not add new (unmerged) rows to the table
-after the table is considered "finished" (again, unless there is only
-one column, in which case we should not discover new columns).
-
-XXX this is now out of date, in the details at least.
-
-RTyping other callable PBCs
-===========================
-
-The above picture attaches "calltable" information to the call
-families containing the function.  When it comes to rtyping a call of
-another kind of pbc (class, instance-method, frozenpbc-method) we have
-two basic choices:
-
- - associate the calltable information with the funcdesc that
-   ultimately ends up getting called, or
-
- - attach the calltable to the callfamily that contains the desc
-   that's actually being called.
-
-Neither is totally straightforward: the former is closer to what
-happens on the trunk but new families of funcdescs need to be created
-at the end of annotation or by normalisation.  The latter is more of a
-change.  The former is also perhaps a bit unnatural for ootyped
-backends.

diff --git a/pypy/doc/discussion/emptying-the-malloc-zoo.rst b/pypy/doc/discussion/emptying-the-malloc-zoo.rst
deleted file mode 100644
--- a/pypy/doc/discussion/emptying-the-malloc-zoo.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-.. coding: utf-8
-
-Emptying the malloc zoo
-=======================
-
-Around the end-of-the-EU-project time there were two major areas of
-obscurity in the memory management area:
-
- 1. The confusing set of operations that the low-level backend are
-    expected to implement.
-
- 2. The related, but slightly different, confusion of the various
-    "flavours" of malloc: what's the difference between
-    lltype.malloc(T, flavour='raw') and llmemory.raw_malloc(sizeof(T))?
-
-At the post-ep2007 sprint, Samuele and Michael attacked the first
-problem a bit: making the Boehm GC transformer only require three
-simple operations of the backend.  This could be extending still
-further by having the gc transformer use rffi to insert calls to the
-relevant Boehm functions^Wmacros, and then the backend wouldn't need
-to know anything about Boehm at all (but... LLVM).
-
-A potential next step is to work out what we want the "llpython"
-interface to memory management to be.
-
-There are various use cases:
-
-**lltype.malloc(T) &#8211; T is a fixed-size GC container**
-
-  This is the default case.  Non-pointers inside the allocated memory
-  will not be zeroed.  The object will be managed by the GC, no
-  deallocation required.
-
-**lltype.malloc(T, zero=True) &#8211; T is a GC container**
-
-  As above, but all fields will be cleared.
-
-**lltype.malloc(U, raw=True) &#8211; U is not a GC container**
-
-  Blah.

diff --git a/pypy/doc/discussion/paper-wishlist.rst b/pypy/doc/discussion/paper-wishlist.rst
deleted file mode 100644
--- a/pypy/doc/discussion/paper-wishlist.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-Things we would like to write papers about
-==========================================
-
-- object space architecture + reflective space
-- stackless transformation
-- composable coroutines
-- jit:
-  - overview paper
-  - putting our jit into the context of classical partial evaluation
-  - a jit technical paper too, probably
-
-- sandboxing
-
-Things about which writing a paper would be nice, which need more work first
-============================================================================
-
-- taint object space
-- logic object space
-
-- jit
-
-  - with some more work: how to deal in a JIT backend with less-that-
-      full-function compilation unit
-
-  - work in progress (Anto?): our JIT on the JVM
-  - (later) removing the overhead of features not used, e.g. thunk space or
-      another special space

diff --git a/pypy/doc/discussion/summer-of-pypy-pytest.rst b/pypy/doc/discussion/summer-of-pypy-pytest.rst
deleted file mode 100644
--- a/pypy/doc/discussion/summer-of-pypy-pytest.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-============================================
-Summer of PyPy proposal: Distributed py.test
-============================================
-
-
-Purpose:
-========
-
-The main purpose of distributing py.test is to speedup tests
-of actual applications (running all pypy tests already takes
-ages).
-
-Method:
-=======
-
-Remote imports:
----------------
-
-On the beginning of communication, master server sends to client
-import hook code, which then can import all needed libraries.
-
-Libraries are uploaded server -> client if they're needed (when
-__import__ is called). Possible extension is to add some kind of
-checksum (md5?) and store files in some directory.
-
-Previous experiments:
----------------------
-
-Previous experiments tried to run on the lowest level - when function/
-method is called. This is pretty clear (you run as few code on client
-side as possible), but has got some drawbacks:
-
-- You must simulate *everything* and transform it to server side in
-  case of need of absolutely anything (tracebacks, short and long,
-  source code etc.)
-- It's sometimes hard to catch exceptions.
-- Top level code in testing module does not work at all.
-
-Possible approach:
-------------------
-
-On client side (side really running tests) run some kind of cut-down
-session, which is imported by remote import at the very beginning and
-after that, we run desired tests (probably by importing whole test
-file which allows us to have top-level imports).
-
-Then we transfer output data to server as string, possibly tweaking
-file names (which is quite easy).
-
-Deliverables:
-=============
-
-- better use of testing machines
-- cut down test time
-- possible extension to run distributed code testing, by running and
-  controlling several distributed parts on different machines.

diff --git a/pypy/doc/discussion/parsing-ideas.rst b/pypy/doc/discussion/parsing-ideas.rst
deleted file mode 100644
--- a/pypy/doc/discussion/parsing-ideas.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-add a way to modularize regular expressions:
-
-_HEXNUM = "...";
-_DECNUM = "...";
-NUM = "{_HEXNUM}|{_DECNUM}";


More information about the Pypy-commit mailing list