Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday September 04, 2009
03:13 AM

Perl 6 Design Minutes for 29 August 2009

[ #39579 ]

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:

  • grrrrrrrrrr

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:

  • will be great (Thanks)

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:

  • it still happens :-(

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
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.