The Perl 6 design team met on 12 December 2007 by phone. Allison, Patrick, Will, Jerry, Jesse, Richard, and chromatic attended.
Patrick:
- it looks possible that I could meet up with Flavio in Europe after FOSDEM at the end of February
- we're talking on IRC
- things are going really well
- I managed to convert Pynie to the new compiler tools on the plane last weekend
- four forty-minute chunks were enough to do it, plus some time in the airport
- mostly answering questions and helping people convert various languages over to the new toolkit
- Perl 6 has some more passing tests and new features
- we're getting the features passed in a correct manner that matches the intent of the spec
- removing some of the previous workarounds
- I'm happy about that
- we've had some discussions about coordinating between kp6 and this effort
- we're going to see if we can get kp6 to target NQP
- it's been a very full week; refer to my journal
Jerry:
- converted Punie to NQP
- it's passing some of the tests that were TODO
- there are some things in the compiler toolkit that aren't quite ready yet, so I'll block on them
- slurpy arguments for example
Patrick:
- I'll try to get that in there tonight
- it's not difficult
Jerry:
- had some discussions with Flavio and other kp6 developers
- we're talking about coordination efforts
- Flavio started an NQP backend for kp6 today
- it's amazing how similar these things are
- we already have the 01-tap.t test running on kp6 using NQP
Jesse:
- it sounds like there'll be a fair bit of overlap between these projects
Jerry:
- we'll both be able to target the Parrot backend through the compiler tools
- then we can steal information on algorithms and techniques used between the two
- eventually converge on a solution
Jesse:
- how different are the implementations?
Jerry:
- I'm not familiar enough with the internals of kp6 to answer that
- Patrick will tell you that kp6 and mp6 inspired NQP earlier
- the architectures are somewhat similar
Patrick:
- one big question in terms of similarity
- how does kp6 handle a runtime environment?
- NQP doesn't handle one beyond what Parrot does
- that depends on how kp6 implements its primitives and what they happen to be
Jerry:
- I need to turn my attention back to Perl 6
- definitely busy with these three implementations
Allison:
- I think I fixed the concurrency bug from last week
- a threading deadlock only present in MP machines
- it came down to a wake signal getting sent too early for the sleeping thread to catch it
- waiting for confirmation from people with affected machines
- did check in the last bits of the event handler code
- pretty much the last task of that
- just need to switch the capturing of low-level signals from the old event thread to the new concurrency scheduler thread
- that'll be the end of that implementation
- next is the MMD PDD
Will:
- is that still on target for the 15th, or will you push that back?
Allison:
- it'll be a couple of days after the 15th, but it won't be much longer than that
- it takes about three days to do a good solid PDD
c:
- fixed a couple of nasty Parrot bugs
- one in the concurrency system
- tried to implement the
copy opcode, but have some questions
- also still planning to implement the scheduling algorithm, unless Allison has finished it
Allison:
- it's a naive queue right now
- not needed until we add other things to the scheduler
- but it'll get used when you add it
Will:
- I'll cut the 0.5.1 release next Tuesday, so Allison can do real work
- we have six release managers for next year, so the schedule will come out along with the release
- minor cleanup in the tree too
- that's about it
Richard:
- TPF officially accepted Patrick's work for the past month
- we reported that to the Mozilla Foundation too
- made a public announcement on news.perlfoundation.org
- very happy to release that good news to the world
- spending some time looking for hackathon sponsors
c:
- let me bring up the question about the
copy operator
- it's not clear how to know which pieces of a PMC to copy
Patrick:
- that's why I suggested the use of
clone in my original proposal
c:
- we need a
clone that reuses a header
- we probably also need to call
destroy to handle any deallocation, or we may have unreachable memory
Allison:
- as long as all
destroys behave properly and just deallocate things
c:
- we have a nice separation between destruction and deallocation, so well-behaved ones should be fine
Patrick:
- maybe the right way to refactor this is to say that
copy takes an existing header and does the copy
-
clone creates a new header and does the copy
- certainly easier than updating every PMC's
assign
c:
- that's a flash of insight, so I'll try that
Patrick:
- I'm so glad you're doing that and not me
c:
Jesse:
- I'm so glad you're doing Perl 6, Patrick
Richard:
- can I just say that I've been watching the discussions between particle, Patrick, and Flavio and I'm impressed at the forward progress?
