This Fortnight on Perl 6, Weeks 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 now 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, and so on. 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 recognize 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://groups.google.com/groups?selm=a06010207bc988256b491@[172.24.18.98]

http://groups.google.com/groups?selm=200404060833.i368Xou16545@thu8.leo.home

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://groups.google.com/groups?selm=1081225995.12079.27.camel@localhost

http://groups.google.com/groups?selm=1081317984.19190.2.camel@localhost

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://groups.google.com/groups?selm=200404041830.09293.parrot@jensbeimsurfen.de

Overriding __find_method in PASM?

Noting that, according to PDD15, defining a method called __find_method should allow Perl 5 AUTOLOAD-like behavior, 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 behavior 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://groups.google.com/groups?selm=1081138355.7995.26.camel@localhost

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://groups.google.com/groups?selm=406FDFAB.3050008@thepierianspring.org

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 favor of a special RC register. Dan asked for further discussion and the whole thing got tossed onto the horns of Warnock's Dilemma.

http://groups.google.com/groups?selm=a06010205bc987b530fde@[172.24.18.98]

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://groups.google.com/groups?selm=a06010206bc9880273177@[172.24.18.98]

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://groups.google.com/groups?selm=200404062141.12274.parrot@jensbeimsurfen.de

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://groups.google.com/groups?selm=4073A4CC.7010006@toetsch.at

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://groups.google.com/groups?selm=4073BAAC.5030806@toetsch.at

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://groups.google.com/groups?selm=CFB7F3BE-88B8-11D8-ADF3-000393A6B9DA@mac.com

http://groups.google.com/groups?selm=612F0D93-8A6A-11D8-ADF3-000393A6B9DA@mac.com -- 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://groups.google.com/groups?selm=a0610050ebc9a03e47738@[10.0.1.2]

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://groups.google.com/groups?selm=200404082028.49211.parrot@jensbeimsurfen.de

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 behaviors.

http://groups.google.com/groups?selm=4075919F.30905@yahoo.co.uk

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://groups.google.com/groups?selm=rt-3.0.8-28393-84164.14.5997263059787@perl.org

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://www.luusa.org/~marcus/parrottest -- 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: bwarnock@raba.com

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://groups.google.com/groups?selm=rt-3.0.8-28383-84147.3.00438339593441@perl.org

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 centered 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://groups.google.com/groups?selm=4077F315.6060200@toetsch.at

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://groups.google.com/groups?selm=4077EC4D.3040806@toetsch.at

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://groups.google.com/groups?selm=40784BF0.20608@alfarrabio.di.uminho.pt

http://groups.google.com/groups?selm=a06100503bca05b379e6f@[10.0.1.2]

http://groups.google.com/groups?selm=a06100505bca05f409099@[10.0.1.2]

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://groups.google.com/groups?selm=a06100500bca0384ce81c@[10.0.1.2]

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://groups.google.com/groups?selm=a06100500bca449931036@[10.0.1.2]

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://groups.google.com/groups?selm=40768F70.1010106@toetsch.at

Joseph Höök Is Back

Long time no see Joseph.

http://groups.google.com/groups?selm=381-220044011141848685@kth.se

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://groups.google.com/groups?selm=a06100502bc9cbc80e445@[172.24.18.98]

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://groups.google.com/groups?selm=408009CE.2070804@toetsch.at

PMC Constants

Leo asked for comments on a proposal for dealing with PMC constants. No comments so far.

http://groups.google.com/groups?selm=407FF01A.2080102@toetsch.at

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://groups.google.com/groups?selm=20040414121848.GJ3645@c4.convolution.nl

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://groups.google.com/groups?selm=20040413121602.GA5213@bytemark.barnyard.co.uk

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://www.perl.com/pub/a/2004/04/16/a12.html

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:p6summarizer@bofh.org.uk.

http://donate.perl-foundation.org/ -- The Perl Foundation

http://dev.perl.org/perl6/ -- Perl 6 Development site

Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en