use Perl

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:

• it fails to fail?

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:

• I could do parity easily

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

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:

• it's the process

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

The Perl 6 design team met by phone on 28 May 2008. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

• mostly off for this long weekend elsewhere
• continuing to work on quoting roles
• they need generic support to mix in roles with parameterized strings as starter and stopper sequences
• that's an interesting problem, when mapped into Perl 5
• no support for generic roles or parameterized types yet
• I'll probably just do an eval

Allison:

• reworked continuations in Parrot, based on our discussion last week
• I have very high regard for the value of reading through the commit logs
• found the source of the problem that way
• someone committed the problem about a year and a half ago
• now continuations work the way they should work
• we now don't try to make CPS respect the dynamic environment stack
• it's largely unused now that we don't store exceptions there anymore
• tracking down one last bug
• I can duplicate it
• it's an exception thrown, caught, and resumed from an :onload subroutine
• looks like they get executed differently from regular execution
• first draft of the Bylaws and Articles of Incorporation for the Parrot Foundation
• hired a lawyer in Washington state for incorporation there

Patrick:

• added quite a few things in the Rakudo implementation
• added a new metamodel that looks like the Perl 6 metamodel
• with Jonathan's and Jerry's and Moritz's help, we converted the compiler tools to that model
• cleaned up some of the inheritance hierarchy in Rakudo
• builtin types report correct methods and types
• a Parrot Integer reports itself as an Int in Rakudo, down to the metaobject information
• fixed pair handling, especially for calling functions
• people are testing those in great detail now
• now it's obvious that Rakudo's and Parrot's and Perl 6's argument handling there somewhat disagree
• doing some PGE refactoring
• primarily fixing up its class hierarchy; looks pretty easy
• may move Rakudo's grammar to use protoregexes
• might help get the metaoperators working -- French brackets, for example
• if we don't get this soon, people might submit patches doing things the wrong way (multiplying new operators for various combinations)

Jerry:

• Google Summer of Code started this week
• the aggregated feed of Perl GSoC 2008 student and mentor blogs is available
• the students will report weekly status at the #parrotsketch meeting
• the students and mentors will report at #perl6-soc on irc.freenode.net on Wednesdays at 18:30 UTC
• all of the students seem to be on track now
• made some spectest changes
• made some changes to rakudo List methods, applied some patches
• made some Rakudo test changes, should make test management easier and allowing us to create private and shared lists of tests we want to run
• should make it simple for rakudo developers to specify a subset of test files, making focused development and focused testing easier

c:

• not a lot of energy for hacking for some reason
• applied a few patches
• cleaned up a few tickets
• talked with Andrew quite a bit yesterday about GC plans
• he has some good ideas, including a clever marking scheme for which I have high hopes
• mostly on the right track
• will write up some guidelines on profiling and optimizing
• have one idea to optimize keyed object attribute access
• otherwise really need to work on the PIR profiler

Richard:

• trying to plan a legitimate way to ascertain Perl 6 grants, given the donation from Ian Hague
• planning a process around that
• thinking about YAPC::NA and a grant process BOF

Allison:

• Patrick mentioned argument passing in his report
• we don't quite understand how it needs to work in Perl 6
• Parrot will support whatever Perl 6 needs, though it may not necessarily be the default
• one goal of argument passing is to make it lazy
• you don't have to parse the whole list to start pulling out parameters
• required parameter positionals are clear
• required positional parameters are clear
• you can pass in a required positional parameter as either a positional or named argument
• Parrot maps the positional arguments to positional parameters
• when it runs out of positional arguments, it starts checking named arguments

Patrick:

• that's not really what Parrot does
• Parrot fills positional parameters with positional arguments
• then it fills in named parameters with positional arguments

Larry:

• what do you mean when you say "named parameter"?

Allison:

• pairs

Patrick:

• all parameters are named in Perl 6
• they can be filled by a named argument
• Parrot has parameters that you can fill only by position
• then there are parameters that you can fill by position or name
• but Parrot fills them opposite from how Perl 6 would expect; it chooses the positional argument over the named one.

Allison:

• I thought you needed a way to skip over a named parameter in a list
• and then fill in its value from the named argument list
• or scan the entire named argument list first, and then fill in positional parameters
• it sounds like this is different

Larry:

• the compiler should recognize arguments intended as named parameters
• it can set up a data structure for efficient access
• the other constraint is that any argument can depend on the value of a previous argument in the list
• you have to bind them in the order of declaration
• you go down the list
• for each of them, you look up in the named argument list
• to see if it's bound by a name
• if not, you take the next one from the positional list

Patrick:

• that can be lazy

Larry:

• yes
• that's the abstract view from the Perl 6 end
• one reason we invented prototypes is so that the compiler can know that the first n arguments are positional
• map any named arguments into positional without having to do the lookup
• that's primarily a sop to efficiency
• for a very small number of named arguments, brute force is probably faster

Allison:

• do you never have any parameters which are strictly only positional?

Larry:

• there's no way to write that
• other than writing a bare sigil in the declaration
• you're not giving it a name
• but you can't access it, because it needs a name

Allison:

• sounds like we want three different flags in Parrot
• one for a purely-positional argument

Larry:

• the optimizer might use that, if it sees a prototype

Allison:

• we keep the :named flag
• for named parameters

Patrick:

• named-only

Allison:

• we don't really have that
• we have named that acts like positional

Patrick:

• we have named that prefers positional, and then throws an exception if a matching named argument is also supplied

Allison:

• might have four flags then
• one that's either named or positional
• maybe one that gives priority to the positional
• not sure that's useful

Patrick:

• I couldn't come up with a case where that's useful

Larry:

• some languages want that

Patrick:

• you can almost simulate that with slurpies in your code
• or sticking in dummy arguments

Allison:

• could come in useful if you have optional parameters
• you don't have to pass anything at all

Patrick:

• I proposed what you described as numbers 1, 2, and 4
• the existing :named flag is named-only
• the :positional flag is a named parameter that accepts positional arguments

Allison:

• I'm trying to get down the ideas
• I probably wouldn't use :positional for that
• important to get the categories right

Patrick:

• I couldn't figure out a case where you have a named parameter that prefers the positional over the name

Allison:

• make it a positional and don't worry about it
• if you make it positional, you don't have to scan the argument list

c:

• look at Python's default parameter handling
• I think it may follow the one case you couldn't figure out
• not entirely sure

Patrick:

• is the answer that Parrot's underlying model will likely change to support what Perl 6 needs?

Allison:

• yes
• exact details yet to be determined
• as soon as possible so that you can use it

Patrick:

• it's been the subject of at least five or six RT tickets in the Rakudo queue
• they look like different problems, but they call come down to the same problem
• it's becoming a pain point
• I'm willing to implement it
• there are probably three or four related tickets in the Parrot queue

Larry:

• there was a question about writing Pairs various ways as arguments
• are they intended to be named arguments or pairs?
• how do you write the prototype for list, by the way?

Patrick:

• I suggested putting colons in front of it

Larry:

• but :a is always a valid term

Patrick:

• you can always look ahead for a fat arrow

Larry:

• I'd almost rather write :> for that
• originally we always used the fat arrow
• then we put in the colons
• we wanted to use the fat arrow for arguments
• people seem to be used to the colon for named arguments, not the fat arrow
• maybe we should just bite the bullet
• you need the name as the identifier
• you don't need the general pair form
• the fat arrow makes a Pair not intended for a named argument, unless you do processing on it
• that'd be a simplification
• you can tell by just looking at it
• one is a named argument
• the other is just a positional parameter

Jerry:

• is there a method on a Pair that allows it to be passed as a named parameter?

Patrick:

• prefix vertical bar?
• S06 has options for making a Pair a named argument
• or a hash as a list of named arguments

Larry:

• we're trying to guess it based on the context of the argument list
• if you pass the list to a function call, it assumes you want named arguments
• otherwise you don't
• that might be guessing too far
• the list function might want to parse more like parens
• but it behaves like a function
• you don't want to pass those as named arguments
• how do you tell the compiler that it's special
• maybe you want to make it a macro, but that's kind of weird
• maybe it's time to look at the cultural issue of how people want to write named arguments
• maybe we can simplify that

Patrick:

• there's a similar issue with the hash constructor
• you can kinda get away with it, because order is less important
• but it still exists
• it'd be interesting to look at the existing tests and Synopses to see the results
• there is some historical baggage toward using the fat arrow

Larry:

• the guy who wrote that Synopsis was familiar with Ada's fat arrow for named arguments

c:

• is there some sort of prototype declarator that says "It was an ordered list in the source code, and that's what I want!"

Larry:

• macros are a lot like prototypes

Patrick:

• Rakudo for now will treat them as special in the way that Pugs does
• it'll treat list as a macro
• do something special, it's not a normal argument list

The Perl 6 design team met by phone on 21 May 2008. Larry, Allison, Patrick, Jerry, Will, and chromatic attended.

Allison:

• working on the exceptions migration
• finished the last half of that
• debugging failing tests now
• I have eight failing tests
• narrowed it down to three basic problems
• had a question for Patrick on that
• continuations taken on labels in the middle of a subroutine make very poor exception handlers
• independent subroutines work much better
• the problem is that setjmp/longjmp isn't stable or guaranteed to be stable in the spec

c:

• that only surprises me if you're using a bad platform with an awful compiler

Allison:

• longjmp isn't guaranteed to restore all of your variables properly
• we're seeing memory corruption when we restore
• we're ready for language testing on that branch
• the places where this is a problem is throwing exceptions from C
• throwing exceptions from within PIR is fine
• it just inserts an exception handler as the next op in the runloop

c:

• released Parrot 0.6.2 yesterday; seems fine so far
• improved performance in Parrot yet again
• ran out of time over the weekend to work on concurrency
• will apply open patches and check for bugs this weekend
• scheduled my trip to YAPC::NA, will be at the Parrot hackathon both days but not the post-conference hackathon

Jerry:

• did some work on mod_parrot on a branch
• rewriting the configure system to improve portability
• some good progress there
• added a couple of Perl 6 spec tests
• modified a few to make them pass on Rakudo
• talked to Moritz about a make target for just passing spectests
• it's make spectest_regression
• should get you noiseless, all-passing spec tests
• they run through fudge for now, but eventually we'll take that out
• trying to get back into Perl 6 development, but I can't keep up with Jonathan and Patrick

Patrick:

• now you know how I felt!

Jerry:

• I'll stick with the tests
• GSoC starts in earnest within a couple of weeks anyway
• want to make sure that all of the students have what they need

Larry:

• took a side trip to Japan
• gave my talk there on the current state of the parser
• why and how we're making it extensible
• continue to work on the parser to make language derivation more real
• revamped the quoting to use real sublanguages and get all the mixins to work right
• I Moose-ified the STD5 implementation
• now does mixins correctly
• now parsed double-quotes for escape sequences and properly returns a Match object
• now working on regexes as a sublanguage
• thinking how terminators match
• the old recursive-descent parsing was kind of brittle
• switched it to use the operator precedence parser
• figured out that I could reuse the same one by supplying different term and infix expectations in the subgrammar
• that effectively hides the parts of the regular grammar that you don't want to see
• you don't have normal regular expressions popping out where you don't want them
• there's no reason not to use the regular operator precedence table for that
• don't have to worry about propagating terminators down so that they stop on double vertical bars

Patrick:

• PGE does the same thing

Larry:

• it looks cleaner
• but it's untested
• if the operator precedence parser works on regular Perl, it'll work on the real thing
• the benefits of longest-token matching still work too
• there are occasions where I don't want to derive a sublanguage just for a different quote terminator
• playing with a single hard-wired stop pattern passed in from the dynamic scope
• may need a start pattern so I can have nested brackets
• should suffice for quoting needs without multiplying grammars for every different delimiter
• instead of the preprocessor rewriting protoregexes, the standard grammar looks at protoregex data and rewrites it on the fly

Patrick:

• had end of semester grading and stuff
• that distraction is gone
• created a new metaobject model on top of Parrot
• makes Parrot objects act like Perl 6 objects — .HOW and .WHAT methods
• follow Perl semantics, not necessarily derived from a common base
• gives a nice consistency to the toolset
• PCT and PGE use that model now
• that went quick
• Jonathan and I are converting Rakudo to that model now
• finding other updates in the process
• seems to be going well
• closing tickets, applying patches, answering questions
• figured out an approach to solving scalars in Rakudo
• will help with list assignment and list context
• a new PMC type for the base class of mutables
• we can attach properties to that
• figured out how to clean up class relationships in PGE
• need to refactor PGE
• that helped me figure out how to implement protoregexes
• that'll help us implement more of the standard grammar
• not a complete longest token matching implementation
• but it'll get us closer
• need to refactor the operator precedence parser slightly
• needs more introspection to make scalar assignment propagate context appropriately
• not a minor refactor; PGE uses operator precedence parser to parse things
• a fair amount of changes to PGE over the next couple of weeks
• I don't expect any external impacts
• our abstraction levels seem good to mitigate that
• it's easy to change the world underneath without having to change things externally
• no blockers at the moment, other than sleep

Will:

• keeping an eye on the queue
• trying to stay active on IRC
• trying to get some people fill out CLAs and get commit bits
• want to make sure we keep good patch submitters happy
• some grant committee work this week, nothing particularly Perl 6-y
• blocking on time

Allison:

• how much do you depend on exception handlers being set as continuations within a subroutine?
• how much would it hurt if they were separate subroutines?

Will:

• I'd have to update a lot of code in Tcl
• that wouldn't kill me

Patrick:

• I like the way it works now
• there could be reasons why that's not fully desirable
• but it's really nice to have all of my registers in scope with labels as it is now

Allison:

• at the moment, exceptions thrown within C require setjmp/longjmp to get to where we can insert a new opcode within Parrot's runloop
• that's fragile
• most exception problems now come from that
• this is the same problem as the continuation from different runloops problem
• longjmp doesn't know anything about the Parrot environment and doesn't restore it
• that's the corruption problem
• maybe the problem is how we handle Continuations

c:

• I think the problem is with how we handle Continuations

Patrick:

• there aren't many places where I do exception handling
• there may be a lot of handlers, but they're mostly in generated code
• not hand-written code
• might not need to update many places if exception handler as label goes away
• then the question is "How do I get to the context I had where the exception occurred?"

Allison:

• from my perspective, an exception handler is basically a block in the HLL
• the same way you'd use :outer with a block
• the outer is the enclosing sub in the HLL

Patrick:

• that's basically lexicals then
• anything I want to preserve into the exception handler, I have to stick into a lexical

Allison:

• yes
• or rely on the information you insert into the exception itself
• it can carry a payload

Patrick:

• but we're talking about exceptions I didn't write
• thrown from C
• I can't put stuff into the payload there

Allison:

• what information do you want?
• PIR information?

Patrick:

• and stuff in registers
• if I create a class, there could be a "Class already exists!" exception
• I branch around it
• if there's an error, handle it elsewhere in the subroutine, then continue on

Jerry:

• it's half-standard, when you write PIR
• half of the ops return NULL
• half of them throw exceptions

Allison:

• is that an idiom because Parrot's exception handling doesn't work?
• resume hasn't ever really worked so far
• if that worked, would that help?

c:

• that would solve some of them for me

Patrick:

• it would for me too
• but sometimes I want to do other things, and then resume
• I'd need to store stuff in lexicals to have access to them

Allison:

• the classic model is where you catch an exception, change a value, and then resume
• that's tricky to do with separate execution for handlers

Patrick:

• about half of my stuff is that
• mostly default handling
• testing to avoid the exception in the first place is a lot more work than trapping and fixing

Allison:

• and that makes exceptions less useful, as you want to take the hit only when an exceptional condition occurs

c:

• and there are race conditions

Patrick:

• exception handlers as labels are useful, because you can call out to an external sub if you want

Allison:

• we'll have to do some work on Continuations to call them from within C without breaking things horribly

Patrick:

• before you go too far in looking at that, let me review where I use exceptions and how I use them to see what needs to change

Allison:

• the confusion is between the HLL and C
• they don't agree on how control flows

Larry:

• C is wrong
• the minute you put C and C in there, you're wrong

Allison:

• that's what I thought when I saw them
• I'll try to keep the ability to allow exception handlers at labels

Patrick:

• I'll look at how I handle C from a PCT perspective

Larry:

• C in Perl 6 allows you to go to the original scope from the exception handler
• the stack doesn't unwind until you tell it to
• it's not impossible... if you can find the right label to go to
• the C itself unwinds the stack

Patrick:

• what happens when you do C now?
• in trunk

Allison:

• it pushes a Continuation object onto the general stack

Patrick:

• when the exception occurs?

Allison:

• it pops it off the stack and invokes it
• when you C, you push the exception back on the stack

Patrick:

• anything that happens after you took that Continuation is still in effect when you get to that label

Allison:

• invoking a Continuation doesn't restore your entire environment
• only certain pieces of the context

Patrick:

• it doesn't change register values back

Allison:

• it's not pure
• in the sense of no side effects

Patrick:

• how does the new one work?

Allison:

• it doesn't use the general stack at all
• C adds a handler to the concurrency scheduler
• like event handlers
• when you invoke an exception, it searches through the concurrency scheduler's list of handlers
• invocation hasn't changed at all
• you'd store your exception information in the interpreter
• then pull that into an Exception PMC
• then throw that object
• we've removed that interpreter structure part
• superfluous
• Continuation invocation hasn't changed at all

Patrick:

• return exception returns a payload

Allison:

• you control that

Patrick:

• how about C and C?

Allison:

• are they all subs?

Patrick:

• PCT doesn't presume that the body of a C or C loop is a sub
• not all languages require that

Allison:

• I removed the idea of handler scope
• the old implementation wasn't very good
• my new idea is to store them in the context structure
• they only exist in your own context
• you attach those handlers to a block
• if you throw an exception within that block, the handler for that block catches it
• when you leave a context, the handler is no longer active

Patrick:

• that doesn't handle C
• have to stay in the loop
• it skips the rest of the block
• starts at the top again
• C exits the block

Allison:

• it hands control back to whatever controls the iteration?

Patrick:

• I need the C and C opcodes to work properly

Allison:

• the block catches it
• the handler says "resume after everything else"
• the ordinary control flow continues on the next iteration

Patrick:

• I need to think about it some more
• I could really use a way to push a new level into a lexpad
• some optimizations there

Will:

• Tcl has a C
• I'm not sure how it works under the hood
• it lets you do things with control flow

c:

• Lisp does too (CL?)
• let's take this to the list
• Bob Rogers has lots of practical experience doing this in Lisp
• good to get more feedback

The Perl 6 design team met by phone on 14 May 2008. Allison, Richard, Patrick, Jerry, Will, Nicholas, and chromatic attended.

Allison:

• working on the exceptions implementation for the concurrency branch
• also the Parrot foundation

Richard:

• trying to drum up funding for the Perl 6 paupers
• something's happened along these lines
• an anonymous member of the Perl community brokered a deal with a philanthropic business acquaintance
• I put together a pitch describing what we could do productively with a donation
• the money arrived yesterday
• half of it will go toward supporting Perl 6 development in a variety of ways
• mostly direct developer granting, like Patrick's grant
• the other half is for TPF use to improve organizational capabilities internally
• there's a lot more potential for funding
• orders of magnitude more
• that'll take us over the finish line
• though TPF is not a paragon of activity and organization
• we'll use it to improve to make us more credible to the rest of the world
• and potentially more developers
• want to go from a handful of grants like this to something larger
• I'll spend the next week or so making plans
• we'd like to start getting some of that out over the next few weeks

Patrick:

• outstanding work
• you'll go down in history for this

Jerry:

• will they money go out through the grant committee?

Richard:

• I don't think so
• this will be as directed by the board

Jerry:

• is there a PR plan for spreading this news?

Richard:

• I hadn't thought of that
• I'd like ideas for helping with that

Jerry:

• it's easy to post to web sites
• it might be good to give brian d foy a heads up for TPJ, too

Richard:

• I'm trying to do similar things for Perl 5
• this particular donor had a specific interest in Perl 6
• the half of this we're using to improve TPF will help Perl 5 as well

Nicholas:

• I hope the positive feedback will encourage other people to do the same for Perl 5
• presumably they're already using it and want to contribute back

Patrick:

• busy week here
• focusing specifically on Rakudo
• helping other people hack themselves
• added fat-arrow parsing, so now that works for passing named parameters
• added signature default values
• no more crazy MMD stuff to get that working
• worked on the test suite
• started at the beginning, Synopsis 2 cleanup
• making notes for others on things to do and not to do
• tried to close out old tickets, did about 18 Parrot-only tickets
• some updates to PGE to bring in S05 changes
• Tene added placeholder parameters to Rakudo
• surprised and pleased me to see that
• he found a problem with hashes versus arrays in PCT
• I did quite a bit of work to improve PCT code generation
• substantial improvements there
• generates much nicer code

c:

• there are some speed improvements there
• they're hard to measure, but they're there

Patrick:

• we're creating many fewer elements there
• especially in places like loops

c:

• we don't have many long-running benchmarks that would demonstrate that
• if we did, you'd really notice it

Patrick:

• it's been in the back of my mind since I started writing PCT
• it makes for nicer looking PIR code, if you like PIR code
• now I'm writing some journal posts to describe this to the wider community
• I don't know if anyone saw it, but there was a Twitter post that singled out TPF for its organization for Google's Summer of Code
• Jerry should get some credit for that for Parrot

Richard:

• I've talked to Eric Wilhelm a lot over the past few weeks
• he's doing a great job
• this has been his full-time job over the past few weeks
• that's why we're not always this organized
• very seldom do we have someone who can make such a thing a full-time job
• simple matters of organization often aren't

Jerry:

• worked with Allison on research for the Parrot Foundation
• she interviewed a lawyer to help set up the incorporation
• work has been lighter this week
• spent more time on Parrot and Perl 6
• haven't had any significant commits
• began to rewrite mod_parrot's configure system for flexibility and portability
• hope to get it compiling on Windows
• shouldn't be difficult
• Patrick and I discussed making HLL type mappings available in IMCC

Patrick:

• PIR doesn't seem to have a way of finding HLL type maps
• PCT needs to move something from a register into a PMC
• equivalent types, as far as the HLL is concerned
• there doesn't appear to be a way to do that
• without the HLL person repeating the mappings in PIR
• violates DRY

Jerry:

• I think I see a way of implementing that
• the major problem is that, internally, the PMC types are still type IDs
• not string names
• I might have a short-term fix
• the long term is to get rid of type IDs internally
• it's easy enough to expose that through interp_info.pasm or something

c:

• let me know if you need help

Patrick:

• also remember that class names are not always strings
• they are now, but the won't always be

Will:

• I'll try to unstick the type ID removal branch later this week
• mostly I've been doing queue management, which is not exciting

Patrick:

• I'm excited about seeing the number go down

Will:

• we've closed an enormous number of tickets in the last week
• yet more tickets keep coming in
• what's wrong with these users?

c:

• spent some time closing bugs and applying patches
• need to go through open patches and make sure they're all closed
• probably won't make much of the Bug Day
• backported yada yada yada operators to Perl 5, waiting for someone to apply them
• managed to speed up the Rakudo-building benchmark by about 40% yesterday
• hope to get onto the concurrency implementation soon

Nicholas:

• talked to Daniel Ruoso and stuck his response on the wiki
• otherwise busy with a potential move

Patrick:

• Jerry, are you still planning to reimplement abc to use the language shell tool?

Jerry:

• yes
• I plan to update the tool to include an operator precedence parser
• not sure if I should couple those changes

Patrick:

• I'm thinking of updating the tutorial
• kjs's tutorial is great
• I just want another one
• I don't want to step on your toes

Jerry:

• I plan to make my changes
• then apply the revised tool to abc
• I'll turn my attention to that next

Patrick:

• we should knock that out pretty quickly

Jerry:

• what's your plan for this release?

Nicholas:

• are you in a position to type things from this release to last release?
• or should I ask Patrick?
• you've sped up a lot of things

Patrick:

• Rakudo gets bigger over time
• there's quite a bit more code there than there was last month

c:

• there are a couple of ways to do that
• we could plot the ratio of time per feature over the release numbers
• that's not too difficult
• otherwise, we could take the current PGE/PCT/NQP/Rakudo and run it on this month's release versus last month's release
• or run last month's toolkit on this month's Parrot

Patrick:

• I can do that
• already thinking of ways to do that

Nicholas:

• Damian was talking about negative time last year
• you guys are doing it!

c:

• the big improvement is likely in the new garbage collector

Jerry:

• Andrew and Patrick should have a race

Patrick:

• longest token matching will help languages
• that's on my agenda for later in the summer though

c:

• remember that these are only Parrot-level improvements
• we haven't even started on PIR-level improvements
• because we can't profile it easily yet
• I suspect there are plenty of trivial 10 - 20% optimizations we'll find in hotspots there

They were walking to the Hemlock, the Rooster and the Mice, and the Mice kept looking at one another, questioning.

"We don't know what the future holds, do we?" said Chauntecleer. The Mice all shook their heads. They knew very little of anything. "If," said Chauntecleer, "I say, if I don't come back again, then you must make this food to last a long, long time. I trust your prudence, don't I?" he asked, and they nodded automatically, but their eyes were very big. "And I trust your integrity, right?" They nodded. "And you are mature, now, and I respect your maturity, isn't that so?" Poor Mice, they nodded and nodded, and they blinked, and they nodded. They looked afraid. "Good," said Chauntecleer. "I know I won't be disappointed.

In this way he gave each Mouse a manhood. They couldn't talk to him just now, having so much to turn over in their minds. But neither did they cry.

— The Book of Sorrows, by Walter Wangerin Jr.

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2 "Reverse Sublimation." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 0.6.2 is available via CPAN (soon), or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on our source code repository to get the latest and best Parrot code.

Parrot 0.6.2 News:

• Specification
  • updated and launched pdd28_strings.pod
  • updated pdd19_pir.pod
• Implementation
  • added implementation of Rational PMC
  • simplified ops control flow syntax
  • enabled backtrace on non-glibc platforms too
  • improved some PIR error reporting
  • removed user stack opcodes (save, restore, lookback, entrytype, depth, rotate_up) (NOTE: This was scheduled to occur after 0.7.0, moved up to this release)
  • removed register stack, saveall, and restoreall opcodes
  • removed various deprecated features and unused code
• Languages
  • Amber: retired
  • C99: grammar updated
  • Cardinal: resurrected, method calls and do blocks work now
  • Eclectus: use NQP as PAST generating code
  • Lua:
    • added big number library
    • updated to match PGE changes
    • added a bytecode disassembler & a Lua 5.1 VM bytecode translator
  • Pheme: updated to match PGE/PCT changes
  • Plumhead:
    • use NQP as PAST generating code
    • use riaxpander for macro expansion
  • Rakudo:
    • updated ROADMAP
    • conditional and loop statement modifiers
    • lots of class, object, role, and method improvements
    • Str increment and decrement
    • improved spectest reporting
    • type checking on assignment
    • regexes and grammars
    • undef and self
    • placeholder vars
  • Squaak: added to repository
  • TAP: retired
• Compilers
  • PGE: updated to match Synopsis 5, deprecated features removed
  • PCT:
    • improve handling of register types, conversion between registers
    • improved error diagnostics
    • add 'arity' to for loops
• Configuration
  • added step auto::opengl
  • added step gen::opengl
  • added step gen::call_list
• Miscellaneous
  • still more optimizations and performance improvements, especially in GC
  • new libraries: OpenGL/GLU/GLUT bindings (small subset working)
  • new dump_pbc.pl utility: PBC disassembly/source code weaver
  • improved C++ compiler support
  • optimized builds work again

Gracias to all our contributors for making this possible, and our sponsors for supporting this project.

Enjoy!

The Perl 6 design team met by phone on 07 May 2008. Larry, Allison, Patrick, Will, Jerry, Nicholas, Jesse, and chromatic attended.

Allison:

• spent my time this week slicing and dicing the exceptions implementation
• replaced the old internals with the new system
• checked that in yesterday
• still a few failing tests in edge cases on the branch
• did more work on the Parrot Foundation

c:

• I own an acre of Mars, we could incorporate there

Allison:

• don't you own a cow in the Philippines?

c:

• yes, but that doesn't give me any governmental powers

Patrick:

• isn't that worth a lot?

c:

• the peso is improving against the dollar

Jesse:

• moving on...

Larry:

• clear bill of health from my medical reports
• hacking a lot against the standard grammar in my STD5 implementation
• lots of refactoring
• all of the various parameters that used to go through separately now go through as part of the Match object
• including the "fate" and whether we're peeking at the longest token set
• the longest token matcher works now
• I threw out my old mechanism for gathering Match objects
• it now creates the more-or-less correctly
• lots of grammar tweaks, as suggested by Mitchell Charity
• lots of refactoring of how logging works so that it doesn't always spew enormous quantities of information to the screen
• I can actually run the parser quite quickly now, for some definition of quickly that approximates 2000 characters per second
• matches symbols directly, rather than calling a rule, which is faster
• does the backoff now on longest token matching
• started refactoring the grammar on the assumption that I cna trust the longest token matcher
• no longer any nofat rule
• the longest token should match the fat arrow, if there is one
• started refactoring the quoting rules to parse as if they were sublanguages
• getting rid of extra rigamarole to recreate the other mechanism we already use for other languages
• working out the linkage for switching in and out of sublanguages
• how to get to the outer language from the inner language
• calling into pure Perl from closures in a regex
• or the host language if you're calling the regex from another language
• nailed down the available methods for Match objects in the specs
• giving a talk in Seattle on Friday at SPU
• flying to Japan on Saturday

Patrick:

• spent a lot of time teaching this past week
• cleared up now
• mostly I've answered questions on mailing lists and IRC
• I'm not always sure that I'm helpful, but I'm there
• yesterday I worked on trying to get a bunch of little small things here and there
• fixed up a few things in PCT internals
• today I'm bringing PGE up to date with some of the latest changes in S05
• these all help Rakudo and other languages in small ways
• trying to clean out my backlog and clean up a bunch of RT tickets
• I'll continue over the next couple of days
• and blogging about it as I go

Jerry:

• things are busy, mostly non-Parrot related stuff
• submitted a ticket that I hope Patrick can close today

Patrick:

• many languages depend on the old behavior, including Plumhead
• I'm not certain about some of them

Jerry:

• mostly otherwise answering questions on #parrot
• making sure that things are set up for the real work phase of GSoC
• making sure that students have their CLAs, if not commit bits
• astonished to see how much work Jonathan is getting done in just two funded days
• it's amazing to see how much a motivator money can be
• I'd like to see more of it, hint hint

c:

• working on closing as many open Parrot bugs as possible
• applying as many open patches as possible
• should be able to help on the concurrency branch soon
• otherwise preparing for the release
• going to check on received CLAs this week

Nicholas:

• found it curious that Perl 5.10 has the best state implementation of any language
• wanted to steal tests from another implementation
• had a discussion with Leon about SMOP
• there's no real description of how all of these implementations fit together
• Rakudo plus Parrot is a complete implementation
• SMOP and kp6 fit together nicely

Jesse:

• I started a wiki page on the Perl 6 wiki at Perl_6_Implementations

Patrick:

• I don't know that it says how things fit together

Jesse:

• I tried to encourage other people to contribute stuff
• didn't get much uptake

Nicholas:

• should we suggest to Daniel that he should help explain things?

Jesse:

• that's more likely to get people contributing to it

Will:

• there's definitely some confusion about it within the Grants Committee

Jerry:

• SMOP has the highest documentation-to-line-of-code ratio of any implementation

Patrick:

• it needs a good overview though

Nicholas:

• I'll ask Daniel to explain more
• especially its relationship to Parrot and Rakudo

Jerry:

• it sounds like it could be an alternate runcore for Perl 5 as well

Jesse:

• tried a few different things
• decided to write a test for Rakudo
• tried a simple arithmetic test pulled from Pugs
• found that Rakudo didn't implement a function specified in the S29 draft
• Patrick helped me write a couple of lines of code to implement it
• then discovered that fudge didn't support try blocks in a specific way
• Larry patched that
• then found that incrementing an undefined value didn't work in Rakudo
• that was the end of my day
• I still need to write up my findings
• how easy is it for someone without experience in Rakudo and its internals to pick things up and contribute something?
• more difficult than I thought it might be, but it's getting more doable
• it's important to understand how it might fail before trying to get people to do it
• then I started trying to play with MAD on the weekend
• found and fixed a bug in its XML
• refactored it such that you can run MAD's tests in the core if you add a copy of XML::Parser to the core
• it's not far enough yet, but it's a start

Nicholas:

• is it going to be difficult to restructure the Parrot foundation from 501(c)(3) to 501(c)(6)?

Allison:

• you can do pretty much the same thing
• sponsors are on the board in a c6
• they're only advisory in a c3
• the sponsors we've talked to are mostly only interested in getting regular status reports and the like

Jesse:

• is there any jumping around to transfer copyright to the new foundation?

Allison:

• we'll do a copyright assignment from the Perl Foundation to the Parrot Foundation
• all of the CLAs that went into the code up to the point of signover will be fine
• but we'll essentially copy the Perl Foundation CLA to a Parrot Foundation CLA

Will:

• do we need to contact committers who haven't signed a CLA?

Patrick:

• where does Rakudo fall?

Allison:

• still under the Perl Foundation
• it doesn't move at all

Will:

• do we want to split up the repository at that point?

Allison:

• eventually, we'll want to do so anyway
• it's not an urgent thing

Jerry:

• what would it take to version a Perl6Regex frontend to PGE?
• let grammars specify a version of the grammar

Patrick:

• I did that before by having a separate compiler
• you're talking about something a bit finer grained
• I don't want to do that
• as we get closer to 1.0, that'd be fine
• I already have enough to do keeping up with the latest versions

Will:

• I don't think we want to keep up old versions

Patrick:

• I don't mind sticking to our deprecation cycle
• I hadn't put the change from today into the deprecation list yet
• we'll get to it in a couple of weeks

Jerry:

• just trying to figure out how to push forward with changes to PGE without having to update every language in the repository

Patrick:

• freeze S05?
• not a great solution

Larry:

• I heard that

Patrick:

• the last few changes have been great
• I'm not really serious about that

Larry:

• some of them you even asked for

c:

• it's an advantage to have these languages in the repository
• we can update them
• but only if we can run the tests before and after and know that they pass

Will:

• we might consider removing languages with failing tests and no recent updates
• there are 17 grant proposals, some of them Perl 6-related
• please comment on the TPF blog
• it'll help

Jesse:

• blog.perlfoundation.org

The Perl 6 design team met by phone on 23 April 2008. Larry, Allison, Patrick, Jerry, Will, Jesse, Nicholas, and chromatic attended.

Jerry:

• we're in a period where everyone's trying to break Parrot
• they're adding new features and accidentally breaking thing
• but they're fixing it
• it's a good part of the cycle
• people fix it
• we don't have a build farm, so we can't test everywhere before committing to trunk

Patrick:

• I thought that was the point of the release cycle

Jerry:

• some people have suggested that we always keep trunk building and passing tests
• but we don't have the means to do that
• especially when we're playing with config
• moving on, the big news is that TPF has six slots in Google's Summer of Code
• one of them is fleshing out the Perl 6 test suite
• we've needed someone to spearhead that
• having a funded new contributor is wonderful
• two Parrot-related projects
• one is generating NCI stubs
• Kevin Tew, a long-time contributor
• the other is the incremental GC specified in the PDD
• that's Andrew Whitworth
• there's also an ASF project for integrating the GC from Apache Harmony into Parrot
• they've wanted to release it as a standalone library
• Parrot's the first test of a standalone system

Nicholas:

• nice that it doesn't count against TPF's slot list

Jesse:

• and it's nice visibility for Parrot from another group

Jerry:

• I finally have six weeks of no plans to travel
• should be able to devote more time to Parrot and Rakudo
• looking forward to that

Larry:

• getting some hacking in on my two pet bugaboos, the longest token matcher and match object generator
• I refactored the matcher
• it still uses TGE
• instead of lumping all of the expect term possible tokens (that is, all of them) into one bucket it separates them into buckets based on their first letter
• it's a one-level tree
• we can build a much smaller DFA for the regexes that start with that letter
• it caches that, of course
• can get an instant reject if the next token can't possibly start with that letter
• also flattened out all of the rules such that the list of tokens is easy to read
• if the first probe with the DFA engine fails, I can take that small set of tokens that start with the same letter, run all of those rules, and sort from longest to shortest
• preserves the token matching order without building huge DFA structures
• as a backoff strategy, that will scale pretty well
• refactored the parameter passing on the matcher side (STD 5)
• instead of passing an initial array of random things, I have parameters
• constructs match objects more correctly
• in the sense that it gets all the information it's supposed to have
• also has some attachments where it shouldn't have
• I'm cleaning that up
• that should scale pretty well

Jerry:

• is there a drop in memory usage?

Larry:

• I haven't measured
• I'm sure that not feeding 800 regexes to TRE at once will make it allocate 17 megabytes on the stack
• it might still be allocating too much for some of the larger things
• I'm still aiming for correct, as opposed to fast
• just trying to bear fast in mind
• the longest token matcher now returns a linked list of states
• not a string
• should be a lot faster; easier to cache
• functionally it's the same as before
• one of those things you don't even have to measure to know it'll be faster
• trying to avoid the bugaboo of premature optimization by doing what I know will be efficient to begin with
• all the while trying to make the thing work
• it has a good chance of being pretty speedy
• my talk in Tokyo will be about all of the places where the current grammar allows extensibility
• it'd be nice to be able to demonstrate some of that

Allison:

• getting work done again
• launched the Strings PDD
• list of tasks for concurrency that I'm breaking down into smaller pieces
• may post what I have now, and leave other people to break them down

Patrick:

• are they parallelizable? :)

Allison:

• many of them are
• there are some bigger things, like switching the exception system over to the event handler
• otherwise, just life stuff

Patrick:

• had paying work come up this past week, so not a lot of actual coding
• need to type the milestones document
• it's all in my head
• managed to remove a lot of unused code thanks to chromatic's post about possible optimizations
• mostly just cleanup
• but helped me figure out things which will feed into my redesign of PGE for longest token matching
• should be able to return to direct Rakduo hacking later this week

Will:

• various Parrot cleanups
• TPF quarterly grant proposals are due at the end of the month
• haven't seen anything come in yet

Allison:

• they're queued in an RT queue
• I don't know if grant members have access to that queue

Will:

• we do
• please, get your proposal in now, sooner than later
• that goes for you on the call as well as people reading the minutes

c:

• mostly spent the past week optimizing Parrot and Rakudo
• looks like it's the building speed is twice as fast as when I started
• runtime is faster too, but the optimization is compilation time
• found some infelicities that need more design thought
• but I'm happy to put these improvements in now and take them out later when the design improves around them
• hope to start adding new features again soon

Patrick:

• most of the test execution time is in compilation
• how useful would it be to compile Rakudo to standalone PIR?

c:

• I'd find it useful
• but I'd find about ten things useful with all I work on
• so not a blocker at the moment

Jesse:

• how far will that get you toward native executables?

Patrick:

• the existing trick for building perl6 would work
• but it's not the same

c:

• if it takes an hour or two, it would help me with debugging and profiling
• if it takes more time, it's not that important

Patrick:

• we have to figure out runtime deployment issues for the Perl 6 runtime library

Will:

• we could add the requirement to run from languages/perl6/ right now

c:

• that's fine by me for now

Patrick:

• that's an afternoon job, not too bad
• what do we need to do to get the Perl 6 and Parrot pages up to date?

Will:

• I'll work on that

Nicholas:

• why is C99 useful to Parrot and the compiler tools?

c:

• front-end parsing for C header files to build NCI declarations automatically
• the backend is pretty easy, that's thunk generation
• the front-end keeps people from having to write boilerplate code by hand
• generate the front-end once, where you have the headers, and then you can run the generated code anywhere even if you don't have the headers

Jesse:

• how does that compare to Python's ctypes?

c:

• as I understand it, they have the nice backend stuff
• not so sure about the front-end
• my P5NCI is nicer, if incomplete
• just haven't had time to work on it...

Jesse:

• if you put in for a TPF grant, that would be very useful

c:

• get me a clone first, and you have a deal

Jerry:

• Allison, we talked about implementing return
• that requires tying in exceptions to the concurrency scheduler?

Allison:

• yes
• just not implemented yet
• when we did exceptions, we didn't have concurrency
• so it's on the top of my list to tie them together

Will:

• Tcl's already using exceptions to handle return, break, and continue

Allison:

• right now, you can't have an exception handler which is a full subroutine

Patrick:

• I'm not sure we need one for that feature
• every subroutine block decorated as such in PAST puts an exception handler in the block
• if any nested block throws a return type exception, it grabs the arguments, does what it has to, and then does a Parrot return

Allison:

• if that's what you need, go ahead and do it
• I thought there are some features you didn't have yet

Patrick:

• I thought there might be some opcodes I needed, like handled
• but we can do something now
• might not be completely optimal
• but it's just packaging things up now
• I have something I think will work
• it's not trivial, but I'm 80% confident
• just a matter of sitting down and doing it

Allison:

• the concurrency stuff will be there before the next release
• might not want to roll it in before the release
• but it'll be there soon

Patrick:

• I want to get return in for the April 15 milestone we're behind on

Jerry:

• have you put in tickets for the breakdown of specific tasks?

Allison:

• I've never done tickets for that
• just sent mail to the list of the tasks
• handed them out to people as they volunteered

c:

• can you put them on a wiki page?
• some of the other committers wanted that

Allison:

• I can do that

The Perl 6 design team met by phone on 16 April 2008. Larry, Allison, Jerry, Will, Nicholas, Jesse, and chromatic attended.

Jerry:

• the release went pretty smoothly
• had some help
• the make release target is broken on Windows, and that's the only platform I had out here
• we'll fix that before the next release from Windows
• talking to Andy Armstrong about getting Test::Harness to 3.0 and subclass TAP::Parser so that we can report Rakudo's fudge tests better
• every fudged test is a failure right now, even if all subtests pass
• I talked Jonathan into implementing simple MMD in Rakudo
• chromatic wrote about it
• but it's broken in the release (and only the release)
• put some work into internationalization
• need to figure out the make rules
• then I can put more work into localization too
• trying to secure the parrot.org domain too
• TPF is likely to get five slots for GSoC
• some will be Parrot and Perl 6 related
• the official announcement is on Monday
• trying to encourage others to take on responsibility
• seems to be working
• some of the committers I've mentored are becoming mentors themselves

Patrick:

• mostly reviewing different things
• working with Jonathan on his various objects and MMD implementations
• will check in my Rakudo milestones document tonight or tomorrow morning
• cleaning up bug reports, closing tickets, catching up on patches
• need to spend a little more time on paying work this week

Will:

• trying to get the most recent release bundled as a macport
• there's apparently a build issue since the previous macport
• should have an easy way to install Rakudo as perl6 after that gets straightened out too
• still trying to cut dead things out of Parrot

c:

• poked at optimizations per Patrick's request
• sped up OO and Rakudo by about 40%
• not as much as I wanted, but you notice it
• looked at a few more optimizations, but they're bigger and take more work
• GC is the biggest, so let's hope we get that as one of the GSoC projects
• think I can get the profiling core to emit Callgrind-compatible output for PIR
• I know mostly how to do it now

Larry:

• spending a lot of time tweaking a new laptop and getting it all set up and customized nicely
• feebly trying to keep up with the onslaught in p6l
• I haven't been keeping up, but I'm keeping my eye out for things going off track badly
• plotting how to get rid of TRE as my longest token matcher
• want something that will scale better
• the handwriting was on the wall the first time I went in it with the debugger
• for the regex matching where a token is expected, TRE was allocating 17 MB on the stack
• I have some ideas for something with better semantics and less memory usage
• TRE optimizes for running one regex a lot over a lot of data, rather than running a lot of regexes

Jesse:

• spent a lot of time in discussions about funding Perl 5 hackers
• I see François Perrad has released a Win32 binary of Parrot

Jerry:

• he's been doing that for the past few releases
• just a release in binary form, not a fork or branch

c:

• what's the status of Parrot in Debian?

Allison:

• one final build bug in IA-64
• the guy with the box should be getting to it this week
• we're planning to put up the 0.6.0 release
• if it doesn't go soon, I'll just put the Fs on the site
• we might put IA-64 builds on our platform wishlist

c:

• we need someone who knows how to fix them too

Allison:

• it was a PGE bug unrelated to the arch, I think, in 0.4.0
• we just need the bug confirmed fixed on that arch for Debian

Jerry:

• PAUSE kinda stinks
• I hate that we don't know if we'll have an authorized release of Parrot until it gets uploaded
• PARROTRE lacks permissions on eight modules
• all of which have been refactored on something else
• they're all related to the configure or test system

Allison:

• we don't have to distribute through PAUSE

Jerry:

• we should not index those modules anyway

c:

• they're not that useful outside of Parrot anyway

Will:

• the release link on the Parrotcode site, http://www.parrotcode.org/release/devel, links to the CPAN download
• there's a lag between the update and the availability

Jerry:

• we could upload to Parrotcode first
• upload to the CPAN from that site

c:

• I'm not sure why we should index the config::* modules
• the only ones I care about are in Parrot::Embed

The Perl 6 design team met by phone on 09 April 2008. Larry, Allison, Patrick, Will, Jerry, Jesse, Nicholas, and chromatic attended.

Larry:

• trying to support John Dlugosz's clarification work on the spec
• working over the STD 5 grammar
• have it parsing statement lists now
• mainly revising the arcane quoting parsing mechanism it currently has
• plenty of refactoring and cleanup there
• re-evaluating how the tiny microlanguages floating around work
• the regular expression grammar is one sublanguage, a derived language
• there are all these dynamically-scoped minilanguages with terminators
• those tend to change depending on context
• trying to get those terminators to pass up and down the hierarchy efficiently and independently of other sets of tokens, while at the same time meshed in with them is an interesting challenge
• mix them in with the current set of longest tokens against which you're matchin?
• or give your set of terminators a higher precedence?
• an interesting little problem
• mixing them in might make you regenerate your lexer continually depending on your lexical context
• but if you mess with precedence, you might recognize a terminator that's actually a prefix of a longer token
• that could be anti-social
• plays out with all the quoting
• all these little minilanguages depending on which switches you've turned on
• if not terminators, it's at least sets of escape sequences
• also recognizing the terminator at the end of the string
• needs to be a dynamic solution there
• either integrated or not with the longest token solution
• also thinking ahead to the talks I'm giving over the next few months

c:

• did a little library work in Parrot
• trying to write in my journal more about it
• waiting for a list of small implementation tasks for new features
• will work on some polishing for next week's release
• still poking at profiling, but it's a bigger project to do right than people think
• thinking about how to revise our test suite

Allison:

• did some work on the strings PDD
• just have to check that in; I'll try this week
• spent several hours with Jerry on Sunday
• put together a list of milestones after the current set
• these are the key, critical milestones for 1.0
• talked a little bit about Parrot Foundation ideas
• giving a talk about Parrot at LUG Radio Live on Sunday

Jerry:

• working with Patrick on PAST syntax
• Jonathan has done some work on typing with Rakudo
• he's working out a couple of bugs
• he'll start on type-based MMD soon, per my request
• preliminarily we're getting five slots from Google for SoC
• we're hoping for more, because we have 16 good applications
• we'll know more by the end of the week
• preparing for the next release next Tuesday
• should go smoothly

Patrick:

• finished and posted the Mozilla Foundation report to my journal
• made my travel arrangements for the summer
• also speaking at the Texas Open Source Symposium on April 26
• cleaned up some RT tickets, applied some backlogged patches
• catching up on messages received while I was away
• still some Warnocking going on; trying to fix that
• checked in a patch to Rakudo which tells NQP to treat the input files as ASCII, not Unicode
• speeds up parsing by about 28%
• chromatic, can you profile the results and see what pops up?

c:

• I will
• if there's anything at the C level that looks fixable, I'll do it

Patrick:

• had some talks about smoke testing and such
• getting smoke testing of Rakudo is important now
• we can get a web page up with our status so people can see what works
• I'm banging the drums to getting that working, even if I have to do that myself
• doing some cleanups and enhancements to PCT
• closures, for example
• making things more robust
• need to review patches to Rakudo
• their ability to develop outstrips my ability to review
• good problem to have
• it'll take me a little while to catch up
• in the back of my mind, I'm playing with ideas for PGE
• how to integrate longest token match
• if it's possible to emit code that runs on a different backend
• C might be faster
• might run on a different VM
• that's a ways off though
• I want longest token matching first, sometime this summer

Will:

• TPF has grant proposals open now
• any Perl 6 publicizing we can do is a good thing
• regarding the Smolder grant, one of the original deliverables was setting up Smolder for a project which doesn't make sense for Smolder anymore
• someone's working with the project to set up Smolder for Parrot now instead
• no one on the Grants Committee is complaining

c:

• what's the opposite of complaining? I'm doing that

Richard:

• am I surprised you don't know the opposite of "complaining"?

Will:

• I managed to get access to update the Macport of Parrot
• we'll be able to get the current release in there now
• it's two years out of date at the moment
• code-wise, ripping out all of the deprecated features that I can
• also proposed a new opcode syntax, but had no feedback on it

c:

• made sense to me
• I didn't reply because I wanted to look at the opcode you mentioned
• I can't imagine how it could possibly work
• I just haven't proved to myself that it doesn't

Will:

• me too
• probably not tested

Richard:

• Patrick, I encourage you to look at Smolder for what you want with Rakudo

Patrick:

• I did, and I'm thrilled
• the grant behind it is great

Richard:

• putting in effort on acquiring TPF philanthropy
• a large chunk would go toward Perl 6 development
• hopefully soon we can make announcements on the usual channels about success

Jesse:

• CLKAO and I wrote about a thousand lines of code daily each for the past week
• looking for a thermometer about features and milestones per Audrey's Pugs Apocryphon 1
• nice way of giving people a high-level view of how things are going
• she had seven, each corresponding with a major version of Pugs
• I'm looking for an equivalent view for Rakudo

Nicholas:

• where can a symbol be both a terminator and the prefix of a longer symbol?

Larry:

• regular expressions have && and ||, but we have & and | of tighter scope
• if the lower-level rule looks for |, it'll see that in ||
• but it can't see that if there's a || which terminates that expression
• if you have a quoted construct and something that interpolates based on a multi-character token, parsing could hit that
• it's more in terms of regular expressions
• dipping into sub-languages in general
• how do you terminate a block of APL plopped into a chunk of Perl code?
• maybe an unmatched right brace corresponds to something in APL
• you need a way to guarantee policy one way or another in those

Nicholas:

• like the C++ annoyances about >>

Larry:

• you can have an assertion in angle brackets that contains something in angle brackets

Nicholas:

• looks like right shift

Larry:

• especially as double angle brackets by themselves can be their own token

Nicholas:

• will these new grants for TPF occur under the new grants scheme?
• the 2008 Q2 grants?

Richard:

• there's been some discussion about that internally
• it won't happen in full this quarter
• I've suggested that Alberto ask all grant submitters if they're comfortable having their proposals discussed publicly for now

Nicholas:

• I know Andy Armstrong and Merijn worked on parallel testing at Oslo QA
• I know TAP::Harness can run all tests in parallel
• the Perl 5 core needs an API to say that some tests had to run in parallel
• that API is tricky
• they may have solved it
• the Perl 5 core runs into problems with temporary file collisions

c:

• we have the same problem in Parrot
• not necessarily the PIR files written by the Perl 5 test drivers
• but it's solvable

Nicholas:

• Andy Armstrong used DTrace on Mac OS X to find these
• checking file opens and closes

The Perl 6 design team met by phone on 02 April 2008. Larry, Allison, Patrick, Jerry, Will, Jesse, Nicholas, and chromatic attended.

Larry:

• things are very busy
• working on a very interesting problem at work that's eating my brain
• sneaked in a few e-mails and synopsis changes
• not much work on the STD parser, just a few nips and tucks
• nothing earth-shaking, mostly just tune-ups in response to John M. Dlugosz and others

Patrick:

• things are going well
• wrote a draft of the second report for the Mozilla Foundation grant
• will post it soon, perhaps tonight
• there has been a ton going on
• this'll be the first in a series of postings to catch up on what's happened the last three months
• closed a few old tickets related to a deprecated feature
• everything that uses PGE is on the new syntax
• reviewed the PCT tutorial and sent kjs some comments and clarifications
• halfway through that
• the changes are all pretty minor
• the tutorial pointed out some places where PCT needs to evolve, and I'm working on that
• getting ready for some heavier Rakudo hacking and reviewing the test suite

Allison:

• finished the main edits to the Strings PDD
• still adding the API reference
• need to ask Simon and Larry to review it
• this is the last PDD in one of the milestones
• working on the next milestone schedule, prioritizing those
• also breaking up tasks for the concurrency milestone

Jerry:

• doing a lot of meta-work, not a lot of work
• four Parrot proposals and one Perl 6 proposal in GSoC
• maybe a few more on the way
• preparing for conference season, especially the Parrot and Perl 6 workshop at YAPC::NA
• hope to catch up with Allison while she's in town
• though we'll probably do more meta work

Will:

• lots of Parrot stuff
• cleaning up build dependencies
• removing some long-deprecated features
• hope to merge back our branch after the next release
• keeping on track with RT
• talked to kjs about shoehorning his tutorial into a compiler tools PDD
• it's a milestone, and one of the last ones
• Allison's looking after the remaining PDDs which aren't part of the milestones