Friday December 22, 2006
Perl 6 Design Meeting Notes for 20 December 2006
The Perl 6 Design team met via phone on 20 December 2006. Allison, Jesse, Nicholas, and chromatic attended. These are the notes.
- the Parrot Bug day went well
- we attracted a few new contributors
- think we regained some portability
- think we fixed the bug where it's tough to build Parrot if you have a libparrot installed
- we'll probably do another one in January
- seems like one a month will be good
- nothing but highest praise for the Bug Day
- trying to get Punie finished now
- no measurable sense of progress or time remaining
- it's just "find a bug, fix a bug"
- also refactoring the new PAST-pm or Patridge or whatever we call it
- have high-level tests in for PAST and POST and HLLCompiler
- it'll get easier to test with more refactoring
- that's pretty much it for me
- anything new in spec land?
- Jonathan asked me about the OO spec
- I want to finish off the IO PDD
- the last thing is to finish off the concurrency model
- IO is separate from the broader concurrency model
- threads is just too heavyweight for async IO
- an earlier version had a strawman along those lines
- some very smart people I know who've been thinking about concurrency think that there are two separate levels of concurrency
- OS-level concurrency and application concurrency
- not all OSes have async IO too
- you have to implement it at the application level there
- why are threads too heavy for async IO?
- it's too process heavy
- the people who've worked with it talked about a polling model
- in the same thread while you're doing your normal bytecode dispatch?
- if the API abstraction is right, it doesn't matter to the people using the API or the people using the bytecode whether the implementation uses one OS thread which polls or on an SMP machine whether one OS thread runs the bytecode and the other blocks on polling and notifies the other thread somewhere
- and presumably you can have a different implementation in different circumstances
- is the goal to define the API or the requirements?
- yes, but Leo has also asked for a selection of the first implementation model
- not a guarantee of the one true implementation for all time
- is the API waiting on the implementation idea?
- I'd like to see those broken out
- get the spec done
- what's left is "how to make it go"
- I'm not sure the spec has quite enough detail for that yet
- we'll see
- I'm trying to get in touch with Chip to figure out how to smooth the release processes
- no meeting next week; can't imagine everyone will be around then
- we'll talk in the new year, unless questions come up