Good afternoon readers. You find me sitting comfortably and tired after a vaguely frantic week involving large amounts of new (and huge) equipment, the delivery of a new Mini Cooper, and four days offline at a large format photography workshop (photos will be going online soonish, if you're interested). All of which hopefully goes some way to explaining the fact that I've only just started writing the summary at ten to four on Tuesday.
We start (and finish) with the internals list.
Leo Tötsch isn't exactly happy with the current classes/pmc2c.pl PMC compiler. He outlined the drawbacks as he sees them, proposed a scheme for reimplementing it, and asked for comments. Dan said that so long as the resulting code is clearer than the current PMC compiler, Leo should go for it. So he did.
Melvin Smith has added a LANGUAGES.STATUS file in the languages/ subdirectory and asked for language authors to add summaries of the various language subdirectories to the file.
Fresh from this success he added a CREDITS file for giving credit where it's due. Rumours of an entry reading
N: Leon Brocard D: Running Joke
are (currently) false.
Later in the week, LANGUAGES.STATUS was extended to cover both the languages found in languages/ but any other languages that people were working on and making available outside the Parrot distribution for whatever reason.
Dan's solved an off by one error with multimethod dispatch and checked everything in, so now Parrot has working two argument multimethod dispatch. Hurrah! There's still lots it doesn't do mind, but getting started is always good.
Dan's searching for a Unicode Monster Wrangler. ICU is now building on enough platforms that the time has come to build an encoding and chartype library for it. Volunteers gratefully received.
Jeff Clites and Michael Scott have both been poking at it a bit; hopefully they'll be able to put their heads together and emerge with something wonderful.
Dan's been a busy boy this week. Parrot now comes with library/postgres.pasm, an interface to libpq (the C library that talks to Postgres). These NCI interface files are currently built by hand. Tim Bunce wondered if it might be possible to ExtUtils::XSBuilder to generate PASM from C header files instead of XS code. It was generally agreed that this would be a cool thing, but it's not been done yet.
Amir Karger is working on getting his head 'round the Z-Machine (The virtual machine that runs Zork and the other Infocom games, amongst others) by writing code to translate Z-code into a Perl executable. He came up with a problem with saving and restoring the stack in order to save the game state.
Leo's been giving the Reference PMC a hard look and, as a result,
suggests adding a couple of handy ops,
finds the type of the thing the reference refers to) to use with
them. Melvin Smith pointed out that, actually we only needed one of
Leo's proposed ops. On the other hand, as Nicholas Clark pointed out,
ref avoids the need to grab another PMC register, which may cause
a register spill. On the gripping hand, Melvin argued that spillage
is pretty rare with the number of registers Parrot has.
Jürgen Bömmels found a subtle bug where objects that had active destruction weren't having their destroy functions called correctly (at all) when parrot terminated. After a couple of goes round the '``this would be so much easier if we were all in the same room'' misunderstanding' loop, the Right Thing was settled upon and implemented.
One of the things that Dan would really like to be able to promise with Parrot's GC is ordered destruction. Taking a leaf out of my lightning talk on complexity management, he noted that ``we just need to order the PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it'' and asked for volunteers to implement it.
Dave Mitchell spoilt the understatement party by pointing out that, in the presence of circular dependencies things got a little more complicated (but not that much more complicated, Dan claims).
Nobody's actually volunteered yet.
Melvin Smith added a
pioctl op for general purpose IO manipulation
in the style of the UNIX
ioctl syscall. Dan reckoned it was almost
certainly time to start thinking about a better API (though we're not
sure if that's because he doesn't like
ioctl as a name). Steve
Fink suggested using keyed access to the IO PMC, so you could do
set IO, P0[.BUFSIZE] set P0[.BUFSIZE], 8192
Steve later backed away from this suggestion, suggesting that maybe
get/setprop fit the semantics better, but Leo thought that
'fundamentals' like buffer size belonged as keyed access, with
properties being reserved for setting up things like encoding
Gregor N. Purdy suggested that, instead of going through the hassle of explicitly setting up a function call under the parrot calling conventions, one could call the the function in the style of a macro call. Leo wasn't keen, IMCC is still an assembler after all (just a very sophisticated one). It looks like, unless Dan rules otherwise, we're going to stick with the current explicit method of function invocation setup, and human parrot programmers will just have to set up convenience macros explicitly.
I'm really sorry I used the '...' joke about perl6-language again. Write something people!
Tuesday continues to be the new Monday, and will probably remain so for a while.
http://www.bofh.org.uk:8080/ will hopefully be hosting my photos from the weekend's workshop.
If you found this summary valuable, you might like to consider one or more of the following suggestions:
- Get involved. There's at least two calls for volunteers out at the moment related to Parrot. Okay, they're not necessarily easy, but if you turn up on the lists (check http://dev.perl.org/perl6/ and http://www.parrotcode.org/ for subscription details) and offer to help I'm sure we'll find something that needs doing.
- Support Larry, Dan, Damian and company by donating to the Perl Foundation at http://donate.perl-foundation.org/. Fun as hacking Perl 6 no doubt is, it's very easy to get distracted from it by the pressing need to feed yourself.
- Boost my ego. Praise my photos/this summary/my lackadaisical weblog. Suggest improvements, point out my grammatical howlers, hire me to do cool stuff, press gifts upon me. Contact me at email@example.com, unless you're a spamming scumbag I can pretty much promise you a prompt response. Assuming I'm not out hooning 'round the countryside in my new car...