[pypy-svn] r21581 - pypy/extradoc/talk/22c3

hpk at codespeak.net hpk at codespeak.net
Wed Dec 28 09:39:20 CET 2005


Author: hpk
Date: Wed Dec 28 09:39:18 2005
New Revision: 21581

Modified:
   pypy/extradoc/talk/22c3/hpk-tech.txt
   pypy/extradoc/talk/22c3/part_bea.txt
Log:
formatting checkin 


Modified: pypy/extradoc/talk/22c3/hpk-tech.txt
==============================================================================
--- pypy/extradoc/talk/22c3/hpk-tech.txt	(original)
+++ pypy/extradoc/talk/22c3/hpk-tech.txt	Wed Dec 28 09:39:18 2005
@@ -9,12 +9,6 @@
 
 .. holger 
 
-PyPy/Translation overview
-=========================
-
-.. image:: translation-overview.png
-   :scale: 500
-
 Python implementation facts 
 ===========================
 
@@ -29,21 +23,28 @@
 - CPython: main Python version (BDFL'ed by Guido)
 - Jython: compiles to Java Bytecode
 - IronPython (MS): compiles to .NET's CLR 
-- PyPy: self-contained - self-translating 
+- PyPy: self-contained - self-translating - flexible
+
+PyPy project facts 
+=======================
+
+- started 2002 as a grass-root effort
+- aims: flexibility, research, speed 
+- test-driven development 
+- received EU-funding from end 2004 on  
+- 350 subscribers to pypy-dev, 150.000 LOCs, 20.000 visitors per month, 
+- MIT license
 
 PyPy implementation facts
 ============================
 
-- implements full Python language in Python itself 
+- implements Python language in Python itself 
 - parts implemented in a restricted subset: RPython 
 - "static enough" for full-program type inference
-- but at boot time we allow unrestricted python! 
-- 350 subscribers to pypy-dev, 150.000 LOCs, 20.000 visitors per month, 
-- MIT license 
+- at boot time we allow unrestricted python! 
 
 PyPy/Python architecture 
 =============================
-[picture]
 
 - parser and compiler
 - bytecode interpreter 
@@ -51,6 +52,14 @@
 - Python VM = interpreter + Standard Object Space
 - builtin and fundamental modules 
 
+PyPy/Python architecture picture
+==================================
+
+.. image:: interpreter-overview.png
+   :width: 650
+   :height: 400
+
+
 Parser and Compiler
 ===================
 
@@ -58,23 +67,24 @@
 - compiles AST to code objects (bytecode) 
 - works from the CPython grammar definition 
 - can be modified/extended at runtime (almost) 
-- [showing interactively] ... 
+- [interactive command line dis-example] ... 
 
 Bytecode interpreter
 ====================
 
-- interprets bytecode/code objects through "Frames" 
+- interprets bytecode/code objects through Frame objects 
 - Frames tie to global and local variable scopes
 - implements control flow (loops, branches, exceptions, calls)
 - dispatches all operations on objects to an Object Library
-  ("Space")
+  or "Object Space"
 
 Object Spaces
 =============
 
 - library of all python types and operations on them 
+- encapsulates all knowledge about app-level objects 
 - is not concerned with control flow or bytecode 
-- ... 
+- e.g. enough control to implement lazy evaluation 
 
 Builtin and Fundamental Modules
 ===============================
@@ -101,6 +111,12 @@
 - Specialising to lltypesystem / ootypesystem 
 - C and LLVM Backends to lltypesystem 
 
+PyPy/Translation overview
+=========================
+
+.. image:: translation-overview.png
+   :height: 422
+   :width: 760
 
 Abstract Interpretation
 ========================
@@ -215,7 +231,7 @@
 - sprints
 - test-driven 
 - open source culture 
-- see talk tomorrow 5pm  (29th Dec. 2005)
+- see talk tomorrow 2pm  (29th Dec. 2005)
 
 technical outlook 2006
 ======================

Modified: pypy/extradoc/talk/22c3/part_bea.txt
==============================================================================
--- pypy/extradoc/talk/22c3/part_bea.txt	(original)
+++ pypy/extradoc/talk/22c3/part_bea.txt	Wed Dec 28 09:39:18 2005
@@ -5,48 +5,70 @@
 
 
 Core of Agile practises: the people factor
-- "Agile processes are designed to capitalize on each individual and each team´s unique strenghts" (Cockburn, Highsmith, 2001)
-- OSS nature of teams: self-organized, intensely collaborative - fit the agile approach
+============================================================
+
+- "Agile processes are designed to capitalize on each
+  individual and each team´s unique strenghts" (Cockburn, Highsmith, 2001)
+- OSS nature of teams: self-organized, intensely 
+  collaborative - fit the agile approach
 - OSS teams are an unique implementation of agile practices - why?
 
 Picture: man on the moon
 
 Agile approaches aim at:
-  * reducing 		"cost of information",distance from decision-making
-  * by 			physical location, unorthodox dissemination
-  * resulting in		improved sense of community, team "morale"
+============================================================
+
+* reducing ... "cost of information",distance from decision-making
+* by ... physical location, unorthodox dissemination
+* resulting in ... improved sense of community, team "morale"
 
 Origins of sprinting
-- Scrum (Agile community): 1 month long iteration of development work, increments 
-  (also supporting activities: planning, documentation, tracking work, evaluation)
-- Zope Foundation (Python Community): "two-day or three-day focused development session, 
-   in which developers pair off together in a room and focus on building a particular subsystem".    
+============================================================
+
+- Scrum (Agile community): 1 month long iteration of
+  development work, increments (also supporting activities:
+  planning, documentation, tracking work, evaluation)
+
+- Zope Foundation (Python Community): "two-day or three-day
+  focused development session, in which developers pair off
+  together in a room and focus on building a particular
+  subsystem".    
    
 PyPy sprints
+============================================================
 - The project "started" during a sprint
-- Changing facilities and location as a strategy (Vilnius, Lovain LeNeuve, Leysin, Gothenburg, 
-   Paris, Heidelberg, Hildesheim, Washington etc)
-- The nature of sprints have evolved since the project started 2003 and since recieving 
-   partial EU-funding 2004/2005
+- Changing facilities and location as a strategy (Vilnius,
+  Lovain LeNeuve, Leysin, Gothenburg, Paris, Heidelberg,
+  Hildesheim, Washington etc)
+- The nature of sprints have evolved since the project started
+  2003 and since recieving partial EU-funding 2004/2005
    
 Bidding for the EU-funding
-- Project needed to reach critical mass, EU needed novel compiler design techniques in OSS contexts
-- Proposal was written during sprints as well as distributed (submitted Oct 2003)
+============================================================
+- Project needed to reach critical mass, EU needed novel
+  compiler design techniques in OSS contexts
+
+- Proposal was written during sprints as well as distributed
+  (submitted Oct 2003)
 - Negotiations in Brussels (March 2004): key issues being 30% cuts in budget and  denied procedures for funding contribution
-- Project "started" 1 Dec 2004: troubles with creating consortium agreement fitting the OSS structure needed
+- Project "started" 1 Dec 2004: troubles with creating
+  consortium agreement fitting the OSS structure needed
 
 Organising the consortium
+============================================================
 - 7 partners, 3 previously not involved in the PyPy community
 - 2 new companies: "forced" entrepreneurship
 - All partners but one partially funded (50% cost models)
 - Less than 5% of the involved developers was covered by this partial funding
 
 Organising the work
+============================================================
 - 14 workpackages and 58 deliverables, 3 phases 
 - Need for consortium meetings every month (IRC)
-- Sprints every 6th week (coordinating the development and management work)
+- Sprints every 6th week (coordinating development and management work)
 
 The different cultures of the PyPy project
+============================================================
 - OSS (Python) culture (agile and distributed workstyle)
 - EU project culture
 - Traditional project management culture
@@ -54,18 +76,23 @@
 - 3 different national cultures
 
 The challenge: managing diversities part 1.
+============================================================
 - Formal project organization vs developer driven process
 		- management team, technical board and partners
 		- sprint organising
-- Resulting in: increased risk of added workload of management work on core developers 
+- Resulting in: increased risk of added workload of management
+  work on core developers 
 
 The challenge: managing diversities part 2.
+============================================================
 - Formal EU requirements vs agile strategies
 		- written high level requirements
 		- change control structures complicated
-- Resulting in:increased risk of missing opportunities and not creating/reacting to change fast enough
+- Resulting in:increased risk of missing opportunities and not
+  creating/reacting to change fast enough
 
 The challenge: managing diversities part 3.
+============================================================
 - OSS community vs "conceptual integrity"
 		- pypy-dev/core developers in technical board
 		- industrial usage vs research oriented work
@@ -74,7 +101,8 @@
 Picture: chaos vs structure
 
 Conclusion
+============================================================
 - A shared and challenging vision
 - Respecting and "exploiting" strengths of the different cultures involved
 - Designing minimalistic project structures channeling work, not hindering work
-- Room for group learning and creating change - not just reacting to change
\ No newline at end of file
+- Room for group learning and creating change - not just reacting to change



More information about the Pypy-commit mailing list