[pypy-commit] extradoc extradoc: merged upstream

[alex_gaynor]

Author: Alex Gaynor <alex.gaynor at gmail.com>
Branch: extradoc
Changeset: r4099:ba04f56772e5
Date: 2012-02-21 20:26 -0500
http://bitbucket.org/pypy/extradoc/changeset/ba04f56772e5/

Log:	merged upstream

diff --git a/planning/separate-compilation.txt b/planning/separate-compilation.txt
new file mode 100644
--- /dev/null
+++ b/planning/separate-compilation.txt
@@ -0,0 +1,81 @@
+Separate Compilation
+====================
+
+Goal
+----
+
+Translation extension modules written in RPython.
+The best form is probably the MixedModule.
+
+Strategy
+--------
+
+The main executable (bin/pypy-c or libpypy-c.dll) exports RPython
+functions; this "first translation" also produces a pickled object
+that describe these functions: signatures, exception info, etc.
+
+It will probably be necessary to list all exported functions and methods,
+or mark them with some @exported decorator.
+
+The translation of an extension module (the "second translation") will
+reuse the information from the pickled object; the content of the
+MixedModule is annotated as usual, except that functions exported by
+the main executable are now external calls.
+
+The extension module simply has to export a single function
+"init_module()", which at runtime uses space operations to create and
+install a module.
+
+
+Roadmap
+-------
+
+* First, a framework to test and measure progress; builds two
+  shared libraries (.so or .dll):
+  
+  - the first one is the "core module", which exports functions 
+  - that can be called from the second module, which exports a single
+    entry point that we call call with ctypes.
+
+* Find a way to mark functions as "exported".  We need to either
+  provide a signature, or be sure that the functions is somehow
+  annotated (because it is already used by the core interpreter)
+
+* Pass structures (as opaque pointers). At this step, only the core
+  module has access to the fields.
+
+* Implement access to struct fields: an idea is to use a Controller
+  object, and redirect attribute access to the ClassRepr computed by
+  the first translation.
+
+* Implement method calls, again with the help of the Controller which
+  can replace calls to bound methods with calls to exported functions.
+
+* Share the ExceptionTransformer between the modules: a RPython
+  exception raised on one side can be caught by the other side.
+
+* Support subclassing.  Two issues here:
+
+  - isinstance() is translated into a range check, but these minid and
+    maxid work because all classes are known at translation time.
+    Subclasses defined in the second module must use the same minid
+    and maxid as their parent; isinstance(X, SecondModuleClass) should
+    use an additional field.  Be sure to not confuse classes
+    separately created in two extension modules.
+
+  - virtual methods, that override methods defined in the first
+    module.
+
+* specialize.memo() needs to know all possible values of a
+  PreBuildConstant to compute the results during translation and build
+  some kind of lookup table.  The most obvious case is the function
+  space.gettypeobject(typedef).  Fortunately a PBC defined in a module
+  can only be used from the same module, so the list of prebuilt
+  results is probably local to the same module and this is not really
+  an issue.
+
+* Integration with GC.  The GC functions should be exported from the
+  first module, and we need a way to register the static roots of the
+  second module.
+
+* Integration with the JIT.
diff --git a/talk/sea2012/talk.rst b/talk/sea2012/talk.rst
--- a/talk/sea2012/talk.rst
+++ b/talk/sea2012/talk.rst
@@ -8,9 +8,9 @@
 
 * What is PyPy and why?
 
-* Numeric landscape in python
+* Numeric landscape in Python
 
-* What we achieved in PyPy?
+* What we achieved in PyPy
 
 * Where we're going?
 
@@ -21,7 +21,7 @@
 
 * A framework for writing efficient dynamic language implementations
 
-* An open source project with a lot of volunteer effort, released under the BSD license
+* An open source project with a lot of volunteer effort, released under the MIT license
 
 * I'll talk today about the first part (mostly)
 
@@ -36,28 +36,28 @@
 
 * XXX some benchmarks
 
-Why would you care?
--------------------
+Why should you care?
+--------------------
 
 * *If I write this stuff in C/fortran/assembler it'll be faster anyway*
 
 * maybe, but ...
 
-Why would you care (2)
-----------------------
+Why should you care? (2)
+------------------------
 
 * Experimentation is important
 
 * Implementing something faster, in **human time**, leaves more time for optimizations and improvements
 
-* For novel algorithms, being clearly expressed in code makes them easier to evaluate (Python is cleaner than C often)
+* For novel algorithms, clearer implementation makes them easier to evaluate (Python often is cleaner than C)
 
 |pause|
 
 * Sometimes makes it **possible** in the first place
 
-Why would you care even more
-----------------------------
+Why would you care even more?
+-----------------------------
 
 * Growing community
 
@@ -65,8 +65,8 @@
 
 * There are many smart people out there addressing hard problems
 
-Example why would you care
---------------------------
+Example of why would you care
+-----------------------------
 
 * You spend a year writing optimized algorithms for a GPU
 
@@ -78,11 +78,11 @@
 
 * Alternative - **express** your algorithms
 
-* Leave low-level details for people who have nothing better to do
+* Leave low-level details to people who have nothing better to do
 
 |pause|
 
-* .. like me (I don't know enough physics to do the other part)
+* ... like me (I don't know enough Physics to do the other part)
 
 Numerics in Python
 ------------------
@@ -197,7 +197,7 @@
 
 |pause|
 
-* However, leave knobs and buttons for advanced users
+* However, retain knobs and buttons for advanced users
 
 * Don't get penalized too much for not using them