Front page | perl.perl6.language |
Postings from December 2003
This week's summary
From: The Perl 6 Summarizer
December 10, 2003 07:04
This week's summary
Message ID: email@example.com
The Perl 6 summary for the week ending 20031207
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
Parrot build system tinkering
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
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.
-- The way forward
-- Dan gets mugged by flu
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
Compilation units and the boundaries of IMCC
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
"printf"/"sprintf" equivalent, implemented in C for speed. Dan seemed to
agree and reckoned it should be addressed as soon as objects were out of
IMCC pending changes
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.
PMC Compiler 2nd edition
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.
"get_pmc_keyed()" in PerlString
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...
Symbolic vs. Named variable register allocation
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.
Testing for null
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
"if_null" and "unless_null" are the front runners).
Determining PMC memory addresses
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
Fixing the Makefile dependencies
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
Meanwhile in perl6-language
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)
has become " >>op<< " which is, if nothing else, a right swine to write
in a POD C<> escape.
Acknowledgements, Apologies, Announcements
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 firstname.lastname@example.org or at my website.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk:8080/ -- My website, "Just a Summary"
This week's summary
by The Perl 6 Summarizer