This week's summary
Piers Cawley
Welcome to my first anniversary issue of the Perl 6 Summary. Hopefully
there won't too many more anniversaries to celebrate before we have a
real, running Perl 6, but there's bound to be ongoing development after
that. My job is secure!
Because I can't think of anything better to do, I'll start with the
action on the perl6-internals list
Converting parrot to continuation passing style
The ongoing effort to convert Parrot to use/support continuation passing
style (CPS) at the assembler level continues. Jonathan Sillito offered
another patch implementing the require support, which Dan liked and
applied.
Klaas-Jan Stol wondered what he'd missed; last time he looked Parrot
wasn't doing continuation passing. He asked why Dan had chosen to go
down that route. Dan answered that he had realized that "we had to save
off so much state that we essentially had a continuation anyway".
Explicitly going with continuation passing just made things more formal,
and wrapped up all the context saving behind a straightforward
interface. He promised a more detailed explanation later.
Portable way of finding libc, unbuffered reads
Clinton Pierce noted that the following code:
loadlib P1, "/lib/libc.so.6"
dlfunc P0, P1, "system", "it"
set I0, 1
set S5, "ls"
invoke
end
just works, which simultaneously pleases and scares him silly. He
wondered if there was a good way of finding the standard C library on a
Unix system without scary hardwiring as in the fragment above. He also
wondered if there was an 'official' way of getting an unbuffered read
via parrot.
Jens Rieks came up with a gloriously evil way of finding libc. The
theory goes that Parrot is linked against libc, so you just have to
"dlopen" the running image and you can call libc functions to your
heart's content. To dlopen the running image you need to pass a NULL
pointer to the underlying "loadlib" so he offered a patch to core.ops
which interpreted an empty string as a pointer to NULL. Leo and Dan were
impressed and the patch (or something similar) was applied. I get the
feeling that Dan wants to do something a little less hacky to access the
current executable though...
Clint noted that the dlopen the running image by passing a null pointer
trick doesn't work with Windows, but outlined a workaround for that too.
Jen Rieks suggested a better Windows workaround.
Nobody came up with an approved way of doing "getc", but once you have
libc loaded you can just use its "getc".
OO, Objects
If you look in a fresh from CVS parrot directory you'll now find
object.ops, which will be the cause of much rejoicing in many places.
Dan's nailed the object spec down enough that he's started implementing
a few of the required ops. As he points out, what we have is "hardly
sufficient", but everyone's got to start somewhere, the journey of a
thousand miles begins with but a single step, etc.
Judging by the number of comments (none), everyone was stunned into
silence.
More CPS shenanigans
I get the strong feeling that Leo Tötsch isn't entirely happy with the
new Continuation Passing Style regime. He's worried that the P6C tests
break, and that CPS subs are some 3 times slower for calling the sub.
This led into a discussion of what context really must go into a
continuation, whether we can get away with different classes of
continuation (hold more or less contextual information) and other ways
of possibly speeding things up.
I'm not sure Leo has been entirely convinced, but I'm confident that
Dan's not going to change his mind about this.
Leo later submitted a large patch which unifies the various subroutine
related PMCs to take into account CPS.
Exceptions
Now that the rules for subs/methods etc are settling down, Dan outlined
his thoughts on exception handlers. If I'm understanding him correctly,
an exception handler is just a continuation that you invoke with the
exception as its only argument. There were no comments by the end of the
week.
Meanwhile in perl6-language
The language list was quiet again. Maybe everyone was doing face to face
things at YAPC. Or on holiday. Or something.
"printf" like formatting in interpolated strings
Remember last week I mentioned that Luke Palmer had made a cool
suggestion about "printf" like formatting in string interpolation? (He
suggested a syntax like "rx/<expression> but formatted(<formatspec>)/",
which I for one quite liked).
Edwin Steiner wasn't so keen, noting that Luke's suggestion was actually
more verbose than "rx/sprintf <formatspec>, <expression>/". He wasn't
entirely sure that having a formatting rule attached to a value with a
'but' was really the right thing to do (it does rather violate the whole
model/view/controller abstraction for instance). Edwin's favoured
interpolation syntax was,
rule formatted_interpolation {\\F <formatspec> <interpolatable_atom>}
rule formatspec { # sprintf format without '%'
}
rule interpolatable_atom { <variable> | \$\( <expr> \) }
(or something along those lines). Edwin went on to extend his idea,
allowing for all sorts of clever interpolation rules, leading Dave
Storrs to comment that the Obfuscated Perl people would certainly thank
him if the suggestions went in.
Arcadi Shehter came up with yet another suggested syntax involving ":"
(neglecting the important rule that, whilst one's heart my belong to
Daddy, the ":" belongs to Larry. And I'm really trying not to think
about the images that conjures up).
At this point, we ended up in a philosophical discussion about when was
the right time to do stuff, generality of solutions and Perl remaining
Perl. I remain confident that come the appropriate time, Larry and/or
Damian (more likely Damian given some of the stuff he was showing off to
do with formatting at YAPC) will nail things down and we'll all go "Of
course!" and move onto the next thing.
Dispatching, Multimethods and the like
Adam Turoff noted that, in his YAPC opening talk, Damian had mentioned
the catchall DISPATCH sub, which will allow for altering the dispatch
behaviour to do any magic you choose. The 'problem' with DISPATCH is
defining its interaction with the likes of AUTOLOAD and other built in
dynamic dispatch behaviours, which will need to be nailed down.
Dan Sugalski jetted over from perl6-internals to give the lowdown on
what would be available at the parrot level (which may or may not be
exposed at the Perl 6 language level). Essentially, what we know is that
there will be the capability to insert any dispatch method you like, but
the details of how you'd do it aren't thrashed out yet. It almost
certainly won't be easy, but that's a good thing.
Type Conversion Matrix, Pragmas (Take 4)
Discussion of Mike Lazzaro's type conversion matrix continued as people
explored corner cases.
Acknowledgements, Announcements and Apologies
Whee! My first anniversary! I confess that when I started writing these
things I didn't expect to keep going for this long. Now I don't expect
to ever stop.
After due and careful consideration of a short shortlist, I should like
to award an anniversary virtual white parrot award to Leopold
"Patchmonster" Tötsch for his astonishing contribution to the Parrot
core. Other mental nominees for this award were: Clinton A Pierce, for
BASIC and the associated bug finding; Leon Brocard, for humorous reasons
and Robert Spier and Ask Bjørn Johansen for invaluable and invisible
work on websites, CVS and mailing list maintenance.
I eliminated the core design team from consideration for the above
award, but I'd like to formally thank Larry, Damian, Allison and Dan,
without whom...
As I said last week, Leon Brocard is no longer the summaries' running
joke. However, I auctioned off the right to specify the next running
joke at YAPC last week; next week should see the unveiling of the new,
improved Perl 6 Summary Running Joke.
If you've appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, photographic and writing commissions,
or a cute little iPod with a huge capacity to satisfy my technolust
p6summ...@bofh.org.uk.
--
Piers
Leopold Toetsch
> More CPS shenanigans
> I get the strong feeling that Leo Tötsch isn't entirely happy with the
> new Continuation Passing Style regime.
No, I'm really happy with CPS. Restoring the whole context by invoke'ing
the return continuation is a very elegant and efficient way to do it,
not speaking from tail calls ...
> He's worried that the P6C tests
> break,
... albeit this is still an issue. Nobody answered, if we need another
Sub class implementing the old invoke/ret scheme ...
> ... and that CPS subs are some 3 times slower for calling the sub.
... while this is solved. Jonathans patch that went in originally had
this bad performance. But with separating the Sub/Continuation setup
from the actual subroutine call (which amongst other things my patches
did), performance is back again at the old level. In fact the current
CPS implementation is faster then the old invoke/ret scheme. I estimate
the final speed, when all needed context things are saved, to be about
the same as invoke/ret w/o much context saving.
> Whee! My first anniversary!
Congrats and thanks for your great summaries.
leo
Sean O'Rourke
> Piers Cawley <p6summ...@bofh.org.uk> wrote:
> > He's worried that the P6C tests
> > break,
>
> ... albeit this is still an issue. Nobody answered, if we need another
> Sub class implementing the old invoke/ret scheme ...
I'd say "no". P6C is now compiling to an obsolete architecture.
While we should all step back and be impressed at how well Intel has
maintained backward compatibility in the x86, there's no particular
reason we should do so ourselves. Rather, someone (me) needs to port
P6C to the new machine.
> > Whee! My first anniversary!
>
> Congrats and thanks for your great summaries.
Seconded.
/s
Leopold Toetsch
> ... Rather, someone (me) needs to port
> P6C to the new machine.
Which is currently not quite possible. Someone (me;-) has to implement
imcc/docs/calling_conventions first - adopted for CPS. I'd rather not
have the HL spit out all registers according to pdd03.
Also the register allocator needs rework due to the CPS scheme.
> /s
leo
David Storrs
> On Tue, 24 Jun 2003, Leopold Toetsch wrote:
> >
> > Sub class implementing the old invoke/ret scheme ...
>
> I'd say "no". P6C is now compiling to an obsolete architecture.
> While we should all step back and be impressed at how well Intel has
> maintained backward compatibility in the x86, there's no particular
> reason we should do so ourselves. Rather, someone (me) needs to port
> P6C to the new machine.
/me shows ignorance yet again.
For those of us who are not hardware types...what is "the new
machine"? The Itanium? Does that really have enough market
penetration at this point to be a worthy target? Or is the idea that,
by the time Parrot is finished, it WILL have massive market
penetration?
> > > Piers Cawley <p6summ...@bofh.org.uk> wrote:
> > > Whee! My first anniversary!
> >
> > Congrats and thanks for your great summaries.
>
> Seconded.
Thirded. Although the doings of the internals list fascinate me, they
are usually totally over my head, so I long ago unsub'd. It's great
to be able to follow along via the summaries.
--Dks
Andrew Wilson
> /me shows ignorance yet again.
>
> For those of us who are not hardware types...what is "the new
> machine"? The Itanium? Does that really have enough market
> penetration at this point to be a worthy target? Or is the idea that,
> by the time Parrot is finished, it WILL have massive market
> penetration?
The machine they're talking about is parrot. A virtual machine, but a
machine none the less. The "new machine" is the new calling conventions
recently implemented.
andrew
--
Aquarius: (Jan. 20 - Feb. 18)
Heartbreak is in the stars for you this week when the woman of
your dreams confesses she cannot love a man with such an unholy
appetite for pie.
David Storrs
> On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote:
> > /me shows ignorance yet again.
> >
> > For those of us who are not hardware types...what is "the new
> > machine"? The Itanium? Does that really have enough market
>
> machine none the less. The "new machine" is the new calling conventions
> recently implemented.
>
> andrew
Ah. Of course; I got confused by the x86 references and took them too
literally. Thanks for setting me straight.
--Dks