[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