| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
It's Monday morning, the croissants have been baked, the focaccia is glistening with all the extra virgin olive oil I poured on it as it left the oven and, in the airing cupboard, a raisin borodinsky slouches towards full proof (thought at the rate it's currently rising it'll probably be Tuesday before I can bake it off), what better time could there be to pause and write a summary?
So, I'll kick off with perl6-internals because, well, it's on the summary checklist (which goes something like: 1. Wibble about the weather or something before; 2. Start with perl6-internals; 3. Continue with perl6-language if it saw any traffic; 4. Make announcements, suggest people give money to the Perl Foundation; 5. Make sure Leon Brocard gets a mention; 6. Aspell; 7. Mail PODs to perl.com and a text version to perl6-announce; 8. Profit!)
Right at the end of the previous week, Melvin Smith suggested having the initial 'empty' PMC registers all point at a global PMCNull which would throw an exception if you tried to invoke any of its methods. Which sounds weird, but it does mean that you get a real exception instead of a segfault, and exceptions are so much more trappable. Dan liked the idea.
Melvin later posted a patch implementing the idea, which Leo Tötsch fixed up slightly an applied.
Steve Fink is having problems using an unprototyped call to a prototyped function, which he thinks is a reasonable thing to do (and I think I agree with him; I can imagine cases where you have a function pointer or something where you don't know its exact prototype, but you do want to make a call to it so you'd be forced to make an unprototyped call.). Melvin Smith disagrees with him. Steve then went on to point out that he's still getting failures when the function is both declared and called in an unprototyped fashion. According to Leo, this is because unprototyped returns are neither defined nor implemented. Which is odd really -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call.
Arthur Bergman, Ponie stablemaster, popped up to point out that definitions like
#define version obj.version
(found in include/parrot/pobj.h if you're interested) did some
scary things to Perl_utilize in the Perl 5 core. Steve Fink stuck
his hand up to being the person who added the version field (which is
apparently rather handy if you're debugging the Garbage Collection
(GC) system. Leo fixed things by applying a
s/version/pobj_version/g patch.
Arthur popped up again asking for help with implementing a
Perl5LVALUE PMC. It turns out that the API doesn't quite support what
he needs. After a certain amount of discussion of various options
Arthur proposed a Parrot_PMC_attach_data(Parrot, PMC, *void)
extension to the API. He didn't *quite* get what he wanted, but he
got something very like it later in the week.
I did like Arthur's reasons for starting the serious Ponie effort by working on Perl5LVALUEs though: "[because] it is so obscure that it's hardly used anywhere and is limited to a few small areas in the core".
On Monday, Leo declared that yes, Melvin Smith's proposed Halloween 'Screaming Pumpkin' Parrot release would be happening. Various people promised extra goodies, and a few problems were sorted out with some platforms.
Features were frozen on Wednesday and Parrot 0.0.13 "Screaming Pumpkin" was released upon a cowering world at 2003103114:11:46 precisely. For all the astonishing speed of the release cycle, there's a lot of good stuff to be had in the screaming pumpkin, check out Leo's announcement for details.
groups.google.com -- Leo's announcement
Jürgen Bömmels wasn't entirely happy with the way Parrot's headers are set up. Apparently there are some nasty dependency (and crypto dependency) issues. He proposed fixing up the headers as much as possible to eliminate these issues. Dan and Leo thought it would be nice, but Dan thought there wouldn't be that much point in doing it as things would probably decay, and pretty much everything internal should just be using parrot.h, and everything external should be using extend.h or embed.h.
Jürgen Bömmels triggered a quick bout of tinderbox fixing, as various different hardware experts helped to figure out why several of the tinderboxes weren't building and testing successfully. Jonathan Worthington submitted a few patches to clean up the various Win32 warnings. David Robins submitted similar patches to clean up some Solaris warnings.
Anuradha Ratnaweera asked a bunch of questions about how Parrot and Perl 6 would interface to external C and C++ libraries. The Leo and Dan provided the answers.
(Sorry about the heading, I couldn't resist). Jonathan Worthington reported some breakage of NCI on Win32. He and Leo worked through the issues in search of a fix.
Luke Palmer responded to the comment in last week's summary about the way to instantiate an object in class Foo being:
new P5, .Foo
He worried that, because classes are now simply integers, there was no way to garbage collect class objects if anonymous classes were used heavily. Jeff Clites, Leo and Dan all rushed to reassure him.
On Thursday, Melvin Smith announced that Parrot had fetched its first web page. Your parrot can fetch webpages too, just update to the latest, check out examples/io/http.imc and the world is yours. Everyone made impressed noises.
Melvin announced that, in his personal copy of Parrot he has most of the Class metadata declaration support working, but that he wouldn't release it 'til after the Screaming Pumpkin release. If it's as good as he promised, I guess we can wait.
Noting the presence of the is_digit function, Peter Gibbs wondered
if it would be useful to have a set of is_foo functions, or better
to have a single is_ctype function with an enum parameter. He
preferred the is_ctype option, and set about implementing it. Ever
the speed demon, Dan thought it best to have a reasonable set of
is_foo functions for 'common' chartypes and a fallback is_ctype
function for the rest. Once they were all wrapped up in sensible
macros that would mean that you didn't have the possibility of a very
small speed hit getting multiplied up in the middle of a tight loop,
but the programmer wouldn't have to worry about which types were
checked in which fashion.
Leo Tötsch posted a patch to switch Parrot over to using pmc2c2, the new version of the PMC compiler, but didn't commit it because his Makefile was playing up. He asked for some help to fix that before the patch could be committed.
Ron Grunwald suggested that it might be a good idea to include a glossary with each summary explaining what IMCC, PMC and PIR stand for (um... Incredibly Magnificent Compiler Compiler(?), Parrot Magic Cookie and Parrot Intermediate Representation(?) respectively) and maybe giving some explanation of other bits of Parrot jargon. Which is a jolly good idea. But laziness dictates that, instead I point you all at docs/glossary.pod which, following a gentle nudge on the mailing list, covers the above acronyms and more (but sadly some of 'em are missing from the Screaming Pumpkin release).
There was some real traffic. With questions. And Answers! What is the world coming to? Admittedly, there were only 10 posts in the week, but it's the quality that counts.
Remember last week, when Luke "Edgecase finder general" Palmer asked about named return values and made David Storrs boggle? This week he was answered. By Damian. And Larry. Any question that elicits a "Please, no!" from Damian has got to be a good question methinks.
The question revolves around the statement in Apocalypse 6 that a
list on the left hand side of a binding operator (:=) is
interpreted in the same way as a function signature. Which means that
you can use 'named' binding:
(who => $name, why => $reason) := (why => $because, who => "me"); # ($name == "me") && ($reason = $because)
What elicited the "Please, no!" was Luke's logical conclusion that this could also mean that you could do:
(+$name, +$id) := getinfo();
and the unary + would be treated as a 'named only' marker in the
same way it would be in a function signature.
Interestingly, Larry was less convinced that this was inherently a bad thing, though he did propose that, under most forms of stricture that it should only work in the case of:
my(+$name, +$id) := getinfo();
because the my helps the reader to realise that + may not be in
Kansas any more without having to reach the := and then
reinterpret everything that went before. (If you've heard Damian,
Allison or possibly even Larry talking about Perl 6, you've almost
certainly come up against the concept of "end weight"; this is an
example).
It's been a while since Damian said anything in perl6-language, so David Wheeler welcomed both him and Larry back. Damian thanked him, and posted a short status report. While he's not been in quite the same state as Larry, "mild influenza and a little light pneumonia" don't sound like a barrel of laughs either. Anyway, he's back on the case when he can spare the time from putting food on the table.
Joe Gottman had some questions about currying. Luke Palmer and Jonathan Scott Duff answered 'em. I'm getting quite good at this summarizing malarkey aren't I?
Whee! Monday is this week's Monday! What's the betting I can keep it up?
Those of you who've been reading this summary since almost the beginning will remember that I copped the basic 'chunks of text followed by a link or two' format/structure(hah!) of these summaries from NTK. Well, this Friday's NTK had some coverage of the state of Larry and Damian's health in their HARD NEWS section (www.ntk.net
If you found this summary valuable, please consider one or more of: