Time marches on, and another summary gets written, sure as eggs are eggs and chromatic is a chap with whom I will never start a sentence. We start, as always, with perl6-internals.
Work continued this week on expanding the number of known (and preferably known good) platforms in the PLATFORMS file.
Dan reckons it's time to be a little more aggressive with tests for ancillary
stuff, in particular the contents of the languages
subdirectory. He called for language maintainers (and any other interested
parties) to at least get minimal tests written for all the languages
in the languages directory, and to get those welded to the
Tim Bunce congratulated everyone on Parrot 0.1.0 before asking about where we stood with IMCC and objects/methods. Leo confirmed Tim's supposition that there is no syntactic support for objects and methods in IMCC, at least in part because there's been no discussion of how such syntax should look.
Jerome Quelin responded to Dan's otherwise ignored request for a parrot equivalent of perlbug when he offered an implementation of parrotbug for everyone's perusal, but didn't go so far to add it to the distribution. I don't think it's been checked into the repository yet, but it'll probably go in tools/dev/ when it does.
Later in the week, he actually got it working, sending mail to the appropriate mailing lists. With any luck the mailing lists themselves will be up and running by the time you read this.
Jens Rieks found what looked like a problem with subclassing, which turned
out to be a problem with
clone not going deep enough. Simon
Glover tracked it to its den and Dan Sugalski fixed it.
Good news! Dan says the infrastructure is in place to do delegated method calls for vtable functions with objects. Bad news! It doesn't actually work because it's impossible to inherit from delegate.pmc properly. Dan pleaded for someone to take a look at pmc2c2.pl and or lib/Parrot/Pmc2c.pm and fix things so that the generated code is heritable.
Bernhard Schmalhofer posted a patch to improve the Parrot implementation of the m4 macro language.
I don't use vim, but it seems that Leo Tötsch does. He's added some handy dandy vim syntax files for IMC code. If you're a vim user you might like to check it out. Leo points out that the syntax tables might well be handy if you don't know all 1384 opcode variants by heart.
Sadly, Jens Rieks' Parrot and SDL implementation of tetris didn't quite make it under the wire for the 0.1.0 release. However, Leo has got round to trying it and is impressed, though he did spot a few bugs (it doesn't spot that the game is over for instance). Jens is working on fixing those (and on adding new features), which he reckons will go a deal faster when IMCC has better syntactic support for OO techniques.
To paraphrase Barbie: Dates and Times are Hard. Not that hardness has ever stopped Dashing Dan Sugalski before. This time he waded into the swamp that is Parrot's handling of dates, times, intervals and all that other jazz. He started by soliciting opinions. He got quite a few.
The discussion can probably be divided into two camps: KISS (Keep it Simple) people, and DTRT (Do The Right Thing) people. But KISS still has it's complexities (which Epoch do we want? Should time be a floating point value?) and what, exactly, is the Right Thing? The catch is, time is a messily human thing, and computers are really bad at messy humanity.
Larry said that Dan could do what he wants with Parrot, but he wants Perl 6's standard interface to be a floating point seconds since 2000. He argues that "floating point will almost always have enough precision for the task at hand, and by the time it doesn't, it will. :-)". He also argued that normal users "should never have to remember the units of the fractional seconds".
Zellyn Hunter pointed everyone at Dave Rolsky's excellent article on the complexities of handling dates and times with a computer.
Discussion is ongoing, but it seems that Larry and Dan are leaning towards the KISS approach.
Anyone who has been reading the internals list for any length of time, or who has chatted to Dan about Parrot on the #parrot irc channel will be only too aware that Dan isn't the greatest fan of the OO silver bullet. So, getting the initial objects implementation out there was the sort of thing he probably hoped would mean he didn't have to come back to objects for a while. Except, once you've got part of an object implementation, the need for the rest of it just seems to become more pressing.
So, poor Dan's been doing more OO stuff. This time he sketched out where he was going with initialization, finalization and fallback method location. The basic idea is that, instead of mandating particular method names for different tasks (which seems like the easy approach, but doesn't work across languages), we mandate particular properties which tag various methods as being initializers/finalizers/fallbacks. He outlined his initial set of standard properties and asked for comments.
Leo liked the basic idea, but suggested that, in the absence of any such properties on a class's methods, Parrot should fall back to some methods on a delegate PMC.
Leo posted the results of a couple of benchmarks. They weren't very encouraging. It seems there was a memory leak. And some inefficiencies in object creation. And some more inefficiencies in object creation. By the end of the mini thread, things had got a good deal faster. Quite where it puts us against Perl 5 and Python wasn't mentioned.
Michael Scott, who has been doing sterling work on Parrot's documentation wanted to remove some non-modified, non-parrot Perl modules from the Parrot distribution and have people install them from CPAN. Dan disagreed quite strongly. The current rule of thumb is that Parrot is allowed to depend on finding a Perl 5.005_0x distribution and a C compiler. Any Perl modules it needs that can't be found in that distribution should be provided as part of the Parrot distribution.
Larry argued that we should separate the notion of the developer distribution from the user distribution. The developer codebase is allowed to have any number of external dependencies ("dependencies out the wazoo" was Larry's chosen phrase), and the (for plural values of 'the') comes with all the bells and whistles a distributer sees fit to include. He argued that the developer codebase should be completely unusable by anyone but developers to prevent ISPs from installing that and then claiming to "support Perl".
Dan wondered whether we were going to need to treat vtables as garbage collectible objects, and if we did, what kind of hit that would entail. He and Leo discussed it, and Leo reinvented refcounting as being a possible way to go rather than full DOD type collection.
Jens Rieks added ParrotObject support to his Parrot data dumper. Dan applied it. Go Jens.
Brent Dax is working on writing a parrot implementation of Parrot::Config. His initial idea for implementation involves generating a PerlHash of configuration info and then freezing it to disk. However, when he tried it he had problems with freezing strings, so he asked for help. It turned out to be a simple matter of unimplemented functions, which he and Leo rapidly implemented. A patch with Brent's implementation appeared shortly afterwards.
Leo wondered if anyone could implement an equivalent of perlbench for parrot's benchmarks to do speed comparisons of Parrot, Perl, Python etc implementations. Sebastien Riedel delivered the goods.
Everyone carried on discussing Damian's Exegesis 7 on Perl6::Format, there was even a surprise appearance by Tom Christiansen, who demonstrated a novel, if computationally intractable, approach to generating fully justified text.
Remember last week, Larry had proposed using
& in Perl
6 rules as a way of matching multiple rules at the same point in the
string. Damian liked it a lot and said he'd be delighted to add support
for it to the semi mythical Perl6::Rules module. So, Larry said the
word ("Execute!", which wasn't quite the word everyone expected)
so Damian tugged his forelock and added it to his todo list. Questions
like "What are the precedence rules for
| in regular expressions then?" haven't been asked
Nigel Sandever wondered if Perl 6 will be able to detect undefined subs
at compile time. Larry thought it would be in theory, if you ask it
to check in a
CHECK block, and you're prepared to assume
INIT block will fill in the
blank later, and there's no
AUTOLOAD that might catch it.
Sounds rather a like "Not in the general case, no" to me.
INIT up prompted Rafael
Garcia-Suarez to ask what the rules would be for them in Perl 6 because
they're pretty broken in Perl 5. (Sometimes you want
INIT semantics to work well when you're loading a module
at runtime, and Perl 5 doesn't do that). It looks like he's going to
get his heart's desire on this (A big "Yay!" from the direction
of Gateshead). Dan Sugalski popped over from perl6-internals to point
out that Parrot would be using properties rather than specifically named
blocks for this sort of stuff.
Larry eventually made a ruling which uses properties in a rather cunning fashion. Check his message for the details.
http://groups.google.com -- Larry on magic blocks
Crumbs, another Monday night, another summary finished. I've got to be careful here, it might by habit forming.
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:firstname.lastname@example.org, or drop by my website.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk/ -- My website, "Just a Summary"