The Perl 6 Summary for the fortnight ending 2004-04-18
The only problem with summarizing two week's worth of Perl 6 happenings
is that there's twice as much stuff to summarize. Still, there's no way
I could have made the time to write a summary last week so I'll take my
lumps. I am exceedingly grateful that Apocalypse 12 (Objects) wasn't
released the Thursday *before* Easter though, as it is I can clear the
decks for the expected perl6-language explosion next week.
We'll start with perl6-internals as usual.
Initializers, finalizers and fallbacks
There was some discussion of the various functions that get called by
object initialization/destruction etc. Dan wondered what he'd been
thinking when he declared that there would be distinct "FINALIZE",
"DELETE" and "CLEANUP" properties (instead of declaring that a function
must be called (say) "FINALIZE", you can mark any function with a
"FINALIZE" property, and Parrot will recognise that as the function to
call at finalization time). Andy Wardley quibbled about American/British
spelling, but Tim Bunce pointed out that the 'ize' form is preferred by
the Oxford English Dictionary (and your humble summarizer).
Leo meanwhile made a (Warnocked) proposal for a new init scheme.
http://tinyurl.com/2s2xp
http://tinyurl.com/2dfj8
New SDL Parrot bindings
Taking advantage of Parrot's new, improved object system, chromatic
updated us all on his efforts to provide a shiny OO interface to the SDL
library. Jens Rieks wondered about chromatic's implementation choices,
and posted a few suggestions and questions. Dan reckoned he'd prefer it
if the SDL bindings used Parrots internal events systems. The catch
being that Parrot doesn't actually have an internal events system yet...
Later in the fortnight, chromatic posted an initial release and promised
to post his notes and slides from the Portland Perl Mongers meeting
where he was showing it off. There's no sign of 'em yet though.
http://tinyurl.com/265sg
http://tinyurl.com/2kpax
"new" method
Jens Rieks and chromatic were unsure of the best name for a constructor
method. They'd like to be able to write a method called "new", but IMCC
wouldn't allow it. Leo T�tsch pointed out that there's already a default
constructor method: "__init". However, chromatic wasn't too keen on it
because he wanted to be able to pass arguments to the constructor. Leo
pointed out that, although it wasn't officially supported, you could
pass arguments in the same was as if you were making a normal parrot
function call.
Dan pointed out that our current initialization system is some way from
being the final one (which will use properties to mark constructor
methods). What we have now is more like an allocator than a real
constructor.
http://tinyurl.com/3gv6y
Overriding "__find_method" in PASM?
Noting that, according to PDD15, defining a method called __find_method
should allow Perl 5 AUTOLOAD-like behaviour, chromatic wondered if it
was workable yet and, if it wasn't, how he should go about adding it.
Leo confessed that what was in the docs was a cut and paste error and
AUTOLOAD behaviour hadn't yet been defined. He suggested a workaround
using exceptions (which turned out to be overkill for what chromatic
needed, but it looks interesting.)
http://tinyurl.com/ypvze
Language interoperability
Randy W. Sims popped over from the Module-Build mailing list, where
they've been discussing plugin architectures to allow for the
modification and extension of Module::Build's capabilities. One of the
desiderata is that, once the transition to Parrot is underway, it should
be possible to write plugins in any language supported by Parrot.
(Mmm... a build system written in Befunge, it's what the world's been
crying out for I tell you). There are currently two competing schemes,
one involving manipulating the class hierarchy at runtime and the other
involving plugins held in particular directories and a formal API. Randy
wondered if there were any technical reasons to choose one scheme or
another.
Dan reckoned that there were no particular technical reasons, but the
inheritance based scheme rather offended his sensibilities, going so far
as to say "No way in hell it'll ever make it in as parrot's standard
module building system if you do it [the inheritance munging solution]".
http://tinyurl.com/33nsw
Save the Return Continuation!
The ongoing discussion about continuations seems to be fizzling
slightly. Piers Cawley had proposed moving the return continuation out
of P1 and held 'somewhere else' (possibly the control stack) and then,
when a routine needed to do cunning things with the current continuation
it could access it with some op (say "get_current_cont"). Dan reckoned
he was okay with the idea, and Luke Palmer voted in favour of a special
RC register. Dan asked for further discussion and the whole thing got
tossed onto the horns of Warnock's Dilemma.
http://tinyurl.com/2x896
Rounding up pending objects
Dan asked for a list of pending issues with objects so he could get
things nailed down and finished so we could move on. Jarkko Hietaniemi,
chromatic and Leo all chimed in with suggestions.
http://tinyurl.com/2te57
Release the Streams!
Jens Rieks posted a "working version" of his new Stream library,
promising more documentation later in the month. Leo and Dan looked on
it, saw that it was good, and granted Jens commit privileges.
Congratulations are in order.
Later, Leo found some bugs around continuation and context handling and
set about tracking it down. (Jens had thought it was an issue with
string handling.)
http://tinyurl.com/3bxjo
Parrot libraries
Leo pointed out that we currently have two different places to find
Parrot runtime stuff: runtime/parrot/* and library/. He proposed we pick
one, add some support for handling library search paths, work out a
scheme to organize library paths and add some library tests. Dan decided
everything should go in runtime/parrot and mused about handling library
metadata.
http://tinyurl.com/2ppqb
Splitting interpreter.c
Apparently interpreter.c runs to rather more than 2500 lines. Leo
proposed splitting it into multiple files. Dan told him to go for it.
http://tinyurl.com/2b6br
Incorporating ICU
I have a rule of thumb about Unicode: Nobody likes it. Nor does anyone
dislike it enough to come up with something better.
Jeff Clites dropped the list a line to let everyone know that he's still
working on integrating the ICU Unicode library into Parrot. (A thankless
task if ever there was one.) With some encouragement from Dan he posted
his (huge) patch. After some debate, Dan checked it in giving a baseline
to start dealing with any issues.
Jeff explained the rationale of his approach (which I have to confess I
skimmed, I don't care how strings work, so long as they work). Jarkko
liked it, noting that other approaches lead "into combinatorial
explosion and instant insanity". Jarkko went on to share his Unicode
pain and generally back Jeff up in discussions with Leo. If you're
interested in the gory details of Unicode implementation, I commend this
thread to you. Or you can just trust Jeff, Jarkko, Leo, Larry and Dan to
get it right (which is what I'm doing).
http://tinyurl.com/37c7s
http://tinyurl.com/3x2h3 -- Jeff's explanations
Tracking JIT down
In another of his ongoing series of simple perl tasks for the
interested, Dan asked for a script to generate a list of all the ops
that aren't JITted (along with a few extra goodies that would be nice).
Stefan Lidman was the man with the script, which was rapidly checked in.
http://tinyurl.com/2zg2j
Diamond inheritance is broken
If you've ever sung bass in choir you'll be aware that sometimes a bass
line is sung on one note for rather a long time. For the past two weeks
perl6-internals' repetitive bass note has been the failure of test 17 in
t/pmc/object-meths.t. Should you find yourself building a CVS parrot and
get caught by this, please be aware that we know about the problem it's
just Dan's suffering from a tuit shortage and there are other important
strings he's concentrating on.
New libraries
Jens "The librarian" Rieks released another set of libraries,
"Data::Sort", "Data::Replace" and "Data::Escape". Tim Bunce wasn't that
keen on his choice of names (and indeed functionality). The current
front runners for new names for these are "PMC::DeepReplace",
"PMC::Printable", "PMC::Sort" and "PMC::Dumper".
http://tinyurl.com/3elvk
Attribute questions
Mark Sparshatt wondered how to handle class attributes, with particular
reference to implementing Ruby. Dan reckons we'll get proper class
attributes once he's sorted out metaclasses. Mark muddied the water
somewhat by pointing out that Ruby has two kinds of class attributes;
ones that are hung off metaclasses and those that are (I think) held in
the class namespace. Annoyingly they have two distinct behaviours.
http://tinyurl.com/2nvkd
Tcl PMCs
Will Coleda posted his first cut at a set of PMCs to support TCL
semantics. He apparently had problems with the Array PMC's assumption
that 'empty' slots contained PerlUndefs, which meant he had to implement
a custom TclArray PMC. For the rest of the thread Will and Leo worked
out how to re-jig the patch so the PMCs could be dynamically loaded
before Leo checked it into the repository.
http://tinyurl.com/29c5t
Parrot Everywhere
I've not really mentioned his work in recent summaries, but Marcus
Thiesen has been doing sterling work helping to get Parrot up and
running on a bewildering variety of systems. Thanks for the sterling
work Marcus.
http://tinyurl.com/2v8b5 -- Marcus's Smoker
Warnocked
Bryan C. Warnock posted a patch to Parrot's CREDITS, correcting a long
defunct email address. You might enjoy the patch:
N: Bryan C. Warnock
+D: Little things here and there in pre-Parrot days.
+D: And, yes, {sigh}, *that* Warnock.
+E: [EMAIL PROTECTED]
He's too modest of course, Bryan started off writing the Perl 6
Summaries. When he stopped doing them due (I presume) to a lack of time,
I missed them so much I started writing my own. So don't blame me for
these, blame Bryan.
Rather appropriately, nobody commented on the patch.
http://tinyurl.com/yve38
Unicode step by step
Leo T�tsch posted a quick overview of steps to get Unicode support into
Parrot. Right now, if you turn Unicode on, your (at least) first build
is going to take a looong time.
Debate centred on whether or not the Parrot distribution should include
the full ICU distribution. (It's looking like a qualified yes, but we
will attempt to use an existing installation of ICU if we can find it.)
http://tinyurl.com/2rjw9
Disappearing PASM files in the test directory
Leo wondered what had happened to the generated .pasm files in t/*/ (he
wasn't alone in this, but he was the person who posted). Will Coleda
confessed that he'd doctored Parrot::Test so that they ended up in /tmp
(probably). He didn't say why.
http://tinyurl.com/2dxhp
ICU build pains
I don't normally discuss issues people have with building Parrot on
various different machines either (the threads usually die out quite
quickly: "Did you do this?" "Oh! Thanks, that worked.") but the ICU
check in seems to have caused no small amount of pain on Linux systems
for some reason.
Alberto Manuel Brandao Simoes posted an error log for a failing build.
Jeff Clites, our Guru of ICU set about helping him to track the problem
down with incomplete success. Dan pointed everyone at Debian's patches
to get ICU to build, and suggested that people wait for his patch to
allow the use of an existing ICU installation.
Various other threads continued the discussion, at the end of which Dan
had checked in a patch that seemed to solve the problems.
http://tinyurl.com/25nrx
http://tinyurl.com/2ka8h
http://tinyurl.com/3gg4z
Tangled strings
Dan posted the beginnings of his plan for how strings are going to work
in Parrot. On the face of it, not a contentious issue. However, strings
are text, and text is a human cultural artifact, which means there's
politics and really, really, really ugly complexities to deal with if
you want to Do It Right (assuming you can decide what Right is). There
was much discussion. And then there was some more. The trouble is, this
stuff is Important (and it's very important that we get it right
*before* we start implementing the matching engine, otherwise some of
the assumptions it might make about how fast various string
manipulations are might turn out to be very wrong indeed...) and Hard.
Because it's Hard it's rather tricky to summarize, so I'm going to punt
and just give you the root message.
http://tinyurl.com/2nyhe
Basic Library Paths
Dan finally got 'round to designing how Parrot was going to handle
searching for libraries and such. Oh, and he and Jarkko engaged in some
unseemly bragging about VMS which has had all this stuff fixed for ages.
There was a fair bit of discussion, but the response was generally
positive.
http://tinyurl.com/28f2u
Alternative object initializer calling scheme
Leo announced that he'd added a new, property based scheme for object
initialization. Instead of initializing an object automagically with the
"__init" method, you mark any method with the "BUILD" property and
Parrot handles calling it for you. You do have to set the "CALL__BUILD"
environment variable before starting Parrot to make use of it though.
http://tinyurl.com/34kvv
Joseph H��k is back
Long time no see Joseph.
http://tinyurl.com/2ub86
Version bump time?
Dan suggested that, once the ICU patch is properly nailed down, it could
be time to start the push to a 0.1.1 (or even 0.2.0) release.
http://tinyurl.com/3bumn
Lies, damned lies and benchmarks
Leo posted a set of benchmark timings for the OO examples when run with
all current optimizations. The numbers are looking rather good: Parrot's
faster than everything on all but one test, where it's outperformed by
Python. Of course, these aren't the benchmarks that'll determine whether
Dan gets a Pie at OSCON...
http://tinyurl.com/yuhx9
PMC Constants
Leo asked for comments on a proposal for dealing with PMC constants. No
comments so far.
http://tinyurl.com/2c3eq
Meanwhile, in perl6-language
Backticks
A proposal for a new use of backticks was made (because the proposer
didn't think the current semantics deserved their privileged place in
the language's Huffman table). Some people disagreed. Some people
disagreed rather strongly. Toys were thrown out of prams. People called
each other narrow minded. It wasn't pretty. With any luck people are
going to calm down, apologize to each other for getting so aerated over
something so trivial, and the list can settle down to the more rewarding
task of dealing with the implications of Apocalypse 12.
http://tinyurl.com/24qoy
Compatibility with Perl 5
Dave Cantrell wondered how Perl 6 would spot legacy code. Everyone
forgot to refer him to the appropriate section of Apocalypse 1 in which
Larry lays down the two rules:
* Files that are pulled in with "require" etc will be deemed to be
Perl 6 unless they contain a "package" declaration.
* Files that are run as scripts ("perl some_script.pl") are treated as
Perl 5 unless it's obviously Perl 6. The proposed way of making this
obvious would be to begin the script with "module Main".
Easy eh? It didn't stop the thread running and running though (not
helped by someone getting the rules of thumb rather badly wrong in the
early stages).
http://tinyurl.com/2jd5z
Oooh look, it's an apocalypse
Apocalypse 12 finally stepped out of the drafty shadows into the glare
of publicity. It's very long. I expect next week will be rather busy on
p6l.
http://tinyurl.com/3fjyj
And we're done
A reminder to everyone on perl6-language: Play Nice.
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:[EMAIL PROTECTED]
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
