The Perl 6 design team met by phone on 11 June 2008. Larry, Allison,
Patrick, Jerry, Jesse, Nicholas, and chromatic attended.
Larry:
- slowly improving
- seems like I'm getting smarter, but appearances can be deceiving
- my brain's not really back to a lot of spec work yet
- continuing to refactor and debug the gimme5/STD5/cursor5 galaxy of pain
- making progress on that
- parses all of radix.t, though I'm not sure it's doing that correctly
- starting to make progress on parsing STD.pm itself, though it's not getting far
- hope to be able to parse most of STD.pm using STD.pm by my talk next week
- my future plans are to switch over from using lists (which cannot easily be lazy in Perl 5) to using lazy scalar iterators
- that'll probably make the produced Perl code look a little prettier too
- unless your idea of prettiness is a lot of nested
map
statements - going to Chicago on Friday
- giving a talk a week from tomorrow at Google in Chicago
Patrick:
- things are going very well
- Rakudo and PCT now support the
return
statement - hooks for the other types of exceptions implemented
- have a version of
fail
implemented, but it fails in certain cases - want to clean that up
Larry:
Patrick:
- it fails badly
- mostly need to find where we did things the Parrot way and layer the Perl 6 way on there instead
- fixing little bugs here and there to get more spectests running
- wrote my own small version of Test::Harness to get the output results in a format that makes it easy for us to chart our progress
- this one tells us how many we passed
- running a test right now to find out where we were this morning
- essentially, we're passing around 700 spec tests this week
- last week we were passing 624
- we may be quite a bit more than 700
- all of this will show up in a journal post in the next day or two
- writing code distracts me from journal posts, or vice versa
- no other distractions
- looking forward to YAPC and the hackathon
- putting together a list of things to work on at the hackathon
- one big thing is how people can help us with the spectests
- doing more thinking about how to update PGE to do protoregexes and longest token matching
- seems doable this summer
- maybe between YAPC and OSCON
- tomorrow is Jonathan's Rakudo day
- we'll do lazy lists in Parrot
Jerry:
- applied a few patches
- answered some questions
- we set up the Parrot Foundation, a new non-profit for supporting Parrot in specific
- assigned directors, incorporated, set up a bank account, will announce at YAPC and OSCON
- involved in the logistics of setting that up and so on
- finalized the purchase of parrot.org
- we'll put up a site there as soon as the domain transfer happens
Jesse:
- what are you transferring over?
Jerry:
- the Parrot milestone funds
Jesse:
- are you getting your own infrastructure for this, or will it run on perl.org?
Jerry:
- need to talk to TPF about that
- just met with Auzon about the Perl 6 tests
- have some questions for discussion
- Kevin Tew's back on track with his project as well
- fighting some PGE brainos
- #parrot helped him move on
- he can parse a 6000 line C++ header file in a minute and a half
c:
- fixing some bugs
- still working on the string system
- made some improvements there
- cleaned up some grotty code, more to go
- might look at the string PDD after the hackathon
- continue to mentor Andrew's GC work; he's on the right track and I have high confidence in him
- helped Kevin profile his code
- found some spots in PGE that could use optimization
- Patrick could put in a couple of hours and get some improvements for everyone
Patrick:
- I spent a couple of hours on that this morning
- too much backtracking
- found some other stuff I want to clean up in the process
- we'll get more speed from longest-token matching though
c:
- and a better garbage collector, Parrot-side
- but a 20% improvement now is a good thing
Patrick:
- also for people who aren't using protoregexes and such
Larry:
- the
xor
problem is between whether you treat them as binaries or list precedence - do you think treating them as lists makes optimization more effective?
- it's not the only thing in that precedence level
- if we treated them all as list precedence, does that open up more general optimization improvements?
- I'm getting the feeling that the answer is yes
Patrick:
- PGE's issue is implementation
- with eleven alternations, it stored ten backtracking points
Larry:
- it's simpler to implement short-circuit logicals as binaries
- implementing them as a list operator might not buy you anything
- but they degrade to left-associative anyway, if the operator changes
- I could change all of those left-associative ops to list-associative with no change in the binary case
- I'm going back and forth on that for
infix:xor
- should they have the useless semantics of parity?
- it's a tradeoff
Patrick:
- if they were listops, I don't think we'd get that big an improvement
- it wouldn't bother me if it were there
- it's not hard to implement them that way
Larry:
- the listop could implement them in terms as binary, if it wanted
- that's fine
Patrick:
- having the
one
sense would have been really handy
Larry:
- you have an explicit
one
now, but that's just junctions
Patrick:
- and it doesn't short-circuit
Larry:
- if you have one that's true, tell me which one
- that's probably more useful
Patrick:
Nicholas:
- would be nice to restart the Perl 6 list summaries
- the Perl 5 summaries have produced some productive work
- David Landgren spends about a full day of work on the summaries every week
- the Perl 6 lists have a bit more traffic combined than p5p
Jesse:
- we've had trouble finding anyone interested in doing the summaries last time
Nicholas:
- there's also the huge problem of trying to summarize IRC
- David's reaction was "ugh"
Patrick:
- I'll try this and report it in the next two weeks
- I haven't been reporting on my progress as frequently as I'd like
- weekly might be better, especially given our velocity
- I prefer that someone else does the summaries
- getting more people to participate is more important
- and it's easier for someone involved to summarize than someone who isn't
- I'll look for some interested people at YAPC
- if that doesn't happen, I'll set aside a day a week to write a summary report
Jesse:
- I'd happily pay in beer or whatever for that
Jerry:
- conference season is a great time to find someone
Patrick:
- if we don't, I'll make that one of my deliverables for my next grant, if I get one
- one question from the SoC meeting before this
- how do we handle design questions?
- I feel badly dumping these on Larry, but I don't know where else to go for resolution of these things
- what should my approach be?
Larry:
- I treat p6l as a queue of things I ought to have thought about
Patrick:
- I'll start posting to p6l then
- I was thinking of p6c, but if p6l works better, I'll use that
Larry:
- p6c tends to read to me like a lot of implementation things my eyes glaze over
Patrick:
- we'll use p6l from now on
Larry:
- you get a little more noise from the theory folks at times
Patrick:
- if things still get Warnocked, I'll bring it up again
Larry:
- that's one reason we have a weekly phone call
Jesse:
- speaking of that, no phone call next week while everyone's at YAPC