Welcome to the leapday summary. We'll crack straight on with perl6-internals
As Leapday had been chosen as the release date for Parrot 0.1.0, the week was mostly spent getting things ready for release. A case in point was the PLATFORMS file which lists those platforms on which Parrot is known to compile and run, which (at the beginning of the week) was short several platforms and generally out of date. So everyone manned the pumps and sent in reports of success and failure. BTW, if you manage to get Parrot up and running (or even partially up and limping) on a platform that's not listed in PLATFORMS then firstname.lastname@example.org would be very pleased to hear from you.
Dan announced that he'd trodden on one of the nasty bits of objects; the proper ordering of classes for initialization and destruction in the face of multiple inheritance. He announced that he was in the process of actively ignoring it for the time being and canvassed opinions about whether to delay the Leapday release in favour of fully specced/implemented objects or whether to make the 29th without objects, or some other choice. In the end we decided to still aim for the 29th, with objects in a 90% there state, but with big 'HERE BE DRAGONS' warnings plastered on the tricky edge cases. A little later Dan announced what would be there for the release (Multiple inheritance, attributes, object instantiation and method calls) and what wouldn't (monkeying with some things after subclassing/instantiation, method redispatch and fancy namespace lookups).
As the week progressed, objects inched closer and closer to readiness, though at least one summarizer's heart was in his mouth as the week ebbed away. Would Dan get everything he'd promised working before the deadline? Tune in later on to find out.
On Wednesday, Leo Tötsch announced a feature slush (patches to add OO features were still being accepted) in anticipation of a release. The patch rate increased as people got on with fixing up failing tests on various platforms, improving documentation, and improving OO functionality. Not all the object patches were from Dan; chromatic got in on the act with a couple of tweaks to parrotobject.pmc...
It turns out that, just at the moment, Parrot bytecode isn't actually platform independent. This will, of course, get fixed, but it's not Leo's top priority at present. He asked people who are running Parrot on 64 bit and Big endian architectures to submit native_pbc test files (if you're on such an architecture, take a look at t/native_pbc/*.t for instructions, and the Parrot community will thank you for it).
Simon Glover did some sterling work exercising the Object documentation and implementation, posting several bug reports and questions.
On Wednesday, several full days before the release date, Dan announced that objects were done (well, everything that he promised would work did) and asked for people to start 'abusing it heavily'. Which they promptly did. There was applause too.
Having got objects up, Dan immediately posted a list of desiderata for the next release but one. Is there no stopping him?
Will the madness never stop?
Mitchell Charity spoke for everyone when he posted an extract from PDD15:
What .NET calls an attribute parrot calls a property What .NET calls a property parrot calls an attribute
Everyone shared the pain, though Paolo Molaro pointed out that it's not exactly accurate and the .NET name for a parrot attribute is 'field' (which is yet another term with wide variety of meanings when you think about it). Not being the biggest OO fan in the world, Dan swears he's just going to rename them Fred and Barney but not tell anyone which is which.
Mitchell also pointed out that LANGUAGES.STATUS was out of date and several languages which were supposed to be okay failed to work on his system. He asked for feedback to get it updated correctly.
Gregor Purdy found that Parrot was doing different things with the .pasm file generated from an .imc file by IMCC than it was when it ran the .imc file directly. Melvin Smith and Leo both agreed that it was a bug, but it's very hard to fix with the current incarnation of IMCC. IMCC2 should (will) fix the issue. Leo provided a workaround to fix the generated .pasm though.
Yay! Parrot 0.1.0 "Leaping Kakapo" got released at 2004022913:45:49 GMT. This is a big release, with Objects and multi-threading as well as a major documentation overhaul and a bunch of other good stuff. Anyone who suggests that I'm only really excited by this particular release because I came up with the code name.
Pointing out that the Kakapo is a flightless, nearly extinct species of parrot is considered unsporting.
Aaron Sherman noted that Apocalypse 1 was published in 2001, and it made mention of Apocalypse 26. And we've seen all of six apocalypses. He wondered if there was anything that could be done to increase the apocalypse rate. As chromatic pointed out, no plan survives first contact with the enemy; it turns out that a lot of the theoretical apocalypses (one apocalypse per chapter of Programming Perl), aren't actually necessary for specifying the language to the point where we can start implementing.
Larry also answered Aaron's concerns and noted that last year he had to take half a year off 'to participate in various non-optional gastric revisions'. He quickly discussed the outstanding chapters and RFCs and pointed out that a large amount of the work had already been done. Which is nice.
Larry also showed us his outline of Apocalypse 12 which is apparently about a week away from the first alpha for the sixcabal. It looks rather promising (and it's rather easy to see why it's taken so long).
http://groups.google.com -- Larry's big plan
http://groups.google.com -- Apocalypse 12 outline
John Williams wondered about how accessors will work with Perl 6 objects. In particular he wondered about cases like:
$foo.bar_attr += $z; $foo.bar_attr++;
Things got a little complicated, indeed Larry muttered that there would be a delay to A12 because John had asked him to explain something that he hadn't figured out yet.
Austin Hastings came up with a neat little problem for matching. Consider an instrumented string class which carries information like 'bold' and 'italic' or even the language of a substring. How would you write a search to match all the letters 'l' in french text. (Not a very realistic problem I know, but you'll have to bear with me).
Larry responded with a neat idea involving
&, so you would write:
/[l & <french>]/
where french is presumably a block rule that makes a method call on the appropriate character.
Damian's Exegesis 7, dealing with the replacement for Perl 5's format, was published on Thursday. It's jolly good. Really. And you can use it now if you grab Perl6::Form from CPAN. This threw up a pile of questions about ambiguities, edge cases and all the other stuff that p6l does so well. The version of the exegesis at perl.com has already been updated to take some of these issues into account.
Whee! The Summary goes to the mailing lists before midnight on Monday. "Will I be able to keep up this dizzy pace?" I ask myself.
If you find these summaries useful or enjoyable, please consider contributing to the Perl
Foundation to help support the development of Perl. You might also like to send me feedback
http://donate.perl-foundation.org/ -- The Perl Foundation
xhttp://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk/ -- My website, "Just a Summary"