|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Another week, another late summary. Luckily it's been a quiet week so I should get this written faster than usual. As is traditional, we start with perl6-internals
Andy Dougherty and other discussed extending the Parrot build system
to allow for building parrot itself outside the main source directory
(useful when Parrot's mounted read only via NFS for example. It's not
(quite) possible to do this just yet because of a couple of generated
files in the IMCC tree. Leo suggested only generating those when
Configure.pl --maintainer is run, on the grounds that a maintainer
shouldn't be building from a read only source. Dan asked for a
volunteer to fix things up.
I (and others I presume) got ready to do the "Happy! Happy! Joy! Joy!" dance of delight; this was the week that Parrot finally got objects. Or, as Dan described them, 'objects-ish'. Parrot now has single inheritance objects. They're not the final word on the matter, but it's definitely better than a poke in the eye with a sharp stick.
Dan went on to discuss what needs to be done with them before we're ready for Parrot 0.1 (Objects are one of the criteria for making a point release).
Dan then went rather quiet, apparently because he got mugged by flu, or something like it, and spent the rest of the week wishing he were dead.
Meanwhile, Leo lived up to his Patchmonster nickname by checking in a bunch of object related stuff.
groups.google.com[10.0.1.2] -- Rumblings
groups.google.com[10.0.1.2] -- Announcement
groups.google.com[10.0.1.2] -- The way forward
groups.google.com[10.0.1.2] -- Dan gets mugged by flu
groups.google.com -- Leo's patches
Cory Spencer wondered about 'proper exception raising' and wondered what the state of play was, and if there were any good examples. Leo Tötsch pointed him at t/pmc/exception.t
Pete Lomax had wondered about package/file local variables in IMCC. At the moment IMCC variables can't be file or package scoped, but Melvin Smith is working on it. As he said this, he asked for suggestions for other potential IMCC features. Cory Spencer wanted to be able to write
if _some_test() goto LABEL
but that was vetoed by Dan (and Melvin) as being rather too high level for an intermediate language that's meant to be a compiler target.
Melvin Smith put forward a convincing argument that IMCC shouldn't
concern itself with doing string interpolation as the expected
behaviour is too 'high level language' dependent, but that Parrot
should have a
sprintf equivalent, implemented in C for
speed. Dan seemed to agree and reckoned it should be addressed as soon
as objects were out of the way.
Melvin Smith posted a list of pending IMCC changes, most of which were concerned with tightening up IMCC behaviour (making it both stricter nd more forgiving...). Discussion ensued.
A few days later, Melvin committed some of his changes.
Leo applied a 'really long pending patch' which should simplify upcoming vtable changes. Melvin wondered if the time had come to replace the existing ops2c and pmc2c with the newer versions. Leo thought that pmc2c2 was definitely stable enough, but wasn't too sure about ops2c2. Jonathan Worthington pointed out a Win32 bug that was quickly fixed.
Sterling Hughes noted that, in PHP it's valid to index a string as if
it were an array. He wondered it would be possible to implement
get_pmc_keyed() on the PerlString vtable to allow for similar
tricks with the standard string PMC. I'm confused as to what the
decision was. I think Leo agreed that it was a good idea, but that it
should probably be implemented in a new PMC for the time being...
Pete Lomax stumbled over a bug in IMCC's register allocation. Melvin thinks the problem is that much of IMCC's flow analysis code doesn't yet know about the Parrot Calling Conventions and went to have a look to see if there was a quick fix available.
Jürgen Bömmels is working on having the Parrot IO system's
open return a PMCNULL on failure instead of an invalid IO-Object
(sounds like a good idea to me). The catch is, there doesn't seem to
be any way for the bytecode to detect that this has happened. There
was some debate about whether what Jürgen was doing was the
right thing, or if we shouldn't introduce a new null.pmc, or some
other possibility. The consensus in the end seemed to be that using
PMCNULL was probably the way to go, but an appropriate test operator
hadn't been finally decided upon (but
are the front runners).
After last week's kerfuffle about the different types of equality Cory
Spencer still needed a test for testing if two PMCs had the same
address so he posted a patch to add an
eq_addr opcode. Melvin Smith
still wasn't sure that the name was quite right though and asked for a
description of why Cory needed it (he needs it for implementing a Lisp
Harry the Surnameless has gone through the makefiles in search of the broken dependencies that meant that parallel makes didn't work and posted a patch. However, he worries that the patch may well introduce other problems.
The only game in town was the ongoing discussion of Properties, which morphed into a discussion of Larry's tantalizing role based OO formulation. People are generally impressed and excited by what Larry has so far revealed and, in the continuing absence of Apocalypse 12 are speculating like mad. It's fascinating, but it's also next to impossible to summarize beyond saying "People talked excitedly about OO".
Oh yes, if you've not been following,
^op (ie, the vector operators)
>>op<< which is, if nothing else, a
right swine to write in a POD C<> escape.
Nope, still no link shortening.
Um... many apologies to Leon Brocard. Last week I stated that he'd become the new Pumpking for Perl 5.004 and would not be appearing as a running joke in these summaries until he relinquished the pumpkin. However, what I should have said is that he has become the new Pumpking for Perl 5.005_04 and will not be appearing as a running joke in these summaries until he relinquishes said pumpkin.
Any suggestions that last week's mistake was deliberate so I could continue the joke for one more week are utterly without foundation.
It was just an 'amusing' consequence of my stupidity, obviously.
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the Perl 6 effort. I also welcome feedback at [email protected]'>p[email protected] or at my website.
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
www.bofh.org.uk -- My website, "Just a Summary"