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 01, 2006
04:22 PM

Perl 6 Design Meeting Notes for 29 November 2006

[ #31780 ]

The Perl 6 Design team met via phone on 29 November 2006. Larry, Damian, Allison, Patrick, Jesse, and chromatic attended. These are the notes.

Patrick:

  • things are going well
  • keeping busy
  • making good progress
  • made the new PAST implementation
  • seems to be working out really well
  • has the right primitives in the right places for the kinds of compilers I've been working on
  • Allison's given me tons of great feedback
  • I'm slowly incorporating her ideas
  • having tons of fun doing all that
  • have lots more of the sanity tests implemented for Perl 6
  • have some implemented but not checked in
  • I'm letting that simmer before I check in improvements
  • finding a couple of sanity tests that build on non-standard Perl 6 features
  • I'll do some commits to bring them in line with the latest specs
  • hope to have that working in the next couple of weeks
  • could start running the Pugs test suite then
  • might just point people to my #parrotsketch reports (pmichaud #parrotsketch report for 21 November 2006 and pmichaud #parrotsketch report for 28 November 2006)
  • spent an hour walking PerlJam through the compiler tools on #parrot
  • I logged it; it'll go into the repository as an overview

c:

  • think I've basically convinced Allison of the value of a MOP for Parrot
  • will work on that a little bit more
  • I had a prototype a couple of months ago
  • I'll refresh that

Allison:

  • Patrick's stuff has kicked forward the design of the compiler tools
  • I've played with it in Punie; have lots of feedback on it
  • I'm just about ready to commit it
  • I have the last lingering little bits of the IO PDD
  • it's pretty much just the Parrot IO object API
  • not a big piece
  • reading a bit on Ruby metaclasses
  • we had a really good conversation about Parrot objects after #parrotsketch
  • I have a much better grasp on the scope of the problem
  • some of the most important questions

Patrick:

  • that's an astounding achievement
  • it's difficult to do
  • it's also very important and necessary
  • I'm ecstatic with the conversation that took place
  • that's exactly what I wanted to hear

Allison:

  • I expect we'll have snippets like that every once in a while
  • that seems to be really helpful
  • oh, and maybe we'll use roles instead of metaclasses

Larry:

  • keeping my fingers lightly on everything that's going on
  • thinking a lot about discussions on p6l
  • come to a conclusion on bags and sets
  • haven't come to a conclusion about some of the questions of closures
  • touches on the nature of dynamic versus lexical scoping
  • the relationship of those versus STM
  • some of those popped up for Parrot lately too
  • did a lot of driving last week for some reason
  • also converting some of my CJK radical dictionary programs to Perl 6
  • fairly happy with those results
  • anxiously looking forward to running those on the Parrot backend

Allison:

  • it would be interesting to get a list of features that you need

Patrick:

  • that would prioritize things
  • or turn the code into tests somehow
  • I can target those tests first

Larry:

  • other than the basic syntax
  • the main thing I've used is roles instead of inheritance
  • the roles turn out to be somewhat faster than inheritance
  • composition time is more direct
  • it's a hand optimization
  • in theory the compiler ought to perform it for me, but it doesn't
  • I'm not performing much fancy stuff

Patrick:

  • the big stumbling block for now is the angle bracket as list constructors
  • parsing that is a trick

Jesse:

  • how much spec change do you end up making as you hack?

Larry:

  • not a lot
  • we're definitely in the mode where we try to fill in the cracks that we didn't think about
  • those implicitly implied by the things that are already there
  • the earth-shaking changes tend to be few and far between
  • mostly it's just going over it to see if we're saying everything we want to say

Damian:

  • still struggling with time issues
  • within one feature of having the POD 6 parser released
  • likely a week or two away

Patrick:

  • I have a question about coordinating test suites
  • as I get close to finishing the sanity tests for the Perl 6 compiler, people will clamor for importing the Pugs test suite into the Parrot repo
  • should we clarify that somehow?
  • any advice on how to proceed?

Allison:

  • the answer is "yes, we can just import the test suite"
  • Audrey is okay with that
  • we need to try to get contributor agreements from people who have committed to the test suite
  • we don't have to wait to get those first
  • we do need to try to get the names of contributors
  • we'll have someone gradually work on that

c:

  • can we use svn:externals to keep them synchronized?

Jesse:

  • I'd hate to see them fall out of synchronization

Patrick:

  • I'd like to see a single test suite
  • I have difficulty seeing how to coordinate working between two repos

Jesse:

  • I hear that the Pugs folks are willing to do plenty of work to make that work

Larry:

  • even just copy and paste

Allison:

  • they do need to ship with stable Parrot releases

Jesse:

  • you can do imports or mirroring

Allison:

  • you don't want to require everyone to be a committer on the Pugs project to contribute to the tests though
  • even though it's trivially easy
  • Perl 6 and Parrot are two independent projects
  • maybe we need an independent repository for the Perl 6 test suite
  • neither Pugs nor Parrot
  • make sure that the infrastructure code for both call into the implementation-agnostic test suite repository

Jesse:

  • I worry about what that'll mean for commit bits about the independent test suite
  • Pugs does have mirroring into svn.perl.org

Patrick:

  • maybe I don't understand how it works
  • if I'm working in Parrot's Perl 6 and I need to add a test, what do I do?
  • do I svn up for Pugs, add a test, commit a test, then svn up for Parrot?

Jesse:

  • would you object to always using the tests directly from the Pugs repository until something sane gets worked out?
  • it's not a discussion we can make a decision on here now
  • it has to involve the Pugs people too

Allison:

  • that's fine
  • I'd eventually like the test suite to be pure Perl 6
  • or at least abstracted from any implementation infrastructure

Jesse:

  • seems to be a reasonable goal once it's not a moving target

Allison:

  • don't wait for that to happen!

Jesse:

  • I don't want to yank the Pugs test suite, make it the official test suite, and then make it hard for them to contribute to it

Allison:

  • oh, absolutely not

c:

  • we have a repository for the specification documents
  • why not put the test suite in that repository?
  • not everyone can commit to the specs and Synopses, but that repo

Allison:

  • how about this?
  • Pugs remains for now the primary repo
  • all commits to there
  • the Perl svn repo gets a mirror of those tests (not the full Pugs mirror)
  • we work on the tests to remove any code specific to a particular implementation
  • get the tests generic when we can

general agreement

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.