| 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 summary. It's been a pretty active week so, with a cunningly mixed metaphor, we'll dive straight into the hive of activity that is perl6-internals.
Discussion and development of Sebastien Riedel's nifty Parrot comparative benchmarking script continued. Leo suggested a handy config file approach which would allow for adding benchmarks in other languages without having to change the script itself.
The initial results don't look good if you're name's Dan and you want to avoid getting a pie in the face at OSCON though, as Dan pointed out, there's a few tricks still to be played in this area. Anyway, benchmark.pl is now in the CVS tree if you want to play with it.
The ever helpful chromatic applied Bernhard Schmalhofer's patch to fix up an endemic speling mostake in some tests. Apparently DESCRIPTION isn't spelt "DECSRIPTION".
Discussion of parrot's handling of dates and times continued this week too. Joshua Hoblitt who works on DateTime.pm (a very handy base for doing date/time handling in Perl 5, you should check it out) said that the DateTime people really, really want is "an epoch that's absolutely fixed across all platforms."
There was also some discussion of where the opcode/library boundary
should be placed, with some arguing that the likes of strftime should
be implemented as opcodes. Melvin Smith responded to this with what
seems to me to be a very telling point: "If we cannot provide a
decently performing VM that makes people want to write stuff in
bytecode (or compiled to bytecode) we have failed anyway".
Toward the end of the week, Dan announced some decisions and questions. Larry had a few quibbles, but otherwise there have been no other comments. Personally, if I never hear the phrase "leap second" again, I'll not be unhappy.
groups.google.com[10.0.1.2] -- Dan's decisions
Dan has come to the view that we need an alternative, light weight, calling convention for calling vtable opcode functions; the idea being that this should speed up objects a tad. He asked for suggestions.
Leo T\xF6tsch wasn't convinced that we really need special calling conventions, arguing (with numbers) that it would be best to concentrate on speeding up object instantiation by optimizing object layout. Simon Glover agreed with him, noting that simply changing the Array that used to store class, classname and attributes gave him a speedup of around 15% on the object benchmarks.
groups.google.com[10.0.1.2]
Last week I said that we can't yet do delegated method calls for vtable functions with objects. Leo pointed out that, actually, we can now. Leo also disclaimed any responsibility for helping Brent Royal-Gordon (n\xE9 Dax?) fix up the support functions for Parrot::Config, though Brent later claimed that he was merely the person doing the typing...
Jerome Quelin noted that parrotbug has already reached version 0.2.1 (I wonder what its version will be when Parrot 1.0.0 gets released).
Not content with his work on everything else this week, Leo has revisited the Garbage Collector and tracked down a couple of bugs including a really nasty sounding one that caused disappearing continuations. He even isolated the problem with a test.
Leo's rearranged the output of parrot -t slightly in an effort to
make it more readable. Jens Rieks was impressed and pointed out a
couple of issues, which Leo quickly fixed.
Dan's day job continues to be a handy driver of Parrot development. This time he needs to make use of namespaces and, whilst namespaces themselves aren't completely nailed down yet, there's enough there that the time has come to work out the syntax for working with them in IMCC. He proposed
.namespace [foo; bar; baz]
as a way of setting the current namespace to foo::bar::baz (in Perl
style, your language may vary). Leo was okay with that as far as it
went, but pointed out that things were slightly more complicated than
Dan's proposal implied. He suggested that the time was right to sort
out the duties of the PIR assembler towards variable names, name
mangling, lexical scopes, namespaces, globals and all that good
stuff. Dan punted slightly on this latter part, saying that, in general
it shouldn't be the assembler's job to track them. The current
namespace would simply be used as the namespace in which to place any
subsequently defined functions. There was the sound of a hand slapping
a forehead from Austria, and Leo went off and implemented it.
groups.google.com[10.0.1.2]
In the process of redoing the Parrot Data::Dumper to use objects, Jens
Rieks built a library of helper functions to make object usage easier,
so he submitted it to the list as a standalone library. Leo checked it
in, you can find it at library/objecthacks.imc
stat?Leo T\xF6tsch proposed a stat opcode for finding out about things in the
filesystem. He outlined a proposed interface. Dan agreed that we'd need
something, but that Leo's proposal was far too unix-centric to work for
a cross platform platform like Parrot. He suggested going back to first
principles and working out what information would be needed (and
possibly available). He also said that one of his guiding principles
for Parrot was that he would "rather not re-implement and expose 35
years worth of 'Whoops, that turned out to be a bad idea' crud."
Josh Wilmes took this opportunity to remind everyone of the proposed miniparrot and pointed out that, if we want it to work again, there needs to be a smooth way to exclude opcodes or PMCs that won't work in miniparrot's environment. Dan agreed strongly, reminding everyone that miniparrot is intended to be the basis of Parrot's eventual build system. (The process will go: Platform specific shell script -> miniparrot -> parrot).
groups.google.com -- Don't forget the miniparrot!
Leo announced that he'd expanded IMCC's PIR parser a bit, allowing you to write:
obj.method(args)
ret = obj.method(...)
(retvals) = obj.method(...)
where method is a label.
A couple of hours later Dan posted a design spec for how he wanted method calls to work in IMCC:
object.variable(params)
object."literal name"(params)
Methods would be declared like:
.pcc_sub foo prototyped, method
.param pmc foo
.param pmc bar
...
.end
Declaring a method in this way would also create a local self which
points to the object PMC register. What do you know, Leo implemented it
all. There is also a more 'explicit' way of making method calls for
those occasions when you need more control. Check the docs/examples for
details.
groups.google.com -- Leo implements at 3pm
groups.google.com[10.0.1.2] -- Dan designs at 5pm
The excellent Jens Rieks posted a test version of his object oriented
version of library/dumper.imc and asked for comments. (Mine was
"Wow!" but I didn't post it to the list 'til now). Leo wondered if he
should add it to the repository or wait for it to get rejigged to take
account of all the improved object syntax changes that had gone into
IMCC. Jens told him to hold fire until he'd converted everything to the
new syntax.
Dan's rejigged the date decoding logic to return months in the range 1-12 instead of 0-11. And there was some rejoicing.
groups.google.com[10.222.20.224]
selfJens Rieks discovered that he couldn't call self."method"(...), or
even compile it for that matter. It turned out to be a problem with the
grammar. Steve Fink provided a grammar fix, Leo tracked down a problem
with registers not getting preserved properly, and there followed some
discussion about the ambiguity of . being used for both method calls
and string concatenation. Luke Palmer suggested (and Melvin Smith
agreed) that it was probably better style to use the concat op
anyway.
Dan's currently seesawing about how to customize object creation by
passing arguments to the constructor function. At present, you create
an object by calling the class's init method, which doesn't take any
arguments, and then call an object method with appropriate arguments to
do any other setup that's dependent on the arguments if you want
to. Dan outlined three ways forward and asked for opinions.
groups.google.com[10.222.20.224]
Nicholas Clark posted to say that Ponie was having problems when built using Parrot's garbage collection. After some encouragement from Leo, he managed to write a short test case that showed the issue in a few lines of C. Leo proposed a solution, but Nicholas and Arthur Bergman (Ponie's core team) weren't happy with either option. This hadn't been resolved by the end of the week.
Matt Greenwood wondered why Parrot had so many opcodes, and what the criteria are for adding or deleting ops. Various rationales were offered. Dan's explanation was probably the most comprehensive though. Apparently, Parrot has opcode explosion issues because there's no runtime op variance and if you want to know what that means, read Dan's post.
groups.google.com[172.24.18.98] -- Dan explains it all
Arthur "Poniemaster" Bergman noticed that Parrot grabs SIGINT, which makes some of Ponie's signal handling code break. He wondered if this was something that needed fixing, or a deliberate design decision. Dan says that, eventually and by design, Parrot will grab all the signals, though not necessarily in the embedded case (which is what Arthur is using of course.)
Arthur Bergman has made the second development release of Ponie, the Perl5/Parrot hybrid. The initial response was positive.
Peter Haworth had a bunch of questions and worries about using numeric offsets to get at class attributes. Dan tried to reassure him, but Oli came up with a worrying corner case. Dan didn't think it was that big an issue, but confessed that it's still a worry.
Poor old Dan; once you've got some bits of objects done, it just means everyone wants more from you. Mark Sparshatt wondered how to handle languages like Ruby, where a class is also an object, which seems to run counter to Parrot's scheme using ParrotClass and ParrotObject PMCs where a ParrotClass isn't a ParrotObject. He suggested three ways forward.
Summarizing this stuff is Hard. One one level you can reduce the issue to a couple of sentences, but understanding those sentences involves rather a lot of underpinning knowledge that I'm not sure I have. I just know that life's an awful lot easier if I can treat classes as objects.
Dan tried to wrap his head 'round things and posted a summary of his initial understanding of what a metaclass is. He wondered if we'd need to have a 'call class method' operation. Paolo Molaro pointed out that most of this stuff only becomes a real issue when you have to deal with objects implemented in one language calling methods on objects implemented in a different one. Leo T\xF6tsch explained Parrot's current (somewhat confusing to these eyes) hierarchy where:
Piers Cawley thought that having ParrotObject inherit from ParrotClass rather than vice versa seemed somewhat perverse. He also argued that method dispatch should be decoupled from method lookup. I think he and Leo failed to communicate.
Mitchell N Charity was good value on all this as well; definitely worth reading if you're into the theory behind OO should work.
groups.google.com[172.24.18.98]
groups.google.com -- Mitchell N Charity on Objects, Classes and MetaClasses
Brent announced that he's been making some significant changes to Configure in the last week or so. He posted a big list. Leo liked what had been done so far, but thought the process needed more steps to probe for more stuff.
=head PIR Syntax changes
Leo announced that he's added some syntactic sugar to PIR; you can now write:
$N0 = sin 0
$I0 = can $P0, "puts"
$I0 = isa $P0, "scalar"
etc, and they'll be magically converted to
PARROT_OP lhs[, args]
which is rather handy (with some ugly cases: P1 = invoke being the
example Leo came up with).
On Sunday, Jens Rieks released his OO version of Data::Dumper, along with a couple of helper libraries, including a rewritten objecthacks.imc, now called objects.imc. Leo committed it (and a followup bugfix) promptly and Parrot now has its first OO application/library. Yay Jens!
Remember last week I implied that magic UPPERCASE blocks for things
like BEGIN, CHECK, INIT etc were being replaced by properties
on variables? Well, I was wrong. We keep magic blocks but we also get
handy properties for attaching actions to variables.
In fact, the handy properties were first discussed in April last year, as Larry pointed out.
Juerd wondered about the possibility of mutating and non mutating
methods in Perl 6. Consider the Perl 5 functions chomp and
lc. chomp potentially modifies its argument, whereas lc
returns a new string. Juerd liked the idea of having mutating and
non mutating versions of both chomp and lc (and other such string
methods). He proposed using
$aString.lc; # Non-mutating
$aString.=lc; # Mutating
The general response to this was favourable.
The thread sparked a discussion of Perl 6 Rules and hypothetical variables (which just makes me hope Damian gets Perl6::Rules written really soon).
Larry posted a chunk of stuff from the forthcoming Apocalypse 12 that looks rather neat. Then he and Simon Cozens started talking Japanese and my head started spinning.
groups.google.com -- Larry tells us more about A12
Carissa wondered if Perl 6 would have what she called 'persistent' operators, so that you could do:
my $a = 10;
my $b = 5;
my $c = $b + $a;
print $c; # 15
$a = 8;
print $c; # 13
Several people pointed out that it's already possible to do this sort of thing in Perl 5 so it'd be a big surprise if you couldn't do the same thing in Perl 6. (See perldoc overload in the section "Really symbolic calculator" for details).
I've had it with discussions of whether Unicode's a good idea or not, and from this summary onwards I'll not be including any such discussions unless Larry does an implausible volte face. That is all.
Now I can go back to being anxious about my stepdaughter who's been in labour for rather a long time.
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], or drop by my website, maybe I'll add some content to it this week.
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
www.bofh.org.uk -- My website, "Just a Summary"