Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday December 22, 2006
01:45 PM

Perl 6 Design Meeting Notes for 20 December 2006

[ #31990 ]

The Perl 6 Design team met via phone on 20 December 2006. Allison, Jesse, Nicholas, and chromatic attended. These are the notes.

c:

  • 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

Allison:

  • 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

Jesse:

  • anything new in spec land?

Allison:

  • 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

Jesse:

  • 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

Allison:

  • not all OSes have async IO too
  • you have to implement it at the application level there

Nicholas:

  • why are threads too heavy for async IO?

Allison:

  • it's too process heavy
  • the people who've worked with it talked about a polling model

Nicholas:

  • 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

Jesse:

  • and presumably you can have a different implementation in different circumstances
  • is the goal to define the API or the requirements?

Allison:

  • 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

Jesse:

  • is the API waiting on the implementation idea?

Allison:

  • right now yes

Jesse:

  • I'd like to see those broken out
  • get the spec done
  • what's left is "how to make it go"

Allison:

  • I'm not sure the spec has quite enough detail for that yet
  • we'll see

Jesse:

  • 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
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.