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

Reply via email to