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)

Thursday August 10, 2006
08:02 PM

Perl 6 Design Meeting Notes for 09 August 2006

[ #30589 ]

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
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.