The Perl 6 design team met by phone on 26 August 2009. Larry, Allison,
Patrick, Jerry, Will, and Nicholas attended.
Larry:
- mostly this last week on an awful lot of question answering online
- spent far too long trying to figure out how to start monitoring Twitter
Patrick:
- when you've figured it out, can you let me know?
Larry:
- even went all the way back to the twitter webpage, with a Firefox extension to auto-reload every 5 minutes. You're hosed if you're typing at the point when it reloads, as it throws it away
- downloaded Adobe AIR, because a lot of the clients want that, but it wanted to download Flash, so I said "Forget about that"
- [Twitter] is probably another big timesink. Well timed given the headline this week about people multitasking
- spec work: a lot of clarifications
- disallowed alphanums as quote delimiters, or at least mention it in a better place
- thinking a lot about the notion of type with implicit coercions
- talked about it a bit on #perl6
- put a typename in a declaration, and follow it with
() or a type in ()
- the named type defaults as
Any. Externally it advertises that it takes an Any type, but it coerces it internally the named type
- probably removes need to write a lot of functions and packages in the
Any package, as it will automatically put things in the right place
- also won't need to write explicit coercing multis in the
Any cases
- thinking about changing the syntax of declarations of context vars
- currently a trait, think it should be a separate decelerator
- unfortunately "context" looks far too much like "constant", so too much visual confusion
- didn't manage to get any hacking on
viv, but hopefully soon, and will finish the bootstrap
- encouraged by seeing the microcosm of that bootstrap -- the grammar engine that Damian put on top of 5.10 regexps
- in the standard grammar, fixed some error messages to be more specific on [something], maps with missing commas and malformed comments
- it catches alphanums used as delimiters, to go with the spec
- now correctly parses Pod style inline comments, with
#=[] and indented Pod, to go along with new Pod spec
- made comments into a syntax category, so it will be trivial for a user to add their own comment syntax
Patrick:
- had visitors, but they're gone, no more trips planned and the kids are back at school
- working on grants: worked with Jonathan to get his Hague grant finished, and on his new one. Sent that to TPF
- working on my grant
- working on a couple of Vienna grant days
- also a variety of planning
- made minor bug fixes: added code to Rakudo's config script, so that if someone attempts to build Rakudo with a Parrot that is installed without the dev components, gives a nicer error message suggesting that you need to use
install-dev
- trying to make it friendlier for people trying to build it, to figure out what's going wrong
- last week's Rakudo release went just fine. No major problems to talk about
- the "PDX" release. Actually, from the US perspective it went off on Wednesday, a day early
- looking at a few things in Parrot HEAD that have caused Rakudo problems building, but nothing spectacular
- made a patch to Parrot that
causes it to no longer compare strings when doing
isa checks
- resulted in about a 4.5% overall speedup for Rakudo (and
should affect other PCT-based languages similarly)
Jerry:
- yesterday was the Parrot Foundation annual meeting
- all existing directors voted in by the membership for another year, and added an additional director: Patrick, so welcome to the board
- my summer has been full of wonderful distractions
- hopefully it will start raining soon, and I'll have more time
Will:
- trying to keep Partcl up to date with Parrot, but first commit after 1.5 was released caused a huge leak that killed my spectest
- I'm stuck at 1.5 release
- [the Parrot commit] was fixed, but that caused Parrot to segfault all the time for Partcl
Allison:
- maybe we should revert that
Will:
- all Parrot's tests pass with that
- forward is probably the best the way out
- There was a discussion on IRC: "Why aren't Parrot's tests failing, if the languages' are?"
Allison:
- Parrot's aren't very complete
Will:
- glad that we're tracking Parrot quite regularly, as Parrot could have got out with a release [with problems for Partcl], but it doesn't, because we're tracking HEAD
- wrote code, added functionality, but for Partcl, not Parrot, unfortunately
- I'm pitching Partcl as easier to hack on than Radukdo
Patrick:
Will:
- I could give you some patches, but IIRC last time I broke the spec test
Patrick:
- you're more that welcome to pitch Partcl as easier to hack on
- I'll fight that by making Radudo easier to hack on
Will:
- hitting segvs and PGE issues that seem to be hitting infinite loops, but need to get HEAD working so that i can diagnose these and open tickets
Allison:
- working on PCC branch, now at about 500 failing tests
- went up to 2700 failing when the PIR tests started printing out a plan
- down 2500 with one change to get MMD working with the new argument passing scheme that was pretty good
- part of the week taken up with Parrot Foundation work
Patrick:
- Rakudo wants features soon please
Allison:
- been reviewing Vasily's branch
- it's not "do we merge it all, or do nothing?" but "do we merge as-is, or do we work to refine it to give backwards compatibility"
Patrick:
- there's an intermediate level, even within that
- backwards compatibility versus delay -- Rakudo would prefer no delay
- within the Rakudo camp, we're really beginning to struggle with Parrot and features landing, because we're working to our deadline
- I chatted with Jonathan - calling conventions are not needed for September, because Jonathan is on holiday, but if they don't land by the start of October, it's a real pain for Rakudo Star
Allison:
- it's really down to the pace of development -- I can go as fast as I can
- go, but [not faster]
- I can't tell you how long it will take to get 500 failing tests resolved
- might be 2 hours -- I fixed 2500 in an hour, with one line of code
- it could be scary edge cases, say the last 5 tests take two months
- I will work as fast as I can
Patrick:
Allison:
- I do have strong opinion on our deprecation policy
- we picked this to avoid problems Parrot was having before 1.0
- back then there was no way even Rakudo could safely develop on it because we kept yanking carpet out from under it
Patrick:
Allison:
- It does, but [a lot less]
- [with the policy], change this macro one way, people using it can still use it
- we can't predict everything
- we will never have no bugs
- if [making these type of changes] is really simple and you can do it, it's insane not to
Patrick:
- can we resolve the problems in trunk, or should Rakudo build against a branch?
- branches can't be long lived
- otherwise there's a really big problem when they are merged merged
Allison:
- We need our developers to think of deprecation cycles
- if function is on the API list (thanks Jeff, for compiling that)
- if your changes change an argument to a function on the API list, you can't change it on a deprecation cycle
- you can create a new function that takes alternate arguments, say
PMC * instead of void *
- think of this as you go, and there's no problem
- merge and we go on
- you need a degree of forethought as you go
- [the branch] looks like all it needs are a few function and macro changes, which is impressive, given how exotic it is
Patrick:
- I trust Rakudo's ability to adapt to Parrot better than than Rakudo waiting for a feature to be definitely safe
Allison:
- on the other side, when we're approaching a production release, say 2.0, if you've got some dramatic changes, the earlier you can merge them in after the previous production release, the more time you have to test trunk
- there's tension between merge in as soon as possible and delay until everything is stable
Patrick:
- would be okay with me if things broke in early months (August, September)
- bigger changes in October, November -- there's not as much time to react
- that argues in favour of going into trunk and fixing breakages there with HLL languages that can find them rather than holding a branch, trying to get it there [perfection], and then having little time [in trunk, before a release]
Allison:
- it's about balancing, weighing the good and bad
Patrick:
- for Rakudo, we desire advancement and features more than stability
- this may not be Parrot's priority and that's fine
Allison:
- the phase you're in is roughly where Parrot was around this time last year -- rapid development towards a point where you can then get to settle down
Patrick:
- rapid development, but a lot of blockers outside our court
- if they were in ours, it would be comfortable, but they are in Parrot's
Allison:
- Aside from calling conventions, and GC-able contexts, what else does Rakudo need?
Patrick:
- Really just those two, but calling conventions are bigger, much bigger
- we expect to have to redo parameter parsing and arguments
- need to do that and happy to do that, because we know we will get big performance wins
- not much else I can think of in Parrot is a huge advantage to us
Allison:
- if we get to a point in the PCC branch where 20 nasty edge cases are all that fail, I'll let you know, as you can try a branch of Rakudo to target it
- hopefully we won't get there. Hopefully the last 500 failures go
Patrick:
- we have some really really good troubleshooters in Parrot right now, at the C level. When something in Rakudo breaks, they fix it fast
- I really have a lot of faith that bugs would be found and fixed quickly
