The Perl 6 summary for the week ending 20030216
Welcome to the all new, entirely unaltered, all singing, all dancing
Perl 6 summary. Your beacon of reliability in the crazy world that is
Perl 6 design and development.
Another quiet week. Even quieter than last week in fact, unless my mail
spent some of the time up the spout, but I don't think so.
So, as is traditional, we kick off with perl6-internals
CGP - The Computed Goto Prederefed Runloop
Last week I mentioned that nobody seemed to have commented on Dan's bet
with Guido van Rossum that Parrot would outperform Python by OSCON 2004.
(I also missed the fact that the penalty for losing the bet now involves
cream pies as well as $10 and a round of drinks...). After I posted the
summary to the mailing lists, Leopold T�tsch informed me that he had
commented indirectly by announcing his new, improved, ludicrously quick
runloop that combines computed GOTOs and predereferencing. Whatever that
means.
This week, Leo and Nicholas Clark worked out how to combine the
blistering pace of the JIT core (for operations that had been translated
into hand hacked machine code) with the blistering pace of the CGP
runloop (for the other ops). As far as I can tell, this involved turning
the idea 'inside out', the VM actually starts up running JIT compiled
code and calls out to the CGP core to execute non-JITable sequences of
ops. The numbers for this approach look fantastic (quite stunningly
quick...) So Leo checked it in.
<http://makeashorterlink.com/?Y27C12083>
<http://makeashorterlink.com/?Q48C22083> -- Some numbers
<http://makeashorterlink.com/?G19C21083> -- Check in notice
Optimized runloops and threading issues
Last week we were reminded that JIT and predereferenced runloops don't
work in a threaded environment. This week Jerome Vouillon pointed out an
approach that looks like it could fix that (it seemed to convince Leo).
Dan (possibly playing mail catchup) said he was okay with having to fall
back to the old fast core (as opposed to the current, stupidly fast
core) in the presence of threads, but Leo seem to think that, using
Jerome's scheme we'll be able to have our cake, eat it and still throw
the cream pie at the Python team. Huzzah!
<http://makeashorterlink.com/?P2AC23083>
"keyed_int" issues
Leo T�tsch had wondered about why "{get,set}_<type>_keyed_int" vtable
methods needed to take an "INTVAL*" value instead of a plain "INTVAL" as
it introduced some possibly unneeded conditional code, a stack variable
for the key and made life hard for JIT code. It looks like the pointer
is a holdover from an early approach to doing multidimensional keyed
structures.
<http://makeashorterlink.com/?W2BC32083>
Changes to the calling convention and other fallout
Dan returned from the Sebastapol Perl 6 meeting with a few announcements
and one change in the parrot calling convention (how many calling
conventions have we had now?).
<http://makeashorterlink.com/?N2CC62083>
Macro support in IMCC
J�rgen B�mmels announced that he'd implemented macro expansion in IMCC
(Yay J�rgen!). Leo liked it, but requested a few changes before he'd
check it in, so hopefully, some time soon the mainline IMCC will have
macros, which is very nice.
<http://makeashorterlink.com/?A2DC15083>
Meanwhile, in perl6-language
Almost all the discussion was about the difference between arrays and
lists. Deborah Ariel Pickett came up with a good list of questions about
arrays and array references in scalar and list contexts, which Michael
Lazzaro answered (very neatly I thought) with a list of their different
contextual behaviours. Deborah extended Michael's list to hashes and
hashrefs in a reasonably obvious way. Smylers came up with a possible
new sigquote (after paraphrasing): "We should limit new features to
those that arise from a desire for the functionality rather than a
desire to use up 'spare' syntax". (Okay, it's not exactly *snappy*, but
I think it's important).
<http://makeashorterlink.com/?H1EC23083> -- Deborah's questions
<http://makeashorterlink.com/?C1FC42083> -- Michael's answers
And that wraps it up for the language list. I'm sure it'll pick up again
soon though. There are rumours of a draft apocalypse in the next couple
of weeks, and presumably that implies a real apocalypse soon after.
Assuming we haven't had another kind of Apocalypse in the mean time.
Announcements, Acknowledgements and AnotherWordBeginningWithA
This week's summary was again prepared in the comfy chair with
surprisingly few distractions apart from the late arrival of mail from
Leon Brocard announcing that he'd implemented a brainf*ck compiler in
brainf*ck, but that didn't really happen this week so I've got no excuse
for mentioning Leon's name in this summary.
Thanks to everyone who dropped us a line about our American Odyssey; I'm
hoping I'll have one of those web page things up at some point with a
rough itinerary in case anyone wants to come and throw rotten tomatoes
at me (or, preferably, buy me sushi).
Proofreading services were again down to Aspell and me.
If you 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, job offers or 17 inches of aluminium
goodness to [EMAIL PROTECTED]
This week's summary was, once more, sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
[EMAIL PROTECTED]
--
Piers
