Bern Sprint, First Day, October 22
So, it seems customary for the Squeak community to use such incredibly advanced technology as RSS feeds and blogs to disseminate their sprint reports, which means us old-fashioned PyPyers just have to follow suit.
Today started the first ever Pypy-Squeak-collaboration sprint, kindly hosted in Bern by the Software Composition Group. The sprint aims to bring people from two different communities together (not without the unavoidable clash of culture, the first wars on zero- versus one-based indexing were already fought today) to learn about each others projects and to explore collaboration possibilies.
Morning was spent setting up the sprint room and general computer infrastructure like Squeak's VMMaker and Pypy. It seems that bootstrapping Squeak is certainly faster then bootstrapping Pypy (and uses way less memory) but not without certain problems. Adrian Kuhn tried to distribute an USB stuck containing a zip archive created under Windows. This turned out to be a bad idea, as obviously the notion of execution access permission is not known to Windows but crucial for Unices. In the end we finally succeeded. The PyPy checkouts of the Squeak guys on the other hand went quite smooth. Nobody tried to translate PyPy yet, though.
After lunch, Armin and Carl Friedrich gave various talks and demo for the SCG crowd (including some increasingly confused students). The first talk covered sprint-driven development in a two-slide presentation, including visualizations of software evolution, then we delved into the technical topics by re-giving our Dyla talk and demos.
After a break, we started brainstorming. We identified the following options as possible main goals for this week's sprint
* to implement a Squeak-bytecode interpreter in RPython
* to define and implement an RSqueak as PyPy frontend
* to write a Squeak backend for PyPy
even though option 2 was favoured as long term goal, we decided to go for the first option. To complete the second option, we felt, that we miss yet an understanding of the second option's trade-offs. Now, we do option one to gain insight into and a feel for the second option. We broke the first option down into smaller steps, as shown on this picture
Next Carl Friedrich quickly introduced the Squeak crowd to RPython, whereas Adrian Kuhn gave a quick and dirty introduction into the Smalltalk object model: "objects all the way down".
Finally, everyone gathered around Armin's laptop, who started hacking the very beginning of said object model into a set of RPython classes. Always writing tests first, true to Test Driven Development (while the rest of the crowed watched in amazement how the svn comments are announced live on PyPy's IRC channel). If you are interested in this very first prototype, please refer to the svn repo.
Please stay tuned for more news tomorrow.
Carl Friedrich Bolz and Adrian Kuhn
Monday, October 22, 2007
Subscribe to:
Post Comments (Atom)
5 comments:
Exciting! I wish you all the best of luck. This collaboration is really intriguing, and I hope something really cool comes from it.
This sounds great! I've been quite interested in Smalltalk/Squeak for a long time, and I think PyPy can provide a nice base for extension and development of both Python and Squeak going forward.
I'm not sure if it would be feasible, but is there any way that audio recordings could be made of the discussions (unless there are plans for more detailed reports after the sprint is complete)?
great work! Hoping to see how far will you go with this sprint.
If someone could explain the differences between the three goal options in terms of what they yield, that would assist my understanding of PyPy no end!
1..
>>
* to implement a Squeak-bytecode interpreter in RPython
<<
This yields an interpreter, on PyPy's back ends, that executes user level Squeak code (compiled in Squeak) -yes?
The Squeak bytecode would be PyPy jitable -yes?
Question: Would this interpreter necessarily need to implemented the interpreter-objectspace separation (plus flowspace)? Or is this separation only required if we want to translate (including jit) Squeak bytecode?
2.
>>* to define and implement an RSqueak as PyPy frontend<<
This allows translation of RSqueak code to PyPy backends -much as slang does to C (but allowing more dynamism than slang). Yes?
One might then write an interpreter for Squeak in RSqueak -and the result would, ceteris paribus, be identical to 1 above in terms of capabilities. Yes?
>>
* to write a Squeak backend for PyPy
<<
So we would have a Python interpreter running on the Squeak VM? -executing Python bytecode on top of Squeak (which would be pretty slow) -or is there a way of getting from Python source to *Squeak* bytecode a la Jython/IronPython on JVM/CLR?
Sorry for all these questions -it is keeping me up at night.
@Charles
There will (hopefully) be more detailed reports after the sprint. These week we are all busy hacking :)
Post a Comment