Lumme! Another week, another summary.
Every week (almost) we start with the perl6-internals list, so here goes.
Our Glorious Leader, Dan Sugalski, last week asked for volunteers to work on making ordered destruction work. (Ordered destruction is where the system tries to ensure that 'parent' objects get destroyed before any of their children). Jeff Clites announced that he'd got a partial implementation working.
Neither Leo Tötsch nor Jürgen Bömmels were sure that the approach Jeff was taking would be the Right Thing in the long run, proposing instead a more general iterator mechanism.
Bringing the perl6 compiler (in languages/ back to live, Steve Fink has committed a 'rather large' patch which implements a subset of the Apocalypse 6 subroutine signature rules. The implementation is apparently very ad hoc and shouldn't be regarded as the final word. But it looks like a very good start to me.
Responding to Matt Fowles' observation that the parrot website is rather behind the times, Robert Spier let slip that there would soon be a revised website that will be easy for everyone to send patches to, and which would be much easier to have multiple maintainers of different areas of the site.
Of course, there are still a few 'technical chunks' that need to get finished before it's ready to unveil, but it's good to know that work continues in this area. Thanks Robert.
http://www.vendian.org/parrot/wiki/bin/view.cgi — Mike Scott's Parrot Wiki
Chances are, you've never really needed a
fortytwo operator, or
what_do_you_get_if_you_multiply_six_by_nine operator, and
you certainly don't need them cluttering up the parrot core. Which is
why Leo Tötsch has implemented those ops as a dynamically
loadable ops library.
Admittedly, you're highly unlikely to load this particular ops library, but the underpinning tools for dynamic loading of ops libraries are new and potentially very useful.
Rather later in the week, once he'd got dynamic loading of ops working in all the runtime cores, Leo posted an 'intermediate summary' which explains how things work.
Dan has been thinking about the problems that can arise with dynamic loading. One issue is that, if you have separate files for each PMC class, opcode library and parrot function library, things get unwieldy very quickly, and if you're not careful you'll exhaust the OS file descriptor pool. Which would be bad. So, he asked for a sanity check before going on to work out a scheme for bundling libraries into larger files. Leo agreed that Dan was talking sense, so I expect we'll be seeing some design in this area soon.
It's been a busy week on the parrot front for Dan. On Wednesday he outlined his thinking on instantiating objects, with the aim of getting single inheritance objects up and running. This sparked a good deal of discussion, but nothing was actually agreed.
Surprisingly, Jürgen Bömmels opened up a can of worms when he redid IMCC's macro support to use a hash lookup instead of a linear search through an array. This sparked a good deal of discussion about the right scoping, which hash implementation to use, and whether IMCC should be closely entwined with the interpreter.
Dan checked in a patch to fix opcode numbers for the core ops, deliberately breaking the JIT in the process. Leo wasn't happy. After a bit of back and forth, we now have fixed opcodes, but the implementation isn't quite what Dan originally did.
There was also some discussion of how many opcodes really needed to be fixed; after all, in the presence of dynamically loaded oplibs, you can't nail every opcode down. Leo worried that dynamically loaded oplibs don't play well with JIT, and making it work would probably need a total rewrite of the JIT core, but Jürgen didn't think it was all that bad.
$ patch RESPONSIBLE_PARTIES 6c6 < Release pumpking Steve Fink --- > Release pumpking Leopold Toetsch
In other words, Steve Fink has stepped down from the role of Parrot Pumpking and handed the his mantle on to Leo "Pumpking Patchmonster" Tötsch. I'm sure I'm not alone in wishing to thank Steve for his sterling work as our release manager. Nor, I'm sure, am I alone in wondering where Leo finds the time.
Simon Glover wanted to know what sort of bounds checking was/will be done by the extension API's register access functions. At the time of his writing they didn't do any, which meant you could trivially cause a buffer overflow in your extension by accessing an illegal register number, like 42. Dan said that what needed to happen is for the access functions to do bounds checking and to throw an exception on an illegal register number. Which wasn't quite as straightforward as he thought.
What's that you say? You've never heard of perl6-language-subs? Shame on you. Actually, I'd forgotten about perl6-language-subs but, judging by the messages I've seen on the list since I started writing the summaries, it would appear that it's a mailing list where students can ask the Perl 6 community to do their computer science homework for them. I don't expect to be covering this list any further.
Larry returned from what sounds like a horrible couple of months in hospital and answered Luke Palmer's awkward question about block returns from a couple of weeks ago.
Tuesday is no longer the new Monday. Wednesday is the new new Monday.
If you found this summary valuable, you might like to consider one or more of:
- Get involved. Parrot (and Perl 6) needs programmers, authors, users and other interested parties. Join the mailing lists and start to contribute. (Check http://dev.perl.org/perl6/ and http://www.parrotcode.org/ as good starting points).
- Support Larry, Dan, Damian and company by donating to the Perl Foundation at http://donate.perl-foundation.org/. I hate to think what the Wall family medical bills must be like at the moment.
- Give me lots of lovely feedback at firstname.lastname@example.org, you know you want to.