[pypy-svn] r52472 - pypy/extradoc/talk/pycon2008

[fijal at codespeak.net]

Author: fijal
Date: Fri Mar 14 01:35:46 2008
New Revision: 52472

Modified:
   pypy/extradoc/talk/pycon2008/pytest.txt
   pypy/extradoc/talk/pycon2008/status.txt
Log:
Minor changes.


Modified: pypy/extradoc/talk/pycon2008/pytest.txt
==============================================================================
--- pypy/extradoc/talk/pycon2008/pytest.txt	(original)
+++ pypy/extradoc/talk/pycon2008/pytest.txt	Fri Mar 14 01:35:46 2008
@@ -6,7 +6,8 @@
 ===========================================
 
 :authors: Maciej Fijalkowski, Holger Krekel (merlinux GmbH), Brian Dorsey
-:date: XXX
+:date: 16 March 2008
+:event: Pycon 2008, Chicago IL
 XXX fill details
 
 Intro

Modified: pypy/extradoc/talk/pycon2008/status.txt
==============================================================================
--- pypy/extradoc/talk/pycon2008/status.txt	(original)
+++ pypy/extradoc/talk/pycon2008/status.txt	Fri Mar 14 01:35:46 2008
@@ -49,7 +49,7 @@
 Status of PyPy
 ==============
 
-* Very compliant language (to Python 2.4/2.5)
+* Very compliant language (to Python version 2.4/2.5)
 
 * Some modules from the stdlib are missing, no 3rd party
   modules at all
@@ -87,50 +87,11 @@
 * If your problem is similiar enough to counting Fibonacci numbers,
   we're as fast as psyco
 
-* PyPy's JIT is way easier to extend (think PPC, think 64 bit,
+* PyPy's JIT is way easier to extend than psyco (think PPC, think 64 bit,
   think floats)
 
-RPython
-=======
-
-* The static subset of Python which we used for implementing the
-  interpreter
-
-* Our compiler toolchain analyzes RPython (i.e. interpreter source code,
-  like C), not the user program
-
-* Our interpreter is a "normal Python" interpreter
-
-* Only PyPy implementers should know anything about RPython
-
-RPython (2)
-===========
-
-* It's not a general purpose language
-
-* One has to have a very good reason to use it
-
-* Clunky error messages (XXX demo)
-
-* It's fast, it is pleasant not to code in C
-
-* Ideally, our JIT will achieve the same level of speed
-
-RPython - language
-==================
-
-* It's high level but only convenient if you want to write interpreters :-)
-
-* Usually tons of metaprogramming
-
-* Like C++ - you can write books about tricks
-
-* Hard to extend
-
-XXX this slides needs to fit somewhere
-
-Example of useful feature - sandboxing
-======================================
+Sandboxing
+==========
 
 * we analyze interpreter source (not user code) for
   all external function calls
@@ -146,11 +107,9 @@
 * special switches for buffer overflows and common
   errors in interpreters (disregard to user code!)
 
-* can work as well with smalltalk or prolog vm (XXX kill this?)
+* cannot segfault (unlike CPython)
 
-XXX demo
-
-Example of useful feature - tproxy
+Transparent proxy
 ===================================
 
 * app-level code for controlling behavior of
@@ -159,9 +118,7 @@
 * very similiar concept to the  .NET VM transparent
   proxy
 
-XXX demo
-
-Example of useful feature - distribution
+Distribution prototype
 =========================================
 
 * a very simple distribution protocol built
@@ -172,9 +129,44 @@
 * can work on any type, so you can
   raise a remote traceback and everything will be fine
 
-* nice experiment, few lines of code (XXX how many exactly?)
+* nice experiment, ~700 lines of code
+
+RPython
+=======
+
+* The static subset of Python which we used for implementing the
+  interpreter
 
-XXX demo
+* Our compiler toolchain analyzes RPython (i.e. interpreter source code,
+  like C), not the user program
+
+* Our interpreter is a "normal Python" interpreter
+
+* Only PyPy implementers should know anything about RPython
+
+RPython (2)
+===========
+
+* It's not a general purpose language
+
+* One has to have a very good reason to use it
+
+* Clunky error messages
+
+* It's fast, it is pleasant not to code in C
+
+* Ideally, our JIT will achieve the same level of speed
+
+RPython - language
+==================
+
+* It's high level but only convenient if you want to write interpreters :-)
+
+* Usually tons of metaprogramming
+
+* Like C++ - you can write books about tricks
+
+* Hard to extend
 
 PyPy - future
 =============