Larry, Allison, Nicholas, Damian, Patrick, Jesse, and chromatic attended the Perl 6 design meeting on 09 August 2006. These are the minutes.
Larry:
- things are doing pretty good
- fighting the hardware wars a little bit
- doing my usual
- putting the .meta and other pseudo-methods in type space
- unifying them with uppercase names
- instead of conflicting with user-defined lower-case names
- otherwise trying to keep up to date on everything that's going
on
Allison:
- spent yesterday pontificating on the subordinate runloop
problem
- it's very interesting
- involved absorbing lots of auxiliary information about CPS and
such
Larry:
- Leo's latest message is well-taken
- going stackless fixes a lot of things
Nicholas:
- is Parrot breaking new ground here?
- is it the first VM that allows you to use continuations as well
as calling back into bytecode?
- why is it so hard?
- are we trying to combine two different things here?
Allison:
- most CPS-based VMs are for functional languages
- they're not fond of side-effecty stuff here
- I don't know if anyone's tried to make a CPS-based VM that is
also readily available from C
- the problem Bob chose was close to tied variables
- the real problem is any time you try to extend such a system
from C
Larry:
- any callback
- you can send a message to the main runloop that says "call this
back"
- it's hard to synchronize those
- if it's a callback and you have to capture control back from C
in that point, you have another problem
Nicholas:
- function pointer passing and holding state...
Larry:
- basically treating your runloop as a coroutine into your C
program
c:
- that's what we said yesterday actually!
- either we're all wrong or we're all right
Damian:
- things are okay, after a weeklong timezone synchronization
struggle
- working on finalizing the POD specification
- I'll pass that around later today, I hope
- may not have an actual parser implementation today
- still working on that
- I have two versions of the specification, one for Perl 5 and
Perl 6
Nicholas:
- I presume you can produce the same output from both sides
- for the regression tests
Damian:
- I'd like to get it to round-trip, modulo blank lines
Nicholas:
- in theory a POD 5 to POD 6 translator?
Damian:
- not working on that right now
Larry:
- maybe Sage will throw one in for free
Jesse:
- I'm sure we can find someone to whip up a basic translator
Damian:
- given the tools for parsing POD 5, emission should be
trivial
- POD 6 is backwards compatible
- going from POD 6 to POD 5 is harder
- you'll have to throw away information
Allison:
- I do need to do a lot more work on POD::Simple
- having a POD 6 variant could be good
Damian:
- gearing up for the next trip to Portugal, YAPC::EU, etc.
- keeping me busy
- haven't seen anything I need to jump in about lately
Patrick:
- working on the TGE redesign and documents
- not much to report
- glad to see the new Parrot release, so I can break PGE and not
worry about the release cycle
- expect to have a new Capture object by this time tomorrow
- we can build many more things on top of it
- will use it as the base class for PGE's match object
c:
- did some work on deploying Parrot
- ran into some problems with paths in load* code
- have some workarounds
- not sure exactly where the problem is
- but I can see this being a problem in the future
Patrick:
- my impression on load_bytecode and loadlib is that they haven't
been specified because we assumed that we'd always do them
later
- what's in there now is just scaffolding to get things to kinda
work
- we actually have the Parrot tree better organized now
- it might not be too much work, but it will be some
- "make install" itself is a problem
- advised Chip et al to modify that target to warn people not to
use it
Nicholas:
- make install I remember needing for Ponie
- it's been a problem for a while
- Parrot's almost backwards with regard to how it's doing shared
libraries
- Perl 5 builds into the executable the library information
- use environment variables to override that
- Parrot seems to build in the building location
- that may be what the problem is
- right now it seems optimized for running out of its build
tree
Jesse:
- would dealing with this be a good task for the Cage
Cleaners?
Patrick:
- sounds more designish than cleanup
Nicholas:
- it needs someone with a bit of experience
- Chip has that experirence
Patrick:
- sounds like it needs an RT ticket with a bump in priority
c:
- I'll look into this a bit more and file the ticket
