Welcome back to another Perl 6 summary in which Piers comes back from watching a load of pretty girls dancing 'round a huge Maypole in Wellow (it's 60 feet high, the tallest permanent Maypole in England, there's been on on the site since at least 1856. One does wonder if the Lord of the Manor who put the first one up was compensating for something). It's not my favourite English traditional event (you'd have to go a long way to beat the Whitby Penny Hedge for weirdness or the Brockworth Hill cheese-rolling for complete and utter reckless insanity (it was called off this year because the people who usually provide cover in case of accidents are in Algeria helping deal with the aftermath of the earthquake there; St John's Ambulance didn't feel up to the rigours of dealing with the kind of injuries that occur when too many people chase a Double Gloucester cheese down a 1 in 2 slope.)) but it made for a lovely afternoon.
Which is why, instead of having this written by mid afternoon on a Monday, I'll be lucky if I have it finished before Tuesday. Ah... the trials of a summary writer.
So, we'll start with perl6-internals because that's what we always do.
Will Coleda discovered that IMCC didn't allow him to have a variable name that happened to be the same as an op, which isn't what the spec says and which could lead to interesting problems where IMCC source code suddenly becomes invalid when someone adds a new op to the language. Will sent a patch to fix the docs. Leo Tötsch didn't apply the patch, choosing to fix the problem instead. Yay Leo.
Leo Tötsch finished checking a series of patches which switch the Parrot source code over from accessing vtable innards directly to accessing them via macros, thus making it easier to monkey with vtable internals without having to change a million and one different source files.
After last week's discussion of timely destruction, the debate
continued this week. Dan announced his design for dealing with the
issue. PMCs now get a flag marking them as requiring timely
destruction and there's a new op to trigger a DOD run if and only if
there are any flagged PMCs in memory. The idea is that compilers for
languages that care about timely destruction would insert the
lazysweep op into their generated code in the appropriate
places. Mr. Zellyn Hunter (hey, that's what he asked to be called, who
am I to argue?) suggested a different name for Dan's proposed flag and
offered the following joke which I repeat here in its entirety because
it's funny (because it's *true*).
Q: How many Parrot programmers does it take to screw in a lightbulb?
A: Just one, as long as it's Leo Tötsch. He will probably also rewire your entire electrical system slightly, saving you about 3% in power consumption during the evenings and on weekends.
Leo denied the truth of this as lightbulbs are hardware and he doesn't do hardware.
Meanwhile, back at the thread...
Guess what? People didn't like the solution. I think this is a classic
problem of GC. Everyone agrees that real Garbage Collection is a good
idea, but they also want it to work by magic and take no time at
all. Sadly, whilst Leo is good, even he can't change the laws of
physics. My suggestion: if you're currently writing Perl code that
relies on magic to close a filehandle the instant it goes out of scope
then Don't Do That, close it yourself. That way, when you come to
switch things over to Perl 6 you can do
use GC scope_end => undef (or something) and get blistering performance and real GC.
Clinton A Pierce has rewritten BASIC's expression evaluator and is reintegrating it with the runtime. This has left a lot of 'junk code' that never actually gets executed, and Clint wanted to know if there was a way of tracking down (and removing) the unreachable code. Leo implied that the answer is 'run it under IMCC' which apparently does dead code detection. This didn't quite work for Clint as IMCC threw an error when it tried to run some BASIC generated PASM (at least, it does when run in dead code detection mode...) Leo wasn't able to help directly with tracking down the issue, but did provide some pointers for conversion of the BASIC compiler so that it targets IMCC's PIR language instead of simple Parrot assembly. This prompted a list of questions from Clint about IMCC and Luke Palmer provided a some good answers.
Sean O'Rourke noticed the new Perl 6 book in O'Reilly's catalogue and wondered where Leo found the time to become an author as well as a coding machine. Dan popped up to note that the plan is to have the book available in time for OSCON and YAPC::Europe. (Be there or be somewhere else). Randal Schwartz mentioned that he'd been a tech reviewer for the book and had found it 'quite an interesting read'.
http://www.oreilly.com/catalog/perl6es/ -- Americans can't spell catalogue
Leo Tötsch posted a proposed new layout for PMCs now that PMC access has been hidden behind macros and asked for comments on his proposed new scheme for the new PMC layout. Dan commented on this, and between them he and Leo appear to have hashed out a way forward. Leo kicked out a patch using the new PMC scheme, with a second version not long after.
Things have started to pick up a little after the virtual silence of the past few weeks.
Dulcimer wondered if anyone was working on a simple introductory tutorial for Perl 6 yet. He thought that writing one might help get him up to speed, especially if people on the list critiqued it as he wrote it. Michael Lazzaro pointed to the documentation list email@example.com which is apparently rather quiet at the moment. Dave Whipp wasn't sure that the time was right to write a tutorial yet as we don't yet know enough about the final language (Personally I think anyone attempting to write a Perl 6 tutorial before the object system gets designed/documented is going to end up having to do some fairly dramatic rewriting at some point).
Anyhoo, this led to a string of suggestions trying to sum up the Spirit of Perl 6, one of which managed to be a spoiler for Buffy the Vampire Slayer...
Simon Cozens also nodded towards the forthcoming Perl 6 Essentials which may be just what Dulcimer is after.
Discussion of Coroutines in Perl 6 was the thread that ate the list this week. John Macdonald, had a few observations about using coroutines and suggestions for the best semantics for them in Perl 6. There seems to be a split between those who want the caller to know it's calling a coroutine and those who want the coroutine to be invisible to the caller. Halfway along the thread, Damian wrote up a proposal which he hoped would make everyone happy. It didn't succeed, but it was at least a step forward as the proposal got batted back and forth a few times, leading to another proposal which got batted back and forth a few more times and which received far more acclaim.
Damian's proposals introduced a new
coro declarator for coroutines,
which Piers Cawley thought wasn't really necessary, and there was some
discussion about whether 'coroutineness' was something that could be
applied to all sorts of different Code based things, in which case
using new declarators could lead to ugliness (coro, comethod, coblock,
corule...) or if there was only really one thing. The jury is out on
There was also discussion of possibly unifying coroutine and threading syntax, which some people thought was cool and which others disliked intensely (nothing new there then).
There was also discussion of what a coroutine is, and why you would want to use them. Damian gave a good explanation of some of this. Actually, Damian gave some really good philosophy in this thread about why he likes Perl.
Elsewhere in the thread, some fool called Piers Cawley attempted to introduce a discussion of multimethods and failed dismally to change the subject line. Bad Piers.
http://groups.google.com/groups -- Damian's proposal
http://groups.google.com/groups -- Damian's second proposal
http://groups.google.com/groups -- Damian addresses the ``Why coroutines?'' question
http://groups.google.com/groups -- Damian on why people like Perl
The eponymous Bryan C. Warnock (note to any Wired Jargonwatch editors who may be watching, that's Bryan, not 'Brian') popped up to set the record straight about his dilemma. Delightfully, by the end of the week, nobody had replied to him.
Thanks once again are due to all the good people on the Perl 6 lists. Apologies will probably be due to the organizers of YAPC North America as I still haven't started writing the talks I'm supposed to be giving.
If you've appreciated this summary, please consider one or more of the following options:
- Send money to the Perl Foundation at http://donate.perl-foundation.org/ and help support the ongoing development of Perl.
- Get involved in the Perl 6 process. The mailing lists are open to all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.
- Send feedback, flames, money, photographic and writing commissions, or a description of this week's deliberate mistake to firstname.lastname@example.org. I'll be awarding points, and points mean prizes.