The Perl 6 design team met on 04 June 2008 by phone. Larry, Allison, Patrick, Jerry, Jesse, and chromatic attended.
Jerry:
- things are going well with GSoC
- Kevin's on vacation, and due back tomorrow
- he'll be getting to work then
- the other students seem to be working according to plan
- we'll start using the Pugs Trac to track additions to the Perl 6 test suite
- a place to request new tests
Jesse:
- is there a really good reason to use two different ticketing systems?
Jerry:
- it's already there and already has a category for Perl 6 tests
Patrick:
- already in use for Pugs
- and the Pugs repo already hosts the tests
- Rakudo still uses RT
Jerry:
- and there's nothing Perl 6 spec-related I know of that lives in any other ticketing system
- applying some good patches from contributors
- modified the test suite tools to make it easier to work with the spec tests in Rakudo
- you can specify a local list of tests to run
- added the ability to run the spec tests purely as they are, or fudged
- you can use a test config file for that
Larry:
- fudge already kinda has that built in
Jerry:
- if there are no directives in the file
- my addition allows you to ignore implementation-specific directives and run the file directly
Larry:
- and take the consequences
- that's fine
Jerry:
- talked to Patrick about Rakudo management
- we're considering adding some new committers
- looking for a better way to handle tickets for patches
- it's getting difficult for Patrick to apply all incoming patches
- interrupting his work
- we want to be able to appoint a person or persons to apply approved patches
c:
- I'm happy to apply anything once you've approved it and it's ready to apply
Jerry:
- that's what we're looking for
- that should make things easier for Patrick
Patrick:
- mostly Parrot time this week
- refactored list and array handling in Rakudo
- list assignment now works!
- the various composer works
- bare curly hash composition doesn't work yet
- that won't be hard to do
- just need to write some rules to detect when to build a block versus build a hash
- it'll happen soon
- Jonathan implemented a Mutable PMC, which implements Perl 6 scalars
- forwards its operations to what it contains
- we can assign to it and do type checks in the process
- some issues in Parrot's type management
- not always clear when we want to talk about the scalar as a scalar versus what it's containing
Allison:
- container type versus value type?
Patrick:
- yes
- the particularly nasty vtable entry for that is
find_method
- we'll look more into that in the next couple of weeks
- it's not impeding progress on us anymore
- lots of cleanup of the AST building routines
- some duplicated code, some refactoring there
- more of that coming in the next few days
- lots of little improvements and changes
- small cleanups
- more tests pass
- starting to keep a daily count of the number of passing tests of the official test suite
- I'll report improvements on a daily basis
- as of yesterday afternoon, we had 55 files and 638 passing tests
- that's an improvement of 344 over the passing week
- Jerry and Moritz deserve special compliments for the work they've done on the tests and the suite
- much easier to work with now
- much easier to find low-hanging fruit
- optimistic about our progress over the next few weeks
- Jonathan is doing a lot of work on classes and types and subsets
- you can declare subset types and have them work
- a variety of improvements are on the way there too
- things are coming together a little faster than I expected
- like Jerry said, one day this week, I spent a few hours applying patches
- that's a good problem to have
- would be nice to read over it for sanity then have someone else test to see that it doesn't break things and perhaps apply it
- not always easy for me to do without colliding with what I'm doing currently
Larry:
- did a little bit of spec work
- trying to remain responsive
- due to a confluence of very many factors, I've been running as hard as I can to stay in one spot
Allison:
- closing out a few last bugs in the concurrency branch
- adding a few new features
- PGE uses
bsr and branch heavily
- they don't play well with continuations
- added a new feature for continuation-safe branching
- about to submit the paperwork for the new foundation this week or next
c:
- fixing bugs, closing tickets
- mostly adding polish
- did some work on optimizing string usage; will have more benefits there shortly
- watching over Andrew and his GC work
- he's on the right track, hasn't needed much guidance
- otherwise preparing for YAPC
Jesse:
- not much to report
- just work
- what do you need?
c:
- maybe encouraging people on #parrot to apply patches and test them locally and report their results would help out
Jesse:
- maybe doing that as an example would help?
Patrick:
- we're going to require all patches to go through RT first
- that gives us a little process
Jesse:
- how many patches need massaging?
Patrick:
- some 80% apply and work, but make incorrect assumptions
- I can apply it and say we'll fix the assumptions later
- or I can respond and give guidance to resubmit the patch
- or I can make the minor changes and fix them as I apply it
- pretty rare to get a 100% patch
- but I don't want to become the bottleneck
Jesse:
- what's the time-consuming part of the apply and test cycle?
Patrick:
- I'm trying to avoid something
- someone comes out with a patch that solves a test case
- they submit it somehow
- you want to give them instant gratification
- if I'm in the middle of working on a feature myself
- and many that I work on aren't small
- I need a separate checkout to apply and test and commit
- that takes a few minutes, maybe ten
- then I have to pick up where I was, merging their changes into mine
- the low-hanging fruit is all in the same files
Jesse:
- it doesn't sound like tooling is the important thing to fix here
Jerry:
Patrick:
- a lot of it will fix itself in a short period of time
- part of the problem is that I was absent from code review for a couple of months
- I'm glad we made progress during that point
- but now it's the time to refactor away some of the assumptions there
- it may not be as big a deal if I get caught up soon
- that will happen sooner if I don't have to deal with the other things
c:
- about 80% of the patches I see for Parrot in general are high quality
- not a lot adding new features, which may affect that
- but the quality is good, and I'm pleased
