This Fortnight on Perl 6, Weeks Ending 2004-04-18
by Piers CawleyApril 22, 2004
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!
|
Related Reading 
Perl 6 Essentials |
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
Pages: 1, 2 |
